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.
Understanding Provider Edge Link Protection for BGP Labeled Unicast Paths
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.
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.
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.
Understanding Provider Edge Link Protection in Layer 3 VPNs
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.
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.
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.
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.
Example: Configuring Provider Edge Link Protection in Layer 3 VPNs
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.
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:
- Configure the router interfaces.[edit interfaces]user@PE3# set ge-2/0/0 unit 0 description toPE1user@PE3# set ge-2/0/0 unit 0 family inet address 10.1.1.10/30user@PE3# set ge-2/0/0 unit 0 family inet6 address 2001:db8:0:9::/64 eui-64user@PE3# set ge-2/0/0 unit 0 family mplsuser@PE3# set ge-2/0/1 unit 0 description toPuser@PE3# set ge-2/0/1 unit 0 family inet address 10.1.1.18/30user@PE3# set ge-2/0/1 unit 0 family inet6 address 2001:db8:0:17::/64 eui-64user@PE3# set ge-2/0/1 unit 0 family mplsuser@PE3# set ge-2/0/2 unit 0 description toCE2user@PE3# set ge-2/0/2 unit 0 family inet address 10.1.1.25/30user@PE3# set ge-2/0/2 unit 0 family inet6 address 12001:db8:0:25::/64 eui-64user@PE3# set ge-2/0/2 unit 0 family mplsuser@PE3# set ge-2/0/3 unit 0 description toCE3user@PE3# set ge-2/0/3 unit 0 family inet address 10.1.1.21/30user@PE3# set ge-2/0/3 unit 0 family inet6 address 2001:db8:0:21::/64 eui-64user@PE3# set ge-2/0/3 unit 0 family mplsuser@PE3# set lo0 unit 0 family inet address 192.0.2.4/24user@PE3# set lo0 unit 0 family inet6 address 2001:db8::4/128
Similarly, configure the interfaces on all other routers.
- Configure the router ID and autonomous system (AS) number.[edit routing-options]user@PE3# set router-id 192.0.2.4user@PE3# set autonomous-system 64497
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.
- Configure MPLS and LDP on all interfaces of Router PE3.[edit protocols]user@PE3# set mpls interface alluser@PE3# set ldp interface all
Similarly, configure other PE routers.
- Configure an IGP on the core-facing interfaces of Router
PE3.[edit protocols ospf area 0.0.0.0]user@PE3# set interface lo0.0 passiveuser@PE3# set interface ge-2/0/1.0 metric 5user@PE3# set interface ge-2/0/0.0 metric 10[edit protocols ospf3 area 0.0.0.0]user@PE3# set interface lo0.0 passiveuser@PE3# set interface ge-2/0/1.0 metric 5user@PE3# set interface ge-2/0/0.0 metric 10
Similarly, configure other PE routers.
- Configure a policy that exports the routes from the routing
table into the forwarding table on Router PE3.[edit policy-options]user@PE3# set policy-statement lb then load-balance per-packet[edit routing-options]user@PE3# set forwarding-table export lb
Similarly, configure other PE routers.
- Configure BGP on Router CE2, and include a policy for
exporting routes to and from the service provider network.[edit policy-options]user@CE2# set policy-statement send-direct from protocol directuser@CE2# set policy-statement send-direct then accept[edit protocols bgp group toAS2]user@CE2# set type externaluser@CE2# set export send-directuser@CE2# set peer-as 64497user@CE2# set neighbor 10.1.1.25user@CE2# set neighbor 10.1.1.29
Similarly, configure other CE routers.
- Configure BGP on Router PE3 for routing within the provider
core.[edit protocols bgp group toInternal]user@PE3# set type internaluser@PE3# set family inet-vpn unicastuser@PE3# set family inet6-vpn unicastuser@PE3# set multipathuser@PE3# set local-address 192.0.2.4user@PE3# set neighbor 192.0.2.2user@PE3# set neighbor 192.0.2.3
Similarly, configure other PE routers.
- Configure the Layer 3 VPN routing instance on Router PE3.[set routing-instances radium]user@PE3# set instance-type vrfuser@PE3# set vrf-table-labeluser@PE3# set interface ge-2/0/2.0user@PE3# set interface ge-2/0/3.0user@PE3# set route-distinguisher 64497:1user@PE3# set vrf-target target:64497:1[edit routing-instances radium protocols bgp group toCE2]user@PE3# set type externaluser@PE3# set peer-as 64498user@PE3# set neighbor 10.1.1.26[edit routing-instances radium protocols bgp group toCE3]user@PE3# set type externaluser@PE3# set peer-as 64499user@PE3# set neighbor 10.1.1.22
Similarly, configure other PE routers.
- Configure provider edge link protection on the link between
Routers PE3 and CE2.[edit routing-instances radium protocols bgp group toCE2]user@PE3# set family inet unicast protectionuser@PE3# set family inet6 unicast protection
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 interfacesge-2/0/0 {
unit 0 {
description toPE1;
family inet {
address 10.1.1.10/30;
}
family inet6 {
address 2001:db8:0:9::/64 {
eui-64;
}
}
family mpls;
}
}
ge-2/0/1 {
unit 0 {
description toP;
family inet {
address 10.1.1.18/30;
}
family inet6 {
address 2001:db8:0:17::/64 {
eui-64;
}
}
family mpls;
}
}
ge-2/0/2 {
unit 0 {
description toCE2;
family inet {
address 10.1.1.25/30;
}
family inet6 {
address 2001:db8:0:25::/64 {
eui-64;
}
}
family mpls;
}
}
ge-2/0/3 {
unit 0 {
description toCE3;
family inet {
address 10.1.1.21/30;
}
family inet6 {
address 2001:db8:0:21::/64 {
eui-64;
}
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.4/24;
}
family inet6 {
address 2001:db8::4/128;
}
}
}
user@PE3# show routing-optionsrouter-id 192.0.2.4;
autonomous-system 64497;
forwarding-table {
export lb;
}user@PE3# show policy-optionspolicy-statement lb {
then {
load-balance per-packet;
}
}user@PE3# show protocolsmpls {
interface all;
}
bgp {
group toInternal {
type internal;
local-address 192.0.2.4;
family inet-vpn {
unicast;
}
family inet6-vpn {
unicast;
}
multipath;
neighbor 192.0.2.2;
neighbor 192.0.2.3;
}
}
ospf {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ge-2/0/1.0 {
metric 5;
}
interface ge-2/0/0.0 {
metric 10;
}
}
}
ospf3 {
area 0.0.0.0 {
interface lo0.0 {
passive;
}
interface ge-2/0/1.0 {
metric 5;
}
interface ge-2/0/0.0 {
metric 10;
}
}
}
ldp {
interface all;
}user@PE3# show routing-instancesradium {
instance-type vrf;
interface ge-2/0/2.0;
interface ge-2/0/3.0;
route-distinguisher 64497:1;
vrf-target target:64497:1;
protocols {
bgp {
group toCE2 {
type external;
family inet {
unicast {
protection;
}
}
family inet6 {
unicast {
protection;
}
}
peer-as 64498;
neighbor 10.1.1.26;
}
group toCE3 {
type external;
peer-as 64499;
neighbor 10.1.1.22;
}
}
}
}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 bgpinet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
radium.inet.0: 9 destinations, 14 routes (9 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
192.0.2.1/24 *[BGP/170] 00:09:15, localpref 100, from 192.0.2.2
AS path: 64496 I, validation-state: unverified
> to 10.1.1.9 via ge-2/0/0.0, Push 299792
192.0.2.6/24 @[BGP/170] 00:09:40, localpref 100
AS path: 64498 I, validation-state: unverified
> to 10.1.1.26 via ge-2/0/2.0
[BGP/170] 00:09:07, localpref 100, from 192.0.2.3
AS path: 64498 I, validation-state: unverified
> to 10.1.1.17 via ge-2/0/1.0, Push 299792, Push 299776(top)
192.0.2.7/24 *[BGP/170] 00:09:26, localpref 100
AS path: 64499 I, validation-state: unverified
> to 10.1.1.22 via ge-2/0/3.0
10.1.1.0/30 *[BGP/170] 00:09:15, localpref 100, from 192.0.2.2
AS path: I, validation-state: unverified
> to 10.1.1.9 via ge-2/0/0.0, Push 299792
10.1.1.20/30 [BGP/170] 00:09:26, localpref 100
AS path: 64499 I, validation-state: unverified
> to 10.1.1.22 via ge-2/0/3.0
10.1.1.24/30 [BGP/170] 00:09:40, localpref 100
AS path: 64498 I, validation-state: unverified
> to 10.1.1.26 via ge-2/0/2.0
10.1.1.28/30 *[BGP/170] 00:09:07, localpref 100, from 192.0.2.3
AS path: I, validation-state: unverified
> to 10.1.1.17 via ge-2/0/1.0, Push 299792, Push 299776(top)
[BGP/170] 00:09:40, localpref 100
AS path: 64498 I, validation-state: unverified
> to 10.1.1.26 via ge-2/0/2.0
mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
bgp.l3vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
64497:1:192.0.2.1/24
*[BGP/170] 00:09:15, localpref 100, from 192.0.2.2
AS path: 64496 I, validation-state: unverified
> to 10.1.1.9 via ge-2/0/0.0, Push 299792
64497:1:192.0.2.6/24
*[BGP/170] 00:09:07, localpref 100, from 192.0.2.3
AS path: 64498 I, validation-state: unverified
> to 10.1.1.17 via ge-2/0/1.0, Push 299792, Push 299776(top)
64497:1:10.1.1.0/30
*[BGP/170] 00:09:15, localpref 100, from 192.0.2.2
AS path: I, validation-state: unverified
> to 10.1.1.9 via ge-2/0/0.0, Push 299792
64497:1:10.1.1.28/30
*[BGP/170] 00:09:07, localpref 100, from 192.0.2.3
AS path: I, validation-state: unverified
> to 10.1.1.17 via ge-2/0/1.0, Push 299792, Push 299776(top)
inet6.0: 12 destinations, 13 routes (12 active, 0 holddown, 0 hidden)
radium.inet6.0: 7 destinations, 8 routes (7 active, 0 holddown, 0 hidden)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.
Verifying Provider Edge Link Protection
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:
- 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.6radium.inet.0: 9 destinations, 14 routes (9 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 192.0.2.6/24 @[BGP/170] 02:55:36, localpref 100 AS path: 64498 I, validation-state: unverified > to 10.1.1.26 via ge-2/0/2.0 [BGP/170] 00:10:13, localpref 100, from 192.0.2.3 AS path: 64498 I, validation-state: unverified > to 10.1.1.17 via ge-2/0/1.0, Push 299840, Push 299776(top) #[Multipath/255] 00:10:13 > to 10.1.1.26 via ge-2/0/2.0 to 10.1.1.17 via ge-2/0/1.0, Push 299840, Push 299776(top)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).
- 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 extensiveradium.inet.0: 9 destinations, 14 routes (9 active, 0 holddown, 0 hidden) 192.0.2.6/24 (3 entries, 2 announced) State: <CalcForwarding> TSI: KRT in-kernel 192.0.2.6/24 -> {list:10.1.1.26, indirect(1048584)} Page 0 idx 1 Type 1 val 9229c38 Nexthop: Self AS path: [64497] 64498 I Communities: Page 0 idx 2 Type 1 val 9229cc4 Flags: Nexthop Change Nexthop: Self Localpref: 100 AS path: [64497] 64498 I Communities: target:64497:1 Path 192.0.2.6 from 10.1.1.26 Vector len 4. Val: 1 2 @BGP Preference: 170/-101 Next hop type: Router, Next hop index: 994 Address: 0x9240a74 Next-hop reference count: 5 Source: 10.1.1.26 Next hop: 10.1.1.26 via ge-2/0/2.0, selected Session Id: 0x200001 State: <Active Ext ProtectionPath ProtectionCand> Peer AS: 64498 Age: 2:55:54 Validation State: unverified Task: BGP_64498.10.1.1.26+52214 Announcement bits (1): 2-BGP_RT_Background AS path: 64498 I Accepted Localpref: 100 Router ID: 192.0.2.6 BGP Preference: 170/-101 Route Distinguisher: 64497:1 Next hop type: Indirect Address: 0x92413a8 Next-hop reference count: 6 Source: 192.0.2.3 Next hop type: Router, Next hop index: 1322 Next hop: 10.1.1.17 via ge-2/0/1.0, selected Label operation: Push 299840, Push 299776(top) Label TTL action: prop-ttl, prop-ttl(top) Session Id: 0x200005 Protocol next hop: 192.0.2.3 Push 299840 Indirect next hop: 94100ec 1048584 INH Session ID: 0x20000b State: <Secondary NotBest Int Ext ProtectionCand> Inactive reason: Not Best in its group - Interior > Exterior > Exterior via Interior Local AS: 64497 Peer AS: 64497 Age: 10:31 Metric2: 1 Validation State: unverified Task: BGP_64497.192.0.2.3+179 Local AS: 64497 Peer AS: 64497 Age: 10:31 Metric2: 1 Validation State: unverified Task: BGP_64497.192.0.2.3+179 AS path: 64498 I Communities: target:64497:1 Import Accepted VPN Label: 299840 Localpref: 100 Router ID: 192.0.2.3 Primary Routing Table bgp.l3vpn.0 Indirect next hops: 1 Protocol next hop: 192.0.2.3 Metric: 1 Push 299840 Indirect next hop: 94100ec 1048584 INH Session ID: 0x20000b Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.1.1.17 via ge-2/0/1.0 Session Id: 0x200005 192.0.2.3/24 Originating RIB: inet.3 Metric: 1 Node path count: 1 Forwarding nexthops: 1 Nexthop: 10.1.1.17 via ge-2/0/1.0 #Multipath Preference: 255 Next hop type: List, Next hop index: 1048585 Address: 0x944c154 Next-hop reference count: 2 Next hop: ELNH Address 0x9240a74 weight 0x1, selected equal-external-internal-type external Next hop type: Router, Next hop index: 994 Address: 0x9240a74 Next-hop reference count: 5 Next hop: 10.1.1.26 via ge-2/0/2.0 Next hop: ELNH Address 0x92413a8 weight 0x4000 equal-external-internal-type internal Next hop type: Indirect Address: 0x92413a8 Next-hop reference count: 6 Protocol next hop: 192.0.2.3 Push 299840 Indirect next hop: 94100ec 1048584 INH Session ID: 0x20000b Next hop type: Router, Next hop index: 1322 Address: 0x9241310 Next-hop reference count: 4 Next hop: 10.1.1.17 via ge-2/0/1.0 Label operation: Push 299840, Push 299776(top) Label TTL action: prop-ttl, prop-ttl(top) State: <ForwardingOnly Int Ext> Inactive reason: Forwarding use only Age: 10:31 Validation State: unverified Task: RT Announcement bits (1): 0-KRT AS path: 64498 IThe 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.
Example: Configuring Provider Edge Link Protection for BGP Labeled Unicast Paths
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.
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.
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.
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:
- Configure the router interfaces.[edit interfaces]user@R4# set ge-2/0/0 unit 0 description toR3user@R4# set ge-2/0/0 unit 0 family inet address 10.1.0.14/30user@R4# set ge-2/0/0 unit 0 family isouser@R4# set ge-2/0/0 unit 0 family mplsuser@R4# set ge-2/0/1 unit 0 description toR5user@R4# set ge-2/0/1 unit 0 family inet address 10.1.0.17/30user@R4# set ge-2/0/1 unit 0 family isouser@R4# set ge-2/0/1 unit 0 family mplsuser@R4# set lo0 unit 0 family inet address 192.0.2.5/24user@R4# set lo0 unit 0 family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5507.2049.00
Similarly, configure the interfaces on all other routers.
- Configure the routing policy options on R4.[edit policy-options]user@R4# set policy-statement 1b then load-balance per-packet
Similarly, configure the policy options on routers R1, R3, R7, R8, R9, and R10 for this example.
- Configure the router ID, autonomous system (AS) number,
and any other routing options.[edit routing-options]user@R4# set router-id 192.0.2.5user@R4# set autonomous-system 300user@R4# set forwarding-table export 1b
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.
- Configure MPLS and LDP on Router R4.[edit protocols]user@R4# set mpls interface alluser@R4# set ldp track-igp-metricuser@R4# set ldp interface ge-2/0/1.0user@R4# set ldp interface lo0.0
Similarly, configure MPLS and LDP on all other routers except R0 and R9.
- Configure an IGP on the core-facing interfaces of Router
R4.[edit protocols isis]user@R4# set level 1 disableuser@R4# set level 2 wide-metrics-onlyuser@R4# set interface ge-2/0/1.0 level 2 metric 10user@R4# set interface lo0.0 passive
Similarly, configure other routers (IS-IS on R5, R6, and R11 and OSPF on all other routers in this example).
- Configure BGP on Router R4.[edit protocols bgp group parent-vpn-peers]user@R4# set type internaluser@R4# set local-address 192.0.2.5user@R4# set family inet-vpn unicastuser@R4# set neighbor 192.0.2.7user@R4# set neighbor 192.0.2.12
Similarly, configure BGP on routers R1, R3, R6, R7, R8, R10, and R11.
- Configure a VPN routing and forwarding (VRF) instance
on Router R4 to create a Layer 3 VPN.[edit routing-instances coc-provider-vpn]user@R4# set instance-type vrfuser@R4# set interface ge-2/0/0.0user@R4# set interface ge-2/0/2.0user@R4# set route-distinguisher 192.0.2.5:1user@R4# set vrf-target target:300:1[edit routing-instances coc-provider-vpn protocols bgp group toR3]user@R4# set type externaluser@R4# set family inet labeled-unicast per-prefix-labeluser@R4# set neighbor 10.1.0.13 peer-as 200
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 interfacesge-2/0/0 {
unit 0 {
description toR3;
family inet {
address 10.1.0.14/30;
}
family iso;
family mpls;
}
}
ge-2/0/1 {
unit 0 {
description toR5;
family inet {
address 10.1.0.17/30;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.5/24;
}
family iso {
address 47.0005.80ff.f800.0000.0108.0001.0102.5507.2049.00;
}
}
}user@R4# show policy-optionspolicy-statement 1b {
then {
load-balance per-packet;
}
}user@R4# show routing-optionsrouter-id 192.0.2.5;
autonomous-system 300;
forwarding-table {
export 1b;
}user@R4# show protocolsmpls {
interface all;
}
ldp {
track-igp-metric;
interface ge-2/0/1.0;
interface lo0.0;
}
isis {
level 1 disable;
level 2 wide-metrics-only;
interface ge-2/0/1.0 {
level 2 metric 10;
}
interface lo0.0 {
passive;
}
}
bgp {
group parent-vpn-peers {
type internal;
local-address 192.0.2.5;
family inet-vpn {
unicast;
}
neighbor 192.0.2.7;
neighbor 192.0.2.12;
}
}user@R4# show routing-instancescoc-provider-vpn {
instance-type vrf;
interface ge-2/0/0.0;
interface ge-2/0/2.0;
route-distinguisher 192.0.2.5:1;
vrf-target target:300:1;
protocols {
bgp {
group toR3 {
type external;
family inet {
labeled-unicast {
per-prefix-label;
}
}
neighbor 10.1.0.13 {
peer-as 200;
}
}
}
}
}
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
- Add the protection statement at the [edit
routing-instances instance-name protocols bgp
group group-name family inet labeled-unicast] hierarchy level.[edit routing-instances coc-provider-vpn protocols bgp group toR3]user@R4# set family inet labeled-unicast protection
- Verify and commit the configuration.
type external; family inet { labeled-unicast { per-prefix-label; protection; } } neighbor 10.1.0.13 { peer-as 200; }
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#[Multipath/255] 00:02:44, metric 20
> to 10.1.0.13 via ge-2/0/0.0, Push 408592
to 10.1.0.18 via ge-2/0/1.0, Push 299856, Push 299792(top)
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 #Multipath Preference: 255
Next hop type: List, Next hop index: 1048609
Address: 0x92f058c
Next-hop reference count: 4
Next hop: ELNH Address 0x92c48ac weight 0x1, selected
equal-external-internal-type external
Next hop type: Router, Next hop index: 1603
Address: 0x92c48ac
Next-hop reference count: 2
Next hop: 10.1.0.13 via ge-2/0/0.0
Label operation: Push 408592
Label TTL action: prop-ttl
Next hop: ELNH Address 0x92c548c weight 0x4000
equal-external-internal-type internal
Next hop type: Indirect
Address: 0x92c548c
Next-hop reference count: 3
Protocol next hop: 192.0.2.12
Push 299856
Indirect next hop: 0x9380f40 1048608 INH Session ID: 0x10001a
Next hop type: Router, Next hop index: 1586
Address: 0x92c5440
Next-hop reference count: 3
Next hop: 10.1.0.18 via ge-2/0/1.0
Label operation: Push 299856, Push 299792(top)
Label TTL action: prop-ttl, prop-ttl(top)
State: <ForwardingOnly Int Ext>
Inactive reason: Forwarding use only
Age: 3:38 Metric: 20
Validation State: unverified
Task: RT
Announcement bits (1): 0-KRT
AS path: 200 I
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.
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 blocklisted 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 primary 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.
See also
Example: Configuring Link Protection with Host Fast Reroute
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.
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:
- Configure the interfaces.[edit interfaces]user@PE1# set ge-4/1/0 unit 0 family inet address 192.0.2.2/24user@PE1# set ge-4/1/0 unit 0 description toPE2user@PE1# set ge-0/2/0 unit 0 family inet address 10.10.10.1/30user@PE1# set ge-0/2/0 unit 0 description toP1user@PE1# set ge-0/2/0 unit 0 family mplsuser@PE1# set ge-0/2/4 unit 0 family inet address 10.10.15.2/30user@PE1# set ge-0/2/4 unit 0 description toP5user@PE1# set ge-0/2/4 unit 0 family mplsuser@PE1# set lo0 unit 0 family inet address 10.255.8.207/32
- (Optional) Configure VRRP on the interface to Device PE2.[edit interfaces ge-4/1/0 unit 0 family inet address 192.0.2.2/24]user@PE1# set vrrp-group 1 virtual-address 192.0.2.5user@PE1# set vrrp-group 1 priority 240user@PE1# set vrrp-group 1 fast-interval 100user@PE1# set vrrp-group 1 preemptuser@PE1# set vrrp-group 1 accept-data
- Configure MPLS on the interfaces.[edit protocols mpls]user@PE1# set interface ge-0/2/0.0user@PE1# set interface ge-0/2/4.0
- Configure BGP.[edit protocols bgp group pe-ce]user@PE1# set type internaluser@PE1# set local-address 10.255.8.207user@PE1# set family inet-vpn unicastuser@PE1# set neighbor 10.255.8.86user@PE1# set export send-routes
- Configure a policy that advertises direct and local interface
routes.[edit policy-options policy-statement send-routes term 1]user@PE1# set from protocol directuser@PE1# set from protocol localuser@PE1# set then accept
- Configure an interior gateway protocol, such as IS-IS
or OSPF.[edit protocols ospf area 0.0.0.0]user@PE1# set interface ge-0/2/0.0user@PE1# set interface ge-0/2/4.0user@PE1# set interface lo0.0 passive
- Configure a signaling protocol, such as RSVP or LDP.[edit protocols ldp]user@PE1# set interface ge-0/2/0.0user@PE1# set interface ge-0/2/4.0
- (Optional) Configure nonstop active routing.[edit routing-options]user@PE1# set nonstop-routing
- Configure the autonomous system (AS).[edit routing-options]user@PE1# set routing-options autonomous-system 100
- Configure the Layer 3 VPN routing instance.[edit routing-instances cust1]user@PE1# set instance-type vrfuser@PE1# set interface ge-4/1/0.0user@PE1# set route-distinguisher 100:100user@PE1# set vrf-target target:100:100user@PE1# set vrf-table-label
- Configure HFRR link protection.[edit routing-instances cust1 routing-options]user@PE1# set interface ge-4/1/0.0 link-protection (Host Fast Reroute)
If you are done configuring the device, commit the configuration.
[edit]user@PE1# commit
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
user@PE1> show hfrr profilesHFRR pointer: 0x9250000 HFRR Current State: HFRR_ACTIVE HFRR Protected IFL Name: ge-4/1/0.0 HFRR Protected IFL Handle: 0x921086c HFRR Routing Instance Name: cust1 HFRR Routing Instance Handle: 0x9129740 HFRR Sync BG Sceduled: NO HFRR RTS Filter On: YES HFRR Delete BG Scheduled: NO HFRR Num ARP Routes learnt: 100 HFRR Num FRR Routes Created: 100
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 arpinet.0: 43 destinations, 43 routes (42 active, 0 holddown, 1 hidden)
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
cust1.inet.0: 1033 destinations, 2043 routes (1033 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.3/24 @[ARP/4294967293] 00:04:35, from 192.0.2.1
Unusable
192.0.2.4/24 @[ARP/4294967293] 00:04:35, from 192.0.2.1
Unusable
192.0.2.5/24 @[ARP/4294967293] 00:04:32, from 192.0.2.1
Unusable
192.0.2.6/24 @[ARP/4294967293] 00:04:34, from 192.0.2.1
Unusable
192.0.2.7/24 @[ARP/4294967293] 00:04:35, from 192.0.2.1
Unusable
192.0.2.8/24 @[ARP/4294967293] 00:04:35, from 192.0.2.1
Unusable
192.0.2.9/24 @[ARP/4294967293] 00:04:35, from 192.0.2.1
Unusable
192.0.2.10/24 @[ARP/4294967293] 00:04:35, from 192.0.2.1
Unusable
192.0.2.11/24 @[ARP/4294967293] 00:04:33, from 192.0.2.1
Unusable
192.0.2.12/24 @[ARP/4294967293] 00:04:33, from 192.0.2.1
Unusable
192.0.2.13/24 @[ARP/4294967293] 00:04:33, from 192.0.2.1
Unusable
...Verifying Fast Reroute Routes
Purpose
Make sure that the expected fast reroute (FRR) routes are learned.
Action
user@PE1> show route protocol frrinet.0: 43 destinations, 43 routes (42 active, 0 holddown, 1 hidden)
inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
cust1.inet.0: 1033 destinations, 2043 routes (1033 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.0.2.3/24 #[FRR/200] 00:05:38, from 192.0.2.1
> to 192.0.2.3 via ge-4/1/0.0
to 10.10.15.1 via ge-0/2/4.0, Push 16, Push 299792(top)
192.0.2.4/24 #[FRR/200] 00:05:38, from 192.0.2.1
> to 192.0.2.4 via ge-4/1/0.0
to 10.10.15.1 via ge-0/2/4.0, Push 16, Push 299792(top)
192.0.2.5/24 #[FRR/200] 00:05:35, from 192.0.2.1
> to 192.0.2.5 via ge-4/1/0.0
to 10.10.15.1 via ge-0/2/4.0, Push 16, Push 299792(top)
192.0.2.6/24 #[FRR/200] 00:05:37, from 192.0.2.1
> to 192.0.2.6 via ge-4/1/0.0
to 10.10.15.1 via ge-0/2/4.0, Push 16, Push 299792(top)
192.0.2.7/24 #[FRR/200] 00:05:38, from 192.0.2.1
> to 192.0.2.7 via ge-4/1/0.0
to 10.10.15.1 via ge-0/2/4.0, Push 16, Push 299792(top)
192.0.2.8/24 #[FRR/200] 00:05:38, from 192.0.2.1
> to 192.0.2.8 via ge-4/1/0.0
to 10.10.15.1 via ge-0/2/4.0, Push 16, Push 299792(top)
192.0.2.9/24 #[FRR/200] 00:05:38, from 192.0.2.1
> to 192.0.2.9 via ge-4/1/0.0
to 10.10.15.1 via ge-0/2/4.0, Push 16, Push 299792(top)
192.0.2.10/24 #[FRR/200] 00:05:38, from 192.0.2.1
...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.3Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 36 1
Routing table: default-switch.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 554 1
Routing table: __master.anon__.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 532 1
Routing table: cust1.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
192.0.2.3/24 user 0 ulst 1048575 2
0:0:14:14:1:3 ucst 767 3 ge-4/1/0.0
indr 1048574 1001
10.10.15.1 Push 16, Push 299792(top) 1262 2 ge-0/2/4.0
192.0.2.3/24 dest 0 0:0:14:14:1:3 ucst 767 3 ge-4/1/0.0
...