• Supported Platforms
• TX Matrix Routers

• Related Topics
• TX Matrix Host Subsystem Description

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 TX-CB 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.

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

     Routing Engine status:   
       Slot 0:
         Current state                 Master
     ...
     
      

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 graceful switchover, 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 section about Routing Engine redundancy in the Junos System Basics Configuration Guide.

   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 Junos System Basics Configuration 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 system commands, see the Junos System Basics and Services Command Reference.

   (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 System Basics and Services Command Reference.

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