13: GRES, NSR and Unified ISSU

Graceful Routing Engine Switchover

GRES ensures that interface and kernel information is preserved. Traffic flow through the data plane is not interrupted when control switches from one routing engine to the other, however, the control plane is interrupted. Routing information must be relearned. If Non-Stop Routing is also enabled, the routing information is kept.

Without GRES, the Packet Forwarding Engine (PFE) restarts and all hardware interfaces go down for the duration of the restart. The new routing engine then discovers the PFE and bring interfaces back up. With GRES, the PFE is not restarted. Switchover is faster. The new routing engine must restart the Routing Protocol Daemon (rpd) and relearn routing information.

Operations

show chassis routing-engine shows the primary and backup routing engines.

The routing engines can be configured with separate hostnames and management IP addresses, on the management port built into the routing engine.

The backup-router statement provides a default route for a backup router, which would otherwise not have any routes, as rpd is not running.

groups {
    re1 {
        system {
            host-name ...;
            backup-router ...;
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address ...;
                    }
                }
            }
        }
    }
    ... same for re0 ...
}

apply-groups {
    re0;
    re1;
}

Where dual routing engines are in use, commits should be synchronised across both routing engines. Either use commit synchronize at each commit, or add commit synchronize under the system hierarchy;

system {
    commit synchronize;
}

Routing engines exchange keepalives. If the backup RE does not receive a keepalive after an interval, usually two seconds, the backup RE becomes the primary RE. The PFE seamlessly disconnects from the old primary RE to the new one, remaining operational throughout. The new primary RE and the PFE synchronise, with the new primary RE sending state updates to the PFE as required.

Routing engine redundancy options are platform specific and are configured under the chassis redundancy hierarchy. Graceful switchover can be forced with the request chassis routing-engine master ? commands, with acquire, release, or switch.

GRES is enabled as;

chassis {
    redundancy {
        graceful-switchover;
    }
}

Once GRES is activated, the command prompt changes to include {master} or {backup}.

Monitoring

Use show system switchover to verify that GRES is active and ready to switch over. GRES can only be verified from the backup RE; the command is unavailable on the primary RE.

Non-Stop Active Routing

NSR enables the primary role change to occur without alerting peer nodes. It uses GRES infrastructure, but also runs rpd on the backup RE to synchronise routing information.

Although NSR uses GRES infrastructure, it cannot be enabled at the same time as GRES. Attempting to do so results in a configuration error. With NSR, both routing engines must run the same version of Junos.

NSR supports most, but not all, protocols. Unsupported protocols are recovered by the usual recovery mechanisms.

Configuring NSR

routing-options {
    nonstop-routing;
}

Once NSR is enabled and the configuration is synchronised, rpd on the backup RE actively acquires routing information from the primary RE.

Monitoring NSR

Use show task replication to list protocols supported by NSR and their current synchronisation states. show commands on the backup RE will provide the current state of routing protocols learned from the primary RE.

The nsr-synchrinization flag can be enabled under protocols ospf traceoptions to enable logging.

Unified ISSU

Enables upgrades between two versions of Junos with no disruption to the control plane. NSR must be enabled for ISSU to work.

Both routing engines must be running the same version of Junos before commencing a unified ISSU. Physical interface cards cannot be taken offline during an ISSU.

Performing a Unified ISSU

1. Enable GRES and NSR and verify that routing protocols are synchronise
2. Verify that both REs are running the same software version
3. Download the new software onto the primary RE
4. Issue the request system software in-service-upgrade command on the primary RE

To verify the status of individual PICs, run show chassis in-service-upgrade.

If the unified ISSU procedure stops progressing, issue the request system software abort in-service-upgrade command. Then check that the upgrade has been aborted.