Kevin Dorrell, CCIE #20765

06 Apr 2008

NMC 14.12 Multicast

Filed under: IP Multicast — dorreke @ 10:29

This posting is not very much about NMC 14.12, but a lot about some experiments that grew from it.

Using a router as a multicast receiver:

The standard way of using a router to simulate a multicast receiver is to use the command ip igmp join-group group-addr.  So, you have a router on a VLAN, and you want it to simulate a multicast receiver, but not to forward multicast packets.  Is it enough to put the ip igmp join-group command on the Ethernet interface.  Well … yes and no.  There is a gotcha that I discovered during NMC 14.12.  Here are my notes:

I had a problem getting a response from R6 (a receiver only) using the configuration in the SHOWiT.  I got it going, but only by adding ip multicast-routing on R6.

I am using Ethereal and SPAN or RSPAN to monitor the protocols.  I start by trying experiment with the connection between R3 and CAT2, and seeing how much config I need in R3 for CAT2 to get a response.

  1. Did no ip multicast-routing on R3 but left ip pim sparse-mode in place on R3-F0/0.   I can still see PIM Hellos (30 seconds) and PIM Bootstraps (60 seconds) from R3.  The bootstraps still carry 172.16.101.1 as the bootstrap router.  Also, and IGMP membership report with 0.0.0.0 every 60 seconds.  However, the show ip mroute on R3 is empty.
  2. Removed ip pim sparse-mode from R3-F0/0.  This killed the PIM stone dead, as you might expect.
  3. Added ip igmp join-goup 239.10.10.10 on R3-F0/0.  This generates an IGMP Membership report.  BUT, it does not repeat.  Strange!  Removing it produces an “IGMP Leave Group”.
  4. With no ip multicast-routing on R3 and no ip pim sparse-mode on R3-F0/0, but ip igmp join-group 239.10.10.10 on R3-F0/0, I can see the ping 239.10.10.10 from CAT2, but R3 does not respond.  So how is R6 supposed to work in the scenario?

So, now I put back the multicast routing stuff in R3 and concentrate on R6.

  1. Starting with no multicast config in R6, it is obvious I will see no response form it.  I do not see it in the show ip igmp snooping group on CAT1 (if I use it … the AK has static MAC forwarding for the multicast).  If I ping from CAT2, I see no ping on R6.
  2. In the AK, R6 has no ip multicast-routing, has no ip pim sparse-mode on F0/0, and has ip igmp join-group 239.10.10.10 on F0/0.  This does not work for me.  I can see the IGMP Membership report from R6, and I can see CAT1 adding it to the show ip igmp snoop group table. I can see the ping from CAT2.  But I do not get any response form R6.
  3. If I add ip multicast-routing on R6, then I get a response.  OTOH, there is no need for any PIM on R6-F0/0.

Conclusion: If a router is to respond to a multicast ping, it must ip igmp join-group on the interface facing the source, AND ip multicast-routing must be enabled.  PIM is not needed unless the ip igmp join-group is on an interface not facing the source.

Follow on:  These is another way to solve this problem, and it is the one in the SHOWiT, and which I had overlooked: no ip route-cache cef on R6-F0/0.  The ip multicast-routing is then not necessary.  Why this makes a difference, I have not the faintest idea.  Just quirky behavior … a magic bullet.  They might at least have mentioned it in the AK!

The first few multicast pings

I know that in a sparse mode scenario you should discard the results of the first two or three pings.  But I want to be able to explain them.  Here are the results from this lab:

CAT2#
CAT2#! =================> First ping
CAT2#
CAT2#ping 239.10.10.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds:
Reply to request 0 from 172.16.31.3, 4 ms
Reply to request 0 from 172.16.26.6, 228 ms
Reply to request 0 from 172.16.124.2, 220 ms
Reply to request 0 from 172.16.124.4, 212 ms
CAT2#
CAT2#
CAT2#! =================> Second ping
CAT2#
CAT2#ping 239.10.10.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds:
Reply to request 0 from 172.16.31.3, 4 ms
Reply to request 0 from 172.16.26.6, 80 ms
Reply to request 0 from 172.16.124.4, 76 ms
Reply to request 0 from 172.16.26.6, 68 ms
Reply to request 0 from 172.16.124.2, 60 ms
Reply to request 0 from 172.16.124.4, 52 ms
Reply to request 0 from 172.16.124.2, 44 ms
Reply to request 0 from 172.16.13.1, 32 ms
CAT2#
CAT2#
CAT2#! =================> Third and subsequent pings
CAT2#
CAT2#ping 239.10.10.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.10.10.10, timeout is 2 seconds:
Reply to request 0 from 172.16.31.3, 4 ms
Reply to request 0 from 172.16.26.6, 64 ms
Reply to request 0 from 172.16.124.2, 56 ms
Reply to request 0 from 172.16.124.4, 48 ms
Reply to request 0 from 172.16.13.1, 32 ms
CAT2#
CAT2#

On the first ping, I get no response from R1, althogh it is evidently forwarding the ping to R2 and R4.  I wonder why.

On the second ping, I get duplicate responses from R2, R4, and R6.  This is evidently because of the loop.  R6 has two routes to the source, so it believes the ping from both R2 and R4.  It has not sorted out yet which one it prefers.  So it also forwards each ping to the other.

From the third ping onwards, everything is sorted, and you get one response from each router. 

 

Advertisements

1 Comment »

  1. […] couple of weeks ago, I blogged about the behavior of a router when acting as a multicast receiver.  I am thinking of the sort of situation where the router has an ip igmp join-group on the […]

    Pingback by NMC 16.14 Multicast « Kevin Dorrell’s CCIE Study Weblog — 20 Apr 2008 @ 15:44


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: