Technical Documentation

Taking the T1600 Host Subsystem Offline

Before you replace a control board or a Routing Engine, you must take the host subsystem offline. The host subsystem is taken offline and brought online as a unit. Normally, if two host subsystems are installed in the router, RE0 functions as the master and RE1 functions as the backup. Table 1 explains the effect of taking the host subsystem offline.

Table 1: Effect of Taking the 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. Nonstop active routing is supported on Junos OS Release 8.5 and later for standalone T1600 routers, Junos OS Release 10.0 and later for T1600 routers in a routing matrix. 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.

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.
Nonstop active routing is supported on Junos OS Release 8.5 and later for standalone T1600 routers, Junos OS Release 10.0 and later for T1600 routers in a routing matrix.
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 switchover and nonstop active routing, 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 MASTER LED is lit, the corresponding host subsystem is functioning as the master.
- Issue the following CLI command. The master Routing Engine is designated Master in the Current state field:
  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
To halt the router:
user@host> request system halt
(If two Routing Engines are installed, also issue the command on the backup Routing Engine.) Wait until a message appears on the console confirming that the operating system has halted.
The command shuts down the Routing Engine cleanly, so its state information is preserved. For more information about the command, see the Junos OS System Basics and Services Command Reference .
Note: The SIBs might continue forwarding traffic for approximately 5 minutes after the request system halt command has been issued.
On the console or other management device connected to the other Routing Engine, enter CLI operational mode and issue the following command.
user@host> request chassis cb offline slot n
n is 0 or 1 for the slot number of the host subsystem being taken offline.
Verify that the control board is offline:
user@host> show chassis environment cb

Choose Country

North America

Europe

Asia Pacific

Technical Documentation

Related Documentation

Taking the T1600 Host Subsystem Offline

Related Documentation

Published: 2011-12-20