The CPU High Availability (CPU-HA) feature provides continuous operation of Virtual Services Platform 9000 features after a CPU failover occurs. The CPU-HA takes over in CPU-HA mode from the master CPU that failed, so operations and processes are not interrupted.
•Overview on page 57
•OSPF on page 58
•RIP on page 58
•Prefix lists and route policies on page 59
•VRRP on page 59
•Router Discovery on page 59
•DHCP relay on page 60
•UDP forwarding on page 60
•IP filters on page 60
Overview
To activate CPU-HA mode, use the boot config flags ha-cpu command. and to disable CPU-HA mode, use the no boot config flags ha-cpu command. Toggling the HA-CPU boot flag will only reset the standby CP module. The standby CP will restart in the specified HA mode (hot or warm standby). All other modules are not affected. You do not need to restart the system to have the standby CP in hot or warm standby mode. After you change the CPU-HA flag, the slave CPU is reset. The master is not affected
CPU-HA for Layer 3 CPU redundancy provides redundancy for the following protocols and features:
• Open Shortest Path First (OSPF) version 2, including MD5
• Routing Information Protocol (RIP) version 1 and RIP version 2
• prefix lists and route policies
• Equal Cost Multipath (ECMP) and alternate routes
• Virtual Router Redundancy Protocol (VRRP)
• Virtual Router Forwarding (VRF) Lite
• ICMP Router Discovery Protocol (IRDP)
• IEEE 802.3ad
• IEEE 802.1x
• Dynamic Host Configuration Protocol (DHCP) relay agent
• User Datagram Protocol (UDP) forwarding
• IP filters
Virtual Services Platform 9000 supports the Packet Capture (PCAP) tool in High Availability mode after you restart the secondary CPU and activate PCAP.
OSPF
CPU-HA for Layer 3 redundancy avoids disruption of network traffic after a master CPU that runs OSPF fails over. CPU-HA maintains an exact copy of the OSPF instance of the master CPU on the CPU-HA. After the CPU-HA initializes, all OSPF information about the master CPU is table synchronized and all OSPF events are event synchronized, to the CPU-HA. After a master CPU failover occurs, the OSPF instance on the CPU-HA resumes without affecting router traffic and OSPF neighbors.
It can take up to three seconds for the new master CPU to transmit OSPF packets during CPU-HA to master CPU transition. Avaya recommends that you use router dead intervals of 5 seconds or higher.
RIP
CPU-HA for Layer 3 redundancy for RIP provides CPU failover without altering existing RIP routing information in the network and without disrupting network traffic.
CPU-HA for Layer 3 redundancy for RIP synchronizes all RIP routing and interface information from the master CPU to the CPU-HA so the RIP instances on both CPUs are exactly the same.
The RIP route time-to-live (TTL), however, can have different values between the master CPU and the CPU-HA because of the nature of the synchronization process.
At failover transition, the new master CPU can miss RIP update packets if they were in the receiving queue of the old master CPU or if the event synchronization message did not reach or finish processing in the previous CPU-HA. RIP can recover this information.
Prefix lists and route policies
A prefix list is a list of networks that route policies use to define an action. You can create one or more IP prefix lists and apply that list to IP route policy.
A prefix list combines the address-list database and the net0lst database. A prefix list with a 32-bit mask is equivalent to an address. A prefix list with a mask less than 32 bits can be used as a network.
After you configure the masklengthFrom field to be less than the Mask LengthTo field, you can also use the masklengthFrom field value as a range.
Configurations related to the route policy and prefix list synchronize to the CPU-HA from the master CPU, so the routes announced or accepted from one protocol domain to another are not affected after the master CPU fails over. The table synchronization synchronizes the configuration to the CPU-HA after it initializes, and events triggered in the master CPU relay to the CPU-HA by event synchronization.
After you create a route policy using the ACLI, the route-policy ID is automatically generated.
Important:
When you configure a prefix list for a route policy, be sure to add the prefix as a.b.c.d/32.
You must enter the full 32-bit mask to exact a full match of a specific IP address.
VRRP
After the VRRP master router fails, the backup virtual router has a delay before functioning as the VRRP master. Layer 3 CPU redundancy of VRRP prevents disruption of IP routing and forwarding operations, and protects networks with virtual routers from interruption.
Layer 3 CPU redundancy of VRRP also provides protection and faster failover than protocol failover. VRRP statistics do not synchronize from the master CPU to the backup CPU.
Router Discovery
Layer 3 redundancy for Router Discovery synchronizes the Router Discovery configuration from the master CPU to the CPU-HA so that Router Discovery advertisements are sent to the hosts without delay after the master CPU fails over. Layer 3 redundancy does this using table Prefix lists and route policies
Router solicitation messages do not synchronize from the master CPU to the CPU-HA. The new master sends router advertisements only if the timer expires or it receives one more solicitation message.
DHCP relay
Layer 3 redundancy for DHCP relay synchronizes the DHCP relay configuration of the master CPU to the relay configuration of the CPU-HA so that DHCP requests forward to the DHCP server without delay after the master CPU fails. An event triggered in the master CPU then synchronizes to the CPU-HA by Event Synchronization.
DHCP-related packets received in the master CPU do not synchronize to the CPU-HA. If the master CPU receives a request, but it switches over to the CPU-HA before it forwards the request, the information is lost after the CPU-HA takes over. However, the client continues to send the DHCP discover packet until it receives the DHCP offer packet. The DHCP statistics do not synchronize to the CPU-HA.
UDP forwarding
Table synchronization and event synchronization permit the CPU-HA to receive UDP
forwarding configurations. The UDP broadcasts forward to the required server without delay after the master CPU fails over.
UDP broadcast packets received in the master CPU do not synchronize to the CPU-HA. If the master CPU receives a packet and failover occurs before it forwards the packet, the forwarding does not occur until the client sends one more broadcast.
IP filters
IP traffic filter redundancy protects network filter activities after a master CPU failover occurs.
IP traffic filter redundancy uses existing CPU-HA table synchronization and event
synchronization mechanisms to synchronize all IP traffic filter information between the master CPU and the CPU-HA. This activity ensures that the master CPU and CPU-HA have exactly the same IP filter information.
Because IP traffic filter counter information is retrieved directly from system hardware, only the master CPU can provide correct filter counter information, not the CPU-HA.