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