Pings to Multicast Address

Hi there,

 

Maybe I am using the wrong verification process but I typically like to use extended pings to a given multicast address to verify my multicast tasks.  It will depend on the task but usually throwing an igmp join command on one end and sending pings from another is usually the easiest way to verify.

 

The part I'm having a difficulty time with is that I never seem to get 100% consistent results with this approach and other times it doesn't seem to work at all, and I don't understand why.

http://blog.ine.com/2010/09/17/troubleshooting-multicast-routing/

 

I've read through this blog entry which is very informative and he even provides specifics on sending pings to a multicast address, however I'm still not seeing consistent results.  I've not been able to find any other resource out there that discusses this in detail.

 

I've learned that you must do an extended ping or else your multicast ping traffic goes out every interface.  And also I seem to get better results if I do the extended ping from the DR on the given interface I'm sending the pings from.  Since the DR is responsible for the registration process to the RP, if you source pings from a different router on that subnet, the DR ends up sending them to the RP encapsulated as unicast anyway.  And the unicast responses come back to the DR and then DR sends them onto the local subnet so the originating router should be able to respond to that.  So sourcing them from the DR takes that step out of the picture.

 

IDK, maybe I should not worry about this as much as I am but usually if I dig hard enough there is a reason why something is doing what it does, but for sending pings to a multicast address it is not adding up for me.  Any feedback is approciated, thanks.

 

Ben,

Comments

  • Ben,

    In a test environment, PING is the easiest way to verify reachability - be it unicast or multicast destination address. In fact, most times, chances are there wont be a multicast source to test the network with. While PING to an IGMP Join enabled interface is a good option to test multicast, remember that Ping responses are unicast ICMP Echoes. 

    I usually send multiple packets and check Multicast route table end-to-end to verify the network states. "debug ip pim" is another thing I enable on the routers.

    Regards,

    AB.

  • I do realize there is not going to be a source to test with and that responses are unicast.  But when I also check multicast routing table entries and flags as well as rpf paths it appears everything should be working but I get partial or no response from my ping testing.

    I am using gns3 at 12.4T but I don't think that plays a role. I'm currently using a mix environment of L2 gns3 switches and external connections to a 3560 switch just for my own mock topology just for the sake of multicast.

    Through packet captures I'm able to verify multicast is treated as unknown unicast and flooded on the gns3 L2 switches and I also turned off igmp snooping on the 3560 to make sure that's not messing with my labbing.

    Sent from my iPhone (please excuse abbreviations or spelling and grammar errors)

    On Aug 12, 2013, at 10:48 PM, AmitB <[email protected]> wrote:

    Ben,

    In a test environment, PING is the easiest way to verify reachability - be it unicast or multicast destination address. In fact, most times, chances are there wont be a multicast source to test the network with. While PING to an IGMP Join enabled interface is a good option to test multicast, remember that Ping responses are unicast ICMP Echoes. 

    I usually send multiple packets and check Multicast route table end-to-end to verify the network states. "debug ip pim" is another thing I enable on the routers.

    Regards,

    AB.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • JoeMJoeM ✭✭✭

    Hey Ben,

    One of the tricks to use, is disabled mroute-cache on the end routers (I think).   I believe this is dynamips specific, but I am not sure.

    Yesterday I was working on a task, and every time I would clear ip mroute *I could consistently get one live reply (but then the trailing periods).    After I did  no ip mroute-cache on the receiving interface,  all of the pings started working.

    I was a bit desperate and trying anything to get the verification to work consistently.  So, I would have to do more testing in regards to this remedy.   Maybe someone else can follow up on the rhyme-and-reason of how disabling the mroute-cache works.

  • Hi, 

    First of all you can check for the multicast join groups using "show ip igmp groups" and check for "show ip pim interface and show ip pim neighbors". If everything is fine and RP is configured properly in case of static RP(show ip pim rp mapping), you can send some ping traffic to verify the reachability and then mtrace. Make sure that you have full network layer unicast reachability from source to destination with successful uRPF check. 

    Since you are using GNS3 with 12.4T version IOS, it could cause an issue in case of hight CPU utilization. I have also faced some weird behaviour while using GNS3, but later i tried same config on my real lab, it was working fine!

    Good luck!

  • Hi,

    Dynamips has issues with multicast. There is an issue with GT96k FastEthernet controller. If you stay away from that you should have better results. Here is a thread about it:

    http://ieoc.com/forums/p/3488/16696.aspx

    Sometimes disabling CEF helps but I recommend real gear for the multicast labs if possible. Otherwise try to stay away from GT96k.

  • Wow guys that's 3 in a row pointing at gns3 as the issue so I'm thinking that is probably what I need to focus on.

    I will try your suggestions and be sure to report back in a few days because this is driving me insane putting so much effort into learning multicast well only to be so discourage by failing pings.

    I even watched the 13hrs of deep dive multicast which was amazing btw, so I better know what I'm doing by now lol.

    Sent from my iPhone (please excuse abbreviations or spelling and grammar errors)

    On Aug 13, 2013, at 12:07 AM, daniel.dib <[email protected]> wrote:

    Hi,

    Dynamips has issues with multicast. There is an issue with GT96k FastEthernet controller. If you stay away from that you should have better results. Here is a thread about it:

    http://ieoc.com/forums/p/3488/16696.aspx

    Sometimes disabling CEF helps but I recommend real gear for the multicast labs if possible. Otherwise try to stay away from GT96k.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • Wow guys that's 3 in a row pointing at gns3 as the issue so I'm thinking that is probably what I need to focus on

    Not to bag GNS3 too much, but when you come across things like this, it's often better to note it, then try it later with real equipment. Try not to get bogged down by debugging GNS3 stuff, when you really want to be learning multicast, or NTP, or whatever.

  • I agree but I'm at a point were I need the satisfaction of validation that I'm doing things right to build confidence. It'll put like a 3hr limit on testing this and see how far I get.

    Sent from my iPhone (please excuse abbreviations or spelling and grammar errors)

    On Aug 13, 2013, at 1:34 AM, northlandboy <[email protected]> wrote:

    imageBen1978:
    Wow guys that's 3 in a row pointing at gns3 as the issue so I'm thinking that is probably what I need to focus on

    Not to bag GNS3 too much, but when you come across things like this, it's often better to note it, then try it later with real equipment. Try not to get bogged down by debugging GNS3 stuff, when you really want to be learning multicast, or NTP, or whatever.




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
  • I'll put like a 3hr limit on testing this and see how far I get

    That sounds like a practical approach. Sure, you want to dig deep, and debug stuff, to check your configs, but you need to balance it against using your study time effectively.

  • Problem solved!  The GT96100-FE module does not support multicast completely.  I changed my GNS3 topology to using all NM-1FE-TX modules for all ethernet interfaces and pinging to multicast addresses works like butter.

     

    Thank you very much guys, I feel more confident about continuing to tackle multicast now that I feel I can rely on pings to validate operations.

     

    I've attached some screen shots just to show what I was doing in case anyone was curious, sorry if the pics are way too big, I don't know how to scale them down.

     

    So the question I have now is are there any other features that have limitations due to the GT96100-FE module?  I rely on GNS3 pretty heavily for my studies and I think I will just get accustomed to always using the NM-1FE-TX module for all ethernet connections just so I don't have to worry about limitations.  I know using real gear will always be better but I'm just not setup for that right now and want to stay focused on my studies and then after CCIE consider working up a flexible real lab with remote power and stuff to evaluate features.

     

    Thanks again for the feedback folks!

     

    Ben,

     

     

    image

    image

Sign In or Register to comment.