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.

Architecture diagram
Cisco Live Lab Reference Topology
The lab is a topology with campus, branch, policy, cloud, software as a service (SaaS), telemetry, and change workflow as separate systems.
LAB TOPOLOGY Campususers / IoT / guest BranchSD-WAN concept Firewall / SSE / ZTNApolicy boundary Cloud VPCprivate app SaaS / Internetegress target segments steer private egress OUT-OF-BAND TelemetryDNS, path, HTTP Change Workflowprecheck + rollback observe control
Keep diagrams, IP plan, policy matrix, failure injection results, and rollback notes as production design evidence.

Minimum Build

ComponentMinimumBetterWhat It Validates
Campus edgeOne 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 boundaryFirewall VM or access control list (ACL) router.Stateful firewall plus identity-aware rules.VRF handoff, inspection, network address translation (NAT), and denied-flow evidence.
BranchOne 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.
CloudOne 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.
TelemetryPing, traceroute, logs, packet capture.ThousandEyes plus device telemetry and app synthetic tests.Root-cause separation across DNS, path, policy, and app.
WorkflowMarkdown change record.Approval flow with precheck, proposed diff, postcheck, rollback.AgenticOps-style guardrails with human approval.

IP, VRF, and VLAN Plan

ZoneVRFVLANSubnetGatewayRole Tags
EmployeesUSER11010.10.10.0/2410.10.10.1Employee, Admin
ContractorsUSER12010.10.20.0/2410.10.20.1Contractor
CamerasIOT21010.20.10.0/2410.20.10.1Camera
PrintersIOT22010.20.20.0/2410.20.20.1Printer
GuestsGUEST31010.30.10.0/2410.30.10.1Guest
Shared servicesSHARED41010.40.10.0/2410.40.10.1DNS, Dynamic Host Configuration Protocol (DHCP), Network Time Protocol (NTP), AD
Branch usersBRANCH51010.50.10.0/2410.50.10.1BranchUser
Cloud appCLOUDnone10.60.10.0/24cloud route tableApp, 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

SourceDestinationExpected ResultReason
EmployeeShared DNS, DHCP, NTPAllowBaseline enterprise services.
EmployeeCloud private app Transmission Control Protocol (TCP) 443AllowBusiness app access through policy boundary.
ContractorCloud private app TCP 443Deny or zero trust network access (ZTNA) onlyProves identity-based access difference inside USER.
CameraVideo management TCP 443 and RTP rangeAllowDevice reaches only its application.
CameraEmployee subnetDenyValidates this camera-to-employee deny path; repeat for other lateral paths before treating the segment as protected.
PrinterPrint server TCP 9100 or Internet Printing Protocol (IPP)AllowDocuments service-specific exception.
GuestInternet DNS and webAllow after NATGuest egress only.
GuestAny internal RFC1918 subnetDenyConfirms no internal route leak.
AdminNetwork management Secure Shell (SSH) and Hypertext Transfer Protocol Secure (HTTPS)AllowPrivileged access is explicit and logged.

Lab Exercises

  1. Baseline: verify every subnet gateway, DNS answer, default route, and firewall zone before adding policy complexity.
  2. Segmentation: validate that USER, IOT, GUEST, SHARED, BRANCH, and CLOUD route domains are isolated except for documented services.
  3. Identity: change one endpoint from Employee to Contractor and validate that access changes without changing its IP subnet.
  4. SD-WAN concept: steer branch SaaS directly while sending private app traffic through the firewall and cloud route path.
  5. Secure Access concept: simulate ZTNA by allowing Contractor to the private app only through a controlled proxy or policy gateway.
  6. Telemetry: create tests from campus, branch, and cloud perspectives for DNS, Hypertext Transfer Protocol (HTTP), path trace, and app transaction time.
  7. Failure injection: break DNS, remove a route, deny an SGT-to-SGT policy relationship, flap an uplink, and expire a certificate.
  8. AgenticOps workflow: generate a proposed route or policy change, run prechecks, require approval, apply it, run postchecks, then roll it back.

Sample Test Cases

IDTestCommand or MethodPass Condition
TC-01Guest isolationFrom 10.30.10.50, connect to 10.40.10.10 and internet target.Internal blocked, internet allowed after NAT.
TC-02Camera least privilegeFrom 10.20.10.50, test video server and employee subnet.Video allowed, employee subnet denied with policy log.
TC-03Admin privilegeFrom Employee and Admin hosts, attempt SSH to network device loopback.Only Admin role succeeds; both attempts logged.
TC-04Private app DNSResolve app.lab.example from campus, branch, cloud, and guest.Campus and branch get private answer; guest does not.
TC-05Cloud path symmetryTrace from branch to app and from app back to branch.Both directions traverse intended firewall or fabric path.
TC-06RollbackApply pilot route, validate, withdraw route, validate old path.Application works in both states; evidence is captured.
TC-07Telemetry diagnosisBreak 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

AreaPassNot Ready
SegmentationAllowed and denied flows match the matrix with logs.Reachability works but deny reasons are unclear.
Cloud accessBranch and campus paths have documented route, DNS, firewall, and return behavior.Forward path is known but return path is assumed.
TelemetryFailure injections produce distinct signals for DNS, path, policy, and app.All failures appear as generic outage alerts.
Change workflowPrecheck, approval, postcheck, and rollback are repeatable.Rollback depends on memory or console history.
ReuseArtifacts can seed a production design review.The lab only produced screenshots.

Cisco References

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.

Request helpGet field notesRecommended gear

Leave a Reply

Your email address will not be published. Required fields are marked *