Network Topology Conformance

Network Topology Conformance lets your firm check a client's as-built network against a reference design you author — and produce a scored, evidence-backed report and client deck from nothing but the device configurations.

Unlike a framework assessment, which uses AI to evaluate evidence against qualitative questions, conformance is deterministic. Device configs are parsed and the real Layer-3 topology is derived with Batfish; each criterion is a rule checked against those facts. No LLM, no inference — every pass/fail cites the specific configuration fact, so a network engineer can independently verify it.

What it's for

Network discovery and design-conformance reviews: "does this network actually match the standard we designed for it?" It is a fit for infrastructure, networking, and cyber practices that assess client estates. It is not a replacement for framework assessments — the two are complementary.

Who can access

Available to organizations that have the Network Topology module enabled (managed per-org in Platform Admin). Within an enabled org:

• Authoring a reference design requires an org admin or practice lead role, or being the reference design's creator. See Roles & Permissions.
• Running a conformance assessment is available to anyone who can open the engagement.

Conformance currently targets Cisco IOS / IOS-XE configurations (the lab reference vendor), with partial support for PAN-OS. Unsupported vendors or device types are surfaced as not applicable rather than failing.

The two halves

The feature has two surfaces that mirror the rest of the platform: you author the standard once, firm-wide, then apply it inside each engagement.

Surface	Where	What you do
Network Frameworks	Left nav → Network Frameworks (firm-level)	Author and publish the reference design(s) you score client networks against
Network Topology	Engagement → Network Topology (Workspace)	Upload a client's device configs and score them against a published reference design

---

1. Author a reference design (Network Frameworks)

Open Network Frameworks from the left nav. This lists your firm's reference designs with their publish status, the same way Frameworks lists assessment frameworks.

Start from the Celeredge Enterprise Network Baseline

Every organization sees a ready-made, published reference design — the Celeredge Enterprise Network Baseline — marked with a Celeredge badge. It's a best-practice design that blends CIS Benchmark hardening with Cisco Validated Design resilience guidance across eight weighted dimensions — Redundancy & High Availability, First-hop & Link Resilience, Routing Resilience, Layer-2 Security, Management-Plane Hardening, Logging, Time & Monitoring, Segmentation, and Addressing & Lifecycle. You can run it against a client's configs immediately, with nothing to author.

The Celeredge baseline is read-only — open it to see exactly how it's built, but you can't edit, publish, or delete it. To make it your own, click Duplicate to my org: this creates a fully editable copy under your firm that you can tailor and publish like any design you author. Enterprise organizations receive an editable copy automatically the moment the Network Topology module is switched on, so there's nothing to set up.

Prefer to build your own standard from scratch? Author a new design from the empty state instead:

1. New profile. Give it a short profile id (used in links, lowercase-dashes), a name, and a framework name (the title shown on the report).
2. Add dimensions. A reference design is organised into dimensions — logical groupings such as Core redundancy, Routing resilience, or Segmentation. Each dimension has a weight that sets how much it counts toward the overall score.
3. Add checks to each dimension. A dimension holds one or more checks. For each check you give it a title, pick a check from the library, set its parameters, an optional per-check weight, and remediation guidance (what the client should do if it fails).
4. Save, then Publish. Publishing makes the design selectable inside engagements. Saving always persists the current draft first, so publishing never ships an empty design.

tip

Start small — a single dimension with one or two checks already produces a usable report. Add dimensions over time as the client's standards evolve (security zones, routing resilience, lifecycle), and the report grows with them.

The check library

Checks are the building blocks. Each reads a specific fact from the parsed configs and returns pass / partial / fail / not-applicable. The catalog is organised by category:

Check	Category	What it verifies	Key parameters
Minimum devices by role	Redundancy	At least N devices whose hostname contains a role token	role, min
First-hop redundancy (HSRP/VRRP)	Redundancy	At least one device configures HSRP/VRRP	—
HA pair present	Redundancy	At least N high-availability pairs are configured	min_pairs
Dual uplinks by role	Redundancy	Every device of a role has at least N uplinks	role, min_uplinks
Link aggregation configured	Redundancy	At least N port-channel / bundle interfaces exist	min
Dynamic routing configured	Routing	At least one device runs OSPF / BGP / EIGRP	protocols
VLAN segmentation	Segmentation	At least N distinct VLANs are in use	min_vlans
Security zones defined	Segmentation	At least N distinct security zones exist	min
No overlapping subnets	Addressing	No two interfaces on different devices overlap	—
Private addressing (RFC1918)	Addressing	All addressed interfaces use RFC1918 space	—
No end-of-life OS	Lifecycle	All devices are at or above a minimum OS major	min_major
OS version consistency	Lifecycle	Devices run a consistent OS major	—
SSH-only remote access	Hardening	VTY lines accept SSH, not telnet	—
SSH version 2	Hardening	Device negotiates SSHv2	—
Centralized login (AAA)	Hardening	AAA is enabled and points at a TACACS+/RADIUS server	—
Password protection	Hardening	Password encryption and an enable secret are set	—
Idle session timeout	Hardening	VTY lines enforce an idle exec-timeout	—
Management access list	Hardening	VTY lines restrict the source address with an access list	—
No default SNMP community	Hardening	No public / private SNMP strings are present	—
No plaintext HTTP management	Hardening	Plaintext ip http server is disabled (HTTPS only)	—
BPDU guard	Layer-2 security	BPDU guard is enabled on the access edge	—
DHCP snooping	Layer-2 security	DHCP snooping is enabled	—
Port security	Layer-2 security	Port security is configured on access ports	—
Redundant time sources	Logging & time	At least two NTP servers are configured	—
Central logging	Logging & time	A remote syslog host is configured	—
Log timestamps	Logging & time	Log messages carry datetime timestamps	—
Routing authentication	Routing	OSPF uses message-digest authentication	—

The Hardening, Layer-2 security, Logging & time, and Routing checks read specific lines from the device configuration (rather than a derived topology fact), and map to CIS Benchmark and Cisco Validated Design guidance — these are the checks that make up the Celeredge baseline above.

A few checks are best-effort or only apply to some devices:

• Switch-only checks (BPDU guard, DHCP snooping, port security) apply only to devices acting as switches; routed-only devices are excluded as not applicable.
• Checks that depend on the OS version, or on a device having a readable configuration for that check, return not applicable rather than failing when the fact isn't available — a device is never scored on a configuration we couldn't read.

---

2. Run a conformance assessment (Network Topology)

Inside an engagement, open Network Topology from the Workspace section of the left nav.

1. Choose a reference design. Tick one or more published designs under Reference design — the Celeredge Enterprise Network Baseline, any copy you've made of it, or a design you authored. Leave it empty to score against the built-in default baseline.
2. Upload device configs. Provide a .zip of the client's device configurations (one file per device).
3. Analyze topology. The configs are parsed, the as-built Layer-3 topology is discovered, and each criterion is evaluated against the derived facts. Results come back in seconds.

Nothing is stored as a long-running job — the report renders in place, and you can re-run it any time by uploading a fresh config set.

Reading the report

The report is a single deliverable-quality page:

• Overall score & band. A 0–100 score and a band: Conformant (≥90), Minor drift (≥70), or Significant drift (below 70), with pass / partial / fail / n-a counts.
• How this was assessed. A short, honest methodology note — configs parsed, topology derived deterministically, every result traceable to a fact.
• As-built topology. The discovered devices laid out by tier (edge, core, distribution, access).
• Conformance by dimension. Each dimension's score, with how many of its checks passed.
• Check register. Every criterion, its result, and the config-fact evidence behind it (e.g. "Only 1 'core' device (need 2). (as2core1)").
• Findings & remediation. The failing and partial checks, each with its remediation step.

How scoring works

Each check result maps to a number — pass = 100, partial = 50, fail = 0 — and not applicable checks are excluded from scoring entirely. Results roll up by your weights: first across the checks in a dimension (by per-check weight), then across dimensions (by dimension weight), into the overall score and band. Because weights are yours, the score reflects your priorities, not a fixed formula.

---

3. Export a client deck

From the Network Topology page, Download PowerPoint deck produces a branded, editable .pptx conformance deck from the same result: a cover, executive summary with takeaways, the methodology, the as-built topology, the weighted dimension breakdown, the full check register with evidence, findings & remediation, and recommended next steps with a suggested quarterly cadence. The slides are native, editable shapes — a consultant can move and adjust anything before presenting. See Deck Studio for the platform's broader presentation tooling.

How it differs from a framework assessment

	Framework assessment	Network topology conformance
Input	Evidence, documents, interviews	Device configuration files
Method	AI evaluates qualitative questions	Deterministic rules over parsed config facts
Output	Maturity / gap scoring	Design-conformance scoring
Verifiability	Cited evidence passages	A specific config fact per result — no inference
Authoring	Framework Authoring	Network Frameworks (this page)

Use a framework assessment to evaluate a client's practices and maturity; use conformance to verify a client's network matches an intended design. Many engagements run both.

Make it repeatable

Re-run conformance each quarter against the same reference design so drift is caught the moment configs change. The deck's recommended next steps slide suggests a cadence you can adopt with the client.