Application Support for Stateful SRP Switchover
Applications are either supported or unsupported by stateful SRP switchover.
- Supported—You can configure supported applications
without having any adverse impact to stateful SRP switchover. When
a switchover occurs, supported applications can react to switchovers
in one of two different ways:
- Gracefully recover using mirrored static and dynamic information (for example, IP, PPP, and PPPoE)
- Recover using static configuration only; that is, no runtime state is restored after a switchover. Dynamic configuration and state information are lost. (For example, CLI sessions are restarted, telnet sessions are dropped, multicast routes must be rebuilt, and so on.)
- Unsupported—We recommend that you not configure unsupported applications on a chassis running in high availability mode. Although configured unsupported applications suspend high availability or prevent high availability from becoming active, they do not cause any problems with the function of the router.
Table 8 indicates which applications support or do not support stateful SRP switchover.
Application Support
Table 8: Application Support for Stateful SRP Switchover
Application | Supported | Unsupported | Notes |
|---|---|---|---|
| Physical Layer Protocols | |||
DS1 | ✓ | – | – |
DS3 | ✓ | – | – |
HDLC | ✓ | – | – |
SONET/SDH | ✓ | – | – |
SONET/SDH VT | ✓ | – | – |
| Link-Layer Protocols | |||
ATM | ✓ | – | Static and dynamic interfaces, with the exception of ATM subscribers, are supported. In this case, ATM subscribers refers to a technology on the E Series router where the ATM layer does authentication (that is, not PPP or IP subscriber manager). |
ATM 1483 bulk configuration of dynamic interfaces | ✓ | – | – |
Bridged Ethernet | ✓ | – | – |
Cisco HDLC | ✓ | – | – |
Ethernet (with and without VLANs) | ✓ | – | – |
Frame Relay | ✓ | – | – |
PPP | ✓ | – | – |
PPPoE | ✓ | – | – |
Transparent bridging | ✓ | – | – |
| Unicast Routing | |||
Access Routes | ✓ | – | – |
BFD | ✓ | – | During a stateful SRP switchover, the BFD transmit interval is set to 1000 ms with a detection multiplier of 3. These values result in a liveness detection interval of 3000 ms. This longer interval helps prevent a BFD timeout during the switchover. BFD negotiates the interval with the remote peer before applying the temporary change. The BFD timers revert back to the configured values after 15 minutes (the maximum duration for graceful restart completion). |
BGP | ✓ | – | Supported for IPv4 only when the graceful restart extension is enabled. Does not support graceful restart for IPv6 address families. |
FTP | ✓ | – | Static recovery support only. |
IP | ✓ | – | – |
IPv6 | ✓ | – | – |
IPv6 neighbor discovery | ✓ | – | IPv6 neighbor discovery characteristics are replayed during switchover. Line modules do not flush neighbor discovery information during the switchover. |
IPSec Transport | – | ✓ | – |
IPSec Tunnels | ✓ | – | Completed IKE phase 1 and phase 2 negotiations supported only. |
IS-IS | ✓ | – | Supported only when the graceful restart extension is enabled. |
IS-ISv6 | ✓ | – | Supported only when the graceful restart extension is enabled. |
OSPFv2 | – | Supported only when the graceful restart extension is enabled. | |
OSPFv3 | ✓ | – | Supported only when the graceful restart extension is enabled. |
RIP | ✓ | – | Static recovery support only. |
Static Routes (IP and IPv6) | ✓ | – | After all high-priority interfaces have been replayed from NVS and mirrored storage, static routes are replayed from NVS, followed by replay of low-priority interfaces from NVS and mirrored storage. This behavior enables static routes that are dependent on high-priority interfaces to be resolved quickly and installed in the IP routing table. |
Telnet | ✓ | – | Static recovery support only. |
| IPv4 Multicast Routing | |||
Multicast Routing | ✓ | – | Stateful SRP switchover. During switchover, the system mirrors the multicast queue so that IP can use the same queue without needing to recreate a different connection. The multicast queues are also preserved during the switchover and graceful restart period to ensure that multicast data continues to be forwarded using the previously learned multicast forwarding state. |
DVMRP | ✓ | – | Static recovery support only. DVMRP gives the restart complete indication to the IP routing table after getting a peer update (60-second timeout). |
IGMP | ✓ | – | IC IGMP deletes its interface and membership state on SRP failover (controller down). As part of SRP warm start, IGMP interfaces are reconfigured from NVS and dynamic IGMP interfaces are reconfigured from mirrored storage. IGMP hosts are queried as IP interfaces come back up, the join state is re-established, and SC IGMP state is created. After the maximum query response time (across all interfaces) expires to allow hosts to re-establish join state, IGMP notifies MGTM that graceful restart is complete. |
MGTM | ✓ | – | On SRP failover, old mroutes are retained on the line module to preserve multicast forwarding; cache-misses to the SRP are disabled. When MGTM warm starts on the SRP, it reads the NVS configuration and enables multicast routing. When IGMP, DVMRP, and PIM have completed graceful restart and the IP route table multicast-view has completed graceful restart, old mroutes are deleted from the line module and cache-misses to the SRP are enabled. This triggers re-creation of mroutes and establishes the current multicast forwarding state. Although cache-misses to the SRP module are disabled, forwarding is preserved for old multicast joins to downstream routers and hosts. However, forwarding for new multicast joins requested by downstream routers and hosts after SRP module switchover is not provided until cache-misses are re-enabled. |
PIM | ✓ | – | Static recovery support only. For warm start, PIM interfaces are reconfigured from NVS. A Hello message with a new Generation ID is issued as IP interfaces come up. A neighbor that receives this Hello determines that the upstream neighbor has lost state and needs to be refreshed. A VR-global configurable graceful restart timer is required for PIM to time out the re-establishment of the join state for sparse-mode interfaces. After this timer expires, PIM notifies MGTM that graceful restart is complete. |
| IPv6 Multicast Routing | |||
Multicast Routing | ✓ | – | Stateful SRP switchover. During switchover, the system mirrors the multicast queue so that IP can use the same queue without needing to recreate a different connection. The multicast queues are also preserved during the switchover and graceful restart period to ensure that multicast data continues to be forwarded using the previously learned multicast forwarding state. |
MGTM | ✓ | – | On SRP failover, old mroutes are retained on the line module to preserve multicast forwarding; cache-misses to the SRP are disabled. When MGTM warm starts on the SRP, it reads the NVS configuration and enables multicast routing. When MLD and PIM have completed graceful restart and the IPv6 route table multicast-view has completed graceful restart, old mroutes are deleted from the line module and cache-misses to the SRP are enabled. This triggers re-creation of mroutes and establishes the current multicast forwarding state. Although cache-misses to the SRP module are disabled, forwarding is preserved for old multicast joins to downstream routers and hosts. However, forwarding for new multicast joins requested by downstream routers and hosts after SRP module switchover is not provided until cache-misses are re-enabled. |
MLD | ✓ | – | IC MLD deletes its interface and membership state on SRP failover (controller down). As part of SRP warm start, MLD interfaces are reconfigured from NVS and dynamic IMLD interfaces are reconfigured from mirrored storage. MLD hosts are queried as IPv6 interfaces come back, the join state is re-established, and SC MLD state is created. After the maximum query response time (across all interfaces) expires to allow hosts to re-establish join state, MLD notifies MGTMv6 that graceful restart is complete. |
PIM | ✓ | – | Static recovery support only. For warm start, PIM interfaces are reconfigured from NVS and a Hello message with a new Generation ID is issued as IPv6 interfaces come up. A neighbor that receives this Hello determines that the upstream neighbor has lost state and needs to be refreshed. A VR-global configurable graceful restart timer is required for PIM to time out the re-establishment of the join state for sparse-mode interfaces. After this timer expires, PIM notifies MGTM that graceful restart is complete. |
| Multiprotocol Label Switching | |||
MPLS | ✓ | – | MPLS is HA-unsafe during a graceful restart. It is HA-unsafe until all the configured MPLS signaling protocols have completed their graceful restart procedures and any stale forwarding elements have been flushed from the line modules. If you force an SRP switchover while MPLS is HA-unsafe, the SRP module switches but the SRP module and the line modules undergo a cold restart. If the primary SRP module resets while MPLS is HA-unsafe, the router undergoes a cold restart. MPLS over IPv6 supports HA. This functionality enables BGP to support graceful restart for IPv6 labeled addresses. |
BGP signaling | ✓ | – | — |
LDP signaling | ✓ | – | To provide uninterrupted service during an SRP switchover in a scaled configuration, such as one with 32,000 Martini circuits, set the LDP graceful restart reconnect time to the maximum 300 seconds and set the LDP graceful restart recovery timer to the maximum 600 seconds. This requirement is true for all SRP switchovers, including those in the context of a unified in-service software upgrade. LDP signaling does not support HA for IPv6. |
RSVP signaling | ✓ | – | — |
Local cross-connects between layer 2 interfaces using MPLS | ✓ | – | – |
| Policies and QoS | |||
Policies | ✓ | – | – |
QoS | ✓ | – | Static recovery support only. |
| Remote Access | |||
AAA | ✓ | – | – |
DHCP External Server and Packet Trigger | ✓ | – | Following a switchover, the DHCP lease (that is, time remaining) is recalculated based on when the lease started. When the release timer for a client expires, the client is deleted and the access route is removed, along with the dynamic subscriber interface if it was created. If the client requests a new lease, DHCP external server resynchronizes with the new lease time. |
DHCP Packet Capture | ✓ | – | – |
DHCP Proxy Client | ✓ | – | When the standby SRP module takes over as the primary after a stateful SRP switchover operation, it continues to handle DHCP lease renewal requests from existing clients based on their states and processes state transitions without any disruption. For more information, see "Preservation of DHCP Proxy Client Bindings During Stateful SRP Switchover" |
DHCP Relay Proxy | – | – | |
DHCP Relay Server | ✓ | – | Before HA support, clients identified by the DHCP relay server were maintained on a switchover (their state was stored to NVS); DHCP relay server always had some level of HA support. Currently, following a switchover, the DHCP lease (that is, time remaining) is reset. When the release timer for a client expires, the client requests a new lease. The E Series router DHCP relay server then synchronizes with the new state. |
DHCPv4 Local Server | ✓ | – | – |
DHCPv6 Local Server | ✓ | – | DHCPv6 now supports stateful SRP switchover (high availability). After SRP warm switchover, the router restores the client bindings from the mirrored DHCPv6 information as it does for other applications that support stateful SRP switchover. |
L2TP | ✓ | – | — |
L2TP Dialout | – | ✓ | – |
IPv4 Local Address Pools | ✓ | – | The internal local address server state supports only static recovery. However, the AAA application reallocates active addresses on a switchover. The resulting effect is the IPv4 local address server having full HA support. |
IPv6 Local Address Pools | ✓ | – | When the IPv6 local pools are configured, you can perform an HA switchover without cold booting the router because the configuration is now HA safe. The prefix assigned to the subscriber, before and after the warm restart, remains the same. The In Use prefix count also remains the same before and after the warm restart. |
RADIUS Client | ✓ | – | Similar to local address server, AAA recovers disrupted RADIUS communication on a switchover. The resulting effect is the RADIUS client having full HA support. |
RADIUS Dynamic-Request Server | ✓ | – | Static recovery support only. |
RADIUS Initiated Disconnect | ✓ | – | |
RADIUS Relay Server | ✓ | – | – |
RADIUS Route-Download Server | ✓ | – | – |
Service Manager | ✓ | – | – |
SRC Client | ✓ | – | – |
TACACS+ | ✓ | – | Static recovery support only. |
| Miscellaneous | |||
DNS | ✓ | – | — |
DNSv6 | – | ✓ | If DNSv6 is configured, no warning or error is displayed during a warm start. DNSv6 is subsequently configured from NVS as it is after a cold reboot. |
J-Flow (IP flow statistics) | ✓ | – | – |
Line Module Redundancy | ✓ | – | – |
Network Address Translation | ✓ | – | – |
NTP | ✓ | – | – |
Resource Threshold Monitor | ✓ | – | – |
Response Time Reporter | ✓ | – | – |
Route Policy | ✓ | – | Static recovery support only. |
Subscriber Interfaces | ✓ | – | IPv4 only. Subscriber interfaces are not applicable to IPv6. |
Tunnels (GRE and DVMRP) | ✓ | – | – |
VRRP | ✓ | – | Static recovery support only. |
![]() | Caution: When IP tunnels are configured on an HA-enabled router and the Service Module (SM) carrying these tunnels is reloaded, HA transitions to the pending state. HA remains in the pending state for 5 minutes after the successful reloading of the SM. This amount of time allows for IP tunnel relocation and for the tunnels to become operational again on the SM. If an SRP switchover occurs while HA is in the pending state, the router performs a cold restart. |
Hide Navigation Pane
Show Navigation Pane
SHA1
