Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Graceful Restarts for VPNs

VPN Graceful Restart

With routing protocols, any service interruption requires that an affected router recalculate adjacencies with neighboring routers, restore routing table entries, and update other protocol-specific information. An unprotected restart of the router results in forwarding delays, route flapping, wait times stemming from protocol reconvergence, and even dropped packets. Graceful restart allows a routing device undergoing a restart to inform its adjacent neighbors and peers of its condition. During a graceful restart, the restarting device and its neighbors continue forwarding packets without disrupting network performance.

For VPN graceful restart to function properly, the following items need to be configured on the PE router:

  • BGP graceful restart must be active on the PE-to-PE sessions carrying any service-signaling data in the session’s network layer reachability information (NLRI).

  • OSPF, IS-IS, LDP, and RSVP graceful restart must be active, because routes added by these protocols are used to resolve VPN NLRIs.

  • For other protocols (static, Routing Information Protocol [RIP], and so on), graceful restart functionality must also be active when these protocols are run between the PE and CE routers. Layer 2 VPNs do not rely on this, because protocols are not configured between the PE and CE routers.

In VPN graceful restart, a restarting router completes the following procedures:

  • Waits for all the BGP NLRI information from other PE routers before it starts advertising routes to its CE routers.

  • Waits for all protocols in all routing instances to converge (or finish graceful restart) before sending CE router information to the other PE routers.

  • Waits for all routing instance information (whether it is local configuration or advertisements from a remote peer router) to be processed before sending it to the other PE routers.

  • Preserves all forwarding state information in the MPLS routing tables until new labels and transit routes are allocated and then advertises them to other PE routers (and CE routers in carrier-of-carriers VPNs).

Graceful restart is supported on Layer 2 VPNs, Layer 3 VPNs, and virtual-router routing instances.

Benefit of a VPN graceful restart

The main benefit of a VPN graceful restart is that it allows a router whose VPN control plane is undergoing a restart to continue to forward traffic while recovering its state from neighboring routers. It temporarily suppresses all routing protocol updates and enables a router to pass through intermediate convergence states that are hidden from the rest of the network. Without graceful restart, a control plane restart disrupts the VPN services provided by the router.

Configuring Graceful Restart for VPNs

You can configure graceful restart to enable a router to pass through intermediate convergence states that are hidden from the rest of the network. Graceful restart allows a router whose VPN control plane is undergoing a restart (restarting router) to continue to forward traffic while recovering its state from neighboring routers (helper routers).

The restarting router requests a grace period from the neighbor or peer, which can then cooperate with the restarting router. When a restart event occurs and graceful restart is enabled, the restarting router can still forward traffic during the restart period, and convergence in the network is not disrupted. The helper routers hide the restart event from other devices not directly connected to the restarting router. In other words, the restart is not visible to the rest of the network, and the restarting router is not removed from the network topology.

Without graceful restart, a control plane restart disrupts any VPN services provided by the router. Graceful restart is supported on Layer 2 VPNs, Layer 3 VPNs, virtual-router routing instances, and VPLS.

The graceful restart request occurs only if the following conditions are met:

  • The network topology is stable.

  • The neighbor or peer routers cooperate.

  • The restarting router is not already cooperating with another restart already in progress.

  • The grace period does not expire.

Before you begin:

  • Configure the devices for network communication.

  • Configure the device interfaces.

Graceful restart is disabled by default. To enable VPN graceful restart:

  1. Configure graceful restart globally.

    Note:

    • Graceful restart can be enabled on logical systems. To configure graceful restart globally, include the graceful-restart statement at the [edit logical-systems logical-system-name routing-options] or the [edit logical-systems logical-system-name routing-instances routing-instance-name routing-options] hierarchy levels.

    • To disable graceful restart globally, include the disable statement at the [edit routing-options graceful-restart] hierarchy level.

      For example:

  2. Enable or disable graceful restart on a per-protocol, per-group, or per-neighbor basis, depending on the specific protocol, where the most specific definition is used.

  3. Configure graceful restart for Layer 3 VPNS for all routing and MPLS-related protocols within a routing instance. Because you can configure multi-instance BGP and multi-instance LDP, graceful restart for a carrier-of-carriers scenario is supported.

    Note:

    • To disable graceful restart globally, include the disable statement at the [edit routing-instances routing-instance-name routing-options graceful-restart] hierarchy level.

      For example:

    • To disable graceful restart for individual protocols, include the disable statement at the [edit routing-instances routing-instance-name protocols protocol-name graceful-restart] hierarchy level.

      For example:

  4. Configure the duration of the graceful restart period for the routing instance.

    The restart-duration option sets the period of time that the router waits for a graceful restart to be completed. You can configure a time between 1 through 600 seconds. The default value is 300 seconds. At the end of the configured time period, the router performs a standard restart without recovering its state from the neighboring routers. This disrupts VPN services, but is probably necessary if the router is not functioning normally.

    Note:

    You can include the restart-duration option at either the global or routing instance level.

Configuring Nonstop Active Routing for BGP Multicast VPN

BGP multicast virtual private network (MVPN) is a Layer 3 VPN application that is built on top of various unicast and multicast routing protocols such as Protocol Independent Multicast (PIM), BGP, RSVP, and LDP. Enabling nonstop active routing (NSR) for BGP MVPN requires that NSR support is enabled for all these protocols.

Before you begin:

The state maintained by MVPN includes MVPN routes, cmcast, provider-tunnel, and forwarding information. BGP MVPN NSR synchronizes this MVPN state between the primary and backup Routing Engines. While some of the state on the backup Routing Engine is locally built based on the configuration, most of it is built based on triggers from other protocols that MVPN interacts with. The triggers from these protocols are in turn the result of state replication performed by these modules. This includes route change notifications by unicast protocols, join and prune triggers from PIM, remote MVPN route notification by BGP, and provider-tunnel related notifications from RSVP and LDP.

Configuring NSR and unified in-service software upgrade (ISSU) support to the BGP MVPN protocol provides features such as various provider tunnel types, different MVPN modes (source tree, shared-tree), and PIM features. As a result, at the ingress PE, replication is turned on for dynamic LSPs. Thus, when NSR is configured, the state for dynamic LSPs is also replicated to the backup Routing Engine. After the state is resolved on the backup Routing Engine, RSVP sends required notifications to MVPN.

To enable BGP MVPN NSR support, the advertise-from-main-vpn-tables configuration statement needs to be configured at the [edit protocols bgp] hierarchy level.

Nonstop active routing configurations include two Routing Engines that share information so that routing is not interrupted during Routing Engine failover. When NSR is configured on a dual Routing Engine platform, the PIM control state is replicated on both Routing Engines.

This PIM state information includes:

  • Neighbor relationships

  • Join and prune information

  • RP-set information

  • Synchronization between routes and next hops and the forwarding state between the two Routing Engines

Junos OS supports NSR in the following PIM scenarios:

  • Dense mode

  • Sparse mode

  • SSM

  • Static RP

  • Auto-RP (for IPv4 only)

  • Bootstrap router

  • Embedded RP on the non-RP router (for IPv6 only)

  • BFD support

  • Draft Rosen multicast VPNs and BGP multicast VPNs

  • Policy features such as neighbor policy, bootstrap router export and import policies, scope policy, flow maps, and reverse path forwarding (RPF) check policies

To configure nonstop active routing:

  1. Because NSR requires you to configure graceful Routing Engine switchover (GRES), to enable GRES, include the graceful-switchover statement at the [edit chassis redundancy] hierarchy level.
  2. Include the synchronize statement at the [edit system] hierarchy level so that configuration changes are synchronized on both Routing Engines.
  3. Configure PIM settings on the desingated routerwith sparse mode and version, and static address pointing to the rendezvous points.

    For example, to set sparse mode, version 2 and static address:

  4. Configure per-packet load balancing on the designated router.

    For example, to set load-balance policy:

  5. Apply the load-balance policy on the designated router.
  6. Configure nonstop active routing on the designated router.

    For example, to set nonstop active routing on the designated router with address 10.210.255.201:

See Also

Related Documentation