Multicast Gotchas

I have listed a few gotchas that i have come across when configuring IP multicast.....

Multicast on a hub-and-spoke frame-relay network.

A multipoint interface won't, by default, send multicast received from one spoke out to another spoke. This doesn't apply to a 'hub-and-spoke' where the hub is using separate physical or virtual interfaces, just multipoint interfaces. For sparse traffic this can be fixed by applying 'ip pim nbma-mode' to the multipoint interface. For dense traffic, you can use a PIM-enabled tunnel between the spokes to fix this. To use the tunnel an mroute pointing to the tunnel is required, to ensure the RPF check does not fail.

Consider the above topology where R1, R2 and R3 are all enabled with ip pim dense-mode on the serial interfaces. R1 has joined multicast group 226.1.1.1. R2 is able to successfully ping this address but from R3 this fails.

To circumvent this problem the following tunnel configuration can be applied...

R1
interface Tunnel1
ip address 148.1.1.1 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.3.3

ip mroute 0.0.0.0 0.0.0.0 Tunnel1

R3
interface Tunnel1
ip address 148.1.1.2 255.255.255.252
ip pim dense-mode
tunnel source Loopback0
tunnel destination 150.1.1.1

RPF Checks

If multicast traffic is required to take a path which unicast wouldn't, then the recieving router will likely drop the traffic because it fails the RPF check. This is typically fixed by applying an mroute.

Using Auto-RP in Sparse Mode
It was my misconception until recently that Auto RP operates in sparse-dense mode only. In fact in can operate in sparse mode as long as routers are configured with ip pim autorp listener command.