Taking the M120 Host Subsystem Offline
The host subsystem is taken offline and brought online
as a unit. Before you replace a CB or a Routing Engine, you must take
the host subsystem offline.
Normally, if two host subsystems are installed in the router, RE0 functions as the master and RE1 functions as the
backup. You can remove the backup host subsystem (or either of its
components) without interrupting the functioning of the router. If
you take the master host subsystem offline, the backup host subsystem
becomes the master (the router might reboot, depending on your configuration).
If the router has only one host subsystem, taking the host subsystem
offline causes the router to shut down.
Table 1 explains the
effect of taking the host subsystem offline.
Table 1: Effect
of Taking the M120 Host Subsystem Offline
Type of Host Subsystem | Effect of taking the Host Subsystem Offline |
|---|
Nonredundant host subsystem | The router shuts down. |
Backup host subsystem | The functioning of the router is not interrupted. The
backup host subsystem is hot-removable and hot-insertable. |
Master host subsystem | The backup host subsystem becomes the master. The backup
Routing Engine assumes Routing Engine functions. The master host subsystem
is hot-pluggable. Removal or failure of the master Routing Engine
affects forwarding and routing based on the high availability configuration: - Dual Routing Engines without any high availability features
enabled—Traffic is interrupted while the Packet Forwarding Engine
is reinitialized. All kernel and forwarding processes are restarted.
When the switchover to the new master Routing Engine is complete,
routing convergence takes place and traffic is resumed.
- Graceful Routing Engine switchover (GRES) is enabled—Graceful
Routing Engine switchover preserves interface and kernel information.
Traffic is not interrupted. However, graceful Routing Engine switchover
does not preserve the control plane. Neighboring routers detect that
the router has restarted and react to the event in a manner prescribed
by individual routing protocol specifications. To preserve routing
without interruption during a switchover, graceful Routing Engine
switchover must be combined with nonstop active routing.
- Nonstop active routing is enabled (graceful Routing Engine
switchover must be configured for nonstop active routing to be enabled)—Nonstop
active routing supports Routing Engine switchover without alerting
peer nodes that a change has occurred. Nonstop active routing uses
the same infrastructure as graceful Routing Engine switchover to preserve
interface and kernel information. However, nonstop active routing
also preserves routing information and protocol sessions by running
the routing protocol process (rpd) on both Routing Engines. In addition,
nonstop active routing preserves TCP connections maintained in the
kernel.
- Graceful restart is configured—Graceful restart
provides extensions to routing protocols so that neighboring helper
routers restore routing information to a restarting router. These
extensions signal neighboring routers about the graceful restart and
prevent the neighbors from reacting to the router restart and from
propagating the change in state to the network during the graceful
restart period. Neighbors provide the routing information that enables
the restarting router to stop and restart routing protocols without
causing network reconvergence. Neighbors are required to support
graceful restart. The routing protocol process (rpd) restarts. A graceful
restart interval is required. For certain protocols, a significant
change in the network can cause graceful restart to stop.
|
 | Note:
Router performance might change if the backup Routing
Engine's configuration differs from the former master's configuration.
For the most predictable performance, configure the two Routing Engines
identically, except for parameters unique to each Routing Engine. |
 | Note:
For information about configuring graceful Routing Engine
switchover, graceful restart, and nonstop active routing, see the Junos OS High Availability Configuration Guide. |
 | Note:
The first supported release for graceful Routing Engine
switchover and nonstop active routing on the M120 router is Junos
OS Release 8.2 and Junos OS Release 9.0, respectively. Graceful restart
software requirements are dependent on the routing protocols configured
on the router. For the minimum software requirements for graceful
restart, see the Junos OS High Availability Configuration Guide. |
To take a host subsystem offline:
- Determine whether the host subsystem is functioning
as the master or as the backup, using one of the two following methods:
- Check the Routing Engine LEDs on the craft interface.
If the green RE MASTER LED is lit, the corresponding host
subsystem is functioning as the master.
- The master Routing Engine is designated Master in the Current state field when you issue the command:
user@host> show chassis routing-engine
Routing Engine status: Slot 0: Current state Master ...
- If the host subsystem is functioning as
the master, switch it to backup using the CLI command:
user@host> request chassis routing-engine
master switch
- On the console or other management device connected to
the Routing Engine that is paired with the CB you are removing, enter
CLI operational mode and issue the following command. The command
shuts down the Routing Engine cleanly, so its state information is
preserved:
user@host> request system halt
Wait until a message appears on the console
confirming that the operating system has halted.
For more
information about the command, see the Junos OS System Basics and Services Command Reference.
 | Note:
The FEB might continue forwarding traffic for approximately
5 minutes after the request system halt command has been
issued. |
Published: 2011-02-23