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
router Base
policy-options
begin
prefix-list "192.0.1.0/24"
prefix 192.0.1.0/24 prefix-length-range 32-32
exit
community "target:64500:1"
members "target:64500:1"
exit
community "target:64500:2"
members "target:64500:2"
exit
policy-statement "export-bgp"
entry 10
from
prefix-list "192.0.1.0/24"
exit
action accept
exit
exit
exit
policy-statement "export-VPLS2"
entry 10
action accept
community add "target:64500:2"
exit
exit
exit
policy-statement "export-VPRN1"
entry 10
action accept
community add "target:64500:1"
next-hop 192.0.1.11
exit
exit
exit
policy-statement "import-VPLS2"
entry 10
from
community "target:64500:2"
family l2-vpn
exit
action accept
exit
exit
default-action drop
exit
exit
policy-statement "import-VPRN1"
entry 10
from
protocol bgp-vpn
community "target:64500:1"
exit
action accept
exit
exit
default-action drop
exit
exit
commit
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
bgp
split-horizon
next-hop-resolution
labeled-routes
transport-tunnel
family label-ipv4
resolution-filter
no ldp
sr-isis
exit
resolution filter
exit
exit
exit
exit
group "iBGPv4"
family vpn-ipv4 label-ipv4
peer-as 64500
neighbor 192.0.2.2
export "export-bgp"
exit
exit
group "iBGP-L2"
family l2-vpn
type internal
local-address 192.0.1.11
neighbor 192.0.1.21
exit
exit
The service configuration on PE-1 is as follows:
# on PE-1:
configure
service
pw-template 1 name "PW1" create
exit
vprn 1 name "VPRN 1" customer 1 create
vrf-import "import-VPRN1"
vrf-export "export-VPRN1"
route-distinguisher 64500:1
auto-bind-tunnel
resolution-filter
bgp # default
exit
resolution filter
exit
vrf-target target:64500:1
interface "lo1" create
address 172.31.1.1/32
loopback
exit
bgp
next-hop-resolution
use-bgp-routes
exit
exit
no shutdown
exit
vpls 2 name "BGP-VPLS 2" customer 1 create
bgp
route-distinguisher 64500:2
vsi-export "export-VPLS2"
vsi-import "import-VPLS2"
route-target export target:64500:2 import target:64500:2
pw-template-binding 1 import-rt "target:64500:2"
exit
exit
bgp-vpls
max-ve-id 100
ve-name "PE-1"
ve-id 1
exit
no shutdown
exit
sap 1/2/1:2 create
exit
no shutdown
exit
vpls 3 name "BGP-AD VPLS 3" customer 1 create
bgp
route-distinguisher 64500:3
route-target export target:64500:3 import target:64500:3
pw-template-binding 1
exit
exit
bgp-ad
vpls-id 64500:3
vsi-id
prefix 192.0.1.11
exit
no shutdown
exit
sap 1/2/1:3 create
exit
no shutdown
exit
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: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: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: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: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
router Base
policy-options
begin
policy-statement "import-VPRN1"
entry 10
from
protocol bgp-vpn
community "target:64500:1"
exit
action accept
local-preference 200
exit
exit
default-action drop
exit
exit
commit
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
Change the import policy back to the original configuration, as follows:
# on PE-1:
configure
router Base
policy-options
begin
policy-statement "import-VPRN1"
entry 10
from
protocol bgp-vpn
community "target:64500:1"
exit
action accept
no local-preference
exit
exit
exit
commit
The mp-bgp-keep 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: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: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: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: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:PE-1# clear router bgp neighbor 192.0.2.2 soft-route-refresh # BGP-LU, BGP-VPN
*A: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.