BGP Fast Reroute Policy Control
This chapter provides information about BGP Fast Reroute Policy Control.
Topics in this chapter include:
Applicability
This chapter was initially based on SR OS Release 15.0.R4, but the CLI in the current edition is based on SR OS Release 22.10.R2.
Overview
BGP Fast Reroute (FRR) allows for precomputing multiple redundant BGP paths in the control plane and installing backup routes in the forwarding plane via indirection techniques. See the BGP Fast Reroute chapter for more information.
The BGP FRR Policy Control feature allows for selectively applying FRR for designated BGP prefixes. This allows an operator to develop separate service and redundancy models for different customers or services. It also allows for using data path resources required for BGP FRR in a more efficient way.
The BGP FRR policy control feature includes the install-backup-path policy action command. This command is supported in the following configuration contexts:
[/]
A:admin@PE-3# tree flat detail | match install-backup-path
configure groups group <string> policy-options policy-statement <string> default-action install-backup-path <boolean>
configure groups group <string> policy-options policy-statement <string> entry <string | number> action install-backup-path <boolean>
configure groups group <string> policy-options policy-statement <string> named-entry <string> action install-backup-path <boolean>
configure policy-options policy-statement <string> default-action install-backup-path <boolean>
configure policy-options policy-statement <string> entry <number> action install-backup-path <boolean>
configure policy-options policy-statement <string> named-entry <string> action install-backup-path <boolean>The install-backup-path command is effective when configured in BGP-import or VRF-import policies. In cases where this command is configured in an import policy applied in the global bgp context, the command applies to the following types of routes:
IPv4
IPv6
Label-IPv4
6PE
VPN-IPv4 (only if vpn-apply-import is configured in BGP)
VPN-IPv6 (only if vpn-apply-import is configured in BGP)
Community addition on PE-1 and PE-2 shows an example of community addition. Two prefixes, 10.1.0.0/16 and 10.2.0.0/16, are advertised by CE-4 to both of its peers, PE-1 and PE-2. The administrator of AS 64496 wants to apply FRR only for the 10.2.0.0/16 prefix that will eventually be advertised to and used on PE-3, and not for 10.1.0.0/16. To facilitate this procedure, an import policy is applied on both PE-1 and PE-2 for routes advertised by CE-4 in AS 64500. The import policy selects and adds a community value of "1:1" to the 10.2.0.0/16 prefix. No community is applied to 10.1.0.0/16.
FRR policy on PE-3 shows the FRR import policy applied on PE-3 for the routes received from PE-1 and PE-2. The policy matches routes with a community value of "1:1" and instructs the router to calculate and install a backup path for those matching routes.
Configuration
The following configuration examples are in this section:
BGP FRR for address family IPv4 without FRR policy
BGP FRR for address family IPv4 with FRR policy
BGP with FRR policy for address family VPN-IPv4 using global BGP policy and vpn-apply-import
BGP with FRR policy for address family VPN-IPv4 using VRF-import policy
BGP FRR policy control feature for address family IPv4
Figure 3 shows the example topology used for the BGP FRR Policy Control feature for the IPv4 address family. The topology is similar to the one in the BGP Add-Path chapter, with the following characteristics:
CE-4 in AS 64500 advertises both prefixes 10.1.0.0/16 and 10.2.0.0/16 to its eBGP peers PE-1 and PE-2 in AS 64496.
RR-5 is route reflector for all PEs in AS 64496.
Add-path is configured on all PE routers and RR-5 with a sending limit of 2.
CE-6 in AS 64501 peers with PE-3 in AS 64496 and can send traffic to CE-4 in 64500.
Initial configuration
The initial configuration on all nodes includes:
Cards, MDAs, ports
Router interfaces
IS-IS as IGP on all interfaces within AS 64496 (alternatively, OSPF can be used)
LDP on all interfaces between the PEs in AS 64496, but not toward RR-5. LDP is used to create the transport tunnels that are bound to the VPRN services in the VPN-IPv4 address family section.
BGP is configured on all the nodes. CE-4 peers with PE-1 and PE-2 and exports prefixes 10.1.0.0/16 and 10.2.0.0/16 to both eBGP peers, as follows:
# on CE-4:
configure {
policy-options {
prefix-list "10.1.0.0/16" {
prefix 10.1.0.0/16 type longer {
}
}
prefix-list "10.2.0.0/16" {
prefix 10.2.0.0/16 type longer {
}
}
policy-statement "export-bgp" {
entry 10 {
from {
prefix-list ["10.1.0.0/16"]
}
action {
action-type accept
}
}
entry 20 {
from {
prefix-list ["10.2.0.0/16"]
}
action {
action-type accept
}
}
}
}
router "Base" {
autonomous-system 64500
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP" {
export {
policy ["export-bgp"]
}
peer-as 64496
}
neighbor "172.16.14.1" {
group "eBGP"
}
neighbor "172.16.24.1" {
group "eBGP"
}
}
}CE-4 also has configured the following loopback interfaces:
# on CE-4:
configure {
router "Base" {
interface "int-loopback-1" {
ipv4 {
primary {
address 10.1.1.1
prefix-length 16
}
}
loopback
}
interface "int-loopback-2" {
ipv4 {
primary {
address 10.2.1.1
prefix-length 16
}
}
loopback
}The BGP configuration on CE-6 is similar, except for the export policy.
PE-1 peers with CE-4 in AS 65400 and RR-5 in AS 64496. The BGP configuration on PE-1 is as follows:
# on PE-1:
configure {
router "Base" {
autonomous-system 64496
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP" {
peer-as 64500
}
neighbor "172.16.14.2" {
group "eBGP"
}
group "iBGP" {
next-hop-self true
peer-as 64496
add-paths {
ipv4 {
send 2
receive true
}
}
}
neighbor "192.0.2.5" {
group "iBGP"
}The BGP configuration on PE-2 and PE-3 is similar to PE-1.
RR-5 acts as a route reflector to all the PEs in AS 64500 with a cluster ID of 5.5.5.5. The BGP configuration on RR-5 is as follows:
# on RR-5:
configure {
router "Base" {
autonomous-system 64496
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "iBGP" {
cluster {
cluster-id 5.5.5.5
}
peer-as 64496
add-paths {
ipv4 {
send 2
receive true
}
}
}
neighbor "192.0.2.1" {
group "iBGP"
}
neighbor "192.0.2.2" {
group "iBGP"
}
neighbor "192.0.2.3" {
group "iBGP"
}BGP FRR for address family IPv4 without FRR policy
PE-3 receives both prefixes from PE-1 and PE-2 via RR-5, but only uses the one from PE-1 (Nexthop: 192.0.2.1).
[/]
A:admin@PE-3# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 10.1.0.0/16 100 None
192.0.2.1 10 10
64500 -
*i 10.1.0.0/16 100 None
192.0.2.2 3 10
64500 -
u*>i 10.2.0.0/16 100 None
192.0.2.1 11 10
64500 -
*i 10.2.0.0/16 100 None
192.0.2.2 4 10
64500 -
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
The following configuration is applied on PE-3 to enable BGP FRR:
# on PE-3:
configure {
router "Base" {
bgp {
backup-path ipv4
PE-3 calculates and marks BGP routes from PE-2 as backup routes in the BGP routing table:
[/]
A:admin@PE-3# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 10.1.0.0/16 100 None
192.0.2.1 10 10
64500 -
ub*i 10.1.0.0/16 100 None
192.0.2.2 3 10
64500 -
u*>i 10.2.0.0/16 100 None
192.0.2.1 11 10
64500 -
ub*i 10.2.0.0/16 100 None
192.0.2.2 4 10
64500 -
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
PE-3 installs BGP routes from PE-2 as backup routes in its route table:
[/]
A:admin@PE-3# show router route-table 10.0.0.0/8 longer alternative
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
Alt-NextHop Alt-
Metric
-------------------------------------------------------------------------------
10.1.0.0/16 Remote BGP 00h02m47s 170
192.168.13.1 10
10.1.0.0/16 (Backup) Remote BGP 00h02m47s 170
192.168.23.1 10
10.2.0.0/16 Remote BGP 00h02m47s 170
192.168.13.1 10
10.2.0.0/16 (Backup) Remote BGP 00h02m47s 170
192.168.23.1 10
-------------------------------------------------------------------------------
No. of Routes: 4
Flags: n = Number of times nexthop is repeated
Backup = BGP backup route
LFA = Loop-Free Alternate nexthop
S = Sticky ECMP requested
===============================================================================
BGP FRR for address family IPv4 with FRR policy
The global BGP FRR activation command enabled on PE-3 in the previous step is removed from the configuration:
# on PE-3:
configure {
router "Base" {
bgp {
backup-path delete ipv4
The following command output on PE-3 shows no community values attached to the prefix 10.2.0.0/16 advertised by PE-1 and PE-2:
[/]
A:admin@PE-3# show router bgp routes 10.2.0.0/16 detail | match '^Nexthop|Community'
Nexthop : 192.0.2.1
Community : No Community Members
Nexthop : 192.0.2.1
Community : No Community Members
Nexthop : 192.0.2.2
Community : No Community Members
Nexthop : 192.0.2.2
Community : No Community Members
The following policy is configured on PE-1 and PE-2 to add the BGP community "1:1" to the prefix 10.2.0.0/16 advertised by CE-4:
# on PE-1 and PE-2:
configure {
policy-options {
community "1:1" {
member "1:1" { }
}
prefix-list "10.2.0.0/16" {
prefix 10.2.0.0/16 type longer {
}
}
policy-statement "add-bgp-community" {
entry 10 {
from {
prefix-list ["10.2.0.0/16"]
}
action {
action-type accept
community {
add ["1:1"]
}
}
}
}The policy is applied as a BGP-import policy on PE-1 and PE-2 for the eBGP group:
# on PE-1, PE-2:
configure {
router "Base" {
bgp {
group "eBGP" {
import {
policy ["add-bgp-community"]PE-3 now shows the community value associated with prefix 10.2.0.0/16 as applied and advertised by PE-1 and PE-2:
[/]
A:admin@PE-3# show router bgp routes 10.2.0.0/16 detail | match '^Nexthop|Community'
Nexthop : 192.0.2.1
Community : 1:1
Nexthop : 192.0.2.1
Community : 1:1
Nexthop : 192.0.2.2
Community : 1:1
Nexthop : 192.0.2.2
Community : 1:1
The following policy is configured on PE-3 to selectively install a backup path only for prefixes with a community value equal to "1:1":
# on PE-3:
configure {
policy-options {
community "1:1" {
member "1:1" { }
}
policy-statement "policy-bgp-frr-import" {
entry 10 {
from {
community {
name "1:1"
}
}
action {
action-type accept
install-backup-path true
}
}
}The policy is applied on PE-3 to selectively install a backup path only for prefixes with a community value equal to "1:1":
# on PE-3:
configure {
router "Base" {
bgp {
group "iBGP" {
import {
policy ["policy-bgp-frr-import"]The following command output shows PE-3 has calculated a BGP FRR path only for prefix 10.2.0.0/16 indicated by the "b" (backup) flag:
[/]
A:admin@PE-3# show router bgp routes
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 10.1.0.0/16 100 None
192.0.2.1 10 10
64500 -
*i 10.1.0.0/16 100 None
192.0.2.2 3 10
64500 -
u*>i 10.2.0.0/16 100 None
192.0.2.1 11 10
64500 -
ub*i 10.2.0.0/16 100 None
192.0.2.2 4 10
64500 -
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
The following command output shows PE-3 has installed a backup route only for prefix 10.2.0.0/16 in its route table:
[/]
A:admin@PE-3# show router route-table 10.0.0.0/8 longer alternative
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
Alt-NextHop Alt-
Metric
-------------------------------------------------------------------------------
10.1.0.0/16 Remote BGP 00h09m48s 170
192.168.13.1 10
10.2.0.0/16 Remote BGP 00h01m12s 170
192.168.13.1 10
10.2.0.0/16 (Backup) Remote BGP 00h01m12s 170
192.168.23.1 10
-------------------------------------------------------------------------------
No. of Routes: 3
Flags: n = Number of times nexthop is repeated
Backup = BGP backup route
LFA = Loop-Free Alternate nexthop
S = Sticky ECMP requested
===============================================================================
BGP with FRR policy for address family VPN-IPv4 using global BGP policy
Example topology - VPN-IPv4 shows the example topology used to illustrate the BGP FRR policy control feature for the VPN-IPv4 route family. CE-4 exports both prefixes 172.31.1.0/24 and 172.31.2.0/24 to VPRN 1 on PE-1 and PE-2.
VPRN 1 is configured on all PEs in AS 64496. The configuration of VPRN 1 is similar on all PEs; for example, for PE-1, the VPRN configuration is as follows:
# on PE-1:
configure {
service {
vprn "VPRN 1" {
customer "1"
service-id 1
autonomous-system 64496
interface "int-PE-1-CE-4-VPRN1" {
ipv4 {
primary {
address 172.16.114.1
prefix-length 30
}
}
sap 1/1/c1/2:1 {
}
}
bgp {
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP-1" {
peer-as 64500
}
neighbor "172.16.114.2" {
group "eBGP-1"
}
}
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "64496:1"
vrf-target {
community "target:64496:1"
}
auto-bind-tunnel {
resolution any
}
}
}
admin-state enable
On the CEs, the configuration is either in the base routing instance, with additional router interfaces and BGP neighbors, or in a VPRN. In this example, the following VPRN is configured on CE-4:
# on CE-4:
service {
vprn "VPRN 1" {
customer "1"
service-id 1
autonomous-system 64500
interface "int-CE-4-PE-1-VPRN1" {
ipv4 {
primary {
address 172.16.114.2
prefix-length 30
}
}
sap 1/1/c1/1:1 {
}
}
interface "int-CE-4-PE-2-VPRN1" {
ipv4 {
primary {
address 172.16.124.2
prefix-length 30
}
}
sap 1/1/c1/2:1 {
}
}
interface "loopback1-VPRN1" {
ipv4 {
primary {
address 172.31.1.1
prefix-length 24
}
}
loopback true
}
interface "loopback2-VPRN1" {
ipv4 {
primary {
address 172.31.2.1
prefix-length 24
}
}
loopback true
}
bgp {
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP-1" {
export {
policy ["export-VPRN1"]
}
peer-as 64496
}
neighbor "172.16.114.1" {
group "eBGP-1"
}
neighbor "172.16.124.1" {
group "eBGP-1"
}
}
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "64500:1"
}
}
admin-state enable
The export policy to export prefixes 172.31.1.0/24 and 172.31.2.0/24 is defined as follows:
# on CE-4:
configure {
policy-options {
prefix-list "172.31.0.0/16" {
prefix 172.31.0.0/16 type longer {
}
}
policy-statement "export-VPRN1" {
entry 10 {
from {
prefix-list ["172.31.0.0/16"]
}
action {
action-type accept
}
}
}The VPRN configuration on CE-6 is similar, but no prefix is exported from CE-6.
For all BGP speakers in AS 64496, BGP must be configured for address family VPN-IPv4 as well as for IPv4, as follows:
# on PE-1, PE-2, PE-3, RR-5:
configure {
router "Base" {
bgp {
group "iBGP" {
family {
ipv4 true
vpn-ipv4 true
}BGP add-path cannot be enabled in the bgp context within a VPRN. However, it can be enabled in the base routing instance for address family VPN-IPv4. This is done on all PEs and RR-5 at group level with the following command:
# on PE-1, PE-2, PE-3, RR-5:
configure {
router "Base" {
bgp {
group "iBGP" {
add-paths {
vpn-ipv4 {
send 2
receive true
}The BGP configuration on PE-1 is as follows:
# on PE-1:
configure {
router "Base" {
bgp {
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
group "eBGP" {
peer-as 64500
import {
policy ["add-bgp-community"]
}
}
group "iBGP" {
next-hop-self true
peer-as 64496
family {
ipv4 true
vpn-ipv4 true
}
add-paths {
ipv4 {
send 2
receive true
}
vpn-ipv4 {
send 2
receive true
}
}
}
neighbor "172.16.14.2" {
group "eBGP"
}
neighbor "192.0.2.5" {
group "iBGP"
}With add-path enabled for address family VPN-IPv4, PE-1 and PE-2 will advertise their routes for prefixes 172.31.1.0/24 and 172.31.2.0/24 as VPN-IPv4 routes to RR-5. RR-5 will advertise both routes to its other RR clients. PE-3 receives two VPN-IPv4 routes for each of the prefixes 172.31.1.0/24 and 172.31.2.0/24, as follows:
[/]
A:admin@PE-3# show router bgp routes 172.31.0.0/16 vpn-ipv4 longer
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.1 21 10
64500 524283
*>i 64496:1:172.31.1.0/24 100 None
192.0.2.2 9 10
64500 524283
u*>i 64496:1:172.31.2.0/24 100 None
192.0.2.1 20 10
64500 524283
*>i 64496:1:172.31.2.0/24 100 None
192.0.2.2 10 10
64500 524283
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
The following policy is configured on PE-1 and PE-2 to include the community value "1:1" to prefix 172.31.2.0/24, as well as to the VPRN route target 64496:1 within entry 10. All the other routes are tagged with only the VPRN route target 64496:1 in entry 20.
# on PE-1 and PE-2:
configure {
policy-options {
community "1:1" {
member "1:1" { }
}
community "target:64496:1" {
member "target:64496:1" { }
}
prefix-list "172.31.2.0/24" {
prefix 172.31.2.0/24 type longer {
}
}
policy-statement "policy-export-VPRN1" {
entry 10 {
from {
prefix-list ["172.31.2.0/24"]
}
action {
action-type accept
community {
add ["1:1" "target:64496:1"]
}
}
}
entry 20 {
from {
}
action {
action-type accept
community {
add ["target:64496:1"]
}
}
}
}The policy is applied as a VRF-export policy in VPRN 1 on PE-1 and PE-2:
# on PE-1, PE-2:
configure {
service {
vprn "VPRN 1" {
bgp-ipvpn {
mpls {
admin-state enable
vrf-export {
policy ["policy-export-VPRN1"]On PE-3, prefix 172.31.1.0/24 is received with the community value of the VPRN route target only:
[/]
A:admin@PE-3# show router bgp routes 172.31.1.0/24 vpn-ipv4 hunt | match "Community"
Community : target:64496:1
Community : target:64496:1
However, prefix 172.31.2.0/24 is received with both community values "1:1" and "target:64496:1" from PE-1 and PE-2:
[/]
A:admin@PE-3# show router bgp routes 172.31.2.0/24 vpn-ipv4 hunt | match "Community"
Community : 1:1 target:64496:1
Community : 1:1 target:64496:1
The following command is applied on PE-3 to make the policy named "policy-bgp-frr-import", configured in the previous section for IPv4 routes, effective also on VPN-IPv4 routes:
# on PE-3:
configure {
router "Base" {
bgp {
vpn-apply-import truePE-3 now has a BGP backup path only for prefix 172.31.2.0/24, as indicated by the "b" (backup) flag:
[/]
A:admin@PE-3# show router bgp routes 172.31.0.0/16 vpn-ipv4 longer
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP VPN-IPv4 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 64496:1:172.31.1.0/24 100 None
192.0.2.1 21 10
64500 524283
*>i 64496:1:172.31.1.0/24 100 None
192.0.2.2 9 10
64500 524283
u*>i 64496:1:172.31.2.0/24 100 None
192.0.2.1 20 10
64500 524283
ub*>i 64496:1:172.31.2.0/24 100 None
192.0.2.2 10 10
64500 524283
-------------------------------------------------------------------------------
Routes : 4
===============================================================================
PE-3 has installed a backup route only for prefix 172.31.2.0/24 in its VPRN route table:
[/]
A:admin@PE-3# show router 1 route-table 172.31.0.0/16 longer alternative
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
Alt-NextHop Alt-
Metric
-------------------------------------------------------------------------------
172.31.1.0/24 Remote BGP VPN 00h01m47s 170
192.0.2.1 (tunneled) 10
172.31.2.0/24 Remote BGP VPN 00h01m47s 170
192.0.2.1 (tunneled) 10
172.31.2.0/24 (Backup) Remote BGP VPN 00h01m47s 170
192.0.2.2 (tunneled) 10
-------------------------------------------------------------------------------
No. of Routes: 3
Flags: n = Number of times nexthop is repeated
Backup = BGP backup route
LFA = Loop-Free Alternate nexthop
S = Sticky ECMP requested
===============================================================================
BGP with FRR policy for address family VPN-IPv4 using VRF-import policy
The vpn-apply-import command enabled in the previous section is removed from the BGP configuration on PE-3:
# on PE-3:
configure {
router "Base" {
bgp {
delete vpn-apply-import
PE-3 removes the backup path for prefix 172.31.2.0/24:
[/]
A:admin@PE-3# show router 1 route-table 172.31.0.0/16 longer alternative
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
Alt-NextHop Alt-
Metric
-------------------------------------------------------------------------------
172.31.1.0/24 Remote BGP VPN 00h01m36s 170
192.0.2.1 (tunneled) 10
172.31.2.0/24 Remote BGP VPN 00h01m36s 170
192.0.2.1 (tunneled) 10
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
Backup = BGP backup route
LFA = Loop-Free Alternate nexthop
S = Sticky ECMP requested
===============================================================================
The following policy is configured to selectively apply FRR for prefixes with a matching community value equal to "1:1" and "target:64496:1" on PE-3:
# on PE-3:
configure {
policy-options {
community "1:1" {
member "1:1" { }
}
community "target:64496:1" {
member "target:64496:1" { }
}
policy-statement "policy-import-VPRN1" {
entry 10 {
from {
community {
expression "[target:64496:1] AND [1:1]"
}
}
action {
action-type accept
install-backup-path true
}
}
default-action {
action-type accept
}
}The policy is applied as a VRF-import policy in VPRN 1 on PE-3:
# on PE-3:
configure {
service {
vprn "VPRN 1" {
bgp-ipvpn {
mpls {
admin-state enable
vrf-import {
policy ["policy-import-VPRN1"]PE-3 again installs a backup path only for prefix 172.31.2.0/24 and not for 172.31.1.0/24:
[/]
A:admin@PE-3# show router 1 route-table 172.31.0.0/16 longer alternative
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
Alt-NextHop Alt-
Metric
-------------------------------------------------------------------------------
172.31.1.0/24 Remote BGP VPN 00h01m42s 170
192.0.2.1 (tunneled) 10
172.31.2.0/24 Remote BGP VPN 00h01m42s 170
192.0.2.1 (tunneled) 10
172.31.2.0/24 (Backup) Remote BGP VPN 00h01m42s 170
192.0.2.2 (tunneled) 10
-------------------------------------------------------------------------------
No. of Routes: 3
Flags: n = Number of times nexthop is repeated
Backup = BGP backup route
LFA = Loop-Free Alternate nexthop
S = Sticky ECMP requested
===============================================================================
Conclusion
The BGP FRR policy control feature allows for selectively applying FRR for designated prefixes. The feature brings more flexibility and granularity to the BGP FRR implementation.