PIM graceful shutdown

The PIM active-active solution makes one of the VSX device act as DR and other device as proxy-DR for each of the downstream VLANs. Both the VSX peers behave the same as far as the protocol is concerned with only the DR forwarding the multicast traffic to downstream routers. The PIM active-active feature is enabled on VSX devices connected to access switches on one side with hosts behind the access switches. The DR election depends on the IP address and a single VSX device doesn't be the DR for all of the downstream VLANs.

When a VSX device which is acting as DR for some of the downstream VLANs starts rebooting, traffic loss would be seen for the multicast streams in those downstream VLANs for few seconds. The VSX software upgrade process involves rebooting each VSX device with new software. The secondary VSX device is upgraded before primary VSX device. If the secondary is acting as DR for some of downstream VLANs then after the VSX software upgrade is triggered multicast traffic loss will be seen twice for the streams present in those VLANs; once during secondary VSX device reboot and then during primary VSX device reboot.

With graceful shutdown traffic loss won't be seen for any of multicast streams. Instead, some duplicates are expected for 1-3 seconds for each stream.

The sequence of events during each VSX device upgrade is outlined below:

  1. The first step is based on device role and is applicable only to the primary device. According to VSX software upgrade process, the device upgrade is triggered in the primary after the secondary upgrade. The secondary should already have all the multicast routes before taking over the DR role from the primary. After the secondary device reboots the primary device waits for few minutes so that the secondary learns the multicast routes and is ready to take over the DR role. The wait time in primary device depends on the number of multicast routes present.

  2. DR roles of all the downstream VLANs are offloaded to its peer. At the end of this step the device which is going to reboot will be a proxy-DR for all the downstream VLANs.

  3. After the interface role change, each multicast flow in the hardware is changed simultaneously in both the DR and proxy-DR based on the new roles they have taken. The new DR converts bridge entries to route entries and the proxy-DR converts route entries to bridge entries in the hardware.

The wait times for the primary upgrade before multicast graceful shutdown process starts are listed below:

Number of MRoutes Timer value
0 0
< 1024 120 seconds
< 2048 150 seconds
< 4096 210 seconds
< 8192 300 seconds
< 16284 360 seconds
> 16384 480 seconds

The recommended configurations for graceful shutdown are as follows:

  1. The multicast graceful shutdown is applicable only to the topologies which are supported for the PIM active-active solution. Other topologies will experience multicast traffic loss during a VSX software upgrade.

  2. The robustness timer for IGMP/MLD protocol should be increased. The robustness timer helps to increase the expiration time of IGMP/MLD joins. This is needed during VSX device reboot so that joins don't expire. The configured value depends on how much time the VSX device reboot takes. If the robustness value is configured at the maximum value of 8, then the expiration time of multicast joins can increase up to 16 minutes with default query-interval. Use the below command to configure robustness timer: 

    switch(config-if)#ip igmp robustness <2-8>

  3. If OSPF v2/v3 is enabled, it is recommended not to configure the VSX device as OSPF v2/v3 DR for any of the interfaces. Use following commands to configure the other routers as DR for an interface: 

    ip ospf priority <0-255>
ipv6 ospfv3 priority <0-255>

  4. If BGP is enabled, it is recommended to increase BGP graceful restart timer for every BGP-enabled interface. The recommended value of BGP graceful restart timer should be the same as the wait time in the primary before the multicast graceful shutdown process starts. Refer to the table in previous section which mentions the wait times. Use following command to reconfigure the BGP graceful restart timer: 

    bgp graceful restart restart-time <1-3600>