Limitations and Precautions for Inter-DC Clusters
Read this section carefully to learn the limitations and precautions before you configure inter-DC cluster.
Hardware Requirements
Only the USG6610E, USG6615E, USG6620E, USG6625E, USG6630E, USG6635E, USG6650E, USG6655E, USG6680E, USG6712E, and USG6716E support inter-DC cluster. Devices that can for a cluster must meet the requirements in System Requirements.
License Requirements
The inter-DC cluster function is not license-controlled.
Networking Restrictions
- A cluster channel usually uses a DCI link. Dedicated lines must be used for DCI links to ensure security and reliability. Otherwise, services will be affected. Channel interfaces must meet the following requirements: no packet fragmentation, MTU greater than 1044, latency less than 10 ms, and no packet loss. Otherwise, the cluster negotiation and backup functions are affected, resulting in cluster faults.
- Enabling traffic aggregation might interrupt services in some networks, for example, in networks where service devices are not reachable to external networks. Before enabling traffic aggregation, ensure the connectivity of cluster members.
- The DCI link uses technologies such as VLAN to logically isolate service traffic from cluster channel traffic. It is recommended that security devices be deployed to ensure the security of west-east traffic in the data center.
- The following features require the forward and return paths be consistent in cluster networking. Otherwise, these features may be unavailable.
- IPSec
- SSL VPN
- SLB Layer-7 session
- Health check
Software Restrictions
- The interface types, interface numbering, and security zones to which interfaces are assigned must be the same for each member in a cluster. Otherwise, configurations are incompatible. For example, if the management master device uses GigabitEthernet0/0/1 as the uplink service interface, other members in the cluster must also use this interface as the uplink service interface.
- Except during upgrade, the software and patch versions of devices in the cluster must be the same. If they are different, errors will occur during synchronization among cluster members.
- After detecting a fault, the cluster triggers a business group switchover. Before the switchover is complete, traffic is still sent to the faulty device, causing service interruption is a short period.
- Before the configuration on the management master device is synchronized to other members, the configurations on member devices are inconsistent. Traffic may not be forwarded along with expected paths. After the configuration synchronization is complete, the system adjusts the traffic to expected paths.
- The cluster supports only IPv4, and does not support IPv6.
- The cluster does not support IP spoofing function.
- The cluster is mutually exclusive with the functions such as hot standby, DHCP snooping, flow probe, and hardware fast forwarding, and the conflicting functions cannot be enabled at the same time.
- Different features have different configuration and service backup. For details, see Service Data and Configuration Backup.
- Devices that join clusters must work in routed mode.
- The service interfaces of cluster member devices must use fixed IP addresses. Therefore, you cannot use the cluster function together with such features as PPPoE and DHCP Client which use dynamic IP addresses.
- Negotiation, backup, and forwarding channels should use separate service interfaces of a cluster member device, but not interfaces for management. Eth-Trunk interfaces are recommended.
- Do not delete the IP addresses used by the cluster (such as the channel address) in the interface view. Otherwise, the cluster function may be affected.
- Do not change the IP addresses or port numbers of cluster channel packets. Otherwise, these packets are unidentifiable.
- During cluster planning, specifications occupied by backup between cluster members shall be reserved. Cluster data backup uses device resources. If the number of data entries reaches the upper threshold of the device, no new data entry can be created.
- The clocks of the cluster members shall be synchronized. Therefore, NTP is recommended.
- For the USG6635E/6655E, USG6680E, and USG6712E/6716E, HASH-based CPU selection mode and hash gene must be the same for each member in a cluster.
- When the cluster system forwards traffic from the root system to a virtual system, you are advised to configure a traffic diversion table. Otherwise, the forwarding performance deteriorates.
- For TCP proxy, SSL proxy, mail proxy, and content security services, the forward and reverse paths must be consistent. Otherwise, the services may be interrupted. When using these functions in the cluster, you can use the following methods to ensure consistent forward and return paths:
- For the session stateful inspection service (such as TCP and ICMP packets), if the forward and reverse paths are inconsistent, the service may be interrupted due to a session stateful inspection failure. In this case, you are advised to enable the cluster backup function or disable the session stateful inspection function.
- The configuration backup function of the cluster is unavailable during the upgrade. Do not configure services during the cluster upgrade.
- Packets in a cluster should not pass through encryption tunnels such as GRE and IPSec. Otherwise, entries cannot be created in the cluster.
- Cluster packets sent and received on the cluster negotiation channel, backup channel, and forwarding channel are not controlled by security policies.
IPSec Restrictions
- IPSec configurations will not be deleted when a device joins or leaves a cluster. Configuring IPSec on a device that joins a cluster for the first time is not recommended. Instead, make the configuration synchronized from the management master device.
- SA is not deleted if a device no longer serves as a backup device in a business group due to its priority change.
- The default hold-off period for preemption in a business group is 60s. If the number of configured IPSec tunnels reaches the specifications, tunnel backup cannot be complete within 60s. In this case, specify a longer preemption hold-off period for the business group.
- Clusters do not support IPSec IKEv1+XAUTH or IKEv2+EAP authentication.
- In clusters, clients cannot be assigned addresses from address pools in L2TP over IPSec scenarios.
- In IPSec, 32-bit UNRs should not be delivered for cluster traffic diversion. When a UNR is generated, traffic diversion addresses may be merged. For example, 10.1.1.2 and 10.1.1.3 can be merged into 10.1.1.2/31, and the route can be advertised. If the traffic diversion addresses are 10.1.1.1 and 10.1.1.2, they cannot be merged, and such routes conflict with direct routes on interfaces.
NAT Restrictions
- The cluster function supports only PAT and NAT Server. Other NAT functions are not supported.
- A NAT address pool can be advertised only through one business group.
- In cluster scenarios, no interface IP address of the master and standby business device is allowed in NAT address pool. If the NAT address pool contains interface IP addresses, both the master and standby business devices will respond to the ARP request sent by the upstream device for addresses in the address pool, causing an ARP conflict.
- In a cluster, if the NAT address pool and the interface address are on the same network segment, one of the following conditions must be met. Otherwise, multiple devices in the cluster will reply to an ARP request, resulting in conflicts.
- Configure VRRP. If the NAT address pool and the VRRP address are on the same network segment, only the VRRP master device sends gratuitous ARP packets and responds to ARP requests. If the NAT address pool and the VRRP address are on different network segments, run the vrrp command in the address pool view to ensure that only one member of the cluster responds to ARP requests.
- Configure traffic diversion for the cluster service and advertise the NAT address pool address in UNR mode.