Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Node and Path Protection for MPLS LSPs

 

MPLS and Traffic Protection

Typically, when an LSP fails, the router immediately upstream from the failure signals the outage to the ingress router. The ingress router calculates a new path to the egress router, establishes the new LSP, and then directs the traffic from the failed path to the new path. This rerouting process can be time-consuming and prone to failure. For example, the outage signals to the ingress router might get lost, or the new path might take too long to come up, resulting in significant packet drops. The Junos OS provides several complementary mechanisms for protecting against LSP failures:

  • Standby secondary paths—You can configure primary and secondary paths. You configure secondary paths with the standby statement. To activate traffic protection, you need to configure these standby paths only on the ingress router. If the primary path fails, the ingress router immediately reroutes traffic from the failed path to the standby path, thereby eliminating the need to calculate a new route and signal a new path. For information about configuring standby LSPs, see Configuring Hot Standby of Secondary Paths for LSPs.

  • Fast reroute—You configure fast reroute on an LSP to minimize the effect of a failure in the LSP. Fast reroute enables a router upstream from the failure to route around the failure quickly to the router downstream of the failure. The upstream router then signals the outage to the ingress router, thereby maintaining connectivity before a new LSP is established. For a detailed overview of fast reroute, see Fast Reroute Overview. For information about configuring fast reroute, see Configuring Fast Reroute.

  • Link protection—You can configure link protection to help ensure that traffic traversing a specific interface from one router to another can continue to reach its destination in the event that this interface fails. When link protection is configured for an interface and configured for an LSP that traverses this interface, a bypass LSP is created that handles this traffic if the interface fails. The bypass LSP uses a different interface and path to reach the same destination. For information about configuring link protection, see Configuring Link Protection on Interfaces Used by LSPs.

When standby secondary path, and fast reroute or link protection are configured on an LSP, full traffic protection is enabled. When a failure occurs in an LSP, the router upstream from the failure routes traffic around the failure and notifies the ingress router of the failure. This rerouting keeps the traffic flowing while waiting for the notification to be processed at the ingress router. After receiving the failure notification, the ingress router immediately reroutes the traffic from the patched primary path to the more optimal standby path.

Fast reroute and link protection provide a similar type of traffic protection. Both features provide a quick transfer service and employ a similar design. Fast reroute and link protection are both described in RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels. However, you need to configure only one or the other. Although you can configure both, there is little, if any, benefit in doing so.

Node-Link Protection Overview

Node-link protection (many-to-one or facility backup) extends the capabilities of link protection and provides slightly different protection from fast reroute. While link protection is useful for selecting an alternate path to the same router when a specific link fails, and fast reroute protects interfaces or nodes along the entire path of an LSP, node-link protection establishes a bypass path that avoids a particular node in the LSP path.

When you enable node-link protection for an LSP, you must also enable link protection on all RSVP interfaces in the path. Once enabled, the following types of bypass paths are established:

  • Next-hop bypass LSP—Provides an alternate route for an LSP to reach a neighboring router. This type of bypass path is established when you enable either node-link protection or link protection.

  • Next-next-hop bypass LSP—Provides an alternate route for an LSP through a neighboring router en route to the destination router. This type of bypass path is established exclusively when node-link protection is configured.

Figure 1 illustrates the example MPLS network topology used in this topic. The example network uses OSPF as the interior gateway protocol (IGP) and a policy to create traffic.

Figure 1: Node-Link Protection
Node-Link Protection

The MPLS network in Figure 1 illustrates a router-only network that consists of unidirectional LSPs between R1 and R5, (lsp2-r1-to-r5) and between R6 and R0 (lsp1-r6-to-r0). Both LSPs have strict paths configured that go through interface fe-0/1/0.

In the network shown in Figure 1, both types of bypass paths are preestablished around the protected node (R2). A next-hop bypass path avoids interface fe-0/1/0 by going through R7, and a next-next-hop bypass path avoids R2 altogether by going through R7 and R9 to R4. Both bypass paths are shared by all protected LSPs traversing the failed link or node (many LSPs protected by one bypass path).

Node-link protection (many-to-one or facility backup) allows a router immediately upstream from a node failure to use an alternate node to forward traffic to its downstream neighbor. This is accomplished by preestablishing a bypass path that is shared by all protected LSPs traversing the failed link.

When an outage occurs, the router immediately upstream from the outage switches protected traffic to the bypass node, and then signals the failure to the ingress router. Like fast reroute, node-link protection provides local repair, restoring connectivity faster than the ingress router can establish a standby secondary path or signal a new primary LSP.

Node-link protection is appropriate in the following situations:

  • Protection of the downstream link and node is required.

  • The number of LSPs to be protected is large.

  • Satisfying path selection criteria (priority, bandwidth, and link coloring) for bypass paths is less critical.

  • Control at the granularity of individual LSPs is not required.

Path Protection Overview

The main advantages of path protection are control over where the traffic goes after a failure and minimum packet loss when combined with fast reroute (one-to-one backup or link protection). Path protection is the configuration, within a label-switched path (LSP), of two types of paths: a primary path, used in normal operations, and a secondary path used when the primary fails, as shown in Figure 2.

In Figure 2, an MPLS network consisting of eight routers has a primary path between R1 and R5 which is protected by the secondary path between R1 and R5. When a failure is detected, such as an interface down event, an Resource Reservation Protocol (RSVP) error message is sent to the ingress router which switches traffic to the secondary path, maintaining traffic flow.

Figure 2: Path Protection
Path Protection

 

If the secondary path is pre-signaled or on standby, recovery time from a failure is faster than if the secondary path is not pre-signaled. When the secondary path is not pre-signaled a call-setup delay occurs during which the new physical path for the LSP is established, extending the recovery time. If the failure in the primary path is corrected, and after a few minutes of hold time, the ingress router switches traffic back from the secondary path to the primary path.

Because path protection is provided by the ingress router for the entire path, there can be some disadvantages, for example, double-booking of resources and unnecessary protection of links. By protecting a single resource at a time, local protection can remedy these disadvantages.

Configuring Path Protection in an MPLS Network (CLI Procedure)

The Junos OS implementation of MPLS on EX Series switches provides path protection as a mechanism for protecting against label switched path (LSP) failures. Path protection reduces the time required to recalculate a route in case of a failure within the MPLS tunnel. You configure path protection on the ingress provider edge switch in your MPLS network. You do not configure the egress provider edge switch or the provider switches for path protection. You can explicitly specify which provider switches are used for the primary and secondary paths, or you can let the software calculate the paths automatically.

Before you configure path protection, be sure you have:

To configure path protection, complete the following tasks on the ingress provider edge switch:

  1. Configuring the Primary Path

  2. Configuring the Secondary Path

  3. Configuring the Revert Timer

Configuring the Primary Path

The primary statement creates the primary path, which is the LSP’s preferred path. The secondary statement creates an alternative path if the primary path can no longer reach the egress provider edge switch.

In the tasks described in this topic, the lsp-name has already been configured on the ingress provider edge switch as lsp_to_240 and the loopback interface address on the remote provider edge switch has already been configured as 127.0.0.8.

When the software switches from the primary to the secondary path, it continuously attempts to revert to the primary path, switching back to it when it is again reachable but no sooner than the retry time specified in the revert-timer statement.

You can configure zero primary paths or one primary path. If you do not configure a primary path, the first secondary path (if a secondary path has been configured) is selected as the path. If you do not specify any named paths, or if the path that you specify is empty, the software makes all routing decisions necessary for the packets to reach the egress provider edge switch.

To configure a primary path:

  1. Create the primary path for the LSP:
    [edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8]

    user@switch# set primary primary_path_lsp_to_240
  2. Configure an explicit route for the primary path by specifying the IP address of the loopback interface or the switch IP address or hostname of each switch used in the MPLS tunnel. You can specify the link types as either strict or loose in each path statement. If the link type is strict, the LSP must go to the next address specified in the path statement without traversing other switches. If the link type is loose, the LSP can traverse through other switches before reaching this switch. This configuration uses the default strict designation for the paths. Note

    You can enable path protection without specifying which provider switches are used. If you do not list the specific provider switches to be used for the MPLS tunnel, the switch calculates the route.

    Tip

    Do not include the ingress provider edge switch in these statements. List the IP address of the loopback interface or switch address or hostname of all other switch hops in sequence, ending with the egress provider edge switch.

    [edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8]

    user@switch# set path primary_path_lsp_to_240 127.0.0.2

    user@switch# set path primary_path_lsp_to_240 127.0.0.3

    user@switch# set path primary_path_lsp_to_240 127.0.0.8

Configuring the Secondary Path

You can configure zero or more secondary paths. All secondary paths are equal, and the software tries them in the order that they are listed in the configuration. The software does not attempt to switch among secondary paths. If the first secondary path in the configuration is not available, the next one is tried, as so on. To create a set of equal paths, specify secondary paths without specifying a primary path. If you do not specify any named paths, or if the path that you specify is empty, the software makes all routing decisions necessary to reach the egress provider edge switch.

To configure the secondary path:

  1. Create a secondary path for the LSP:
    [edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8]

    user@switch# set secondary secondary_path_lsp_to_240 standby
  2. Configure an explicit route for the secondary path by specifying the IP address of the loopback interface or the switch IP address or hostname of each switch used in the MPLS tunnel. You can specify the link types as either strict or loose in each path statement. This configuration uses the default strict designation for the paths.Tip

    Do not include the ingress provider edge switch in these statements. List the IP address of the loopback interface or switch address or hostname of all other switch hops in sequence, ending with the egress provider edge switch.

    [edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8]

    user@switch# set path secondary_path_lsp_to_240 127.0.0.4

    user@switch# set path primary_path_lsp_to_240 127.0.0.8

Configuring the Revert Timer

For LSPs configured with both primary and secondary paths, you can optionally configure a revert timer. If the primary path goes down and traffic is switched to the secondary path, the revert timer specifies the amount of time (in seconds) that the LSP must wait before it can revert traffic back to the primary path. If the primary path experiences any connectivity problems or stability problems during this time, the timer is restarted.

Tip

If you do not explicitly configure the revert timer, it is set by default to 60 seconds.

To configure the revert timer for LSPs configured with primary and secondary paths:

  • For all LSPs on the switch:

    [edit protocols mpls]

    user@switch# set revert-timer 120
  • For a specific LSP on the switch:

    [edit protocols mpls label-switched-path]

    user@switch# set lsp_to_240 revert-timer 120

Preventing Use of a Path That Previously Failed

If you configure an alternate path through the network in case the active path fails, you may not want traffic to revert back to the failed path, even if it is no longer failing. When you configure a primary path, the traffic switches over to the secondary path during a failure, and reverts back to the primary path when it returns.

At times, switching traffic back to a primary path that has previously failed may not be a particularly sound idea. In this case, only configure secondary paths, resulting in the next configured secondary path establishing when the first secondary path fails. Later, if the first secondary path becomes operational, the Junos OS will not revert to it, but will continue using the second secondary path.

Configuring MPLS Inter-AS Link-Node Protection with Labeled BGP

Link protection is essential in an MPLS network to ensure traffic restoration in case of an interface failure. The ingress router chooses an alternate link through another interface to send traffic to its destination.

In Figure 3, autonomous system border routers (ASBRs) run external BGP (EBGP) to ASBRs in another autonomous system (AS) to exchange labels for /32 IPv4 routes. Inside the ASs, internal BGP (IBGP) propagates the routes to provider edge (PE) devices. If the link from Device ASBR3 to Device ASBR1 goes down, until Device ASBR3 reinstalls the new next hop, all traffic going toward AS 64510 from AS 64511 through the ASBR3-ASBR1 link is dropped. A fast traffic restoration can be achieved if Device ASBR3 preprograms a backup path either through Device ASBR4 or through a direct path to Device ASBR2 if one exists (not shown in the diagram). This assumes that Device ASBR3 learns a loop-free MPLS path for routes that need to protected either through IBGP or EBGP.

This solution does not handle a failure on Device ASBR3 for traffic going toward AS 64511 from AS 64510 through the ASBR3-ASBR1 link. This solution is limited to downstream inter-AS link-node protection with labeled BGP. This solution does not support service restoration between provider (P) and ASBR routers when there is an ASBR failure. For example, this solution does not handle a failure on the P3-ASBR3 link.

This supported functionality is similar to BGP multipath, except only one next hop is used for active forwarding, and a second path is in protected mode.

In an MPLS inter-AS environment, link protection can be enabled when labeled-unicast is used to send traffic between ASs. Hence, MPLS inter-AS link protection is configured on the link between two routers in different ASs.

To configure link protection on an interface, use the protection statement at the [edit protocols bgp group group-name family inet labeled-unicast] hierarchy level:

Note

MPLS inter-AS link protection is supported only with labeled-unicast and external peers in a master routing instance.

The link on which protection is configured is known as the protection path. A protection path is selected only after the best path selection and is not selected in the following cases:

  • The best path is a non-BGP path.

  • Multiple next hops are active, as in BGP multipath.

Example: Configuring MPLS Inter-AS Link-Node Protection

This example shows how to configure tail-end protection in an inter-AS deployment with Layer 3 VPNs.

Requirements

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

Overview

In Figure 4. autonomous system border routers (ASBRs) run external BGP (EBGP) to ASBRs in another autonomous system (AS) to exchange labels for /32 IPv4 routes. Inside the ASs, internal BGP (IBGP) propagates the routes to provider edge (PE) devices.

If the link from Device ASBR3 to Device ASBR1 goes down, until ASBR3 reinstalls the new next hop, all traffic going toward AS 64510 from AS 64511 through the ASBR3-ASBR1 link is dropped.

This example shows how to achieve fast traffic restoration by configuring Device ASBR3 to preprogram a backup path through Device ASBR2.

Note

This solution does not handle the Device P3 to Device ASBR3 failure. Nor does it handle a failure on Device ASBR3 for traffic going toward AS 645111 from AS 64510 through the ASBR3-ASBR1 link. This traffic is dropped.

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.

Device ASBR1

Device ASBR2

Device ASBR3

Device CE1

Device CE2

Device P1

Device P2

Device P3

Device PE1

Device PE2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure the EBGP scenario:

  1. Configure the router interfaces.
  2. Configure an interior gateway protocol (IGP), such as OSPF or IS-IS.
  3. Configure the autonomous system (AS) number.
  4. Configure the routing policy.
  5. Configure the EBGP sessions.
  6. Configure the IBGP sessions.
  7. Configure MPLS.
  8. Configure a signaling protocol.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options, 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

Confirm that the configuration is working properly.

Checking the BGP Neighbor Sessions

Purpose

Verify that BGP protection is enabled.

Action

user@ASBR3# show bgp neighbor 21.21.21.1


user@ASBR3# show bgp neighbor 26.26.26.1

Meaning

The output shows that the Protection option is enabled for the EBGP peers, Device ASBR1 and Device ASBR2.

This is also shown with the NLRI configured with protection: inet-labeled-unicast screen output.

Checking the Routes

Purpose

Make sure that the backup path is installed in the routing table.

Action

user@ASBR3> show route 2.2.2.2

Meaning

The show route command displays active as well as backup paths to Device PE1.

Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services

Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there is a link or node failure in the egress PE node. If there is a link or node failure in the core network, a protection mechanism such as MPLS fast reroute can be triggered on the transport LSPs between the PE routers to repair the connection within tens of milliseconds. An egress protection LSP addresses the problem of a node-link failure at the edge of the network (for example, a failure of a PE router).

Figure 1 shows a simplified topology of the use case that explains this feature.

Figure 5: Egress Protection LSP Configured from Router PE1 to Router PE2
Egress Protection LSP Configured
from Router PE1 to Router PE2

CE1 is multihomed to PE1 and PE2. There are two paths connecting CE1 and CE2. The working path is CE2-PE3-P-PE1-CE1, via pseudowire PW21. The protecting path is CE2-PE3-P-PE2-CE1, via pseudowire PW22 Traffic is flowing through the working path under normal circumstances. When the end-to-end OAM between CE1 and CE2 detects failure on the working path, traffic will be switched from the working path to the protecting path. The end-to-end failure detection and recovery relies on control plane hence should be relatively slow. To achieve faster protection, local repair mechanisms similar to those used by MPLS fast reroute should be used. In Figure 1 above, if link or node failed in the core network (like link failure on P-PE1, P-PE3, or node failure on P), the MPLS fast reroute will happen on the transport LSPs between PE1 and PE3. The failure could be locally repaired within tens of milliseconds. However, if link or node failure happens at the edge (like link failure on PE3-CE2 or node failure on PE3), there is no local repair currently so we have to rely on the CE1-CE2 end-to-end protection to repair the failure.

  • Device CE2—Traffic origin

  • Router PE3—Ingress PE router

  • Router PE1— (Primary) Egress PE router

  • Router PE2—Protector PE router

  • Device CE1—Traffic destination

When the link between CE1– PE1 goes downs, PE1 will briefly redirect that traffic towards CE1, to PE2. PE2 forwards it to CE1 until ingress router PE3 recalculates to forward the traffic to PE2.

Initially the traffic direction was; CE2 – PE3 – P – PE1 – CE1.

When the link between CE1– PE1 goes down, the traffic will be; CE2 – PE3 – P – PE1 – PE2 –CE1. PE3 then recalculates the path; CE2 – PE3 – P – PE2 – CE1.

  1. Configure RSVP on PE1, PE2, and PE3.
  2. Configure MPLS.
  3. Set PE1 as primary and PE2 as protector nodes.
  4. Enable egress-protection on PE1 and PE2.
  5. Configure LDP and ISIS on PE1, PE2, and PE3.
  6. Configure a load balancing policy at PE1, PE2, and PE3.
  7. Configure the routing options at PE1, PE2, and PE3, to export routes based on the load balancing policy.
  8. Configure BGP at PE1 to advertise nrli from the routing instance with context-ID as next-hop.
  9. Configure l2vpn at PE1, PE2, and PE3

    At PE1:

    At PE2:

    At PE3:

Example: Configuring MPLS Egress Protection Service Mirroring for BGP Signaled Layer 2 Services

Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there is a link or node failure in the egress PE node. If there is a link or node failure in the core network, a protection mechanism such as MPLS fast reroute can be triggered on the transport LSPs between the PE routers to repair the connection within tens of milliseconds. An egress protection LSP addresses the problem of a node-link failure at the edge of the network (for example, a failure of a PE router).

This example shows how to configure link protection for BGP signaled Layer 2 services.

Requirements

MX Series Routers running Junos OS Release 14.2 or later.

Overview

If there is a link or node failure in the core network, a protection mechanism such as MPLS fast reroute can be triggered on the transport LSPs between the PE routers to repair the connection within tens of milliseconds. An egress protection LSP addresses the problem of a node-link failure at the edge of the network (for example, a failure of a PE router).

This example includes the following configuration concepts and statements that are unique to the configuration of an egress protection LSP:

  • context-identifier—Specifies an IPv4 or IPv6 address used to define the pair of PE routers participating in the egress protection LSP. It is assigned to each ordered pair of primary PE and the protector to facilitate protection establishment. This address is globally unique, or unique in the address space of the network where the primary PE and the protector reside.

  • egress-protection—Configures the protector information for the protected Layer 2 circuit and configures the protector Layer 2 circuit at the [edit protocols mpls] hierarchy level. Configures an LSP as an egress protection LSP at the [edit protocols mpls] hierarchy level.

  • protector—Configures the creation of standby pseudowires on the backup PE for link or node protection for the instance.

Figure 6: Egress Protection LSP Configured from Router PE1 to Router PE2
Egress
Protection LSP Configured from Router PE1 to Router PE2

In the event of a failure of the egress PE Router PE1, traffic is switched to the egress protection LSP configured between Router PE1 and Router PE2 (the protector PE router):

  • Device CE2—Traffic origin

  • Router PE3—Ingress PE router

  • Router PE1— (Primary) Egress PE router

  • Router PE2—Protector PE router

  • Device CE1—Traffic destination

When the link between CE1– PE1 goes downs, PE1 will briefly redirect that traffic toward CE1, to PE2. PE2 forwards it to CE1 until ingress router PE3 recalculates to forward the traffic to PE2.

Initially the traffic direction was: CE2 – PE3 – P – PE1 – CE1.

When the link between CE1– PE1 goes down, the traffic will be: CE2 – PE3 – P – PE1 – PE2 –CE1. PE3 then recalculates the path: CE2 – PE3 – P – PE2 – CE1.

This example shows how to configure routers PE1, PE2, and PE3.

Configuration

CLI Quick Configuration

To quickly configure an egress protection LSP, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configurations, copy and then paste the commands into the CLI and enter commit from configuration mode.

PE1

PE2

PE3

Step-by-Step Procedure

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure an egress protection LSP for router PE1:

  1. Configure RSVP.
  2. Configure MPLS to use the egress protection LSP to protect against a link failure to Device CE1.
  3. Configure BGP.
  4. Configure IS-IS.
  5. Configure LDP.
  6. Configure a load-balancing policy.
  7. Configure the routing options to export routes based on the load-balancing policy.
  8. Configure BGP to advertise nrli from the routing instance with context-ID as next-hop.
  9. Configure l2vpn instance to use the egress LSP configured.
  10. If you are done configuring the device, enter commit from configuration mode.

Step-by-Step Procedure

To configure an egress protection LSP for Router PE2:

  1. Configure RSVP.
  2. Configure MPLS and the LSP that acts as the egress protection LSP.
  3. Configure BGP.
  4. Configure IS-IS.
  5. Configure LDP.
  6. Configure a load-balancing policy.
  7. Configure the routing options to export routes based on the load-balancing policy.
  8. Configure BGP to advertise nrli from the routing instance with context-ID as next-hop.
  9. Configure l2vpn instance to use the egress LSP configured.
  10. If you are done configuring the device, enter commit from configuration mode.

Step-by-Step Procedure

To configure an egress protection LSP for Router PE3:

  1. Configure RSVP.
  2. Configure MPLS.
  3. Configure BGP.
  4. Configure IS-IS.
  5. Configure LDP.
  6. Configure a load-balancing policy.
  7. Configure the routing options to export routes based on the load-balancing policy.
  8. Configure BGP to advertise nlri from the routing instance with context-ID as next-hop.
  9. Configure l2vpn to specify the interface that connects to the site and the remote interface to which you want the specified interface to connect.
  10. If you are done configuring the device, enter commit from configuration.

Results

From configuration mode, confirm your configuration on Router PE1 by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

From configuration mode, confirm your configuration on Router PE2 by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

From configuration mode, confirm your configuration on Router PE3 by entering the show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying the L2VPN Configuration

Purpose

Verify that LSP is protected by the connection protection logic.

Action

From operational mode, run the show l2vpn connections extensive command.

Meaning

The Egress Protection: Yes output shows that the given PVC is protected by connection protection logic.

Verifying the Routing Instance Details

Purpose

Verify the routing instance information and the context identifier configured on the primary, which is used as the next-hop address in case of node-link failure.

Action

From operational mode, run the show route foo detail command.

Meaning

The context-id is set to 198.51.100.3 and the Vrf-import: [ __vrf-import-foo-internal__] in the output mentions the policy used for rewriting the next-hop address.

Verifying the IS-IS Configuration

Purpose

Verify the IS-IS context identifier information.

Action

From operational mode, run the show isis context-identifier detail command.

Meaning

Router PE2 is the protector and the configured context identifier is in use for the MPLS protocol.

Verifying the MPLS Configuration

Purpose

Verify the context identifier details on the primary and protector PEs.

Action

From operational mode, run the show mpls context-identifier detail command.

Meaning

Context-id is 198.51.100.3, advertise-mode is alias, the MPLS table created for egress protection is __198.51.100.3__.mpls.0, and the egress instance name is foo, which is of type local-l2vpn.

Example: Configuring Layer 3 VPN Egress Protection with PLR as Protector

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.

Starting in Junos OS Release 15.1, the enhanced point of local repair (PLR) functionality addresses a special scenario of egress node protection, where the PLR and the protector are co-located as one router. In this case, there is no need to have a bypass LSP reroute traffic during local repair. Instead, the PLR or the protector can send the traffic directly to the target CE (in Co-located protector model where the PLR or the protector is also the backup PE that is directly connected to the CE) or to the backup PE (in Centralized protector model where the backup PE is a separate router).

Requirements

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

This example requires Junos OS Release 15.1 or later.

Overview

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 (the transport 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).

Topology

Figure 7 shows the sample network.

Figure 7: Co-located PLR and protector in collocated protector model
Co-located PLR and protector
in collocated protector model

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.

Device CE1

Device PE1

Device P

Device PE2

Device PE3

Device CE2

Configuring Device CE1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Configure interfaces.

Configuring Device PE1

Step-by-Step Procedure

  1. Configure the interfaces.
  2. Configure the autonomous system (AS) number.
  3. Configure RSVP.
  4. Enable MPLS.
  5. Configure BGP.
  6. Enable IS-IS.
  7. (Optional) Configure OSPF
  8. Configure the routing instance.
  9. Configure the routing policy.

Configuring Device P

Step-by-Step Procedure

  1. Configure the device interfaces.
  2. Enable IS-IS.
  3. Enable MPLS.
  4. Configure RSVP.
  5. (Optional) Configure OSPF.

Configuring Device PE2

Step-by-Step Procedure

  1. Configure the interfaces.
  2. Configure autonomous number(AS).
  3. Configure RSVP.
  4. Configure MPLS.
  5. Configure BGP.
  6. Configure IS-IS.
  7. (Optional) Configure OSPF.
  8. Configure the routing policy.
  9. Configure the routing instance.

Configuring Device PE3

Step-by-Step Procedure

  1. Configure the interfaces.
  2. Configure the autonomous number (AS).
  3. Configure RSVP.
  4. Configure MPLS.
  5. Configure BGP.
  6. Configure IS-IS.
  7. (Optional) Configure OSPF.
  8. Configure the routing instance.

Configuring Device CE2

Step-by-Step Procedure

  1. Configure the interfaces.

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.

Device CE1

Device PE1

Device P

Device PE2

Device PE3

Device CE2

Verification

Verifying the Routing Instance

Purpose

Check the routes in the routing table.

Action

user@PE1> show route 10.10.50 table vpn.inet.0
user@PE1>show route 10.10.50 extensive table vpn.inet.0
user@PE2> show route table mpls.0
user@PE2> show route table __1.1.1.1__.mpls.0
user@PE2> show route table __1.1.1.1__.mpls.0 extensive
user@PE2> show route table __1.1.1.1-vpn__.inet.0
user@PE2> show route table __1.1.1.1-vpn__.inet.0 extensive
user@PE2> show route table mpls.0 label 17
user@PE2> show route table mpls.0 label 17 extensive
user@PE3> show route table mpls.0
user@PE3> show route table mpls.0 label 16
user@PE3> show route table mpls.0 label 16 extensive

Checking the Context Identifier Route

Purpose

Examine the information about the context identifier (1.1.1.1).

Action

user@PE1> show route 1.1.1.1
user@PE2> show route 1.1.1.1
user@PE2> show mpls context-identifier
user@PE2> show mpls context-identifier detail
user@PE3> show route 1.1.1.1
user@PE3> show mpls context-identifier
user@PE3> show mpls context-identifier detail

Understanding MPLS and Path Protection on EX Series Switches

Junos OS MPLS for Juniper Networks EX Series Ethernet Switches provides path protection to protect your MPLS network from label switched path (LSP) failures.

By default, an LSP routes itself hop-by-hop from the ingress provider edge switch through the provider switches toward the egress provider edge switch. The LSP generally follows the shortest path as dictated by the local routing table, usually taking the same path as destination-based, best-effort traffic. These paths are “soft” in nature because they automatically reroute themselves whenever a change occurs in a routing table or in the status of a node or link.

Typically, when an LSP fails, the switch immediately upstream from the failure signals the outage to the ingress provider edge switch. The ingress provider edge switch calculates a new path to the egress provider edge switch, establishes the new LSP, and then directs traffic from the failed path to the new path. This rerouting process can be time-consuming and prone to failure. For example, the outage signals to the ingress switch might get lost or the new path might take too long to come up, resulting in significant packet drops.

You can configure path protection by configuring primary and secondary paths on the ingress switch. If the primary path fails, the ingress switch immediately reroutes traffic from the failed path to the standby path, eliminating the need for the ingress switch to calculate a new route and signal a new path. For information about configuring standby LSPs, see Configuring Path Protection in an MPLS Network (CLI Procedure).

Verifying Path Protection in an MPLS Network

To verify that path protection is working correctly on EX Series switches, perform the following tasks:

  1. Verifying the Primary Path

  2. Verifying the RSVP-Enabled Interfaces

  3. Verifying a Secondary Path

Verifying the Primary Path

Purpose

Verify that the primary path is operational.

Action

user@switch> show mpls lsp extensive ingress

Meaning

As indicated by the ActivePath in the output, the LSP primary_path_lsp_to_240 is active.

Verifying the RSVP-Enabled Interfaces

Purpose

Verify the status of Resource Reservation Protocol (RSVP)-enabled interfaces and packet statistics.

Action

user@switch> show rsvp interfaces

Meaning

This output verifies that RSVP is enabled and operational on interface ge-0/0/20.0.

Verifying a Secondary Path

Purpose

Verify that a secondary path is established.

Action

Deactivate a switch that is critical to the primary path and then issue the following command:

user@switch> show mpls lsp extensive

Meaning

As indicated by the ActivePath in the output, the LSP secondary_path_lsp_to_240 is active.

Related Documentation

Release History Table
Release
Description
Starting in Junos OS Release 15.1, the enhanced point of local repair (PLR) functionality addresses a special scenario of egress node protection, where the PLR and the protector are co-located as one router. In this case, there is no need to have a bypass LSP reroute traffic during local repair.
Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there is a link or node failure in the egress PE node.
Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there is a link or node failure in the egress PE node.