Using BGP graceful restart, the data-forwarding plane of a router can continue to process and forward packets even if the control plane - which is responsible for determining best paths - fails. Graceful restart also reduces routing flaps, stabilizing the network and reducing control-plane resource consumption.

By exchanging a new BGP capability (BGP capability code 64) in the initial BGP open messages that establish the session, the restarting router and its peers show that they are aware of the BGP graceful restart mechanism when the initial BGP connection is established. In addition, the restarting router provides its peers with a list of supported address-families (VPNv4, IPv4, and IPV6) for which it can maintain a forwarding state across a BGP restart.

The peer router's TCP connection might be cleared, when the router's BGP process is restarted. Under normal circumstances, this would cause the peer router to clear all routes associated with the restarting router. But with a BGP graceful restart, this doesn't happen. Instead, in expectation of the restarting router shortly re-establishing the BGP session, the peer router marks all routes as “stale” yet continues to use them to forward packets. Likewise, the restarting router also continues forwarding packets in the interim.

When the restarting router opens the new BGP session, it will again send BGP capability 64 to its peers. But this time, flags will be set in the graceful restart capabilities exchange to let the peer router know that the BGP process has restarted.

The goal of the BGP graceful restart was to minimize the duration and reach of an outage associated with a failed BGP process. To do this, the software extensions must be deployed on both the router restarting the BGP process and the BGP peers of that router. The peers help the BGP process regain lost forwarding information and also help isolate failures from the rest of the network.

While forwarding packets, the peer router will refresh the restarting router with any relevant BGP routing information base (RIB) updates. The peer signals that it has finished sending the updates with an "End-of-RIB" (EOR) marker - an “empty” BGP update message. EOR markers help speed convergence because once the restarting router has received them from all peers, it can begin best-path selection again using the new routing information. Similarly, the restarting router then sends any updates to its peer routers and uses the EOR marker to indicate the completion of the process.

As part of this feature, we will be extending the feature for VPNv4 AF.

In the below example shows to configure BGP VPNv4 neighborship between PE1 and PE2.