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 Feature Description - Network Reliability 01

This is NE40E V800R010C10SPC500 Feature Description - Network Reliability
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).
Inter-chassis Hot Backup

Inter-chassis Hot Backup

Basic Concepts

When two CGN devices equipped with the VSUF-80/160 are deployed on the network, the master and slave service boards are deployed on different chassis to achieve inter-chassis backup. Inter-chassis backup ensures data consistency and service continuity between the master and slave devices by triggering a master/slave switchover upon a fault on the master service, service board, public link, or private link.

Backup Principles

Inter-chassis hot backup is associated with the following features:

VRRP: Virtual Router Redundancy Protocol (VRRP) is a fault-tolerant protocol that groups several routers into a virtual router. If the next hop of a host is faulty, VRRP switches traffic to another router, which ensures communication continuity and reliability. Typically, two routing devices are grouped, with one as the master chassis and the other as the slave chassis. The master/slave relationship is determined based on the priorities of routing devices. If VRRP detects a VSUF board fault, service traffic will be switched from the master device to the slave device.

NOTE:
Some acronyms and abbreviations in this document are described as follows:
  • VSM: Value-added service management, HA: High availability.
  • VSUF: Flexible Card Versatile Service Unit.
Inter-chassis hot backup determines the backup relationships of members in the inter-chassis backup group based on VRRP. As shown in Figure 11-3, CPU 0 of the VSUFs on the master and slave devices belong to VSM HA backup group 1, and CPU 1 belongs to VSM HA backup group 2. The service information on CPU 0 of the VSUF on the master service is backed up to CPU 0 of the VSUF on the slave device, and the service information on CPU 1 of the VSUF on the maser device is backed up to CPU 1 of the VSUF on the slave device.
Figure 11-3 Inter-chassis hot backup

Inter-chassis backup includes the cold backup, warm backup, and hot backup modes. Table 11-2 lists the comparison between the cold backup, warm backup, and hot backup. Hot backup is widely used because it delivers high reliability and minimized impact on the network.

Table 11-2 Inter-chassis backup modes

Backup mode

Applicable NAT Scenario

Service Running Scenario

Service Switching Scenario

Inter-chassis cold backup

Centralized NAT

Distributed NAT

The master service board processes services, and the slave service board does not back up any tables.

During a master/slave switchover, the NAT relationship between public and private addresses is changed, and NAT sessions need to be re-established.

Inter-chassis warm backup

Distributed NAT

The master service board processes services, and the slave service board backs up user table information in real time.

During a master/slave switchover, the NAT relationship between public and private addresses remains unchanged, but NAT sessions need to be re-established.

Inter-chassis hot backup

Centralized NAT

The master service board processes services, and the slave service board backs up NAT session table information in real time.

During a master/slave switchover, the NAT relationship between public and private addresses remains unchanged, and NAT sessions do not need to be re-established.

Distributed NAT

The master service board processes services, and the slave service board backs up user entries and NAT session table information.

Troubleshooting Mechanism

Direct links are established between the master and slave NAT devices. As defined in relevant standards, the destination IP address in VRRP packets is the multicast IP address 224.0.0.18, and the TTL value must be 255. Therefore, VRRP packets can be transmitted over a Layer 2 network (VLAN, VLL, and VPLS), instead of a Layer 3 network. The network on which the master and slave devices reside must be a directly connected one or a Layer 2 network. As such, deploying direct-connect inter-chassis backup is recommended. For troubleshooting details about inter-chassis backup for non-directly connected links, see Virtual Access over NAT Inter-chassis Backup for Non-Directly-Connected Links.

  • Inter-chassis backup for direct links

    On the network shown in Figure 11-4, both NAT device 1 (master) and NAT device 2 (slave) are equipped with the VSUF-80/160 and back up each other. A backup channel is deployed based on VRRP through a 10GE inter-board trunk to carry VRRP packets. VRRP is established between the master and slave NAT devices over an intermediate link. The VRRP is associated with the user-side link (downstream link), network-side link (upstream link), and VSM HA backup group status. In distributed inter-chassis backup scenarios, user-side VRRP is associated with the VSM HA backup group. The following troubleshooting mechanism also applies to centralized inter-chassis backup scenarios.

    Figure 11-4 Inter-chassis hot backup
    The troubleshooting mechanism is applicable to the following fault-triggered service switching scenarios:
    • Service switching triggered by a private-network-side link fault

      As shown in Figure 11-5, the private-network-side link fails. VRRP detects the fault and triggers service switching. The switching between the master and slave NAT devices is not consistent with traffic temporarily transmitted over the intermediate backup link. On the private network side, traffic is switched to the slave NAT device upon fault detection, and the slave NAT device functions as the master device. On the public network side, the slave NAT device advertises routes with a higher priority, and traffic from the public network is switched to the slave NAT device (NAT device 2).
      Figure 11-5 Service switching triggered by a private-network-side link fault
    • Service switching triggered by a public-network-side link fault

      As shown in Figure 11-6, the public-network-side link fails. VRRP detects the fault and triggers service switching. The public-network-side link failure triggers IGP/BGP convergence, and traffic is switched to the new master device. On the private network side, VRRP does not detect the fault, and private-to-public traffic is still sent to the master device (NAT device 1) and forwarded to the slave device (NAT device 2) over an intermediate link.
      Figure 11-6 Service switching triggered by a public-network-side link fault
    • Service switching triggered by a VSUF board fault

      As shown in Figure 11-7, a VSUF board fault occurs. VRRP detects the fault and triggers service switching. Private-network-side VRRP detects the VSUF board on NAT device 1, and the master/slave relationship is changed. Therefore, private-network-side traffic is forwarded to NAT device 2 for NAT implementation. NAT device 2 becomes the master device and advertises routes with a high priority. Public-network-side traffic is switched to NAT device 2 and does not pass through NAT device 1 any more.
      Figure 11-7 Service switching triggered by a VSUF board fault
  • Inter-chassis backup for indirect links

    In inter-chassis backup for indirect links, a PW tunnel is deployed on the upstream device (such as the CR) to provide protection. The PW tunnel carries HA backup, service, and VRRP packets.

    As shown in Figure 11-8, CGN1 and CGN2 equipped with a VSUF-80/160 are deployed with inter-chassis hot backup and connected over a non-direct link. CGN1 and CGN2 provide backup for each other. CGN1 forwards service redirection packets or HA backup packets to L3VE, and the VE interface diverts traffic to the L2VE interface. The traffic is then forwarded to CGN2 over the PW tunnel. The terminal on the PW tunnel distributes traffic to the L2VE interface to terminate L2VPN packets and then uses the L3VE interface to forward traffic or distribute traffic to the corresponding VSUF-80/160 based on the outer label. To prevent packet loss, diverting traffic through an intermediate VE link should be avoided, and VRRP is associated with public-network-side routes.
    Figure 11-8 Inter-chassis hot backup connected over a non-direct link
Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055045

Views: 11610

Downloads: 34

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