Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Taking a TX Matrix Host Subsystem Offline

 Note

We recommend that you run the same Junos OS release on the master and backup Routing Engines. If you elect to run different Junos OS releases on the Routing Engines, a change in Routing Engine mastership can cause one or all T640 routers to be logically disconnected from the TX Matrix router. For more information, see Running Different Junos OS Releases on the Routing Engines.

The host subsystem is taken offline and brought online as a unit. Before you replace a Control Board or a Routing Engine, you must take the host subsystem offline. Table 1 shows the effect of taking a master, backup, and nonredundant host subsystem offline.

Table 1: Effect of Taking the Host Subsystem Offline

Type of Host SubsystemEffect of Taking the Host Subsystem Offline

Nonredundant host subsystem

The TX Matrix router shuts down.

Backup host subsystem

The functioning of the TX Matrix 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.

During the switchover:

  • Graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) are both configured—Packet forwarding and routing are continued without interruption.

  • GRES is configured but NSR is not configured—Packet forwarding continues but routing is interrupted momentarily.

  • GRES and NSR are not configured—Packet forwarding halts while the standby Routing Engine becomes the master. The Packet Forwarding Engine components reset and connect to the new master Routing Engine.

Note: TX Matrix 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.

For information about configuring graceful switchover and nonstop active routing, see the Junos OS High Availability Library for Routing Devices.

To take a host subsystem offline:

  1. 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 scc
  2. 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 scc

    If the Routing Engines are running the same Junos OS release and are configured for nonstop active routing, the standby Routing Engine immediately assumes Routing Engine functions and there is no interruption to packet forwarding. Otherwise, packet forwarding halts while the standby Routing Engine becomes the master and the Packet Forwarding Engine components reset and connect to the new master Routing Engine. For information about configuring graceful switchover, see the Junos OS High Availability Library for Routing Devices.

    Note

    TX Matrix router performance might change if the standby 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 a Routing Engine, such as the hostname defined at the [edit system] hierarchy level and the management interface (fxp0 or equivalent) defined at the [edit interfaces] hierarchy level.

    To configure Routing Engine-specific parameters and still use the same configuration on both Routing Engines, include the appropriate configuration statements under the re0 and re1 statements at the [edit groups] hierarchy level and use the apply-groups statement. For instructions, see the Routing Matrix with a TX Matrix Router Deployment Guide..

  3. To halt the router:
    user@host> request system halt scc
    Note

    The request system halt scc command halts all Routing Engines on the control plane from which it was issued. To reboot a Routing Engine that has been halted, you must connect through the console. For more information about this command, see 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.

    Note

    The TX-SIBs might continue forwarding traffic for approximately five minutes after the request system halt command has been issued.