Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Provider Edge Link Protections in Layer 3 VPNs

 

This topic describes and provides examples on configuring precomputed protection path, which provides link protection and a backup path between a CE router and an alternative PE router.

In MPLS service provider networks, when Layer 3 VPNs are used for carrier-of-carriers deployments, the protocol used to link the customer edge (CE) routers in one autonomous system (AS) and a provider edge (PE) router in another AS is BGP labeled-unicast. Reroute solutions between ASs are essential to help service providers ensure that network outages will have minimal impact on the data flows through the networks. A service provider that is a customer of another service provider can have different CE routers that are connected to the other service provider through different PE routers. This setup enables load balancing of traffic. However, this can lead to disruption in traffic if the link between one CE router and a PE router goes down. Therefore, a precomputed protection path should be configured such that if a link between a CE router and a PE router goes down, the protection path (also known as the backup path) between the other CE router and the alternative PE router can be used.

To configure a labeled-unicast path to be a protection path, use the protection statement at the [edit routing-instances instance-name protocols bgp family inet labeled-unicast] hierarchy level:

The protection statement indicates that protection is desired on prefixes received from the particular neighbor or family. After protection is enabled for a given family, group, or neighbor, protection entries are added for prefixes or next hops received from the given peer.

Note

A protection path can be selected only if the best path has already been installed by BGP in the forwarding table. This is because a protection path cannot be used as the best path.

To minimize packet loss when the protected path is down, also use the per-prefix-label statement at the [edit routing-instances instance-name protocols bgp family inet labeled-unicast] hierarchy level. Set this statement on every PE router within the AS containing the protected path.

The protection path selection takes place based on the value of two state flags:

  • The ProtectionPath flag indicates paths desiring protection.

  • The ProtectionCand flag indicates the route entry that can be used as a protection path.

Note
  • Provider edge link protection is configured only for external peers.

  • If provider edge link protection is configured with the equal-external-internal multipath statement, multipath takes precedence over protection.

In an MPLS service provider network, a customer can have dual-homed CE routers that are connected to the service provider through different PE routers. This setup enables load balancing of traffic in the service provider network. However, this can lead to disruption in traffic if the link between a CE router and a PE router goes down. Hence, a precomputed protection path should be configured such that if a link between a CE router and a PE router goes down, the protection path (also known as the backup path) between the CE router and an alternate PE router can be used.

To configure a path to be a protection path, use the protection statement at the [edit routing-instances instance-name protocols bgp family inet unicast] hierarchy level:

The protection statement indicates that protection is required on prefixes received from the particular neighbor or family. After protection is enabled for a given family, group, or neighbor, protection entries are added for prefixes or next hops received from the given peer.

Note

A protection path can be selected only if the best path has already been installed by BGP in the forwarding table. This is because a protection path cannot be used as the best path.

Note

The option vrf-table-label must be configured under the [routing-instances instance-name] hierarchy for the routers that have protected PE-CE links. This applies to Junos OS Releases 12.3 through 13.2 inclusive.

The protection path selection takes place based on the value of two state flags:

  • The ProtectionPath flag indicates paths requesting protection.

  • The ProtectionCand flag indicates the route entry that can be used as a protection path.

Note
  • Provider edge link protection is configured only for external peers.

  • If provider edge link protection is configured with the equal-external-internal multipath statement, multipath takes precedence over protection.

This example shows how to configure a provider edge protection path that can be used in case of a link failure in an MPLS network.

Requirements

This example uses the following hardware components, software components and configuration options:

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

  • Junos OS Release 12.3 through 13.2 inclusive

  • The option vrf-table-label must be enabled at the [routing-instances instance-name] hierarchy level for routers with protected PE-CE links.

Overview

The following example shows how to configure provider edge link protection in a Layer 3 VPN.

Topology

In this example, a Layer 3 VPN is set up by configuring three customer edge devices and three service provider edge devices in four autonomous systems. The CE devices are configured in AS 64496, AS 64498, and AS 64499. The PE devices are configured in AS 64497.

Figure 1 shows the topology used in this example.

Figure 1: Provider Edge Link Protection in a Layer 3 VPN
Provider Edge Link Protection in
a Layer 3 VPN

The aim of this example is to protect the provider edge link between Routers PE2 and CE2. Protection is configured on the backup link between Routers PE3 and CE2, such that the traffic can be routed through this link when the PE2-CE2 link goes down.

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.

Router CE1

Router PE1

Router PE2

Router PE3

Router P

Router CE2

Router CE3

Configuring Provider Edge Link Protection in Layer 3 VPNs

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.

To configure provider edge link protection:

  1. Configure the router interfaces.

    Similarly, configure the interfaces on all other routers.

  2. Configure the router ID and autonomous system (AS) number.

    Similarly, configure the router ID and AS number for all other routers. In this example, the router ID is chosen to be identical to the loopback address configured on the router.

  3. Configure MPLS and LDP on all interfaces of Router PE3.

    Similarly, configure other PE routers.

  4. Configure an IGP on the core-facing interfaces of Router PE3.

    Similarly, configure other PE routers.

  5. Configure a policy that exports the routes from the routing table into the forwarding table on Router PE3.

    Similarly, configure other PE routers.

  6. Configure BGP on Router CE2, and include a policy for exporting routes to and from the service provider network.

    Similarly, configure other CE routers.

  7. Configure BGP on Router PE3 for routing within the provider core.

    Similarly, configure other PE routers.

  8. Configure the Layer 3 VPN routing instance on Router PE3.

    Similarly, configure other PE routers.

  9. Configure provider edge link protection on the link between Routers PE3 and CE2.

Results

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

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

user@PE3# show interfaces
user@PE3# show routing-options
user@PE3# show policy-options
user@PE3# show protocols
user@PE3# show routing-instances

Run these commands on all other routers to confirm the configurations. If you are done configuring the routers, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying BGP

Purpose

Verify that BGP is functional in the Layer 3 VPN.

Action

From operational mode on Router PE3, run the show route protocol bgp command.

user@PE3> show route protocol bgp

The output shows all the BGP routes in the routing table of Router PE3. This indicates that BGP is functioning as required.

Similarly, run this command on other routers to check if BGP is operational.

Meaning

BGP is functional in the Layer 3 VPN.

Purpose

Verify that the provider edge link between Routers PE2 and CE2 is protected.

Action

To verify that provider edge link protection is configured correctly:

  1. Confirm that a route on Router CE2 is advertised to Router PE3, directly and through Router PE2.

    If the route is advertised correctly, you will see multiple paths for the route.

    From operational mode on Router PE3, run the show route destination-prefix command.

    user@PE3> show route 192.0.2.6

    The output verifies the presence of multiple paths from Router PE3 to the destination route, 192.0.2.6, on Router CE2. The first path is directly through the PE3-CE2 link (10.1.1.26). The second path is through the provider core and PE2 (10.1.1.17).

  2. Verify that the protection path is correctly configured by confirming that the weight for the active path being protected is 0x1, and the weight for the protection candidate path is 0x4000.

    From operational mode on Router PE3, run the show route destination-prefix extensive command.

    user@PE3> show route 192.0.2.6 extensive

    The output shows that the weight (0x4000) assigned to the PE3-CE2 path is greater than the weight (0x1) assigned to the PE2-CE2 path. This confirms that the PE2-CE2 path is protected by the PE3-CE2 path.

Meaning

The provider edge link between Routers PE2 and CE2 is protected.

This example shows how to configure a labeled unicast protection path that can be used in case of a link failure in a carrier-of-carriers topology.

Requirements

This example uses the following hardware and software components:

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

  • Junos OS Release 13.3 or later

Overview

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

Topology

In this example, a carrier-of-carriers topology is set up by configuring two customer edge devices and eight service provider edge devices in five autonomous systems. The CE devices are configured in AS100 and AS101. The PE devices are configured in AS200, AS300, and AS201.

Figure 2 shows the topology used in this example.

Figure 2: Labeled Unicast Link Protection in a Layer 3 VPN
Labeled Unicast Link Protection
in a Layer 3 VPN

The aim of this example is to protect the provider edge link between Routers R4 and R3. Protection is configured on the primary link between R4 and R3 such that the traffic can be routed through the backup link (R11 to R10) when the primary link goes down.

Note

Protection can also be configured on the secondary link between R11 and R10 so that if that link becomes the primary link and the R4-R3 link becomes secondary, the R11-R10 link will be protected as well.

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.

Note

Protection is added to the configuration only after the initial configuration is committed and BGP has installed the best path in the forwarding table.

Router R0

Router R1

Router R2

Router R3

Router R4

Router R5

Router R6

Router R7

Router R8

Router R9

Router R10

Router R11

Configuring Provider Edge Link Protection in Layer 3 VPNs

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.

To configure labeled unicast link protection:

  1. Configure the router interfaces.

    Similarly, configure the interfaces on all other routers.

  2. Configure the routing policy options on R4.

    Similarly, configure the policy options on routers R1, R3, R7, R8, R9, and R10 for this example.

  3. Configure the router ID, autonomous system (AS) number, and any other routing options.

    Similarly, configure the router ID, AS number, and any other routing options for all other routers. In this example, the router ID is chosen to be identical to the loopback address configured on the router.

  4. Configure MPLS and LDP on Router R4.

    Similarly, configure MPLS and LDP on all other routers except R0 and R9.

  5. Configure an IGP on the core-facing interfaces of Router R4.

    Similarly, configure other routers (IS-IS on R5, R6, and R11 and OSPF on all other routers in this example).

  6. Configure BGP on Router R4.

    Similarly, configure BGP on routers R1, R3, R6, R7, R8, R10, and R11.

  7. Configure a VPN routing and forwarding (VRF) instance on Router R4 to create a Layer 3 VPN.

    Similarly, configure other VRF routing instances on R1, R6, R8, and R11.

Results

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

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

user@R4# show interfaces
user@R4# show policy-options
user@R4# show routing-options
user@R4# show protocols
user@R4# show routing-instances

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

Confirm that the configuration is working properly.

Enabling Protection

Purpose

Enable protection on R4 to request protection for the link from R4 to R3.

Action

  1. Add the protection statement at the [edit routing-instances instance-name protocols bgp group group-name family inet labeled-unicast] hierarchy level.
  2. Verify and commit the configuration.

Verifying Multipath Entries

Purpose

Verify that R4 has a multipath entry with two entries.

Action

From operational mode on Router R4, run the show route 192.0.2.2 command to check the route to R1.

user@R4> show route 192.0.2.2

Verifying That Multipath Entries Have Different Weights

Purpose

Verify that the two routes in the multipath entry have different weights, with the first entry having a weight of 0x1 and the second having a weight of 0x4000.

Action

From operational mode on Router R4, run the show route 192.0.2.2 detail command to check the route to R1.

user@R4> show route 192.0.2.2 detail

Understanding Host Fast Reroute

Host fast reroute (HFRR) adds a precomputed protection path into the Packet Forwarding Engine (PFE), such that if a link between a provider edge device and a server farm becomes unusable for forwarding, the PFE can use another path without having to wait for the router or the protocols to provide updated forwarding information. This precomputed protection path is often called a repair or a backup path.

HFRR is a technology that protects IP endpoints on multipoint interfaces, such as Ethernet. This technology is important in datacenters where fast service restoration for server endpoints is critical. After an interface or a link goes down, HFRR enables the local repair time to be approximately 50 milliseconds.

Consider the network topology shown in Figure 3.

Figure 3: Host Fast Reroute
Host Fast Reroute

Routing devices create host route forwarding entries triggered by the Address Resolution Protocol (ARP) and IPv6 Neighbor Discovery Protocol (NDP). HFRR augments the host routes with backup next hops supplied by routing protocols. These backup next hops enable arriving traffic to keep flowing while the network reconverges.

Traffic flows from networks connected to the provider edge devices, PE1 and PE2, to host A and host B. This traffic is protected with HFRR. If the link goes down between device PE2 and the host servers, traffic is rerouted through device PE1 to the host servers. In the topology, host A and host B represent LAN PCs, collectively known as a server farm. The PE devices are routers with a Layer 3 VPN configured between them. Device PE1 learns about the directly connected hosts by way of ARP or the IPv6 NDP.

Device PE2 also has information about the server farm network and advertises this information to Device PE1. This advertisement is transmitted through the Layer 3 VPN using internal BGP (IBGP). On Devices PE1 and PE2, this route is considered a direct route to the server farm subnet.

Device PE1 uses the host routes learned through ARP and NDP to send traffic to the host machines in the server farm. If the link between Device PE1 and the server farm is disrupted and if HFRR is not configured, the routing device finds the next best route, which is the IBGP route. This implementation results in traffic loss for an interval until the update occurs and the network reconverges. HFRR configured on Device PE1 resolves this issue by augmenting the ARP and NDP routes with a backup path so that traffic can continue to be forwarded without interruption.

The backup path in this particular topology is the IBGP Layer 3 VPN route. In an actual deployment, Device PE2 can also configure link protection for its directly connected server farm network, and Device PE1 can advertise reachability to the server farm through itself using the Layer 3 VPN routes to Device PE2. Therefore, HFRR should be enabled on both Device PE1 and Device PE2. Also, Device PE1 and Device PE2 should both advertise reachability to the server farm through BGP.

A temporary routing loop can develop between the PE devices if, for example, the link between Device PE1 to the server farm and the link between Device PE2 to the server farm both go down at same time. The loop can continue until BGP on both ends learns that the server farm subnet is down and withdraws the BGP routes.

ARP Prefix Limit and Blackout Supplementary Timeout

When you configure HFRR profiles, an optional ARP prefix limit sets a maximum for the number of ARP routes and, therefore, FRR routes created for each HFRR profile in the routing table. This limit prevents ARP attacks from exhausting the virtual memory on the routing devices. The ARP prefix limit does not limit ARP routes in the forwarding table. It does, however, limit the number of ARP routes that Junos OS reads for a profile and therefore limits the number of HFRR routes that the routing process (rpd) creates in the routing table and the forwarding table.

The ARP prefix limit is applied to each HFRR profile. It does not limit the total count of all ARP/HFRR routes in the routing table. It only limits the number of ARP/HFRR routes for each HFRR profile.

There are two configuration statements (global-arp-prefix-limit and arp-prefix-limit) that set the ARP prefix limit, one at the global [edit routing-options host-fast-reroute] hierarchy level and the other at the [edit routing-instances instance-name routing-options interface interface-name] hierarchy level, respectively. The global global-arp-prefix-limit statement sets a default ARP prefix limit for all HFRR profiles configured on the routing device. The arp-prefix-limit statement overrides the global-arp-prefix-limit for that HFRR profile for that protected interface.

When the number of ARP routes in an HFRR profile reaches 80% of the configured ARP prefix limit, a warning message is sent to the system log. The warning message is displayed for any subsequent ARP route added to that HFRR profile if the ARP prefixes remain at greater than 80% of the configured value.

When the number of ARP routes in an HFRR profile reaches 100% of the configured ARP prefix limit for an HFRR profile, another warning message is sent to the system log. When the number crosses the 100% threshold, the HFRR profile is deactivated. When this happens, all ARP/FRR routes are deleted from the routing table. FRR routes are deleted from forwarding table as well.

After the HFRR profile is deactivated, a blackout timer is started. The timeout value of this timer is the ARP cache timeout (kernel timeout) + the supplementary blackout timer.

There are global and per-HFRR CLI statements (global-supplementary-blackout-timer and supplementary-blackout-timer). The global value is at the [edit routing-options host-fast-reroute] hierarchy level and applies to all HFRR profiles on the routing device. The supplementary blackout timer configured for the routing-instance interface at the [edit routing-instances instance-name routing-options interface interface-name] hierarchy level overrides the global value for that HFRR profile only.

When the blackout timer expires, the HFRR profile is reactivated, and Junos OS relearns the ARP routes and re-creates the HFRR routes. If the ARP prefix limit is not exceeded again, the HFRR routes will be up.

If an HFRR profile is blacklisted and is in the deactivated state, a reevaluation of the ARP state is performed during every commit operation or whenever the routing process (rpd) is restarted with the restart routing command.

Primary Route and Backup Route Candidates

The primary route for the HFRR next hop is provided by the ARP and IPv6 NDP routes. These are /32 or /128 routes. The backup route is an exact prefix match of the address configured on the local interface. For example, if the local address configured is 10.0.0.5/24, the routing device looks for an exact match of prefix 10.0.0.0 with a prefix length of 24 for selection of backup route.

Constraints for backup route selection are as follows:

  • Must be a prefix matching the same subnet address configured on the routing device’s HFRR-enabled interface.

  • The remote end must not have route aggregation (also known as summarization) configured. For example, if the remote end combines two or more /24 subnets to advertise a subnet with a prefix length smaller than /24, the Junos OS does not select this summarized route to be a backup route.

  • If there is another route in the routing table learned by another protocol with a longest-prefix match for the /32 or /128 (ARP or NDP) route, that route is not selected to be a backup candidate. For example, suppose that the local interface address is 10.0.0.5/24. Also suppose that the routing table contains an IBGP route with a prefix of 10.0.0.0/24 and an OSPF route with a prefix of 10.0.0.0/28. Even though the /28 route is a better route for certain prefixes in the subnet, the Junos OS does not consider 10.0.0.0/28 to be a backup candidate. The IBGP route becomes the backup candidate for all host routes. However, after the global repair, the OSPF route is used for forwarding.

In short, the backup candidate must be a route with the same prefix as the subnet local interface that you are protecting with HFRR.

Backup Path Selection Policy

Only Layer 3 VPN routes are considered for backup selection. HFRR uses the usual BGP path selection algorithm to select one best backup route. Only one backup path is selected. In case there are multiple backup path candidates, the selection algorithm selects the best backup path. HFRR provides only two paths, one primary and one backup at any point in time. If the selected backup path itself has two paths in it, then the first path in that backup next hop is used as the backup next hop for the HFRR route.

The primary path is installed with a weight of one. The backup path is installed with a weight of 0x4000. The backup path obviously must be a path through an interface that is not the same as the primary interface.

The backup route is looked up only in the routing table to which interface belongs. For IPv4, the Junos OS uses routing-instance-name.inet.0. For IPv6, the Junos OS looks in routing-instance-name.inet6.0.

Characteristics of HFRR Routes

The HFRR route is a forwarding-only route and is not used for route resolution. HFRR routes have host addresses, meaning that they have /32 or /128 as the prefix length. In the case of platforms with dual Routing Engines, the backup routing process (rpd) also creates HFRR routes. However, the backup outing process (rpd) does not install HFRR routes to a routing table until the backup becomes the master after a Routing Engine switchover.

Also note that if an HFRR route is present in the routing table, the HFRR route is used for the unicast reverse-path-forwarding (uRPF) computation.

Removal of HFRR Routes

HFRR routes are deleted if the protected interface is deleted or deactivated in the configuration, if HFRR is configured on a routing instance and the routing instance is deactivated or deleted, or when the statement that enables HFRR (link-protection (Host Fast Reroute)) is deleted or deactivated. HFRR routes are deleted and readded when there is a catastrophic operation on routing the instance, such as when the routing process is restarted. HFRR routes are also be removed if all backup routes are deleted. such as when BGP withdraws routes or when BGP is deactivated or deleted.

After a protected interface goes down and if HFRR is deleted or deactivated, a timer starts with a timeout of 20 seconds. The HFRR route deletion occurs after the timer expires. This is to ensure that if the interface is flapping (quickly going up and down), the Junos OS does not unnecessarily perform route deletions and additions that cause traffic loss. This timer is used only when the interface is down or when the HFRR route is deleted or deactivated.

HFRR routes are purged immediately in the following cases:

  • A backup route goes down and there are no other potential backup paths.

  • An ARP delete message is received.

  • The routing process (rpd) terminates.

Interfaces That Support HFRR

HFRR is allowed only on Ethernet interfaces. The commit operation fails if you configure HFRR on point-to-point interfaces.

Only interfaces configured under routing instance of type VPN routing and forwarding (VRF) are accepted. The commit operation fails if you configure HFRR on other types of routing instances.

When the following requirements are not met, the commit operation does not fail. However, the interface is not protected by HFRR, and the interface is marked inactive in the show hfrr profiles command output:

  • HFRR is allowed only on numbered interfaces, meaning that an address must be assigned to the interface. You cannot, for example, configure IPv4on the interface with an address and IPv6 without an address.

  • Interfaces that are configured for HFRR protection must be configured at the [edit interfaces] hierarchy level and also must be attached to the routing instance.

  • The routing instance must have a virtual tunnel (VT) interface or the vrf-table-label statement included.

Another reason the interface might be marked inactive in the show hfrr profiles command output is when the interface is migrating from one instance to another, and the HFRR configuration is in the previous routing instance.

HFRR is not supported on overlapping logical units if they belong to the same routing instance, as shown here:

If you configure overlapping subnets as shown here, and if you enable HFRR on both of the overlapping subnets, the routing protocol process (rpd) generates an RPD_ASSERT error.

This example shows you how to configure host fast reroute (HFRR). HFRR protects IP endpoints on multipoint interfaces, such as Ethernet.

Requirements

This example uses the following hardware and software components:

  • Two provider edge (PE) devices and four provider (P) devices.

  • The example assumes that hosts are present, behind the PE devices.

  • The example assumes that at least one Layer 3 switch, such as an EX Series switch, is attached to the hosts.

  • Junos OS 11.4R2 or later.

Overview

In this example, traffic flows to server hosts from networks connected to PE devices. This traffic is protected with HFRR. If the link goes down between one PE device and the server farm, traffic is rerouted to the server farm through the other PE device.

You can configure HFRR by adding the link-protection statement to the interface configuration in the routing instance.

We recommend that you include this statement on all PE devices that are connected to server farms through multipoint interfaces.

In this example, the PE devices advertise reachability to their server farms through Layer 3 VPN routes and BGP.

As optional settings, the PE devices have the high availability features Nonstop Active Routing and Virtual Router Redundancy Protocol (VRRP) configured. Nonstop active routing (NSR) enables a routing platform with redundant Routing Engines to switch from a primary Routing Engine to a backup Routing Engine without alerting peer nodes that a change has occurred and without losing routing and protocol information. VRRP provides for automatic assignment of available routers to participating hosts, thus increasing the availability and reliability of routing paths.

Topology Diagram

Figure 4 shows the topology used in this example.

Figure 4: Host Fast Reroute Topology
Host Fast Reroute Topology

This example shows the configuration on all of the routing devices and shows the step-by-step procedure on Device PE1.

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 PE1

Device PE2

Device P1

Device P2

Device P4

Device P5

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 HFRR:

  1. Configure the interfaces.
  2. (Optional) Configure VRRP on the interface to Device PE2.
  3. Configure MPLS on the interfaces.
  4. Configure BGP.
  5. Configure a policy that advertises direct and local interface routes.
  6. Configure an interior gateway protocol, such as IS-IS or OSPF.
  7. Configure a signaling protocol, such as RSVP or LDP.
  8. (Optional) Configure nonstop active routing.
  9. Configure the autonomous system (AS).
  10. Configure the Layer 3 VPN routing instance.
  11. Configure HFRR link protection.
  12. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by issuing the show interfaces, show protocols, show policy-options, show routing-options, and show routing-instances commands.

Verification

Confirm that the configuration is working properly.

Verifying HFRR

Purpose

Make sure that HFRR is enabled.

Action

Meaning

The output shows that the HFRR is enabled on interface ge-4/1/0.0.

Verifying ARP Routes

Purpose

Make sure that the expected ARP routes are learned.

Action

user@PE1> show route protocol arp

Verifying Fast Reroute Routes

Purpose

Make sure that the expected fast reroute (FRR) routes are learned.

Action

user@PE1> show route protocol frr

Verifying Forwarding

Purpose

Make sure that the expected routes appear in the forwarding table.

Action

user@PE1> show route forwarding-table destination 192.0.2.3