Configuring Graceful Restart for Routing Protocols
You can configure graceful restart for routing protocols with the steps below.
Enabling Graceful Restart
By default, graceful restart is disabled. To enable graceful restart, include the graceful-restart statement at the [edit routing-instance instance-name routing-options] or [edit routing-options] hierarchy level.
For example:
routing-options {
graceful-restart;
}
To configure the duration of the graceful restart period, include the restart-duration at the [edit routing-options graceful-restart] hierarchy level.
Helper mode (the ability to assist a neighboring router attempting a graceful restart) is enabled by default when you start the routing platform, even if graceful restart is not enabled. You can disable helper mode on a per-protocol basis.
[edit]
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}
To disable graceful restart globally, include the disable statement at the [edit routing-options graceful-restart] hierarchy level.
When graceful restart is enabled for all routing protocols at the [edit routing-options graceful-restart] hierarchy level, you can disable graceful restart on a per-protocol basis.
If you configure graceful restart after a BGP or LDP session has been established, the BGP or LDP session restarts and the peers negotiate graceful restart capabilities. Also, the BGP peer routing statistics are reset to zero.
Configuring Graceful Restart Options for BGP
To configure the duration of the BGP graceful restart period, include the restart-time statement at the [edit protocols bgp graceful-restart] hierarchy level. To set the length of time the router waits to receive messages from restarting neighbors before declaring them down, include the stale-routes-time statement at the [edit protocols bgp graceful-restart] hierarchy level.
[edit]
protocols {
bgp {
graceful-restart {
disable;
restart-time seconds;
stale-routes-time seconds;
}
}
}
routing-options {
graceful-restart;
}
To disable BGP graceful restart capability for all BGP sessions, include the disable statement at the [edit protocols bgp graceful-restart] hierarchy level.
To set BGP graceful restart properties or disable them for a group, include the desired statements at the [edit protocols bgp group group-name graceful-restart] hierarchy level.
To set BGP graceful restart properties or disable them for a specific neighbor in a group, include the desired statements at the [edit protocols bgp group group-name neighbor ip-address graceful-restart] hierarchy level.
Configuring graceful restart for BGP resets the BGP peer routing statistics to zero. Also, existing BGP sessions restart, and the peers negotiate graceful restart capabilities.
Do not configure both Bidirectional Forwarding Detection (BFD) for BGP and graceful restart for BGP. Routing performance may be sub-optimal if you do this.
Using Control Plane Dependent BFD along with Graceful Restart Helper Mode
When BFD is control plane dependent and the device detects a BFD down event and is not already entering the graceful restart helper mode, this is treated as a regular BFD down event and the device enters the graceful restart helper mode. This behavior makes the control plane dependent BFD unusable in conjunction with graceful restart.
Include the dont-help-shared-fate-bfd-down statement at the
[edit protocols bgp graceful-restart] hierarchy to ensures
that the device does not enter the graceful restart helper mode and data traffic
continues to be fowarded to an alternate path even if there is an interface
failure (without a control plane restart on the BGP neighbor).
[edit]
protocols {
bgp {
graceful-restart {
disable;
dont-help-shared-fate-bfd-down;
restart-time seconds;
stale-routes-time seconds;
}
}
}
routing-options {
graceful-restart;
}
Starting in Junos OS Release 18.3R1, you can prevent SRX Series Firewalls from
entering the graceful restart helper mode when the device is configured with BFD
with a single-hop external BGP (EBGP), by including the
dont-help-shared-fate-bfd-down statement at the
[edit protocols bgp graceful-restart] hierarchy.
See Also
Configuring Graceful Restart Options for ES-IS
On J Series Services Routers, to configure the duration of the ES-IS graceful
restart period, include the restart-duration statement at the
[edit protocols esis graceful-restart] hierarchy level.
[edit]
protocols {
esis {
graceful-restart {
disable;
restart-duration seconds;
}
}
}
routing-options {
graceful-restart;
}
To disable ES-IS graceful restart capability, include the
disable statement at the [edit protocols esis
graceful-restart] hierarchy level.
Configuring Graceful Restart Options for IS-IS
To configure the duration of the IS-IS graceful restart period, include the
restart-duration statement at the [edit protocols
isis graceful-restart] hierarchy level.
[edit]
protocols {
isis {
graceful-restart {
disable;
helper-disable;
restart-duration seconds;
}
}
}
routing-options {
graceful-restart;
}
To disable IS-IS graceful restart helper capability, include the
helper-disable statement at the [edit protocols
isis graceful-restart] hierarchy level. To disable IS-IS graceful
restart capability, include the disable statement at the
[edit protocols isis graceful-restart] hierarchy level.
Starting with Junos OS Release 12.3, if adjacencies between the Routing Engine and the neighboring peer 'helper' routers time out, graceful restart protocol extensions are unable to notify the peer 'helper' routers about the impending restart.Graceful restart can then stop and cause interruptions in traffic.
To ensure that these adjacencies are kept, change the hold-time for IS-IS protocols from the default of 27 seconds to a value higher than 40 seconds.
You can also track graceful restart events with the
traceoptions statement at the [edit protocols
isis] hierarchy level. For more information, see Tracking Graceful Restart Events.
Configuring Graceful Restart Options for OSPF and OSPFv3
To configure the duration of the OSPF/OSPFv3 graceful restart period, include the restart-duration statement at the [edit protocols (ospf | ospf3) graceful-restart] hierarchy level. To specify the length of time for which the router notifies helper routers that it has completed graceful restart, include the notify-duration at the [edit protocols (ospf | ospf3) graceful-restart] hierarchy level. Strict OSPF link-state advertisement (LSA) checking results in the termination of graceful restart by a helping router. To disable strict LSA checking, include the no-strict-lsa-checking statement at the [edit protocols (ospf | ospf3) graceful-restart] hierarchy level.
[edit]
protocols {
ospf | ospfv3{
graceful-restart {
disable;
helper-disable
no-strict-lsa-checking;
notify-duration seconds;
restart-duration seconds;
}
}
}
routing-options {
graceful-restart;
}
To disable OSPF/OSPFv3 graceful restart, include the disable statement at the [edit protocols (ospf | ospf3) graceful-restart] hierarchy level.
Starting with Release 11.3, the Junos OS supports both the standard (based on RFC 3623, Graceful OSPF Restart) and the restart signaling-based (as specified in RFC 4811, RFC 4812, and RFC 4813) helper modes for OSPF version 2 graceful restart configurations. Both the standard and restart signaling-based helper modes are enabled by default. To disable the helper mode for OSPF version 2 graceful restart configurations, include the helper-disable <both | restart-signaling | standard> statement at the [edit protocols ospf graceful-restart] hierarchy level. Note that the last committed statement always takes precedence over the previous one.
[edit protocols ospf]
graceful-restart {
helper-disable <both | restart-signaling | standard>
}
To reenable the helper mode, delete the helper-disable statement from the configuration by using the delete protocols ospf graceful-restarthelper-disable <restart-signaling | standard | both> command. In this case also, the last executed command takes precedence over the previous ones.
Restart signaling-based helper mode is not supported for OSPFv3
configurations. To disable helper mode for OSPFv3 configurations, include
the helper-disable statement at the [edit
protocols ospfv3 graceful-restart] hierarchy level.
You can also track graceful restart events with the traceoptions statement at the [edit protocols (ospf | ospf3)] hierarchy level. For more information, see Tracking Graceful Restart Events.
You cannot enable OSPFv3 graceful restart between a routing platform running Junos OS Release 7.5 and earlier and a routing platform running Junos OS Release 7.6 or later. As a workaround, make sure both routing platforms use the same Junos OS version.
Configuring Graceful Restart Options for RIP and RIPng
To configure the duration of the RIP or RIPng graceful restart period, include
the restart-time statement at the [edit protocols (rip
| ripng) graceful-restart] hierarchy level.
[edit]
protocols {
(rip | ripng) {
graceful-restart {
disable;
restart-time seconds;
}
}
}
routing-options {
graceful-restart;
}
To disable RIP or RIPng graceful restart capability, include the
disable statement at the [edit protocols (rip |
ripng) graceful-restart] hierarchy level.
Configuring Graceful Restart Options for PIM Sparse Mode
PIM sparse mode continues to forward existing multicast packet streams during a graceful restart, but does not forward new streams until after the restart is complete. After a restart, the routing platform updates the forwarding state with any updates that were received from neighbors and occurred during the restart period. For example, the routing platform relearns the join and prune states of neighbors during the restart, but does not apply the changes to the forwarding table until after the restart.
PIM sparse mode-enabled routing platforms generate a unique 32-bit random number called a generation identifier. Generation identifiers are included by default in PIM hello messages, as specified in the IETF Internet draft Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). When a routing platform receives PIM hellos containing generation identifiers on a point-to-point interface, Junos OS activates an algorithm that optimizes graceful restart.
Before PIM sparse mode graceful restart occurs, each routing platform creates a generation identifier and sends it to its multicast neighbors. If a PIM sparse mode-enabled routing platform restarts, it creates a new generation identifier and sends it to its neighbors. When a neighbor receives the new identifier, it resends multicast updates to the restarting router to allow it to exit graceful restart efficiently. The restart phase completes when either the PIM state becomes stable or when the restart interval timer expires.
If a routing platform does not support generation identifiers or if PIM is enabled on multipoint interfaces, the PIM sparse mode graceful restart algorithm does not activate, and a default restart timer is used as the restart mechanism.
To configure the duration of the PIM graceful restart period, include the
restart-duration statement at the [edit protocols
pim graceful-restart] hierarchy level:
[edit]
protocols {
pim {
graceful-restart {
disable;
restart-duration seconds;
}
}
}
routing-options {
graceful-restart;
}
To disable PIM sparse mode graceful restart capability, include the
disable statement at the [edit protocols pim
graceful-restart] hierarchy level.
Multicast forwarding can be interrupted in two ways. First, if the underlying routing protocol is unstable, multicast reverse-path-forwarding (RPF) checks can fail and cause an interruption. Second, because the forwarding table is not updated during the graceful restart period, new multicast streams are not forwarded until graceful restart is complete.
Tracking Graceful Restart Events
To track the progress of a graceful restart event, you can configure graceful restart trace options flags for IS-IS and OSPF/OSPFv3. To configure graceful restart trace options, include the graceful-restart statement at the [edit protocols protocol traceoptions flag] hierarchy level:
[edit protocols]
isis {
traceoptions {
flag graceful-restart;
}
}
(ospf | ospf3) {
traceoptions {
flag graceful-restart;
}
}
Configuring Graceful Restart for MPLS-Related Protocols
This section contains the following topics:
- Configuring Graceful Restart Globally
- Configuring Graceful Restart Options for RSVP, CCC, and TCC
- Configuring Graceful Restart Options for LDP
Configuring Graceful Restart Globally
To configure graceful restart globally for all MPLS-related
protocols, include the graceful-restart statement at the [edit routing-options] hierarchy level. To configure the duration
of the graceful restart period, include the restart-duration at the [edit routing-options graceful-restart] hierarchy
level:
[edit]
routing-options {
graceful-restart {
disable;
restart-duration seconds;
}
}
To disable graceful restart globally, include the disable statement at the [edit routing-options graceful-restart] hierarchy level.
Configuring Graceful Restart Options for RSVP, CCC, and TCC
Because CCC and TCC rely on RSVP, you must modify these three protocols as a single group.
To configure how long the router retains the state of its RSVP
neighbors while they undergo a graceful restart, include the maximum-helper-recovery-time statement at the [edit protocols
rsvp graceful-restart] hierarchy level. This value is applied
to all neighboring routers, so it should be based on the time required
by the slowest RSVP neighbor to recover.
To configure the delay between when the router discovers
that a neighboring router has gone down and when it declares the neighbor
down, include the maximum-helper-restart-time statement
at the [edit protocols rsvp graceful-restart] hierarchy
level. This value is applied to all neighboring routers, so it should
be based on the time required by the slowest RSVP neighbor to restart.
[edit]
protocols {
rsvp {
graceful-restart {
disable;
helper-disable;
maximum-helper-recovery-time;
maximum-helper-restart-time;
}
}
}
routing-options {
graceful-restart;
}
To disable RSVP, CCC, and TCC graceful restart, include the disable statement at the [edit protocols rsvp graceful-restart] hierarchy level. To disable RSVP, CCC, and TCC helper capability,
include the helper-disable statement at the [edit
protocols rsvp graceful-restart] hierarchy level.
Configuring Graceful Restart Options for LDP
When configuring graceful restart for LDP, you can include
the following optional statements at the [edit protocols ldp
graceful-restart] hierarchy level:
[edit protocols ldp graceful-restart] disable; helper-disable; maximum-neighbor-reconnect-time seconds; maximum-neighbor-recovery-time seconds; reconnect-time seconds; recovery-time seconds; [edit routing-options] graceful-restart;
The statements have the following effects on the graceful restart process:
To configure the length of time required to reestablish a session after a graceful restart, include the
reconnect-timestatement; the range is 30 through 300 seconds. To limit the maximum reconnect time allowed from a restarting neighbor router, include themaximum-neighbor-reconnect-timestatement; the range is 30 through 300 seconds.To configure the length of time that helper routers are required to maintain the old forwarding state during a graceful restart, include the
recovery-timestatement; the range is 120 through 1800 seconds. On the helper router, you can configure a statement that overrides the request from the restarting router and sets the maximum length of time the helper router will maintain the old forwarding state. To configure this feature, include themaximum-neighbor-recovery-timestatement; the range is 140 through 1900 seconds.Note:The value for the recovery-time and
maximum-neighbor-recovery-timestatements at the[edit protocols ldp graceful-restart]hierarchy level should be approximately 80 seconds longer than the value for therestart-durationstatement at the[edit routing-options graceful-restart]hierarchy level. Otherwise, a warning message appears when you try to commit the configuration.To disable LDP graceful restart capability, include the
disablestatement. To disable LDP graceful restart helper capability, include thehelper-disablestatement.
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.