Automating IP Capacity & Network Configuration Analysis

This project started while I was working in transmission and network planning. Planning decisions depended on inspecting network capacity, device configurations, routing, and related conditions across the infrastructure — and that inspection was almost entirely manual, done check by check across separate tools and sessions.

No single check told the whole story. Capacity looked fine in isolation while a configuration mismatch, a duplicate path, or an interference condition elsewhere changed what that capacity number actually meant. Getting a trustworthy read on a site or link meant manually combining network configurations, VLAN information, routes, link utilization, duplicate-path checks, and interference-related checks — fragmented, repetitive, and easy to get subtly wrong under time pressure.

Instead of treating this as a recurring task to repeat faster, I treated it as a system to build: if the underlying checks were all pulling from the same network reality, they belonged in one workflow that reconstructed that reality once and reasoned over it — not eleven separate manual passes.

I initiated and directed the development of an IP Capacity Dimensioning & Offline Radio Sites Configuration Tool. It connected to the network infrastructure and brought previously separate checks — configuration, VLANs, routing, link utilization, duplicate paths, interference-related conditions — into one automated workflow, rather than automating any single check on its own.

Conceptually, the tool moved through the same stages a manual review would, just without the manual part in between:

Network Systems → Automated Collection → Network Context / Topology → Validation → Analysis / Insight

The tool was built in Python and connected directly to the network infrastructure to pull configuration and topology data programmatically, reconstructing enough network context in one place to run the checks that had previously required switching between several manual tools and sessions.

The workflow moved from a process that could consume roughly a full working day of manual checking to an automated analysis run — the system reconstructed enough network context on its own to surface issues that previously only turned up after several separate manual checks.

This was an early proof that combining telecom domain knowledge with software and automation could solve operational problems differently than either could alone. The visibility this work generated within the organization contributed to my later move toward Telecom Cloud and production engineering, and eventually MLOps.