Making Configuration Changes Safely

Optional, lab-only material

Everything in this lesson is here so you understand what's possible with Netmiko — it is not part of this module's main project, and the capstone lesson does not use it. If you try any example here yourself, do it only against a disposable lab device (your own hardware, or a virtual lab like CML/GNS3/EVE-NG) that you can safely reset — never a production device, and never anything you don't fully control.

Why this is a bigger deal than a show command

Every lesson so far in this module has been read-only: send_command() asks a device a question and gets an answer back. Nothing about the device changes. send_config_set() is different — it actually modifies the running configuration. Get a show command wrong and you waste a moment re-running it. Get a configuration push wrong and you may have just changed how a production network behaves.

This is exactly what 'Idempotency' and 'Validation, Safety & Failure Handling' were preparing you for

Two modules ago, this curriculum spent real time on checking before changing, avoiding configuration drift, and validating a change actually worked — all in the abstract, without any code that could actually touch a device. This is the lesson where that caution becomes concrete: send_config_set() is powerful enough to need every bit of that discipline.

How it works

push_config.py

config_commands = [
  "ntp server 192.168.1.1",   # placeholder IP — use your lab's real NTP source
]

output = connection.send_config_set(config_commands)
print(output)

send_config_set() takes a list of configuration-mode commands, enters config mode, sends each one, and exits config mode — returning the device's output from the whole exchange. Only ever run this against a lab device you control.

send_config_set() expects a list of lines, even for a single command — because most real configuration changes involve more than one line (entering an interface, then configuring it, for example), and the function is built around that.

Quick checkConcept check

What's the key difference between send_command() and send_config_set()?

There's no real difference — they do the same thingsend_command() runs a read-only command and returns output; send_config_set() actually changes the device's configurationsend_config_set() only works on Cisco devicessend_command() requires a list of commands; send_config_set() takes a single string

Quick checkIdentify the correct code

Which correctly calls send_config_set() to push a single NTP server line?

connection.send_config_set("ntp server 192.168.1.1")connection.send_config_set(["ntp server 192.168.1.1"])connection.send_command(["ntp server 192.168.1.1"])connection.send_config_set(ntp_server="192.168.1.1")

Idempotency, for real this time

This is the exact moment "Idempotency Explained for Network Engineers" was pointing toward: check the current state before pushing a change, so running the same script twice doesn't push a duplicate line or make an unnecessary change the second time.

idempotent_push.py

current_config = connection.send_command("show run | include ntp server")

if "192.168.1.1" in current_config:
  print("NTP server already configured — no change needed")
else:
  connection.send_config_set(["ntp server 192.168.1.1"])
  print("NTP server added")

Check first, using the same send_command() pattern from the last lesson, then only push a change if it's actually needed — exactly the check-before-changing habit that lesson taught in the abstract.

Quick checkScenario

The idempotent script above is run twice in a row against the same device, with nothing else changing in between. What happens the second time?

The NTP server line is pushed again, creating a duplicateThe check finds the line already present and skips the push, printing 'no change needed'The script raises an error because the configuration already existsNothing — the second run is blocked entirely

Before any real configuration change

A short checklist worth having in mind every time, not just for this lesson:

Is this a lab device you fully control, not production, and not something someone else depends on right now?
Have you checked current state first (idempotency), so you're not pushing a redundant or conflicting change?
Do you have a way to verify the change worked afterward — not just that the command ran without error?
Could you undo this if it didn't do what you expected?

Quick checkMyth check

Is it acceptable to test a send_config_set() example from this lesson against a production network device, as long as the change seems small?

Yes, if the change is small enough it's low-riskNo — configuration-changing examples in this lesson are for a disposable, fully-controlled lab device only, never production, regardless of how small the change looksYes, as long as you have a backup of the config firstNo, but only for devices you don't personally own

Key takeaways

send_config_set() genuinely changes a device's configuration — a different level of risk than any read-only send_command() call.
It takes a list of configuration-mode command lines, even for a single change.
Checking current state before pushing — idempotency — is exactly what prevents duplicate or unnecessary changes on a second run.
Every example in this lesson is optional and lab-only: never run against production, and never part of this module's main capstone project.
Before any real change: confirm it's a lab device, check state first, have a way to validate afterward, and know how you'd undo it.

What you'll learn

Why this is a bigger deal than a show command

How it works

Idempotency, for real this time

Before any real configuration change