TX Matrix Software and CLI Overview
TX Matrix Software
The TX Matrix router runs the same Junos OS that runs on all Juniper Networks J-series, M-series, MX-series, and T-series routing routers. Familiarity with the Junos OS and its CLI allow you to quickly and easily configure and operate the routing matrix.
From the perspective of the user interface, the routing matrix appears as a single routing router. This means that the configuration file on the TX Matrix router is used for the entire routing matrix. When you commit the configuration on the TX Matrix master Routing Engine, the changes are automatically propagated to all master Routing Engines in all T640 routers. If you issue the commit synchronize command, you commit the configuration to all master and backup Routing Engines in the routing matrix.
For more information about software installation, see the Junos System Basics Configuration Guide. For more information about routing matrix configuration, see the Junos Feature Guide.
Configuring Specific Chassis Features
You can configure PIC-specific features, such as SONET/SDH framing, for specific T640 routers within the routing matrix. To do so, include the lcc lcc-number statement at the [edit chassis] hierarchy level, and specify the chassis-specific feature to configure.
Following is a list of PIC-specific configuration statements that must be configured for specific T640 routers within the routing matrix:
- atm-cell-relay-accumulation
- atm-l2ciruit-mode
- framing
- idle-cell-format
- max-queues-per-interface
- no-concatenate
 | Note: When you include statements at the [edit chassis lcc lcc-number] hierarchy level, specify the actual FPC hardware slot number as labeled on the T640 router. Do not use the routing matrix-based FPC number shown in FPC Slot Number Correspondence. |
If you include configuration statements at the [edit chassis] hierarchy level, these statements are applied to the TX Matrix chassis and all T640 chassis in the routing matrix.
By default, the Junos OS allows all T640 routers in the routing matrix to come online. Optionally, you can configure the TX Matrix router to generate an alarm if the T640 routers in the routing matrix do not come online. To configure, include the online-expected statement at the [edit chassis lcc lcc-number] hierarchy level on the TX Matrix router.
If you do not want a T640 router to be part of the routing matrix, you can configure it to be offline. This is useful when you are performing maintenance on a T640 router. To configure a T640 router so that it is offline, include the offline statement at the [edit chassis lcc lcc-number] hierarchy level.
When you are ready to bring the T640 router back online, delete the offline configuration statement at the [edit chassis lcc lcc-number] hierarchy level.
| Note: If you do not configure the online-expected or offline statement, any T640 router that is part of the routing matrix is allowed to come online. However, if a T640 router does not come online, the TX Matrix router does not generate an alarm. |
For more information about chassis-specific statements, see the Junos System Basics Configuration Guide.
Configuration Groups
Configuration groups allow you to create a group containing configuration statements (by including the groups statement) and to direct the inheritance of that group's statements in the rest of the configuration. The configuration groups offer a simple way to establish hostnames, management interfaces, and default routes. You can also specify two special group names—re0 and re1. These two special group names apply to the Routing Engines in slots 0 and 1 of the TX Matrix router. In addition, the TX Matrix router supports group names for the Routing Engines in each T640 router in the following formats:
lcc-number identifies the T640 router and can be from 0 through 3. For example, to configure Routing Engine 1 properties for lcc3, you include statements at the [edit groups lcc3-re1] hierarchy level.
You must include the apply-groups statement in the configuration for all special groups, including re0 and re1.
Providing special group names for all Routing Engines in the routing matrix allows you to configure the individual Routing Engines in each T640 router differently. Parameters that are not configured at the groups hierarchy level apply to all Routing Engines in the routing matrix.
For more information about configuring the TX Matrix router, seePerforming the Initial Software Configuration for the TX Matrix Router and the Junos OS configuration guides.
PIC MAC Addresses
When you integrate a T640 router into a routing matrix, the PIC media access control (MAC) addresses for the T640 router are derived from a pool of MAC addresses maintained by the TX Matrix router. This means the PIC MAC addresses used in the formerly standalone T640 router are changed after the T640 router is integrated into a routing matrix. To determine the newly assigned MAC address for an interface on a PIC in an integrated T640 router, issue the show interfaces interface-name command.
Running Different Junos OS Releases on the Routing Engines
We recommend that you run the same Junos OS release on the master and backup Routing Engines. However, if you elect to run different Junos OS releases on the Routing Engines, all Routing Engines on the same control plane must run the same Junos OS release (All master Routing Engines in the TX Matrix router and T640 routers are on one control plane; all backup Routing Engines are on another control plane [see Routing Matrix Routing Engine Connections].) If you or a host subsystem initiates a change in mastership to any backup Routing Engine in the routing matrix, be aware of the following:
- If the on-loss-of-keepalives statement is included
at the [edit chassis redundancy failure] hierarchy level,
consider the following:
- If you or a host subsystem initiates a change in mastership to the backup Routing Engine in the TX Matrix router, the master Routing Engines in the T640 routers detect a software release mismatch with the new master Routing Engine in the TX Matrix router and switch mastership to their backup Routing Engines.
- If you attempt to initiate a change in mastership to a backup Routing Engine in a T640 router, the new master Routing Engine in the T640 router detects a software release mismatch with the master Routing Engine in the TX Matrix router and relinquishes mastership to the original master Routing Engine. (Routing Engine mastership in the TX Matrix router does not switch in this case.)
- If a host subsystem initiates a change in mastership to a backup Routing Engine in a T640 router because the master Routing Engine has failed, the T640 router is logically disconnected from the TX Matrix router. To reconnect the T640 router, initiate a change in mastership to the backup Routing Engine in the TX Matrix router, or replace the failed Routing Engine in the T640 router and switch mastership to it. (The replacement Routing Engine must be running the same software release as the master Routing Engine in the TX Matrix router.)
- If the on-loss-of-keepalives statement is not
included at the [edit chassis redundancy failure] hierarchy
level, consider the following:
- If you initiate a change in mastership to the backup Routing Engine in the TX Matrix router, all T640 routers are logically disconnected from the TX Matrix router. To reconnect the T640 routers, switch mastership of all master Routing Engines in the T640 routers to their backup Routing Engines.
- If you initiate a change in mastership to a backup Routing Engine in a T640 router, the T640 router is logically disconnected from the TX Matrix router. To reconnect the T640 router, switch mastership of the new master Routing Engine in the T640 router back to the original master Routing Engine.
If you run the same Junos OS release on all master and backup Routing Engines in the routing matrix, a change in mastership to any backup Routing Engine in the routing matrix does not cause a change in mastership in any other chassis in the routing matrix.
