Protocol Support for Hitless Failover
Protocol Support for Hitless Failover summarizes the protocol support for hitless failover. Unless otherwise noted, the behavior is the same for all switches.
If a protocol indicates support for hitless failover, additional information is also available in that particular chapter. For example, for information about network login support of hitless failover, see Network Login.
|Bootstrap Protocol Relay||All bootprelay statistics (including option 82 statistics) are available on the backup node also||Yes|
If you configure BGP graceful restart, by default the route manager does not delete BGP routes until 120 seconds after failover occurs. There is no traffic interruption. However, after BGP comes up after restart, BGP re-establishes sessions with its neighbors and relearns routes from all of them. This causes an increase in control traffic onto the network.
If you do not configure graceful restart, the route manager deletes all BGP routes 1 second after the failover occurs, which results in a traffic interruption in addition to the increased control traffic.
|Connectivity Fault Management (IEEE 802.1ag)||
An ExtremeXOS process running on the master node should continuously send the MEP state changes to the backup. Replicating the protocol packets from an master node to a backup may be a huge overhead if CCMs are to be initiated/received in the CPU and if the CCM interval is in the order of milliseconds.
RMEP timeout does not occur on a remote node during the hitless failover.
RMEP expiry time on the new master node in case of double failures, when the RMEP expiry timer is already in progress, is as follows:
RMEP Expiry Time = elapsed expiry time on the master node + 3.5 * ccmIntervaltime + master node convergence time.
|Dynamic Host Configuration Protocol client||The IP addresses learned on all DHCP enabled VLANs are retained on the backup node after failover.||Yes|
|Dynamic Host Configuration Protocol server||A DHCP server continues to maintain the IP addresses assigned to various clients and the lease times even after failover. When a failover happens, all the clients work as earlier.||Yes|
The primary node replicates all EAPS BPDUs to the backup, which allows the backup to be aware of the state of the EAPS domain. Since both primary and backup nodes receive EAPS BPDUs, each node maintains equivalent EAPS states.
By knowing the state of the EAPS domain, the EAPS process running on the backup node can quickly recover after a primary node failover. Although both primary and backup nodes receive EAPS BPDUs, only the primary transmits EAPS BPDUs to neighboring switches and actively participates in EAPS.
|EDP||EDP does not checkpoint protocol data units (PDUs) or states, so the backup node does not have the neighbor‘s information. If the backup node becomes the primary node, and starts receiving PDUs, the new primary learns about its neighbors.||No|
|Extreme Loop Recovery Protocol (ELRP)||
If you use ELRP as a standalone tool, hitless failover support is not needed since you initiate the loop detection. If you use ELRP in conjunction with ESRP, ELRP does not interfere with the hitless failover support provided by ESRP.
Although there is no hitless failover support in ELRP itself, ELRP does not affect the network behavior if a failover occurs.
|Extreme Standby Router Protocol (ESRP)||
If failover occurs on the ESRP MASTER switch, it sends a hello packet with the HOLD bit set. On receiving this packet, the ESRP SLAVE switch freezes all further state transitions. The MASTER switch keeps sending hellos with the HOLD bit set on every hello interval. When the MASTER is done with its failover, it sends another hello with the HOLD bit reset. The SLAVE switch resumes normal processing. (If no packet is received with the HOLD bit reset, the SLAVE timeouts after a certain time interval and resumes normal processing.)
Failover on the ESRP SLAVE switch is of no importance because it is the SLAVE switch.
|Intermediate System-Intermediate System (IS-IS)||
If you configure IS-IS graceful restart, there is no traffic interruption. However, after IS-IS comes up after restart, IS-IS re-establishes sessions with its neighbors and relearns Link State Packets (LSPs) from all of the neighbors. This causes an increase in network control traffic.
If you do not configure graceful restart, the route manager deletes all IS-IS routes one second after the failover occurs, which results in a traffic interruption and increased control traffic. IS-IS for IPv6 does not support hitless restart .
IS-IS (IPv4) Yes
IS-IS (IPv6) No
|Link Aggregation Control Protocol (LACP)|