Kevin Dorrell, CCIE #20765

20 Apr 2008

NMC 16.14 Multicast

Filed under: IP Multicast — dorreke @ 12:45

Multicast receivers

A 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 interface facing the multicast source, but does not need to forward to anywhere.  the questions are: do you need to enable multicast-routing, and do you need to put PIM on the interface.

At the time, I was doing NMC DOiT Lab 14, which was a sparse-mode scenario.  At the time, I came to the conclusion:

If a router is to respond to a multicast ping, and it has ip igmp join-group on the interface facing the source, then ip multicast-routing must be enabled.  PIM is not needed unless the ip igmp join-group is on an interface not facing the source.  There is an alternative to enabling multicast routing: no ip route-cache cef interface facing the source.

Now lab 16 presents an opportunity for the same sort of experiment in dense-mode.  We have two devices that are acting purely as multicast receivers: FRS and CAT2.  What do we need to configure on those to get a response to the ping from R4 and CAT1?

This time, to get a response out of CAT1, it needs all three parts: multicast routing, the pim dense-mode, and the join-group:

ip multicast-routing
interface Vlan10
 ip address
 ip pim dense-mode
 ip igmp join-group

I am puzzled about these differences.  However, it could be simple that an SVI on a Catalyst running 12.1 behaves differently from a FastEthernet on a router running 12.4.

Dense-mode with hub-and-spoke

There is one other thing that worries me about this scenario.  We have a hub-and-spoke topology in dense-mode, with R1 acting as hub, and R2 and R3 acting as spokes.  Normally, this shouts out to me “TUNNEL”.  But in this case, we get away with it because both spokes need the multicast group.  I bet if I removed the join from R3 loopbaack, and PIM from the R3-R5 link, then R3 would prune towards R1, and R2 would stop receiving.  In fact, yes, that is exactly what happens:

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to, timeout is 2 seconds:
Reply to request 0 from, 481 ms
Reply to request 0 from, 489 ms

A question for the proctor: Do you require this scenario to work if R3 no longer needs the multicast stream?



1 Comment »

  1. […] 16.14 Multicast – Receive-only devices+ dense-mode prunes […]

    Pingback by NMC DOiT Lab 16 « Kevin Dorrell’s CCIE Study Weblog — 20 Apr 2008 @ 15:48

RSS feed for comments on this post. TrackBack URI

Leave a Reply

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

You are commenting using your 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

%d bloggers like this: