Auditing a Service Provider Grade Enterprise Network

The kind of assignment this is

Large enterprises that have grown for a decade under different teams and different priorities accumulate a gap between what leadership believes they run and what is actually in the racks. Documentation drifts, ownership fragments, and the network keeps working well enough that nobody has to look closely. Then a budget cycle, an incident, or a new architect forces the question: what do we actually have, what is at risk, and what should the next few years look like?

This write-up is a composite of that audit work, with the details generalized. The deliverable is never a penetration test report or a slide deck. It is a structured High-Level Design meant to become the single source of truth, backed by low-level design documents, inventory exports, and raw CLI evidence for every claim.

The kind of environment

The networks worth auditing at this level tend to share a shape: a service-provider-grade core (SR-MPLS over IS-IS, clean segment routing with no legacy label protocols), EVPN/VXLAN fabrics extended over the WAN, public internet routing at the edge, heavy L3VPN segmentation, and a multi-vendor estate (Juniper in the core, mixed firewalls, cloud interconnects). Enough moving parts that no single person holds the whole picture, which is exactly why an evidence-first audit earns its keep.

Method: evidence first, opinions second

Audits fail in two ways. Either they trust the documentation, which is always stale, or they trust interviews, which are always optimistic. I build the audit on a different rule: every claim traces to confirmed evidence, and anything inferred is flagged as inference, never presented as fact.

In practice that means:

• Pulling live state from the devices themselves: routing tables, BGP session states, BFD timers, OSPF databases, firewall policy hit counters.
• Reconciling that against the inventory system, then treating every mismatch as a finding in itself.
• Separating domains strictly. A typical audit covers five: WAN and backbone, data center and campus fabrics, internet edge, security and segmentation, and operational readiness. Security findings never bleed into fabric sections, which keeps each chapter defensible on its own.
• Grading every domain on the same scale: what is working, what needs optimization, and what is an actual business risk.

The audience is director-level leadership, so the writing discipline matters as much as the engineering. Recommendations have to survive executive scrutiny without over-committing to implementation details that belong in later projects.

The central lesson: judge transport and security separately

The most useful sentence in an audit like this is usually the same one: the transport can be excellently engineered while the critical risks live somewhere else entirely.

A carrier-grade backbone (clean segment routing, a tiered IS-IS metric hierarchy, a well-structured route reflector design, uniform BGP communities, RPKI origin validation policy templated across the edge) tells you the people who built it knew what they were doing. But the risk often sits in the security model layered on top of it, and the two are independent axes.

The recurring example is VRF route-import policy. L3VPN segmentation is governed by route-target import and export, which means the import list is functionally the access control list between entire network segments, except it lives in routing configuration, gets edited by engineers solving connectivity tickets, and is reviewed by nobody thinking in terms of attack paths. Over years and one ticket at a time, a remote-access segment can end up importing far more of the network than it should. Worse, when two segments exchange routes directly, that east-west traffic resolves inside the fabric and never traverses the north-south firewalls at all, so the inspection model has a blind spot that no alarm reports. (I unpack that failure mode in the VRF route-leaking write-up.) The reusable point: read the import/export matrix as if it were a firewall policy, because that is what it is.

This distinction, excellent transport with a separable security question, is what separates a targeted remediation plan from a rip-and-replace panic. It is also the argument that keeps a well-built MPLS core from being thrown away for SD-WAN because “the network has problems.”

The kinds of findings that recur

A selection of the patterns an evidence-first audit tends to surface, generalized rather than tied to any one network:

• RPKI theater. Origin validation policy templated identically everywhere, but not every edge actually has a healthy validator feed behind it, so on some sessions the policy is a silent no-op. The lesson generalizes: verify effect, not config presence. (More in RPKI: the policy was perfect, the validators were missing.)
• Firewall rule decay. The large majority of firewall rules having never matched a single packet, with traffic concentrated into a handful of broad permits. (The full pattern is here.)
• Lifecycle debt. Access switches past end-of-support with no vendor contract, and privileged infrastructure (console servers, management appliances) running years-behind firmware carrying known, named CVEs, often reachable more widely than anyone intended.
• The out-of-band paradox. A break-glass management path that quietly depends on the very network it is meant to rescue, so during a real outage the tool for fixing the network goes down with the network. (Detailed here.)
• Quiet drift. Configuration remnants, inconsistent timers, missing routing-protocol authentication, and redundancy that exists on paper but not in practice.

Each finding enters a risk register with severity, blast radius, and a concrete remediation, so leadership can reason about priorities instead of adjectives.

From findings to a multi-year plan

An audit that ends at findings is a complaint. This kind ends in a roadmap:

1. Stabilize. Quick wins and de-risking: harden over-permissive access segments in place, close the RPKI validator gaps, patch and refresh the out-of-band estate, replace end-of-life switches, fix AAA redundancy. Mostly configuration work, minimal capital.
2. Segment. The strategic security investment: build an east-west inspection point, pull the DMZ into its own segment, and begin a ZTNA rollout to retire flat VPN access, with flow baselining as a prerequisite before touching any route imports.
3. Standardize. Department-aligned VLAN and VRF redesign, a uniform VRF import/export matrix across sites, a consistent EVPN ESI scheme, OSPF authentication fleet-wide.
4. Observe and automate. Consolidated monitoring, automated compliance auditing, drift detection, hybrid DDoS protection.
5. Optionality. Re-evaluate SD-WAN for small spoke sites only. Backbone sites that carry full routing tables, EVPN over the WAN, and heavy segmentation tend to stay on MPLS, and pretending otherwise is expensive theater.

Budget figures are framed as capital versus recurring categories with vendor quotes pending, never invented precision. Firewall procurement, for example, goes to leadership as a multi-vendor bake-off with a total-cost-of-ownership model rather than a single number.

What I take away from it

This work reinforced a belief I now apply everywhere: separate the quality of what was built from the risk of how it is used. Those are independent axes, and collapsing them into one “network health” score produces either false alarm or false comfort. The follow-on work becomes its own series of projects, including the east-west segmentation design and the AI knowledge layer built on top of an audit’s documentation base.