Network automation
Typing the same config on every switch is slow, and one typo leaves a switch quietly different. Watch the same job done as code: a template and a variables file render one config per switch, version control keeps every change, tests check it, a tool pushes it over NETCONF or RESTCONF, a second push changes nothing, and a bad change is rolled back from the history.
5 quick questions
Pick an answer to see why. Your score saves with your progress.
01Switch 3 has VLAN 200 where every other switch has VLAN 20, because of a typo. What is this called?
Config drift is when devices that should match slowly stop matching, usually through small manual changes. Pushing the desired state from code removes it.
02A template says 'hostname {{hostname}}'. Where does the real name come from?
The tool fills each blank in the template from the variables, once per switch. One template plus four sets of variables gives four configs.
03You run the same push twice in a row. What happens the second time?
The push compares what each switch has with what it should have and makes only the differences. The second time there are none: 0 edits. That is idempotence.
04Commit v3 removed VLAN 20 by mistake and was pushed. What is the fastest safe fix?
Version control keeps every past version. A revert saves the last good one again as a new commit (v4), and the same push restores every switch at once.
05What do NETCONF (RFC 6241) and RESTCONF (RFC 8040) give an automation tool?
Both carry YANG-modelled config data: NETCONF over SSH (port 830), RESTCONF over HTTPS. The tool sets named fields; the switch checks them against its model.
Glossary
- Network automation
- Configuring and checking network devices with software from a description of what you want, instead of typing commands on each one.
- Desired state
- A written description of how every device should be configured. Tools make the devices match it.
- Template
- A config with blanks, such as {{hostname}}, that a tool fills in from variables, once per device.
- Config drift
- Devices that should match slowly becoming different, usually through manual changes and typos.
- YANG
- A language for data models (RFC 7950) that names each setting and its rules, so tools and devices agree on a config's shape.
- NETCONF / RESTCONF
- Protocols for reading and changing a device's config as structured data: NETCONF over SSH (RFC 6241), RESTCONF over HTTPS (RFC 8040).
- Version control
- A system such as Git that saves every change as a commit (who, what, when, why) so any old version can be brought back.
- Idempotence
- Doing an action twice has the same effect as doing it once, so a push can be safely repeated.
Notes and sources
- The switches sit on a private management network, 192.168.1.0/24 (RFC 1918). VLAN ids run from 1 to 4094; 0 and 4095 are reserved (IEEE 802.1Q).
- 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).
- HTTP defines idempotent requests the same way: repeating one has the same effect on the server as sending it once (RFC 9110 §9.2.2). A RESTCONF PUT is one.
Quiz Unlocks after the last step.