Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Committing Configurations on a Routing Matrix with a TX Matrix Plus Router

 

On a routing matrix with a TX Matrix Plus router, you must commit configuration changes on the TX Matrix Plus router (also referred as SFC) rather than on the individual T1600 or T4000 routers. All configuration changes you commit on the SFC are distributed to all the T1600 or T4000 routers in the routing matrix and override any configuration changes committed directly on a T1600 or T4000 router.

Note

If you commit a configuration directly on a T1600 or T4000 router in a routing matrix, the configuration is not distributed to the SFC or to the other T1600 or T4000 routers in the routing matrix.

There are three main ways to commit configurations on a TX Matrix Plus router:

Committing a Configuration to Both Master and Backup Routing Engines in the Routing Matrix

To commit the same configuration to both the master and backup Routing Engines in the routing matrix, issue the commit operational command with the synchronize option.

The Routing Engine on which you execute the commit synchronize command (the requesting Routing Engine) copies and loads its candidate configuration to the other Routing Engine (the responding Routing Engine). Both Routing Engines then perform a syntax check on the candidate configuration file being committed. If no errors are found, the configuration is activated and becomes the current operational configuration on both Routing Engines.

The commit synchronize command makes the active or applied configuration the same for both Routing Engines with the exception of two special configuration groups for Routing Engines:

  • Configuration statements specified in the re0 configuration group are applied only to Routing Engines in slot 0 (designated re0).

  • Configuration statements specified in the re1 configuration group are applied only to Routing Engines in slot 1 (designated re0).

Note

If you do not synchronize the configurations between two Routing Engines and one of them fails, the router may not forward traffic correctly because the backup Routing Engine may have a different configuration.

The following example shows command output for the commit command issued on the TX Matrix Plus router with the synchronize option:

[edit groups]


user@host# set re0 system hostname sfc0–re0–hostname
user@sfc0–re0–hostname#commit synchronize;

It can happen that the commit synchronize command is initiated at the same time from both Routing Engines, which causes the process to hang. For example, suppose you had the following configuration in combination with nonstop active routing (NSR):

With NSR enabled, both Routing Engines run rpd and both notice the rpd_bgp_neighbor_state_changed event. Prior to Junos OS Release 15.1, in this situation, both Routing Engines tried to lock the configuration and execute a synchronous commit. The action hung while each Routing Engine tried to obtain a configuration database lock from the other, and the CLI became unresponsive for an extended period of time (at least for one hour). As of Junos OS Release 15.1, to handle unresponsiveness, the system waits 20 seconds for the database lock. if in that time interval the lock cannot be taken, control is returned with the following error messages:

This message indicates that the database lock is temporarily not available due to internal system conditions; the user can retry the commit synchronize process after several seconds.

Committing a Configuration to the Master Routing Engines (Only) in the Routing Matrix

In a routing matrix with a TX Matrix Plus router, issuing the basic form of the commit operational command on the TX Matrix Plus router commits the candidate configuration only to the master Routing Engines in the routing matrix.

The following example shows command output for the basic form of the commit command:

user@host# commit

Synchronizing to the Configuration on the Other Routing Engine

In a routing matrix with at TX Matrix Plus router, issuing the commit synchronize command with the force option directs one Routing Engine to synchronize its configuration with the other.

Note

We recommend that you use the force option only if you are unable to resolve the issues that caused the commit synchronize command to fail.

The Routing Engine on which you issue this command (the requesting Routing Engine) copies and loads its candidate configuration to the other Routing Engine (the responding Routing Engine). Both Routing Engines then perform a syntax check on the candidate configuration file being committed. If no errors are found, the configuration is activated and becomes the current operational configuration on both Routing Engines.

The commit synchronize command does not work if the responding Routing Engine has uncommitted configuration changes. However, you can enforce commit synchronization on the Routing Engines by using the force option.

Note

When you issue the commit synchronize command with the force option from one Routing Engine, the configuration sessions on the other Routing Engine will be terminated and its configuration synchronized with that on the Routing Engine from which you issued the command.