Hot Backup (RBM) Technology White Paper-6W100

HomeSupportResource CenterTechnology White PapersHot Backup (RBM) Technology White Paper-6W100
Download Book
Table of Contents
Related Documents

 

 

Hot Backup (RBM) Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Copyright © 2022 New H3C Technologies Co., Ltd. All rights reserved.

No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.

Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.

This document provides generic technical information, some of which might not be applicable to your products.

The information in this document is subject to change without notice.


Contents

Overview·· 1

Technical background· 1

Benefits· 2

Hot backup implementation· 3

Concepts· 3

Hot backup system setup· 4

RBM packets· 4

RBM channels· 4

Device roles· 5

Setup process· 6

Operating modes of the hot backup system·· 7

Configuration backup· 9

Triggering batch configuration backup· 10

Configuration consistency check· 10

Service entry backup· 11

Running status switchover 11

Running status switchover triggers· 11

Monitoring mechanisms· 12

Switchover process· 13

Hot backup deployment schemes· 15

Routed in-path deployment in active/standby mode· 16

Routed in-path deployment in dual-active mode· 17

Transparent in-path deployment in active/standby mode· 19

Transparent in-path deployment in dual-active mode· 21

Traffic steering of the hot backup system·· 22

Associating the hot backup system with VRRP· 22

Associating the hot backup system with static routes· 24

Associating the hot backup system with routing protocols· 25

Associating the hot backup system with VLANs· 27

Asymmetric traffic forwarding· 28

Traffic switchover upon failure recovery· 29

Configuring service features in the hot backup system·· 30

NAT in the hot backup system·· 30

Hot backup system support for SSL VPN· 33

Hot backup system support for DPI services· 33

Hot backup system support for contexts· 33

Hot backup system support for vSystems· 33

Restrictions and guidelines for the hot backup system·· 34

Application scenarios· 34

Hot backup system in active/standby mode in collaboration with VRRP· 34

Hot backup system in dual-active mode in collaboration with VRRP· 35

Hot backup system in active/standby mode in collaboration with a routing protocol 36

Hot backup system in dual-active mode in collaboration with a routing protocol 37

Transparent in-path hot backup system in active/standby mode· 38

Transparent in-path hot backup system in dual-active mode· 39

 


Overview

Technical background

In the big data era, with the digital transformation in various industries, the network carries more and more important services. Network availability and service continuity are required for network construction.

As shown in Figure 1, typically redundant egress devices are deployed at the border between the external and internal networks to prevent a single point of failure from interrupting traffic forwarding. When one egress device fails, traffic is switched to a different path.

Hot backup is not used on traditional network devices such as switches and routers as they require only interface and network redundancy to ensure service continuity. It is used on security devices that perform status check and policy-based processing on packets, such as firewalls, IPSs, and network access behavior auditors. These devices check the validity of the first packet of each flow and create a session entry to record the traffic pattern, including the source and destination IP addresses, source and destination ports, and protocol. A security device forwards the subsequent packets of a flow only when the packets match a session entry. To ensure service continuity after traffic is switched between redundant security devices, hot backup is used to synchronize service entries and configuration between the devices through a dedicated channel.

Figure 1 HA network model

 

Hot backup can effectively address the previous issues. As shown in Figure 1, the hot backup system formed by two devices can implement link redundancy. In addition, the hot backup system can synchronize session entries, service state, and configuration information between the two devices to implement device redundancy.

Benefits

Hot backup is a backup management technique that provides a high availability solution at the device level and system level. In addition to increased link bandwidth, enhanced network reliability, and traffic load sharing, hot backup has the following benefits:

·     Device-level reliability—The hot backup system enhances the network communication reliability from the link and card level to the device level. It can perform deep packet processing and inspection for service-level smooth migration.

·     Fast service deployment—You only need to configure services on one device. The other device automatically synchronizes configuration information in real time. This simplifies device configuration and implements fast service onboarding.

·     Separate device upgrade—The two devices in the hot backup system can be upgraded separately. When you upgrade one device, the other device can operate correctly. The upgrade process has almost no impact on ongoing services.

·     Automatic traffic switchover—The hot backup system can use multiple monitoring techniques to monitor device and link status, and cooperate with other technologies (such as OSPF) to perform traffic switchover upon detecting a failure.

·     Support for multiple services—The hot backup system ensures service continuity upon traffic switchover for services such as security policies, DPI, NAT, LB, IPsec, and SSL VPN.

·     Networking compatibility—The hot backup system can be associated with RFC standard protocols such as OSPF, IS-IS, BGP, and VRRP to direct traffic. It features high compatibility and scalability in networks deployed with devices from various vendors.

Hot backup implementation

The hot backup feature is implemented through the remote backup management (RBM) protocol that can back up configuration and service entries between devices. It can also cooperate with VRRP and dynamic routing protocols to ensure uninterrupted transmission of user data based on unified traffic switchover management.

Concepts

Hot backup implements unified device management from the control and service aspects, providing device-level redundancy and traffic load sharing. Hot backup has the following the basic concepts:

·     Primary and secondary roles—In the control plane, the primary and secondary roles are assigned to the two devices in the hot backup system to control the configuration synchronization between the devices.

·     Active and standby states—Determine which device forwards and processes traffic in the data plane. The active device forwards traffic of services and backs up service entries to the standby device in real time.

·     RBM packets—Packets transmitted through TCP over the RBM channels between the two devices in the hot backup system.

·     RBM channels—Transmit status information, configuration, and service entries between the two devices.

·     Hot backup modes—Include active/standby mode and dual-active mode. In active/standby mode, the active device processes all services. In dual-active mode, both devices process services to increase the capability of the hot backup system and load share traffic.

Hot backup system setup

RBM packets

Packet types

RBM packets include the following:

·     Control packets—Set up the hot backup system based on the device configuration, and control active/standby switchovers based on the running status.

·     Keepalive packets—Transmitted periodically between the hot backup system members for peer availability detection.

·     Configuration consistency check packets—Check whether the hot backup system members have consistent configuration.

·     Configuration backup packets—Back up configuration between the hot backup system members.

·     Service entry backup packets—Back up service entries between the hot backup system members.

·     Transparent transmission packets—Transmit or replicate asymmetric-path traffic between the hot backup system members.

RBM channels

The hot backup system members transmit hot backup system status, important configuration, and service entries over the following channels:

·     Control channel—Transmits data by using packets, including hot backup status packets, configuration consistency check packets, and packets used for configuration synchronization. The hot backup system compares the specified local and peer IP address to determine the device role for setting up the control channel. The device with higher IP address acts as the server, and the other device acts as the client to initiate the TCP connection. The port numbers used for setting up the control channel must be identical on all devices in the hot backup system.

·     Data channel—Transmits only backup packets and packets that require transparent transmission. The data channel uses the hardware driver for data transmission and supports only Layer 2 forwarding.

Device roles

In the hot backup system, the primary and secondary roles control the configuration synchronization between the devices. The master and backup roles ensure service entry consistency and switchover of both inbound and outbound traffic for symmetric forwarding upon device failure.

Primary and secondary device roles

As shown in Figure 2, the hot backup system backs up important configuration from the primary device to the secondary device to prevent service interruption when an active/standby switchover occurs. The configuration on the secondary device is overwritten. The unidirectional backup mechanism avoids configuration conflicts, especially in dual-active mode. The roles can only be manually assigned to devices.

Figure 2 Primary and secondary device roles

 

Each hot backup member device adds a prefix to the view prompt to identify its role.

·     The primary device adds the RBM_P prefix, RBM_P<Sysname> for example.

·     The secondary device adds the RBM_S prefix, RBM_S<Sysname> for example.

After you assign roles to the member devices in the hot backup system, both devices add the RBM_P prefix to their view prompts. The devices display view prompt prefixes according to their roles after they set up the HA control channel.

You must assign the primary and secondary roles to the two member devices in the hot backup system, respectively. After RBM control channel setup, you can configure services only on the primary device. The configuration information can only be synchronized from the primary device to the secondary device, and overwrites the corresponding information on the secondary device.

Master and backup device roles

As shown in Figure 3, to ensure ordered packet processing and unified traffic management, assign master and backup roles to the devices in the hot backup system at the data plane. The master device processes services and synchronize service entries to the backup device in real time. The backup device receives service entries synchronized from the master device. In addition, upon failure of the master device, the backup device can take over to ensure service continuity.

The master and backup roles are elected and can dynamically switchover. Initially, when the hot backup system operates in active/standby mode, the master and backup roles corresponds to the primary and secondary roles of the devices, respectively. When the hot backup system operates in dual-active mode, both devices are master devices.

Figure 3 Master and backup device roles

 

Setup process

As shown in Figure 4, the two devices set up a hot backup system as follows:

1.     After the devices complete hot backup configuration and startup process, they start to establish an RBM channel.

2.     After RBM channel establishment, the devices exchange negotiation packets to set up the hot backup system.

3.     When the local device receives negotiation packets from the peer device, it checks whether the hot backup configuration in the negotiation packet is consistent with the local configuration. If they are consistent, the two device successfully set up the hot backup system. If they are not consistent, two device cannot set up the hot backup system.

4.     Upon hot backup system setup, the devices elect the primary and secondary roles. In the current software version, the primary and secondary roles can only be manually assigned. The device with primary role becomes the master device, and the device with the secondary role becomes the backup device.

5.     After primary and secondary role configuration, the devices elect the master and backup roles. The master and backup roles depend on the operating mode of the hot backup system and device running status.

6.     After master and backup role configuration, the primary device starts to synchronize configuration information to the secondary device. The master device starts to synchronize service entries to the backup device.

7.     Meantime, both devices periodically send keepalive packets to detect the neighbor status through the RBM channel.

8.     After the hot backup system operates correctly, the master device synchronizes local data, such as configuration information and service entries, to the peer in real time. In this way, failure of one device does not interrupt traffic forwarding. Service continuity is ensured.

Figure 4 Hot backup system setup process

 

Operating modes of the hot backup system

The hot backup system supports the active/standby and dual-active modes.

Active/standby mode

In active/standby mode, one device is active to process services, and the other device stands by, as shown in Figure 5. When an interface or link on the active device fails or when the active device fails, the standby device becomes active to process services.

Figure 5 Active/standby mode of the hot backup system

 

Dual-active mode

In dual-active mode, both devices process services to increase load sharing capability of the hot backup system, as shown in Figure 6. When one device fails, its traffic is switched to the other device for forwarding.

Figure 6 Dual-active mode of the hot backup system

 

Configuration backup

The hot backup system backs up important configuration from the primary device to the secondary device to prevent service interruption when an active/standby switchover occurs.

The hot backup system supports manual and automatic configuration backup.

·     Automatic backup—Automatically synchronize configuration changes on the primary device to the secondary device in real time.

·     Manual backup—Manually enable the primary device to perform a batch backup to the secondary device.

The hot backup system supports real-time backup and batch backup methods.

·     Real-time backup—Synchronizes added, deleted, or modified configuration information on the primary device to the secondary device in real time.

·     Batch backup—Synchronizes all configuration information on the primary device to the secondary device in a batch.

Triggering batch configuration backup

Batch configuration backup between devices is triggered in the following conditions:

·     After the hot backup system operates correctly, perform a manual backup on the primary device.

·     After the devices operate correctly in the hot backup system, the devices successfully establish the RBM channel for the first time. In addition, automatic configuration backup is enabled for the first time (or enabled by default). The primary device will batch synchronize all configuration information to the secondary device. After the device operates correctly, if a batch backup is performed, no more batch configuration backups will be triggered upon repeated enabling of automatic configuration backup or RBM control channel establishment.

·     A device in the hot backup system reboots or the hot backup process (RBM process) restarts, and the automatic configuration backup is enabled on the peer device during the period of time. After the device completes reboot and the RBM control channel is established again, the peer device (even if it is a secondary device) will back up all configuration information from the local device to perform overwrite.

Configuration consistency check

The hot backup system verifies configuration consistency between the hot backup members by using configuration consistency check packets. If a device detects configuration inconsistency, it generates a log for you to manually synchronize configuration.

Configuration consistency check operates as follows:

1.     The primary device sends configuration consistency check packets to the secondary device and collects configuration digests of related modules at the same time.

2.     The secondary device receives the packets, encapsulates its configuration digests into configuration consistency check packets, and sends these packets to the primary device.

3.     The primary device compares its configuration digests with those of the secondary device. If inconsistency is detected, the primary device generates a log.

The hot backup system supports automatic and manual configuration consistency check.

·     Automatic configuration consistency check—The device periodically sends configuration consistency check packets to verify configuration consistency between the two devices.

·     Manual configuration consistency check—Manually enable the device to perform a configuration consistency check.

Service entry backup

The hot backup system backs up the service entries generated on the active device to the standby device to prevent service interruption when an active/standby switchover occurs.

Devices that perform packet inspection generate a session entry for each dynamic connection. In the hot backup system, only the active device processes traffic and generates session entries. To ensure service continuity, the active device backs up its session entries to the standby device in real time. After an active/standby switchover, the new active device can forward the packets of the existing services based on the session entries without interruption.

Running status switchover

The primary or secondary device role is determined based on configuration. The running status is determined based on device role election and can be switched over.

Running status switchover triggers

As shown in Figure 7, in the hot backup system, an active/standby switchover occurs if one device fails or its links fail. The other device that operates correctly will take over to process all traffic that traverse the hot backup system to ensure service continuity.

Figure 7 Active/standby switchover in the hot backup system

 

The following events can trigger an active/standby switchover:

·     Disconnection of the control channel.

If the control channel is disconnected when both member devices are operating correctly, both devices become active devices. However, the devices will leave the hot backup system in this situation, and forwarding of asymmetric-path traffic will be interrupted.

·     Failure of the active device.

After the device fails, the control channel is disconnected, and a switchover is triggered.

·     Failure of the interface monitored by the hot backup system on the active device.

If any interface monitored by the hot backup system fails, a switchover is triggered.

·     Failure of any security service module on the active device.

This event triggers an active device election based on the following rules:

¡     If the member devices have the same number of present security service modules, the following rules apply:

-     In active/standby mode, the primary device is the active device, and the secondary device is the standby device.

-     In dual-active mode, both member devices are active.

¡     If one member device has more present security service modules than the other, the former becomes the active device, and the latter becomes the standby device. This rule applies regardless of whether the hot backup system is operating in active/standby or dual-active mode.

·     Failure of all MPUs on the active device.

Switchover is not triggered when only the active MPU fails. Switchover is triggered when both the active and standby MPUs fail.

·     Failure of all switching fabric modules on the active device.

·     State change to Negative of any track entry monitored by the hot backup system on the active device.

This event triggers an active device election. If both member devices have track entries in Negative state, the following rules apply:

¡     In active/standby mode, the primary device is the active device, and the secondary device is the standby device.

¡     In dual-active mode, both member devices are active.

The hot backup system can use the previous methods to perform switchover, and immediately direct traffic to the normal device for service continuity. However, as a best practice, troubleshoot the failure in time to ensure stable operation of the hot backup system.

Monitoring mechanisms

The hot backup system supports multiple fault monitoring methods to detect the running status of the device and uplink or downlink status. For more information, see "Running status switchover triggers."

Certain monitoring events of the hot backup system do not require configuration. The hot backup system automatically monitors such events, for example, control channel events, overall system failure, MPU failure, service module failure, and switching fabric failure. Certain monitoring events require configuration, for example, monitoring interfaces and track entries. Table 1 shows such monitoring configuration in various networks.

Table 1 Monitoring configuration for the hot backup system in various networks

Networking scenario

Monitoring configuration

The service interfaces operate at Layer 3, and are connected to the Layer 3 interfaces on the uplink and downlink routers. Static routes are configured.

Enable monitoring of the uplink and downlink Layer 3 Ethernet interface status.

The service interfaces operate at Layer 3, and are connected to the Layer 3 interfaces on the uplink and downlink routers. Dynamic routing protocols are configured.

Associate track entries to monitor the uplink and downlink link status.

The service interfaces operate at Layer 3, and are connected to the uplink and downlink Layer 2 switches.

Associate track entries to monitor the uplink and downlink link status.

Do not configure Track settings for the VRRP group.

The service interfaces operate at Layer 2, and are connected to the Layer 3 interfaces on the uplink and downlink routers.

Enable monitoring of the uplink and downlink Layer 3 Ethernet interface status.

The service interfaces operate at Layer 2, and are connected to the uplink and downlink Layer 2 switches.

Associate VLANs to monitor the uplink and downlink interface status.

 

The hot backup system can monitor interfaces and VLANs and can be associated with Track as follows:

·     Monitor interfaces—The monitored interfaces can forward packets only when they are all up. If any of the monitored interfaces goes down, none of them will be able to forward packets.

·     Monitor VLANs—The monitored VLANs are active and the member ports can forward packets only when the member ports are all up. If any of the member ports goes down, none of them will be able to forward packets, and all the monitored VLANs will become inactive.

·     Associate with Track—If one of the monitored track entries becomes Negative, the hot backup system performs an active/standby switchover and switches traffic to the new active device to ensure service continuity.

Switchover process

As shown in Figure 8, both devices are primary in the control plane and active in the data plane when the RBM channels are not established. This is not a correct condition because the hot backup system has not set up.

Figure 8 RBM channels not established

 

As shown Figure 9, when the RBM channels are established and both devices are operating correctly, the roles of the devices are determined based on configuration and do not change in any condition. In the data plane, the running status of the devices is consistent with their roles. In active/standby mode, the primary device is the active device, and the secondary device is the standby device. In dual-active mode, both devices are active.

Figure 9 Hot backup system in active/standby mode

 

As shown in Figure 10, when the uplink or downlink fails on a device, the status of the devices changes in the data plane. The device that operates correctly processes all traffic. In the control plane, the roles of the devices do not change.

Figure 10 Uplink or downlink failure

 

As shown in Figure 11, the device role changes in the control plane only when the primary device fails or restarts, and the running status in the data plane will change accordingly. The secondary device will take over the primary role. When the original primary device recovers, it takes over the primary role.

Figure 11 Device failure or restart

 

Hot backup deployment schemes

The hot backup system supports the following deployment schemes:

·     Routed in-path deployment in active/standby mode.

·     Routed in-path deployment in dual-active mode.

·     Transparent in-path deployment in active/standby mode.

·     Transparent in-path deployment in dual-active mode.

Routed in-path deployment in active/standby mode

Figure 12 shows a typical model of routed in-path deployment in active/standby mode. The hot backup system is directly connected to the upstream and downstream Layer 2 switches by Layer 3 interfaces. To use this scheme in collaboration with VRRP, perform the following tasks:

·     Establish RBM channels between Device A and Device B.

·     On Device A and Device B, create uplink VRRP group 1 and downlink VRRP group 2 and associate them with the hot backup system.

·     On Device A, associate VRRP group 1 and VRRP group 2 with the VRRP active group. On Device B, associate VRRP group 1 and VRRP group 2 with the VRRP standby group.

·     On Device A and Device B, specify the IP address of Interface A1 on the router (2.1.1.15) as the next hop of the route to the Internet.

·     On the router, specify the virtual IP address of VRRP group 1 (2.1.1.3) as the next hop of the route to the host's subnet.

·     On the host, specify the virtual IP address of VRRP group 2 (10.1.1.3) as the default gateway.

·     On Switch A, assign the interfaces attached to the router, Device A, and Device B to the same VLAN.

·     On Switch B, assign the interfaces attached to the host, Device A, and Device B to the same VLAN.

Figure 12 Routed in-path deployment in active/standby mode

 

Routed in-path deployment in dual-active mode

Figure 13 shows a typical model of routed in-path deployment in dual-active mode. The hot backup system is directly connected to the upstream and downstream Layer 2 switches by Layer 3 interfaces. To use this scheme in collaboration with VRRP, perform the following tasks:

·     Establish RBM channels between Device A and Device B.

·     On Device A and Device B, create two uplink VRRP groups and two downlink VRRP groups.

·     Create VRRP group 3 and VRRP group 4 on the downlink interfaces of Device A and Device B.

·     On Device A, associate VRRP group 1 and VRRP group 3 with the VRRP active group, and associate VRRP group 2 and VRRP group 4 with the VRRP standby group.

·     On Device B, associate VRRP group 1 and VRRP group 3 with the VRRP standby group, and associate VRRP group 2 and VRRP group 4 with the VRRP active group.

·     On Device A and Device B, specify the IP address of Interface A1 on the router (2.1.1.15) as the next hop of the route to the Internet.

·     On the router, configure routes as follows:

¡     Specify the virtual IP address of VRRP group 1 (2.1.1.3) as the next hop of the route to Host A's subnet.

¡     Specify the virtual IP address of VRRP group 2 (2.1.1.4) as the next hop of the route to Host B's subnet.

·     On Host A, specify the virtual IP address of VRRP group 3 (10.1.1.3) as the default gateway.

·     On Host B, specify the virtual IP address of VRRP group 4 (10.1.1.4) as the default gateway.

·     On Switch A, assign the interfaces attached to the router, Device A, and Device B to the same VLAN.

·     On Switch B, assign the interfaces attached to the hosts, Device A, and Device B to the same VLAN.

Figure 13 Routed in-path deployment in dual-active mode

 

Transparent in-path deployment in active/standby mode

Figure 14 shows a typical model of transparent in-path deployment in active/standby mode. The Layer 2 hot backup system is directly connected to the upstream and downstream Layer 2 switches by Layer 2 interfaces. To use this scheme, perform the following tasks:

·     Establish RBM channels between Device A and Device B.

·     On Device A and Device B, assign uplink and downlink interfaces to the same VLAN.

·     Configure the hot backup system to monitor one of the following objects:

¡     The VLAN where Device A and Device B reside.

You do not need to enable spanning tree on the upstream and downstream switches.

¡     Uplink and downlink interfaces of Device A and Device B.

You must enable spanning tree on the upstream and downstream switches.

·     On Switch A, assign the interfaces attached to the upstream router, Device A, and Device B to the same VLAN.

·     On Switch B, assign the interfaces attached to the hosts, Device A, and Device B to the same VLAN.

Figure 14 Transparent in-path deployment in active/standby mode

 

Transparent in-path deployment in dual-active mode

Figure 15 shows a typical model of transparent in-path deployment in dual-active mode. The Layer 2 hot backup system is directly connected to the upstream and downstream routers by Layer 2 interfaces. To use this scheme, perform the following tasks:

·     Establish RBM channels between Device A and Device B.

·     On Device A and Device B, assign uplink and downlink interfaces to the same VLAN.

·     On Device A and Device B, configure the hot backup system to monitor the status of the uplink and downlink interfaces.

·     On Router A and Router B, configure the same cost for OSPF routes and enable per-flow load sharing among ECMP routes.

Figure 15 Transparent in-path deployment in dual-active mode

 

Traffic steering of the hot backup system

Associated with a routing protocol, VRRP, or a VLAN, the hot backup system can ensure service continuity upon a switchover for both inbound and outbound traffic.

Associating the hot backup system with VRRP

About this task

You can use the hots backup system and VRRP in combination to control master/backup switchover for device role consistency (master or backup) in multiple VRRP groups. This ensures that both inbound and outbound traffic can be switched to the new master for symmetric forwarding upon device failure.

Figure 16 illustrates VRRP association with the hot backup system in active/standby mode.

·     As shown in the left, VRRP cannot ensure symmetric forwarding upon failure on a device, which causes traffic interruption.

·     As shown in the right, after the RBM control channel is established, the hot backup system determines the roles of the devices in all VRRP groups. The master election mechanism of VRRP no longer takes effect. If the RBM control channel is disconnected, the master election mechanism of VRRP takes effect again.

Figure 16 VRRP and hot backup system association

 

VRRP active/standby group

The hot backup system is associated with VRRP by VRRP active and standby groups.

A VRRP active/standby group can be in master or backup state, which determines the state of devices in the associated VRRP groups. For example, if a VRRP active group is in master state, all devices in the associated VRRP groups are masters.

The initial state of a VRRP active/standby group is depends on the hot backup system mode.

·     Active/Standby mode—On the primary device, the initial state is master for the VRRP active and standby groups. On the secondary device, the initial state is backup for the VRRP active and standby groups.

·     Dual-active mode—The state of a VRRP active/standby group is not affected by the HA roles. The initial state is master for the VRRP active group and is backup for the VRRP standby group.

VRRP master election in the hot backup system

After the hot backup system is associated with VRRP, the hot backup system determines the roles of the devices in the VRRP groups. As shown in Figure 16, Device A is the master in VRRP group 1 and VRRP group 2, and Device B is the backup in VRRP group 1 and VRRP group 2. When Interface A2 on Device A fails, the following events occur:

1.     The hot backup system receives an interface failure event and sends the status change information of the VRRP active and standby groups to Device B.

2.     Device B sets its role to master in the VRRP standby group and then becomes the master in VRRP group 1 and VRRP group 2.

3.     Device B sends a response to Device A after the master/backup switchover.

4.     Device A sets its role to backup in the VRRP active group and then becomes the backup in VRRP group 1 and VRRP group 2.

When Interface A2 recovers, the hot backup system performs another master/backup switchover following the same procedure. Traffic is switched back to Device A after the switchover.

ARP and MAC learning in VRRP

When the members of a VRRP group receive an ARP request for the group's virtual IP address, the master replies with the group's virtual MAC address. This allows the upstream and downstream Layer 2 devices and hosts to learn the virtual MAC address.

Associating the hot backup system with static routes

You can enable the hot backup system to monitor interfaces and associate interface status with static routes. The feature ensures that both inbound and outbound traffic can be switched to the new active device for symmetric forwarding.

This feature requires associating the hot backup system with monitored interfaces to perform active/standby switchover upon link or interface failures.

Figure 17 illustrates static route association with the hot backup system in active/standby mode.

·     As shown in the left, Device A (active device) forwards traffic based on floating static route configuration. (Multiple static routes has the same destination, the route priority on the active device is higher than that on the standby device.) Both inbound and outbound traffic are forwarded through Device A.

·     As shown in the right, when interface A2 fails, Device A and Device B perform an active/standby switchover. Meantime, the device shuts down Interface A1. The static route with higher priority on Device A becomes invalid, and the static route with lower priority takes effect. Both inbound and outbound traffic are forwarded through Device B.

Figure 17 Static route and hot backup system association

 

In the network where static routes and hot backup system are associated, you need to configure equal-cost static routes on the device for traffic load sharing.

Associating the hot backup system with routing protocols

You can use the hot backup system to enable the routing protocols on the standby device to advertise modified link cost. The feature ensures that both inbound and outbound traffic can be switched to the new active device for symmetric forwarding.

This feature requires associating the hot backup system with Track to perform active/standby switchover upon link or interface failures.

Figure 18 illustrates OSPF association with the hot backup system in active/standby mode.

·     As shown in the left, Device A (active device) advertises link cost 1 based on OSPF configuration. Device B (standby device) advertises link cost 65500 modified by the hot backup system. Both inbound and outbound traffic are forwarded through Device A.

·     As shown in the right, when interface A2 fails, Device A and Device B perform an active/standby switchover. After the switchover is complete, Device B (active device) advertises link cost 1 based on OSPF configuration. Device A (standby device) advertises link cost 65500 modified by the hot backup system. Both inbound and outbound traffic are forwarded through Device B.

Figure 18 OSPF and hot backup system association

 

If you configure this feature, the active device advertises the original link costs for a routing protocol, and the standby device advertises one of the following link costs:

·     Absolute cost—The device advertises an absolute link cost for the routing protocol.

·     Calculated cost—The device advertises the original link cost plus the configured increment cost for the specified routing protocol.

The feature takes effect on only the standby device.

Associating the hot backup system with VLANs

You can enable the hot backup system to monitor VLANs or interfaces to associate the statuses of uplink and downlink interfaces. When one interface fails, the other interface will fail to forward packets, and both inbound and outbound traffic can be switched to the new active device for symmetric forwarding.

Through monitoring VLANs and interfaces, the hot backup system can ensure status consistency of monitored objects, so that traffic forwarding is enabled or disabled for both of them.

Figure 19 illustrates VLAN association with the transparent hot backup system.

·     As shown in the left, on Device A (active device), the hot backup system sets the state of VLAN 10 to Active. On Device B (secondary device), the hot backup system sets the state of VLAN 10 to Inactive. Both inbound and outbound traffic are forwarded through Device A.

·     As shown in the right, when Port A2 fails, Device A and Device B perform an active/standby switchover. After that, on Device B (active device), the hot backup system sets the state of VLAN 10 to Active. On Device A (secondary device), the hot backup system sets the state of VLAN 10 to Inactive. Device A cannot forward traffic. Both inbound and outbound traffic are forwarded through Device B.

Figure 19 VLAN and hot backup system association

 

Asymmetric traffic forwarding

As shown in Figure 20, in the hot backup system in dual-active mode, the asymmetric traffic forwarding issue might occur. The request and response packets of the same flow are forwarded to different devices (Device A and Device B) in the hot backup system.

Figure 20 Asymmetric traffic forwarding

 

In the network where asymmetric traffic forwarding exists, the hot backup system adopts the following processing mechanisms according to different service modules:

·     For the modules (such as security policies and NAT) that do not require processing content above Layer 4 in packets, the hot backup system backs up session entries to the peer device in real-time. This can ensure that the response packets can be correctly processed by the peer device.

·     For the modules (DPI services such as IPS and NBAR) that require processing content above Layer 4 in packets, the hot backup system backs up session entries to the peer device in real-time. In addition, it synchronizes request packet information to the peer device. This can ensure that the response packets can be correctly processed by the peer device.

Traffic switchover upon failure recovery

After an active/standby switchover occurs, if the original active device recovers, traffic will not be switched back by default. Perform this task to enable traffic switchover to the original active device upon failure recovery. You can set a delay timer to ensure smooth service switchover.

Set an appropriate delay timer based on the network scale to implement smooth traffic switchover upon completion of route convergence.

In dual-active hot backup mode, you must enable this feature to ensure that both devices can operate after the failure is recovered.

In active/standby hot backup mode, you can enable this feature to ensure that a dedicated device can still act as the active device immediately after failure recovery.

Configuring service features in the hot backup system

NAT in the hot backup system

For NAT to operate correctly in the hot backup system associated with VRRP, you must associate NAT features with the VRRP groups. For example, when you use dynamic NAT, static NAT, NAT server, or NAT444, you must associate the feature with the VRRP groups.

NAT features have similar mechanisms, and the operating mode of the hot backup system does not change the IP address translation process. This section uses dynamic NAT in the hot backup system in active/standby mode to explain how NAT works in the hot backup system.

Background

When receiving an ARP request with a target IP address that belongs to the subnet of the IP address of a NAT interface, a NAT device replies with the MAC address of the NAT interface.

As shown in Figure 21, dynamic NAT is configured for the hot backup system that is operating in active/standby mode. If dynamic NAT is not associated with any VRRP group, the devices process the traffic as follows when the host accesses the Internet:

1.     When receiving the packets sent by the host, Device A translates the source IP address into a public IP address in the NAT address group and forwards the packets to the router. In this example, the public IP address is in the same subnet as the virtual IP address of uplink VRRP group 1.

2.     The router receives the return packets and broadcasts an ARP request for the destination public IP address.

3.     Device A and Device B receive the ARP request and reply with the MAC address of their respective uplink interface because they have the same NAT address group configuration.

4.     The router might send the return packets to the uplink interface of Device A or Device B, which affects service continuity.

For the router to learn the virtual MAC address of the uplink VRRP group, you must associate NAT features with the VRRP group.

Figure 21 NAT not associated with a VRRP group

 

Traffic forwarding process

The master in a VRRP group relies with the virtual MAC address of the VRRP group to an ARP request if the following requirements are met:

·     NAT features are associated with the VRRP group.

·     The target IP address belongs to the subnet that contains the IP address of a NAT interface.

As shown in Figure 22, dynamic NAT is configured for the hot backup system that is operating in active/standby mode. If NAT is associated with the uplink VRRP group, the devices process the traffic as follows when the host accesses the Internet:

1.     When receiving the packets sent by the host, Device A translates the source IP address into a public IP address in the NAT address group and forwards the packets to the router. In this example, the public IP address is in the same subnet as the virtual IP address of uplink VRRP group 1.

2.     The router receives the return packets and broadcasts an ARP request for the destination public IP address.

3.     Device A and Device B receive the ARP request, and Device A (master) replies with the virtual MAC addresses of the uplink VRRP group.

4.     Router A sends the return packets to Device A.

Figure 22 NAT in the hot backup system

 

Hot backup system support for SSL VPN

The RBM channels are used to back up SSL VPN data, including user data, entries, and configuration.

The hot backup system supports SSL VPN only when it is operating in active/standby mode and collaborating with VRRP groups.

Hot backup system support for DPI services

When you use DPI services in the hot backup system operating in dual-active mode, you must enable DPI support for the hot backup system if asymmetric-path traffic exists. If you do not enable this feature, DPI services might fail to correctly identify and process packets.

Hot backup system support for contexts

You can configure the hot backup system only on the default context. The configuration will be issued to all non-default contexts.

To ensure configuration and service entry consistency, all non-default contexts use the RBM channels created for the default context to back up configuration and service entries and transmit service traffic.

All non-default contexts use the keepalive detection and configuration consistency check mechanisms of the default context. When an active/standby switchover occurs on any context, the other contexts will perform an active/standby switchover accordingly.

Hot backup system support for vSystems

You can configure the hot backup system only on the default vSystem. The configuration will be issued to all non-default vSystems.

To ensure configuration and service entry consistency, all non-default vSystems use the RBM channels created for the default vSystem to back up configuration and service entries and transmit service traffic.

All non-default vSystems use the keepalive detection and configuration consistency check mechanisms of the default vSystem. When an active/standby switchover occurs on any vSystem, the other vSystems will perform an active/standby switchover accordingly.

Restrictions and guidelines for the hot backup system

The hot backup system can contain a maximum of two devices with the same hardware and software settings.

To ensure that the traffic size is within the processing capability of one device upon failure of the other device, make sure the throughput of each device does not exceed 50% of its capability.

Application scenarios

Hot backup system in active/standby mode in collaboration with VRRP

As shown in Figure 23, set up the hot backup system at the border between the Internet and the internal network of an enterprise to ensure service continuity.

·     Configure the hot backup system to collaborate with VRRP.

·     Configure the hot backup system to operate in active/standby mode.

·     Configure Device A and Device B as the primary device and the secondary device, respectively.

Figure 23 Network diagram

Hot backup system in dual-active mode in collaboration with VRRP

As shown in Figure 24, set up the hot backup system at the border between the Internet and the internal network of an enterprise to ensure service continuity.

·     Configure the hot backup system to collaborate with VRRP.

·     Configure the hot backup system to operate in dual-active mode.

·     Configure Device A and Device B to load share traffic.

Figure 24 Network diagram

 

Hot backup system in active/standby mode in collaboration with a routing protocol

As shown in Figure 25, set up the hot backup system at the border between the Internet and the internal network of an enterprise to ensure service continuity.

·     Configure the hot backup system to collaborate with OSPF.

·     Configure the hot backup system to operate in active/standby mode.

·     Configure Device A and Device B as the primary device and the secondary device, respectively.

·     Associate the hot backup system with Track.

Figure 25 Network diagram

 

Hot backup system in dual-active mode in collaboration with a routing protocol

As shown in Figure 26, set up the hot backup system at the border between the Internet and the internal network of an enterprise to ensure service continuity.

·     Configure the hot backup system to collaborate with OSPF.

·     Configure the hot backup system to operate in dual-active mode.

·     Configure Device A and Device B to load share traffic.

·     Associate the hot backup system with Track.

Figure 26 Network diagram

 

Transparent in-path hot backup system in active/standby mode

As shown in Figure 27, set up a transparent in-path hot backup system at the border between the Internet and the internal network of an enterprise to ensure service continuity.

·     Configure the hot backup system to operate in active/standby mode.

·     Connect Switch A and Switch B to Layer 2 interfaces of the hot backup system.

·     Configure Device A and Device B as the primary device and the secondary device, respectively.

·     Configure the hot backup system to monitor the VLAN status.

Figure 27 Network diagram

 

Transparent in-path hot backup system in dual-active mode

As shown in Figure 28, set up a transparent in-path hot backup system at the border between the Internet and the internal network of an enterprise to ensure service continuity.

·     Configure the hot backup system to operate in dual-active mode.

·     Connect Router A and Router B to Layer 2 interfaces of the hot backup system.

·     Configure Device A and Device B to load share traffic.

·     Configure the hot backup system to monitor the VLAN status.

Figure 28 Network diagram

 

  • Cloud & AI
  • InterConnect
  • Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网