NET-201 Week 14 -- Capstone Workshop: Enterprise Operational Playbook

"An engineer who can build a network but cannot document it has not finished the job. The playbook is the artifact that lets the next operator understand, extend, and defend what you built." -- NET-201 Course Philosophy

Workshop (50 min lecture + 270 min lab)

14.1 Capstone Scope

The NET-201 capstone is a constructive exercise: produce a complete Enterprise Operational Playbook for a small enterprise network. The playbook documents every design decision made across the course's 12 chapters, justifies the choices, and leaves a future operator with enough detail to operate, extend, and troubleshoot the network.

Scenario: a small-to-medium business with:

• 1 primary site (200 users); 1 branch site (30 users); 1 datacenter rack (collocated or on-prem)
• Dual-ISP connectivity at the primary site; single ISP at branch
• On-premise DNS, DHCP, and VPN; cloud-hosted SaaS workloads (Office 365 or equivalent)
• Security requirement: HIPAA-adjacent (strict TLS everywhere, no insecure protocols, audit logging)

This scenario is deliberately rich enough to touch every chapter. Students who cannot fit their design into the scenario constraints document their reasoning.

14.2 Playbook Structure

The playbook is 25-35 pages. Sections map directly to course chapters.

Required sections:

1. Executive Summary (1 page): what the network does, who it serves, the top-3 design decisions and why they were made. Written for a non-technical manager.

2. Routing Architecture (3-4 pages):

   • Primary site: routing protocol choice (OSPF vs IS-IS vs eBGP-unnumbered) + rationale
   • Branch connectivity: IPsec VPN overlay or MPLS; routing protocol within the overlay
   • Dual-ISP BGP: eBGP to both providers; LOCAL_PREF policy for preferred exit; MED or AS_PATH prepending for inbound traffic shaping
   • Route redistribution: where does the VPN overlay connect to the internal IGP?
   • Include: neighbor diagram, AS topology diagram, route-map configuration excerpts

3. Switching Architecture (2-3 pages):

   • VLAN layout: which VLANs, which subnets, which hosts in each VLAN
   • STP or RSTP (or disable STP entirely with LACP-only); Root Bridge placement
   • LACP bonds: where, how many members, which switch pairs
   • Inter-VLAN routing: Layer-3 switch or router-on-a-stick
   • Include: switch topology diagram, port-configuration table

4. TLS Policy (2-3 pages):

   • Internal vs. external CA: public CA (Let's Encrypt or commercial) for external services; private CA for internal services
   • Minimum TLS version: 1.3 for all new services; 1.2 with strong cipher suites only where 1.3 is not feasible; no 1.0/1.1
   • Certificate inventory: list all cert-bearing services; renewal automation (certbot or equivalent)
   • TLS inspection: is it deployed? If so, which devices and under what policy? How are certificate pinned apps handled?
   • OCSP Stapling: required for all public-facing services
   • Include: CA trust chain diagram; certificate rotation schedule

5. DNS Architecture (2-3 pages):

   • Authoritative: which zones, which nameserver software (BIND 9 or Knot DNS), primary/secondary
   • Recursive: BIND 9 or Unbound; forwarding to DoT resolvers vs. recursive resolution
   • DNSSEC: signed zones (yes/no for each zone); validation (yes/no); rollover schedule
   • DoT/DoH: internal clients forwarding to DoT? Browser-level DoH blocked or allowed?
   • Split-DNS: internal vs. external view for same domain?
   • Include: DNS architecture diagram; zone file excerpt; DNSSEC key management table

6. NAT and IPv6 Transition (1-2 pages):

   • Current state: dual-stack, NAT44 only, or IPv6-only with NAT64?
   • IPv6 address plan: which prefix, SLAAC vs DHCPv6, ULA vs global
   • NAT64/DNS64 plan (if applicable)
   • Timeline: when will IPv6 reach 100% internal coverage?
   • Include: address plan table; IPv6 prefix diagram

7. SDN / Automation (1-2 pages):

   • Is SDN deployed in any part of the network? (OpenFlow for campus, EVPN for datacenter fabric?)
   • Configuration automation: Ansible playbooks, Netconf/YANG, or manual?
   • Network observability: what monitoring is in place (SNMP, gRPC telemetry, OpenTelemetry)?

8. NSM Deployment (2-3 pages):

   • Sensor placement: where are the Suricata sensors? Zeek sensors?
   • Which Suricata rule sets (ET Open, custom)? Tuning approach?
   • Which Zeek logs are enabled? Where are they stored? Retention period?
   • Alert pipeline: Suricata eve.json -> where (SIEM, ELK, Splunk, local)?
   • PCAP retention: which links, how much storage, how long?
   • Include: sensor placement diagram; rule/script inventory; PCAP retention table

9. Performance SLA and AQM (1-2 pages):

   • Latency SLA for critical applications (VoIP < 150ms, videoconference < 100ms)
   • Bufferbloat mitigation: FQ-CoDel or CAKE on edge interfaces?
   • TCP congestion control: CUBIC or BBR? QoS marking (DSCP)?
   • Baseline measurement: how is performance monitored? (Flent periodic tests, synthetic monitoring)

10. Datacenter Fabric (1-2 pages, if applicable):

    • If on-premise datacenter: leaf-spine or traditional three-tier?
    • VXLAN-EVPN: which VNIs, which tenants?
    • Underlay: eBGP (RFC 7938) or OSPF?

11. Security Posture Summary (1 page):

    • Protocol risk inventory: which protocols are running; which are insecure; compensating controls
    • Incident response contact list
    • Audit logging summary: what is logged, where, how long retained
    • Compliance mapping (if HIPAA-adjacent): which controls map to HIPAA Security Rule §164.312

14.3 Evaluation Rubric

The playbook is evaluated on four dimensions.

Technical correctness (40 points):

• Routing protocol selection is justified with reference to the scenario constraints
• BGP dual-ISP configuration is technically correct (AS numbers, LOCAL_PREF policy, neighbor statements)
• TLS policy is coherent and enforces minimum TLS 1.2 (TLS 1.3 preferred)
• DNSSEC and DoT/DoH policies are correctly specified (not confused with each other)
• NSM sensor placement covers ingress/egress and east-west paths
• No technically incorrect statements (e.g., claiming DNSSEC encrypts DNS queries)

Depth and completeness (30 points):

• All 9 required sections present and substantively complete
• Design choices explained with technical rationale (not just "we chose OSPF")
• Configuration excerpts included where specified (FRR vtysh, named.conf, Suricata rule, etc.)
• Diagrams are accurate and readable (may be ASCII art or drawn; must be correct)

Practical viability (20 points):

• Design could actually be implemented with tools covered in the course (no imaginary features)
• No contradictions between sections (e.g., claiming DNSSEC validation and DoH bypass simultaneously without resolving the conflict)
• Resource constraints acknowledged (e.g., a 30-user branch site does not need a full Zeek cluster)

Communication quality (10 points):

• Executive summary is readable by a non-technical manager
• No jargon without definition in the body text
• Configuration excerpts are syntactically correct and properly commented
• No LLM-tell prose patterns (no em-dashes, no "leverages", no megasentence asides)

14.4 Binary Gates

The following failures result in an automatic Incomplete (resubmission required):

• Missing more than 2 required sections
• BGP dual-ISP configuration that would create a routing loop or that is syntactically wrong
• TLS policy that permits TLS 1.0 without documented exception and compensating control
• NSM section that places no sensors (no visibility)
• Playbook under 20 pages (insufficient depth)

14.5 Workshop Schedule (3 hours lab)

Submission

Playbook submitted as a single PDF or Markdown document. If Markdown: all diagrams must render correctly in a standard Markdown viewer. Code blocks must use proper fence syntax. Configuration excerpts must be syntactically correct.

Submission deadline: 7 days after the Week 14 session.

Key Terms

• Operational playbook: a technical reference document that enables a future operator to run, extend, and troubleshoot a network without the original author; the NET-201 capstone artifact
• DSCP: Differentiated Services Code Point; 6-bit field in the IP header ToS byte; used for QoS marking; DSCP EF (Expedited Forwarding) for VoIP; DSCP AF41 for video; DSCP CS0 for bulk
• HIPAA Security Rule §164.312: HIPAA Technical Safeguards; includes §164.312(a)(2)(iv) encryption/decryption (TLS), §164.312(b) audit controls (logging), §164.312(c) integrity (DNSSEC, TLS), §164.312(e)(1) transmission security (TLS everywhere)
• Split-DNS: serving different DNS responses to internal vs. external clients for the same domain; common for internal services not exposed externally; requires careful DNSSEC configuration to avoid validation failures
• Synthetic monitoring: automated, scripted probes that simulate user actions to measure service availability and latency; distinct from passive NSM; examples: Prometheus Blackbox Exporter, Pingdom, internal Flent cron jobs