All things related to multicast

[Peter John Hill <>]

Actually I think that PIM DR can change due to changes in the 
DR-Priority. (actually I know it does as I have done what I believe you 
are trying to do).

In order to do a low impact failover of a router for maintenance in an 
hsrp setup (I guess VRRP has similar metrics) you need to move both 
unicast and multicast away from the router for traffic in both directions...

For unicast in from the edge, you can lower the hsrp priority. 
Brainstorming with one of the workstudies at CMU we came up with an idea 
to use the interface tracking to track a loopback interface that was 
configured for just this purpose. It has no ip address. Its only 
function is to change hsrp priority by having the interfaces track this 
loopback... Warning, make sure your priority never ends up less than 1 
or else it will effectively prevent the router from being hsrp active. 
This seems to be taking liberties with the RFC, since this does not need 
to be the way to work...

For unicast from the distribution layer to the edge, increase the ospf 
cost on the uplinks pointing to your core, this will also move multicast 
traffic inbound from the core to your edge.

For multicast out from your edge (sources) you need to lower the pim 
dr-priority on all your interfaces. If you have alot of traffic, you 
want to do this slowly, as it will potentially cause CPU spikes on the 
router that is now becoming the DR (the other router). You need to watch 
the cpu carefully on that router or your effort will be spoiled by your 
other router dropping out of ospf potentially.

Good luck!
Peter John Hill


John Kristoff wrote:

> I have a situation where I have a pair of Cisco routers attached to the
> same edge LAN segment in a redundant configuration.  I'd like to try to
> minimize packet loss when one of the routers is intentionally brought
> down for maintenance activity.  In my case there will more likely be
> high-rate multicast receivers on the edge segment rather than sources,
> but reducing sender loss/latency is probably most important.
>
> I see that my recent IOS code there is a 'ip pim dr-priority <#>' option
> in interface mode only.  In a cursory search it appears that IOS XR has
> a global option so hopefully that is on the horizon for existing trains
> of code.  In either case I was planning on testing this option to see
> what I can expect during planned maintenance activities, but thought I
> would check with folks here to see if this is the right and worthwhile
> path to go down.
>
> Is there a better way to minimize or eliminate multicast forwarding loss
> in a scenario such as this?  It's not clear to me exactly what will
> happen in real-time situations when the DR priority is changed from one
> interface to another.  Any pointers to PIM join/prune state examples
> when a new DR priority is announced by a peer interface.  I presume the
> new DR priority will be announced during the next random interval.
>
> John
>
>