High Availability-CPU (HA-CPU)

The High Availability-CPU (HA-CPU) framework supports redundancy at the hardware and application levels. The CP software runs on an Input/Output control (IOC) module in both slots 1 and 2, and the HA-CPU feature activates two CPUs simultaneously in master or standby role. These CPUs exchange topology data so that, if a failure occurs, one of the CPUs can take over the operations of the other. You can configure the CPUs to operate in either HA mode or non-HA mode. In HA mode, the two CPUs synchronize configuration, protocol states, and tables. In non-HA mode, the two CPUs do not synchronize.

The default mode is HA disabled. To activate HA-CPU mode, use the boot config flags ha-cpu command. To deactivate HA-CPU mode, use the no boot config flags ha-cpu command.

If you switch from one mode to the other, the standby CP restarts in the specified HA mode (hot standby) or non-HA mode (warm standby). This does not impact the Input/Output process and there is no traffic loss on the physical slot of the card.

If a failure occurs and the chassis is configured for either HA mode (hot standby) or non-HA mode (warm standby), the CP software restarts and runs as standby. The system generates a trap to indicate the change from hot-standby mode to warm-standby mode.

Note

• The HA-CPU feature provides node-level redundancy. Hot standby mode is not supported with fabric functionality, which provides network-level redundancy.

• If your switch is in hot standby mode (ha-cpu boot flag is set to true), you must disable boot config flag to configure SPBM or vIST on the switch. When the switch is in warm standby mode (ha-cpu boot flag is set to false), you must disable SPBM and vIST to move to hot standby mode.

• When you try to switch-over from warm standby mode to hot standby mode using EDM, the system displays the following error message when you enable the boot config flag for ha-cpu:

  

  Hot-standby mode cannot be enabled while SPB/VIST features are still configured.

HA mode

In HA mode, also called hot standby, the platform synchronizes the master (primary) CPU information to the standby (secondary) CPU. The platform adds any configuration changes or application table changes to the master CPU by using bulk synchronization or incremental synchronization. Once synchronization is complete, both the CPUs contain the same configuration and application tables information. Application in HA mode support either full HA implementation or partial HA implementation. In full HA implementation, both the configuration and runtime application data tables exist on the master CPU and the standby CPU.

If the master CPU fails, the standby CPU takes over the master responsibility quickly and you do not see an impact on your network. Also, the IOC and SF modules as well as the full HA applications continue to operate and the full HA applications run consistency checks to verify the tables.

Partial HA

A few applications in HA mode have partial HA implementation, where the system synchronizes user configuration data (including interfaces, IPv6 addresses and static routes) from the master CPU to the standby CPU. However, for partial HA implementation, the platform does not synchronize dynamic data learned by protocols. After failure, those applications restart and rebuild their tables, which causes an interruption to traffic that is dependent on a protocol or application with partial HA support.

The following applications support Partial HA:

• Layer 3

  • Border Gateway Protocol (BGP)

  • Dynamic Host Configuration Protocol (DHCP) Relay

  • IPv6

  • Protocol Independent Multicast-Sparse Mode (PIM-SM)

  • Protocol Independent Multicast-Source Specific Mode (PIM-SSM)

• Transport Layer

  • Terminal Access Controller Access Control System plus (TACACS+)

Non-HA mode

In non-HA mode, also called warm standby, the platform does not synchronize the configuration between the master CPU and the standby CPU. When failover happens, the standby CPU switches to master role, and all the IOCs (except the new master CPU) are restarted. The new master CPU loads the configuration when all the cards are ready. These operations cause an interruption to traffic on all ports on the chassis.

Note

• When there is a switch-over to warm standby mode, only the RWA access level user can log in to the new master CPU console screen.

  The remaining users can log in to the CPU console screen only after the master CP module reloads the configuration and displays the new login prompt.

• When the platform switches from standby CPU to master CPU in warm standby mode, the platform always uses the previously-saved primary configuration file to boot the chassis on the switch.

• The runtime config file must be present on the flash drive during the boot-up of both the master CPU and the standby CPU. If the config file that is used by the master CPU for booting is not available on the standby CPU, the standby CPU loads the default config file. You can run the save config command to synchronize the configuration settings or copy the boot config file from the master CPU to the standby CPU. The standby CPU must be rebooted to load the desired config file.

  When the master CPU is physically removed in warm-standby mode, all cards are rebooted and the standby CPU switches to the master role and loads the saved configuration. If the old master CPU is physically not plugged in during this time, the respective slot configuration is not loaded to memory even though the configuration exists in the config file. When the old master CPU is re-inserted later, the system considers this as a first time insertion and loads the default configuration on the inserted CP card. This is expected behavior in warm-standby mode. To load the configuration for the re-inserted standby CPU, ensure that the savetostandby boot-flag is set to true after re-inserting the removed CPU, and run the CLI command source <config-file> on the active CPU.