Multicast and pinging from Loopback interfaces

awilkinsawilkins ✭✭
in CCIE Service Provider Technical

Have any of you noticed in the practice labs when trying to source multicast traffic from a loopback interface, it does not work.  It seems to always source itself from the physical interface's source IP.  Even when explicitly sourcing from the loopback, the routers downstream show the physical interface IP address in debugs.  Could this be an IOS related issue?  Have any of you ran across this? 

· Share on FacebookShare on Twitter

Comments

  • shai-lshai-l

    this was already discussed before - try looking in the forums

    anyway its what you call - "not a bug ' but a feature" of IOS to source multicast traffic from "all around" the place ....

    try using extended ping and then sourcing whatever interface you want (specifying all extended options...) - maybe it will work then (should work i think)

     

    Have any of you noticed in the practice labs when trying to source multicast traffic from a loopback interface, it does not work.  It seems to always source itself from the physical interface's source IP.  Even when explicitly sourcing from the loopback, the routers downstream show the physical interface IP address in debugs.  Could this be an IOS related issue?  Have any of you ran across this? 


    · Share on FacebookShare on Twitter
  • awilkinsawilkins ✭✭
    I will look in the forum, thanks.  I should have done that to begin with.

     

    In any event, sourcing off the loopback does not work for me.  I'll see what I can come up with.


    On Sat, Jan 24, 2009 at 9:19 AM, shai-l <[email protected]> wrote:

    this was already discussed before - try looking in the forums

    anyway its what you call - "not a bug ' but a feature" of IOS to source multicast traffic from "all around" the place ....

    try using extended ping and then sourcing whatever interface you want (specifying all extended options...) - maybe it will work then (should work i think)

     



    imageawilkins:

    Have any of you noticed in the practice labs when trying to source multicast traffic from a loopback interface, it does not work.  It seems to always source itself from the physical interface's source IP.  Even when explicitly sourcing from the loopback, the routers downstream show the physical interface IP address in debugs.  Could this be an IOS related issue?  Have any of you ran across this? 





    Internetwork Expert - The Industry Leader in CCIE Preparation
    http://www.internetworkexpert.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx


    · Share on FacebookShare on Twitter
  • shai-lshai-l

    whatever you find - please post it here - i for one will be very intrested to hear what you find...

    · Share on FacebookShare on Twitter
  • jonbovjonbov ✭✭

    i usually forgets to add 'ip pim sparse-mode' on loopback within vrf I am pinging from.

    But extended ping from an ethernet (vrf) interface always gives no more than 2 successful pings. Identical test from loopback interface - no problem.

     

    access-list 134 permit ip any host 230.0.0.1
    access-list 134 permit ip any host 230.0.0.2

    R3#deb ip packet 134
    IP packet debugging is on for access list 134

    R3#deb ip icmp
    ICMP packet debugging is on

    R3#ping vr testvpn
    Protocol [ip]:
    Target IP address: 230.0.0.1
    Repeat count [1]: 10
    Datagram size [100]:
    Timeout in seconds [2]:
    Extended commands [n]: y
    Interface [All]: fastethernet0/0.34
    Time to live [255]:
    Source address:
    Type of service [0]:
    Set DF bit in IP header? [no]:
    Validate reply data? [no]:
    Data pattern [0xABCD]:
    Loose, Strict, Record, Timestamp, Verbose[none]:
    Sweep range of sizes [n]:
    Type escape sequence to abort.
    Sending 10, 100-byte ICMP Echos to 230.0.0.1, timeout is 2 seconds:

    *Jan 24 14:38:33: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast.
    *Jan 24 14:38:35: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:35: IP: s=5.5.34.3 (FastEthernet0/0.34), d=230.0.0.1 (Tunnel0), len 100, sending full packet
    *Jan 24 14:38:35: ICMP: echo reply rcvd, src 5.5.68.8, dst 5.5.34.3
    Reply to request 1 from 5.5.68.8, 4 ms
    *Jan 24 14:38:37: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:37: IP: s=5.5.34.3 (FastEthernet0/0.34), d=230.0.0.1 (Tunnel0), len 100, sending full packet
    *Jan 24 14:38:37: ICMP: echo reply rcvd, src 5.5.68.8, dst 5.5.34.3
    Reply to request 2 from 5.5.68.8, 1 ms
    *Jan 24 14:38:39: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:39: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending full packet.
    *Jan 24 14:38:41: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:41: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending full packet.
    *Jan 24 14:38:43: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:43: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending full packet.
    *Jan 24 14:38:45: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:45: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending full packet.
    *Jan 24 14:38:47: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:47: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending full packet.
    *Jan 24 14:38:49: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:49: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending full packet.
    *Jan 24 14:38:51: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending broad/multicast
    *Jan 24 14:38:51: IP: s=5.5.34.3 (local), d=230.0.0.1 (FastEthernet0/0.34), len 100, sending full packet.

    · Share on FacebookShare on Twitter
  • awilkinsawilkins ✭✭

    Let us look at Lab 6 in the SP Vol II workbook.  There is a Section 6.3 that states the following:

    • Configure the network in such a way that when R5 sends traffic to the multicast group 224.5.5.5 from it's Loopback interface R4 reponds with ICMP echo-replies.

    Here is an example that I see way too many times:

     

    IP PIM Sparse Mode is configured on R5's loopback:

    R5#sh ip pim int

    Address          Interface                Ver/   Nbr    Query  DR     DR
                                              Mode   Count  Intvl  Prior
    20.1.5.5         Loopback0                v2/S   0      30     1      20.1.5.5
    20.1.35.5        Ethernet0/0              v2/S   1      30     1      20.1.35.5


    Command issued at R5:
    R5#ping 224.5.5.5 so lo0
    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 224.5.5.5, timeout is 2 seconds:
    Packet sent with a source address of 20.1.5.5


    Result on R4:
    *Mar  1 00:07:18.471: ICMP: echo reply sent, src 20.1.46.4, dst 20.1.35.5

    R4 never responds to R5's Loopback interface because it didn't get the packet from it. The 20.1.35.5 is the Ethernet0/0 interface on R5.

     

    When R6 pings 224.5.5.5, R4 does see its loopback though.  I'll have to do some digging around.

     

    Ideally, you shouldn't have to source multicast traffic off any interface.  It should automatically source itself from all PIM enabled interfaces on the router the pings are being sourced.

     

     

    · Share on FacebookShare on Twitter
Sign In or Register to comment.