Can I see the pending (commit at) changes on a JunOS box?

Question

If an engineer configures some changes in a JunOS box and then set them to go live later, that effectively locks the config database with a configure exclusive. How can I see the changes that he or she has committed?

score 32 · Accepted Answer · edited May 08 '13 at 15:34

32

I think, you can use show | compare from configuration mode.

edited May 08 '13 at 15:34

Oluf Lorenzen

2
6

answered May 08 '13 at 03:02

Pavel Glushkov

536
4
6

1

Sometimes I think I'm so smart, and then I'm brutally proven wrong. This is so much cleaner than the answer I came up with (couldn't answer the question due to low reputation score). I'm so used to using configure private, it didn't even occur to me not to bloody put private on the end. Thanks for the answer that is far better than my solution. – hrtednrup May 08 '13 at 03:23
1

I may be able to save a bit of face here. When dealing with a cluster of SRXs, for example, common configure mode is not available. In this case, show | compare doesn't work. – hrtednrup May 08 '13 at 04:35
"show | compare" from configure mode is the only way to see staged changes for the normal "shared" or "exclusive" modes. This comes with the caveat that all users be operating on the same Routing Engine / CPU / box. In a clustered SSH configuration, ideally you should always be logging into whatever unit is "active". I generally see this done by setting up a loopback interface and logging into a DNS name that points there. – jof May 08 '13 at 08:18
2

show | compare works just fine on my SRX clusters. I am generally not using fxp interface for management though, I have a separate reth interface for management. logging in through that make sure you always end up on the active routing engine. – cryptochrome May 09 '13 at 17:17
2

You can run `show conf | compare` while not in configure mode. – bahamat Sep 07 '14 at 17:19

hrtednrup · Answer 2 · 2013-12-05T18:34:18.783

In cases where common configure mode is unavailable, like when the chassis are clustered, you can use the following method.

After executing a commit at, JunOS checks the config and creates the file /config/juniper.conf+.gz. The running config database is locked until the commit at time, so other users won't be able to commit interim changes. Other users can delete pending changes with the clear system commit command. This will unlock the running config database and allow for other commits; however, the original user may be a bit upset at his or her changes not going in.

If you want to see what the differences between the pending config file and the current running config, perform the following:

configure private
load replace /config/juniper.conf+.gz
show | compare

JunOS will output the patch-style text of the changes in the pending commit. After doing whatever work you need to complete during the pending commit, you can paste that back in with a load patch terminal (or pipe to another file), and the original commit at user will be much happier.

Edit: If you seem to be forced into a private edit mode, as might be the case in a chassis cluster:

user@SRX3600> configure 
warning: Clustering enabled; using private edit
warning: uncommitted changes will be discarded on exit
Entering configuration mode

{primary:node1}[edit]

you can use

configure shared
show | compare

That seems to work just fine and skirts that nasty issue of being forced into private config mode. configure shared is a hidden commmand

score 3 · Answer 3 · edited Dec 05 '13 at 13:03

show configuration | compare rollback <rollback-number>

Command output would be as below:

admin@NICFW1# run show configuration | compare rollback 2    
[edit applications application MORTIMERHARVEY]
     term WWW_TCP_2131 { ... }
+    term WWW_TCP_65000 protocol tcp destination-port 65000-65050;

{primary:node0}[edit]
admin@NICFW1# run show configuration | compare rollback 3    
[edit security policies from-zone Internet to-zone Corporate policy InternetPortals match]
-      application [ junos-http junos-https ];
+      application [ junos-http junos-https MORTIMERHARVEY ];
[edit applications application MORTIMERHARVEY]
     term WWW_TCP_2131 { ... }
+    term WWW_TCP_65000 protocol tcp destination-port 65000-65050;

In the above e.g. + represents the config that has been added and - represents the config that has been deleted.

If you are forced into a configure private mode, as is the case with chassis clustering (at least as of 11.4R6.5), you cannot compare your candidate config with the running config. The candidate config is a copy of the running config, so comparing the two won't show any differences. — hrtednrup, Dec 05 '13 at 17:16

score 1 · Answer 4 · answered Sep 12 '16 at 06:51

commit | compare

I always use this to see the prior versus the new config, also using commit confirm 1 or other arbitrary value can save you from mistakes and rollback when the value expires if necessary. For example the 1 after confirm is 1 minute..after that if not confirmed it will rollback the changes made.

c-tsmith@COSMO_CORPDC_EX45_00# commit | ?
Possible completions: count Count occurrences display Show additional kinds of information except Show only text that does not match a pattern find Search for first occurrence of pattern hold Hold text without exiting the --More-- prompt last Display end of output only match Show only text that matches a pattern no-more Don't paginate output request Make system-level requests resolve Resolve IP addresses save Save output text to file trim Trim specified number of columns from start of line

There is an example from one of our switches without the output for comparison.

Can I see the pending (commit at) changes on a JunOS box?

4 Answers4