VPN graceful restart uses
three types of restart functionality:
BGP graceful restart functionality is used on all PE-to-PE
BGP sessions. This affects sessions carrying any service signaling
data for network layer reachability information (NLRI), for example,
an IPv4 VPN or Layer 2 VPN NLRI.
OSPF, IS-IS, LDP, or RSVP graceful restart functionality
is used in all core routers. Routes added by these protocols are used
to resolve Layer 2 and Layer 3 VPN NLRI.
Protocol restart functionality is used for any Layer 3
protocol (RIP, OSPF, LDP, and so on) used between the PE and customer
edge (CE) routers. This does not apply to Layer 2 VPNs because Layer
2 protocols used between the CE and PE routers do not have graceful
restart capabilities.
Before VPN graceful restart can work properly,
all of the components must restart gracefully. In other words, the
routers must preserve their forwarding states and request neighbors
to continue forwarding to the router in case of a restart. If all
of the conditions are satisfied, VPN graceful restart imposes the
following rules on a restarting router:
The router must wait to receive all BGP NLRI information
from other PE routers before advertising routes to the CE routers.
The router must wait for all protocols in all routing
instances to converge (or complete the restart process) before it
sends CE router information to other PE routers. In other words, the
router must wait for all instance information (whether derived from
local configuration or advertisements received from a remote peer)
to be processed before it sends this information to other PE routers.
The router must preserve all forwarding state in the instance.mpls.0 tables until the new labels and transit routes
are allocated and announced to other PE routers (and CE routers in
a carrier-of-carriers scenario).
If any condition is not met, VPN graceful restart does not succeed
in providing uninterrupted forwarding between CE routers across the
VPN infrastructure.
