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 - Virtual-Cluster-Chassis 01

This is NE40E V800R010C10SPC500 Feature Description - Virtual-Cluster-Chassis

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).
Virtual Cluster Forwarding Plane Fundamentals

Virtual Cluster Forwarding Plane Fundamentals

Basic Principles

The principles of the forwarding plane on a single-chassis router are as follows.



  1. The uplink board looks up a table (for example, a FIB table) for packets, obtains information (including outbound interface names), encapsulates the information in the upstream frame header in packets, and sends the packets to the SFU.
  2. The SFU forwards the packets with downstream frame headers to the downlink board.
  3. The downlink board searches a table (for example, an ARP table), finds matching entries, encapsulates the information to the packet, and sends the packets.

In addition to the forwarding process that is also performed on a single chassis, inter-chassis forwarding is performed on the virtual cluster. The following figure shows the process.



On the virtual cluster, if the ingress's SFU+downlink board and the egress's uplink board+SFU are considered as virtual boards, the forwarding principles become the same as those for the single chassis.

  1. The uplink board of the ingress looks up a table (for example, a FIB table) for packets, obtains information (including outbound interface names), encapsulates the information in the upstream frame header of the packets, and sends the packets to the SFU.
  2. The downlink board (interworking board) on the ingress encapsulates inter-chassis frame headers into the packets. The egress's uplink board (interworking board) removes the inter-chassis frame headers. The SFU forwards the packets with downstream frame headers to the downlink board of the egress.
  3. The downlink board on the egress searches a table (for example, an ARP table), finds matching entries, encapsulates the information to the packet, and sends the packets.

In the preceding figure, the virtual cluster decouples the regular service forwarding and the particular inter-chassis forwarding.

  1. The ingress's uplink board and egress's downlink board perform regular service forwarding.
  2. Interworking boards perform particular inter-chassis forwarding.

In this way, the service forwarding process on the virtual cluster is the same as that on a single chassis.

Global and Local Port Numbers

The forwarding plane uses port numbers to identify destination interfaces. The outbound interface in a service entry (for example, a FIB entry) contains a port number.

On a single chassis, the destination port number is unique within the device and chassis. This port number is a local one.

In a virtual cluster, a destination port must be unique within the cluster. The port number is a global port number.

Unicast Forwarding



As shown in the preceding figure, unicast traffic is forwarded by a virtual cluster based on the decoupling between the service forwarding and inter-chassis forwarding. The ingress's uplink board and egress's downlink board perform regular service forwarding. Interworking boards perform particular inter-chassis forwarding. Services enter the inter-chassis forwarding process on the ingress' uplink board. In the following example, the process of forwarding Layer 3 unicast services is as follows:

  1. The ingress' uplink board forwards services:
    • Searches the FIB table and finds a matching global port number.
    • Searches the global port table and determines whether the interface is a local one or not.

    If a local interface is used, a local port number is obtained. In this situation, the intra-chassis service forwarding is carried out.

    If the interface resides in another chassis and a destination chassis ID is obtained, the inter-chassis service forwarding is carried out.

  2. The ingress's uplink board performs the inter-chassis forwarding:
    • Inter-chassis routing

      When multiple chassis are used, there may be multiple paths passing through different next-hop chassis to a destination chassis. The control plane on each chassis uses inter-chassis topology information to compute inter-chassis routes and generate a routing table. A chassis searches the inter-chassis routing table for a local outbound chassis ID matching a destination chassis ID before forwarding data.

    • Inter-chassis load balancing

      An inter-chassis data channel consists of multiple data links. In forwarding, a chassis performs per-flow load balancing based on inter-chassis channel IDs of member links and selects a data link as an outbound interface for inter-chassis forwarding.

    • The outbound interface for inter-chassis forwarding is assigned a global port number. The chassis searches the global port table for an entry matching the global port number. The destination port is a local one, and therefore, the local port number is obtained. The chassis uses this port number to forward data through the SFU.
  3. The ingress's interworking board forwards packets:
    • Performs inter-chassis encapsulation for packets to be forwarded between chassis and sends them through an interface.
    • Performs inter-chassis encapsulation by adding the destination chassis ID, global port number, and load-balancing hash value into the packets.
  4. The egress's interworking board forwards services:
    • Terminates the inter-chassis forwarding since the target chassis ID is a local one.
    • Removes inter-chassis encapsulation information.
    • Searches the table for an entry mapped to the local port number. Since a local interface is used, a local port number is obtained.
    • Forwards data through an interface with the local port number.

    The combination of Steps 2, 3, and 4 is the process of the inter-chassis forwarding, which implements the function of a virtual SFU.

  5. The egress's downlink board performs service forwarding:

    The regular downlink forwarding is carried out, for example, querying the ARP table for Layer 2 encapsulation and forwarding.

    The unicast forwarding on the virtual cluster is similar to that on the single chassis. The difference is that inter-chassis forwarding is added and is decoupled from the service process. Various services do not need to be aware of a virtual cluster, and no special processing is needed.

Multicast Forwarding Principles

NOTE:
Principles of broadcast and unknown unicast traffic are the same as those of multicast traffic and are not described.

In multicast forwarding on a virtual cluster, two replication solutions are used:

  • One-level multicast replication

    The ingress replicates traffic for all multicast leaf nodes on all chassis. Each copy of traffic is separately sent to a destination chassis. In this solution, a large number of inter-chassis bandwidth resources are consumed.

  • Hierarchical multicast replication

    The ingress replicates traffic for multicast leaf nodes only on the local chassis and replicates and sends traffic to each adjacent chassis. Each adjacent chassis repeats the replication process. Hierarchical multicast replication is performed within the whole virtual cluster consisting of three or more chassis. In this solution, bandwidth is not repeatedly consumed on inter-chassis channels.

To minimize inter-chassis bandwidth consumption, the virtual cluster uses hierarchical multicast replication. In the following example, a virtual cluster with two chassis performs hierarchical multicast replication.



  • A local chassis replicates and sends one copy of traffic to each chassis.
  • Each chassis replicates traffic to local members through an inter-board trunk interface.
  • The multicast forwarding process within a virtual cluster is similar to that on a single chassis, except for the inter-chassis replication.

Inter-Chassis Packet Encapsulation

Private encapsulation is performed for data packets transmitted along the data channel.

A virtual cluster supports only Ethernet encapsulation. Ethernet encapsulation is compatible in various networking scenarios, but its overhead is large.

The following figure shows Ethernet encapsulation.



The DMAC and SMAC are set to interconnection interfaces' MAC addresses, and the Ethtype value is 0x8888.

An inter-chassis frame header contains various fields, including the Global Port Number, Destination Chassis ID, and History fields, which are used to guide the inter-chassis forwarding.

Creation of the Data Plane

Data channels are specified manually, and a virtual cluster cannot automatically detect or identify them.



In the preceding networking, operate both chassis 1 and 2 and configure them to work in cluster mode. Add the interconnection interfaces on each chassis to the same data channel group.

The cluster runs the Hello protocol on data links to detect link faults.

The cluster runs the control plane to collect data link information, generate cluster topology, and deliver the inter-chassis routing table and inter-chassis load balancing table to the forwarding plane. The data plane is then created and available.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055054

Views: 2819

Downloads: 33

Average rating:
This Document Applies to these Products

Related Version

Related Documents

Share
Previous Next