Redundancy is designed.
Resilience is verified.
An enterprise-style campus network developed through structured implementation, extensive verification and controlled failure testing. Explore the architecture, investigate the findings and follow the original engineering evidence in GitHub.
Follow the work.
From design decisions to the evidence behind them.
Understand the design
Inspect devices, interfaces and VLANs in the full campus topology.
02 / IMPLEMENTATIONFollow the verified build
Nine implementation phases with 36 numbered verification tests.
03 / FAILURE TESTINGInvestigate the results
Fourteen resilience tests, six interactive investigations and the original evidence.
HQ Campus · OSPF Area 10
A two-tier collapsed-core design. Each distribution switch has four cost-10 point-to-point /31 links to its paired edge router for four-way ECMP, plus one cost-100 cross-link to the other edge router as an alternate path. HSRP gateway ownership is split between the distribution switches, and Rapid PVST+ root placement follows it, so each VLAN's Layer 2 path leads to its active gateway.
The diagram uses the same data as the signed-off topology page. Select any device or link to inspect it, trace a VLAN, or overlay the fault from any Phase 10 test.
Layer 2 redundancy
Po10 and Po20 dual-home hq-a1; Po30 joins the distribution pair.
Layer 3 redundancy
Never bundled; cross-links at cost 100.
Gateway redundancy
Priority 110/100 with preempt; STP root follows the Active gateway.
Control plane
Explicit Lo0 router IDs and point-to-point network type.
HQ Campus
Built one verified phase at a time
I wrote the design first, then built and verified it in phases, each with its own tests and evidence. Design intent stays separate from implementation: a surprising result is investigated and recorded, any accepted difference becomes a design deviation, and the design document is not rewritten to match the lab.
What counts as as-built
- ConfiguredCommands entered from the design.
- VerifiedExpected behaviour demonstrated and captured.
- Failure-tested where appropriateThe redundancy exercised, not assumed.
- Evidence recordedCLI captures and session records retained in Git.
- Faults resolved or documentedEach fault fixed, or recorded as it stands.
- Accepted as-builtOnly then described as verified as-built.
Records and traceability
HQ-VP-XX.YYVerification test: phase XX, test YY.HQ-TS-NNNTroubleshooting record, only where real diagnosis was needed.HQ-DEV-NNNAccepted difference between design intent and the as-built network.configs/hq/Sanitised running configurations for all five devices, tied to milestone commits.Reference IDs are permanent once assigned. They are never renumbered or reused, and the build log, reports, evidence and configs cross-reference each other by ID.
Lab platform
Edge routers run IOSv 15.9 and switches run IOSvL2 15.2. The campus uses all five nodes that Cisco Modeling Labs Free allows.14 tests, each reported as it happened
Phase 10 tested the campus under controlled link, EtherChannel and device failures, including a combined two-device outage. I recorded what the network did and how it recovered, using IP SLA probes, sourced pings, routing and CEF lookups, and device logs.
A test can fail or confirm a design limitation as well as pass. Each result below is the one its test report records.
Choose All tests or a category to see each fault, what happened and the report behind it.
| Test | Fault injected | Layer | What happened | Result | Detail |
|---|
The Phase 10 index lists 10.01 and 10.09 as PASS. Their own reports record BASELINE ESTABLISHED and DESIGN LIMITATION CONFIRMED, and this page uses the reports' wording. Report links open the evidence in the project repository at commit 6bd19be.
Step through six of the tests
Each walkthrough replays a test on the full topology diagram. Step from before the failure to recovery and watch the routes, probe results and animated request and reply paths change, with the recorded checks and captured CLI behind them. Every drawn path is labelled Observed Inferred or Untested.
The signed-off HQ Campus topology
The diagram every walkthrough builds on, with full interface schedules for all five devices, the VLAN and gateway table and the complete addressing plan.
Open the topologyWhat the failures showed me
Several alternate paths worked as designed, and the isolation tests exposed real limits in the design. The most useful part for me was working out why traffic stopped.
The main lesson from these tests is that redundancy has to be checked across the whole traffic path, in both directions. An interface being up or a gateway showing Active does not prove that traffic can reach its destination and get back.From my Phase 10 engineering review
Priorities for the next revision
From my engineering review. These changes were not implemented or tested in Phase 10; they belong to a separate design revision and test cycle.
- HSRP upstream trackingTest object or route-health tracking, with a priority decrement and preemption policy that move the gateway role when upstream connectivity is lost.
- An independent inter-distribution connectionKeep Root Guard on the access-facing port-channels and add a separate Layer 2 path between hq-d1 and hq-d2, then test root placement, loop prevention and HSRP during failure and recovery.
- Time synchronisation and continuous monitoringConfigure and verify NTP before testing, and add central logging and continuous traffic probes alongside the manual CLI checks, so events line up across devices and outages can be measured.
GitHub is the source of truth.
The repository allows me to revisit earlier network states, track changes and verify their impact against recorded evidence, rather than simply presenting a finished configuration.
Version-controlled network engineering
GitHub provides version control and change management throughout the ongoing project. I use Git Bash, feature branches, structured commits and pull requests to manage each development phase. Configuration snapshots, CML topology exports, CLI evidence and test results are retained alongside the engineering records, providing a traceable history of the network's development.
The repository tells the engineering story. The interactive portfolio brings it to life.
Branch → Build → Verify → Review → Merge
I followed a structured testing framework, verifying each implementation stage and testing how the network responded to failures. After each change, I repeated relevant verification checks to confirm that previously working network functions still behaved as expected. These manual regression checks helped me identify unexpected changes, investigate findings and check the evidence behind each conclusion.
The classifications above distinguish what I directly observed, what I inferred from recorded evidence and what remains untested.