There is only one TX Matrix platform per routing
matrix. It is referred to as the switch-card chassis (scc) in the JUNOS CLI.
T640 routing nodes
There can be one to four T640 routing nodes in
a routing matrix. These are referred to as line-card chassis 0 through
3 (lcc0–lcc3) in the JUNOS CLI. The T640 routing
node number is set by the hardware. See the TX Matrix Platform Hardware Guide for further information
on installing and connecting the hardware.
Viewing the Routing Matrix as a Single Routing Platform
Even though a routing matrix can comprise five
separate physical components (a TX Matrix platform and up to four
T640 routing nodes), it is best if you consider a routing matrix as
a single routing platform. When you issue configuration and operational
commands on the TX Matrix platform, your view of the routing matrix
shows a single routing device with a high number of FPCs and PICs.
For a detailed discussion of FPC numbering in a routing matrix, see Adjusting the Configuration to Accommodate Increased FPC Numbers.
Connecting to a Routing Matrix
The TX Matrix platform and every T640 routing node
can each be configured with two Routing Engines to provide redundancy
and graceful Routing Engine switchover capabilities. You can connect
to each Routing Engine in the following ways:
Console/AUX—Asynchronous access via the console
and auxiliary ports on the TX Matrix platform or T640 routing node
Connector Interface Panel (CIP).
Management Ethernet—Telnet access via the Fast Ethernet
ports on the TX Matrix platform or T640 routing node CIPs.
CLI login from one Routing Engine to another—All
Routing Engines in the routing matrix are connected to their respective
control boards, which in turn are connected to the CIP on the TX Matrix
platform (see the TX Matrix Platform Hardware Guide for more details). After
you log in to one Routing Engine, you can connect to another Routing
Engine as follows:
user@router> request routing-engine
login ?
Possible completions:
backup Log in to backup RE
lcc Log in to LCC (0..3)
master Log in to master RE
other-routing-engine Log in to the other Routing Engine
re0 Log in to RE0
re1 Log in to RE1
user@router> request routing-engine login lcc ?
Possible completions:
<lcc> Log in to LCC (0..3)
user@router> request routing-engine login lcc 0 ?
Possible completions:
backup Log in to backup RE
master Log in to master RE
re0 Log in to RE0
re1 Log in to RE1
Note:
Because the routing matrix appears as a single
routing platform, we recommend that you access the master Routing
Engine of the TX Matrix platform to perform all configuration tasks
for the routing matrix. Under normal operating conditions, you do
not need to access or configure the T640 routing nodes directly. If
you access a Routing Engine on a T640 routing node, the following
warning is displayed:
--- JUNOS 7.0-20040625.1 built 2004-06-25 19:51:38 UTC
%
% cli
warning: This chassis is a Line Card Chassis (LCC) in a multichassis system.
warning: Use of interactive commands should be limited to debugging.
warning: Normal CLI access is provided by the Switch Card Chassis (SCC).
warning: Use 'request routing-engine login scc' to log into the SCC.
To manage the backup Routing Engines on all components
(for example, to upgrade JUNOS software), log in to the TX Matrix
platform backup Routing Engine and perform the necessary operations.
Committing Configurations on a Routing Matrix
You must commit configuration changes for a routing
matrix on the TX Matrix platform rather than on the individual T640
routing nodes. If you commit a configuration directly on a T640 routing
node within a routing matrix, the configuration is not distributed
to the TX Matrix platform or the other T640 routing nodes in the routing
matrix. Conversely, all configuration changes you commit on the TX
Matrix platform are distributed to all the T640 routing nodes in the
routing matrix and override any changes committed directly on a T640
routing node.
There are two main ways to commit configurations
on a TX Matrix platform. When you issue the commit synchronize command, you synchronize the configurations of both the primary
and backup Routing Engines on the TX Matrix platform and the primary
and backup Routing Engines of all the associated T640 routing nodes.
If you issue the basic form of the commit command on the TX Matrix platform, this action updates only the
master Routing Engines of the TX Matrix platform and the T640 routing
nodes in the routing matrix.
By default, when you upgrade software on the TX
Matrix platform, the new image is loaded onto the TX Matrix platform
and distributed to all T640 routing nodes in the routing matrix. To
upgrade software for the entire routing matrix, issue the request
system software add command:
user@router> request system software
add jbundle-7.0-20040705.0-domestic-signed.tgz
user@router> ...test/jinstall-9.1-daily-domestic.tgz reboot no-validate
Fetching package...
Pushing bundle to lcc0-re0
Pushing bundle to lcc2-re0
lcc0-re0:
Installing package '/var/tmp/mchassis-install.tgz' ...
Verified jinstall-9.1-20081002.0-domestic.tgz signed by PackageProduction_9_1_0 Adding jinstall...
Verified manifest signed by PackageProduction_9_1_0
WARNING: This package will load JUNOS 9.1-20081002.0 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in /var/sw/pkg/jinstall-9.1-20081002.0-domestic-signed.tgz ...
Saving state for rollback ...
lcc2-re0:
Installing package '/var/tmp/mchassis-install.tgz' ...
Verified jinstall-9.1-20081002.0-domestic.tgz signed by PackageProduction_9_1_0 Adding jinstall...
Verified manifest signed by PackageProduction_9_1_0
WARNING: This package will load JUNOS 9.1-20081002.0 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in /var/sw/pkg/jinstall-9.1-20081002.0-domestic-signed.tgz ...
Saving state for rollback ...
scc-re0:
Installing package '/var/tmp/mchassis-install.tgz' ...
Verified jinstall-9.1-20081002.0-domestic.tgz signed by PackageProduction_9_1_0 Adding jinstall...
Verified manifest signed by PackageProduction_9_1_0
WARNING: This package will load JUNOS 9.1-20081002.0 software.
WARNING: It will save JUNOS configuration files, and SSH keys
WARNING: (if configured), but erase all other files and information
WARNING: stored on this machine. It will attempt to preserve dumps
WARNING: and log files, but this can not be guaranteed. This is the
WARNING: pre-installation stage and all the software is loaded when
WARNING: you reboot the system.
Saving the config files ...
NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-install
Installing the bootstrap installer ...
WARNING: A REBOOT IS REQUIRED TO LOAD THIS SOFTWARE CORRECTLY. Use the
WARNING: 'request system reboot' command when software installation is
WARNING: complete. To abort the installation, do not reboot your system,
WARNING: instead use the 'request system software delete jinstall'
WARNING: command as soon as this operation completes.
Saving package file in /var/sw/pkg/jinstall-9.1-20081002.0-domestic-signed.tgz ...
Saving state for rollback ...
Rebooting lcc0-re0
Rebooting lcc2-re0
Rebooting scc-re0
{master}
regress@anatole>
*** FINAL System shutdown message from user@router ***
System going down IMMEDIATELY
When you complete the software installation and
reboot the TX Matrix platform, all T640 routing nodes also reboot
and all devices in the routing matrix execute the new software.
To upgrade the backup Routing Engines, log in to
the backup Routing Engine on the TX Matrix platform before you issue
the request system software add command.
You can also update the software on the TX Matrix
platform only or on a specific T640 routing node as needed by including
the lcc or scc option.
Note:
The master Routing Engines in all components of
a routing matrix must run the same version of software in order to
operate. As a result, we recommend that you upgrade all components
simultaneously and upgrade individual components only in rare cases.
Note:
We recommend you run the same JUNOS software release
on the master and backup Routing Engines on all components of a routing
matrix. If you elect to run different JUNOS software releases on the
Routing Engines, a change in Routing Engine mastership can cause one
or all T640 routing nodes to be logically disconnected from the TX
Matrix platform. It is also a best practice to make sure that all
master Routing Engines are re0 and all backup Routing Engines are
re1 (or vice versa).
Note:
You must use the same Routing Engine model in all
LCC and SCC components of a routing matrix. For example, a routing
matrix with an SCC using an RE-A-2000 and an LCC using an RE-1600
is not supported.
Managing System Processes in the Routing Matrix
Some system processes in a routing matrix run on
the TX Matrix platform and some run on the T640 routing nodes. For
example, the routing protocol process (rpd) runs exclusively on the
TX Matrix platform. To restart the routing protocol process for the
entire routing matrix, issue the restart routing command
on the TX Matrix platform.
user@router> restart routing ?
Possible completions:
<[Enter]> Execute this command
gracefully Gracefully restart the process
immediately Immediately restart (SIGKILL) the process
logical-system Name of logical system
soft Soft reset (SIGHUP) the process
| Pipe through a command
Other processes run on both the TX Matrix platform
and the T640 routing nodes. To restart the chassis process that manages
PICs, FPCs, and other hardware components, issue the restart chassis-control command on the TX Matrix platform and select the all, all-lcc, or lcc lcc-number option.
user@router> restart chassis-control
?
Possible completions:
<[Enter]> Execute this command
all Restart software process on all chassis all-lcc Restart software process on all LCC chassis
gracefully Gracefully restart the process
immediately Immediately restart (SIGKILL) the process
lcc Restart software process on specific chassis (0..3)
soft Soft reset (SIGHUP) the process
| Pipe through a command
To restart the Simple Network Management Protocol
(SNMP) process, issue the restart snmp command on the TX
Matrix platform and select the all, all-lcc, or lcc lcc-number option.
user@router> restart snmp ?
Possible completions:
<[Enter]> Execute this command
all Restart software process on all chassisall-lcc Restart software process on all LCC chassis
gracefully Gracefully restart the process
immediately Immediately restart (SIGKILL) the process
lcc Restart software process on specific chassis (0..3)
soft Soft reset (SIGHUP) the process
| Pipe through a command
Rebooting and Halting Routing Matrix Components
You can control which component in a routing matrix
is rebooted or halted. If you reboot or halt the TX Matrix platform,
by default you also reboot or halt the master Routing Engines on all
T640 routing nodes. To reboot a specific component, issue the request system reboot command with the all-lcc, lcc, or scc option.
user@router> request system reboot ?
Possible completions:
<[Enter]> Execute this command
all-lcc Reboot all LCC chassis
at Time at which to perform the operation
in Number of minutes to delay before operation
lcc Reboot LCC (0..3)
media Boot media for next boot
message Message to display to all users
scc Reboot SCC chassis
| Pipe through a command
user@router> request system reboot
Reboot the system ? [yes,no] (no) yes
Rebooting lcc0-re0
Rebooting lcc1-re0
Similarly, to halt a specific component in a routing
matrix, issue the request system halt command with the all-lcc, lcc, or scc option.
Caution:
Before entering this command, you must have access
to the TX Matrix console port and the console ports of all of the
LCCs in order to bring up the TX Matrix Routing Engines.
user@router> request system halt ?
Possible completions:
<[Enter]> Execute this command
all-lcc Halt all LCC chassis
at Time at which to perform the operation
both-routing-engines Halt both Routing Engines
in Number of minutes to delay before operation
lcc Halt LCC (0..3)
media Boot media for next boot
message Message to display to all users
scc Halt SCC
| Pipe through a command
Issuing the request system halt both-routing-engines command on a TX Matrix platform halts both Routing Engines in the
TX Matrix platform and both Routing Engines in all T640 routing nodes
in the routing matrix. 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.
Enabling and Disabling Specific Routing Matrix Hardware Components
You can temporarily disable certain hardware components
(such as FPCs, PICs, and SIBs) that belong to the TX Matrix platform
and T640 routing nodes in the routing matrix. To do so, issue the
appropriate request chassis command and include the lcc or scc option as needed.
Note:
If you issue a chassis-related command that references
FPCs, we recommend that you use the FPC hardware slot number (0 through
7) of the specific T640 routing node and specify its corresponding
LCC number.
user@router> request chassis ?
Possible completions:
cb Change Control Board status
fpc Change Flexible PIC Concentrator status
fpm Change craft interface status
lcc Change LCC status
pic Change Physical Interface Card status
routing-engine Change Routing Engine status
scg Change SONET Clock Generator status
sib Change Switch Interface Board status
spmb Change Switch Processor Mezzanine Board status
user@router> request chassis fpc ?
Possible completions:
lcc Slot number of LCC that houses FPC (0..3)
offline Take FPC offline
online Bring FPC online
restart Restart FPC
slot FPC slot number (0..31)
user@router> request chassis pic ?
Possible completions:
fpc-slot Slot number of FPC that houses PIC (0..31)
lcc Slot number of LCC that houses FPC (0..3)
offline Take PIC offline
online Bring PIC online
pic-slot PIC slot number (0..3)
user@router> request chassis sib ?
Possible completions:
lcc Change Switch Interface Board status (0..3)
offline Take SIB offline
online Bring SIB online
scc Change Switch Interface Board statusslot SIB slot number (0..4)
start-receiver Start SIB optical receiver (0..3)
stop-receiver Stop SIB optical receiver (0..3)
The routing matrix extends the concept of taking
specific hardware components offline or online to include an entire
T640 routing node in a routing matrix. To enable or disable a T640
routing node in a routing matrix, issue the request chassis lcc
slot lcc-number (offline | online) command.
user@router> request chassis lcc ?
Possible completions:
offline Take LCC offline
online Bring LCC online
slot LCC Slot (0..3)
Although you can enter the routing matrix-based
slot number when you issue the request chassis fpc command,
output from show chassis commands always references the FPC
hardware slot number (0 through 7) of the specific T640 routing node
and its corresponding LCC number. As a result, we recommend that you
include the FPC hardware slot number when you issue request chassis or show chassis commands, as shown in the following example:
First, issue the request chassis fpc command
with the routing matrix-based FPC slot number of 19:
user@router> request chassis fpc offline
slot 19
lcc2-re0:
--------------------------------------------------------------------------
Offline initiated, use "show chassis fpc" to verify
However, when you issue the show chassis fpc command to check the result, the output displays the change using
node-centric terminology: FPC slot number 3 on T640 routing
node LCC2 (the equivalent of routing matrix slot 19).
lcc2-re0:
--------------------------------------------------------------------------
Online initiated, use "show chassis fpc" to verify
Once you bring the FPC back online, reissue the show chassis fpc command to see that the FPC slot and LCC number
you used in the last command now matches the command output:
Managing Files on Routing Engines in a Routing Matrix
You can manage files on all Routing Engines in
a routing matrix. For example, you can copy a file from the master
Routing Engine in the TX Matrix platform to the master Routing Engine
on a T640 routing node.
user@router> file list lcc0-re0:
/var/home/user/lcc0-re0: No such file or directory
user@router> file list
/var/home/user/:
.ssh/
fred.txt
user@host> file copy fred.txt lcc0-re0:fred.txt
user@host> file list lcc0-re0:
lcc0-re0:
--------------------------------------------------------------------------
/var/home/user/:
.ssh/
fred.txt
