BGP Graceful Shutdown (RFC 8326): No-Outage Maintenance

Taking a router out of service normally means traffic keeps arriving until the session drops, and then a few seconds of blackhole while every neighbour reconverges. BGP graceful shutdown (RFC 8326) removes the blackhole: before you touch anything, you advertise the routes with a well-known community that tells neighbours to prefer another path, wait for traffic to drain, and only then shut down. The same mechanism leaves a useful state - your routes stay visible in the RIB, so operators and monitoring can see that the maintenance is intentional rather than a failure.

The Mechanism

• The router advertises its prefixes with the GRACEFUL_SHUTDOWN well-known community (65535:0) and lowers the LOCAL_PREF it attaches to them.
• Neighbours receive the routes with the lower preference and move traffic to alternative paths that were previously less preferred.
• You confirm traffic has left the router interfaces, then perform the maintenance.
• When maintenance ends, you stop the advertisement, LOCAL_PREF returns to normal, and traffic comes back - ideally with a hold-down period so the return is not a thundering herd.

Junos Configuration

# enable graceful shutdown with propagation on teardown
set routing-options graceful-shutdown receiver local-preference
set routing-options graceful-shutdown propagate-teardown
commit

# drain a neighbour, then keep routes down for 5 minutes after restart
clear bgp neighbor 10.0.0.2 graceful-shutdown

# alternative: policy-based approach
set policy-options community GS members 65535:0
set policy-options policy-statement GS-EXPORT term gs from protocol bgp
set policy-options policy-statement GS-EXPORT term gs then community add GS
set policy-options policy-statement GS-EXPORT term gs then local-preference 50
set policy-options policy-statement GS-EXPORT term gs then accept
set protocols bgp group EBGP export GS-EXPORT

Cisco, NX-OS and FRR

! IOS-XE: shutdown a neighbour without an immediate session drop
router bgp 65000
 neighbor 10.0.0.2 shutdown
 ! graceful shutdown keeps the session until the hold-down expires:
clear ip bgp 10.0.0.2 shutdown

! NX-OS
router bgp 65000
 neighbor 10.0.0.2 graceful-shutdown

! FRR
router bgp 65000
 neighbor 10.0.0.2 graceful-shutdown

On the receiving side the effect is a lower LOCAL_PREF for the affected prefixes, visible in show ip bgp output before the session goes down. That visibility is what lets you prove the drain is complete rather than guessing.

Operating Procedure

• Enable graceful shutdown, then verify on two neighbours that LOCAL_PREF dropped for the affected prefixes.
• Watch interface counters and, if available, flow exports until traffic on the relevant interfaces is at baseline.
• Perform the change or reload.
• Return: clear the graceful-shutdown state and confirm LOCAL_PREF is back. Use the hold-down timer if your platform supports it - restoring hundreds of prefixes at once creates a burst of updates.
• Record the drain time in the change ticket; it is the number that matters for future windows.

show ip bgp 10.20.0.0/16 | include Local
show bgp l2vpn evpn summary          ! NX-OS
show bgp neighbor 10.0.0.2 | match Local
monitor traffic interface et-0/0/0 no-resolve | match 179

Things That Still Hurt

• Single-homed peers: graceful shutdown cannot create a path that does not exist. Slamming a single-homed link still causes an outage; schedule with the customer.
• Traffic already in flight during the drain is still processed - measure, do not assume.
• TCP sessions terminating on the router (management, BGP itself) are unaffected; the mechanism is for forwarded traffic.
• Bringing a full-table router back without a hold-down can trigger damping or CPU spikes on older peers - see route flap damping for the interaction.

Related: BGP communities and AS-path filtering for the policy building blocks, BGP add-path when you want secondary paths visible in the RIB, and IP SLA object tracking to confirm the alternate path is alive before you drain.

原文链接：https://www.rfc-editor.org/rfc/rfc8326.html