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.
BGP neighbor is <IP>, remote AS <AS>, internal link[...]Neighbor capabilities:[...]Graceful Restart Capability: advertised and receivedRemote Restart timer is 120 secondsAddress 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.
BGP neighbor is <IP>, remote AS <AS>, internal link[...]Neighbor capabilities:[...]Graceful Restart Capability: advertised and receivedRemote Restart timer is 120 secondsAddress 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.