With netscreen background I know if secondary node was disabled or out of network due to any reason and we do some configuration changes on primary node. After that if secondary node joins the cluster then we have to manually synchronize the configuration using "exec nsrp sync global-config saved" on backup node.
What is the procedure to sychronize the configuration on secondary node from primary node in SRX chassis cluster?
The only way to recover for node1 from disable situation is reboot.
I am asking how to synchronize the configuration between nodes.
When there is proper chassis cluster between node0 and node1.
You can do commit synchronize or commit full on primary node to synchronize the configuration and if still doesn't work just do a dummy config like interface description or anything dummy config in primary node and do commit.
You can verfiy the config line between two nodes via below command
root#show | display set | count<<<<<<execute command on both nodes and count the config lines...it should be the same until and unless there is no local config on any of the nodes.
I hope this helps.
This is what I was looking for. Thanks. Just one more thing if both nodes have some how different configurations and we make a cluster then I want to to have configuration of primary node on both nodes then what I need to do? Actually I want to understand that always configuration from primary to secondary node synchronize? OR it depends on which node we are and doing commit full, means if I do the commit full on secondary then configuration from secondary node to primary node syn and vice versa?
As long as your chassis cluster is established properly and control probes are reaching both nodes then you should be fine. Run the following command to confirm if control plane is working fine;
# run clear chassis cluster control-plane statistics
# ...is cluster control-plane statisticsControl link statistics:Control link 0:Heartbeat packets sent: 3Heartbeat packets received: 3Heartbeat packet errors: 0Fabric link statistics:Probes sent: 3Probes received: 3Probe errors: 0
If the probes are not being recieved and sent properly then your devices may be acting out of sync.
When you log on to a device and make changes, it initially makes a copy of the configuration that is local to itself. We call it "candidate configuration". When you commit it from either node, it will try to push the candidate configuration to BOTH nodes via control link using JSRPD. Obviously if the link is broken the the configuration will only be committed to the local node only.
Let's say you had a working cluster and then you detached the nodes i.e. disconnected the control link and fabric link as well. Now both nodes are acting as primary (Split-brain). You make some minor changes to the configuration on one of the nodes. But both nodes still remain in the same cluster-id. So when you connect them back together by joining the control and fabric links then the node that becomes primary will drive the configuration. The primary node configuration will override the secondary node configuration. So no matter where you are committing from, it will be the same configuration on two devices as long as your control and fabric links are up.
Hope that helps.
Thanks for the reply. As you wrote "The primary node configuration will override the secondary node configuration. So no matter where you are committing from, it will be the same configuration on two devices as long as your control and fabric links are up"
What I am experiencing in lab testing. If we detached the nodes. I did some configuration changes on secondary node. then again secondary node join the cluster with same cluster-id. Now when I am doing commit full on primary node then primay configurations are pushed to secondary node BUT when I repeated the same activity and doing commit full from secondary node then secondary node configuration is pushed to primary node. So I am not sure what is correct?
I guess it needs a bit more explanation.
What happens when you connect the two nodes with different configuration for the first time? Whose configuration takes over without doing any commit or commit-full? You have to notice that after the chassis cluster has decided on the primary/secondary status? Once the sync-up finishes, what do you see?
Now once the status is adjusted from two primaries to one primary and one secondary, the configuration should only be a single configuration. After that no matter which node you commit from, the config will remain synched up.
I am thinking when you did a commit-full from secondary-node the auto sync up process hadn't finished. How lond did you wait. Make sure you run the "show chassis cluster information detail" command to see the cold-sync happen before you do the commit.
Even after all the above constraints, if your answer is still the same, then I will test it out in my lab and find the correct behavior for you.
Thanks for the reply. When secondary node joins the cluster (assume it has some different configuration as compare to primary), and show chassis cluster status showing correct status means node0 as primary and node1 as secondary then one time I did the commit full from primary and repeating the same activity one time I did the commit full from secondary node. I am experiencing the same thing that if I commit from the primary node then configuration of primary is synchronized and If I commit from the secondary node then configuration of secondary is synchoronzed.
So I am confused. I would appreciate if you can do some testing in your lab.
I'm bit confused on which link config synchroziation happen, Is control link used for config sync or fab link?
Control link is used for configuration sync: