Blog

Pasting the same VLAN configuration into forty switches, parsing show ip route output by eye, keeping a spreadsheet of device IPs that drifts out of sync the moment someone touches the network — these are the daily frustrations that lead network engineers to Python. This is the first post in a 21‑day series that moves from “Python sounds useful” all the way to writing real automation scripts: scripts that back up configs, push changes to dozens of devices at once, and turn raw show output into clean structured data.

Each day brings one focused lesson. Read it over coffee, work through the examples in a lab, then attempt the exercises at the bottom — the answers are hidden behind a toggle, so it pays to try first. By the end of the three weeks, the series builds up to a complete multi‑vendor configuration tool. Today sets the stage.

Why Python and not Bash, Tcl, or Ansible?

The honest answer: Python is the language the network industry has converged on. Cisco’s pyATS, NAPALM, Netmiko, Nornir, Scrapli, Genie, and almost every vendor SDK ship as Python libraries. NETCONF/RESTCONF tooling is Python. Ansible itself is written in Python and its custom modules are Python. For one language to cover the next decade of network work, this is the one.

That does not mean Bash and Tcl go away. Bash is still the right tool for “do this once across a few Linux boxes,” and Tcl scripting (EEM applets) lives inside the IOS process so it can react to events Python cannot reach. But for anything that talks to multiple devices, parses output, or integrates with an API, Python wins on ecosystem alone.

What this series builds toward by Day 21

• Looping over a YAML inventory of routers and switches, connecting to each over SSH, and capturing the running‑config to a Git repository.
• Generating per‑device configuration from a single Jinja2 template — no more copy‑paste drift.
• Calling REST and NETCONF APIs to read interface state without screen‑scraping.
• Converting messy show output into Python dictionaries with TextFSM and acting on them programmatically.
• Building a tool that pushes a config snippet to dozens of devices in parallel and produces a diff report for change control.

None of that requires being a software engineer. It requires being comfortable with about a dozen Python concepts, which this week covers one per day.

Installing Python the right way

Use Python 3.11 or newer. Python 2 is dead, and 3.6/3.7 are missing features (like the := walrus and modern typing) that appear in libraries by 2026.

Linux (Ubuntu/Debian):

sudo apt update
sudo apt install -y python3 python3-venv python3-pip
python3 --version   # expect 3.11.x or newer

macOS:

brew install [email protected]
python3 --version

Windows: install from python.org (check “Add Python to PATH” during the installer) or use the Microsoft Store build. Then in PowerShell:

python --version

Avoid installing network libraries with sudo pip install. That pollutes the system Python and leads to version conflicts within a month. The right pattern is one virtual environment per project, which is the next thing to set up.

A first virtual environment

A virtualenv is a private folder of Python packages. Once it is activated, pip install only affects that folder. Create one for this whole series:

mkdir ~/python-net && cd ~/python-net
python3 -m venv .venv
source .venv/bin/activate         # Windows: .venv\Scripts\activate
python -m pip install --upgrade pip

The shell prompt should now start with (.venv). From inside the venv, install the libraries this series needs over the next three weeks:

pip install netmiko napalm ncclient requests pyyaml jinja2 textfsm ntc-templates

That is one command, and the toolchain is ready for everything in this series. To leave the venv, type deactivate.

Pick an editor that helps rather than fights

Python can be written in Notepad, but it shouldn’t be. Use an editor that provides syntax highlighting, indentation guides, and at least basic linting:

• VS Code with the official Python extension — free, cross‑platform, the de‑facto standard. Good remote‑SSH support when the lab is a Linux box.
• PyCharm Community Edition — heavier, but powerful refactoring and a debugger that teaches Python by accident.
• Vim/Neovim with python-lsp-server for those who already live in the terminal.

Whichever one, configure it to use the interpreter from the .venv folder, not the system one. In VS Code that is Ctrl+Shift+P → Python: Select Interpreter.

Pick a lab that is safe to break

Automation needs somewhere to push real config that does not page anyone at 3 AM. Three good options, cheapest first:

1. EVE‑NG Community or GNS3 running CSR1000v / IOSvL2 / cEOS images on a beefy laptop or a small server. Free, infinitely repeatable, and the closest match to production behavior.
2. Cisco DevNet Sandboxes — free reservable labs with always‑on IOS XE, NX‑OS, and DNAC instances. Perfect when no hardware is available. A search for “DevNet Sandbox always on” turns up an IOS XE device reachable over SSH right now.
3. Containerlab for anyone comfortable with Docker — spin up an Arista cEOS or Nokia SR Linux topology in seconds.

This series assumes access to at least one device over SSH. If there isn’t one yet, the DevNet always‑on IOS XE sandbox takes five minutes to set up and gets used from Day 12 onward.

The Python REPL is the CLI

One last habit before tomorrow: get comfortable with the interactive Python prompt. From inside the venv, just type python:

$ python
Python 3.12.0 (main, Oct  2 2023, 11:27:05) [GCC 11.4.0] on linux
>>> 2 + 2
4
>>> "GigabitEthernet0/1".split("/")
['GigabitEthernet0', '1']
>>> exit()

Think of the REPL as show running for ideas — when a function’s behavior is unclear, try it there before putting it in a script. This series uses it constantly this week.

A 12‑line teaser of where this is going

Here is what the Day 12 script looks like, just to show the destination. There’s no need to run it yet — a week of basics comes first.

from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "sandbox-iosxe-latest-1.cisco.com",
    "username": "admin",
    "password": "C1sco12345",
}

with ConnectHandler(**device) as conn:
    output = conn.send_command("show ip interface brief")
    print(output)

Twelve lines, one SSH session, one structured connection object that closes itself. By Day 13 the same loop runs against a list of forty devices in parallel.

Exercises

Spend 15 minutes on these before tomorrow’s post. Try first, then expand the answer.

1. Install Python 3.11+ on a workstation. Confirm python3 --version prints a version starting with 3.11 or higher.
2. Create a virtualenv called .venv inside a fresh folder, activate it, and install netmiko. Then run pip list and confirm netmiko appears with its dependencies.
3. Inside the activated venv, open the Python REPL and compute how many usable host addresses are in a /27. Hint: no library required — it’s basic math, but building the habit of using the REPL as a calculator matters.
4. Reserve a Cisco DevNet always‑on IOS XE sandbox, find its hostname and credentials, and successfully SSH to it from a terminal (not Python yet). Note the prompt — that’s the device this series automates from Day 12.
5. Stretch: deactivate the venv, then activate it again. What does which python print before vs. after? Why is that the entire point of a virtualenv in one observation?

Answers

python3 --version
# Python 3.12.0

mkdir test && cd test
python3 -m venv .venv
source .venv/bin/activate
pip install netmiko
pip list | grep -i netmiko
# netmiko       4.x.x

>>> 2 ** (32 - 27) - 2
30

ssh [email protected]
# accept fingerprint, type the password, and csr1000v# should appear

deactivate
which python
# /usr/bin/python  (system)
source .venv/bin/activate
which python
# /home/you/test/.venv/bin/python  (venv)

Coming tomorrow

Day 2: Python Syntax Crash Course for People Who Already Know IOS — variables, types, indentation, and the handful of syntactic rules that account for 90 percent of beginner errors. By the end of tomorrow, reading other people’s Python stops being intimidating.