A multi-device backup platform runs Huawei proprietary Redundancy User Information (RUI) protocol to back up user information between devices in a Virtual Router Redundancy Protocol (VRRP) group. This allows fast service switching to be performed if a network node or link fails, enhancing service reliability.
Prerequisites
Before establishing a multi-device backup platform, complete the following tasks:
Configure peer BFD, link BFD, or Ethernet OAM on the user side.
Configure peer BFD on the network side.
Configure a local or remote address pool. The same address pool must be configured on devices that back up one another.
Background
Establishing a multi-device backup platform includes configuring basic VRRP group functions, a remote backup profile (RBP), and a remote backup service (RBS).
Perform the following steps on both the master and backup devices:
Procedure
- Configure basic VRRP group functions.
- Run system-view
The system view is displayed.
- Run interface interface-type interface-number [.subinterface-number ]
The view of the interface on which a VRRP group is configured is displayed.
- Run vrrp vrid virtual-router-id virtual-ip virtual-address
A VRRP group is created, and a virtual IP address is assigned to the VRRP group.
The same VRID and virtual IP address must be set on each of devices that back up one another.
- Run admin-vrrp vrid virtual-router-id [ ignore-if-down ]
The VRRP group is configured as an mVRRP group.
- Run vrrp vrid virtual-router-id priority priority-value
The priority of a device in the VRRP group is configured.
The devices in the VRRP group must be assigned different VRRP priorities. The device with a higher priority serves as the master.
- Run vrrp vrid virtual-router-id preempt-mode timer delay delay-time
A preemption delay is set for the master device in the VRRP group.
This ensures that the device preempts the master role after the fault is rectified and services are fully restored.
The preemption delay is related to service types in the following scenarios:
- In an IPv4 single-stack scenario, the minimum preemption delay is 10 minutes. Increase the value by 1 for every 6K users. If 256K users go online through a device, setting the value to 40 minutes is recommended.
- In an IPv4 and IPv6 dual-stack scenario, the minimum preemption delay is 10 minutes. Increase the value by 1 for every 6K users. If 128K users go online through a device, setting the value to 40 minutes is recommended.
- When the IPv4 single-stack and EDSG services are configured, the minimum preemption delay is 15 minutes. Increase the value by 1 for every 4K users. If 256K users go online through a device, setting the value to 60 minutes is recommended.
- When the IPv4 and IPv6 dual-stack and EDSG services are configured, the minimum preemption delay is 15 minutes. Increase the value by 1 for every 4K users. If 128K dual-stack users go online through a device, setting the value to 60 minutes is recommended.
- Run commit
The configuration is committed.
- Configure an RBP.
- (Optional) Run peer-backup batch access enable
The device is configured to allow users to go online when performing batch backup.
- Run system-view
The system view is displayed.
- Run remote-backup-profile profile-name
An RBP is created, and the RBP view is displayed.
- Run peer-backup hot
Inter-device hot backup is enabled.
- Run vrrp-id vrid interface { interface-name | interface-type interface-number
The RBP is bound to the VRRP group.
- In multi-device backup networking, using load balancing improves link usage. To load-balance traffic, use either of the following parameters:
- odd-mac: user packets with odd MAC addresses
- even-mac: user packets with even MAC addresses
- If odd-mac or even-mac is not configured, the vrrp-id command only binds a single VRRP group ID to an RBP and associates the RBP with a single VRRP sub-interface. If load balancing is required, run the vrrp-id command twice, with odd-mac and even-mac configured, respectively. Two VRRP group IDs must be bound to the same RBP and be associated with different VRRP sub-interfaces. In addition, odd-mac and even-mac must be configured for different VRRP groups with specific IDs. The two devices that load-balance traffic must have the same configuration, including the binding between the VRRP group ID and even or odd MAC address type.
- Before modifying the setting of odd-mac or even-mac, run the undo vrrp-idvrid command to delete the configuration. Then run the vrrp-idvrid command to reconfigure the setting.
- Run backup-id backup-id remote-backup-service service-name
The RBP is associated with the RBS, and the user backup ID in the RBP is set.
backup-id sets a user backup ID. The RBP to which a user belongs can be determined based on the backup-id and RBS. Note that the same backup-id value must be set for devices that back up one another in the same RBP, and different backup-id values must be set in other RBPs.
- Run service-type { arp | l2tp| bras | multicast | igmp | igmp-snooping | no-host-multicast | dhcp-server | nd }
Remote backup for user services is enabled.
- Run commit
The configuration is committed.
- (Optional) Run acct-session-id nas-logic-sysname host-name
A logic host name is configured to generate an RUI user accounting ID.
- (Optional) Run load-balance hash-arithmetic { arithmetic1 | arithmetic2 } [ hash-fields mac offsetmac-offset ]
A hash algorithm for load balancing based on odd and even MAC addresses is configured on the interface board.
- (Optional) Run bras access remark mac mac-address { odd-mac | even-mac }
The device is enabled to mark a specified MAC address as an odd or even MAC address.
- Run commit
The configuration is committed.
- Configure an RBS.
- Run system-view
The system view is displayed.
- Run remote-backup-service service-name
An RBS is created, and the RBS view is displayed.
If both a dynamic BFD session and a static BFD session are configured on a BRAS to detect the same link, BFD parameters of one BFD session take effect. Specifically, when an RBS is configured, a dynamic BFD session is created, and BFD parameters are generated. The system compares BFD parameters of the static BFD session with dynamically generated BFD parameters, and BFD parameters with smaller values take effect.
- (Optional) Run bind ssl-policy ssl-policy-name
An SSL policy is created and bound to a TCP connection.
You are advised to bind an SSL policy to enhance RBS security. If no SSL policy is bound, data leakage and tampering may occur.
- Run peer peer-ip-address source source-ip-address port port-id
Parameters of a TCP connection for the RBS are set.
peer-ip-address sets the IP address of a remote device that backs up the local device. source-ip-address sets the IP address of a local device. The remote IP address must be already assigned to the remote device's main interface, sub-interface, or logical interface (for example, loopback interface). The local IP address must be already assigned to the local device's main interface, sub-interface, or logical interface. The local and remote IP addresses must be pinged by each other.
port-id indicates the listening port number of a server. The same TCP port number must be set on devices that back up one another.
- (Optional) Run batch-backup service-type { arp | all| bras | l2tp | multicast | igmp-snooping | dhcp-server | nd } now
The device is enabled to immediately back up user services configured in the RBS.
- (Optional) Run track interface { interface-name | interface-type interface-number } [ weight weight ]
The RBS is configured to monitor the network-side interface status and check whether the TCP connection for the RBS fails or recovers.
If devices have multiple uplinks with different bandwidth values, configure different weights for the inbound interfaces based on the uplink bandwidths. If the interfaces have different rates, set weights based on their rates. Set a greater weight for a 10GE interface than a GE interface. For example, interface A is 10GE, and the bandwidth planned for RUI is 5 Gbit/s; interface B is GE, and the bandwidth planned for RUI is 1 Gbit/s; interface C is GE, and the bandwidth planned for RUI is 0.5 Gbit/s. If you use interface B as a reference interface and set its weight to 10, set the weight of interface A to 50 and that of interface C to 5.
The formula is as follows:
Fault rate = Total weight of faulty interfaces/Total weight of interfaces x 100%
If interfaces B and C fail, the fault rate is as follows:
(10 + 5)/(50 + 10 + 5) x 100% = 23%
If interface A fails, the fault rate is as follows:
50/(50 + 10 + 5) x 100% = 77%
- (Optional) Run switchover uplink { failure-ratio failure-ratio | duration duration } *
The threshold for a master/backup switchover due to uplink failures and the duration before the switchover is complete are set.
When you run the track interface command, the weights specified must comply with the rules for performing a master/backup VRRP switchover. If a master/backup BRAS switchover is performed based on the fault rate of uplinks but a master/backup VRRP switchover is not performed, the backup device forwards the network-side traffic back to the master device for processing after receiving the traffic from the master device. In this case, the master device is congested with traffic because the master/backup BRAS switchover is not performed at the same time as the master/backup VRRP switchover.
When you run the switchover uplink command to configure a master/backup BRAS switchover to be performed based on the fault rate of uplinks, also run the peer-backup route-cost auto-advertising command in the system view to enable both devices to automatically generate address pool user network routes (UNRs). In this situation, when a master/backup BRAS switchover is performed based on the fault rate of uplinks, the priority of a UNR is reduced, but no UNRs are withdrawn. This configuration prevents downstream traffic from being interrupted.
- (Optional) Run track monitor-group group-name switchover failure-ratio percent
The RBS is configured to track the interface monitoring group status.
After the track interface-group command is run, the device automatically deletes the track interface and switchover uplink commands if these two commands have been run in the RBS view. The device determines whether to perform a master/backup device switchover based on the track interface-group command.
An interface monitoring group has been created using the monitor-group command.
- (Optional) Run track route-monitor-group group-name switchover failure-ratio percent
A link fault threshold (in percentage) that triggers a master/backup switchover is set for the route monitor group on the network side.
After the track route-monitor-group switchover failure-ratio command is run, the device automatically deletes the track interface command if this command has been run in the RBS view. The device then determines a master/backup switchover based on the track route-monitor-group switchover failure-ratio command.
- (Optional) Run track bfd-session bfd-session
The RBS tracks the BFD status so that the RBS can rapidly monitor the remote device status.
This step is recommended. Before running this command, ensure that a peer BFD session is established between the master and backup devices on the network side.
- (Optional) Run radius-authorization source same-as nas-logic-ip
The device is configured to reply to the RADIUS authorization server with packets in which the source IP address is the same as the NAS IP address.
- Run commit
The configuration is committed.