Hot backup is a device-level HA solution. It enables two devices to back up each other dynamically to ensure user service continuity upon failure of one of the devices.

Remote Backup Management (RBM) uses H3C proprietary RBM to manage multiple VRRP groups or adjust the link costs for routing protocols on two member devices to ensure that the devices have consistent roles and states. The RBM system can synchronize important configuration and service entries between the devices to ensure service continuity. Two devices must have the same software and hardware environments to join an RBM system.

Application scenario

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.

The RBM system is not used on traditional network devices such as switches and routers as they require only Layer 2 redundancy and route backup 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, RBM is used to synchronize service entries and configuration between the devices through a dedicated channel.

Figure 1 RBM network model

Basic hot backup concepts

Basic hot backup concepts are as follows:

· Primary and secondary roles—In the control plane, the primary and secondary roles are assigned to the two devices in an RBM system to control the configuration synchronization between the devices. After the control channel is set up, you can configure the settings for which RBM supports synchronization only on the primary device. You cannot configure those settings on the secondary device.

Each RBM member device adds a prefix to the view prompt to identify its RBM 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.

· 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. When the active device fails, the standby device takes over the active role to ensure service continuity.

· RBM channels—Transmit status information, important configuration, and service entries between the RBM members.

· Hot backup modes—Include active/standby mode, mirroring mode, and dual-active mode. In active/standby mode, the active device processes all services. In mirroring mode, the two devices use the same interface IP address, and only the active device processes all services. In dual-active mode, both devices process services to increase the capability of the RBM system and load share traffic.

· RBM packets—RBM packets transmitted through TCP over the RBM channels between the RBM members.

Operating modes of hot backup

Hot backup supports the active/standby, mirroring, 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 2. 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 2 Active/standby mode of hot backup

Mirroring mode

The mirroring mode is a special active/standby mode, and its deployment is the same as that for the active/standby mode. In mirroring mode, the interfaces on the two devices (except the mirroring mode management interface and RBM channel interface) use the same IP address, and typically the active device processes services, and the other device stands by. When an interface or link on the active device fails or when the active device fails, the standby device becomes active to process services.

This networking environment requires associating RBM with Track. Without RBM and Track collaboration, active/standby switchover cannot be performed.

Dual-active mode

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

Figure 3 Dual-active mode of hot backup

Active device election

As shown in Figure 4, the priority order of active device election conditions from highest to lowest is as follows: Link status, context status, health value, service module count, and hot backup operating mode.

Figure 4 Active device election

‌

The election process is as follows:

1. ‍The hot backup member devices check the link status of their service interfaces. To monitor the link status of service interfaces, use the track, track vlan, or track interface command. The election rules are as follows:

¡ If all service interfaces on one member device are up and down service interfaces exist on the other member device, the former will be elected as the active device, and the latter will be the standby device.

¡ If all service interfaces are up on both member devices, the member devices proceed to the next step.

¡ If both member devices have down service interfaces, the member devices proceed to the next step.

2. The member devices check the status of non-default contexts with the same ID. The member device with more active contexts becomes the active device, and the other member device becomes the standby device.

3. If the member devices have the same number of active contexts, the member device with the smaller health value becomes the active device, and the other member device becomes the standby device. To view the health value of a device, use the display system health command.

4. If the member devices have the same health value, the member device with more service modules becomes the active device, and the other member device becomes the standby device.

5. If the member devices have the same number of service modules, the state of a member device is determined based on the hot backup operating mode:

¡ In dual-active or mirroring mode, both member devices become active.

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

If the hot backup roles are automatically assigned, the device with the smaller IP address for the control channel will be elected as the primary device, and that device is the active device.

RBM data synchronization

RBM packets

RBM packets include the following:

· Keepalive packets—Transmitted periodically between the RBM members for peer availability detection.

· Control packets—Control active/standby switchovers based on the running status.

· Backup packets—Back up configuration and service entries between the RBM members.

· Configuration consistency check packets—Check whether the RBM members have consistent configuration.

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

RBM channels

RBM transmits RBM status, important configuration, and service entries between the RBM members through the following channels:

· Control channel—Transmits data by using packets, including RBM heartbeat packets and status packets, configuration consistency check packets, and packets used for configuration synchronization.

· Data channel—Transmits backup packets and packets that require transparent transmission. The data channel supports Layer 2 packet transmission mode.

The control channel uses the keepalive mechanism of TCP for reachability detection. Each member device periodically sends RBM keepalive packets to the RBM peer over the RBM control channel. If a device has not received any responses from the peer when the maximum number of RBM keepalive attempts is reached, the RBM control channel is disconnected.

Service entry backup

RBM backs up the service entries generated on the active device to the standby device to prevent service interruption when an active/standby switchover occurs.

Security devices generate a session entry for each dynamic connection. In the RBM 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.

RBM can perform hot backup for the following service entries:

· Entries created for IPsec tunnels.

· Entries created for DNS.

· NAT port blocks.

· AFT port blocks.

· Session entries.

· Session relation entries.

· Entries generated by security service modules.

Support for the service entries listed above varies by device model.

Configuration backup

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

· When both devices are operating correctly, the primary device synchronizes configuration to the secondary device. The configuration on the secondary device is overwritten. As a best practice to ensure correct operation of the RBM system, enable configuration backup on the primary device.

· When one of the devices reboots, the device that completes reboot obtains configuration from the device that is not rebooted. The configuration on the rebooted device is overwritten.

RBM supports both automatic backup and manual backup.

This section lists all service modules and corresponding commands that support configuration backup in RBM. Support for these services and commands depends on the device model.

The hot backup system in active/standby, mirroring, and dual-active modes can perform configuration backup for the following services:

Table 1 Service modules for which the hot backup system in active/standby, mirroring, and dual-active modes can perform configuration backup

Module	Support	Remarks
RBAC	Partially supported	Only the following commands can be backed up: · role feature-group. · feature. · vpn-instance policy deny. · permit vpn-instance.
Interface management	Partially supported	All commands except the shutdown command in interface view can be backed up.
VLAN	All supported	N/A
IPoE	All supported	N/A
DNS	Partially supported	DDNS commands cannot be backed up.
NAT	All supported	N/A
AFT	All supported	N/A
VPN instance	All supported	N/A
ACL	Partially supported	All commands except the acl copy command can be backed up.
Time range	All supported	N/A
Security zone	All supported	N/A
AAA	Partially supported	All commands executed by local users for configuring network access user attributes can be backed up. The following RADIUS commands can be backed up: · radius dynamic-author server. · port. · client. · attribute translate. · attribute convert (RADIUS DAE server view). · attribute reject (RADIUS DAE server view). The following RADIUS server commands can be backed up: · radius-server client. · radius-server activate. · radius-server deactivate. · radius-server ldap-scheme. · radius-server eap-profile. The HWTACACS commands except the hwtacacs nas-ip and nas-ip (HWTACACS scheme view) commands can be backed up.
Password control	All supported	N/A
IPsec	Partially supported	Only configuration of IKEv1, IKEv2, and IPsec security policy features can be backed up. Configuration of other IPsec features cannot be backed up.
SSL VPN	All supported	N/A
ASPF	All supported	N/A
APR	All supported	N/A
Session management	All supported	N/A
Connection limit	All supported	N/A
Object group	All supported	N/A
Security policy	All supported	N/A
Attack detection and prevention	All supported	N/A
Cloud platform connection	All supported	N/A
NQA	Partially supported	The nqa agent enable command in system view can be backed up. All commands in NQA template view, except for the following commands, can be backed up: · destination ipv6. · destination ip. · next-hop ip. · next-hop ipv6. · proxy-url. · source ip. · source ipv6. · source port. · url.
Fast log output	All supported	N/A
Flow log	All supported	N/A
Information center	Partially supported	The info-center loghost source command cannot be backed up.
DPI engine	All supported	N/A
IPS	All supported	N/A
URL filtering	All supported	N/A
Data filtering	All supported	N/A
File filtering	All supported	N/A
Anti-virus	All supported	N/A
Data analysis center	All supported	N/A
Proxy policy	All supported	N/A
WAF	All supported	N/A
APT defense	All supported	N/A
Bandwidth management	All supported	N/A
Application audit and management	All supported	N/A
NetShare control	All supported	N/A
Load balancing	All supported	N/A
Global load balancing	Partially supported	The loadbalance default-syncgroup member command cannot be backed up.

‌

In mirroring mode, the configuration can be backed up for the following modules in addition to the preceding modules:

Table 2 Modules for which configuration backup can be performed only in mirroring mode

Module	Support	Remarks
Login management	Partially supported	The commands in user line view can be backed up.
Configuration file management	Partially supported	The command used to save configuration files can be backed up.
Device management	Partially supported	The following commands can be backed up: · clock datetime. · clock summer-time. · clock timezone.
MAC address table	Partially supported	The commands except the mac-address blackhole and mac-address static commands can be backed up.
VLAN termination	All supported	N/A
Layer 2 forwarding	Partially supported	The mac fast-forwarding check-vlan-id and bridge fast-forwarding check-vlan-id commands can be backed up.
ARP	Partially supported	All commands except the arp multiport command can be backed up.
IP address	Partially supported	Only the ip address command can be backed up.
DHCP	Partially supported	Common DHCP commands, DHCP server commands, and DHCP client commands can be backed up.
IP forwarding basics	All supported	N/A
Fast forwarding	Partially supported	All commands except the hardware fast-forwarding enable command can be backed up.
Multi-CPU packet distribution	All supported	N/A
IP performance optimization	Partially supported	IP packet-related commands, and the tcp mss and tcp auto-adjust-mss commands can be backed up.
IPv6 basics	Partially supported	The ipv6 address and ipv6 mtu commands and IPv6 neighbor discovery (ND) related commands can be backed up.
DHCPv6	Partially supported	Common DHCPv6 commands, DHCPv6 server commands, and DHCPv6 client commands can be backed up.
IPv6 fast forwarding	All supported	N/A
Tunneling	Partially supported	The interface tunnel number [ mode { gre [ ipv6 ] \| ipv4-ipv6 \| ipv6-ipv4 [ 6rd \| 6to4 \| auto-tunnel \| isatap ] \| mgre } ] command can be backed up.
GRE	Partially supported	The gre key and gre checksum commands can be backed up.
IP routing basics	All supported	N/A
Static routing	All supported	N/A
RIP	All supported	N/A
OSPF	All supported	N/A
BGP	All supported	N/A
IPv6 static routing	All supported	N/A
RIPng	All supported	N/A
OSPFv3	All supported	N/A
Routing policy	All supported	N/A
MPLS L3VPN	Partially supported	All commands except the commands in BGP view can be backed up.
QoS	All supported	N/A
AAA	Partially supported	All commands executed by local users for configuring device management user attributes can be backed up.
Keychain	All supported	N/A
PKI	Partially supported	Commands related to private keys, local certificates, CA certificates, CRL, and certificate filtering can be backed up.
SSH	Partially supported	The commands except the dsa local-key-pair create, rsa local-key-pair create, and ecc local-key-pair create commands can be backed up.
ARP attack protection	All supported	N/A
MFF	All supported	N/A
BFD	All supported	N/A
EVI	Partially supported	Only the evi arp-suppression enable command can be backed up.
VXLAN	Partially supported	Only the arp distributed-gateway dynamic-entry synchronize command can be backed up.

‌

Configuration consistency check

RBM verifies configuration consistency between the RBM 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.

Running status switchover

The hot backup role is determined based on configuration. The running status is determined based on RBM role election and can be switched over.

Running status switchover process

As shown in Figure 5, 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 RBM system has not set up.

Figure 5 RBM channels not established

As shown Figure 6, when the RBM channels are established and both devices are operating correctly, the RBM roles of the devices are determined based on configuration. In the data plane, the running status of the devices is consistent with their RBM 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 6 RBM in active/standby mode

As shown in Figure 7, 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 RBM roles of the devices do not change.

Figure 7 Uplink or downlink failure

As shown in Figure 8, the RBM 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 8 Device failure or restart

Running status switchover triggers

In the RBM 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 RBM system to ensure service continuity.

An active/standby switchover is triggered by disconnection of the RBM channel in one of the following conditions:

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

· The active device fails, and the standby device becomes active to process traffic.

· All MPUs on the active device fail, and the standby device becomes active to process traffic.

· All switching fabric modules on the active device fail, and the standby device becomes active to process traffic.

If the RBM channel is working correctly, an active/standby switchover is triggered by one of the following events

· Failure of the interfaces monitored by RBM on the active device. To configure interface monitoring, use the track, track vlan, and track interface commands.

If both member devices have monitored interface failure, the following rules apply:

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

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

· 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 active device is the primary device, and the standby device is the secondary 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 RBM system is operating in active/standby or dual-active mode. If no security service module is present on either member device, both member devices are standby and cannot process traffic.

· Shutdown of a non-default context on the active device with the same ID as a non-default context on the standby device.

This event will trigger active device election. If the member devices have the same number of active non-default contexts with the same ID during the election, the following rules apply:

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

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

If the member devices have different numbers of active non-default contexts with the same ID, the member device with more active contexts becomes the active device, and the other member device becomes the standby device. This rule applies in both active/standby and dual-active modes.

· Change of the active device's health value.

This event will trigger active device election. If the member devices have the same health value during the election, the following rules apply:

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

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

If the member devices have different health values, the member device with the smaller health value becomes the active device, and the other member device becomes the standby device. This rule applies in both active/standby and dual-active modes.

When an active/standby switchover occurs, RBM collaborates with other modules to direct traffic to the new active device.

· When working with VRRP, RBM places all VRRP groups on the failed device to backup state.

· When working with a routing protocol, RBM increases the link costs of routes on the failed device.

Associating RBM with VRRP

About RBM and VRRP association

You can use RBM 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 9 illustrates VRRP association with active/standby RBM.

· 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, RBM 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 9 VRRP and RBM association

‌

VRRP active/standby group

RBM 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 RBM 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 RBM roles. The initial state is master for the VRRP active group and is backup for the VRRP standby group.

VRRP master election in the RBM environment

After RBM is associated with VRRP, RBM determines the roles of the devices in the VRRP groups. As shown in Figure 9, 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 RBM 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, RBM 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 RBM with virtual IP addresses

About virtual IP addresses and RBM association

A cloud environment typically provides services for multiple tenants, and each tenant requires independent networks (IP addresses). If you use VRRP association with RBM, each VRRP group requires three IP addresses, which might result in a shortage of IP addresses in the cloud environment. In this case, use virtual IP address association with RBM to save IP addresses.

Virtual IP address association with RBM assigns virtual IP addresses (also known as floating IP addresses) to the service interfaces with the same ID on the RBM member devices. These virtual addresses on the service interfaces are associated with and managed by RBM. The active device uses the virtual IP address and virtual MAC address of a service interface to respond to ARP requests, while the standby device will not respond to ARP requests. This ensures that the upstream and downstream traffic can always be directed to the active device for processing.

You must associate RBM with track entries to monitor uplinks and downlinks. If you cannot do that, the RBM system cannot perform active/standby switchover.

Mechanism

As shown in Figure 10, traffic is sent from the internal network to the external network as follows:

1. When an internal host accesses the external network, the host first broadcasts an ARP request to learn the MAC address of the gateway at virtual IP address 10.1.1.1.

2. Upon receiving this ARP request, only the active device (Device A) responds with the virtual MAC address of the service interface to the host.

3. During the ARP learning process, the intermediate switch (Switch B) also learns the MAC address entry for the virtual MAC address that guides subsequent packet forwarding.

4. The host only receives the ARP response from the active device (Device A). The host then encapsulates packets by using the learned virtual MAC address and sends the packets to Device A.

5. Response packets from the external network is forwarded by following the same procedure.

Figure 10 Virtual IP addresses and RBM association

‌

Associating RBM with routing protocols

You can use RBM 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 RBM with Track to perform active/standby switchover upon link or interface failures.

Figure 11 illustrates OSPF association with active/standby RBM.

· 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 RBM 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 RBM system. Both inbound and outbound traffic are forwarded through Device B.

Figure 11 OSPF and RBM association

‌

Transparent in-path deployment of RBM

When you use this networking scheme, you can use the track vlan or track interface command to enable collaboration between uplink and downlink interfaces. The Track configuration ensures that a group of interfaces have the same status, and uplink and downlink traffic can be switched simultaneously between the member devices.

The following information uses the track vlan setting as an example to describe how interfaces collaborate:

· As shown in Figure 12, when both Device A (active) and Device B (standby) are operating correctly, tracked VLAN 10 is in active state on Device A and in inactive state on Device B. As a result, Device A forwards all traffic that traverses the RBM system.

· As shown in Figure 12, when downlink Port A2 of Device A fails, Device A and Device B switch their roles. Then, the RBM system places VLAN 10 in inactive state on Device A (standby) and in active state on Device B (active). As a result, Device B forwards all traffic that traverses the RBM system.

Figure 12 Transparent in-path deployment of RBM

How virtual MAC addresses work

A virtual MAC address is a unique MAC address generated by software programs rather than hardware to simulate the MAC address of a real device in the network. In specific scenarios (including hot standby in mirroring mode, RBM collaboration with VRRP, and RBM collaboration with virtual addresses), virtual MAC addresses are used. However, the way the virtual MAC addresses are used varies by scenario.

In the scenario of RBM collaboration with VRRP, configure VRRP groups to collaborate with RBM on the service interfaces of the RBM member devices. Each VRRP group generates a virtual MAC address and decides whether to use the real MAC address or the virtual MAC address for sending packets based on the configuration.

Figure 13 MAC address usage rules in the scenario of RBM collaboration with VRRP

Packet type	Default configuration	ip send-packet source-mac prefer virtual-mac command executed in system view	undo vrrp virtual-mac enable command executed in system view
The RBM active device receives ARP requests for the virtual IP and sends replies for the virtual IP.	The source MAC address for Ethernet encapsulation and the MAC address for ARP replies are both the virtual MAC address.	No impact	The source MAC address for Ethernet encapsulation and the MAC address for ARP replies are both the real MAC address.
The RBM active device actively sends gratuitous ARP requests for the virtual IP.	The source MAC address for Ethernet encapsulation and the MAC address for ARP announcements are both the virtual MAC address.	No impact	The source MAC address for Ethernet encapsulation and the MAC address for ARP announcements are both the real MAC address.
The RBM active device forwards IP packets.	The source MAC address for Ethernet encapsulation is the real MAC address.	The source MAC address for Ethernet encapsulation is the virtual MAC address.	No impact
The RBM active device sends IP packets locally.	The source address MAC for Ethernet encapsulation is the real MAC address.	If the source IP address is a virtual IP address, the source MAC address in Ethernet encapsulation is a virtual MAC address. If the source IP address is not a virtual IP address, the source MAC address in Ethernet encapsulation is a real MAC address.	No impact
The RBM standby device forwards IP packets.	The source MAC address for Ethernet encapsulation is the real MAC address.	The source MAC address for Ethernet encapsulation is the real MAC address.	No impact
The RBM standby device sends IP packets locally.	The source MAC address for Ethernet encapsulation is the real MAC address.	The source MAC address for Ethernet encapsulation is the real MAC address.	No impact

In the scenario of RBM collaboration with virtual addresses, after you configure a virtual IP (floating IP) address on the service interface of an RBM member device, the virtual MAC address on the device takes effect. The device then determines whether to use the real MAC address or the virtual MAC address for sending packets based on the configuration.

Figure 14 MAC address usage rules in the scenario of RBM collaboration with virtual addresses

Packet type	Default configuration	ip send-packet source-mac prefer virtual-mac command executed in system view
The RBM active device receives ARP requests for the virtual IP and sends replies for the virtual IP.	The source MAC address for Ethernet encapsulation and the MAC address for ARP replies are both the virtual MAC address.	No impact
The RBM active device actively sends gratuitous ARP requests for the virtual IP.	The source MAC address for Ethernet encapsulation and the MAC address for ARP announcements are both the virtual MAC address.	No impact
The RBM active device forwards IP packets.	The source MAC address for Ethernet encapsulation is the real MAC address.	The source MAC address for Ethernet encapsulation is the virtual MAC address.
The RBM active device sends IP packets locally.	The source MAC address for Ethernet encapsulation is the real MAC address.	If the source IP address is a virtual IP address, the source MAC address in Ethernet encapsulation is a virtual MAC address. If the source IP address is not a virtual IP address, the source MAC address in Ethernet encapsulation is a real MAC address.
The RBM standby device forwards IP packets.	The source MAC address for Ethernet encapsulation is the real MAC address.	The source MAC address for Ethernet encapsulation is the real MAC address.
The RBM standby device sends IP packets locally.	The source MAC address for Ethernet encapsulation is the real MAC address.	The source MAC address for Ethernet encapsulation is the real MAC address.

In the scenario of hot standby in mirroring mode, the virtual MAC addresses on the service interfaces of RBM member devices become active and they are used for sending packets.

Figure 15 MAC address usage rules in the scenario of hot standby in mirroring mode

Packet type	Default configuration
The RBM active device receives ARP requests for the virtual IP and sends replies for the virtual IP.	The source MAC address for Ethernet encapsulation and the MAC address for ARP replies are both the virtual MAC address.
The RBM active device actively sends gratuitous ARP requests for the virtual IP.	The source MAC address for Ethernet encapsulation and the MAC address for ARP announcements are both the virtual MAC address.
The RBM active device forwards IP packets.	The source MAC address for Ethernet encapsulation is the virtual MAC address.
The RBM active device sends IP packets locally.	The source MAC address for Ethernet encapsulation is the virtual MAC address.

In specific RBM scenarios (including RBM collaboration with VRRP and RBM collaboration with virtual addresses), the service interfaces of RBM member devices use virtual MAC addresses to send ARP replies. However, packets processed by the active device are encapsulated with the real interface MAC addresses, which might result in service issues. For example, when the upstream and downstream devices of RBM member devices use strict uRPF check, packets might be dropped to cause service interruption. In this case, the following solutions are available:

· Enable the RBM primary device to preferentially use virtual MAC addresses as the source MAC addresses of packets. Then, packets from the active device can be encapsulated with virtual MAC addresses.

· In the scenario of RBM collaboration with virtual addresses, you can also use the undo vrrp virtual-mac enable command to configure ARP packets to use the real MAC addresses to avoid service interruption. The two features are mutually exclusive.

For more information about the vrrp virtual-mac enable command, see VRRP commands in High Availability Command Reference.

Restrictions and guidelines: RBM-based hot backup configuration

Member device restrictions and guidelines

An RBM system can contain a maximum of two devices.

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.

For the features or signature libraries that require licenses, purchase separate licenses and activate them on the hot backup member devices.

Configuration synchronization

For the service modules for which RBM supports configuration synchronization, you need to configure relevant settings only on the primary device. For the service modules that do not support configuration synchronization, you need to configure relevant settings on all devices in the RBM system. For support of RBM for configuration synchronization of service modules, see "RBM data synchronization." The commands in RBM view do not support synchronization. You must configure them at both ends.

You must import resource files to both RBM member devices, such as public keys, ISP address library files, and signature library files.

Interface restrictions and guidelines

On each member device, you must assign the interfaces that transmit service traffic to security zones and configure security policies to enable inter-zone communication.

Do not use RBM in combination with the features that obtain IP addresses automatically, DHCP client for example. The interfaces on the RBM system must use static IP addresses.

If service interfaces work in Layer 2 mode, assign uplink and downlink service interfaces to the same VLAN.

If the control channel has been set up and automatic configuration backup is enabled, you cannot create virtual interfaces such as VLAN interfaces and subinterfaces on the secondary device. You can only configure the existing virtual interfaces on the secondary device. To create virtual interfaces on the secondary device, create them on the primary device, and the primary device will synchronize those interfaces to the secondary device.

If you use the track, track interface, and track vlan commands to monitor aggregate interfaces, the device only monitors the status of those aggregate interfaces. The related aggregation member ports are not monitored. If you use the track, track interface, and track vlan commands to monitor aggregation member ports, the device only monitors the status of those aggregation member ports. The related aggregate interfaces are not monitored.

If a device has both hot backup and Ethernet interfaces, use the hot backup interface for control and data channel setup to protect device security and stability. Do not use a hot backup interface as a service interface.

RBM channel restrictions and guidelines

The RBM channels are set up over the keepalive link that is a direct link or traverses intermediate devices.

The RBM channels transmit multiple types of packets, and the traffic size increases with the service traffic size. To provide enough bandwidth for the RBM channels, follow these guidelines when you set up the RBM channels:

· For symmetric forwarding, use N + 3 10-G interfaces for RBM channel setup, where N is the number of service modules.

· For asymmetric forwarding, make sure the bandwidth of the RBM channels equals the total bandwidth of uplink and downlink traffic if DPI features are enabled.

When you select interfaces for RBM channel and data channel setup, follow these restrictions and guidelines:

· Use physical interfaces or aggregate interfaces. Do not use subinterfaces or aggregation member ports.

· If an interface is assigned to a non-default context in shared or exclusive mode, you cannot use the interface as an RBM channel interface. Information in the non-default context can be synchronized through the RBM channel of the default context.

· If an interface is assigned to a non-default vSystem in shared or exclusive mode, you cannot use the interface as an RBM channel interface. Information in the non-default vSystem can be synchronized through the RBM channel of the default vSystem.

· As a best practice, use the same physical or logical link to convey the RBM data and control channels. Use the default MTU on the interfaces used for setting up the link.

When configuration backup is in progress, do not perform active/standby switchovers, remove or install service modules, or change the configuration. To view the backup progress, execute the display remote-backup-group status command.

If the RBM system performs asymmetric forwarding, use the session aging-time state fin command to set the aging time for TCP sessions in FIN_WAIT state to 15 seconds. This configuration speeds up session entry aging when TCP connections disconnect and thus saves system resources. For more information about the session aging-time state command, see session management commands in Security Command Reference.

RBM deployment restrictions and guidelines

When you deploy RBM, follow the restrictions and guidelines for the network scheme you have chosen.

Routed in-path RBM deployment between upstream and downstream routers

You can use either active/standby or dual-active mode.

If you use RBM with a routing protocol, use the adjust-cost enable command to enable RBM to adjust the link costs for the routing protocol. In addition, associate RBM with track entries to monitor the status of uplink and downlink interfaces.

If you use RBM with static routes, use the track interface command to monitor uplink and downlink Layer 3 Ethernet interfaces.

Routed in-path RBM deployment between upstream and downstream switches

This network environment applies to active/standby, mirroring, and dual-active modes.

In active/standby mode, you must associate RBM with VRRP or virtual IP addresses. In dual-active mode, you must associate RBM with VRRP. In mirroring mode, you can use the feature directly.

In collaboration with virtual IP addresses, you must use the track command to enable RBM to monitor the status of uplink and downlink Layer 3 Ethernet interfaces.

Transparent in-path RBM deployment between upstream and downstream routers

You can use either active/standby or dual-active mode.

You must use the track interface command to enable RBM to monitor the status of uplink and downlink Layer 2 Ethernet interfaces.

Transparent in-path RBM deployment between upstream and downstream switches

You can use only active/standby mode.

You must use the track vlan command to enable RBM to monitor the status of uplink and downlink VLANs.

Feature compatibility restrictions

Compatibility with virtual systems

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

When an active/standby switchover occurs on any context, the other contexts will perform an active/standby switchover accordingly. As a best practice, place the active member devices of all contexts on the same device.

If you use RBM feature on a non-default context, you must assign service interfaces to the non-default context in shared mode. Because RBM compares only the states of the non-default contexts with the same number on the two ends, to use RBM on non-default contexts, you must use non-default contexts with the same number on both devices.

You cannot use virtual IP addresses on non-default contexts.

Compatibility with NAT

When you use NAT on an RBM system, follow these restrictions:

· RBM does not support detecting reachability of NAT address group members or Easy IP.

· NAT address groups cannot contain the IP addresses of any interfaces on the RBM member devices. If you violate this restriction, both RBM member devices will respond to the ARP packets that an upstream device sends to request the IP addresses in the NAT address groups. As a result, ARP conflicts occur.

· The source or destination IP address in a NAT policy does not belong to the interface used for setting up the RBM channels. Violation of this restriction causes keepalive link faults.

· If you cannot ensure that a flow identified by a five-tuple is processed by the same device in one direction, you must use the nat remote-backup port-alloc { primary | secondary } command to specify NAT port ranges for both RBM member devices.

When you use NAT on an RBM system operating in dual-active mode, follow these restrictions:

· NAT address groups do not support EIM.

· If NAT operates in PAT mode, you must execute the following commands on the NAT group members, one command on one device:

¡ nat remote-backup port-alloc primary

¡ nat remote-backup port-alloc secondary

These commands divide an address group into two halves to avoid conflicts.

· If NAT operates in NO-PAT mode, you must configure two address groups to avoid resource assignment conflicts.

Compatibility with AFT

If you enable AFT in the network with RBM and VRRP association, make sure the AFT policy does not contain HA channel interface IP addresses. This prevents heartbeat packets from being translated by AFT, resulting in communication anomaly through the heartbeat link.

Compatibility with other protocols

Make sure the control and data packets of a multi-channel protocol such as FTP or SIP are processed by the same RBM member device.

In the RBM environment, to process traffic based on the SCTP protocol, make sure both the outbound and inbound packets of the same flow are processed by the same device.

Compatibility with configuration rollback

After you use the configuration replace file command to roll back the configuration, execute the configuration manual-sync command on the primary device to manually back up its configuration to the secondary device. For more information about configuration rollback, see configuration file management in Fundamentals Configuration Guide.

Hardware environment consistency

Before you configure RBM, verify that the following hardware settings are the same on the devices to be assigned to an RBM system:

· Device model.

· Location, number, and type of MPUs.

· Location, number, and type of service modules.

· Location, number, and type of switching fabric modules.

· Location, number, and type of interface modules.

· Number and type of management interfaces of active and standby devices or mirroring-mode devices, service interfaces, and interfaces for setting up the RBM channels. Do not use one interface for multiple purposes.

· Location, number, and type of disks. A device not with disks installed has small log storage and do not support some types of logs or reports.

Software environment consistency

Before you configure RBM, verify that the following software settings are the same on the devices to be assigned to an RBM system:

· Software environment and version, including boot packages, system packages, feature packages, and patches.

· System time.

· Licensed signature libraries and features, such as signature library types, signature library version, validation time, and number of licensed resources.

· Resource files, such as public keys and ISP database files.

· Interface numbers.

· Type, speed, and number of the interfaces for setting up the RBM channels. As a best practice, use aggregate interfaces.

· Aggregate interface numbers and aggregation member port numbers.

· Security zone configuration on the interfaces at the same location.

· Multi-CPU packet distribution policy (configurable with the forwarding policy command).

Network interconnection restrictions

Configure security policies for the RBM members to correctly exchange the packets required in forwarding over the RBM channels, routing protocol packets for example. As a best practice, make sure only those packets are transmitted between the security zone that accommodates service interfaces and the Local security zone.

The device by default permits the RBM packets transmitted over the RBM channels. You do not need to configure security policies for the RBM packets.

Configure a feature prior to RBM deployment if RBM cannot back up configuration of the feature. For more information about the features that can be backed up by RBM, see "RBM data synchronization."

Restrictions and guidelines for the mirroring mode

· Create a mirroring mode hot backup system by using two devices in their initial state (without hot backup mode configured). If the devices are in operation, do not switch directly from non-mirroring to mirroring mode. Instead, reset them to their initial state before switching to avoid potential service exceptions.

· For hot backup in mirroring mode, interfaces with the same number on both devices use the same IP address, except for the mirroring mode management interface and RBM channel interface.

· For IPv6 hot backup in mirroring mode, interfaces with the same number on both devices use the same IPv6 address and IPv6 link-local address. Manually configure the IPv6 link-local address and do not use automatically generated address to avoid inconsistencies.

· If mirroring mode is enabled, the configurations that can be backed up between the two devices increase. For example, interface IP address configuration commands, which are not backed up in non-mirroring mode, will be backed up after you enable the mirroring mode. For information about service configuration backup supported in mirroring mode, see "Configuration backup."

· With mirroring mode enabled, the device can adjust the state of service interfaces based on their running roles. Service interfaces on the primary device receive and send packets, while those on the standby device can only send and receive Layer 3 and lower-layer packets, such as LLDP and LACP packets.

· In mirroring mode, RBM cannot collaborate with VRRP or virtual addresses. If VRRP or virtual addresses are configured on a device, you cannot enable the mirroring mode. You cannot configure VRRP or virtual addresses on the device after enabling the mirroring mode.

· Do not execute the track interface command in mirroring mode.

· When you quit mirroring mode, you must quit mirroring mode of the standby device and then quit mirroring mode of the active device.

· Only static routes are supported between the device and upstream/downstream devices. Dynamic routing protocols or RIR are not supported. For example, in mirroring mode, the standby device does not send or receive routing protocol packets, so it cannot establish a dynamic routing neighbor relationship with upstream/downstream devices. During an active/standby switchover, the new primary device must renegotiate routing information, resulting in longer service interruptions. Therefore, mirroring mode hot backup is not supported when the service interfaces of both devices operate at Layer 3, connect to routers in the uplink or downlink direction, and run dynamic routing protocols with those routers.

Hot backup configuration flow

Figure 16 shows the configuration flow for hot backup.

Figure 16 Hot backup configuration flow chart

‌

Hot backup tasks at a glance

Active/Standby-mode hot backup tasks at a glance

1. Configuring the active/standby hot backup mode

2. Configuring the hot backup role

3. Configuring RBM data synchronization settings

a. Configuring the RBM control channel

b. Configuring the RBM data channel

c. Enabling RBM service entry hot backup

d. (Optional.) Enabling automatic synchronization for running data

e. Configuring RBM configuration synchronization

f. (Optional.) Enabling static route synchronization by RBM

4. (Optional.) Enabling traffic switchover upon failure recovery

5. Configuring RBM associations

Choose one of the following tasks:

¡ Associating RBM with VRRP

¡ Associating RBM with virtual IP addresses

¡ Associating RBM with routing protocols

¡ Configuring RBM transparent in-path deployment

Mirroring-mode hot backup tasks at a glance

1. Configuring the mirroring hot backup mode

2. Configuring the hot backup role

3. Configuring RBM data synchronization settings

a. Configuring the RBM control channel

b. Configuring the RBM data channel

c. Enabling RBM service entry hot backup

d. (Optional.) Enabling automatic synchronization for running data

e. Configuring RBM configuration synchronization

f. Enabling static route synchronization by RBM

4. Configuring the management interface for the mirroring mode

5. (Optional.) Enabling traffic switchover upon failure recovery

Dual-active-mode hot backup tasks at a glance

1. Configuring the dual-active hot backup mode

2. Configuring the hot backup role

3. Configuring RBM data synchronization settings

a. Configuring the RBM control channel

b. Configuring the RBM data channel

c. Enabling RBM service entry hot backup

d. (Optional.) Enabling automatic synchronization for running data

e. Configuring RBM configuration synchronization

4. Enabling traffic switchover upon failure recovery

5. Configuring RBM associations

Choose one of the following tasks:

¡ Associating RBM with VRRP

¡ Associating RBM with routing protocols

¡ Configuring RBM transparent in-path deployment

Advanced hot backup tasks at a glance

1. (Optional.) Associating RBM with Track

3. (Optional.) Performing an active/standby switchover

4. (Optional.) Specifying the peer device as the default operating device in a VRRP group

5. (Optional.) Enabling transparent service traffic transmission between the RBM members

6. (Optional.) Configuring MAD

7. (Optional.) Enabling RBM non-stop-routing (NSR)

8. (Optional.) Enabling interfaces to preferentially use the virtual MAC addresses as the source MAC addresses when sending packets

10. (Optional.) Bulk backing up local session entries to the hot backup peer

11. (Optional.) Configuring the interface recovery wait timer

12. (Optional.) Configuring service features on the RBM system

Configuring the active/standby hot backup mode

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Configure the hot backup mode for the device as active/standby.

undo backup-mode

By default, the hot backup mode for the device is active/standby.

Configuring the mirroring hot backup mode

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Configure the hot backup mode for the device as mirroring.

backup-mode mirror-mode

By default, the hot backup mode for the device is active/standby.

Configuring the dual-active hot backup mode

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Configure the hot backup mode for the device as dual-active.

backup-mode dual-active

By default, the hot backup mode for the device is active/standby.

Configuring the hot backup role

About this task

RBM 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 hot backup roles can only be manually assigned to devices.

Configuration can be synchronized only from the primary device to the secondary device. The configuration on the secondary device is overwritten to ensure consistency between the two devices.

The RBM system supports both manual configuration and auto selection for the device role.

· Manual configuration—Manually assigns the RBM roles, primary and secondary, to the member devices through the command line. The RBM role of a device does not change unless you manually change it from the command line. This mode applies to the network where a dedicated management Ethernet interface is used for device management. This mode can be used in only the RBM active/standby and dual-active modes, and cannot be used in mirroring mode.

· Auto selection—Assigns the hot backup roles to the member devices according to their operating mode. For each member device, the hot backup role is consistent with the operating mode. The active device is the primary device, and the standby device is the secondary device. This mode applies to the network where service interfaces are reused for device management. This mode can be used in only the hot backup active/standby and mirroring modes, and cannot be used in dual-active mode.

After configuring the RBM role for the device, the system adds a prefix before the view prompt in the command line. This helps you identify the primary and secondary device roles.

In the active/standby or dual-active mode, the device roles are identified as follows:

· Primary device—The system adds the RBM_P prefix before the view prompt in the command line, for example, RBM_P<Sysname>.

· Secondary device—The system adds the RBM_S prefix before the view prompt in the command line, for example, RBM_S<Sysname>.

In the mirroring mode, the device roles are identified as follows:

· Primary device—The system adds the RBM_MIRROR_P prefix before the view prompt in the command line, for example, RBM_MIRROR_P<Sysname>.

· Secondary device—The system adds the RBM_MIRROR_S prefix before the view prompt in the command line, for example, RBM_MIRROR_S<Sysname>.

Before successfully establishing an RBM channel, the system takes the primary role for the local device regardless of the device role configuration. It adds the RBM_P or RBM_MIRROR_P prefix to the view prompt in the command line. After successfully establishing an RBM channel, the system displays the associated prefix for the view prompt in the command line based on the device role configuration.

Restrictions and guidelines

You must assign the primary and secondary roles to the two member devices in the RBM system, respectively.

As a best practice to ensure correct operation of the RBM system, enable configuration backup on the primary device.

In a mirroring-mode hot backup network or a network where RBM member devices use service interfaces as the management interfaces, if the running status of the devices switches, the administrator can only remotely log in to the current active device for management. If the active device is the secondary device, the configuration changes made by the administrator on the current device will not be synchronized to the standby device, resulting in inconsistent configuration between the primary and secondary devices. To resolve this issue, use automatic hot backup role election.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Configuring the hot backup role for the device

¡ Configure the hot backup role for the device in active/standby mode.

device-role { auto | primary | secondary }

By default, the hot backup role is not configured.

¡ Configure the hot backup role for the device in mirroring mode.

device-role auto

By default, the hot backup role is not configured.

¡ Configure the hot backup role for the device in dual-active mode.

device-role { primary | secondary }

By default, the hot backup role is not configured.

Configuring the RBM control channel

About this task

RBM 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.

If the port number is configured on the server, the port provides services for the client. If the port number is configured on the client, the port serves as the destination port to establish TCP connection to the server. The source port is randomly generated on the client.

Restrictions and guidelines

You can specify only one peer IP address with the same port number on the RBM member devices. The specified port cannot be the same as the TCP listening port in use.

The local and remote IP addresses of the control channel cannot be identical.

You can set up an IPv4 control channel or IPv6 control channel, but not both.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Set up an RBM control channel. Choose one of the following options:

¡ Set up an IPv4 control channel.

- Configure the peer IPv4 address for setting up the RBM control channel.

remote-ip ipv4-address [ port port-number ]

By default, the peer IPv4 address is not configured.

- Configure the local IPv4 address for setting up the RBM control channel.

local-ip ipv4-address

By default, the local IPv4 address is not configured.

¡ Set up an IPv6 control channel.

- Configure the peer IPv6 address for setting up the RBM control channel.

remote-ipv6 ipv6-address [ port port-number ]

By default, the peer IPv6 address is not configured.

- Configure the local IPv6 address for setting up the RBM control channel.

local-ipv6 ipv6-address

By default, the local IPv6 address is not configured.

4. Set the interval for sending RBM keepalive packets.

keepalive interval interval

By default, the device sends RBM keepalive packets at one-second intervals.

5. Set the maximum number of RBM keepalive attempts.

keepalive count counts

By default, the maximum number of RBM keepalive attempts is 10.

6. (Optional.) Enable CRC for RBM bulk data backup.

crc enable

By default, CRC is disabled for RBM bulk data backup.

Configuring the RBM data channel

About this task

The data channel is connected over the heartbeat link. The heartbeat link can be either a direct link or a link with intermediate devices. The data channel supports transmitting packets across Layer 2 switches, but does not support transmitting packets across Layer 3 devices.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Configure an RBM data channel.

data-channel interface interface-type interface-number

By default, no RBM data channel is configured.

Enabling RBM service entry hot backup

About this task

RBM service entry hot backup enables the active device to back up service entries to the standby device in real time.

Enable HTTP and DNS backup if asymmetric-path traffic traverses the RBM system. HTTP and DNS backup ensures that a flow and its return traffic are processed correctly on the RBM members.

If hot backup active/standby or mirroring mode is used or only symmetric-path traffic traverses the RBM system, disabling HTTP and DNS backup can improve performance of the RBM members at the expense of delayed data synchronization. When you disable HTTP and DNS backup, make sure you are fully aware of the impact on the network. A device removes a DNS or HTTP connection if packet exchange is inactive. When a switchover interrupts a connection, the DNS or HTTP client re-initiates the connection immediately, which has little impact on user services.

Restrictions and guidelines

When the RBM system is operating stably and is processing traffic, do not execute the reset session table command. If you execute the command, traffic might be interrupted, and the session entries might become inconsistent on the RBM member devices. For more information about session management, see Security Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable RBM service entry hot backup.

hot-backup enable

By default, RBM service entry hot backup is enabled.

4. Enable hot backup for the RBM session entries of application layer protocols.

hot-backup protocol { dns | http } * enable

By default, the RBM system performs hot backup for the session entries of application layer protocols.

The hot-backup protocol enable command takes effect only on DNS and HTTP. The device automatically backs up the session entries of other application layer protocols after you enable RBM service entry hot backup.

Enabling automatic synchronization for running data

About this task

The hot backup member devices generate running data when processing packets, and perform packet detection and forwarding based on the running data. To ensure service continuity upon an active/standby switchover, back up running data between the hot backup member devices. In the active/standby-mode or mirroring-mode hot backup network, only the active device processes services. The active device synchronizes running data to the standby device. In the dual-active-mode hot backup network, both hot backup members process services. They both generate running data and back up running data to each other.

Restrictions and guidelines

In the current software version, RBM-based hot backup supports synchronizing the following dynamic running data: DNS entries, ARP entries, load balancing (LB) proximity entries, and LB running data, as well as running data of IPsec, IKE, and IKEv2.

Procedures

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable automatic synchronization for running data.

running-data auto-sync enable

By default, automatic synchronization for running data is enabled.

Configuring RBM configuration synchronization

About this task

The RBM member devices can synchronize configuration changes in real time and synchronize all configuration in bulk.

· Real-time synchronization—The primary device copies added, deleted, or modified configuration to the secondary device in real time to maintain configuration consistency.

· Bulk synchronization—The primary device backs up important configuration in bulk to the secondary device. The secondary device will delete the settings that are inconsistent with those on the primary device.

Hot backup can perform RBM configuration synchronization only when automatic configuration synchronization is enabled and the RBM control channel is set up.

A bulk synchronization is triggered by the following events:

· The RBM control channel is set up and automatic configuration synchronization is enabled (including the default status) for the first time. The primary device will send all its key configuration in bulk to overwrite the configuration on the secondary device. Hot backup does not perform bulk synchronization afterwards, even if automatic configuration synchronization is enabled again or the RBM control channel is set up again.

· An RBM member device reboots, or the RBM process restarts, and automatic configuration synchronization is enabled on the other device. After the reboot or restart and the RBM control channel is set up again, the device that does not reboot will send all its key configuration in bulk to overwrite the configuration on the rebooted device.

Restrictions and guidelines

After the RBM control channel is set up and automatic configuration synchronization is enabled for the first time, do not disable automatic configuration synchronization. If you fail to do so, the devices will not perform bulk configuration, and configuration inconsistency will affect services.

If the amount of configuration to be synchronized is large, bulk synchronization might take one to two hours. To avoid the issue, you can perform one of the following operations:

· Enable automatic configuration synchronization first when you configure RBM.

· Copy the configuration file to the secondary device during initial network deployment and then enable configuration consistency check.

If the control channel has been established and automatic configuration synchronization is enabled, you can configure services only on the primary device.

If the control channel is not established or automatic configuration synchronization is disabled, you can configure services on both the primary and secondary devices.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable automatic configuration synchronization.

configuration auto-sync enable

By default, automatic configuration synchronization is enabled.

4. Enable configuration consistency check.

configuration sync-check [ interval interval | { daily | weekly { fri | mon | sat | sun | thu | tue | wed } } time ]

By default, configuration consistency check is enabled, and the configuration consistency check interval is 24 hours.

5. (Optional.) Perform a one-off configuration consistency check.

configuration manual-sync-check

This command applies only to the primary device.

6. (Optional.) Manually synchronize the configuration of the primary device to the secondary device.

configuration manual-sync

This command applies only to the primary device.

Enabling static route synchronization by RBM

About this task

This feature enables the primary device to copy all static routes to the secondary device in automatic or manual configuration synchronization.

This feature takes effect only after automatic configuration synchronization is enabled by using the configuration auto-sync enable command. If you enable automatic configuration synchronization prior to static route synchronization, the device will automatically synchronize the static routes added after static route synchronization is enabled. To synchronize the static routes configured before static route synchronization is enabled, execute the configuration manual-sync command to synchronize the configuration manually.

Restrictions and guidelines

Enable this feature only in the mirroring-mode hot backup network or the network where virtual IP addresses are configured to direct traffic on the RBM system. Do not enable this feature in any other RBM scenarios.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable static route synchronization by RBM.

configuration auto-sync enable route-static

By default, static route synchronization by RBM is disabled.

Configuring the management interface for the mirroring mode

About this task

In RBM mirroring mode, interface configurations on the primary device (except the management interface and RBM channel interface) are synchronized to the secondary device. Interfaces connected to the network management device and log host have use the same IP addresses on both devices. Only the primary device can establish connections with the network management device and log host. The secondary device cannot establish the connections. To avoid this issue, you can configure the mirroring mode management interface, whose configurations will not be synchronized.

Restrictions and guidelines

You can configure the management interface for the mirroring mode only in RBM mirroring mode. If the mirroring mode is disabled for the device, the management interface for the mirroring mode restores to the default setting.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Configure the hot backup mode for the device as mirroring.

backup-mode mirror-mode

By default, the hot backup mode for the device is active/standby.

4. Configure the management interface for the mirroring mode.

mirror mgt-interface interface-type interface-number

By default, no management interface for the mirroring mode.

Enabling traffic switchover upon failure recovery

About this task

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.

Restrictions and guidelines

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

If this timer is modified during the countdown of the switchover delay timer, the switchover will still be performed according to the old timer value. Subsequent switchovers will be performed based on the modified timer value. If traffic switchover upon failure recovery is disabled during the countdown of the switchover delay timer, no switchover will occur.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable traffic switchover upon failure recovery.

delay-time delay-time

By default, traffic switchover upon failure recovery is disabled.

Associating RBM with VRRP

Restrictions and guidelines

You can associate only VRRP groups operating in standard mode with RBM.

Use RBM in combination with VRRP groups only for in-path RBM deployment between upstream and downstream switches. As a best practice, assign the primary device to the VRRP active group, and assign the secondary device to the VRRP standby group.

You can assign multiple virtual IP addresses to a VRRP group associated with RBM. Make sure the interfaces in the VRRP group do not own the virtual IP addresses.

In the network configured with RBM and VRRP association where subinterfaces are used for networking, you must first configure the vlan-type dot1q vid command, and then configure the VRRP group settings for the subinterface on the primary device. Then configure the previous settings in the same order for the subinterface on the secondary device.

You cannot use the track interface command to monitor the interfaces used by VRRP.

For an IPv6 VRRP group to work correctly, you must assign it a link-local address and a global unicast address as virtual IPv6 addresses. The first virtual IPv6 address of an IPv6 VRRP group must be a link-local address. To delete virtual IPv6 addresses, make sure the link-local address is deleted at last. A VRRP group can have only one link-local address.

In the network configured with RBM and IPv6 VRRP association, you must first configure an IPv6 address, and then configure the VRRP group one second later.

In the network configured with RBM and VRRP association, to delete interface configuration, you must first delete the VRRP group and then delete the IPv4/IPv6 address.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Associate RBM with VRRP. Choose one of the following options:

¡ Create an IPv4 VRRP group and associate it with RBM.

vrrp vrid virtual-router-id virtual-ip virtual-address [ mask | mask-length ] { active | standby }

By default, no IPv4 VRRP groups exist.

¡ Create an IPv6 VRRP group and associate it with RBM. Assign a link-local address and a global unicast address as virtual IPv6 addresses to the VRRP group.

vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address [ prefix-length ] link-local { active | standby }

vrrp ipv6 vrid virtual-router-id virtual-ip virtual-address

By default, no IPv6 VRRP groups exist.

For more information about the vrrp vrid and vrrp ipv6 vrid commands, see VRRP commands in High Availability Command Reference.

Associating RBM with virtual IP addresses

About this task

Assign virtual IP addresses (also known as floating IP addresses) to the service interfaces with the same ID on the RBM member devices. These virtual addresses on the service interfaces are associated with and managed by RBM. This feature ensures that the upstream and downstream traffic can always be directed to the active device for processing.

Restrictions and guidelines

Configure floating IP addresses only on the active device in a RBM system operating in active/standby mode. Floating IP addresses are not available in dual-active or mirroring mode.

You cannot configure virtual IP addresses and VRRP together if NAT is used with virtual IP addresses.

In a network where RBM is associated with virtual IP addresses, because the standby device does not send or receive route negotiation packets, it cannot establish dynamic routing neighbor relationships with the uplink or downlink devices. Upon an active/standby switchover, the new active device needs to renegotiate routes with the uplink and downlink devices. As a result, services will be interrupted for a long time upon the active/standby switchover. As a best practice, do not use dynamic routing protocols in a network where RBM is associated with virtual IP addresses.

In a network where RBM is associated with virtual IP addresses, you can use common IP addresses or floating IP addresses for RBM member device management as needed.

· If manual RBM role configuration is used, because the primary device and active device might be different devices, you can use only common IP addresses for device management.

· If auto RBM role selection is used, using only floating IP addresses might result in device management failure when the RBM state becomes abnormal. As a best practice, use both common IP addresses and floating IP addresses to perform RBM member device management.

If an interface is assigned to a non-default context in exclusive mode, a user can log in to the non-default context and modify the interface's virtual MAC address in interface view.

If an interface is assigned to a non-default context in shared mode, a user cannot modify the interface's virtual MAC address in interface view. The virtual MAC address of the interface shared with the non-default context is automatically generated by the system.

If an interface is assigned to a non-default vSystem, the virtual MAC address of the interface used within the non-default vSystem is automatically generated by the system. You cannot modify the virtual MAC address of the interface.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Assign a floating IP address to the interface. Choose at least one of the following tasks.

¡ Assign an IPv4 floating IP address.

ip address { ip-address { mask-length | mask } | ip-address/mask-length } [ sub ] float

By default, no IPv4 address is assigned to an interface.

¡ Assign an IPv6 floating IP address.

ipv6 address { ipv6-address prefix-length | ipv6-address/prefix-length } float

By default, no floating IPv6 global unicast address is assigned to an interface.

4. (Optional.) Modify the virtual MAC address of the interface.

mac-address virtual mac-address

By default, the virtual MAC address of an interface is automatically assigned by the device, and the primary and secondary devices assign the same virtual MAC address to the interfaces with the same ID.

Typically, the virtual MAC address of an interface is automatically assigned by the device.

Associating RBM with routing protocols

Enabling RBM to adjust the link cost for a routing protocol

About this task

When you use RBM together with a routing protocol, you can enable RBM to adjust the link cost for a routing protocol on the standby device. This feature applies to the scenario where the RBM member devices run the same routing protocol. 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.

Restrictions and guidelines

This feature applies to the scenario where the RBM member devices run the same routing protocol.

The feature takes effect on only the standby device.

To ensure switchover of both uplink and downlink traffic to the new active device, configure this feature with the same parameters on both RBM member devices.

Do not use the silent-backup-interface and adjust-cost enable commands together.

On an RBM system in dual-active mode and in collaboration with a routing protocol, configure per-flow load sharing for IP forwarding on both the uplink and downlink devices as a best practice.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable RBM to adjust the link cost for the specified routing protocol on the standby device.

adjust-cost { bgp | isis | ospf | ospfv3 } enable { absolute [ absolute-cost ] | increment [ increment-cost ] }

By default, RBM does not adjust the link cost for the specified routing protocol on the standby device.

Disabling the standby device from sending or receiving protocol packets of a routing protocol.

This feature applies to the scenario where the RBM member devices run multiple routing protocols. As shown in Figure 17, IBGP and OSPF have different default priorities. When the link between Device A and Router C fails, traffic destined for the hosts might be forwarded to Device A as OSPF has higher priority than IBGP. To resolve this issue, disable Device A from sending or receiving OSPF protocol packets to disconnect its OSPF neighbors. Then, Device B will forward all uplink and downlink traffic.

Figure 17 Hot backup member devices running multiple routing protocols

Restrictions and guidelines

This feature applies to the scenario where the RBM member devices run multiple routing protocols.

To ensure switchover of both uplink and downlink traffic to the new active device, configure this feature with the same parameters on both RBM member devices.

Do not use the silent-backup-interface and adjust-cost enable commands together.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Disable the standby device from sending or receiving protocol packets of a dynamic routing protocol.

silent-backup-interface { ospf | ospfv3 }

By default, the standby device can send and receive protocol packets of a dynamic routing protocol.

Configuring RBM transparent in-path deployment

Enabling RBM to monitor interfaces

About this task

Perform this task to enable RBM to monitor the interfaces connecting the uplink and downlink devices in a network with RBM transparent in-path deployment or where RBM collaborates with static routing. 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.

Restrictions and guidelines

You can use the track interface and track commands in conjunction, but you cannot use these commands to monitor the same interfaces.

You cannot use the track interface command to monitor the interfaces used by VRRP.

The track vlan and track interface commands are mutually exclusive. You cannot configure both of them.

Hot backup does not support monitoring member ports of aggregate interfaces.

This feature applies only to transparent in-path deployment of RBM and the network configured with RBM and static route association.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable RBM to monitor a Layer 2 or Layer 3 Ethernet interface.

track interface interface-type interface-number

By default, RBM does not monitor any interfaces.

Enabling RBM to monitor VLANs

About this task

Perform this task to enable RBM to monitor the VLANs of the uplink and downlink devices in RBM transparent in-path deployment. 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.

In active/standby mode, the state of monitored VLANs is active on the primary device and inactive on the secondary device.

In dual-active mode, the state of monitored VLANs is active on both RBM member devices.

Restrictions and guidelines

The track vlan command is mutually exclusive with the track interface and track commands. You cannot use the track vlan command in conjunction with the track interface or track command.

Do not enable RBM to monitor VLAN 1 (to which all access ports belong by default). This restriction prevents an unused interface in down state from interrupting operation of other interfaces in VLAN 1.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable RBM to monitor a VLAN.

track vlan vlan-id

By default, RBM does not monitor any VLANs.

Associating RBM with Track

About this task

Perform this task to associate RBM with Track to monitor links. If one of the monitored track entries becomes Negative, the RBM system performs an active/standby switchover and switches traffic to the new active device to ensure service continuity. For more information about Track, see Network Management and Monitoring Configuration Guide.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Associate RBM with Track.

track track-entry-number

By default, RBM is not associated with Track.

Performing an active/standby switchover

About this task

To replace components or upgrade software on one device, you can perform this task to switch services to the other device.

The function of this task is as follows:

· switchover request—In an active/standby or mirroring-mode RBM system, use this command to trigger an active/standby switchover on either the active device or standby device.

· switchover active—In a dual-active RBM system, typically both member devices are active. From a member device, you can use this command to switch the running status of the peer device to standby. The local device retains its active state.

· switchover standby—In a dual-active RBM system, typically both member devices are active. You can use this command to switch the running status of one member device to standby. The peer device retains its active state.

· switchover reset—In an active/standby or dual-active RBM system, use this command to perform running status re-election on either the active device or standby device.

Restrictions and guidelines

Use this feature when both member devices are operating correctly. This feature does not take effect if the RBM status is abnormal. For example, when a service interface of the active device fails and the running status changes to standby, the switchover request command will not switch the running status back to active.

In an RBM system and VRRP associated network, this task might cause temporary virtual IP address conflict in the VRRP group, which is considered a normal condition.For more information about VRRP, see "Configuring VRRP."

For stable operation of the RBM system, do not repeatedly perform this task within one minute.

Procedure

1. ‍Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Perform an active/standby switchover.

switchover { active | request | reset | standby }

Specifying the peer device as the default operating device in a VRRP group

About this task

This task applies only when the RBM system is operating in dual-active mode.

This task enables you to switch all traffic of a VRRP group to the RBM peer device for load balancing. After you perform this task, the RBM module sets the role of the local device to backup in the specified VRRP group, and the peer device becomes the master.

Feature and hardware compatibility

Series	Models	Feature compatibility
M9000 series	M9006, M9010, M9014, M9016-V	No
M9000-S series	M9008-S, M9008-S-V	No
M9000-AK series	M9000-AK001	No
M9000-AI-E series	M9000-AI-E4	No
M9000-AI-E series	M9000-AI-E8, M9000-AI-E16	Yes
M9000-X series	M9000-X06, M9000-X06-B, M9000-X06-B-G, M9000-X06-G, M9000-X10	No
M9000-AI-X series	M9000-AI-X06, M9000-AI-X10	No
M9000-CN series	M9000-CN04	No

‌

Restrictions and guidelines

The switchover vrrp backup command takes effect only when both member devices in the RBM system are in active state.

Before RBM channels are set up, you can use this command without following any restrictions. After RBM channels are set up, you can use the switchover vrrp backup command only when both member devices in the RBM system are in active state. If executed on the secondary device, this command will be deleted.

You can execute the switchover vrrp backup command for multiple VRRP groups.

If you execute the undo switchover vrrp backup command without specifying any parameters, the command takes effect on all VRRP groups associated with RBM.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Specify the peer device as the default operating device in a VRRP group

switchover vrrp [ ipv6 ] vrid virtual-router-id backup

By default, the RBM role election result determines the default operating device in a VRRP group associated with RBM.

Enabling transparent service traffic transmission between the RBM members

About this task

Enable transparent service traffic transmission only when asymmetric-path traffic traverses the RBM system operating in dual-active mode.

If an asymmetric-path flow traverses the RBM system operating in dual-active mode, the flow and its return traffic are processed by different RBM members. This will degrade the traffic processing performance of modules such as NBAR, load balancing, and DPI. For example, the packet recognition rate of NBAR might drop. For an asymmetric-path flow and its return traffic to be processed by the same RBM member, enable transparent service traffic transmission. Transparent service traffic transmission is resource-intensive. Make sure you are fully aware of the impact of this feature when you use it on a live network.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable transparent service traffic transmission between the RBM members.

transparent-transmit enable

By default, transparent service traffic transmission is enabled.

Configuring MAD

About this task

On a RBM system, if the RBM channel is disconnected, RBM will fail. Both member devices become active and process services, but they are no longer in RBM mode, impacting subsequent asymmetric traffic. To enhance system availability and minimize the impact of the RBM channel disconnection, configure multi-active detection (MAD).

With MAD configured, when the RBM channel is disconnected, the member devices will use MAD to maintain the RBM status. However, the member devices will be unable to synchronize configuration and service entries, and transparently forward traffic. If the RBM mode is active/standby, the mode remains unchanged. If the RBM mode is dual-active or mirroring, the mode will switch to active/standby.

Feature and hardware compatibility

Series	Models	Feature compatibility
M9000 series	M9006, M9010, M9014, M9016-V	Yes
M9000-S series	M9008-S, M9008-S-V	Yes
M9000-AK series	M9000-AK001	Yes
M9000-AI-E series	M9000-AI-E4, M9000-AI-E8, M9000-AI-E16	Yes
M9000-X series	M9000-X06, M9000-X06-B, M9000-X06-B-G, M9000-X06-G, M9000-X10	Yes
M9000-AI-X series	M9000-AI-X06, M9000-AI-X10	Yes
M9000-CN series	M9000-CN04	No

‌

Restrictions and guidelines

Do not enable MAD on VLAN-interface 1. VLAN 1 cannot be used for MAD.

If you execute the mad arp enable or mad nd enable command, you must enter a domain ID. The domain ID does not affect the MAD feature. To use the current domain ID, press Enter.

The domain ID is a global setting. You can use either the mad arp enable or mad nd enable command to edit the global domain ID on a RBM member device. If you configure the global domain ID multiple times, the most recent configuration takes effect.

Configure MAD before the RBM channels are disconnected.

Configuring ARP MAD

1. Enter system view.

system-view

2. Create a VLAN for ARP MAD.

vlan vlan-id

By default, only VLAN 1 exists.

VLAN 1 cannot be used for ARP MAD.

If intermediate devices exist, you must also perform this task on the intermediate devices.

3. Return to system view.

quit

4. Enter Ethernet interface view.

interface interface-type interface-number

5. Assign the interface to the ARP MAD VLAN.

¡ Assign an access interface to the ARP MAD VLAN.

port access vlan vlan-id

¡ Assign a trunk interface to the ARP MAD VLAN.

port trunk permit vlan vlan-id

¡ Assign a hybrid interface to the ARP MAD VLAN.

port hybrid vlan vlan-id { tagged | untagged }

The link type does not affect ARP MAD. You do not need to modify the link type of the Ethernet interface.

By default, the link type of an interface is access.

If intermediate devices exist, you must also perform this task on the intermediate devices.

6. Return to system view.

quit

7. Enter VLAN interface view.

interface vlan-interface interface-number

8. Assign an IPv4 address to the VLAN interface.

ip address ip-address { mask | mask-length }

By default, no IPv4 address is assigned to a VLAN interface.

9. Enable ARP MAD.

mad arp enable

By default, ARP MAD is disabled.

Configuring ND MAD

1. Enter system view.

system-view

2. Create a VLAN for ND MAD.

vlan vlan-id

By default, only VLAN 1 exists.

VLAN 1 cannot be used for ND MAD.

If intermediate devices exist, you must also perform this task on the intermediate devices.

3. Return to system view.

quit

4. Enter Ethernet interface view.

interface interface-type interface-number

5. Assign the interface to the ND MAD VLAN.

¡ Assign an access interface to the ND MAD VLAN.

port access vlan vlan-id

¡ Assign a trunk interface to the ND MAD VLAN.

port trunk permit vlan vlan-id

¡ Assign a hybrid interface to the ND MAD VLAN.

port hybrid vlan vlan-id { tagged | untagged }

The link type does not affect ND MAD. You do not need to modify the link type of the Ethernet interface.

By default, the link type of an interface is access.

If intermediate devices exist, you must also perform this task on the intermediate devices.

6. Return to system view.

quit

7. Enter VLAN interface view.

interface vlan-interface interface-number

8. Assign an IPv6 address to the VLAN interface.

ipv6 address { ipv6-address/pre-length | ipv6 address pre-length }

By default, no IPv6 address is assigned to a VLAN interface.

9. Enable ND MAD.

mad nd enable

By default, ND MAD is disabled.

Enabling RBM non-stop-routing (NSR)

About this task

On a hot standby system, if the active MPU of an hot backup member device fails, the standby MPU will detect the active MPU failure and become the new active MPU. As the original MPU process exits, the RBM channel will disconnect, and the new MPU needs to re-establish the channel. When RBM NSR is enabled, the active MPU will back up the established channel information to the standby MPU. In the event of an active MPU failure, the standby MPU will use the backed-up channel information to set up the RBM channel, ensuring a smooth transition to the active MPU and avoiding RBM channel disconnection.

Feature and hardware compatibility

Series	Models	Feature compatibility
M9000 series	M9006, M9010, M9014, M9016-V	Yes
M9000-S series	M9008-S, M9008-S-V	Yes
M9000-AK series	M9000-AK001	Yes
M9000-AI-E series	M9000-AI-E4, M9000-AI-E8, M9000-AI-E16	Yes
M9000-X series	M9000-X06, M9000-X06-B, M9000-X06-B-G, M9000-X06-G, M9000-X10	Yes
M9000-AI-X series	M9000-AI-X06, M9000-AI-X10	Yes
M9000-CN series	M9000-CN04	No

‌

Restrictions and guidelines

If the standby MPU fails after RBM NSR is enabled, the RBM channel will be disconnected. In this case, disable RBM NSR to maintain RBM channel connectivity and then re-enable it after replacing the standby MPU.

During MPU bulk configuration backup, RBM NSR cannot work correctly. If the active MPU fails, the standby MPU cannot smoothly switch to the active MPU role, and the RBM channel will disconnect, requiring the new MPU to re-establish the channel.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Enable RBM NSR.

nsr enable

By default, RBM NSR is enabled.

Enabling interfaces to preferentially use the virtual MAC addresses as the source MAC addresses when sending packets

About this task

To avoid this issue, enable the RBM primary device to preferentially use virtual MAC addresses as the source MAC addresses of packets. Then, packets from the active device can be encapsulated with virtual MAC addresses.

Restrictions and guidelines

In the scenario of RBM collaboration with virtual addresses, besides using this feature, you can also use the undo vrrp virtual-mac enable command to configure ARP packets to use the real MAC addresses to avoid service interruption. The two features are mutually exclusive.

This feature supports configuration synchronization. Once you enable the automatic configuration backup feature, you must enable this feature only on the RBM primary device. When you configure multiple VRRP groups to collaborate with RBM on an interface, this feature is not supported.

Use this feature only in scenarios of RBM collaboration with VRRP and RBM collaboration with virtual addresses. Do not use this feature in other scenarios.

With this feature enabled, the source MAC address used by the RBM member device for sending packets is a virtual MAC address, which remains unchanged during switchover. This might cause the outgoing interface in the MAC address entry for this virtual MAC address on upstream and downstream devices to switch repeatedly during active/standby switchover, leading to transient traffic interruption.

Procedure

1. Enter system view.

system-view

2. Enable interfaces to preferentially use the virtual MAC addresses as the source MAC addresses when sending packets.

ip send-packet source-mac prefer virtual-mac

By default, an interface is disabled from preferentially using the virtual MAC address as the source MAC address when sending packets.

Bulk backing up local session entries to the hot backup peer

About this task

If the hot backup member devices have inconsistent session entries, you can manually bulk back up local session entries from one hot backup member device to the other.

Restrictions and guidelines

This task does not take effect during bulk configuration backup or bulk service entry backup. To examine whether bulk configuration backup or bulk service entry backup is in progress, execute the display remote-backup-group status command. The minimum interval between two executions of the session manual-sync command is 1 minute.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Bulk back up local session entries to the hot backup peer.

In standalone mode:‌

session manual-sync [ slot slot-number [ cpu cpu-number ] ]

In IRF mode:

session manual-sync [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]

Configuring the interface recovery wait timer

About this task

In an RBM network, you can use the track interface or track vlan command to monitor the uplink and downlink interfaces, ensuring consistency for the states of the monitored interfaces. If an active/standby switchover occurs due to failure of a monitored interface on the active device, the other monitored interfaces on the original active device will also be unable to forward packets. After the failed interface recovers, traffic switches back to the original active device if traffic switchover upon failure recovery is enabled and the switchover delay timer has expired. The other monitored interfaces will also recover to normal status.

If the recovery time is too long for any other monitored interfaces, another active/standby switchover might occur. To avoid this issue, you can configure an interface recovery wait timer. Traffic will switch to the peer device only if the monitored interfaces have not completed recovery or another monitored interface has failed upon expiration of the wait timer.

Restrictions and guidelines

If a monitored interface has failed before the switchover delay timer expires, traffic will still switch to the interface-associated device, which results in service interruption. This situation will persist until another switchover is triggered upon expiration of the interface recovery wait timer. As a best practice, configure the interface recovery wait time as short as possible provided that the other monitored interfaces have sufficient time to recover.

As a best practice, configure this command only in the scenario where you use the track interface or track vlan command to monitor the uplink and downlink interfaces in the network. You do not need to configure this command in other scenarios.

Procedure

1. Enter system view.

system-view

2. Enter RBM view.

remote-backup group

3. Configure the interface recovery wait timer.

wait-interface-up delay-time time-value

By default, the interface recovery wait timer is 32 seconds.

Configuring service features on the RBM system

NAT on the RBM system

For NAT to operate correctly on the RBM system, 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. For more information about NAT features, see NAT Configuration Guide.

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

About NAT on the RBM system

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 18, dynamic NAT is configured on the RBM 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 18 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 19, dynamic NAT is configured on the RBM 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:

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 NAT-associated uplink VRRP group.

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

Figure 19 NAT on the RBM system

For more information about VRRP group association with dynamic NAT, static NAT, NAT server, and NAT444, see Layer 3—IP Services Configuration Guide.

Hot backup support for SSL VPN

The RBM channels are used to back up SSL VPN data, including user data, entries, and configuration. For more information about SSL VPN configuration, see VPN Configuration Guide.

RBM supports SSL VPN only when it is operating in active/standby mode and collaborating with VRRP groups.

RBM support for IPsec

An RBM system backs up IPsec configurations and entries of established IPsec tunnels over the RBM channel. For more information about IPsec, see Security Configuration Guide.

RBM ensures service continuity only for IPsec tunnels that use IKEv1 as the IPsec security policy. Service continuity is not ensured for IPsec tunnels set up by using other methods, such as the IPsec security framework, IKEv2, and manual tunnel setup.

RBM support for DPI services

When you use DPI services on the RBM system operating in dual-active mode, you must enable DPI support for RBM if asymmetric-path traffic exists. If you do not enable this feature, DPI services might fail to correctly identify and process packets. For more information about DPI support for RBM, see DPI engine configuration in DPI Configuration Guide.

RBM support for contexts

You can configure RBM 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.

Common RBM deployment schemes

RBM supports the following common 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 20 shows a typical model of routed in-path deployment in active/standby mode. An RBM 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 RBM.

· 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 20 Routed in-path deployment in active/standby mode

The following shows how traffic is forwarded when the host accesses the Internet in Figure 20:

1. The host identifies that the destination IP address is on a different subnet and sends an ARP request to obtain the MAC address of the default gateway. In this example, the host does not have the ARP entry for the default gateway.

2. Switch B broadcasts the ARP request and learns the MAC address of the host.

3. Device A and Device B receives the ARP request, and Device A (master) replies with the virtual MAC address of VRRP group 2.

4. Switch B learns the MAC address entry for the virtual MAC address of VRRP group 2 and forwards the ARP reply to the host.

5. The host learns the virtual MAC address and sends the packets destined for the Internet to the default gateway.

6. Switch B forwards the packets to Device A (master). The traffic of the host will be processed and forwarded by Device A as long as it is the master.

7. Device A does not have the ARP entry for the next hop of the route to the Internet and sends an ARP request to obtain the MAC address of the next hop. In the ARP request, the source MAC address is the virtual MAC address of VRRP group 1.

8. Switch A and the router then perform typical forwarding and ARP and MAC address learning.

The forwarding process for the traffic sent from the Internet to the host is similar to the above process.

Routed in-path deployment in dual-active mode

Figure 21 shows a typical model of routed in-path deployment in dual-active mode. A RBM 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 21 Routed in-path deployment in dual-active mode

As shown in Figure 21, the traffic of Host A and Host B is distributed to Device A and Device B, respectively. The traffic forwarding process is similar to that in active/standby mode.

Transparent in-path deployment in active/standby mode

Figure 22 shows a typical model of transparent in-path deployment in active/standby mode. A Layer 2 RBM 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 RBM 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 22 Transparent in-path deployment in active/standby mode

Transparent in-path deployment in dual-active mode

Figure 23 shows a typical model of transparent in-path deployment in dual-active mode. A Layer 2 RBM 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 RBM 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 23 Transparent in-path deployment in dual-active mode

Display and maintenance commands for RBM

Execute display commands in any view.

Task	Command
Display virtual MAC addresses.	display mac-address virtual [ mac-address \| interface interface-type interface-number ]
Display MAD configuration.	display mad [ verbose ]
Display RBM status information.	display remote-backup-group status
Display the configuration consistency check result for RBM.	display remote-backup-group sync-check
Display statistics of the mirroring-mode-specific data transmitted through the data channel.	display remote-backup-group trans-data
Clear statistics of the mirroring-mode-specific data transmitted through the data channel.	reset remote-backup-group trans-data

RBM configuration examples‌ (IPv4)

Example: Configuring active/standby RBM in collaboration with VRRP

Network configuration

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

· Configure RBM to collaborate with VRRP.

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

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

Figure 24 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Switch A:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the router to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

3. Configure Switch B:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the host to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

4. Configure the router:

NOTE:

This step only provides the brief configuration procedure.

# Assign 2.1.1.15/24 to GigabitEthernet 1/0/7.

# Configure routes as follows:

¡ Specify 2.1.1.3 (virtual IP address of VRRP group 1) as the next hop of the routes to the internal network.

¡ Specify the IP address of the peer interface attached to the traffic outgoing interface as the next hop of the route to the Internet.

5. Configure Device A:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 2.1.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

c. Configure settings for routing. This example configures a static route, and the next hop in the route is 2.1.1.15.

[DeviceA] ip route-static 0.0.0.0 0.0.0.0 2.1.1.15

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure a rule named trust-untrust to permit the packets from 10.1.1.0/24 to the Internet.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 10.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

# Configure rules to permit VRRP protocol packets. When the RBM channel is disconnected, Device A and Device B can exchange VRRP protocol packets to elect a VRRP master.

[DeviceA-security-policy-ip] rule name vrrp1

[DeviceA-security-policy-ip-4-vrrp1] source-zone trust

[DeviceA-security-policy-ip-4-vrrp1] destination-zone local

[DeviceA-security-policy-ip-4-vrrp1] service vrrp

[DeviceA-security-policy-ip-4-vrrp1] action pass

[DeviceA-security-policy-ip-4-vrrp1] quit

[DeviceA-security-policy-ip] rule name vrrp2

[DeviceA-security-policy-ip-5-vrrp2] source-zone local

[DeviceA-security-policy-ip-5-vrrp2] destination-zone trust

[DeviceA-security-policy-ip-5-vrrp2] service vrrp

[DeviceA-security-policy-ip-5-vrrp2] action pass

[DeviceA-security-policy-ip-5-vrrp2] quit

[DeviceA-security-policy-ip] rule name vrrp3

[DeviceA-security-policy-ip-6-vrrp3] source-zone untrust

[DeviceA-security-policy-ip-6-vrrp3] destination-zone local

[DeviceA-security-policy-ip-6-vrrp3] service vrrp

[DeviceA-security-policy-ip-6-vrrp3] action pass

[DeviceA-security-policy-ip-6-vrrp3] quit

[DeviceA-security-policy-ip] rule name vrrp4

[DeviceA-security-policy-ip-7-vrrp4] source-zone local

[DeviceA-security-policy-ip-7-vrrp4] destination-zone untrust

[DeviceA-security-policy-ip-7-vrrp4] service vrrp

[DeviceA-security-policy-ip-7-vrrp4] action pass

[DeviceA-security-policy-ip-7-vrrp4] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings.

In this example, Ethernet interfaces are used for control and data channel setup. If a device has both RBM and Ethernet interfaces, use the RBM interface for control and data channel setup to protect device security and stability. Do not use an RBM interface as a service interface.

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] undo backup-mode

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

RBM_P[DeviceA-remote-backup-group] quit

# Create VRRP groups and associate them with RBM.

RBM_P[DeviceA] interface gigabitethernet 1/0/1

RBM_P[DeviceA-GigabitEthernet1/0/1] vrrp vrid 1 virtual-ip 2.1.1.3 active

RBM_P[DeviceA-GigabitEthernet1/0/1] quit

RBM_P[DeviceA] interface gigabitethernet 1/0/2

RBM_P[DeviceA-GigabitEthernet1/0/2] vrrp vrid 2 virtual-ip 10.1.1.3 active

RBM_P[DeviceA-GigabitEthernet1/0/2] quit

f. Configure security services on Device A. (Details not shown.)

6. Configure Device B:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ip address 2.1.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

c. Configure settings for routing. This example configures a static route, and the next hop in the route is 2.1.1.15.

[DeviceB] ip route-static 0.0.0.0 0.0.0.0 2.1.1.15

d. Configure RBM settings.

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] undo backup-mode

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

RBM_S[DeviceB-remote-backup-group] quit

# Create VRRP groups and associate them with RBM.

RBM_S[DeviceB] interface gigabitethernet 1/0/1

RBM_S[DeviceB-GigabitEthernet1/0/1] vrrp vrid 1 virtual-ip 2.1.1.3 standby

RBM_S[DeviceB-GigabitEthernet1/0/1] quit

RBM_S[DeviceB] interface gigabitethernet 1/0/2

RBM_S[DeviceB-GigabitEthernet1/0/2] vrrp vrid 2 virtual-ip 10.1.1.3 standby

RBM_S[DeviceB-GigabitEthernet1/0/2] quit

7. On the host, specify 10.1.1.3 (virtual IP address of VRRP group 2) as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify the configuration on Device A:

# Verify that the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that Device A is the master in all VRRP groups.

RBM_P[DeviceA] display vrrp

IPv4 Virtual Router Information:

Running mode : Standard

RBM control channel is established

VRRP active group status : Master

VRRP standby group status: Master

Total number of virtual routers : 2

Interface VRID State Running Adver Auth Virtual

Pri Timer Type IP

---------------------------------------------------------------------

GE1/0/1 1 Master 100 100 None 2.1.1.3

GE1/0/2 2 Master 100 100 None 10.1.1.3

# Enable logging for the security policy that permits communication between security zones Trust and Untrust. Verity that Device A generates log messages when the host communicates with the Internet. (Details not shown.)

2. Verify the configuration on Device B:

# Verify that the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Secondary

Device running status: Standby

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Standby Interface status changed

# Verify that Device A is the backup in all VRRP groups.

RBM_S[DeviceB] display vrrp

IPv4 Virtual Router Information:

Running mode : Standard

RBM control channel is established

VRRP active group status : Backup

VRRP standby group status: Backup

Total number of virtual routers : 2

Interface VRID State Running Adver Auth Virtual

Pri Timer Type IP

---------------------------------------------------------------------

GE1/0/1 1 Backup 100 100 None 2.1.1.3

GE1/0/2 2 Backup 100 100 None 10.1.1.3

# Enable logging for the security policy that permits communication between security zones Trust and Untrust. Verity that Device B does not generate log messages when the host communicates with the Internet. (Details not shown.)

Example: Configuring dual-active RBM in collaboration with VRRP

Network configuration

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

· Configure RBM to collaborate with VRRP.

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

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

Figure 25 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Switch A:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the router to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

3. Configure Switch B:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the host to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

4. Configure the router:

NOTE:

This step only provides the brief configuration procedure.

# Assign 2.1.1.15/24 to GigabitEthernet 1/0/7.

# Configure routes as follows:

¡ Specify 2.1.1.3 (virtual IP address of VRRP group 1) as the next hop of the routes to some subnets of the internal network. Specify 2.1.1.4 (virtual IP address of VRRP group 2) as the next hop of the routes to the other subnets of the internal network.

¡ Specify the IP address of the peer interface attached to the traffic outgoing interface as the next hop of the route to the Internet.

5. Configure Device A:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 2.1.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

c. Configure settings for routing. This example configures a static route, and the next hop in the route is 2.1.1.15.

[DeviceA] ip route-static 0.0.0.0 0.0.0.0 2.1.1.15

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure a rule named trust-untrust to permit the packets from 10.1.1.0/24 to the Internet.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 10.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

# Configure rules to permit VRRP protocol packets. When the RBM channel is disconnected, Device A and Device B can exchange VRRP protocol packets to elect a VRRP master.

[DeviceA-security-policy-ip] rule name vrrp1

[DeviceA-security-policy-ip-4-vrrp1] source-zone trust

[DeviceA-security-policy-ip-4-vrrp1] destination-zone local

[DeviceA-security-policy-ip-4-vrrp1] service vrrp

[DeviceA-security-policy-ip-4-vrrp1] action pass

[DeviceA-security-policy-ip-4-vrrp1] quit

[DeviceA-security-policy-ip] rule name vrrp2

[DeviceA-security-policy-ip-5-vrrp2] source-zone local

[DeviceA-security-policy-ip-5-vrrp2] destination-zone trust

[DeviceA-security-policy-ip-5-vrrp2] service vrrp

[DeviceA-security-policy-ip-5-vrrp2] action pass

[DeviceA-security-policy-ip-5-vrrp2] quit

[DeviceA-security-policy-ip] rule name vrrp3

[DeviceA-security-policy-ip-6-vrrp3] source-zone untrust

[DeviceA-security-policy-ip-6-vrrp3] destination-zone local

[DeviceA-security-policy-ip-6-vrrp3] service vrrp

[DeviceA-security-policy-ip-6-vrrp3] action pass

[DeviceA-security-policy-ip-6-vrrp3] quit

[DeviceA-security-policy-ip] rule name vrrp4

[DeviceA-security-policy-ip-7-vrrp4] source-zone local

[DeviceA-security-policy-ip-7-vrrp4] destination-zone untrust

[DeviceA-security-policy-ip-7-vrrp4] service vrrp

[DeviceA-security-policy-ip-7-vrrp4] action pass

[DeviceA-security-policy-ip-7-vrrp4] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings.

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] backup-mode dual-active

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

RBM_P[DeviceA-remote-backup-group] delay-time 1

RBM_P[DeviceA-remote-backup-group] quit

# Create VRRP groups and associate them with RBM.

RBM_P[DeviceA] interface gigabitethernet 1/0/1

RBM_P[DeviceA-GigabitEthernet1/0/1] vrrp vrid 1 virtual-ip 2.1.1.3 active

RBM_P[DeviceA-GigabitEthernet1/0/1] vrrp vrid 2 virtual-ip 2.1.1.4 standby

RBM_P[DeviceA-GigabitEthernet1/0/1] quit

RBM_P[DeviceA] interface gigabitethernet 1/0/2

RBM_P[DeviceA-GigabitEthernet1/0/2] vrrp vrid 3 virtual-ip 10.1.1.3 active

RBM_P[DeviceA-GigabitEthernet1/0/2] vrrp vrid 4 virtual-ip 10.1.1.4 standby

RBM_P[DeviceA-GigabitEthernet1/0/2] quit

f. Configure security services on Device A. (Details not shown.)

6. Configure Device B:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ip address 2.1.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

c. Configure settings for routing. This example configures a static route, and the next hop in the route is 2.1.1.15.

[DeviceB] ip route-static 0.0.0.0 0.0.0.0 2.1.1.15

d. Configure RBM settings.

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] backup-mode dual-active

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

RBM_S[DeviceB-remote-backup-group] delay-time 1

RBM_S[DeviceB-remote-backup-group] quit

# Create VRRP groups and associate them with RBM.

RBM_S[DeviceB] interface gigabitethernet 1/0/1

RBM_S[DeviceB-GigabitEthernet1/0/1] vrrp vrid 1 virtual-ip 2.1.1.3 standby

RBM_S[DeviceB-GigabitEthernet1/0/1] vrrp vrid 2 virtual-ip 2.1.1.4 active

RBM_S[DeviceB-GigabitEthernet1/0/1] quit

RBM_S[DeviceB] interface gigabitethernet 1/0/2

RBM_S[DeviceB-GigabitEthernet1/0/2] vrrp vrid 3 virtual-ip 10.1.1.3 standby

RBM_S[DeviceB-GigabitEthernet1/0/2] vrrp vrid 4 virtual-ip 10.1.1.4 active

RBM_S[DeviceB-GigabitEthernet1/0/2] quit

7. On some hosts, specify 10.1.1.3 (virtual IP address of VRRP group 3) as the default gateway. On the other hosts, specify 10.1.1.4 (virtual IP address of VRRP group 4) as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify the configuration on Device A:

# Verify that the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that Device A is the master in VRRP groups 1 and 3 and the backup in VRRP groups 2 and 4.

RBM_P[DeviceA] display vrrp

IPv4 Virtual Router Information:

Running mode : Standard

RBM control channel is established

VRRP active group status : Master

VRRP standby group status: Backup

Total number of virtual routers : 4

Interface VRID State Running Adver Auth Virtual

Pri Timer Type IP

---------------------------------------------------------------------

GE1/0/1 1 Master 100 100 None 2.1.1.3

GE1/0/1 2 Backup 100 100 None 2.1.1.4

GE1/0/2 3 Master 100 100 None 10.1.1.3

GE1/0/2 4 Backup 100 100 None 10.1.1.4

# Enable logging for the security policy that permits communication between security zones Trust and Untrust. Verity that Device A generates log messages when a host for which Device A forwards traffic communicates with the Internet. Verity that Device A does not generate log messages when a host for which Device B forwards traffic communicates with the Internet. (Details not shown.)

2. Verify the configuration on Device B:

# Verify that the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Secondary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that Device B is the master in VRRP groups 2 and 4 and the backup in VRRP groups 1 and 3.

RBM_S[DeviceB] display vrrp

IPv4 Virtual Router Information:

Running mode : Standard

RBM control channel is established

VRRP active group status : Master

VRRP standby group status: Backup

Total number of virtual routers : 4

Interface VRID State Running Adver Auth Virtual

Pri Timer Type IP

---------------------------------------------------------------------

GE1/0/1 1 Backup 100 100 None 2.1.1.3

GE1/0/1 2 Master 100 100 None 2.1.1.4

GE1/0/2 3 Backup 100 100 None 10.1.1.3

GE1/0/2 4 Master 100 100 None 10.1.1.4

# Enable logging for the security policy that permits communication between security zones Trust and Untrust. Verity that Device B generates log messages when a host for which Device B forwards traffic communicates with the Internet. Verity that Device B does not generate log messages when a host for which Device A forwards traffic communicates with the Internet. (Details not shown.)

Example: Configuring active/standby RBM in collaboration with virtual IP addresses

Network configuration

As shown in Figure 26, Device A and Device B are border security devices connected to the internal network and the Internet. To improve service stability, set up an RBM system with the devices.

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

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

· Assign the same floating IP address to the service interfaces with the same ID on both devices. The virtual addresses on these service interfaces will be associated with RBM and managed and controlled by RBM.

· Set up MAD to avoid address conflicts between the two devices when the RBM channel is disconnected. If Device A or its link fails, Device B takes over to ensure service continuity.

Figure 26 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Switch A:

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the router to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

3. Configure Switch B:

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the host to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

4. Configure the router:

# Assign 2.1.1.15/24 to GigabitEthernet 1/0/7.

# Configure routes as follows:

¡ Specify 2.1.1.1 (floating IP address) as the next hop of the routes to the internal network.

¡ Specify the IP address of the peer interface attached to the traffic outgoing interface as the next hop of the route to the Internet.

5. Configure Device A:

a. Assign floating IP addresses to GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 and common IP addresses to other interfaces.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 2.1.1.1 255.255.255.0 float

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] ip address 10.1.1.1 255.255.255.0 float

[DeviceA-GigabitEthernet1/0/2] quit

[DeviceA] interface gigabitethernet 1/0/3

[DeviceA-GigabitEthernet1/0/3] ip address 10.2.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/3] quit

b. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

c. Configure settings for routing. This example configures a static route, and the next hop in the route is 2.1.1.15.

[DeviceA] ip route-static 0.0.0.0 0.0.0.0 2.1.1.15

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure a rule named trust-untrust to permit the packets from 10.1.1.0/24 to the Internet.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 10.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings.

# Configure Track to monitor status of interfaces.

[DeviceA] track 1 interface gigabitethernet 1/0/1

[DeviceA-track-1] quit

[DeviceA] track 2 interface gigabitethernet 1/0/2

[DeviceA-track-2] quit

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] undo backup-mode

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable route-static

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

# Associate track entries 1 and 2 with RBM.

RBM_P[DeviceA-remote-backup-group] track 1

RBM_P[DeviceA-remote-backup-group] track 2

RBM_P[DeviceA-remote-backup-group] quit

f. Configure ARP MAD.

# Create VLAN 20, and assign GigabitEthernet 1/0/4 to VLAN 20.

RBM_P[DeviceA] vlan 20

RBM_P[DeviceA-vlan20] quit

RBM_P[DeviceA] interface gigabitethernet 1/0/4

RBM_P[DeviceA-GigabitEthernet1/0/4] port link-mode bridge

RBM_P[DeviceA-GigabitEthernet1/0/4] port access vlan 20

RBM_P[DeviceA-GigabitEthernet1/0/4] quit

# Create VLAN-interface 20, assign an IP address to the interface, and enable ARP MAD.

RBM_P[DeviceA] interface vlan-interface 20

RBM_P[DeviceA-Vlan-interface20] ip address 10.3.1.1 24

RBM_P[DeviceA-Vlan-interface20] mad arp enable

You need to assign a domain ID (range: 0-4294967295)

[Current domain is: 1]:

The assigned domain ID is: 1

g. Configure security services on Device A. (Details not shown.)

For the service modules for which RBM supports configuration synchronization, you need to configure relevant settings only on the primary device.

6. Configure Device B:

a. Assign IP addresses to interfaces. The floating IP addresses on Device A will be automaticaly synchronized to Device B.

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] ip address 10.2.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/3] quit

b. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

c. Configure RBM settings.

# Configure Track to monitor status of interfaces.

[DeviceB] track 1 interface gigabitethernet 1/0/1

[DeviceB-track-1] quit

[DeviceB] track 2 interface gigabitethernet 1/0/2

[DeviceB-track-2] quit

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] undo backup-mode

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable route-static

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

# Associate track entries 1 and 2 with RBM.

RBM_S[DeviceB-remote-backup-group] track 1

RBM_S[DeviceB-remote-backup-group] track 2

RBM_S[DeviceB-remote-backup-group] quit

d. Configure ARP MAD.

# Create VLAN 20, and assign GigabitEthernet 1/0/4 to VLAN 20.

RBM_S[DeviceB] vlan 20

RBM_S[DeviceB-vlan20] quit

RBM_S[DeviceB] interface gigabitethernet 1/0/4

RBM_S[DeviceB-GigabitEthernet1/0/4] port link-mode bridge

RBM_S[DeviceB-GigabitEthernet1/0/4] port access vlan 20

RBM_S[DeviceB-GigabitEthernet1/0/4] quit

# Create VLAN-interface 20, assign an IP address to the interface, and enable ARP MAD.

RBM_S[DeviceB] interface vlan-interface 20

RBM_S[DeviceB-Vlan-interface20] ip address 10.3.1.2 24

RBM_S[DeviceB-Vlan-interface20] mad arp enable

You need to assign a domain ID (range: 0-4294967295)

[Current domain is: 1]:

RBM_S[DeviceB-Vlan-interface20] ip address 10.3.1.2 24

7. On the host, specify 10.1.1.1 (floating IP address) as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify the configuration on Device A:

# Verify that the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Data channel interface current state: Up

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

2. Verify the configuration on Device B:

# Verify that the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Secondary

Device running status: Standby

Data channel interface: GigabitEthernet1/0/3

Data channel interface current state: Up

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Standby Interface status changed

Example: Configuring active/standby RBM in collaboration with a routing protocol

Network configuration

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

· Configure RBM to collaborate with OSPF.

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

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

Figure 27 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Router A:

NOTE:

This step only provides the brief configuration procedure.

# Assign 2.1.1.2/24 to GigabitEthernet 1/0/7.

# Assign 2.1.10.2/24 to GigabitEthernet 1/0/8.

# Configure OSPF for Device A, Device B, and the routers to have Layer 3 reachability.

3. Configure Router B:

NOTE:

This step only provides the brief configuration procedure.

# Assign 10.1.1.2/24 to GigabitEthernet 1/0/7.

# Assign 10.1.10.2/24 to GigabitEthernet 1/0/8.

# Configure OSPF for Device A, Device B, and the routers to have Layer 3 reachability.

4. Configure Device A:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 2.1.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

c. Configure OSPF. Use the default OSPF link cost configuration.

[DeviceA] router id 2.1.1.1

[DeviceA] ospf

[DeviceA-ospf-1] area 0

[DeviceA-ospf-1-area-0.0.0.0] network 2.1.1.0 0.0.0.255

[DeviceA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

[DeviceA-ospf-1-area-0.0.0.0] quit

[DeviceA-ospf-1] quit

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure a rule named trust-untrust to permit the packets from 20.1.1.0/24 to the Internet.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 20.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

# Configure rules to permit OSPF protocol packets.

[DeviceA-security-policy-ip] rule name ospf1

[DeviceA-security-policy-ip-4-ospf1] source-zone trust

[DeviceA-security-policy-ip-4-ospf1] destination-zone local

[DeviceA-security-policy-ip-4-ospf1] service ospf

[DeviceA-security-policy-ip-4-ospf1] action pass

[DeviceA-security-policy-ip-4-ospf1] quit

[DeviceA-security-policy-ip] rule name ospf2

[DeviceA-security-policy-ip-5-ospf2] source-zone local

[DeviceA-security-policy-ip-5-ospf2] destination-zone trust

[DeviceA-security-policy-ip-5-ospf2] service ospf

[DeviceA-security-policy-ip-5-ospf2] action pass

[DeviceA-security-policy-ip-5-ospf2] quit

[DeviceA-security-policy-ip] rule name ospf3

[DeviceA-security-policy-ip-6-ospf3] source-zone untrust

[DeviceA-security-policy-ip-6-ospf3] destination-zone local

[DeviceA-security-policy-ip-6-ospf3] service ospf

[DeviceA-security-policy-ip-6-ospf3] action pass

[DeviceA-security-policy-ip-6-ospf3] quit

[DeviceA-security-policy-ip] rule name ospf4

[DeviceA-security-policy-ip-7-ospf4] source-zone local

[DeviceA-security-policy-ip-7-ospf4] destination-zone untrust

[DeviceA-security-policy-ip-7-ospf4] service ospf

[DeviceA-security-policy-ip-7-ospf4] action pass

[DeviceA-security-policy-ip-7-ospf4] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings.

# Associate track entries with interfaces.

[DeviceA] track 1 interface gigabitethernet 1/0/1

[DeviceA-track-1] quit

[DeviceA] track 2 interface gigabitethernet 1/0/2

[DeviceA-track-2] quit

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] undo backup-mode

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

# Configure RBM to change the link costs advertised in OSPF routes to 6000.

RBM_P[DeviceA-remote-backup-group] adjust-cost ospf enable absolute 6000

# Configure RBM to monitor the status of track entry 1 and track entry 2.

RBM_P[DeviceA-remote-backup-group] track 1

RBM_P[DeviceA-remote-backup-group] track 2

RBM_P[DeviceA-remote-backup-group] quit

f. Configure security services on Device A. (Details not shown.)

5. Configure Device B:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ip address 2.1.10.1 255.255.255.0

[DeviceB-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

c. Configure OSPF. Use the default OSPF link cost configuration.

[DeviceB] router id 2.1.10.1

[DeviceB] ospf

[DeviceB-ospf-1] area 0

[DeviceB-ospf-1-area-0.0.0.0] network 2.1.10.0 0.0.0.255

[DeviceB-ospf-1-area-0.0.0.0] network 10.1.10.0 0.0.0.255

[DeviceB-ospf-1-area-0.0.0.0] quit

[DeviceB-ospf-1] quit

# Associate track entries with interfaces.

[DeviceB] track 1 interface gigabitethernet 1/0/1

[DeviceB-track-1] quit

[DeviceB] track 2 interface gigabitethernet 1/0/2

[DeviceB-track-2] quit

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] undo backup-mode

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

# Configure RBM to change the link costs advertised in OSPF routes to 6000.

RBM_S[DeviceB-remote-backup-group] adjust-cost ospf enable absolute 6000

# Configure RBM to monitor the status of track entry 1 and track entry 2.

RBM_S[DeviceB-remote-backup-group] track 1

RBM_S[DeviceB-remote-backup-group] track 2

RBM_S[DeviceB-remote-backup-group] quit

6. On the host, specify 20.1.1.1 as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify the configuration on Device A:

# Verify that the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that the OSPF routes advertised by Device A include a smaller link cost than that advertised by Device B.

RBM_P[DeviceA] display ospf interface

OSPF Process 1 with Router ID 2.1.1.1

Interfaces

Area: 0.0.0.0

IP Address Type State Cost Pri DR BDR

2.1.1.1 Broadcast BDR 1 1 2.1.1.2 2.1.1.1

10.1.1.1 Broadcast DR 1 1 10.1.1.1 10.1.1.2

2. Verify the configuration on Device B:

# Verify that the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Secondary

Device running status: Standby

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Standby Interface status changed

# Verify that the OSPF routes advertised by Device B include a larger link cost than that advertised by Device A.

RBM_S[DeviceB] display ospf interface

OSPF Process 1 with Router ID 2.1.10.1

Interfaces

Area: 0.0.0.0

IP Address Type State Cost Pri DR BDR

2.1.10.1 Broadcast BDR 6000 1 2.1.10.2 2.1.10.1

10.1.10.1 Broadcast BDR 6000 1 10.1.10.2 10.1.10.1

Example: Configuring dual-active RBM in collaboration with a routing protocol

Network configuration

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

· Configure RBM to collaborate with OSPF.

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

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

Figure 28 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Router A:

NOTE:

This step only provides the brief configuration procedure.

# Assign 2.1.1.2/24 to GigabitEthernet 1/0/7.

# Assign 2.1.10.2/24 to GigabitEthernet 1/0/8.

# Configure OSPF for Device A, Device B, and the routers to have Layer 3 reachability.

# Configure per-flow load sharing for IP forwarding.

3. Configure Router B:

NOTE:

This step only provides the brief configuration procedure.

# Assign 10.1.1.2/24 to GigabitEthernet 1/0/7.

# Assign 10.1.10.2/24 to GigabitEthernet 1/0/8.

# Configure OSPF for Device A, Device B, and the routers to have Layer 3 reachability.

# Configure per-flow load sharing for IP forwarding.

4. Configure Device A:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 2.1.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

c. Configure OSPF. Use the default OSPF link cost configuration.

[DeviceA] router id 2.1.1.1

[DeviceA] ospf

[DeviceA-ospf-1] area 0

[DeviceA-ospf-1-area-0.0.0.0] network 2.1.1.0 0.0.0.255

[DeviceA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255

[DeviceA-ospf-1-area-0.0.0.0] quit

[DeviceA-ospf-1] quit

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure a rule named trust-untrust to permit the packets from 20.1.1.0/24 to the Internet.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 20.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

# Configure rules to permit OSPF protocol packets.

[DeviceA-security-policy-ip] rule name ospf1

[DeviceA-security-policy-ip-4-ospf1] source-zone trust

[DeviceA-security-policy-ip-4-ospf1] destination-zone local

[DeviceA-security-policy-ip-4-ospf1] service ospf

[DeviceA-security-policy-ip-4-ospf1] action pass

[DeviceA-security-policy-ip-4-ospf1] quit

[DeviceA-security-policy-ip] rule name ospf2

[DeviceA-security-policy-ip-5-ospf2] source-zone local

[DeviceA-security-policy-ip-5-ospf2] destination-zone trust

[DeviceA-security-policy-ip-5-ospf2] service ospf

[DeviceA-security-policy-ip-5-ospf2] action pass

[DeviceA-security-policy-ip-5-ospf2] quit

[DeviceA-security-policy-ip] rule name ospf3

[DeviceA-security-policy-ip-6-ospf3] source-zone untrust

[DeviceA-security-policy-ip-6-ospf3] destination-zone local

[DeviceA-security-policy-ip-6-ospf3] service ospf

[DeviceA-security-policy-ip-6-ospf3] action pass

[DeviceA-security-policy-ip-6-ospf3] quit

[DeviceA-security-policy-ip] rule name ospf4

[DeviceA-security-policy-ip-7-ospf4] source-zone local

[DeviceA-security-policy-ip-7-ospf4] destination-zone untrust

[DeviceA-security-policy-ip-7-ospf4] service ospf

[DeviceA-security-policy-ip-7-ospf4] action pass

[DeviceA-security-policy-ip-7-ospf4] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings.

# Associate track entries with interfaces.

[DeviceA] track 1 interface gigabitethernet 1/0/1

[DeviceA-track-1] quit

[DeviceA] track 2 interface gigabitethernet 1/0/2

[DeviceA-track-2] quit

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] backup-mode dual-active

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

RBM_P[DeviceA-remote-backup-group] delay-time 1

# Configure RBM to change the link costs advertised in OSPF routes to 1.

RBM_P[DeviceA-remote-backup-group] adjust-cost ospf enable absolute 1

# Configure RBM to monitor the status of track entry 1 and track entry 2.

RBM_P[DeviceA-remote-backup-group] track 1

RBM_P[DeviceA-remote-backup-group] track 2

RBM_P[DeviceA-remote-backup-group] quit

f. Configure security services on Device A. (Details not shown.)

5. Configure Device B:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ip address 2.1.10.1 255.255.255.0

[DeviceB-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

c. Configure OSPF. Use the default OSPF link cost configuration.

[DeviceB] router id 2.1.10.1

[DeviceB] ospf

[DeviceB-ospf-1] area 0

[DeviceB-ospf-1-area-0.0.0.0] network 2.1.10.0 0.0.0.255

[DeviceB-ospf-1-area-0.0.0.0] network 10.1.10.0 0.0.0.255

[DeviceB-ospf-1-area-0.0.0.0] quit

[DeviceB-ospf-1] quit

d. Configure RBM settings.

# Associate track entries with interfaces.

[DeviceB] track 1 interface gigabitethernet 1/0/1

[DeviceB-track-1] quit

[DeviceB] track 2 interface gigabitethernet 1/0/2

[DeviceB-track-2] quit

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] backup-mode dual-active

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

RBM_S[DeviceB-remote-backup-group] delay-time 1

# Configure RBM to change the link costs advertised in OSPF routes to 1.

RBM_S[DeviceB-remote-backup-group] adjust-cost ospf enable absolute 1

# Configure RBM to monitor the status of track entry 1 and track entry 2.

RBM_S[DeviceB-remote-backup-group] track 1

RBM_S[DeviceB-remote-backup-group] track 2

RBM_S[DeviceB-remote-backup-group] quit

6. On the hosts, specify 20.1.1.1 as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify the configuration on Device A:

# Verify that the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: RBM enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that the OSPF routes advertised by Device A and Device B include the same link cost.

RBM_P[DeviceA] display ospf interface

OSPF Process 1 with Router ID 2.1.1.1

Interfaces

Area: 0.0.0.0

IP Address Type State Cost Pri DR BDR

2.1.1.1 Broadcast BDR 1 1 2.1.1.2 2.1.1.1

10.1.1.1 Broadcast DR 1 1 10.1.1.1 10.1.1.2

2. Verify the configuration on Device B:

# Verify that the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Secondary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that the OSPF routes advertised by Device A and Device B include the same link cost.

RBM_S[DeviceB] display ospf interface

OSPF Process 1 with Router ID 2.1.10.1

Interfaces

Area: 0.0.0.0

IP Address Type State Cost Pri DR BDR

2.1.10.1 Broadcast BDR 1 1 2.1.10.2 2.1.10.1

10.1.10.1 Broadcast BDR 1 1 10.1.10.2 10.1.10.1

Example: Configuring a transparent in-path RBM system in active/standby mode

Network configuration

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

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

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

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

Figure 29 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Switch A:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the router to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

3. Configure Switch B:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the host to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

4. Configure Device A:

a. Configure VLANs.

# Configure the uplink and downlink interfaces to operate at Layer 2.

<DeviceA> system-view

[DeviceA] interface range gigabitethernet 1/0/1 to gigabitethernet 1/0/2

[DeviceA-if-range] port link-mode bridge

[DeviceA-if-range] quit

# Assign the uplink and downlink interfaces to VLAN 10.

[DeviceA] vlan 10

[DeviceA-vlan10] port gigabitethernet 1/0/1

[DeviceA-vlan10] port gigabitethernet 1/0/2

[DeviceA-vlan10] quit

b. Assign an IP address to GigabitEthernet 1/0/3.

[DeviceA] interface gigabitethernet 1/0/3

[DeviceA-GigabitEthernet1/0/3] ip address 10.2.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/3] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

c. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1 vlan 10

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2 vlan 10

[DeviceA-security-zone-Trust] quit

d. Configure a rule named trust-untrust to permit the packets from 10.1.1.0/24 to the Internet.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 10.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings.

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] undo backup-mode

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

# Configure RBM to monitor the status of VLAN 10.

RBM_P[DeviceA-remote-backup-group] track vlan 10

RBM_P[DeviceA-remote-backup-group] quit

f. Configure security services on Device A. (Details not shown.)

5. Configure Device B:

a. Configure VLANs.

# Configure the uplink and downlink interfaces to operate at Layer 2.

<DeviceB> system-view

[DeviceB] interface range gigabitethernet 1/0/1 to gigabitethernet 1/0/2

[DeviceB-if-range] port link-mode bridge

[DeviceB-if-range] quit

# Assign the uplink and downlink interfaces to VLAN 10.

[DeviceB] vlan 10

[DeviceB-vlan10] port gigabitethernet 1/0/1

[DeviceB-vlan10] port gigabitethernet 1/0/2

[DeviceB-vlan10] quit

b. Assign an IP address to GigabitEthernet 1/0/3.

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] ip address 10.2.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/3] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

c. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1 vlan 10

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2 vlan 10

[DeviceB-security-zone-Trust] quit

d. Configure RBM settings.

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] undo backup-mode

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

# Configure RBM to monitor the state of VLAN 10.

RBM_S[DeviceB-remote-backup-group] track vlan 10

RBM_S[DeviceB-remote-backup-group] quit

6. On the host, specify 10.1.1.1 as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify that the RBM channels have been set up on Device A.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

2. Verify that the RBM channels have been set up on Device B.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Secondary

Device running status: Standby

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Standby Interface status changed

Example: Configuring a transparent in-path RBM system in dual-active mode

Network configuration

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

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

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

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

Figure 30 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure OSPF on Router A for the host to access the Internet and for Device A and Device B to load share the traffic sent to the host.

3. Configure OSPF on Router B for the host to access the Internet and for Device A and Device B to load share the traffic sent to the Internet.

4. Configure Device A:

a. Configure VLANs.

# Configure the uplink and downlink interfaces to operate at Layer 2.

<DeviceA> system-view

[DeviceA] interface range gigabitethernet 1/0/1 to gigabitethernet 1/0/2

[DeviceA-if-range] port link-mode bridge

[DeviceA-if-range] quit

# Assign the uplink and downlink interfaces to VLAN 10.

[DeviceA] vlan 10

[DeviceA-vlan10] port gigabitethernet 1/0/1

[DeviceA-vlan10] port gigabitethernet 1/0/2

[DeviceA-vlan10] quit

b. Assign an IP address to GigabitEthernet 1/0/3.

[DeviceA] interface GigabitEthernet 1/0/3

[DeviceA-GigabitEthernet1/0/3] ip address 10.2.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/3] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

c. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1 vlan 10

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2 vlan 10

[DeviceA-security-zone-Trust] quit

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure a rule named trust-untrust to permit the packets from 10.1.1.0/24 to the Internet.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 10.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

# Configure rules to permit OSPF protocol packets.

[DeviceA-security-policy-ip] rule name ospf1

[DeviceA-security-policy-ip-4-ospf1] source-zone trust

[DeviceA-security-policy-ip-4-ospf1] destination-zone untrust

[DeviceA-security-policy-ip-4-ospf1] service ospf

[DeviceA-security-policy-ip-4-ospf1] action pass

[DeviceA-security-policy-ip-4-ospf1] quit

[DeviceA-security-policy-ip] rule name ospf2

[DeviceA-security-policy-ip-5-ospf2] source-zone untrust

[DeviceA-security-policy-ip-5-ospf2] destination-zone trust

[DeviceA-security-policy-ip-5-ospf2] service ospf

[DeviceA-security-policy-ip-5-ospf2] action pass

[DeviceA-security-policy-ip-5-ospf2] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings.

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] backup-mode dual-active

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

RBM_P[DeviceA-remote-backup-group] delay-time 1

# Configure RBM to monitor the status of GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.

RBM_P[DeviceA-remote-backup-group] track interface gigabitethernet 1/0/1

RBM_P[DeviceA-remote-backup-group] track interface gigabitethernet 1/0/2

RBM_P[DeviceA-remote-backup-group] quit

f. Configure security services on Device A. (Details not shown.)

5. Configure Device B:

a. Configure VLANs.

# Configure the uplink and downlink interfaces to operate at Layer 2.

<DeviceB> system-view

[DeviceB] interface range gigabitethernet 1/0/1 to gigabitethernet 1/0/2

[DeviceB-if-range] port link-mode bridge

[DeviceB-if-range] quit

# Assign the uplink and downlink interfaces to VLAN 10.

[DeviceB] vlan 10

[DeviceB-vlan10] port gigabitethernet 1/0/1

[DeviceB-vlan10] port gigabitethernet 1/0/2

[DeviceB-vlan10] quit

b. Assign an IP address to GigabitEthernet 1/0/3.

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] ip address 10.2.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/3] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

c. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1 vlan 10

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2 vlan 10

[DeviceB-security-zone-Trust] quit

d. Configure RBM settings.

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] backup-mode dual-active

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] delay-time 1

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

# Configure RBM to monitor the status of GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.

RBM_S[DeviceB-remote-backup-group] track interface gigabitethernet 1/0/1

RBM_S[DeviceB-remote-backup-group] track interface gigabitethernet 1/0/2

RBM_S[DeviceB-remote-backup-group] quit

6. On the host, specify 10.1.1.1 as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify that the RBM channels have been set up on Device A.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

2. Verify that the RBM channels have been set up on Device B.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Secondary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

Example: Configuring NAT on an active/standby RBM system in collaboration with VRRP

Network configuration

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

· Configure RBM to collaborate with VRRP.

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

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

· Configure dynamic NAT to translate the private IP addresses in the internal network into public IP addresses 2.1.1.1 through 2.1.1.10.

Figure 31 Network diagram

‌

Procedure

1. Set up the RBM system as described in "Example: Configuring active/standby RBM in collaboration with VRRP."

2. Configure dynamic NAT on Device A (primary):

# Create NAT address group 1 and add address range 2.1.1.5 to 2.1.1.10. Associate NAT address group 1 with VRRP group 1.

RBM_P<DeviceA> system-view

RBM_P[DeviceA] nat address-group 1

RBM_P[DeviceA-address-group-1] address 2.1.1.5 2.1.1.10

RBM_P[DeviceA-address-group-1] vrrp vrid 1

RBM_P[DeviceA-address-group-1] quit

# Configure outbound dynamic NAT to use NAT address group 1 for address translation on GigabitEthernet 1/0/1.

RBM_P[DeviceA] interface gigabitethernet 1/0/1

RBM_P[DeviceA-GigabitEthernet1/0/1] nat outbound address-group 1

RBM_P[DeviceA-GigabitEthernet1/0/1] quit

Verifying the configuration

# Verify that the host can communicate with the Internet. (Details not shown.)

# Verify that Device A has generated a NAT session entry.

RBM_P[DeviceA] display nat session verbose

Slot 1:

Initiator:

Source IP/port: 10.1.1.10/52082

Destination IP/port: 202.38.1.10/80

DS-Lite tunnel peer: -

VPN instance/VLAN ID/Inline ID: -/-/-

Protocol: TCP(6)

Inbound interface: GigabitEthernet1/0/2

Source security zone: Trust

Responder:

Source IP/port: 202.38.1.10/80

Destination IP/port: 2.1.1.5/1036

DS-Lite tunnel peer: -

VPN instance/VLAN ID/Inline ID: -/-/-

Protocol: TCP(6)

Inbound interface: GigabitEthernet1/0/1

Source security zone: Untrust

State: TCP_ESTABLISHED

Application: HTTP

Rule ID: 2

Rule name: 3

Start time: 2019-1-29 16:16:59 TTL: 9995s

Initiator->Responder: 551 packets 32547 bytes

Responder->Initiator: 956 packets 1385514 bytes

Total sessions found: 1

Example: Configuring NAT on a dual-active RBM system in collaboration with VRRP

Network configuration

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

· Configure RBM to collaborate with VRRP.

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

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

· Configure dynamic NAT to translate the private IP addresses in the internal network into public IP addresses 2.1.1.1 through 2.1.1.10.

Figure 32 Network diagram

‌

Procedure

1. Set up the RBM system as described in "Example: Configuring dual-active RBM in collaboration with VRRP".

2. Configure dynamic NAT on Device A (primary):

# Create NAT address group 1 and add address range 2.1.1.5 to 2.1.1.7. Associate NAT address group 1 with VRRP group 1.

RBM_P<DeviceA> system-view

RBM_P[DeviceA] nat address-group 1

RBM_P[DeviceA-address-group-1] address 2.1.1.5 2.1.1.7

RBM_P[DeviceA-address-group-1] vrrp vrid 1

RBM_P[DeviceA-address-group-1] quit

# Create NAT address group 2 and add address range 2.1.1.8 to 2.1.1.10. Associate NAT address group 2 with VRRP group 2.

RBM_P[DeviceA] nat address-group 2

RBM_P[DeviceA-address-group-2] address 2.1.1.8 2.1.1.10

RBM_P[DeviceA-address-group-2] vrrp vrid 2

RBM_P[DeviceA-address-group-2] quit

# Configure ACL 3000 to permit packets from 10.1.1.1/25. Configure ACL 3001 to permit packets from 10.1.1.129/25.

RBM_P[DeviceA] acl advanced 3000

RBM_P[DeviceA-ipv4-adv-3000] rule permit ip source 10.1.1.1 0.0.0.127

RBM_P[DeviceA-ipv4-adv-3000] quit

RBM_P[DeviceA] acl advanced 3001

RBM_P[DeviceA-ipv4-adv-3001] rule permit ip source 10.1.1.129 0.0.0.127

RBM_P[DeviceA-ipv4-adv-3001] quit

# Configure outbound dynamic NAT on GigabitEthernet 1/0/1. The source IP addresses of the packets permitted by ACL 3000 are translated into the addresses in NAT address group 1. The source IP addresses of the packets permitted by ACL 3001 are translated into the addresses in NAT address group 2.

RBM_P[DeviceA] interface gigabitethernet 1/0/1

RBM_P[DeviceA-GigabitEthernet1/0/1] nat outbound 3000 address-group 1

RBM_P[DeviceA-GigabitEthernet1/0/1] nat outbound 3001 address-group 2

RBM_P[DeviceA-GigabitEthernet1/0/1] quit

Verifying the configuration

# Verify that Host 1 can communicate with the Internet. (Details not shown.)

# Verify that Device A has generated a NAT session entry.

RBM_P[DeviceA] display nat session verbose

Slot 1:

Initiator:

Source IP/port: 10.1.1.100/52082

Destination IP/port: 202.38.1.10/80

DS-Lite tunnel peer: -

VPN instance/VLAN ID/Inline ID: -/-/-

Protocol: TCP(6)

Inbound interface: GigabitEthernet1/0/2

Source security zone: Trust

Responder:

Source IP/port: 202.38.1.10/80

Destination IP/port: 2.1.1.5/1036

DS-Lite tunnel peer: -

VPN instance/VLAN ID/Inline ID: -/-/-

Protocol: TCP(6)

Inbound interface: GigabitEthernet1/0/1

Source security zone: Untrust

State: TCP_ESTABLISHED

Application: HTTP

Rule ID: 2

Rule name: 3

Start time: 2019-1-29 16:16:59 TTL: 9995s

Initiator->Responder: 551 packets 32547 bytes

Responder->Initiator: 956 packets 1385514 bytes

Total sessions found: 1

# Verify that Host 3 can communicate with the Internet. (Details not shown.)

# Verify that Device B has generated a NAT session entry.

RBM_S[DeviceB] display nat session verbose

Slot 1:

Initiator:

Source IP/port: 10.1.1.200/52082

Destination IP/port: 202.38.1.10/80

DS-Lite tunnel peer: -

VPN instance/VLAN ID/Inline ID: -/-/-

Protocol: TCP(6)

Inbound interface:

Source security zone: Trust

Responder:

Source IP/port: 202.38.1.10/80

Destination IP/port: 2.1.1.8/1036

DS-Lite tunnel peer: -

VPN instance/VLAN ID/Inline ID: -/-/-

Protocol: TCP(6)

Inbound interface:

Source security zone: Untrust

State: TCP_ESTABLISHED

Application: HTTP

Rule ID: 2

Rule name: 3

Start time: 2019-1-29 16:17:59 TTL: 9995s

Initiator->Responder: 551 packets 32547 bytes

Responder->Initiator: 956 packets 1385514 bytes

Total sessions found: 1

Example: Configuring RBM in mirroring mode

Network configuration

As shown in Figure 33, Device A and Device B are border security devices connected to the internal network and the Internet. To improve service stability, set up a RBM system with the devices. Configure the RBM system to operate in mirroring mode. The service interfaces with the same number on the devices use the same IP address. Configure Device A and Device B as the primary device and the secondary device, respectively. Set up MAD to avoid address conflicts between the two devices when the RBM channel is disconnected. When Device A or its attached link fails, Device B takes over to ensure service continuity.

Figure 33 Network diagram

‌

Procedure

1. Verify that the primary and secondary devices have software and hardware environment consistency.

# Before configuring the RBM system, verify that the primary and secondary devices have software and hardware environment consistency. (Details not shown.)

2. Configure Switch A:

# Create VLAN 10, configure the interfaces connected to Device A, Device B, and Router to operate at Layer 2, and assign the interfaces to VLAN 10 as access interfaces.

3. Configure Switch B:

# Create VLAN 10, configure the interfaces connected to Device A, Device B, and Host to operate at Layer 2, and assign the interfaces to VLAN 10 as access interfaces.

4. Configure the router:

# Assign IPv4 address 2.1.1.15/24 to GigabitEthernet 7/0/1.

# Configure routes as follows:

¡ Specify 2.1.1.1 as the next hop of the route to the internal network.

¡ Specify the IP address of the peer interface attached to the traffic outgoing interface as the next hop of the route to the Internet.

5. Configure Device A:

a. Assign IPv4 addresses to interfaces

# Assign IPv4 addresses to interfaces according to the network diagram.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ip address 2.1.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] ip address 10.1.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/2] quit

[DeviceA] interface gigabitethernet 1/0/3

[DeviceA-GigabitEthernet1/0/3] ip address 10.2.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/3] quit

[DeviceA] interface gigabitethernet 1/0/5

[DeviceA-GigabitEthernet1/0/5] ip address 10.3.1.1 255.255.255.0

[DeviceA-GigabitEthernet1/0/5] quit

b. Add interfaces to security zones.

# Add interfaces to security zones according to the network diagram.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

[DeviceA] security-zone name dmz

[DeviceA-security-zone-DMZ] import interface gigabitethernet 1/0/5

[DeviceA-security-zone-DMZ] quit

c. Configure route settings for network connectivity.

This example takes static route configuration as an example. Configure route settings according to the actual network requirements.

# Configure a static route for Layer 3 connectivity between the internal and external networks according to the network diagram. The next hop for the static route to the external network is 2.1.1.15.

[DeviceA] ip route-static 0.0.0.0 0.0.0.0 2.1.1.15

d. Configure security policy settings to permit specific service packets:

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Create a security policy rule named trust-untrust to allow internal network users to access the Internet and prevent Internet users to access the internal network.

[DeviceA] security-policy ip

[DeviceA-security-policy-ip] rule name trust-untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ip-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ip-3-trust-untrust] source-ip-subnet 10.1.1.0 24

[DeviceA-security-policy-ip-3-trust-untrust] action pass

[DeviceA-security-policy-ip-3-trust-untrust] quit

# Configure a security policy rule named loglocalout to allow Device to send fast log information to the log host.

[DeviceA-security-policy-ip] rule name loglocalout

[DeviceA-security-policy-ip-4-loglocalout] source-zone local

[DeviceA-security-policy-ip-4-loglocalout] destination-zone dmz

[DeviceA-security-policy-ip-4-loglocalout] action pass

[DeviceA-security-policy-ip-4-loglocalout] quit

[DeviceA-security-policy-ip] quit

e. Configure RBM settings

# Configure Track to monitor status of interfaces.

[DeviceA] track 1 interface gigabitethernet 1/0/1

[DeviceA-track-1] quit

[DeviceA] track 2 interface gigabitethernet 1/0/2

[DeviceA-track-2] quit

# Specify two devices for the RBM system, with Device A as the primary device, and Device B as the secondary device. When Device A or its attached link fails, Device B takes over to ensure service continuity.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ip 10.2.1.2

[DeviceA-remote-backup-group] local-ip 10.2.1.1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] backup-mode mirror-mode

[DeviceA-remote-backup-group] device-role auto

RBM_MIRROR_P[DeviceA-remote-backup-group] hot-backup enable

RBM_MIRROR_P[DeviceA-remote-backup-group] configuration auto-sync enable route-static

RBM_MIRROR_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_MIRROR_P[DeviceA-remote-backup-group] configuration sync-check interval 12

# Configure the management interface for the mirroring mode to connect to the network management device and log host.

RBM_MIRROR_P[DeviceA-remote-backup-group] mirror mgt-interface gigabitethernet 1/0/5

# Associate the RBM system with track entries 1 and 2.

RBM_MIRROR_P[DeviceA-remote-backup-group] track 1

RBM_MIRROR_P[DeviceA-remote-backup-group] track 2

RBM_MIRROR_P[DeviceA-remote-backup-group] quit

f. Configure ARP MAD to avoid address conflicts between the two devices when the RBM channel is disconnected.

# Create VLAN 20, and assign GigabitEthernet1/0/4 on Device A to VLAN 20.

RBM_MIRROR_P[DeviceA] vlan 20

RBM_MIRROR_P[DeviceA-vlan20] quit

RBM_MIRROR_P[DeviceA] interface gigabitethernet 1/0/4

RBM_MIRROR_P[DeviceA-GigabitEthernet1/0/4] port link-mode bridge

RBM_MIRROR_P[DeviceA-GigabitEthernet1/0/4] port access vlan 20

RBM_MIRROR_P[DeviceA-GigabitEthernet1/0/4] quit

# Create VLAN-interface 20, assign an IP address to the interface, and enable ARP MAD.

RBM_MIRROR_P[DeviceA] interface vlan-interface 20

RBM_MIRROR_P[DeviceA-Vlan-interface20] ip address 10.3.1.1 24

RBM_MIRROR_P[DeviceA-Vlan-interface20] mad arp enable

You need to assign a domain ID (range: 0-4294967295)

[Current domain is: 1]:

The assigned domain ID is: 1

g. Configure security services on Device A. (Details not shown.)

# After completing RBM system configuration, configure security services. Configure the modules whose configuration information can be backed up by the RBM system only on the primary device (Device A).

6. Configure Device B:

a. ‍Assign IPv4 addresses to interfaces

# Assign IPv4 addresses to interfaces according to the network diagram. (The configuration is not required for the interfaces except the mirroring-mode management interface and RBM channel interface. The IP address of such interfaces will be automatically synchronized to the standby device.)

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] ip address 10.2.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/3] quit

[DeviceB] interface gigabitethernet 1/0/5

[DeviceB-GigabitEthernet1/0/5] ip address 10.3.1.2 255.255.255.0

[DeviceB-GigabitEthernet1/0/5] quit

b. Add interfaces to security zones.

# Add interfaces to security zones according to the network diagram.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

[DeviceB] security-zone name dmz

[DeviceB-security-zone-DMZ] import interface gigabitethernet 1/0/5

[DeviceB-security-zone-DMZ] quit

c. Configure RBM settings

# Configure Track to monitor status of interfaces.

[DeviceB] track 1 interface gigabitethernet 1/0/1

[DeviceB-track-1] quit

[DeviceB] track 2 interface gigabitethernet 1/0/2

[DeviceB-track-2] quit

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ip 10.2.1.1

[DeviceB-remote-backup-group] local-ip 10.2.1.2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] backup-mode mirror-mode

[DeviceB-remote-backup-group] device-role auto

RBM_MIRROR_S[DeviceB-remote-backup-group] hot-backup enable

RBM_MIRROR_S[DeviceB-remote-backup-group] configuration auto-sync enable route-static

RBM_MIRROR_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_MIRROR_S[DeviceB-remote-backup-group] configuration sync-check interval 12

# Configure the mirroring-mode management interface for connecting to the network management device and log host and for performing MAD.

RBM_MIRROR_S[DeviceB-remote-backup-group] mirror mgt-interface gigabitethernet 1/0/5

# Associate the hot backup system with track entries 1 and 2.

RBM_MIRROR_S[DeviceB-remote-backup-group] track 1

RBM_MIRROR_S[DeviceB-remote-backup-group] track 2

RBM_MIRROR_S[DeviceB-remote-backup-group] quit

d. Configure ARP MAD

# Create VLAN 20, and assign GigabitEthernet1/0/4 on Device B to VLAN 20.

RBM_MIRROR_S[DeviceB] vlan 20

RBM_MIRROR_S[DeviceB-vlan20] quit

RBM_MIRROR_S[DeviceB] interface gigabitethernet 1/0/4

RBM_MIRROR_S[DeviceB-GigabitEthernet1/0/4] port link-mode bridge

RBM_MIRROR_S[DeviceB-GigabitEthernet1/0/4] port access vlan 20

RBM_MIRROR_S[DeviceB-GigabitEthernet1/0/4] quit

# Create VLAN-interface 20, assign an IP address to the interface, and enable ARP MAD. (The IP address configuration is not required, because mirroring-mode interface IP addresses will be automatically synchronized.)

RBM_MIRROR_S[DeviceB] interface vlan-interface 20

RBM_MIRROR_S[DeviceB-Vlan-interface20] mad arp enable

You need to assign a domain ID (range: 0-4294967295)

[Current domain is: 1]:

The assigned domain ID is: 1

7. Configure the host

# Specify the default gateway as 10.1.1.1 (virtual IPv4 address) for the host.

Verifying the configuration

1. Device A:

# Verify that the RBM settings have taken effect and the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Mirroring

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Data channel interface current state: Up

Local IP: 10.2.1.1

Remote IP: 10.2.1.2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

2. Device B:

# Verify that the RBM settings have taken effect and the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Mirroring

Device management role: Secondary

Device running status: Standby

Data channel interface: GigabitEthernet1/0/3

Data channel interface current state: Up

Local IP: 10.2.1.2

Remote IP: 10.2.1.1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Standby Interface status changed

RBM configuration examples‌ (IPv6)

Example: Configuring active/standby RBM in collaboration with VRRP

Network configuration

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

· Configure RBM to collaborate with VRRP.

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

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

Figure 34 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Switch A:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the router to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

3. Configure Switch B:

NOTE:

This step only provides the brief configuration procedure.

# Create VLAN 10.

# Configure the interfaces attached to the RBM system and the host to operate at Layer 2. Assign them to VLAN 10 as access interfaces.

4. Configure the router:

NOTE:

This step only provides the brief configuration procedure.

# Assign 3003::15/64 to GigabitEthernet 1/0/7.

# Configure routes as follows:

¡ Specify 3003::3/64 (virtual IP address of VRRP group 1) as the next hop of the routes to the internal network.

¡ Specify the IP address of the peer interface attached to the traffic outgoing interface as the next hop of the route to the Internet.

5. Configure Device A:

a. Assign IP addresses to interfaces.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ipv6 address 3003::1/64

[DeviceA-GigabitEthernet1/0/1] ipv6 address fe80::3:1 link-local

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface gigabitethernet 1/0/2

[DeviceA-GigabitEthernet1/0/2] ipv6 address 3001::1/64

[DeviceA-GigabitEthernet1/0/2] ipv6 address fe80::1:1 link-local

[DeviceA-GigabitEthernet1/0/2] undo ipv6 nd ra halt

[DeviceA-GigabitEthernet1/0/2] quit

[DeviceA] interface gigabitethernet 1/0/3

[DeviceA-GigabitEthernet1/0/3] ipv6 address 3005::1/64

[DeviceA-GigabitEthernet1/0/3] ipv6 address auto link-local

[DeviceA-GigabitEthernet1/0/3] quit

b. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

c. Configure settings for routing. This example configures a static route, and the next hop in the route is 3003::15.

[DeviceA] ipv6 route-static 0::0 0 3003::15

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure security policy rule named trust-untrust to permit the packets from 3001::0/64 to the Internet.

[DeviceA] security-policy ipv6

[DeviceA-security-policy-ipv6] rule name trust-untrust

[DeviceA-security-policy-ipv6-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ipv6-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ipv6-3-trust-untrust] source-ip-subnet 3001::0 64

[DeviceA-security-policy-ipv6-3-trust-untrust] action pass

[DeviceA-security-policy-ipv6-3-trust-untrust] quit

# Configure rules to permit VRRP protocol packets. When the RBM channel is disconnected, Device A and Device B can exchange VRRP protocol packets to elect a VRRP master.

[DeviceA-security-policy-ipv6] rule name vrrp1

[DeviceA-security-policy-ipv6-4-vrrp1] source-zone trust

[DeviceA-security-policy-ipv6-4-vrrp1] destination-zone local

[DeviceA-security-policy-ipv6-4-vrrp1] service vrrp

[DeviceA-security-policy-ipv6-4-vrrp1] action pass

[DeviceA-security-policy-ipv6-4-vrrp1] quit

[DeviceA-security-policy-ipv6] rule name vrrp2

[DeviceA-security-policy-ipv6-5-vrrp2] source-zone local

[DeviceA-security-policy-ipv6-5-vrrp2] destination-zone trust

[DeviceA-security-policy-ipv6-5-vrrp2] service vrrp

[DeviceA-security-policy-ipv6-5-vrrp2] action pass

[DeviceA-security-policy-ipv6-5-vrrp2] quit

[DeviceA-security-policy-ipv6] rule name vrrp3

[DeviceA-security-policy-ipv6-6-vrrp3] source-zone untrust

[DeviceA-security-policy-ipv6-6-vrrp3] destination-zone local

[DeviceA-security-policy-ipv6-6-vrrp3] service vrrp

[DeviceA-security-policy-ipv6-6-vrrp3] action pass

[DeviceA-security-policy-ipv6-6-vrrp3] quit

[DeviceA-security-policy-ipv6] rule name vrrp4

[DeviceA-security-policy-ipv6-7-vrrp4] source-zone local

[DeviceA-security-policy-ipv6-7-vrrp4] destination-zone untrust

[DeviceA-security-policy-ipv6-7-vrrp4] service vrrp

[DeviceA-security-policy-ipv6-7-vrrp4] action pass

[DeviceA-security-policy-ipv6-7-vrrp4] quit

[DeviceA-security-policy-ipv6] quit

e. Configure RBM settings.

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ipv6 3005::2

[DeviceA-remote-backup-group] local-ipv6 3005::1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] undo backup-mode

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

RBM_P[DeviceA-remote-backup-group] quit

# Create VRRP groups and associate them with RBM. The first virtual IPv6 address of an IPv6 VRRP group must be a link-local address.

RBM_P[DeviceA] interface gigabitethernet 1/0/1

RBM_P[DeviceA-GigabitEthernet1/0/1] vrrp ipv6 vrid 1 virtual-ip fe80::3:3 link-local active

RBM_P[DeviceA-GigabitEthernet1/0/1] vrrp ipv6 vrid 1 virtual-ip 3003::3

RBM_P[DeviceA-GigabitEthernet1/0/1] quit

RBM_P[DeviceA] interface gigabitethernet 1/0/2

RBM_P[DeviceA-GigabitEthernet1/0/2] vrrp ipv6 vrid 2 virtual-ip fe80::1:3 link-local active

RBM_P[DeviceA-GigabitEthernet1/0/2] vrrp ipv6 vrid 2 virtual-ip 3001::3

RBM_P[DeviceA-GigabitEthernet1/0/2] quit

f. Configure security services on Device A. (Details not shown.)

6. Configure Device B:

a. Assign IP addresses to interfaces.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ipv6 address 3003::2/64

[DeviceB-GigabitEthernet1/0/1] ipv6 address fe80::3:2 link-local

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface gigabitethernet 1/0/2

[DeviceB-GigabitEthernet1/0/2] ipv6 address 3001::2/64

[DeviceB-GigabitEthernet1/0/2] ipv6 address fe80::1:2 link-local

[DeviceB-GigabitEthernet1/0/2] undo ipv6 nd ra halt

[DeviceB-GigabitEthernet1/0/2] quit

[DeviceB] interface gigabitethernet 1/0/3

[DeviceB-GigabitEthernet1/0/3] ipv6 address 3005::2/64

[DeviceB-GigabitEthernet1/0/3] ipv6 address auto link-local

[DeviceB-GigabitEthernet1/0/3] quit

b. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

c. Configure settings for routing. This example configures a static route, and the next hop in the route is 3003::15.

[DeviceB] ipv6 route-static 0::0 0 3003::15

d. Configure RBM settings.

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ipv6 3005::1

[DeviceB-remote-backup-group] local-ipv6 3005::2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] undo backup-mode

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

RBM_S[DeviceB-remote-backup-group] quit

# Create VRRP groups and associate them with RBM. The first virtual IPv6 address of an IPv6 VRRP group must be a link-local address.

RBM_S[DeviceB] interface gigabitethernet 1/0/1

RBM_S[DeviceB-GigabitEthernet1/0/1] vrrp ipv6 vrid 1 virtual-ip fe80::3:3 link-local standby

RBM_S[DeviceB-GigabitEthernet1/0/1] vrrp ipv6 vrid 1 virtual-ip 3003::3

RBM_S[DeviceB-GigabitEthernet1/0/1] quit

RBM_S[DeviceB] interface gigabitethernet 1/0/2

RBM_S[DeviceB-GigabitEthernet1/0/2] vrrp ipv6 vrid 2 virtual-ip fe80::1:3 link-local standby

RBM_S[DeviceB-GigabitEthernet1/0/2] vrrp ipv6 vrid 2 virtual-ip 3001::3

RBM_S[DeviceB-GigabitEthernet1/0/2] quit

7. On the host, specify 3001::3 (virtual IP address of VRRP group 2) as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify the configuration on Device A:

# Verify that the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IPv6: 3005::1

Remote IPv6: 3005::2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that Device A is the master in all VRRP groups.

RBM_P[DeviceA] display vrrp ipv6

IPv6 Virtual Router Information:

Running mode : Standard

RBM control channel is established

IPv6 VRRP active group status : Master

IPv6 VRRP standby group status: Master

Total number of virtual routers : 2

Interface VRID State Running Adver Auth Virtual

Pri Timer Type IP

---------------------------------------------------------------------

GE1/0/1 1 Master 100 100 None FE80::3:3

GE1/0/2 2 Master 100 100 None FE80::1:3

2. Verify the configuration on Device B:

# Verify that the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Active/standby

Device management role: Secondary

Device running status: Standby

Data channel interface: GigabitEthernet1/0/3

Local IPv6: 3005::2

Remote IPv6: 3005::1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Standby Interface status changed

# Verify that Device A is the backup in all VRRP groups.

RBM_S[DeviceB] display vrrp ipv6

IPv6 Virtual Router Information:

Running mode : Standard

RBM control channel is established

IPv6 VRRP active group status : Backup

IPv6 VRRP standby group status: Backup

Total number of virtual routers : 2

Interface VRID State Running Adver Auth Virtual

Pri Timer Type IP

---------------------------------------------------------------------

GE1/0/1 1 Backup 100 100 None FE80::3:3

GE1/0/2 2 Backup 100 100 None FE80::1:3

Example: Configuring dual-active RBM in collaboration with a routing protocol

Network configuration

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

· Configure RBM to collaborate with OSPFv3.

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

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

Figure 35 Network diagram

‌

Procedure

1. Verify that Device A and Device B have software and hardware environment consistency.

2. Configure Router A:

NOTE:

This step only provides the brief configuration procedure.

# Assign 3003::2/64 to GigabitEthernet 1/0/7.

# Assign 3004::2/64 to GigabitEthernet 1/0/8.

# Configure OSPFv3 for Device A, Device B, and the routers to have Layer 3 reachability.

# Configure per-flow load sharing for IP forwarding.

3. Configure Router B:

NOTE:

This step only provides the brief configuration procedure.

# Assign 3001::2/64 to GigabitEthernet 1/0/7.

# Assign 3002::2/64 to GigabitEthernet 1/0/8.

# Configure OSPFv3 for Device A, Device B, and the routers to have Layer 3 reachability.

# Configure per-flow load sharing for IP forwarding.

4. Configure Device A:

a. Assign an IP address to GigabitEthernet 1/0/1.

<DeviceA> system-view

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ipv6 address 3003::1/64

[DeviceA-GigabitEthernet1/0/1] ipv6 address auto link-local

[DeviceA-GigabitEthernet1/0/1] quit

# Assign IP addresses to other interfaces in the same way. (Details not shown.)

b. Add interfaces to security zones.

[DeviceA] security-zone name untrust

[DeviceA-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceA-security-zone-Untrust] quit

[DeviceA] security-zone name trust

[DeviceA-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceA-security-zone-Trust] quit

c. Configure OSPFv3. Use the default OSPFv3 link cost configuration.

[DeviceA] ospfv3 1

[DeviceA-ospfv3-1] router-id 2.1.1.1

[DeviceA-ospfv3-1] quit

[DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] ospfv3 1 area 0

[DeviceA-GigabitEthernet1/0/1] quit

[DeviceA] interface GigabitEthernet1/0/2

[DeviceA-GigabitEthernet1/0/2] ospfv3 1 area 0

[DeviceA-GigabitEthernet1/0/2] quit

d. Configure a security policy.

Perform this task only on the primary device. After the RBM system is set up, the secondary device automatically synchronizes its security policy configuration with the primary device.

# Configure security policy rule named trust-untrust to permit the packets from 2001::0/64 to the Internet.

[DeviceA] security-policy ipv6

[DeviceA-security-policy-ipv6] rule name trust-untrust

[DeviceA-security-policy-ipv6-3-trust-untrust] source-zone trust

[DeviceA-security-policy-ipv6-3-trust-untrust] destination-zone untrust

[DeviceA-security-policy-ipv6-3-trust-untrust] source-ip-subnet 2001::0 64

[DeviceA-security-policy-ipv6-3-trust-untrust] action pass

[DeviceA-security-policy-ipv6-3-trust-untrust] quit

# Configure rules to permit OSPFv3 protocol packets.

[DeviceA-security-policy-ipv6] rule name ospf1

[DeviceA-security-policy-ipv6-4-ospf1] source-zone trust

[DeviceA-security-policy-ipv6-4-ospf1] destination-zone local

[DeviceA-security-policy-ipv6-4-ospf1] service ospf

[DeviceA-security-policy-ipv6-4-ospf1] action pass

[DeviceA-security-policy-ipv6-4-ospf1] quit

[DeviceA-security-policy-ipv6] rule name ospf2

[DeviceA-security-policy-ipv6-5-ospf2] source-zone local

[DeviceA-security-policy-ipv6-5-ospf2] destination-zone trust

[DeviceA-security-policy-ipv6-5-ospf2] service ospf

[DeviceA-security-policy-ipv6-5-ospf2] action pass

[DeviceA-security-policy-ipv6-5-ospf2] quit

[DeviceA-security-policy-ipv6] rule name ospf3

[DeviceA-security-policy-ipv6-6-ospf3] source-zone untrust

[DeviceA-security-policy-ipv6-6-ospf3] destination-zone local

[DeviceA-security-policy-ipv6-6-ospf3] service ospf

[DeviceA-security-policy-ipv6-6-ospf3] action pass

[DeviceA-security-policy-ipv6-6-ospf3] quit

[DeviceA-security-policy-ipv6] rule name ospf4

[DeviceA-security-policy-ipv6-7-ospf4] source-zone local

[DeviceA-security-policy-ipv6-7-ospf4] destination-zone untrust

[DeviceA-security-policy-ipv6-7-ospf4] service ospf

[DeviceA-security-policy-ipv6-7-ospf4] action pass

[DeviceA-security-policy-ipv6-7-ospf4] quit

[DeviceA-security-policy-ipv6] quit

e. Configure RBM settings.

# Associate track entries with interfaces.

[DeviceA] track 1 interface gigabitethernet 1/0/1

[DeviceA-track-1] quit

[DeviceA] track 2 interface gigabitethernet 1/0/2

[DeviceA-track-2] quit

# Set up an RBM system.

[DeviceA] remote-backup group

[DeviceA-remote-backup-group] remote-ipv6 3005::2

[DeviceA-remote-backup-group] local-ipv6 3005::1

[DeviceA-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceA-remote-backup-group] device-role primary

RBM_P[DeviceA-remote-backup-group] backup-mode dual-active

RBM_P[DeviceA-remote-backup-group] hot-backup enable

RBM_P[DeviceA-remote-backup-group] configuration auto-sync enable

RBM_P[DeviceA-remote-backup-group] configuration sync-check interval 12

RBM_P[DeviceA-remote-backup-group] delay-time 1

# Configure RBM to change the link costs advertised in OSPFv3 routes to 1.

RBM_P[DeviceA-remote-backup-group] adjust-cost ospfv3 enable absolute 1

# Configure RBM to monitor the status of track entry 1 and track entry 2.

RBM_P[DeviceA-remote-backup-group] track 1

RBM_P[DeviceA-remote-backup-group] track 2

RBM_P[DeviceA-remote-backup-group] quit

f. Configure security services on Device A. (Details not shown.)

5. Configure Device B:

a. Assign IP addresses to interfaces. This step uses GigabitEthernet 1/0/1 as an example.

<DeviceB> system-view

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ipv6 address 3004::1/64

[DeviceB-GigabitEthernet1/0/1] ipv6 address auto link-local

[DeviceB-GigabitEthernet1/0/1] quit

b. Add interfaces to security zones.

[DeviceB] security-zone name untrust

[DeviceB-security-zone-Untrust] import interface gigabitethernet 1/0/1

[DeviceB-security-zone-Untrust] quit

[DeviceB] security-zone name trust

[DeviceB-security-zone-Trust] import interface gigabitethernet 1/0/2

[DeviceB-security-zone-Trust] quit

c. Configure OSPFv3. Use the default OSPFv3 link cost configuration.

[DeviceB] ospfv3 1

[DeviceB-ospfv3-1] router-id 3.1.1.1

[DeviceB-ospfv3-1] quit

[DeviceB] interface gigabitethernet 1/0/1

[DeviceB-GigabitEthernet1/0/1] ospfv3 1 area 0

[DeviceB-GigabitEthernet1/0/1] quit

[DeviceB] interface GigabitEthernet1/0/2

[DeviceB-GigabitEthernet1/0/2] ospfv3 1 area 0

[DeviceB-GigabitEthernet1/0/2] quit

d. Configure RBM settings.

# Associate track entries with interfaces.

[DeviceB] track 1 interface gigabitethernet 1/0/1

[DeviceB-track-1] quit

[DeviceB] track 2 interface gigabitethernet 1/0/2

[DeviceB-track-2] quit

# Set up an RBM system.

[DeviceB] remote-backup group

[DeviceB-remote-backup-group] remote-ipv6 3005::1

[DeviceB-remote-backup-group] local-ipv6 3005::2

[DeviceB-remote-backup-group] data-channel interface gigabitethernet 1/0/3

[DeviceB-remote-backup-group] device-role secondary

RBM_S[DeviceB-remote-backup-group] backup-mode dual-active

RBM_S[DeviceB-remote-backup-group] hot-backup enable

RBM_S[DeviceB-remote-backup-group] configuration auto-sync enable

RBM_S[DeviceB-remote-backup-group] configuration sync-check interval 12

RBM_S[DeviceB-remote-backup-group] delay-time 1

# Configure RBM to change the link costs advertised in OSPFv3 routes to 1.

RBM_S[DeviceB-remote-backup-group] adjust-cost ospfv3 enable absolute 1

# Configure RBM to monitor the status of track entry 1 and track entry 2.

RBM_S[DeviceB-remote-backup-group] track 1

RBM_S[DeviceB-remote-backup-group] track 2

RBM_S[DeviceB-remote-backup-group] quit

6. On the hosts, specify 2002::1 as the default gateway. (Details not shown.)

Verifying the configuration

1. Verify the configuration on Device A:

# Verify that the RBM channels have been set up.

RBM_P[DeviceA] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Primary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IPv6: 3005::1

Remote IPv6: 3005::2 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that the OSPFv3 routes advertised by Device A and Device B include the same link cost.

RBM_P[DeviceA] display ospfv3 interface

OSPFv3 Process 1 with Router ID 2.1.1.1

Area: 0.0.0.0

-------------------------------------------------------------------------

ID State Cost Pri DR BDR Ins Name

2 DR 1 1 2.1.1.1 1.1.1.1 0 GE1/0/1

3 BDR 1 1 4.1.1.1 2.1.1.1 0 GE1/0/2

2. Verify the configuration on Device B:

# Verify that the RBM channels have been set up.

RBM_S[DeviceB] display remote-backup-group status

Remote backup group information:

Backup mode: Dual-active

Device management role: Secondary

Device running status: Active

Data channel interface: GigabitEthernet1/0/3

Local IPv6: 3005::2

Remote IPv6: 3005::1 Destination port: 60064

Control channel status: Connected

Keepalive interval: 1s

Keepalive count: 10

Configuration consistency check interval: 12 hour

Configuration consistency check result: Not Performed

Configuration backup status: Auto sync enabled

Session backup status: Hot backup enabled

Delay-time: 1 min

Uptime since last switchover: 0 days, 3 hours, 11 minutes

Switchover records:

Time Status change Cause

2021-06-22 13:33:33 Initial to Active Interface status changed

# Verify that the OSPFv3 routes advertised by Device A and Device B include the same link cost.

RBM_S[DeviceB] display ospfv3 interface

OSPFv3 Process 1 with Router ID 3.1.1.1

Area: 0.0.0.0

-------------------------------------------------------------------------

ID State Cost Pri DR BDR Ins Name

2 DR 1 1 3.1.1.1 1.1.1.1 0 GE1/0/1

3 BDR 1 1 4.1.1.1 3.1.1.1 0 GE1/0/2

16-High Availability Configuration Guide

Configuring RBM-based hot backup

RBM packets

Transparent in-path deployment of RBM

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedures

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

About this task

Restrictions and guidelines

Procedure

About this task

Feature and hardware compatibility

Restrictions and guidelines

Procedure

About this task

Procedure

Configuring MAD

Configuring ARP MAD

Configuring ND MAD

About this task

Feature and hardware compatibility

Restrictions and guidelines

Procedure

About this task

Restrictions and guidelines

Procedure

About this task