Egress Protection in Layer 3 VPNs

Egress Protection for BGP Labeled Unicast

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.

Configuring Egress Protection for BGP Labeled Unicast

Before configuring egress protection for BGP labeled unicast, ensure that all routers in the AS or area are running Junos OS 14.1 or a later release.

1. Add the following configuration to the protected router:
2. Add the following configuration to the protector router:
3. Add the following configuration to the PLR (point of local repair) router:
4. Run show bgp neighbor on the protected router to verify that egress protection is enabled, for example:

Example: Configuring Egress Protection for BGP Labeled Unicast

• Requirements

• Overview

• Configuration

• Verification

Requirements

• M Series Multiservice Edge Routers, MX Series 5G Universal Routing Platforms, or T Series Core Routers

• Junos OS Release 14.1 or later

Overview

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.

This example shows how to configure labeled-unicast egress protection in a Layer 3 VPN.

Topology

In this example, an Inter-AS Option C topology is set up by configuring two customer edge (CE) devices and six service provider edge (PE) devices in four autonomous systems. The CE devices are configured in AS100 and AS101. The PE devices are configured in AS200 and AS300.

Figure 3 shows the topology used in this example.

Figure 3: Egress Protection in a Layer 3 VPN

The aim of this example is to protect PE Router R4. Egress protection is configured on Router R4 and Router R9 so that the traffic can be routed through the backup link (R9 to R8) when Router R4 (or the link from R5 to R4) goes down. In this example, Router R4 is the protected router, Router R9 is the protector router, and Router R5 is the point of local repair (PLR).

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configuring Egress Protection in Layer 3 VPNs

Step-by-Step Procedure

1. Configure the interfaces on each router, for example:
2. Configure the router ID and autonomous system (AS) number for each router, for example:

   In this example, the router ID is chosen to be identical to the loopback address configured on the router.

3. Configure the protocols on each router, for example:
4. Configure routing policies on all PE routers and AS border routers (Routers R1, R3, R4, R6, R8, and R9), for example:
5. Configure the VPN routing instance on Routers R1 and R6.

   and
6. Configure egress protection for Router R4, setting Router R4 as the protected router and Router R9 as the protector.

   and

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show protocols, show policy-options (if applicable), and show routing-instances (if applicable) commands.

If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the router, enter commit from configuration mode.

Repeat the procedure for every router in this example, using the appropriate interface names and addresses for each router.

Verification

• Verifying That Egress Protection Is Enabled

• Verifying the State of the Protected ASBR as ’primary’

• Verifying the State of the Protector ASBR as ’protector’

Verifying That Egress Protection Is Enabled

Purpose

Verify that egress protection is enabled on the protected router, Router R4.

Action

Verifying the State of the Protected ASBR as ’primary’

Purpose

Verify that the state of the protected AS border router, Router R4, is ’primary’.

Action

Verifying the State of the Protector ASBR as ’protector’

Purpose

Verify that the state of the protector AS border router, Router R9, is ’protector’.

Action

Egress Protection for Layer 3 VPN Edge Protection Overview

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

In Figure 4, the following routers perform the following functions:

Protected PE Router

• Updates a context identifier for the BGP next hop for the Layer 3 VPN prefix.

• Advertises the context identifier to the IS-IS domain.

Protector PE Router

• Advertises the context identifier to the IS-IS domain with a high metric. The high IGP metric (configurable) along with the LDP label ensures that the PLR router uses the LDP-signaled backup LSP in the event of an egress PE router failure.

• Builds a context-label table for route lookup and a backup forwarding table for the protected PE router (PE2).

  Note

  The protector PE router should not be in the forwarding path to the primary PE router.

PLR Router

• Computes per-prefix loop-free alternate routes. For this computation to work, the configuration of the node-link-protection statement and the backup-spf-options per-prefix-calculation statement is necessary at the [edit protocols isis] hierarchy level.

• Installs backup next hops for the context identifier through the PE3 router (protector PE).

• Detects PE router failure and redirects the transport LSP traffic to the protector.

Protector and Protection Models

• Co-located protector—In this model, the protector PE router and the backup PE router configurations are done on the same router. The protector is co-located with the backup PE router for the protected prefix, and it has a direct connection to the multihomed site that originates the protected prefix. In the event of an egress PE failure, the protector receives traffic from the PLR router and routes the traffic to the multihomed site.

• Centralized protector—In this model, the protector PE router and the backup PE router are different. The centralized protector might not have a direct connection to the multihomed site. In the event of an egress PE link or node failure, the centralized protector reroutes the traffic to the backup egress PE router with the VPN label advertised for the backup egress PE router that takes over the role of sending traffic to the multihomed site.

A network can use either of the protection models or a combination of both, depending on the requirement.

As a special scenario of egress node protection, if a router is both a Protector and a PLR, it installs backup next hops to protect the transport LSP. In particular, it does not need a bypass LSP for local repair.

In the Co-located protector model, the PLR or the Protector is directly connected to the CE via a backup AC, while in the Centralized protector model, the PLR or the protector has an MPLS tunnel to the backup PE. In either case, the PLR or the Protector will install a backup next hop with a label followed by a lookup in a context label table, i.e. __context__.mpls.0. When the egress node fails, the PLR or the Protector will switch traffic to this backup next hop in PFE. The outer label (th etransport LSP label) of packets is popped, and the inner label (the layer 3 VPN label allocated by the egress node) is looked up in __context__.mpls.0, which results in forwarding the packets directly to the CE (in Collocated protector model) or the backup PE (in Centralized protector model).

For more information about egress PE failure protection, see Internet draft draft-minto-2547-egress-node-fast-protection-00, 2547 egress PE Fast Failure Protection..

IGP Advertisement Model

Egress protection availability is advertised in the interior gateway protocol (IGP). Label protocols along with Constrained Shortest Path First (CSPF) use this information to do egress protection.

• Context identifier as a stub link (supported in Junos OS 11.4 R3 and later). A link connecting a stub node to a transit node is a stub link.

• Context identifier as a stub alias node (supported in Junos OS 13.3 and later).

• Context identifier as a stub proxy node (supported in Junos OS 13.3 and later).

By default, the stub link is used. To enable enhanced point-of-local-repair (PLR) functionality, in which the PLR reroutes service traffic during an egress failure, configure a stub alias node or a stub proxy node as follows:

The two methods offer different advantages, depending on the needs of your network deployment.

Context Identifier as a Stub Alias Node

In the stub alias method, the LSP end-point address has an explicit backup egress node where the backup can be learned or configured on the penultimate hop node of a protected LSP. With this model, the penultimate hop node of a protected LSP sets up the bypass LSP tunnel to back up the egress node by avoiding the primary egress node. This model requires a Junos OS upgrade in core nodes, but is flexible enough to support all traffic engineering constraints.

The PLR learns that the context ID has a protector. When the primary context ID goes down, packets are rerouted to the protector by way of a pre-programmed backup path. The context ID and protector mapping are configured or learned on the PLR and signaled in the IGP from the protector. A routing table called inet.5 on the PLR provides the configured or IGP-learned details.

IS-IS advertises context IDs into the TED through an IP address TLV. IS-IS imports this TLV into the TED as extended information. IS-IS advertises the protector TLV routes in the inet.5 route for the context ID with protocol next hop being the protector’s router ID. If the protector TLV has a label, the label is added to the route in the inet.5 routing table for LDP to use.

CSPF considers the IP address TLV for tunnel endpoint computation.

With the stub alias model, the protector LSP setup does not require any changes in any nodes. But bypass LSP setup for node protection requires changes in the PHN and the protector router.

When RSVP sets up bypass for node protection LSP, RSVP also performs a lookup for the protector if the PLR is the penultimate hop of the LSP. If the protector is available for the LSP destination, it uses CSPF to compute a path with a constraint that excludes the egress PE and sets up a bypass LSP destination to the context ID if one is not already set up. When setting up a bypass LSP to the context ID, the PLR unsets all protection options.

LDP is useful in the case when the network supports 100 percent LFA coverage but does not support 100 percent per-prefix LFA coverage. LDP sets up a backup path with the protector with the context label advertised by the protector to the service point.

In networks in which 100 percent LFA coverage is not available, it is useful to have backup LSP LFAs with RSVP-based tunnels.

In a steady state, the forwarding is the same as on any other protected LSP in the PLR. In the protector, the non-null label that is advertised and signaled for the context ID has the table next hop point to the MPLS context table, where the peers' labels are programmed.

During a failure, the PLR swaps the transport label with the bypass LSP for the context ID or swaps the label context-label (the protector-advertised label for the context ID) and pushes the transport label to the protector lo0 interface address.

Context Identifier as a Stub Proxy Node

Context identifier as a stub proxy node (supported in Junos OS 13.3 and later). A stub node is one that only appears at the end of an AS path, which means it does not provide transit service. In this mode, known as the virtual or proxy mode, the LSP end-point address is represented as a node with bidirectional links, with the LSP's primary egress node and backup egress node. With this representation, the penultimate hop of the LSP primary egress point can behave like a PLR in setting up a bypass tunnel to back up the egress by avoiding the primary egress node. This model has the advantage that you do not need to upgrade Junos OS on core nodes and will thereby help operators to deploy this technology.

The context ID is represented as a node in the traffic engineering (TE) and IGP databases. The primary PE device advertises the context node into the IGP and TE databases. The primary PE device and the protected PE device support one link to the context node with a bandwidth and a TE metric. Other TE characteristics of TE links are not advertised by Junos OS.

In IS-IS, the primary PE router advertises the proxy node along with links to the primary router and the protector router. The primary and the protector routers advertise links to the proxy node. The proxy node builds the following information.

• System ID—Binary-coded decimal based on the context ID.

• Host name—Protector-name:context ID

• LSP-ID—<System-ID>.00

• PDU type—Level 2 and Level 1, based on the configuration

• LSP attributes:

  • Overload—1

  • IS_TYPE_L1(0x01) | IS_TYPE_L2(0x02) for the level 2 PDU

  • IS_TYPE_L1 for level 1

  • Multiarea—No

  • All other attributes—0

The proxy node only contains area, MT, host name, router ID, protocols and IS reachabilty TLVs. The area, MT, authentication, and protocols TLV are the same as on the primary. The IS reachability TLVs contains two links called Cnode-primary-link and Cnode-protector-link. Both links include TE TLVs. The following TE-link-TLVs are advertised in context links:

• IPv4 interface or neighbor address

• Maximum bandwidth

• TE default metric

• Link (local or remote) Identifiers

Sub TLV values:

• Bandwidth—zero

• TE metric—Maximum TE metric

• Interface address—context ID

• Protector neighbor address—protector router ID

• Primary neighbor address—protected router ID

• Link local-ID protector—0x80fffff1

• Link local-ID primary—0x80fffff2

• Link remote-ID protector—Learned from protector

• Link remote-ID primary—Learned from primary

Protected PE links to context node (primary advertises the link with the following details):

• Bandwidth—Maximum

• TE metric—1

• Interface address—Router ID

• Context neighbor address—Context ID

• Link local-ID to context node—Automatically generated (similar to a sham link)

• Link remote-ID to context node—0x80fffff2

Protector PE links to context node:

• The protector advertises unnumbered transit links with the maximum routable link metric and the maximum TE metric and zero bandwidth to the context node. Other TE characteristics are not advertised.

Unnumbered links are advertised with the following attributes:

• bandwidth—0

• TE metric—MAX TE metric

• Interface address—Router ID

• Context neighbor address—Context ID

• Link local ID to context node—Autogenerated (similar to a sham link)

• Link remote ID to context node—0x80fffff1

In RSVP, the behavior changes are only in the protector and primary routers. RSVP terminates the LSP and the bypass LSP to the context ID. If the context ID is the protector, a non-null label is signaled. Otherwise, it will be based on the configuration or the requested label type. RSVP verifies the Explicit Route Object (ERO) from the path for itself and the context ID. RSVP sends the Resv message with two Record Route Object (RRO) objects—one for the context ID and one for itself. This simulates the penultimate-hop node (PHN) to do node protection with the protector for the primary for context ID LSP. As the fast reroute (FRR)-required bypass, the LSP has to merge back to the protector LSP PHN setup bypass to context ID through the protector by avoiding the primary.

The protector also terminates the backup LSP for the context ID to keep the protected LSP alive during a failure until the ingress node resignals the LSP. The new LSP is reestablished through the protector, but this LSP is not used for service traffic as service protocol does not use the context ID. The LSP traverses through the protector even if the primary comes up. Only reoptimization resignals the LSP through the primary. In stub proxy mode, the bypass LSP with constraints is not supported.

LDP cannot use the stub proxy method due to the inflated metric advertised in the IGP.

With regard the forwarding state, a PE router that protects one or more segments that are connected to another PE is referred to as a protector PE. A protector PE must learn the forwarding state of the segments that it is protecting from the primary PE that is being protected.

For a given segment, if the protector PE is not directly connected to the CE device associated with the segment, it must also learn the forwarding state from at least one backup PE. This situation might arise only in the case of egress PE failure protection.

A protector PE maintains forwarding state for a given segment in the context of the primary PE. A protector PE might maintain state for only a subset of the segments on the primary PE or for all the segments on the primary PE.

Example: Configuring MPLS Egress Protection for Layer 3 VPN Services

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.

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

Example: Configuring Egress Protection for Layer 3 VPN Services

• Requirements

• Overview

• Configuration

• Verification

Requirements

• MX Series 5G Universal Routing Platforms

• Tunnel PICs or the configuration of the Enhanced IP Network Services mode (using the network-services enhanced-ip statement at the [edit chassis] hierarchy level).

• Junos OS Release 11.4R3 or later running on the devices

• Configure the device interfaces. See the Junos OS Network Interfaces Configuration Guide.

• Configure the following routing protocols on all the PE and PLR routers.

  • MPLS, LSPs, and LDP. See the Junos OS MPLS Applications Configuration Guide.

  • BGP and IS-IS. See the Junos OS Routing Protocols Configuration Guide.

• Configure Layer 3 VPNs. See the Junos OS VPNs Configuration Guide.

Overview

Typically, Layer 3 VPN service restoration, in case of egress PE router failure (for multihomed customer edge [CE] routers), depends on the ingress PE router to detect the egress PE node failure and switch traffic to the backup PE router for multihomed CE sites.

Junos OS Release 11.4R3 or later enables you to configure egress protection for Layer 3 VPN services that protects the services from egress PE node failure in a scenario where the CE site is multihomed with more than one PE router. The mechanism enables local repair to be performed immediately upon an egress node failure. The router acting as the point of local repair (PLR) redirects VPN traffic to a protector PE router for restoring service quickly, achieving fast protection that is comparable to MPLS fast reroute.

• egress-protection—When configured at the [edit protocols mpls] hierarchy level, this statement specifies protector information and the context identifier for the Layer 3 VPN and edge protection virtual circuit:

  When configured at the [edit protocols bgp group group-name family inet-vpn unicast], [edit protocols bgp group group-name family inet6-vpn unicast], or [edit protocols bgp group group-name family iso-vpn unicast] hierarchy levels, the egress-protection statement specifies the context identifier that enables egress protection for the configured BGP VPN network layer reachability information (NLRI).

  When configured at the [edit routing-instances] hierarchy level, the egress-protection statement holds the context identifier of the protected PE router.

  This configuration must be done only in the primary PE router and is used for outbound BGP updates for the next hops.

  Configuring the context-identifier statement at the [edit routing-instances routing-instance-name] hierarchy level provides customer edge VRL-level context ID granularity for each VRF instance.

• context-identifier—This statement specifies an IPV4 address used to define the pair of PE routers participating in the egress protection LSP. The context identifier is used to assign an identifier to the protector PE router. The identifier is propagated to the other PE routers participating in the network, making it possible for the protected egress PE router to signal the egress protection LSP to the protector PE router.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configuring the Protected PE Router (PE2)

Step-by-Step Procedure

1. Configure MPLS on the interfaces.
2. Configure egress protection and the context identifier.Note

   The context identifier type must be set to primary.
3. Configure egress protection for the configured BGP NRLI.Note

   The context identifier configured at the [edit protocols bgp group group-name family inet-vpn] hierarchy level should match the context identifier configured at the [edit protocols mpls] hierarchy level.

   Note

   Configuring the context-identifier at the [edit routing-instances routing-instance-name] hierarchy level provides CE VRF-level context-id granularity for each virtual routing and forwarding (VRF) instance.

4. After you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show protocols command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring the Protector PE Router (PE3)

Step-by-Step Procedure

1. Configure MPLS on the interfaces.
2. Configure egress protection and the context identifier.
3. Configure IPv4 Layer 3 VPN NRLI parameters.
4. Configure routing policy options.
5. After you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show protocols and the show policy-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Configuring the PLR Router

Step-by-Step Procedure

1. Configure MPLS on the interfaces.
2. Configure per-prefix-LFA calculation along with link protection.
3. Configure LDP to use the interior gateway protocol (IGP) route metric instead of the default LDP route metric (the default LDP route metric is 1).

Results

Confirm your configuration by issuing the show protocols command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

• Verifying Egress Protection Details

• Verifying Routing Instances

• Verifying BGP NRLI

Verifying Egress Protection Details

Purpose

Check the egress protection configuration.

Action

Meaning

Instance indicates the routing-instance name. Type shows the type of the VRF. It can be either local-vrf or remote-vrf. RIB (routing information base) indicates the edge-protection created routing table. Context-Id shows the context ID associated with the RIB. Route Target shows the route target associated with the routing instance.

Verifying Routing Instances

Purpose

Verify the routing instances.

Action

Meaning

Vrf-edge-protection-id shows the egress protection configured in the protector PE router with the routing instance.

Verifying BGP NRLI

Purpose

Check the details of the BGP VPN network layer reachability information.

Action

Meaning

NLRI configured with egress-protection shows the BGP family configured with egress protection. egress-protection NLRI inet-vpn-unicast, keep-import: [remote-vrf] shows the egress protection routing policy for the BGP group.

Example: Configuring Layer 3 VPN Egress Protection with RSVP and LDP

• Requirements

• Overview

• Configuration

• Verification

Requirements

No special configuration beyond device initialization is required before configuring this example.

This example requires Junos OS Release 13.3 or later.

Overview

In this example, the customer edge (CE) devices are part of a VPN where Device CE1 is multihomed with Device PE2 and Device PE3.

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

Device PE1 is the originator for the context identifier for Device CE1, Device PE2 is the primary router for that context identifier, while Device PE3 is the protector for that context identifier.

Device P1 acts as the point of local repair (PLR). As such, Device P1 can redirect Layer 3 VPN traffic to the protector PE router to enable fast restoration and reroute.

The working path is through P1>PE2. The backup path is through P1>PE3. Traffic flows through the working path under normal circumstances. When a Device PE2 node or link failure is detected, 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 is used in this example to repair and restore the connection quickly. Because egress protection is configured, the PLR router detects the Device PE2 link or node failure and reroutes traffic through the protector Device 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 Device PE3, and traffic is forwarded to Device CE2 using the alternate paths. This restoration is done quickly after the PLR router detects the Device 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.

In addition to egress protection, this example demonstrates an enhanced PLR function, in which the PLR reroutes service traffic during the egress failure. This enhancement is supported in Junos OS Release 13.3 and later. In this example, Device P1 (the PLR) is directly connected to Device PE3 (the protector). A new configuration statement, advertise-mode, enables you to set the method for the interior gateway protocol (IGP) to advertise egress protection availability.

Topology

Figure 5 shows the sample network.

Figure 5: Layer 3 VPN Egress Protection with RSVP and LDP

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

1. Configure the device interfaces.
2. Configure IS-IS.

   Configure per-prefix-LFA calculation along with node link protection.
3. Enable MPLS.
4. Enable RSVP.
5. Enable LDP.

Step-by-Step Procedure

1. Configure the device interfaces.
2. Enable RSVP.
3. Configure MPLS.
4. Configure IBGP.
5. Configure IS-IS.
6. Enable LDP.
7. Configure the routing instance.
8. Configure the autonomous system (AS) number.

Step-by-Step Procedure

1. Configure the device interfaces.
2. Enable RSVP.
3. Configure MPLS.
4. Configure IBGP.
5. Configure IS-IS.
6. Enable LDP.
7. Configure the AS number.

Step-by-Step Procedure

1. Configure the device interfaces.
2. Enable RSVP.
3. Configure MPLS.
4. Configure IBGP.
5. Configure IS-IS.
6. Enable LDP.
7. Configure the routing policy.
8. Configure the AS number.

Results

From configuration mode, confirm your configuration by entering the show interfaces and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the devices, enter commit from configuration mode.

Verification

• Verifying the Protector Node

• Verifying the Primary Node

• Checking the Context Identifier Route

• Verifying Egress Protection

• Verifying the Routing Instance on Device PE1

• Verifying the LSPs

• Verifying BGP NRLI

• Verifying the Traffic Engineering Database

• Verifying the IS-IS Database

Verifying the Protector Node

Purpose

On the protector node (Device PE3), check the information about configured egress protection context identifiers.

Action

Meaning

Device PE3 is the protector node for two LSPs configured from Device PE1 (172.16.183.55) and Device PE2 (172.16.183.56).

Verifying the Primary Node

Purpose

On the primary node (Device PE2), check the information about configured egress protection context identifiers.

Action

Meaning

Device PE2 is the primary node.

Checking the Context Identifier Route

Purpose

Examine the information about the contenxt identifier (192.0.2.6).

Action

Verifying Egress Protection

Purpose

On Device PE3, check the routes in the routing table.

Action

Meaning

Instance indicates the community name. Type shows the type of the VRF. It can be either local-vrf or remote-vrf. Route Target shows the route target associated with the routing instance.

Verifying the Routing Instance on Device PE1

Purpose

On Device PE1, check the routes in the routing table.

Action

Verifying the LSPs

Purpose

On all devices, check the LSP information.

Action

Verifying BGP NRLI

Purpose

Check the details of the BGP VPN network layer reachability information.

Action

Meaning

NLRI configured with egress-protection shows the BGP family configured with egress protection. egress-protection NLRI inet-vpn-unicast, keep-import: [remote-vrf] shows the egress protection routing policy for the BGP group.

Verifying the Traffic Engineering Database

Purpose

On all devices, check the TED.

Action

Verifying the IS-IS Database

Purpose

On all devices, check the IS-IS database.

Action