BGP Graceful Restart

Mel Beckman mel at beckman.org
Fri Apr 16 16:24:27 UTC 2021


I use it BGP Graceful Restart in order to avoid route flapping penalties and undesired path selection when adding or removing prefixes on border routers (which entails ACL changes as well). However, when BGP is used as a data center fabric, I have heard it can cause complex failure modes lasting many minutes or even hours. I found this VMWare Validated Design Document 5.0.1 warning:

NSXT-VISDN-038 Do not enable Graceful Restart between BGP neighbors. Avoids loss of traffic. Graceful Restart maintains the forwarding table which in turn will forward packets to a down neighbor even after the BGP timers have expired causing loss of traffic

I don't run BGP as an east-west protocol, so I've never had cause to use this, but this might be one of the risks the speaker of the talk you heard was referring to.

 -mel

________________________________
From: NANOG <nanog-bounces+mel=beckman.org at nanog.org> on behalf of Graham Johnston <johnston.grahamj at gmail.com>
Sent: Friday, April 16, 2021 7:11 AM
To: nanog at nanog.org <nanog at nanog.org>
Subject: BGP Graceful Restart

I do believe that I understand the intended purpose of BGP
graceful-restart. With that said, I was watching a video of a talk
given by someone respected in the industry the other day on the use of
graceful-shutdown and at the beginning of the talk there was a quick
disclaimer that his topic had nothing to do with graceful-restart
along with some text on the slide that provided me a clear indication
that he was not a fan of graceful-restart.

Largely, I suspect that his point was that if you otherwise do the
right things during maintenance that graceful-restart has the
potential of being really problematic if things go wrong, and thus he
was discouraging the use of it. Is there consensus as to whether
graceful-restart has any place in a service provider network?

Thanks,
Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210416/4e52d745/attachment.html>


More information about the NANOG mailing list