Hello,
To add to what's been already covered - "commit check" runs the commit
scripts as if it is an actual commit.
And You can do pretty much everything with commit scripts, including
logging to another node and comparing/changing the config there.
One use case is to keep DetNAT pools & prefix-lists synced between 2
CGNAT nodes in case inter-node failover happens. So if You want to
always make changes on 1 such node only, and never bother with manually
checking config consistency, then use a commit script which logs in to a
neighbor node and does comparison and maybe fixes some trivial
discrepansies. In this case, You want to run "commit check" first, to
get 2nd node changed, and then "commit comment" to get 1st node aligned
with the 2nd.
HTH
Thanks
Alex
On 28/09/2015 22:24, Martin T wrote:
Hi,
when I commit the candidate configuration in Junos, I tend to execute
"commit check" and if configuration check succeeds, then I execute
"commit comment <COMMENT>". However, when I think about it, "commit
(comment)" itself should perform those very same checks that "commit
check" does. If yes, then what is the point of "commit check"? Only
purpose I could see is to check the validity of the candidate
configuration in the middle of the configuration process, i.e. to
check if the changes made in candidate configuration so far are fine
but the candidate configuration is not ready to be committed.
thanks,
Martin
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
