Cisco IOS BGP Graceful-Restart Implementation query

Florin Vlad Olariu florinvlad.olariu at gmail.com
Thu Nov 15 18:27:47 UTC 2018


Hey there!

In our environment we generally have ASR-1000X-2s everywhere peering via
iBGP/eBGP. These routers have no redundant RPs, hence cannot keep
forwarding traffic while the router reboots or crashes. As such, this is a
clear example of a router that's only NSF-aware (or graceful-restart-aware)
but not capable.

The reason I enabled this is because, from RFC 4724:

In addition, even if the speaker does not have the ability to preserve its
forwarding state for any address family during BGP restart, it is still
recommended that the speaker advertise the Graceful Restart Capability to
its peer (as mentioned before *this is done by not including any <AFI,
SAFI> in the advertised capability*). There are two reasons for doing this.
The first is to indicate its intention of generating the End-of-RIB marker
upon the completion of its initial routing updates, as doing this would be
useful for routing convergence in general. The second is to indicate its
support for a peer which wishes to perform a graceful restart.


So what I would expect to see in the "show ip bgp neighbor <ip>" command,
regarding Graceful Restart, would be something like the following:

BGP neighbor is <IP>,  remote AS <AS>, internal link
[...]
  Neighbor capabilities:
[...]
    Graceful Restart Capability: advertised and received
      Remote Restart timer is 120 seconds
      Address families advertised by peer:
        *none*

Basically, GR is negotiated, but no address family is specified,
effectively only using the EOR marker for routing convergence improvements.
Instead, here's what the router specifies:

BGP neighbor is <IP>,  remote AS <AS>, internal link
[...]
  Neighbor capabilities:
[...]
    Graceful Restart Capability: advertised and received
      Remote Restart timer is 120 seconds
      Address families advertised by peer:
        *IPv4 Unicast (was not preserved, VPNv4 Unicast (was not preserved*

My assumption is that the 'was not preserved' in the parentesis refers to
the most recent restart of the neighbor, and it means that when the
neighbor re-established the BGP connection, the GR Capability for IPv4 and
VPNv4 AFIs did not set the "Forwarding bit" as specified by the GR-RFC:

Once the session is re-established, if the "Forwarding State" bit for a
specific address family is not set in the newly received Graceful Restart
Capability, or if a specific address family is not included in the newly
received Graceful Restart Capability, or if the Graceful Restart Capability
is not received in the re-established session at all, then the Receiving
Speaker MUST immediately remove all the stale routes from the peer that it
is retaining for that address family.

Clearly the Forwarding State bit is never going to be set by this type of
router, due to hardware limitations. Here's my concern though: What happens
when the router reboots, and the neighboring routers keep forwarding
packets to this router because the GR-capabily did specify IPv4 and VPNv4
AFI/SAFI? This would clearly cause impact as traffic would be blackholed.

I will try to simulate this and see how it behaves, I'll report back, but
any info you have it would be greatly appreciated.
-- 
Florin Vlad Olariu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181115/4e713ce6/attachment.html>


More information about the NANOG mailing list