Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TX Matrix Software and CLI Overview

 

TX Matrix Software

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.

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.

For more information about routing matrix configuration, see the Routing Matrix with a TX Matrix Router Deployment Guide.

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.

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, see Performing the Initial Software Configuration for the TX Matrix Router and the Routing Matrix with a TX Matrix Router Deployment Guide.

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.