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 160.60.26.6 255.255.255.0
 ip pim dense-mode
 ip igmp join-group 229.9.9.9

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:

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

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

 

Advertisements

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:

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

Create a free website or blog at WordPress.com.

%d bloggers like this: