Cisco network automation

Cisco IOS Patterns

Use this skill when reviewing Cisco IOS or IOS-XE snippets, building a change-window checklist, or explaining how to collect evidence from a router or switch without making the incident worse.

When to Use

• Reviewing IOS or IOS-XE configuration before a planned change.
• Choosing read-only show commands for troubleshooting.
• Checking ACL wildcard masks and interface direction.
• Explaining global, interface, routing process, and line configuration modes.
• Verifying that a change landed in running config and was saved intentionally.

Operating Rules

Treat IOS examples as patterns, not paste-ready production changes. Confirm the platform, interface names, current config, rollback path, and out-of-band access before making changes on a real device.

Prefer this workflow:

1. Capture current state with read-only commands.
2. Review the exact candidate config.
3. Confirm management access cannot be locked out.
4. Apply the smallest change in a maintenance window.
5. Re-read state, compare to the baseline, then save only after validation.

Mode Reference

Router> enable
Router# show running-config
Router# configure terminal
Router(config)# interface GigabitEthernet0/1
Router(config-if)# description UPLINK-TO-CORE
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# end
Router# show running-config interface GigabitEthernet0/1

running-config is active memory. startup-config is what survives reload. Do not save a change just because a command was accepted; validate behavior first, then use copy running-config startup-config if the change is approved.

Read-Only Collection

show version
show inventory
show processes cpu sorted
show memory statistics
show logging
show running-config | section line vty
show running-config | section interface
show running-config | section router bgp
show ip interface brief
show interfaces
show interfaces status
show vlan brief
show mac address-table
show spanning-tree
show ip route
show ip protocols
show ip access-lists
show route-map
show ip prefix-list

Collect the specific section you need instead of dumping full config into a ticket when the config may contain secrets, customer names, or private topology.

Wildcard Masks

IOS ACL and many routing statements use wildcard masks, not subnet masks.

Subnet mask       Wildcard mask
255.255.255.255   0.0.0.0
255.255.255.252   0.0.0.3
255.255.255.0     0.0.0.255
255.255.0.0       0.0.255.255

Review wildcard masks before deployment. A subnet mask accidentally used as a wildcard can match far more traffic than intended.

ip access-list extended WEB-IN
  10 permit tcp 192.0.2.0 0.0.0.255 any eq 443
  999 deny ip any any log

Every ACL has an implicit deny at the end. Add an explicit logged deny when the operational goal includes observing misses, and confirm logging volume is safe.

ACL Placement Review

Before applying an ACL to an interface, answer these questions:

• Which traffic direction is being filtered, in or out?
• Is management traffic sourced from a known jump host or management subnet?
• Is there an explicit permit for required routing, DNS, NTP, monitoring, or application traffic?
• Are hit counters available from a safe test source?
• Is there a rollback command and an active console or out-of-band path?

Do not test reachability by removing firewall or ACL protections. Read counters, logs, and route state first.

Interface Hygiene

interface GigabitEthernet0/1
 description UPLINK-TO-CORE
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 switchport trunk native vlan 999
 no shutdown

Use clear descriptions, explicit switchport mode, and documented native VLANs. On routed interfaces, confirm the mask, peer addressing, and routing process before assuming link state means forwarding is correct.

Change-Window Verification

Use before/after checks that match the actual change.

show running-config | section interface GigabitEthernet0/1
show interfaces GigabitEthernet0/1
show logging | include GigabitEthernet0/1|changed state|line protocol
show ip route <prefix>
show ip access-lists <name>

For routing changes, also capture neighbor state and route tables before and after the change. For ACL changes, compare hit counters from a planned test source rather than relying on a generic ping.

Anti-Patterns

• Applying a generated config without a device-specific diff.
• Saving configuration before post-change checks pass.
• Using a subnet mask where IOS expects a wildcard mask.
• Applying an ACL to the wrong interface direction.
• Troubleshooting by disabling ACLs, route policies, or authentication.
• Pasting full configs into public tools without sanitizing secrets and topology.

See Also

• Agent: network-config-reviewer
• Agent: network-troubleshooter
• Skill: network-config-validation
• Skill: network-interface-health

---

Netmiko SSH Automation

Use this skill when writing or reviewing Python automation that connects to network devices with Netmiko. Keep the default path read-only; config changes need a separate change window, peer review, and rollback plan.

When to Use

• Collecting show command output across routers, switches, or firewalls.
• Building a small audit script for interface, routing, or config evidence.
• Adding timeouts and exception handling to network SSH scripts.
• Parsing command output with TextFSM when a template exists.
• Reviewing automation before it touches production devices.

Safety Defaults

• Start with read-only send_command() collection.
• Keep inventory small and explicit; do not sweep whole address ranges.
• Use environment variables, a vault, or getpass; never hardcode credentials.
• Set connection and read timeouts.
• Limit concurrency so older devices are not overloaded.
• Require an explicit operator flag before send_config_set().
• Do not call save_config() until the change has been verified and approved.

Read-Only Connection Pattern

import os
from getpass import getpass
from netmiko import ConnectHandler
from netmiko.exceptions import (
    NetmikoAuthenticationException,
    NetmikoTimeoutException,
    ReadTimeout,
)

device = {
    "device_type": "cisco_ios",
    "host": "192.0.2.10",
    "username": os.environ.get("NETMIKO_USERNAME") or input("Username: "),
    "password": os.environ.get("NETMIKO_PASSWORD") or getpass("Password: "),
    "secret": os.environ.get("NETMIKO_ENABLE_SECRET"),
    "conn_timeout": 10,
    "auth_timeout": 20,
    "banner_timeout": 15,
    "read_timeout_override": 30,
}

try:
    with ConnectHandler(**device) as conn:
        if device.get("secret") and not conn.check_enable_mode():
            conn.enable()
        output = conn.send_command("show ip interface brief", read_timeout=30)
        print(output)
except NetmikoAuthenticationException:
    print("Authentication failed")
except NetmikoTimeoutException:
    print("SSH connection timed out")
except ReadTimeout:
    print("Command read timed out")

Use placeholder addresses from documentation ranges in examples. Keep real inventory in an ignored local file or a secrets-managed system.

Batch Collection

from concurrent.futures import ThreadPoolExecutor, as_completed
from typing import Any

def collect_show(device: dict[str, Any], command: str) -> dict[str, Any]:
    host = device["host"]
    try:
        with ConnectHandler(**device) as conn:
            output = conn.send_command(command, read_timeout=45)
        return {"host": host, "ok": True, "output": output}
    except (NetmikoAuthenticationException, NetmikoTimeoutException, ReadTimeout) as exc:
        return {"host": host, "ok": False, "error": type(exc).__name__}

results = []
with ThreadPoolExecutor(max_workers=8) as pool:
    futures = [pool.submit(collect_show, device, "show version") for device in devices]
    for future in as_completed(futures):
        results.append(future.result())

Keep max_workers low unless the device estate and AAA systems are known to handle higher connection volume.

Structured Parsing

Netmiko can ask TextFSM, TTP, or Genie to parse supported command output. Treat parser output as an optimization, not the only evidence path.

with ConnectHandler(**device) as conn:
    parsed = conn.send_command(
        "show ip interface brief",
        use_textfsm=True,
        raise_parsing_error=False,
        read_timeout=30,
    )

if isinstance(parsed, str):
    print("No parser template matched; store raw output for review")
else:
    for row in parsed:
        print(row)

If parsing drives a blocking decision, keep the raw command output alongside the parsed result so an operator can inspect mismatches.

Guarded Config Pattern

import os

commands = [
    "interface GigabitEthernet0/1",
    "description CHANGE-1234 UPLINK-TO-CORE",
]

apply_changes = os.environ.get("APPLY_NETWORK_CHANGES") == "1"

if not apply_changes:
    print("Dry run only. Candidate commands:")
    print("\n".join(commands))
else:
    with ConnectHandler(**device) as conn:
        conn.enable()
        before = conn.send_command("show running-config interface GigabitEthernet0/1")
        output = conn.send_config_set(commands)
        after = conn.send_command("show running-config interface GigabitEthernet0/1")
        print(before)
        print(output)
        print(after)
        print("Verify behavior before saving startup config.")

Saving the config is a separate approval step. In production, include a rollback snippet and capture before/after evidence in the change record.

Review Checklist

• Does the script identify an explicit inventory source?
• Are credentials absent from source, logs, and exception messages?
• Are conn_timeout, auth_timeout, and command read_timeout set?
• Are failures reported per device without stopping the whole batch?
• Does the script avoid broad scans and unbounded concurrency?
• Are config changes behind a dry-run or explicit operator flag?
• Is save_config() separate from the initial push and tied to verification?

Anti-Patterns

• Hardcoding passwords, enable secrets, or private keys in source.
• Sending config commands as the default code path.
• Running automation against a CIDR range instead of a reviewed inventory.
• Logging full running configs to shared systems without sanitization.
• Treating parser success as proof that the device state is correct.

See Also

• Skill: cisco-ios-patterns
• Skill: network-config-validation
• Skill: network-interface-health