SP Scott Peterman
Network systems engineering

I turn opaque networks into something you can query, plan around, and build against.

When a network's real state isn't queryable, your designs become shapes automation can't consume, and the tools you bought are the ones you can't extend. That's the gap I work in. Thirty years operating networks; the last five building the software that makes their state something you can trust.

OPERATE 30 yrs · MPLS · BGP · EVPN BUILD validated on real Arista · Juniper · Cisco DOMAIN datacenter · peering · service provider BASE Littleton, CO
How it's built

Every tool below was validated against real multi-vendor network OSes in a functional lab — real routing tables, real failure scenarios, run through automated suites and re-run on every change, not a one-time pass. Never mock data. The constructs have since made their way into production, but the lab is where they were proven.

Lab-validated
Built against real network OSes with real routing state and real failures. Never mock data.
Multi-vendor
Arista, Juniper, Cisco — on a shared, vendor-agnostic core.
QA-driven
Robot Framework + pyATS out of GitLab CI. Four years of it.
Inheritable
Reusable primitives on carefully chosen libraries — FastAPI, SQLite. Nothing obscure; the next engineer can pick it up.
Selected work

Three tools, one architecture.

Not a catalog. Three tools that came out of the same set of ideas — see the network, know its real state, build its foundations — and each one turns on a single decision that wasn't the obvious one.

FIG.01
Observe
Python
FastAPI
ECMP · FIB
directed graph

fibtrace — the forwarding table, read from the device itself

A traceroute probes from outside with ICMP and sees hop IPs. It's blind to RIB-versus-FIB divergence, an unresolved next-hop, and any ECMP path it didn't happen to hash into.

The decision

The device itself is the most accurate source of truth — so work it inside-out. SSH into each device, read its own forwarding tables, and ask four questions at every hop — is there a route, is it in the FIB, is the next-hop resolved, is the link healthy — then build a directed graph of every path a packet can actually take. Load a before and after and it tells you exactly what changed.

FIG.02
Know
Python
SQLite
TextFSM
REST API

Netlapse — a searchable state-tracking machine

Config backup answers "what changed?" with a text diff, and only for config. Everything else the network knows — ARP, BGP, routes, LLDP, interfaces — is state you can't query, can't version, and can't trust.

The decision

Make any CLI output a first-class record. Define a template and it's collected, parsed, versioned, and semantically diffed — a peer dropping to Idle, not a timer ticking. And every parse is scored, so the platform tells you whether its own data is even true. All of it API-addressable, so it becomes the source of truth other automation reads.

FIG.03
Build
Python
SQLite
dnslib
two-process

waypost DNS + DHCP — control-plane services you can actually build against

DHCP hands out an address; DNS has to carry the name; and in most shops a human stitches the two together while the automation can touch neither. The network's own foundational services are the part nobody designs to be built against.

The decision

Build both to be automated from the first packet. Authored intent lives in git, but the decisions get made on state — machine state in SQLite, and DNS derived directly from live lease state. Two processes joined by one narrow, well-defined interface that degrades gracefully instead of ever failing a lease. Validated end to end on real Cisco gear, across a relay.

One foundation

These aren't three tools — they're one set of reusable primitives applied three times. I'd rather everything spoke RESTCONF; operational reality is SSH-first, so parsing is the first-class citizen — the output selects the template, not the engineer. Underneath sits a hardened, vendor-agnostic SSH client I wrote and a structured artifact that carries the contract between stages. Each one is built to be a platform, not a script: something automation can consume reliably, and the next engineer can pick up and extend. Build the second one and the third comes fast.

Track record

Where it came from.

2024 — now
Principal Infrastructure Engineer
Datacenter and peering infrastructure on Arista and Juniper — circuit turn-ups, PNI implementations, and BGP peer migrations with pre-flight validation, state auditing, and cutover execution.
2022 — 2024
Principal Infrastructure Engineer · Columbia Sportswear
Enterprise network across 600+ retail locations, datacenters, and corporate sites (Cisco, Aruba, Palo Alto). Built a device-state collection platform for auditing and compliance.
2019 — 2022
Principal Engineer · Charter the QA instinct
Built datacenter QA network automation from the ground up — Robot Framework and pyATS suites against real hardware, out of GitLab CI on every config and image change. EVPN/VXLAN fabric and control/data-plane convergence validation. This is where "is the data even true?" became a habit.
2012 — 2019
Architect, IP Edge · Level3 / TW Telecom the gap seat
IP services architecture across a tier-1 backbone — MPLS L3VPN, VPLS, anycast DNS, NetFlow at carrier scale. Sat between engineering and automation, making sure the design constructs were built to be consumed by automation, a decade before that was the norm.
2006 — 2012
Architect III · Cricket / AT&T
Mobile carrier core — MPLS with OSPF-TE, VPLS, MVNO peering, datacenter fabrics up to ~300 switches.
Reference
Protocols
BGP · MPLS L3VPN
VPLS · EVPN/VXLAN
OSPF / IS-IS · SD-WAN
Platforms
Cisco IOS/XE/NX-OS
Arista EOS · Junos
Palo Alto · Aruba · F5
Languages
Python · Go
C#/.NET · JS/TS
PyQt6 · FastAPI · Fyne
Automation
pyATS · Robot Framework
Nornir · NAPALM · TextFSM
Paramiko · GitLab CI