No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE40E V800R010C10SPC500 Configuration Guide - User Access 01

This is NE40E V800R010C10SPC500 Configuration Guide - User Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Establishing a Multi-Device Backup Platform

Establishing a Multi-Device Backup Platform

A multi-device backup platform can be established to back up user information between multiple devices. If a node or link between devices becomes abnormal, this function rapidly switches user services to a standby link, improving 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

Based on a VRRP backup group, a multi-device backup platform runs the Huawei-proprietary Redundancy User Information (RUI) protocol to back up user information between devices, which allows for more flexible user service management and improves service reliability. Establishing a multi-device backup platform involves configuring basic functions of a VRRP backup group, a remote backup service (RBS), and a remote backup profile (RBP).

Perform the following steps on each of devices that back up one another:

Procedure

  • Configure basic functions of a VRRP backup group.
    1. Run system-view

      The system view is displayed.

    2. Run interface interface-type interface-number [.subinterface-number ]

      The view of the interface on which a VRRP backup group is configured is displayed.

    3. Run vrrp vrid virtual-router-id virtual-ip virtual-address

      A VRRP backup group is created, and a virtual IP address is assigned to the VRRP backup group.

      NOTE:

      The same VRID and virtual IP address must be set on each of devices that back up one another.

    4. Run admin-vrrp vrid virtual-router-id [ ignore-if-down ]

      This VRRP backup group is configured as an mVRRP backup group.

    5. Run vrrp vrid virtual-router-id priority priority-value

      The priority of a device in the VRRP backup group is configured.

      The devices in the VRRP backup group must be assigned different VRRP priorities. The device with a higher priority serves as the master one.

    6. Run vrrp vrid virtual-router-id preempt-mode timer delay delay-value

      The preemption delay is set in a VRRP backup group.

      Run this command on the master VRRP device so that the backup VRRP device becomes the master one only after the fault is rectified and services are 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 get 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 get 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 get 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 get online through a device, setting the value to 60 minutes is recommended.

    7. Run commit

      The configuration is committed.

  • Configure an RBP.
    1. (Optional) Run peer-backup batch access enable

      The device is configured to allow users to get online when performing batch backup.

    2. Run system-view

      The system view is displayed.

    3. Run remote-backup-profile profile-name

      An RBP is created, and the RBP view is displayed.

    4. Run peer-backup { hot | virtual }

      Inter-device hot, or virtual backup is enabled.

    5. Run vrrp-id vrid interface interface-type interface-number [ odd-mac | even-mac ]

      The RBP is bound to the VRRP backup 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 backup 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 backup 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 backup groups with specific IDs. The two devices that load-balance traffic must have the same configuration, including the binding between the VRRP backup group ID and even or odd MAC address type.
      • Before modifying the setting of odd-mac or even-mac, run the undo vrrp-id vrid command to delete the configuration. Then run the vrrp-id vrid command to reconfigure the setting.

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

    7. Run service-type { arp | ipsec | l2tp | lacp | bras | multicast | igmp | igmp-snooping | no-host-multicast | dhcp-server }

      Remote backup for user services is enabled.

    8. (Optional) Run acct-session-id nas-logic-sysname host-name

      A logic host name is configured to generate an RUI user accounting ID.

    9. Run commit

      The configuration is committed.

  • Configure an RBS.
    1. Run system-view

      The system view is displayed.

    2. Run remote-backup-service service-name

      An RBS is created, and the RBS view is displayed.

    3. (Optional) Run bind ssl-policy ssl-policy-name

      An SSL policy is created and bound to a TCP connection.

      NOTE:
      The RBS has no secure authentication mechanism by default. Binding the RBS to an SSL policy to improve security is recommended.

    4. 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 already exist on the remote device's main interface, sub-interface, or logical interface (for example, loopback interface). The local IP address must already exist on 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.

    5. (Optional) Run batch-backup service-type { arp | all | ipsec | lacp | bras | l2tp | multicast | igmp-snooping | dhcp-server } now

      The device is enabled to immediately back up user services configured in the RBS.

    6. (Optional) Run track interface interface-name [ 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, the weight of interface A is 50 and that of interface C is 5.

      NOTE:

      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%

    7. (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 of the master/backup VRRP switchover. If a master/backup 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 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 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 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.

    8. (Optional) Run track monitor-group group-name switchover failure-ratio percent

      The RBS is configured to track the interface group status.

      If the track interface command is run in the RBS view, the device automatically deletes the track interface and switchover uplink commands after the track interface-group command is run. The device then determines a master/backup switchover based on the track monitor-group command.

    9. (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.

      If the track interface command is run in the RBS view, the device automatically deletes the track interface command after the track route-monitor-group switchover failure-ratio command is run. The device then determines a master/backup switchover based on the track route-monitor-group switchover failure-ratio command.

    10. (Optional) Run track bfd-session bfd-session

      The RBS tracks the BFD status so that the RBS can rapidly monitor the remote device status.

      NOTE:

      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.

    11. (Optional) Run radius-authorization source same-as nas-logic-ip

      The device is configured to reply to the RADIUS server with packets in which the source IP address is the same as the NAS IP address.

    12. Run commit

      The configuration is committed.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055031

Views: 17786

Downloads: 72

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next