Configuring Graceful Routing Engine Switchover
SUMMARY Learn how to configure Graceful Routing Engine Switchover (GRES) with the following steps and examples.
Requirements for Routers with a Backup Router Configuration
If your Routing Engine configuration includes a backup-router statement or an inet6-backup-router statement, you can
also use the destination statement to specify a subnet
address or multiple subnet addresses for the backup router. Include
destination subnets for the backup Routing Engine at the [edit
system (backup-router | inet6-backup-router) address] hierarchy
level. This requirement also applies to any T640 router connected
to a TX Matrix router that includes a backup-router or inet6-backup-router statement.
If you have a backup router configuration in which multiple
static routes point to a gateway from the management Ethernet interface,
you must configure prefixes that are more specific than the static
routes or include the retain flag at the [edit routing-options
static route] hierarchy level.
For example, if you configure the static route 172.16.0.0/12 from the management Ethernet interface for management purposes, you must specify the backup router configuration as follows:
backup-router 172.29.201.62 destination [172.16.0.0/13 172.16.128.0/13]
See Also
Enabling Graceful Routing Engine Switchover
By default, graceful Routing Engine switchover (GRES) is disabled. To configure
GRES, include the graceful-switchover statement at the
[edit chassis redundancy] hierarchy level.
[edit chassis redundancy] graceful-switchover;
When you enable GRES, the command-line interface (CLI) indicates which Routing Engine you are using. For example:
{master} [edit]
user@host#
To disable GRES, delete the graceful-switchover statement from
the [edit chassis redundancy] hierarchy level.
Configuring Graceful Routing Engine Switchover with Graceful Restart
When using GRES with Graceful Restart, 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.
Synchronizing the Routing Engine Configuration
A newly inserted backup Routing Engine automatically synchronizes its configuration with the primary Routing Engine configuration.
When you configure GRES, you can bring the backup Routing Engine online after the primary Routing Engine is already running. There is no requirement to start the two Routing Engines simultaneously.
Only when you enable the graceful Routing Engine switchover, you can copy the running Junos OS version of the primary Routing Engine to the backup Routing Engine.
If the system is in ISSU state, you cannot copy the running Junos OS version of the primary Router Engine.
Starting in Junos OS release 14.1, you can enable automatic synchronization of the primary Routing Engine configuration with the backup Routing Engine by including the events CHASSISD_SNMP_TRAP7 statement at the [edit event-options policy policy-name] hierarchy level.
CHASSISD_SNMP_TRAP7 is a system event logging message that the chassis process (chassisd) generates a Simple Network Management Protocol (SNMP) trap with the seven indicated argument-value pairs. An example of an event script to trigger automatic synchronization of primary to the backup Routing Engine is as follows:
[edit event-options]
policy UPGRADE-BACKUPRE {
events CHASSISD_SNMP_TRAP7;
attributes-match {
CHASSISD_SNMP_TRAP7.value5 matches "Routing Engine";
CHASSISD_SNMP_TRAP7.trap matches "Fru Online";
CHASSISD_SNMP_TRAP7.argument5 matches jnxFruName;
}
then {
event-script auto-image-upgrade.slax {
arguments {
trap "{$$.trap}";
value5 "{$$.value5}";
argument5 "{$$.argument5}";
}
}
}
}
event-script {
file auto-image-upgrade.slax;
}After receiving this event, the event policy on the primary Router Engine is triggered and the image available in the /var/sw/pkg path is pushed to the backup Router Engine upgrade. During script execution, the image is copied to the backup Routing Engine's /var/sw/pkg path.
If the image is not available in the /var/sw/pkg path, the script is terminated with an appropriate syslog message.
If the Routing Engine is running at the Junos OS Release 13.2 or later, the Junos automation scripts is synchronized automatically.
After the primary Router Engine is rebooted, the event script available at the /usr/libexec/scripts/event/auto-image-upgrade.slax must be copied to the /var/db/scripts/event path.
For MX Series routers using enhanced subscriber management, the new backup Routing Engine (the former primary Routing Engine) will reboot when a graceful Routing Engine switchover is performed. This cold restart resynchronizes the backup Routing Engine state with that of the new primary Routing Engine, preventing discrepancies in state that might have occurred during the switchover.
Verifying Graceful Routing Engine Switchover Operation
To verify whether GRES is enabled on the backup Routing Engine, issue the
show system switchover command. When the output of the
command indicates that the Graceful switchover field is
set to On, GRES is operational. The status of the kernel
database and configuration database synchronization between Routing Engines is
also provided. For example:
Graceful switchover: On Configuration database: Ready Kernel database: Ready Peer state: Steady state
You must issue the show system switchover command on the
backup Routing Engine. This command is not supported on the primary Routing
Engine.
For more information about the show system switchover command,
see the CLI Explorer.
Configuring Graceful Routing Engine Switchover in a Virtual Chassis
In a Virtual Chassis, one member switch is assigned the primary role and has the primary Routing Engine. Another member switch is assigned the backup role and has the backup Routing Engine. Graceful Routing Engine switchover (GRES) enables the primary and backup Routing Engines in a Virtual Chassis configuration to switch from the primary to backup without interruption to packet forwarding as a hitless failover solution. When you configure graceful Routing Engine switchover, the backup Routing Engine automatically synchronizes with the primary Routing Engine to preserve kernel state information and the forwarding state.
To set up the Virtual Chassis configuration to use graceful Routing Engine switchover (GRES):
Commit the configuration.
We recommend that you use the commit synchronize command to save any configuration changes that you make to a multimember
Virtual Chassis.
See Also
Preventing Graceful Routing Engine Switchover in the Case of Slow Disks
Unexpected slow disk access can happen for various reasons—a faulty or bad sector, for example—causing a hold up of the normal operation of processes such as the routing process (rpd). Eventually, the router’s performance will be impacted. Under these circumstances, it may take longer for the typical failover mechanism to be triggered.
Juniper Networks has introduced a disk monitoring daemon to solve this dilemma. The daemon detects slow disk access and initiates failover. Failover can minimize the traffic impact and ease the load on the original primary Routing Engine for its backlog clean up.
However, there are instances when you might not want failover
to occur. You might commit a large set of changes or even minor changes
that might lead to a series of updates on the routing topology. Such
activity could lead to extensive disk access delay and, therefore,
trigger failover. For expected disk access delays like this, where
you do not want to trigger failover, you can choose to not have failover
occur by setting the chassis redundancy failover not-on-disk-underperform configuration command. Another way is to disable the disk monitoring
daemon completely by setting the system processes gstatd disable command.
To prevent failovers in the case of slow disks in the Routing Engine:
[edit chassis redundancy failover] hierarchy level. [edit] user@host# set chassis redundancy failover not-on-disk-underperform
See Also
Resetting Local Statistics
When you enable graceful Routing Engine switchover, the primary Routing Engine configuration is copied and loaded to the backup Routing Engine. User files, accounting information, and trace options information are not replicated to the backup Routing Engine.
When a graceful Routing Engine switchover occurs, local statistics such as process statistics and networking statistics are displayed as a cumulative value from the time the process first came online. Because processes on the primary Routing Engine can start at different times from the processes on the backup Routing Engine, the statistics on the two Routing Engines for the same process might differ. After a graceful Routing Engine switchover, we recommend that you issue the clear interface statistics (interface-name | all) command to reset the cumulative values for local statistics. Forwarding statistics are not affected by graceful Routing Engine switchover.
For information about how to use the clear command to clear statistics and protocol database information, see the CLI Explorer.
The clear firewall command cannot be used to clear the Routing Engine filter counters on a backup Routing Engine that is enabled for graceful Routing Engine switchover.
See Also
Example: Configuring IS-IS for GRES with Graceful Restart
This example shows how to configure the Routing Engine’s graceful restart protocol extensions using the intermediate system to intermediate system (IS-IS) interior gateway protocol (IGP) to successfully enable graceful Routing Engine switchover (GRES) with graceful restart.
Requirements
GRES prevents interruptions in network traffic if the primary Routing Engine fails when combined with either:
Graceful restart
Nonstop active routing (NSR)
Before you follow the directions here to configure graceful restart, be sure you have enabled GRES, which is disabled by default. See Configuring Graceful Routing Engine Switchover for more information.
Overview
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.
If your system uses the open shortest pathway first (OSPF) protocol instead of IS-IS, see Example: Configuring OSPF Timers for configuration information.
Configuration
CLI Quick Configuration
To quickly configure the hold-time, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the different hierarchy levels shown.
Each interface must be set individually, with a value for each level that the routing device operates on. The minimum recommended value of 41 seconds is used in this example, your system may require a higher value based on size and traffic.
Level 1 and level 2 can be set to different values.
[edit protocols]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[edit logical-systems logical-system-name}
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[edit logical-systems logical-system-name routing-instances routing-instance-name]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[edit routing-instances routing-instance-name]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
Configuring the IS-IS Protocol Hold Time for Graceful Restart
Step-by-Step Procedure
To configure the IS-IS hold-time for graceful restart:
Locate or set the interfaces.
set protocols isis interface interface-name
Set the network level and the hold-time in seconds for that level.
set protocols isis interface interface-name level 1 hold-time 41
If the routing device functions on more than one level, set the value for the other level.
set protocols isis interface interface-name level 2 hold-time 41
If you are done configuring the routing device, commit the configuration.
Note:Repeat the entire configuration on all routing devices in a shared network.
Results
Verification
Verifying the IS-IS Protocol Hold Time for Graceful Restart
Purpose
Verify that the IS-IS protocol hold-time is set to 41 seconds or greater to ensure that graceful restart is enabled.
Action
Confirm your configuration by entering the show
isis adjacency brief command from operational mode. If the output
does not display the intended configuration, repeat the instructions
in this example to correct the configuration.
Meaning
A high enough IS-IS protocol hold-time value allows your system configuration to restart and ensures that even if a Routing Engine fails, traffic continues.
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.