By hand
The old way: you log in to each switch over SSH (a secure remote login) and type the same commands. Four switches means typing it all four times. Real networks have hundreds.
On switch 3 you typed VLAN 200 instead of 20. Now it quietly differs from the others, and nobody notices until something breaks. Switches slowly stopping matching is called config drift.
Config as code
Automation starts by writing down what you want, not the commands to get there. A variables file lists each switch's name and address, and the VLANs every switch should have. This is the desired state.
A template is the config with blanks, like {{hostname}}. The tool fills the blanks from the variables, once per switch. One template, four configs that differ only where they should.
Tools and switches agree on the shape of a config using YANG data models (RFC 7950). A model names each setting, like a VLAN's id and name, and its rules, like id 1 to 4094. Tools set fields, not typed text.
Save and test
The files live in version control, such as Git. Every saved change is a commit: who changed what, when and why. Adding guest VLAN 30 becomes commit v2, next to v1.
Before anything touches a switch, tests check the four new configs. Is every VLAN id between 1 and 4094? Is every name and address unique and in the right network? All four configs pass.
Push and roll back
The tool sends each switch its config through an API: NETCONF (RFC 6241) over SSH or RESTCONF (RFC 8040) over HTTPS. Each switch changes only what differs, so switch 3's typo is fixed too.
Run the very same push again. Every switch already matches, so nothing changes: 0 edits. Doing it twice gives the same result as doing it once. That is idempotence, and it makes pushes safe to repeat.
Commit v3 tidies up the VLAN list and deletes VLAN 20 by mistake. It breaks no test rule, so it is pushed. A check after the push finds that the servers' VLAN is gone.
The history still holds v2, the last good version. A revert saves it again as commit v4, and the same push puts VLAN 20 back on all four switches. The check passes in minutes.
The files and the switches
;; step 1/11 · by-hand · packet ;; laptop → sw4 you 192.168.1.10 → .11 .12 .13 .14 (ssh) typed 4 lines × 4 switches = 16 lines, by hand hostname sw1 management-address 192.168.1.11/24 vlan 10 name staff vlan 20 name servers the same work, again and again, by a tired human
The config lines here are neutral example syntax, not any vendor’s commands. Real tools render the same idea into each vendor’s format, or send YANG data directly. NETCONF runs over SSH on port 830 (RFC 6242). RESTCONF is the same YANG data over HTTPS (RFC 8040). Both can also be used to read the current config, which is how drift is found. NETCONF can also roll back by itself: with a confirmed commit, a switch undoes the change unless it is confirmed in time, by default within 600 seconds (RFC 6241 §8.4).