This article describes how to implement Long-Lived BGP Graceful Restart (LLGR) capability in the case when data forwarding goes in a different direction compared to the direction of BGP session. For example, when the BGP router reflector is used in the network.
BGP Long-lived Graceful Restart (LLGR) allows a network operator to choose to maintain stale routing information from a failed BGP peer much longer than the existing BGP Graceful Restart facility. The motivations for and limitations on this are described in the internet-draft that defines LLGR . According to the internet-draft, LLGR must be explicitly configured per NLRI. It includes provisions to prevent the spread of stale information to other peers that do not understand LLGR. A customer is able to see the following:
The requirement is that L2VPN/VPLS connections on the PE router must remain stable for an excessive periods of time in the case of the router reflector failure in the network, i.e. in the case when the BGP session between PE an RR router is disrupted.
Consider the following scenario:
PE1 --------------- P --------------- PE2
|
RR
PE routers have IBGP sessions with RR and data forwarding path doesn’t go through RR router.
Though it can be applied to a number of different scenarios, there is one specific scenario that is the target of LLGR:
An implicit goal was to implement this functionality while maintaining compatibility with existing Junos features, specifically Graceful Restart (GR) and Non-Stop Routing (NSR). When LLGR is configured, GR will operate as it does now. It will also be possible to configure both LLGR and NSR, and retain full LLGR functionality.
Notification Message support for BGP Graceful Restart in Junos was done according to Notification Message support for BGP Graceful Restart draft-ietf-idr-bgp-gr-notification-01. This draft extends the behavior of ordinary GR to allow it to protect against communications interruptions and protocol errors.
PE1 configuration
group L2VPN_RR {
type internal;
local-address 192.168.1.21;
log-updown;
family l2vpn {
auto-discovery-only {
prefix-limit {
maximum 10000;
teardown 90 idle-timeout 20;
}
graceful-restart {
long-lived {
restarter {
stale-time 1000;
graceful-restart;
neighbor 192.168.1.23;
RR configuration
local-address 192.168.1.23;
cluster 0.0.0.1;
neighbor 192.168.1.21;
neighbor 192.168.1.24;
BGP state when the session with RR is established i.e. RR is functional
lab@test> show bgp summary
Groups: 1 Peers: 1 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.l2vpn.0
3 3 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.1.23 65000 65 60 0 0 27:02 Establ
bgp.l2vpn.0: 3/3/3/0
TEST_1.l2vpn.0: 1/1/1/0
TEST_2.l2vpn.0: 1/1/1/0
TEST_3.l2vpn.0: 1/1/1/0
lab@test> show bgp neighbor | match "Restart|Options|stale" | except RIB
Options: <LLGR> <-- LLGR is enabled
NLRI for restart configured on peer: l2vpn
Restart time configured on the peer: 120 <-- GR parameter
Stale routes from peer are kept for: 300 <-- GR parameter
Restart time requested by this peer: 120 <-- GR parameter
Restart flag received from the peer: Notification <-- Notification (N) flag set
NLRI that peer supports restart for: l2vpn
NLRI that restart is negotiated for: l2vpn
NLRI and times that peer supports LLGR Restarter for: l2vpn 00:16:40 <-- LLGR stale time 1000 seconds
The routes are in import accepted state.
lab@test> show route table bgp.l2vpn.0 extensive | match "Import"
Import Accepted
RR becomes unavailable i.e. RR router failure
After the BGP holdtime expires BGP session transitions into the Active state but the routes are still kept due to configuration of graceful restart.
Groups: 1 Peers: 1 Down peers: 1
192.168.1.23 65000 0 0 0 3 1:04 Active
lab@test> show bgp neighbor | match "Restart|Options|stale|Time" | except RIB
Last Error: Hold Timer Expired Error
Options: <LLGR>
Local Address: 192.168.1.21 Holdtime: 90 Preference: 170
Last flap event: HoldTime
Error: 'Hold Timer Expired Error' Sent: 1 Recv: 0
NLRI we are holding stale routes for: l2vpn
Time until stale routes are deleted or become long-lived stale: 00:00:53 <-- time until routes become long-live staled
Stale prefixes: 3
The routes are in stale import accepted state due to GR configured.
Stale Import Accepted
After the graceful restart timer expires LLGR kicks in
192.168.1.23 65000 0 0 0 3 3:46 Active
Time until long-lived stale routes deleted: l2vpn 00:15:13 <-- routes will remain in the routing table until LLGR stale timer expires
LLGR-stale prefixes: 3
lab@test> show route table bgp.l2vpn.0 extensive | match "Import|communit"
Communities: llgr-stale target:65111:231220 l2vpn-id:65111:231220
Import Accepted LongLivedStale
Communities: llgr-stale target:65111:231330 l2vpn-id:65111:231330
Communities: llgr-stale target:65111:231440 l2vpn-id:65111:231440
The routes are in Import Accepted LongLivedStale state and llgr-stale community is added to them so route manipulation is possible by using those communities.
Until LLGR stale timer expires VPLS connections will remain up.
lab@test> show vpls connections | match Up | except --
Remote-id Type St Time last up # Up trans
192.168.1.24 rmt Up Jan 2 16:15:24 2017 1
Local interface: lsi.51380234, Status: Up, Encapsulation: ETHERNET
Local interface: lsi.51380235, Status: Up, Encapsulation: ETHERNET
Local interface: lsi.51380233, Status: Up, Encapsulation: ETHERNET
2020-08-10: Article reviewed for accuracy and no modifications needed