Changing multicast packet source

I got this message when trying to ping a group in lab 4 6.2. Had no ip mroute-cache and deb ip mpacket on.

is it possible to change the packet source? I dont know where its getting 7.7.7.7 from, thats on loopback 7777 in another VRF. I tried ip pim register-source lo0|f0/0.207 but the debug was the same.

 

R7(config)#do ping 239.0.0.5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.0.0.5, timeout is 2 seconds:

IP(0): s=7.7.7.7 (Loopback0) d=239.0.0.5 id=22, ttl=254, prot=1, len=100(100), not RPF interface.

 

 

Comments

  • When do you a ping without specifying the source, the device will send out the multicast packet out of all multicast enabled interfaces. Dependining on who's the DR on the segment, each DR will then register the (S,G) with the RP. If there is no PIM neighbor who is a DR at the other end of the segment, then the multicast packet on that link will simply get dropped. The whole registration process is trigered by an INCOMING packet causing an interrupt on an interface running PIM. 

    The best way to test multicast streams in a controlled fashion is by using extended pings, and enableing PIM on the loopback that you want to test from:

     

    !

    int loo0

    ip pim sparse

    !

    R1#ping

    Protocol [ip]: 

    Target IP address: 239.0.0.5

    Repeat count [1]: 1000

    Datagram size [100]: 

    Timeout in seconds [2]: 

    Extended commands [n]: y

    Interface [All]: loopback0

    Time to live [255]: 

    Source address: 1.1.1.1

    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 1000, 100-byte ICMP Echos to 239.0.0.5, timeout is 2 seconds:

    Packet sent with a source address of 1.1.1.1 

     

    This works well for the following reason: 

    You sent a multicast packet out of a loopback interface. Being a loopback interface, the packet loops back into the router and causes an "interrupt". Since this packet was looped, it is seen as being RECEIVED INTO an interface that is running PIM (the loopback). This starts the PIM Registration process and the rest is normal multicast operation. 

    I am aware that this "trick" does not work on older versions of code. It works well with the code we are running in the lab though, so you will be able to use this.

     

     

  • Cheers Pablo, excellent response as usual!

    When I use the extended ping and set the physical interface it works no problem. When I set the source interface to the correct RPF interface in a single line extended ping I get a response but still see the error. It fails when setting the loopback0 interface explicitly.

    Any idea why it was choosing loop7777 in VRF L2VPN?

    R7#ping
    Protocol [ip]:
    Target IP address: 239.0.0.5
    Repeat count [1]: 20
    Datagram size [100]:
    Timeout in seconds [2]:
    Extended commands [n]: y
    Interface [All]: FastEthernet0/0.207
    Time to live [255]:
    Source address or interface: 172.16.207.7
    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 20, 100-byte ICMP Echos to 239.0.0.5, timeout is 2 seconds:
    Packet sent with a source address of 172.16.207.7

    Reply to request 0 from 172.16.0.5, 24 ms
    Reply to request 1 from 172.16.0.5, 1 ms
    Reply to request 2 from 172.16.0.5, 1 ms
    R7#ping 239.0.0.5 so f0/0.207

    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 239.0.0.5, timeout is 2 seconds:
    Packet sent with a source address of 172.16.207.7

    IP(0): s=172.16.207.7 (Loopback0) d=239.0.0.5 id=34, ttl=254, prot=1, len=100(100), not RPF interface
    Reply to request 0 from 172.16.0.5, 1 ms

  • I don't know why it was choosing the interface in the VRF L2VPN. However, I do know why it does not work when setting the interface in the "one line extended ping".

    When you do something like this:

    ping 237.0.0.9 source f0/0.207  

    This does not actually force the multicast packet to ONLY go out of the f0/0.207 interface. The packet still goes out of all of the other interfaces on the router when you do this (clear the mroute tables everywhere and try it...then go to your RP and look at the mroute). 

    The only way to ensure that your mcast stream only goes out one interface is by forcing the packet OUT of a specific interface with the extended ping. This line is what sets it:

    Extended commands : y

    Interface [All]: FastEthernet0/0.207

     

    Notice how by default it says "all". 

     

  • Cool, I never really thought about what the source command was doing.  I guess I just assumed setting the source address also sent the packet out that interface. Before I started on this journey I had never even seen the interface (all) option under the extended ping. Good to know.

Sign In or Register to comment.