Egress Protection in Layer 3 VPNs

When network node or link failures occur, it takes some time to restore service using traditional routing table convergence. Local repair procedures can provide much faster restoration by establishing local protection as close to a failure as possible. Fast protection for egress nodes is available to services in which BGP labeled unicast interconnects IGP areas, levels, or autonomous systems (ASs). If a provider router detects that an egress router (AS or area border router) is down, it immediately forwards the traffic destined to that router to a protector router that forwards the traffic downstream to the destination.

To provide egress protection for BGP labeled unicast, the protector node must create a backup state for downstream destinations before the failure happens. The basic idea of the solution is that the protector node constructs a forwarding state associated with the protected node and relays the MPLS labels assigned by the protected node further downstream to the final destination.

This feature supports the applications Inter-AS Option C and Seamless MPLS.

Inter-AS Option C—BGP labeled unicast provides end-to-end transport label-switched paths (LSPs) by stitching the intra-AS LSPs together. AS boundary routers run EBGP to other AS boundary routers to exchange labels for /32 PE loopback routes. IBGP runs between the provider edge router and AS boundary routers within each AS. In Figure 1, the traffic goes from CE1 to CE2. ASBR1 is the protected AS boundary router, ASBR2 is the protector, and Device P1 is the point of local repair (PLR). The primary path is chosen from PE1 to PE2 over ASBR1 and ASBR3. When ASBR1 fails, Router P1 detects the ASBR1 failure and forwards the traffic to ASBR2, which provides backup service and forwards the traffic downstream.

Figure 1: Inter-AS Option C

Seamless MPLS—BGP labeled unicast provides end-to-end transport LSPs by stitching the intra-area/level LSPs. Area border routers (ABRs) run BGP labeled unicast to other ABRs to exchange labels for /32 PE loopback routes. In Figure 2, the traffic goes from Device CE1 to Device CE2. ABR1 is the protected ABR, ABR2 is the protector, and T1 is the PLR. The primary path is chosen from PE1 to PE2 over ABR1 and ABR3. When ABR1 fails, Router T1 detects the ABR1 failure and forwards the traffic to ABR2, which provides backup service and forwards the traffic downstream.

Figure 2: Seamless MPLS

In each of these applications, the protected node advertises a primary BGP labeled unicast route that needs protection. When fast protection is enabled, BGP advertises the label routes with a special address as the next hop. This special address is a context identifier that is configured through the CLI. The protected node also advertises the context identifier in IGP and a NULL label in LDP for the context identifier.

The backup node advertises backup BGP labeled unicast routes for the protected routes. The protector node forwards traffic to the backup node using the labels advertised by the backup node.

The protector node provides the backup service by cross-connecting the labels originated by the protected node and the labels originated by the backup node. The protector node forwards the traffic to the backup node in case of failure of the protected node. The protector node advertises the same context-identifier into IGP with high metric. Also, it advertises a real label in LDP for the context identifier. The protector node listens for the BGP labeled unicast routes advertised by both the protected node and backup node and populates the context label table and backup FIB. When traffic with the real context LDP label arrives, the lookup is done in the context of a protected node. The protector node often acts as the backup node.

The PLR detects the protected node failure and forwards the MPLS traffic to the protector node. The high IGP metric along with the LDP label advertised by the protector node ensure that the PLR uses the protector node as an LDP backup LSP.

There are two supported protection types: collocated protector and centralized protector. In the collocated type, the protector node is also the backup node. In the centralized type, the backup node is different from the protector node.

This example shows how to configure BGP labeled unicast protection that can be used in case of a PE failure in an Inter-AS Option C topology.

Typically, Layer 3 VPN service restoration for multihomed customer edge (CE) routers depends on the ingress provider edge (PE) router to detect the egress PE link or node failure and switch traffic to the backup PE router. To achieve faster restoration, a protector mechanism for the PE router can be used to perform local restoration of the service immediately in case of an egress PE node failure. This mechanism requires the router at the point of local repair (PLR) to redirect VPN traffic to a protector PE router for fast reroute of traffic.

The following topology describes the concept of egress protection.

Figure 4: Sample Topology for Egress Protection

In this topology:

Router PE3 acts as the protector for the PE2 Layer 3 VPN routing instances or subnets.

The CE routers are part of a VPN where Router CE1 is multihomed with Router PE1 and Router PE2. Likewise, Router CE2 is multihomed with Routers PE2 and PE3.

Router PE1 can be the originator for the context identifier for Router CE1, while Router PE2 is the protector for that context identifier. Likewise, PE2 can be the originator for the context identifier for Router CE2, while Router PE3 is the protector for that context identifier.

The working path taken by Router PE4 might be through PLR>PE2 for both Router CE1 and Router CE2. The backup path for Router CE1 is through PLR>PE1. The backup path for Router CE2 is through PLR>PE3. Traffic flows through the working path under normal circumstances.

When Router PE4 detects a PE2 node or link failure, traffic is rerouted from the working path to the protected path. In the normal failover process, the detection of failure and the recovery rely on the control plane and is therefore relatively slow.

Typically, if there is a link or node failure in the core network, the egress PE router would have to rely on the ingress PE router to detect the failure and switch over to the backup path, because a local repair option for egress failure is not available.

To provide a local repair solution for the egress PE link or node failure, a mechanism known as egress protection can be used to repair and restore the connection quickly. If egress protection is configured, the PLR router detects the PE2 link or node failure and reroutes traffic through the protector Router PE3 using the backup LDP-signaled label-switched path (LSP). The PLR router uses per-prefix loop-free alternate routes to program the backup next hop through Router PE3, and traffic is forwarded to Routers CE1 and CE2 using the alternate paths. This restoration is done quickly after the PLR router detects the Router PE2 egress node or link failure.

The dual protection mechanism can also be used for egress protection where the two PE routers can simultaneously act as the primary PE router and the protector PE router for their respective context ID routes or next hops.

• Router Functions
• Protector and Protection Models
• IGP Advertisement Model

This example describes a local repair mechanism for protecting Layer 3 VPN services against egress provider edge (PE) router failure in a scenario where the customer edge (CE) routers are multihomed with more than one PE router.

The following terminology is used in this example:

• Originator PE router—A PE router with protected routing instances or subnets that distributes the primary Layer 3 VPN router.

• Backup PE router—A PE router that announces a backup Layer 3 VPN route.

• Protector PE router—A router that cross-connects VPN labels distributed by the originator PE router to the labels originated by the backup PE router. The protector PE router can also be a backup PE router.

• Transport LSP—An LDP-signaled label-switched path (LSP) for BGP next hops.

• PLR—A router acting as the point of local repair (PLR) that can redirect Layer 3 VPN traffic to a protector PE router to enable fast restoration and reroute.

• Loop-free alternate routes—A technology that essentially adds IP fast-reroute capability for the interior gateway protocol (IGP) by precomputing backup routes for all the primary routes of the IGP. In the context of this document, the IGP is IS-IS.

• Multihoming—A technology that enables you to connect a CE device to multiple PE routers. In the event that a connection to the primary PE router fails, traffic can be automatically switched to the backup PE router.

• Context identifier—An IPv4 address used to identify the VPN prefix that requires protection. The identifier is propagated to the PE and PLR core routers, making it possible for the protected egress PE router to signal the egress protection to the protector PE router.

• Dual protection—A protection mechanism where two PE routers can simultaneously act as the primary PE router and the protector PE router for their respective context ID routes or next hops. For example, between the two PE routers PE1 and PE2, PE1 could be a primary PE router for context identifier 203.0.113.1 and protector for context identifier 203.0.113.2 Likewise, the PE2 router could be a protector for context identifier 203.0.113.1 and a primary PE router for context identifier 203.0.113.2.

This example shows how to configure egress protection for fast restoration of Layer 3 VPN services.

This example shows how to configure fast service restoration at the egress of a Layer 3 VPN when the customer is multihomed to the service provider. Further, this example includes enhanced point-of-local-repair (PLR) functionality, in which the PLR reroutes service traffic during an egress failure.

Starting in Junos OS Release 13.3, enhanced PLR functionality is available, in which the PLR reroutes service traffic during an egress failure. As part of this enhancement, the PLR router no longer needs to be directly connected to the protector router. Previously, if the PLR was not directly connected to the protector router, the loop-free alternate route could not find the backup path to the protector.