node – Networks and rants

The other day I got a problem with one of my SRX clusters when I was running a commit. The commit was not able to complete and I got the following error:

{primary:node0}[edit]
srx1400# commit
node1:
error: configuration database modified
node0:
error: remote lock-configuration failed on node1

The reason for this error is some uncommited configuration on the secondary node. Earlier the same day I changed the primary for redundancy-group 0 and I guess that I didn’t commit all the config on node1 before changing to node0.

To solve this I had to go into the secondary node (node1) and rollback the uncommitted configuration. Normally you can use OOB to connect to the secondary node but I dont have it at this location. So I have to connect to the secondary node trough the primary node. This is done with the following command on branch devices (SRX650 and below): request routing-engine login node 1
On High end devices like the one I’m working on (SRX1400 and above) you use: rlogin -T node1

{secondary:node1}% rlogin -T node1
root@srx1400>
--- JUNOS 11.4R9.4 built 2013-08-22 06:24:21 UTC
{secondary:node1}
root@srx1400> configure
warning: Clustering enabled; using private edit
error: shared configuration database modified

Please temporarily use 'configure shared' to commit
outstanding changes in the shared database, exit,
and return to configuration mode using 'configure'

As you can see from the error I have to use configure shared to be able to edit the configuration.

root@srx1400> configure shared
Entering configuration mode
The configuration has been changed but not committed

Before entering the rollback command you can check the uncommitted configuration by running show | compare. This will display all the uncommited configuration

{secondary:node1}[edit]
root@srx1400# show | compare
[edit access profile unos clientjunos]
- pap-password "$9$2V4GDikP5T3fTrvLXwsz36C0B"; ## SECRET-DATA
+ pap-password "$9$jhHP5QF/CA09AxdsYGUp0BRyl"; ## SECRET-DATA

Now you can rollback the uncommited config, check that there is any uncommited config left and exit the configuration mode.

{secondary:node1}[edit]
root@rx1400# rollback
load complete

{secondary:node1}[edit]
root@srx1400# show | compare

{secondary:node1}[edit]
root@srx1400# exit
Exiting configuration mode

{secondary:node1}
root@srx1400>

Now you can close the session and try to commit the configuration from the primary node again. It worked for me! 🙂

As a note I also know that alot of people has had a success of using just the command commit synchronize force on the primary node but it does not work for everyone.

Today I had some issues when working on a SRX650. We had to replace the Services and Routing Engine a few days ago. When I was supposed to get the cluster back online I got the following error message when trying to run a few of the commands on the device:

Could not connect to node1 : No route to host

I got this error when typing show interface ge-0/0/2. I also entered the command on the node1 so I felt it was a bit strange that node1 could not connect to node1.

The firewall was also saying that it was in a hold mode

{hold:node1}

So it was not showing as secondary or primary. It was keeping this status all the time and didn’t try to go to any other modes while the issue was occuring.

The reason for my issues was that I had not deleted all the default config from the new Service and Routing engine card that we got. My config was not correct for all the cluster ports since some of the ports in the cluster is dedicated to cluster services (on the SRX650 it is ge-0/0/0 (fxp0) and ge-0/0/0 (control plane)). These ports are not to be configured as network ports and that is the reason for my issues. When I deleted the config and set a default root authentication password everything was connected. When I did a commit from the primary node the config was correct on both devices and everything connected succesfully.

During my search on the internet I read that some people also forgot to set the reth-count and got the same error. The command to set the number of reth interfaces is:

set chassis cluster reth-count 4

A great source for more information is the following chapter of the book “Juniper SRX Series” written by Brad Woodberg and Rob Cameron.

http://chimera.labs.oreilly.com/books/1234000001633/ch07.html#activating_juniper_services_redundancy

Tag: node

Secondary node locked when commiting

Could not connect to node1 : No route to host