show configuration and compare — inspecting the candidate without leaving it

The two commands that read the candidate configuration without changing it are the operator’s review surface: show to print nodes and leaves, compare to see what would change on commit. Mastering them is what separates an operator who can make changes from an operator who can defend them.

show — printing the candidate

[edit]
vyos@vyos# show system
 host-name router-core-01
 login {
     user vyos {
         authentication {
             encrypted-password "$6$xxxx$yyyy"
             public-keys operator@laptop {
                 key "ssh-ed25519 AAAA..."
                 type ssh-ed25519
             }
         }
     }
 }
 name-server 192.0.2.53
 name-server 198.51.100.53

show from the root prints the entire candidate tree in config-file syntax. show <path> prints the subtree starting at the given path. From inside a scope (edit protocols bgp), show is relative to the current node.

Note what the password leaf is called. You type plaintext-password; commit hashes it and what you read back afterwards is encrypted-password. show prints the tree as it now stands, not the command you typed to build it.

[edit]
vyos@vyos# show interfaces ethernet eth0
 address 192.0.2.1/24
 description OUTSIDE
 hw-id 52:54:00:12:34:56
 mtu 1500

compare — the diff to the running

[edit]
vyos@vyos# compare
+ interfaces {
+     ethernet eth0 {
+         address 192.0.2.1/24
+     }
+ }
+ protocols {
+     bgp {
+         system-as 64512
+         neighbor 192.0.2.2 {
+             remote-as 64512
+         }
+     }
+ }

compare shows the difference between the candidate and the running configuration, in the same braced syntax show uses rather than as a flat list of paths. Every + line is one the commit would add and every - line is one it would remove. There is no separate “modified” marker: changing a leaf’s value appears as a - for the old value and a + for the new one.

That braced shape is worth noticing, because it means the container lines around a change are part of the diff too. A one-leaf change inside a deeply nested path prints several lines, and the line that matters is the innermost one.

compare takes arguments:

[edit]
vyos@vyos# compare saved
[edit]
vyos@vyos# compare 1

compare saved diffs the candidate against /config/config.boot — what has drifted since the last save, which is not the same question as what this session changed. compare <revision> diffs against a stored commit revision; run show system commit lists the revisions and their numbers, with 0 as the most recent commit.

Filtering with match

[edit]
vyos@vyos# show | match address
 address 192.0.2.1/24
 address 192.0.2.2/24
 address 192.0.2.3/24

match keeps only the lines matching the pattern, and the pattern is a regular expression rather than a literal string — . matches any character, * repeats the previous element, [abc] is a character class.

The candidate as set lines

[edit]
vyos@vyos# show | commands
set system host-name 'router-core-01'
set system login user vyos authentication encrypted-password '$6$xxxx$yyyy'
set system login user vyos authentication public-keys operator@laptop key 'ssh-ed25519 AAAA...'
set interfaces ethernet eth0 address '192.0.2.1/24'
set protocols bgp system-as '64512'
set protocols bgp neighbor 192.0.2.2 remote-as '64512'

show | commands prints the candidate in set form rather than braced form — the shape you paste into a change record, a peer review, or another router. An auditor can replay the whole configuration by running the lines in order.

Two things to read in that output. The password leaf is encrypted-password, because commit hashed the plaintext one you typed. And the local AS is set protocols bgp system-as, with the peer on its own line under set protocols bgp neighbor — the 1.5 shape. A change record produced on a 1.3 router will not paste into a 1.5 one, and this is the output where you find that out cheaply rather than at commit on the far side.

From operational mode the equivalent is show configuration commands, which reports the running configuration rather than the candidate. Same format, different question — and reaching for the operational one while you are mid-edit is a good way to convince yourself your uncommitted work has vanished.

Reading the running configuration from the operational shell

vyos@vyos:~$ show configuration
interfaces {
    ethernet eth0 {
        address 192.0.2.1/24
    }
}

From the operational shell ($ prompt), show configuration reads the running configuration. From configure mode, show reads the candidate.

How the result is validated

[edit]
vyos@vyos# show | commands
[edit]
vyos@vyos# show | match 'interfaces ethernet'
[edit]
vyos@vyos# compare
[edit]
vyos@vyos# compare saved

The first two confirm the candidate is what the operator expects. compare confirms the change against the running configuration, and compare saved catches the separate problem of a router whose running configuration has drifted from what is on disk — which is what will come back after the next reboot.

How it fails

The production failure modes the engineer must recognise:

• show after set but before commit shows the new value. The operator believes the change is live; the running configuration does not have it.
• show after discard shows nothing. The operator believes the change has been undone; the running configuration is unchanged.
• compare with no candidate changes. The operator types compare after accidentally editing the candidate twice; the diff shows no change. The operator believes nothing was edited; the candidate actually has both edits, which cancel out.
• An unescaped . in a match pattern. show | match 'eth0.10' treats the . as “any character”, so it also matches eth0-10 and eth0x10. Write eth0\.10 when you mean a literal dot. This bites hardest when the operator concludes from a match that a VIF exists.
• compare reviews intent, not effect. The diff tells you what the configuration tree will say after the commit. It does not tell you what the router will then do. A rule set that nothing jumps to, a route-map attached to no neighbour, and an interface with no cable all produce a clean, correct-looking diff. compare is the last check on the change, not the first check on the outcome — that one happens after commit, in operational mode.

Rollback

show and compare are read-only; they do not change the candidate. The rollback path is for the underlying change the operator was reviewing, not for the review commands themselves.

Production discipline

Cross-course references

The Linux course’s V-Linux-NetConfig covers the underlying configuration management. The Ansible course’s XLII-Ansible-BeyondLinux shows how to drive show/compare from Ansible with the same review workflow.

Quiz