The engagement had 460 managed devices and no current topology documentation. Network topology automation was the only viable path — manual spreadsheet work would have taken weeks and produced a point-in-time artifact no one could re-run. The Cisco design team needed three structured deliverables before they could move: device inventory, physical topology graph, VLAN/service map.
I built the pipeline instead.
The engagement was a brownfield Avaya/Extreme SPBM-to-Cisco migration across dozens of sites in multiple states — five OS types in flight simultaneously: Avaya VSP, Avaya ERS, Cisco NX-OS, IOS-XE, IOS. The post-processor pipeline requires no network access — raw CLI show-command output is the only input. Collection was live, directed using existing tooling on the engagement, running targeted commands per OS type against the device corpus. Five independent export scripts producing three structured CSV deliverables and a LucidChart-ready diagram file in a single repeatable run.
459 devices processed in seconds. Device inventory: 459/459, zero errors. Physical topology: 2,254 links. VLAN/service map: 10,045 rows, 6,885 cross-validated against both sources.
The headline result: 34 topology links that would have been invisible to any purely LLDP-based approach.
Network Topology Automation: Parsing What LLDP Can’t See
LLDP and CDP tell you what devices advertise about themselves. SPBM’s ISIS-based control plane doesn’t advertise to LLDP. The fabric’s topology lives in the ISIS LSDB — a nested TLV/sub-TLV structure that line-oriented FSMs cannot model. TextFSM is powerful for well-structured CLI output. It cannot parse recursive structures. There is no off-the-shelf template for this.
I wrote isis_lsdb_parser.py from scratch: a purpose-built recursive parser producing both flat spreadsheet-ready output and normalized six-table relational output. Validated against the live engagement fabric plus two historic corpora for stress testing.
The topology algorithm runs two passes. Pass 1 builds the LLDP/CDP graph. Pass 2 injects ISIS-derived adjacencies for node pairs not covered by standard discovery. LLDP wins on collision. The result is a complete graph — not a best-effort approximation missing a third of the fabric’s internal links.
Corpus Integrity Across 11 Sites
Corpus integrity was its own problem.
460 devices across 11 sites, mid-conversion. rsync --ignore-existing was silently preserving stale files — discovered, switched to cp. IP address conflicts from devices captured mid-conversion: a VSP-8404C and a newly deployed C9500-48Y4C at the same IP, different collection windows. Archive strategy preserving pre-conversion provenance without contaminating the active corpus. Timestamp-based gap triage distinguishing genuine collection gaps from conversion candidates.
The pipeline surfaced 2 IP-conflicted devices automatically. Without it, those conflicts would have appeared as unexplained inconsistencies in the design artifacts — discovered late, at cost.
I also built preflight.py: a self-describing coverage report that runs before the main pipeline. Device count by site and OS. Per-OS command coverage with visual bar charts. Gap breakdown naming the specific devices and commands missing. The tool tells the operator exactly what to collect next and from where, before a single export script runs.
NTC Templates and the Bespoke Fallthrough
The NTC-templates integration is worth a note. NTC-first with bespoke TextFSM fallthrough for cases NTC doesn’t cover or covers incorrectly. Three NX-OS commands required bespoke templates despite NTC coverage — silent field-name changes across versions; pinned ntc-templates==9.0.0 after discovering this. TextFSM authoring rules documented encoding failure modes specific to this installation, none of which appear in the TextFSM project documentation.
The LucidChart export includes role-based node coloring from hostname tokens, per-site scope filter, and node tooltips carrying model/version/serial/location. The diagram consumer never needs to cross-reference the inventory CSV.
Self-initiated. No assignment, no management request. I identified the documentation bottleneck, built the post-processor pipeline, and released it to colleagues on the engagement. Collection infrastructure on the engagement was existing tooling; the pipeline consumed its output.
The pipeline is version-controlled, documented, and extensible. Any engineer on the engagement can run it. The weeks of manual Visio and spreadsheet work it replaced don’t come back. Full technical context in the resume.
What does your topology documentation look like when the fabric’s control plane doesn’t speak LLDP?
Leave a Reply
You must be logged in to post a comment.