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 - Segment Routing 01

This is NE40E V800R010C10SPC500 Feature Description - Segment Routing
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).
Importing Traffic

Importing Traffic

After an SR LSP or SE-TE tunnel is established, service traffic needs to be imported to the SR LSP or SR-TE tunnel. The common methods are to use a static route, tunnel policies, or an automatic route. Services include public network services, EVPN, L2VPN, and L3VPN.

Table 2-22 Support for tunnels

Traffic Direction Mode/Tunnel Type

SR LSP

SR-TE Tunnel

Static route

No tunnel interface is available. Therefore, You can configure a static route to specify the next hop, then the static route iterates SR LSP based on the next hop.

A tunnel interface is available. A static route can direct traffic to an SR-TE tunnel.

Tunnel policy

The tunnel select-sequence method can be used, whereas a tunnel binding policy cannot be used.

Either the tunnel select-sequence method or a tunnel binding policy can be used.

Auto route

No tunnel interface is available. Therefore, auto routes cannot be used to direct traffic to SR LSPs.

A tunnel interface is available. An auto route can direct traffic to an SR-TE tunnel.

Policy-Based Routing

No tunnel interface is available. Therefore, policy-based routing cannot be used to direct traffic to SR LSPs.

A tunnel interface is available. policy-based routing can direct traffic to an SR-TE tunnel.

Static Route

No tunnel interface is available for SR LSP. Therefore, You can configure a static route to specify the next hop, then the static route iterates SR LSP based on the next hop.

Static routes on an SR-TE tunnel work in the same way as common static routes. When configuring a static route, set the outbound interface of a static route to an SR-TE tunnel interface so that traffic transmitted over the route is directed to the SR-TE tunnel.

Tunnel Policy

By default, VPN traffic is forwarded through LDP LSPs, not SR LSPs or SR-TE tunnels. If the default LDP LSPs cannot meet VPN traffic requirement, a tunnel policy is used to direct VPN traffic to an SR LSP or an SR-TE tunnel.

The tunnel policy may be a tunnel type prioritizing policy or a tunnel binding policy. Select either of the following policies as needed:

  • Select-seq mode: This policy changes the type of tunnel selected for VPN traffic. An SR LSP or SR-TE tunnel is selected as a public tunnel for VPN traffic based on the prioritized tunnel types. If no LDP LSPs are available, SR LSPs are selected by default.

  • Tunnel binding mode: This policy defines a specific destination IP address, and this address is bound to an SR-TE tunnel for VPN traffic to guarantee QoS.

Auto Route

An IGP uses an auto route related to an SR-TE tunnel that functions as a logical link to compute a path. The tunnel interface is used as an outbound interface in the auto route. According to the network plan, a node determines whether an LSP link is advertised to a neighbor node for packet forwarding. An auto route is configured using either of the following methods:

  • Forwarding shortcut: The node does not advertise an SR-TE tunnel to its neighbor nodes. The SR-TE tunnel can be involved only in local route calculation, but cannot be used by the other nodes.

  • Forwarding adjacency: The node advertises an SR-TE tunnel to its neighbor nodes. The SR-TE tunnel is involved in global route calculation and can be used by the other nodes.

NOTE:
  • Forwarding shortcut and forwarding adjacency are mutually exclusive, and cannot be used simultaneously.

  • When the forwarding adjacency is used, a reverse tunnel must be configured for a routing protocol to perform bidirectional check after a node advertises LSP links to the other nodes. The forwarding adjacency must be enabled for both tunnels in opposite directions.

Policy-Based Routing

The policy-based routing (PBR) allows a device to select routes based on user-defined policies, which improves traffic security and balances traffic. If PBR is enabled on an SR network, IP packets are forwarded over specific LSPs based on PBR rules.

SR-TE PBR, the same as IP unicast PBR, is implemented by defining a set of matching rules and behaviors. The rules and behaviors are defined using the apply clause with an SR-TE tunnel interface used as an outbound interface. If packets do not match PBR rules, they are properly forwarded using IP; if they match PBR rules, they are forwarded over specific tunnels.

Public IP Routes Iterated to SR LSPs

Public Network BGP Route Iterated to an SR LSP

If an Internet user performs IP forwarding to access the Internet, core devices on a forwarding path must learn many Internet routes. This imposes a heavy load on the core devices and affects the performance of these devices. To tackle the problems, a user access device can be configured to iterate non-labeled public network BGP or static routes to a segment routing (SR) LSP. User packets travel through the SR LSP to access the Internet. The iteration to the SR LSP prevents the problems induced by insufficient performance, heavy burdens, and service transmission on the core devices on the network.

Figure 2-42 Public network BGP route iterated to an SR LSP
In Figure 2-42, the deployment is as follows:
  • An E2E IGP neighbor relationship is established between each pair of directly connected devices, and segment routing is configured on PEs and Ps. An SR LSP is established between PEs.
  • A BGP peer relationship between PEs is established to enable the PEs to learn the peer routes.
  • A BGP route is iterated to an SR LSP on each PE.
Static Route Iterated to an SR LSP

The next hop of a static route may be unreachable. Such a route must be iterated to a path. If such a static route is iterated to an SR LSP, packets over the static route are forwarded based on labels.

Figure 2-43 Static route iterated to an SR LSP
In Figure 2-43, the deployment is as follows:
  • An E2E IGP neighbor relationship is established between each pair of directly connected devices, and segment routing is configured on PEs and Ps. PE1 establishes an SR LSP destined for PE2's loopback IP address.
  • A static route is configured on PE1. The next-hop IP address is set to PE2's loopback IP address.
  • After receiving an IP packet, PE1 adds a label into the packet and forwards the packet along the SR LSP.

L3VPN Iterated to SR LSPs

Basic VPN Iterated to an SR LSP

If an Internet user performs IP forwarding to access the Internet, core devices on a forwarding path must learn many Internet routes. This imposes a heavy load on the core devices and affects the performance of these devices. To tackle the problems, a VPN instance can be iterated to a segment routing (SR) LSP, and users access the Internet through the SR LSP.

Figure 2-44 Basic VPN iterated to an SR LSP
The network shown in Figure 2-44 consists of inconsecutive L3VPN subnets with a backbone network in between. PEs establish an SR LSP to forward L3VPN packets. PEs run BGP to learn VPN routes. The deployment is as follows:
  • An IS-IS neighbor relationship is established between each pair of directly connected devices on the public network to implement route reachability.
  • A BGP peer relationship is established between the two PEs to learn peer VPN routes of each other.
  • The PEs establish an IS-IS SR LSP to assign public network labels and compute a label switched path.
  • BGP is used to assign a private network label, for example, label Z, to a VPN instance.
  • VPN routes are iterated to the SR LSP.
  • PE1 receives an IP packet, adds the private network label and SR public network label to the packet, and forwards the packet along the label switched path.
HVPN

On a growing network with increasing types of services, PEs encounter scalability problems, such as insufficient access or routing capabilities, which reduces network performance and scalability. In this situation, VPNs cannot be deployed in a large scale. In Figure 2, on a hierarchical VPN (HVPN), PEs play different roles and provide various functions. These PEs form a hierarchical architecture to provide functions that are provided by one PE on a non-hierarchical VPN. HVPNs lower the performance requirements for PEs.

Figure 2-45 HVPN
In Figure 2-45, the deployment is as follows:
  • BGP peer relationships are established between the UPE and SPE and between the SPE and NPE. A segment routing LSP is established between the UPE and NPE.
  • The SPE iterates a VPNv4 routes to the SR LSP.
The process of forwarding HVPN packets that CE1 sends to CE2 is as follows:
  1. CE1 sends a VPN packet to the NPE.

  2. After receiving the packet, the NPE searches its VPN forwarding table for an LSP to forward the packet based on the destination address of the packet. Then, the NPE adds an inner label L4 and an outer SR public network label Lv to the packet and sends the packet to the SPE over the corresponding LSP. The label stack is L4/Lv.

  3. After receiving the packet, the SPE replaces the outer SR public network label Lv with Lu and the inner label L2 with L3. Then, the SPE sends the packet to the NPE over the same LSP.

  4. After receiving the packet, the NPE removes the outer SR public network label Lu, searches for a VPN instance corresponding to the packet based on the inner label L3, and removes the inner label L3 after the VPN instance is found. Then, the NPE searches the VPN forwarding table of this VPN instance for the outbound interface of the packet based on the destination address of the packet. The NPE sends the packet through this outbound interface to CE2. The packet sent by the NPE is a pure IP packet with no label.

VPN FRR

In Figure 2-46, PE1 adds the optimal route advertised by PE3 and less optimal route advertised by PE4 into a forwarding entry. The optimal route is used to guide traffic forwarding, and the less optimal route is used as a backup route.

Figure 2-46 VPN FRR networking
Table 2-23 Typical fault-triggered switching scenarios

Faulty Point

Protection Switching

P1-to-P3 link failure

PE1 does not support BFD for SR-BE and cannot detect an LSP Down event. As a result, PE2 cannot perform VPN FRR switching to switch traffic to PE4 along LSP3 over a path in Figure 2-46.

After IS-IS/OSPF FRR is configured, P1 performs FRR switching to switch traffic to LSP2 over the path PE1->P1->P2->P4->P3->PE3, shown in Figure 2-46.

PE3 node failure

If PE3 fails, traffic on LSP1 cannot be switched to an FRR backup path, and LSP2 cannot converge. PE1 uses IS-IS/OSPF protocol packets to detect the PE3 fault and performs path convergence. Then the LSP goes Down, and BGP switches traffic to LSP3 along the path PE1->PE2->P2->P4->PE4, shown in Figure 2-46.

L2VPN Iterated to SR LSPs

VPLS Iterated to an SR LSP

Figure 2-47 shows a typical VPLS networking mode. In this networking, users located in various geographical regions communicate with each other through different PEs. From the perspective of users, a VPLS network is a Layer 2 switched network that allows them to communicate with each other in a way similar to communication over a LAN. The VPLS service can be iterated to a segment routing (SR) LSP. Sites in each VPN establish virtual connections, and public network SR LSPs are established to forward Layer 2 packets.

Figure 2-47 VPLS iterated to an SR LSP
The process of iterating VPLS services to an SR LSP is as follows:
  • CE1 sends a packet with Layer 2 encapsulation to PE1.
  • PE1 establishes an E2E SR LSP to PE2.
  • An LSP policy is configured on PE1 to select the SR LSP, and the VSI forwarding entries are associated with the SR forwarding entries.
  • PE1 receives the packet, searches for a VSI entry, and selects an LSP and a PW based on the entry. PE1 adds double labels (outer LSP label and inner VC label) to the packet based on the selected LSP and PW, performs Layer 2 encapsulation, and forwards the packet to PE2.
  • Upon receipt of the packet, PE2 decapsulates the packet by removing Layer 2 encapsulation information and two MPLS labels.
  • PE2 forwards the original packet to CE2.

The process of iterating HVPLS services to an SR LSP is similar to that of iterating VLL and VPLS services to an SR LSP. The process is not described.

EVPN Iterated to SR LSPs

EVPN Iterated to an SR LSP

Ethernet virtual private network (EVPN) is a Layer 2/3 interworking VPN technique. EVPN uses a mechanism similar to BGP/MPLS IP VPN. EVPN extends the BGP protocol and uses extended reachability information to move the process of learning and advertising MAC addresses between Layer 2 networks at various sites from the data plane to the control plane. Compared with VPLS, EVPN tackles the load imbalance and high network resource consumption problems occurring on VPLS networks.

Figure 2-48 Unicast traffic transmission
In Figure 2-48, after the PEs learn the MAC addresses of VPN sites and establish a public network SR LSP, the PEs can transmit unicast packets to the other site. The packet transmission process is as follows:
  1. CE1 sends unicast packets based on Layer 2 forwarding to PE1.
  2. After PE1 receives the packets, PE1 encapsulates a private network label carried in a MAC entry and a public network SR label in sequence and sends the packets to PE2.
  3. After PE2 receives the encapsulated unicast packets, PE1 performs decapsulation, removes the private network label, and searches the private network MAC table for a matching outbound interface.
Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055048

Views: 5491

Downloads: 65

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