Saturday, February 15, 2014

[mini] PIM Dense State Refresh

Been brushing up on multicast recently.  It was one of the first topics I ever deep-dived and some of the material is rusty now... two and a half years later.

Came across PIM-DM State Refresh.  This is an interesting attempt to make dense mode PIM more scalable. If you ask a CCNP student what the common detriment with using dense mode is, he'd probably tell you "It floods all its groups to every PIM device every three minutes".  That is true, but that's an attempt to solve a problem, not the problem itself.

The real problem is that dense mode has no way of letting potential receivers know what groups are available, or where to find them. It's easy to lose site of this when labbing: you control every device and know exactly where all the transmitters and receivers are, and know what groups are on the network.  The 3-minute flooding is only present because that's how dense mode tells the network what groups are available and where to find them.

State Refresh is not a new technology - it was proposed in the late 90's - but I'd never heard of it before today.  With it enabled, you still have the initial densing of the actual multicast stream, but after the initial prune, instead of just firing the stream off every 3 minutes, it instead sends a state refresh every X number of seconds, where X is defined by the command that enables it:

interface FastEthernet1/0
 ip pim dense-mode
 ip pim state-refresh origination-interval 10

In this sample, we would send state refresh messages every 10 seconds.

In this fashion, all PIM routers in the network are still aware of the stream, but they don't get the annoying densing out of the traffic followed by having to prune it constantly.

Also note, this process only works if the transmitter is still sending traffic. It does not do this "keepalive" signaling for multicast streams that are no longer in use.

Where you place the state-refresh command is important.  It should always go on the PIM interface closest to the transmitting host. If you put it anywhere else, it does not work.  You do not need to enable it on other routers on the host.  In my lab, I had three interfaces, one pointing at a host endlessly pinging 239.0.0.100, and the other two pointing towards PIM routers. I only have it enabled on the interface pointing towards the host.

All PIM Dense routers/interfaces will automatically relay state-refresh messages.  This command only needs to be enabled on interface facing transmitting hosts.

If you don't want a PIM router to relay these messages, use this global command:
ip pim state-refresh disable

Cheers,

Jeff

No comments:

Post a Comment