BGP Route Refresh
This chapter describes BGP Route Refresh.
Topics in this chapter include:
Applicability
The information and configuration in this chapter are based on SR OS Release 20.5.R2. The option to manually trigger BGP ROUTE_REFRESH messages to a BGP peer is supported in SR OS Release 19.7.R1, and later.
In SR OS releases earlier than 19.7.R1, only the automatic route refresh mechanism for VPN routes that carry Route Target extended communities, such as VPN-IPv4, VPN-IPv6, L2-VPN, MVPN-IPv4, or MVPN-IPv6 routes, is supported.
In SR OS releases earlier than 19.7.R1, soft reconfiguration inbound is supported for all non-VPN and VPN address families, using a clear command with soft-inbound option. With soft reconfiguration inbound, incoming routes are continuously retained in memory (RIB-IN), exactly as they were originally received from a BGP peer. Therefore, when an import policy change happens, the reevaluation of these routes can happen locally. There is no need to involve the peer node, because no route-refresh is involved. The disadvantage is the extra resource consumption to retain a copy of all original routes in memory, even if they are not needed at the current time.
Overview
RFC 2918, Route Refresh Capability for BGP-4, describes the BGP ROUTE_REFRESH message type and capability for BGP-4. When BGP router PE-1 sends a route refresh message for a specific address family to its BGP peer PE-2, PE-2 re-advertises all its RIB-OUT routes for PE-1 belonging to that address family. Manually-triggered BGP route refresh can be used for any BGP address family. However, if PE-2 did not advertise the route refresh capability in the BGP OPEN message to PE-1, then PE-2 ignores the incoming ROUTE_REFRESH message from PE-1.
In this chapter, the following use cases are shown:
-
Automatic route refresh for VPN-IP and L2-VPN routes after an import policy is modified
-
Block automatic route refresh for VPN-IP routes (mp-bgp-keep option)
-
Manual route refresh for BGP routes for different address families (soft-route-refresh option in clear command)
Configuration
Example topology shows the example topology with two nodes.
The initial configuration on the nodes includes:
-
Cards, MDAs, ports
-
Router interfaces
-
SR-ISIS
The following route policies are configured on PE-1; the policies on PE-2 are similar.
# on PE-1:
configure {
policy-options {
community "target:64500:1" {
member "target:64500:1" { }
}
community "target:64500:2" {
member "target:64500:2" { }
}
prefix-list "192.0.1.0/24" {
prefix 192.0.1.0/24 type range {
start-length 32
end-length 32
}
}
policy-statement "export-VPLS2" {
entry 10 {
action {
action-type accept
community {
add ["target:64500:2"]
}
}
}
}
policy-statement "export-VPRN1" {
entry 10 {
action {
action-type accept
next-hop 192.0.1.11
community {
add ["target:64500:1"]
}
}
}
}
policy-statement "export-bgp" {
entry 10 {
from {
prefix-list ["192.0.1.0/24"]
}
action {
action-type accept
}
}
}
policy-statement "import-VPLS2" {
entry 10 {
from {
family [l2-vpn]
community {
name "target:64500:2"
}
}
action {
action-type accept
}
}
default-action {
action-type reject
}
}
policy-statement "import-VPRN1" {
entry 10 {
from {
community {
name "target:64500:1"
}
protocol {
name [bgp-vpn]
}
}
action {
action-type accept
}
}
default-action {
action-type reject
}
}
Two BGP groups are configured: one for the VPN-IPv4 and Label-IPv4 address families and another for the L2-VPN address family. The BGP configuration for the base router on PE-1 is as follows:
# on PE-1:
configure {
router "Base" {
autonomous-system 64500
bgp {
split-horizon true
next-hop-resolution {
labeled-routes {
transport-tunnel {
family label-ipv4 {
resolution-filter {
ldp false
sr-isis true
}
}
}
}
}
group "iBGP-L2" {
type internal
local-address 192.0.1.11
family {
l2-vpn true
}
}
group "iBGPv4" {
peer-as 64500
family {
vpn-ipv4 true
label-ipv4 true
}
}
neighbor "192.0.1.21" {
group "iBGP-L2"
}
neighbor "192.0.2.2" {
group "iBGPv4"
export {
policy ["export-bgp"]
}
}
}
The service configuration on PE-1 is as follows:
# on PE-1:
configure {
service {
pw-template "PW1" {
pw-template-id 1
}
vpls "BGP-AD VPLS 3" {
admin-state enable
service-id 3
customer "1"
bgp 1 {
route-distinguisher "64500:3"
route-target {
export "target:64500:3"
import "target:64500:3"
}
pw-template-binding "PW1" {
}
}
bgp-ad {
admin-state enable
vpls-id "64500:3"
vsi-id-prefix 192.0.1.11
}
sap 1/2/1:3 {
}
}
vpls "BGP-VPLS 2" {
admin-state enable
service-id 2
customer "1"
bgp 1 {
route-distinguisher "64500:2"
vsi-import ["import-VPLS2"]
vsi-export ["export-VPLS2"]
route-target {
export "target:64500:2"
import "target:64500:2"
}
pw-template-binding "PW1" {
import-rt ["target:64500:2"]
}
}
bgp-vpls {
admin-state enable
maximum-ve-id 100
ve {
name "PE-1"
id 1
}
}
sap 1/2/1:2 {
}
}
vprn "VPRN 1" {
admin-state enable
service-id 1
customer "1"
route-distinguisher "64500:1"
vrf-target {
community "target:64500:1"
}
vrf-import {
policy ["import-VPRN1"]
}
vrf-export {
policy ["export-VPRN1"]
}
auto-bind-tunnel {
resolution filter
}
bgp {
next-hop-resolution {
use-bgp-routes true
}
}
interface "lo1" {
loopback true
ipv4 {
primary {
address 172.31.1.1
prefix-length 32
}
}
}
}
The following BGP OPEN message sent by PE-1 includes the route refresh capability for two BGP address families:
1 2020/06/23 09:03:58.168 UTC MINOR: DEBUG #2001 Base BGP
"BGP: OPEN
Peer 1: 192.0.2.2 - Send (Passive) BGP OPEN: Version 4
AS Num 64500: Holdtime 90: BGP_ID 192.0.2.1: Opt Length 26 (ExtOpt F)
Opt Para: Type CAPABILITY: Length = 24: Data:
Cap_Code GRACEFUL-RESTART: Length 2
Bytes: 0x0 0x78
Cap_Code MP-BGP: Length 4
Bytes: 0x0 0x1 0x0 0x80 # AFI / SAFI ; 1 / 128 ; vpn-ipv4
Cap_Code MP-BGP: Length 4
Bytes: 0x0 0x1 0x0 0x4 # AFI / SAFI ; 1 / 4 ; label-ipv4
Cap_Code ROUTE-REFRESH: Length 0
Cap_Code 4-OCTET-ASN: Length 4
Bytes: 0x0 0x0 0xfb 0xf4
"
The BGP session between PE-1 and PE-2 includes the route refresh capability, as follows. No route refresh messages have been triggered manually yet.
[]
A:admin@PE-1# show router bgp neighbor 192.0.2.2 | match RtRefresh
Input RtRefresh : 0 Output RtRefresh : 0
Local Capability : RtRefresh MPBGP 4byte ASN
Remote Capability : RtRefresh MPBGP 4byte ASN
PE-1 receives the following BGP Labeled Unicast (BGP-LU) route:
[]
A:admin@PE-1# show router bgp routes label-ipv4
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
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 Routes
===============================================================================
Flag Network LocalPref MED
Nexthop (Router) Path-Id IGP Cost
As-Path Label
-------------------------------------------------------------------------------
u*>i 192.0.1.21/32 100 None
192.0.2.2 None 10
No As-Path 524274
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
PE-1 receives the following VPN-IPv4 route for VPRN 1:
[]
A:admin@PE-1# show router bgp routes vpn-ipv4
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
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 64500:1:172.31.1.2/32 100 None
192.0.1.21 None 0
No As-Path 524286
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
PE-1 receives one L2-VPN route for BGP-VPLS 2 and one L2-VPN route for BGP-AD VPLS 3:
[]
A:admin@PE-1# show router bgp routes l2-vpn
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
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 L2VPN Routes
===============================================================================
Flag RouteType Prefix MED
RD SiteId Label
Nexthop VeId BlockSize LocalPref
As-Path BaseOffset vplsLabelBa
se
-------------------------------------------------------------------------------
u*>i VPLS - - 0
64500:2 - -
192.0.1.21 2 8 100
No As-Path 1 524278
u*>i AutoDiscovery 192.0.1.21 - 0
64500:3 - -
192.0.1.21 - - 100
No As-Path - -
-------------------------------------------------------------------------------
Routes : 2
===============================================================================
Automatic route refresh for VPN-IP and L2-VPN routes
The following import policy is modified on PE-1; the "import-VPRN1" policy action sets the local preference to a value of 200:
# on PE-1:
configure {
policy-options {
policy-statement "import-VPRN1" {
entry 10 {
from {
community {
name "target:64500:1"
}
protocol {
name [bgp-vpn]
}
}
action {
action-type accept
local-preference 200
}
}
default-action {
action-type reject
}
}
When one or more import policies are modified after the VPN-IP and L2-VPN routes have been received, the node automatically generates route refresh messages for VPN-IP and L2-VPN routes to its peers. In this case, PE-1 sends one route refresh message for VPN-IPv4 routes and one route refresh message for L2-VPN routes to its BGP peer PE-2. When debugging is enabled for BGP route refresh messages, the following debug messages are logged on PE-1:
18 2020/06/23 09:14:47.611 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: ROUTE REFRESH
Peer 1: 192.0.2.2 - Send BGP ROUTE REFRESH:
Address Family AFI_IPV4: Sub AFI SAFI_VPN
"
19 2020/06/23 09:14:47.611 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.1.21
"Peer 1: 192.0.1.21: ROUTE REFRESH
Peer 1: 192.0.1.21 - Send BGP ROUTE REFRESH:
Address Family AFI_L2VPN: Sub AFI SAFI_VPLS
"
The first route refresh message triggers VPN-IPv4 routes to be re-advertised by the peer, while the second route refresh message triggers L2-VPN routes to be re-advertised. With these BGP route refresh messages, all VPN-IPv4 and L2-VPN routes are refreshed, even for services without an import policy, such as BGP-AD VPLS 3. The first of the following routes is related to VPRN 1 (with route-target target:64500:1), the second to BGP-VPLS 2 (with route-target target:64500:2), and the third to BGP-AD VPLS 3 (with route-target target:64500:3):
20 2020/06/23 09:14:47.614 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: UPDATE
Peer 1: 192.0.2.2 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 62
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family VPN_IPV4
NextHop len 12 NextHop 192.0.1.21
172.31.1.2/32 RD 64500:1 Label 524286
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:64500:1
"
21 2020/06/23 09:14:47.614 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.1.21
"Peer 1: 192.0.1.21: UPDATE
Peer 1: 192.0.1.21 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 72
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.1.21
[VPLS/VPWS] preflen 17, veid: 2, vbo: 1, vbs: 8, label-base: 524278, RD 64500:2
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:2
l2-vpn/vrf-imp:Encap=19: Flags=none: MTU=1514: PREF=0
"
22 2020/06/23 09:14:47.614 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.1.21
"Peer 1: 192.0.1.21: UPDATE
Peer 1: 192.0.1.21 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 67
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.1.21
[AD] 192.0.1.21/32, RD 64500:3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:3
l2-vpn/vrf-imp:64500:3
"
Block automatic route refresh for VPN-IP routes
When the VPN-IP routes do not need to be re-advertised when an import policy is modified, the mp-bgp-keep option can be configured in the generic bgp context of the base router, as follows:
# on PE-1:
configure {
router "Base" {
bgp {
mp-bgp-keep true
Change the import policy back to the original configuration, as follows:
# on PE-1:
configure {
policy-options {
policy-statement "import-VPRN1" {
entry 10 {
from {
community {
name "target:64500:1"
}
protocol {
name [bgp-vpn]
}
}
action {
action-type accept
delete local-preference # do not modify LP
}
}
default-action {
action-type reject
}
}
The mp-bgp-keep true option blocks the route refresh message for the VPN-IP routes, but not for the L2-VPN routes. The following route refresh message is sent by PE-1:
35 2020/06/23 09:21:33.951 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.1.21
"Peer 1: 192.0.1.21: ROUTE REFRESH
Peer 1: 192.0.1.21 - Send BGP ROUTE REFRESH:
Address Family AFI_L2VPN: Sub AFI SAFI_VPLS
"
Therefore, PE-1 receives the following refreshed L2-VPN routes from PE-2:
36 2020/06/23 09:21:33.954 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.1.21
"Peer 1: 192.0.1.21: UPDATE
Peer 1: 192.0.1.21 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 67
Flag: 0x90 Type: 14 Len: 23 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.1.21
[AD] 192.0.1.21/32, RD 64500:3
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:3
l2-vpn/vrf-imp:64500:3
"
37 2020/06/23 09:21:33.954 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.1.21
"Peer 1: 192.0.1.21: UPDATE
Peer 1: 192.0.1.21 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 72
Flag: 0x90 Type: 14 Len: 28 Multiprotocol Reachable NLRI:
Address Family L2VPN
NextHop len 4 NextHop 192.0.1.21
[VPLS/VPWS] preflen 17, veid: 2, vbo: 1, vbs: 8, label-base: 524278, RD 64500:2
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 16 Len: 16 Extended Community:
target:64500:2
l2-vpn/vrf-imp:Encap=19: Flags=none: MTU=1514: PREF=0
"
Manually-triggered route refresh for any BGP address family
A manual route refresh can be triggered by the soft-route-refresh option using the clear operation. This command can be launched for any address family. The command will look like the following:
[]
A:admin@PE-1# clear router bgp neighbor {<ip-address>|as <as-number>|external|all}
soft-route-refresh [<family>]
<family> : ipv4|vpn-ipv4|ipv6|mcast-ipv4|vpn-ipv6|l2-vpn|mvpn-ipv4|mdt-safi|flow-ipv4|ms-pw|route-target|mcast-vpn-ipv4|mvpn-ipv6|flow-ipv6|evpn|mcast-ipv6|label-ipv4|label-ipv6|mcast-vpn-ipv6|bgp-ls|sr-policy-ipv4
For example, the following command on PE-1 clears the BGP-LU routes from PE-1:
[]
A:admin@PE-1# clear router bgp neighbor 192.0.2.2 soft-route-refresh label-ipv4
The preceding command triggers the following route refresh message for the BGP-LU routes:
38 2020/06/23 09:23:48.951 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: ROUTE REFRESH
Peer 1: 192.0.2.2 - Send BGP ROUTE REFRESH:
Address Family AFI_IPV4: Sub AFI SAFI_MPLS_LABEL
"
The following BGP-LU route is received by PE-1:
39 2020/06/23 09:23:48.954 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: UPDATE
Peer 1: 192.0.2.2 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 35
Flag: 0x90 Type: 14 Len: 17 Multiprotocol Reachable NLRI:
Address Family LBL-IPV4
NextHop len 4 NextHop 192.0.2.2
192.0.1.21/32 Label 524274
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
"
The following command on PE-1 shows that one output route refresh message is sent:
[]
A:admin@PE-1# show router bgp neighbor 192.0.2.2 | match RtRefresh
Input RtRefresh : 0 Output RtRefresh : 1
Local Capability : RtRefresh MPBGP 4byte ASN
Remote Capability : RtRefresh MPBGP 4byte ASN
A similar command on PE-2 shows that one input route refresh message has been received:
[]
A:admin@PE-2# show router bgp neighbor 192.0.2.1 | match RtRefresh
Input RtRefresh : 1 Output RtRefresh : 0
Local Capability : RtRefresh MPBGP 4byte ASN
Remote Capability : RtRefresh MPBGP 4byte ASN
When the soft-route-refresh option is executed without a specific address family, the BGP routes are refreshed for all negotiated address families with that neighbor:
[]
A:admin@PE-1# clear router bgp neighbor 192.0.2.2 soft-route-refresh
# BGP- LU, BGP-VPN
[]
A:admin@PE-1# clear router bgp neighbor 192.0.1.21 soft-route-refresh # L2-VPN
The preceding clear commands trigger the following BGP ROUTE_REFRESH messages:
42 2020/06/23 09:39:53.836 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.1.21
"Peer 1: 192.0.1.21: ROUTE REFRESH
Peer 1: 192.0.1.21 - Send BGP ROUTE REFRESH:
Address Family AFI_L2VPN: Sub AFI SAFI_VPLS
"
43 2020/06/23 09:39:53.836 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: ROUTE REFRESH
Peer 1: 192.0.2.2 - Send BGP ROUTE REFRESH:
Address Family AFI_IPV4: Sub AFI SAFI_VPN
"
44 2020/06/23 09:39:53.836 CEST MINOR: DEBUG #2001 Base Peer 1: 192.0.2.2
"Peer 1: 192.0.2.2: ROUTE REFRESH
Peer 1: 192.0.2.2 - Send BGP ROUTE REFRESH:
Address Family AFI_IPV4: Sub AFI SAFI_MPLS_LABEL
"
Conclusion
The soft-route-refresh option in the clear router bgp neighbor command keeps a BGP session up and sends one or more ROUTE_REFRESH messages to the peer, each requesting the peer to resend all RIB-OUT routes for a specific address family (or for all established address families for a BGP neighbor). This option can be used to debug and troubleshoot route advertisement issues.