Cisco Live 2026 Lab Build: A Small-Scale Reference Architecture
A Cisco Live lab does not need to reproduce an enterprise. It needs to reproduce the decisions engineers actually make: segment the campus, steer branch traffic, protect private apps, observe user experience, approve a change, and recover when the change is wrong. Build the lab around those workflows so it becomes a reusable design tool.
Design takeaway: the lab should produce reusable artifacts: topology, Internet Protocol (IP) plan, virtual routing and forwarding (VRF) and virtual local area network (VLAN) map, policy matrix, telemetry tests, failure injections, and rollback notes.
Reference Topology
Tie the lab back to the Cisco Live themes without forcing every product into the rack: Cloud Control, AgenticOps, Secure Access, Multicloud Fabric, and Cisco SD-Access-style segmentation. Physical Catalyst, Meraki, or Cisco routing platforms make the exercises richer, but virtual routers, containers, and cloud test VPCs are enough to validate the design logic.
Minimum Build
| Component | Minimum | Better | What It Validates |
|---|---|---|---|
| Campus edge | One switch or virtual L3 gateway with virtual local area networks (VLANs). | Two fabric edges with routed underlay and anycast gateway. | Endpoint classification, segmentation, and failure behavior. |
| Policy boundary | Firewall VM or access control list (ACL) router. | Stateful firewall plus identity-aware rules. | VRF handoff, inspection, network address translation (NAT), and denied-flow evidence. |
| Branch | One virtual router with two uplinks. | software-defined wide area network (SD-WAN) edge or router with application-aware path policy. | Branch-to-SaaS and branch-to-private-app steering. |
| Cloud | One VPC or VNet with test app and route table. | Two regions with transit and private Domain Name System (DNS). | Cloud route control, DNS, and failover visibility. |
| Telemetry | Ping, traceroute, logs, packet capture. | ThousandEyes plus device telemetry and app synthetic tests. | Root-cause separation across DNS, path, policy, and app. |
| Workflow | Markdown change record. | Approval flow with precheck, proposed diff, postcheck, rollback. | AgenticOps-style guardrails with human approval. |
IP, VRF, and VLAN Plan
| Zone | VRF | VLAN | Subnet | Gateway | Role Tags |
|---|---|---|---|---|---|
| Employees | USER | 110 | 10.10.10.0/24 | 10.10.10.1 | Employee, Admin |
| Contractors | USER | 120 | 10.10.20.0/24 | 10.10.20.1 | Contractor |
| Cameras | IOT | 210 | 10.20.10.0/24 | 10.20.10.1 | Camera |
| Printers | IOT | 220 | 10.20.20.0/24 | 10.20.20.1 | Printer |
| Guests | GUEST | 310 | 10.30.10.0/24 | 10.30.10.1 | Guest |
| Shared services | SHARED | 410 | 10.40.10.0/24 | 10.40.10.1 | DNS, Dynamic Host Configuration Protocol (DHCP), Network Time Protocol (NTP), AD |
| Branch users | BRANCH | 510 | 10.50.10.0/24 | 10.50.10.1 | BranchUser |
| Cloud app | CLOUD | none | 10.60.10.0/24 | cloud route table | App, Database |
Reserve loopbacks and transit space separately. For example, use 10.255.0.0/24 for infrastructure loopbacks and 10.255.10.0/24 for point-to-point routed links. That keeps endpoint tests from being confused with underlay reachability tests.
Policy Matrix
| Source | Destination | Expected Result | Reason |
|---|---|---|---|
| Employee | Shared DNS, DHCP, NTP | Allow | Baseline enterprise services. |
| Employee | Cloud private app Transmission Control Protocol (TCP) 443 | Allow | Business app access through policy boundary. |
| Contractor | Cloud private app TCP 443 | Deny or zero trust network access (ZTNA) only | Proves identity-based access difference inside USER. |
| Camera | Video management TCP 443 and RTP range | Allow | Device reaches only its application. |
| Camera | Employee subnet | Deny | Validates this camera-to-employee deny path; repeat for other lateral paths before treating the segment as protected. |
| Printer | Print server TCP 9100 or Internet Printing Protocol (IPP) | Allow | Documents service-specific exception. |
| Guest | Internet DNS and web | Allow after NAT | Guest egress only. |
| Guest | Any internal RFC1918 subnet | Deny | Confirms no internal route leak. |
| Admin | Network management Secure Shell (SSH) and Hypertext Transfer Protocol Secure (HTTPS) | Allow | Privileged access is explicit and logged. |
Lab Exercises
- Baseline: verify every subnet gateway, DNS answer, default route, and firewall zone before adding policy complexity.
- Segmentation: validate that USER, IOT, GUEST, SHARED, BRANCH, and CLOUD route domains are isolated except for documented services.
- Identity: change one endpoint from Employee to Contractor and validate that access changes without changing its IP subnet.
- SD-WAN concept: steer branch SaaS directly while sending private app traffic through the firewall and cloud route path.
- Secure Access concept: simulate ZTNA by allowing Contractor to the private app only through a controlled proxy or policy gateway.
- Telemetry: create tests from campus, branch, and cloud perspectives for DNS, Hypertext Transfer Protocol (HTTP), path trace, and app transaction time.
- Failure injection: break DNS, remove a route, deny an SGT-to-SGT policy relationship, flap an uplink, and expire a certificate.
- AgenticOps workflow: generate a proposed route or policy change, run prechecks, require approval, apply it, run postchecks, then roll it back.
Sample Test Cases
| ID | Test | Command or Method | Pass Condition |
|---|---|---|---|
| TC-01 | Guest isolation | From 10.30.10.50, connect to 10.40.10.10 and internet target. | Internal blocked, internet allowed after NAT. |
| TC-02 | Camera least privilege | From 10.20.10.50, test video server and employee subnet. | Video allowed, employee subnet denied with policy log. |
| TC-03 | Admin privilege | From Employee and Admin hosts, attempt SSH to network device loopback. | Only Admin role succeeds; both attempts logged. |
| TC-04 | Private app DNS | Resolve app.lab.example from campus, branch, cloud, and guest. | Campus and branch get private answer; guest does not. |
| TC-05 | Cloud path symmetry | Trace from branch to app and from app back to branch. | Both directions traverse intended firewall or fabric path. |
| TC-06 | Rollback | Apply pilot route, validate, withdraw route, validate old path. | Application works in both states; evidence is captured. |
| TC-07 | Telemetry diagnosis | Break DNS while keeping routing intact. | Monitoring flags DNS failure, not wide area network (WAN) outage. |
Artifacts to Keep
- A topology diagram with every routed handoff, firewall zone, NAT point, DNS resolver, and cloud route table.
- A source-of-truth file for subnets, VLANs, virtual routing and forwarding instances (VRFs), role tags, route targets, test users, and app VIPs.
- A policy matrix that includes denied flows, not only allowed flows.
- A precheck and postcheck list for every route, policy, DNS, and firewall change.
- A rollback note that names the exact route, policy, or DNS record to restore.
- Packet captures and telemetry screenshots for both working and broken states.
Acceptance Criteria
| Area | Pass | Not Ready |
|---|---|---|
| Segmentation | Allowed and denied flows match the matrix with logs. | Reachability works but deny reasons are unclear. |
| Cloud access | Branch and campus paths have documented route, DNS, firewall, and return behavior. | Forward path is known but return path is assumed. |
| Telemetry | Failure injections produce distinct signals for DNS, path, policy, and app. | All failures appear as generic outage alerts. |
| Change workflow | Precheck, approval, postcheck, and rollback are repeatable. | Rollback depends on memory or console history. |
| Reuse | Artifacts can seed a production design review. | The lab only produced screenshots. |
Cisco References
- Cisco Cloud Control
- Cisco AgenticOps
- Cisco Secure Access
- Cisco Multicloud Fabric
- Cisco SD-Access Design Guide
Related foundation post: Cisco Live 2026: Network Announcements That Matter.
Need help applying this?
Bring TechGeeks into the real environment.
If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.

