Precautions for Using Hot Standby Together with Other Features

Limitations for Using Hot Standby with Virtual Systems

• Ensure that the active and standby devices use the same virtual system name and ID.
• Hot standby configurations in the public system take effect on virtual systems. Only hot standby between two physical devices is supported. Hot standby between virtual systems is not supported. For example, if an interface in the virtual system on the active device goes Down, the active/standby device switchover is performed, not the switching between virtual systems on the devices.

Limitations for Using Hot Standby with the Agile Controller

In non-mirroring hot standby networking, if one FW restarts, the Agile Controller cannot deliver configurations to the other FW during the restart to prevent configuration inconsistency. In hot standby networking of the mirroring mode, to address the problem, you must run the hrp base config enable command on the active and standby devices so that the devices automatically synchronize configurations after restart.

Limitations for Using Hot Standby with DHCP

In hot standby deployment for load balancing, the FW cannot serve as the DHCP server.

In a hot standby scenario, only the device that is active in both hot standby and VRRP group can respond to DHCP requests of clients and allocates IP addresses to them. In load balancing networking, however, it is possible that two devices are active in both hot standby and VRRP group. In this case, both devices respond to request packets of DHCP clients. These two devices, however, use the same DHCP address pool. Therefore, it is possible that an IP address is allocated to different DHCP clients, causing address conflicts.

Limitations for Using Hot Standby with IPSec

• In the active/standby hot standby scenario, run the ipsec policy policy-name command to apply the specified IPSec security policy group on the specified interface. During command backup, this command will be backed up from the active device to the standby device. In the load balancing hot standby scenario, run the ipsec policy policy-name { alone | master | slave } command to apply the specified IPSec security policy group on the specified interface. This command is not backed up during command backup.
• If the FW initiates the establishment of an IPSec tunnel, you must run the tunnel local ip-address command to specify the virtual VRRP IP address as the local IP address for initiating the IPSec negotiation.
• In hot standby networking, if the active device fails, an active/standby device switchover is performed, and the standby device takes over services. After the original active device restarts, IPSec SAs are backed up in batches from the original standby device to the original active device. The backup takes a certain period of time. If the preemption function is enabled and there are many IPSec SAs (more than 10000 IPSec SAs), the original active device may preempt the active state before the IPSec SA backup is complete. As a result, the IPSec service becomes abnormal.

  Therefore, if there are many IPSec SAs, you are advised to disable the preemption function or set a great preemption hold-off period.

• In IPSec hot standby scenarios, you should not run the hrp switch command to manually switch the active/standby status. If you do so, the standby device directly becomes active without backing up IPSec tunnel information from the active device, causing IPSec service interruption.
• In LTE IPSec scenarios, you are advised to run the re-authentication interval interval command to set the IKEv2 negotiation aging time (interval for re-authentication) 15% greater than the eNodeB aging time to prevent active/standby switchovers upon the receipt of re-negotiation packets during active/standby backup. If the standby device does not completely synchronize the active device configuration, IPSec services may be interrupted.
• When the undo hrp enable command is run to disable hot standby, created IPsec tunnels are automatically deleted, which affects IPsec services. Exercise caution when you run this command.

Limitations for Using Hot Standby with SSL VPN

• When hot standby functions with SSL VPN, the local certificates of the virtual gateways for the active and standby devices must be the same. Otherwise, the SSL VPN service cannot be properly switched over during active/standby device switchover.
• In hot standby deployment for load balancing, the FW does not support SSL VPN.
• After an active/standby switchover, online SSL VPN users do not need to log in again. However, connections need to be re-established for services, such as port forwarding, web proxy, file sharing, and network extension.

Limitations for Using Hot Standby with NAT

• Hot standby networking does not support NAT address pool detection.
• In hot standby deployment in load balancing mode, if NAT is in NAPT mode, you must run the hrp nat resource primary-group command on one and run the hrp nat resource secondary-group command on the other to divide the ports for the addresses in the address pool into two segments to prevent port conflicts.
• In hot standby networking in load balancing mode, if NAT is in NAT NO-PAT mode, you must run the nat resource load-balance enable command to enable one device to perform both address and port allocation so that the addresses and ports allocated to the two devices are not in conflict with each other. After you run this command, the heartbeat interface traffic will increase (the increased traffic volume is subject to the size of live network services, generally the size of the first packet). You need to check whether the heartbeat interface bandwidth is sufficient.
• In hot standby scenarios, no interface IP address of the active and standby device is allowed in NAT address pool. If the NAT address pool contains interface IP addresses, both the active and standby devices will respond to the ARP request sent by the upstream device for addresses in the address pool, causing an ARP conflict.
• In a hot standby scenario, the source or destination IP addresses in the NAT policy cannot contain the IP address of the heartbeat interface. Otherwise, NAT is performed for heartbeat packets, causing a heartbeat link communication exception.
• In hot standby networking in load balancing mode, the address pool mode can be PAT (including port pre-allocation) or No-PAT and cannot be 3-tuple (including static mapping).
• The non-mirroring hot standby scenario does not support easy-IP. As easy-IP directly uses the public IP address of an interface as the post-NAT address, in non-mirroring hot standby scenario, if you use easy-IP, the post-NAT address if the active device's interface address. Because the standby device does not have the active device's interface address, sessions backed up from the active device to the standby device are unavailable. In addition, when upstream devices learn ARP entries, they learn the active device's MAC address but fail to learn the standby device's MAC address. Therefore, do not use easy-IP in non-mirroring hot standby scenarios.

Limitations for Using Hot Standby with Port Pre-allocation

In load-balancing hot standby networking, when port pre-allocation is used, the active device assigns the port resources with an even address pool ID, and the standby device assigns the port resources with an odd address pool ID. Address pool IDs need to be set on both active and standby devices and cannot be all odd numbers or even numbers. Otherwise, port resources that are not assigned by the local device need to be requested from the peer device through the heartbeat interfaces, which increases the burden on the heartbeat interfaces. For example, you are not advised to set the address pool IDs on the active and standby devices to an even number (2, 4, 6, or 8) or an odd number (1, 3, 5, or 7).