Multicast VPN - ping testing

Hi

some weeks ago someone in SP forum posted a extensive explanation how to ping test in multicast VPN -  and why it may fail without using extended ping

Not able to find this post again - could anyone help?

 

Jon

Comments

  • I am not usre if you are looking for this - http://ieoc.com/forums/p/1470/4887.aspx#4887

    This is from RS Archive, not SP, but general rules would be the same

    <QUOTE>

    Hi folks,

    I believe the reason why the multicast ping traffic ends up failing is due to the way a Cisco router behaves when sending ping traffic to a multicast address when not using the extended ping method to send the ping traffic. In unicast it’s pretty simple, you have an outbound interface leading to your destination address, and the ip address of this outbound interface is used for the source of the ping traffic. When you send ping traffic to a multicast address and do not use the extended ping method, the router seems to get confused and free-willed on two things, 1) what to use as the source address, 2) which interface to send these multicast ping packets out.

    To see this behavior, we can use the following test:

    Rack1R5#ping 224.4.4.4 source 192.10.1.5 repeat 100

    While this seems like the correct approach for verification, we will find out that the router seems to be sloppy and have a mind of its own on what to use as the source ip address of this traffic, as well as which interface to send the traffic out of. Even though we specifically are telling the router to use 192.10.1.5 as the source of the ping traffic it does not do so the entire time. I think it may use that address for the first two or three packets (which is why the first two or three pings succeed) but I did a lot of testing and there doesn’t seem to be a rhyme or reason on what address it ends up using. The outbound interface is the other factor, this is actually what causes the ping traffic to fail in the above test (bad RPF check on R4). We assume the ping traffic will be sent out the S0/0 interface since that’s the interface leading to the RP, as well as the only interface on R5 configured for pim. However when testing, it is discovered that R5 will send the majority of this traffic out the E0/0 interface only for R4 to receive it on its E0/1 interface which fails the RPF check.

    To verify all of this I had configured extended ACLs on R4’s E0/1 and S0/0 interfaces along with R1’s S0/0 interface with permit statements for traffic destined to host 224.4.4.4 (also a permit ip any any after that to maintain all other traffic). This allowed me to determine exactly which direction R5 sends the ping traffic. In addition I performed “debug ip mpacket detail” on R1 to see the details of the ping traffic from R5. If you do this, don’t forget to disable fast switching for multicast packets by configuring “no ip mroute-cache” on R1’s S0/0 interface or else you will not see any of the multicast ping traffic from R5. I discovered that when performing the non-extended ping with or without specifying a source address on R5, it would randomly send the ping packets in both directions and seem to use various addresses as the source of it’s traffic.

    So performing the above ping test on R5, I think the logic of what happened is that R5 would send the first couple of ping packets out S0/0, R1 would correctly send them onto R4 and because these arrived on R4’s correct RPF check interface (S0/0) it would reply to them. It didn’t even matter if R5 used its E0/1.52 or S0/0 interface as the source address for these first couple ping packets because the RPF check on R4 for both networks will pass if received on its S0/0 interface. Then for some reason R5 would then send what seemed to be the remaining packets out its E0/0 interface with some random source address. R4 would receive these packets on it’s E0/1 interface and the RPF check would fail because pim is not configured on this interface.

    When I perform the extended ping test on R5 to the 224.4.4.4 multicast group address, the correct source address is chosen and packets are sent out the correct interface:

    Rack1R5#ping
    Protocol [ip]:
    Target IP address: 224.4.4.4
    Repeat count [1]: 10
    Datagram size [100]:
    Timeout in seconds [2]: 1
    Extended commands [n]: y
    Interface [All]: serial1/0
    Time to live [255]:
    Source address: ethernet0/1.52
    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 224.4.4.4, timeout is 1 seconds:
    Packet sent with a source address of 192.10.1.5

    Reply to request 0 from 174.1.145.4, 132 ms
    Reply to request 1 from 174.1.145.4, 236 ms
    Reply to request 2 from 174.1.145.4, 172 ms
    Reply to request 3 from 174.1.145.4, 208 ms
    Reply to request 4 from 174.1.145.4, 484 ms
    Reply to request 5 from 174.1.145.4, 92 ms
    Reply to request 6 from 174.1.145.4, 216 ms
    Reply to request 7 from 174.1.145.4, 160 ms
    Reply to request 8 from 174.1.145.4, 112 ms
    Reply to request 9 from 174.1.145.4, 144 ms
    Rack1R5#

    Notice that the default option for the outbound interface is (Interface [All]) but I specify serial1/0 (I’m using Dynamips, that’s why the serial interface is different). Because of that All, I bet the router just willy nilly sends out the multicast ping traffic out every interface. If I did more testing I bet I would see it being send out E0/1.53 and E0/1.52 as well.

    I believe this is why the solution guide shows an extended ping being performed on R5, because this is multicast traffic and the router would not operate the way we want if we didn’t use the extended ping test.

    I believe this has been the way Cisco routers operate with ping traffic to multicast addresses for a while now. I’ve can recall seeing this behavior as far back as 12.2(15t) and my current setup is Dynamips running 12.4(17). So I guess Cisco doesn’t see this as undesirable behavior, maybe they want the multicast traffic to be sent everywhere if not using an extended ping.

    Another thing to comment on is that throughout my studies with multicast I have usually seen the “ip pim nbma-mode” feature only being used with sparse-mode and not with sparse-dense-mode. However, because we use it here and everything seems to work after we work out the bugs I’m going to assume that nbma-mode can be used with either sparse-mode or sparse-dense-mode.

    Ben, 

    </QUOTE>

    Cheers,

    Seba

  •  

    Thanks

    Yes - this was the correct document.

     

    Jon

     

  • Hello all

    I have not seen this before yesterday and was thinking of this ever since...

    could there be an "icmp redirect" being sent from R1 to R5 after a few multicast packets are sent, and that "icmp redirect" is only ignored by R5 if using extended ping command?

    if anyone knows more on this - please comment - this seems interesting to me and I wish to understand this further...

    Shai


    I am not usre if you are looking for this - http://ieoc.com/forums/p/1470/4887.aspx#4887

    This is from RS Archive, not SP, but general rules would be the same

    <QUOTE>

    Hi folks,

    I believe the reason why the multicast ping traffic ends up failing is due to the way a Cisco router behaves when sending ping traffic to a multicast address when not using the extended ping method to send the ping traffic. In unicast it’s pretty simple, you have an outbound interface leading to your destination address, and the ip address of this outbound interface is used for the source of the ping traffic. When you send ping traffic to a multicast address and do not use the extended ping method, the router seems to get confused and free-willed on two things, 1) what to use as the source address, 2) which interface to send these multicast ping packets out.

    To see this behavior, we can use the following test:

    Rack1R5#ping 224.4.4.4 source 192.10.1.5 repeat 100

    While this seems like the correct approach for verification, we will find out that the router seems to be sloppy and have a mind of its own on what to use as the source ip address of this traffic, as well as which interface to send the traffic out of. Even though we specifically are telling the router to use 192.10.1.5 as the source of the ping traffic it does not do so the entire time. I think it may use that address for the first two or three packets (which is why the first two or three pings succeed) but I did a lot of testing and there doesn’t seem to be a rhyme or reason on what address it ends up using. The outbound interface is the other factor, this is actually what causes the ping traffic to fail in the above test (bad RPF check on R4). We assume the ping traffic will be sent out the S0/0 interface since that’s the interface leading to the RP, as well as the only interface on R5 configured for pim. However when testing, it is discovered that R5 will send the majority of this traffic out the E0/0 interface only for R4 to receive it on its E0/1 interface which fails the RPF check.

    To verify all of this I had configured extended ACLs on R4’s E0/1 and S0/0 interfaces along with R1’s S0/0 interface with permit statements for traffic destined to host 224.4.4.4 (also a permit ip any any after that to maintain all other traffic). This allowed me to determine exactly which direction R5 sends the ping traffic. In addition I performed “debug ip mpacket detail” on R1 to see the details of the ping traffic from R5. If you do this, don’t forget to disable fast switching for multicast packets by configuring “no ip mroute-cache” on R1’s S0/0 interface or else you will not see any of the multicast ping traffic from R5. I discovered that when performing the non-extended ping with or without specifying a source address on R5, it would randomly send the ping packets in both directions and seem to use various addresses as the source of it’s traffic.

    So performing the above ping test on R5, I think the logic of what happened is that R5 would send the first couple of ping packets out S0/0, R1 would correctly send them onto R4 and because these arrived on R4’s correct RPF check interface (S0/0) it would reply to them. It didn’t even matter if R5 used its E0/1.52 or S0/0 interface as the source address for these first couple ping packets because the RPF check on R4 for both networks will pass if received on its S0/0 interface. Then for some reason R5 would then send what seemed to be the remaining packets out its E0/0 interface with some random source address. R4 would receive these packets on it’s E0/1 interface and the RPF check would fail because pim is not configured on this interface.

    When I perform the extended ping test on R5 to the 224.4.4.4 multicast group address, the correct source address is chosen and packets are sent out the correct interface:

    Rack1R5#ping
    Protocol Paradise:
    Target IP address: 224.4.4.4
    Repeat count [1]: 10
    Datagram size [100]:
    Timeout in seconds [2]: 1
    Extended commands : y
    Interface [All]: serial1/0
    Time to live [255]:
    Source address: ethernet0/1.52
    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 :
    Type escape sequence to abort.
    Sending 10, 100-byte ICMP Echos to 224.4.4.4, timeout is 1 seconds:
    Packet sent with a source address of 192.10.1.5

    Reply to request 0 from 174.1.145.4, 132 ms
    Reply to request 1 from 174.1.145.4, 236 ms
    Reply to request 2 from 174.1.145.4, 172 ms
    Reply to request 3 from 174.1.145.4, 208 ms
    Reply to request 4 from 174.1.145.4, 484 ms
    Reply to request 5 from 174.1.145.4, 92 ms
    Reply to request 6 from 174.1.145.4, 216 ms
    Reply to request 7 from 174.1.145.4, 160 ms
    Reply to request 8 from 174.1.145.4, 112 ms
    Reply to request 9 from 174.1.145.4, 144 ms
    Rack1R5#

    Notice that the default option for the outbound interface is (Interface [All]) but I specify serial1/0 (I’m using Dynamips, that’s why the serial interface is different). Because of that All, I bet the router just willy nilly sends out the multicast ping traffic out every interface. If I did more testing I bet I would see it being send out E0/1.53 and E0/1.52 as well.

    I believe this is why the solution guide shows an extended ping being performed on R5, because this is multicast traffic and the router would not operate the way we want if we didn’t use the extended ping test.

    I believe this has been the way Cisco routers operate with ping traffic to multicast addresses for a while now. I’ve can recall seeing this behavior as far back as 12.2(15t) and my current setup is Dynamips running 12.4(17). So I guess Cisco doesn’t see this as undesirable behavior, maybe they want the multicast traffic to be sent everywhere if not using an extended ping.

    Another thing to comment on is that throughout my studies with multicast I have usually seen the “ip pim nbma-mode” feature only being used with sparse-mode and not with sparse-dense-mode. However, because we use it here and everything seems to work after we work out the bugs I’m going to assume that nbma-mode can be used with either sparse-mode or sparse-dense-mode.

    Ben, 

    </QUOTE>

    Cheers,

    Seba


Sign In or Register to comment.