NET-201 Capstone: Enterprise Operational Playbook

Assignment: VCA-NET-201 Final Capstone
Weight: 40 points (of 150 total lab points; ~27% of course grade)
Format: 25-35 page technical document (PDF or Markdown)
Submission: 7 days after Week 14 workshop session
Prerequisites: Labs 1-11 completed or in progress; Week 14 workshop attended

Scenario

You are the network architect for Meridian Health Partners, a small regional healthcare company. They operate:

• Primary site (Portland, OR): 200 staff; 3 office floors; clinical workstations + admin PCs + VoIP phones
• Branch site (Eugene, OR): 30 staff; single floor; remote desktop to Portland for clinical systems
• Collocated datacenter rack (Portland): 8 physical servers running KVM/libvirt; 2 storage nodes; no cloud
• SaaS workloads: Microsoft 365 (email, collaboration); no self-hosted email

Compliance context: Meridian is not formally HIPAA-regulated (they do not handle ePHI directly) but they follow HIPAA-adjacent practices as a contractual requirement with their clinical partners. TLS everywhere, audit logging, and no insecure protocols are hard requirements.

Network constraints:

• Portland site has dual ISP: AS 65002 (100 Mbps fiber, primary) and AS 65003 (50 Mbps cable, backup)
• Branch site has single ISP: AS 65004 (50 Mbps fiber); connects to Portland via IPsec VPN
• Datacenter is on the same LAN as Portland primary (on separate VLANs)
• No budget for commercial SD-WAN; routing must use open-source tools

Deliverable: Enterprise Operational Playbook

Produce a complete operational playbook covering all nine required sections. The playbook must be written as if handed to a competent network engineer who has never seen this network. It must contain enough specificity that they could re-implement it from scratch.

Required Sections

Section 1: Executive Summary (1 page)

Write for a non-technical manager. Describe:

• What the network does (1-2 sentences)
• The top three design decisions and why they were made (3 bullet points)
• Any outstanding risks or deferred capabilities

No jargon without a one-sentence lay explanation.

Section 2: Routing Architecture (3-4 pages)

Cover all of the following with justification:

Internal routing (Portland primary + datacenter):

• Choose OSPF or IS-IS for the internal IGP; justify the choice
• Area design (single area vs. multi-area); justify
• Adjacency diagram (which routers peer; include interface names and IP addresses)
• Reference bandwidth configuration (must not be default 100 Mbps)

Dual-ISP BGP at Portland:

• AS number for Meridian (use a private ASN from 64512-65534)
• eBGP peering to AS 65002 and AS 65003
• LOCAL_PREF policy: prefer AS 65002 for all outbound traffic
• Backup route: how does AS 65003 route take over when AS 65002 is down?
• Inbound traffic shaping: AS_PATH prepending or MED to steer inbound toward AS 65002

Branch VPN:

• IPsec VPN between Portland and Eugene (site-to-site)
• Routing within VPN: static routes or BGP over GRE; justify
• Failover: what happens if the VPN tunnel drops?

Configuration excerpts required:

• FRR vtysh BGP configuration for the Portland border router (neighbor statements, route-maps)
• FRR vtysh OSPF configuration for the Portland internal router
• Route map for LOCAL_PREF policy

Section 3: Switching Architecture (2-3 pages)

VLAN design: Design a VLAN layout for Portland primary site. Include at minimum:

• Management VLAN (switches, APs, printers)
• Clinical workstations VLAN
• Admin/staff VLAN
• VoIP VLAN
• Datacenter servers VLAN (on the datacenter ToR switch)
• DMZ VLAN (internet-facing services)

For each VLAN: VLAN ID, subnet (use RFC 1918 addressing), purpose, and which physical switches carry it.

STP/RSTP:

• Choose RSTP (recommended) or provide justification for disabling STP entirely
• Root Bridge placement: which switch; how is the priority set?
• PortFast: which ports; verify no switch-to-switch ports have PortFast enabled

Inter-VLAN routing:

• Layer-3 switch or router-on-a-stick; justify
• Which VLANs can route to each other; which are isolated?

Configuration excerpts required:

• Switch port configuration for one trunk port and one access port (IOS or Linux bridge syntax)
• Inter-VLAN routing configuration (SVIs or sub-interfaces)

Section 4: TLS Policy (2-3 pages)

Certificate infrastructure:

• Public CA for externally-facing services (which services; Let's Encrypt or commercial?)
• Internal PKI for internal services (which CA software; root + intermediate structure)
• Certificate inventory table: list every cert-bearing service; cert type (public/private); validity period; renewal method (manual/certbot/ACME)

TLS enforcement:

• Minimum TLS version for each service category (web servers, VPN endpoints, email relays if any, internal APIs)
• Cipher suite whitelist for TLS 1.2 (for any legacy services that cannot yet run TLS 1.3)
• Prohibited: TLS 1.0, TLS 1.1, SSLv3, RC4, 3DES, NULL ciphers, export ciphers

TLS inspection:

• Is TLS inspection deployed? If yes: which device, which traffic, how are pinned apps handled?
• If no: what compensating controls exist for encrypted traffic visibility?

OCSP stapling:

• Enabled on all public-facing HTTPS services?
• Any exceptions and rationale?

Configuration excerpts required:

• nginx TLS configuration block (minimum TLS version, cipher suite, OCSP stapling)
• Certificate renewal cron job (certbot or ACME-based)

Section 5: DNS Architecture (2-3 pages)

Zone inventory:

• Which zones does Meridian own and operate?
• Authoritative nameserver software (BIND 9 or Knot DNS); primary/secondary setup
• External DNS (what is hosted externally vs. self-hosted?)

Recursive resolver:

• BIND 9 or Unbound for internal clients
• Forwarding to DoT upstream resolvers (1.1.1.1@853, 8.8.8.8@853) vs. recursive resolution; justify
• Split-DNS: internal view for meridian.local; external DNS for public-facing names

DNSSEC:

• Which zones are DNSSEC-signed?
• Key algorithm (ECDSAP256SHA256 recommended)
• NSEC vs. NSEC3 choice and rationale
• Key rollover schedule (ZSK: annual; KSK: biennial is a common baseline)

DoT/DoH policy:

• Are internal clients using DoT forwarding to upstream resolvers?
• Is browser-level DoH blocked (to preserve internal DNS policy)?

DNS monitoring:

• Is Zeek dns.log enabled on the NSM sensor? How long is it retained?

Configuration excerpts required:

• Named.conf fragment (zone declaration with DNSSEC policy)
• Unbound or BIND forwarder configuration with DoT
• dig command output showing a signed zone response

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

Current state:

• NAT44 at Portland border router
• IPv6 assignment: has Meridian requested a /48 from ARIN? (If not, plan includes timeline to do so)

IPv6 plan:

• Choose dual-stack, NAT64, or deferred (with timeline)
• If dual-stack: which prefix, which interfaces, SLAAC vs. DHCPv6 for clients
• If NAT64: which servers require NAT64; DNS64 configuration
• Address plan table: show IPv6 prefix allocation per site/VLAN

Transition timeline:

• When will IPv6 be deployed on the internal LAN?
• When will IPv6 be enabled on public-facing services?
• What is the last IPv4-only dependency and when will it be eliminated?

Section 7: SDN and Automation (1-2 pages)

Is SDN deployed? Choose one of: A. No SDN; configuration management via Ansible playbooks (document which playbooks and what they manage) B. OpenFlow SDN on the datacenter edge (document controller choice, flow policy) C. EVPN/VXLAN for datacenter (document VNI layout, VTEP placement)

Justify the choice given Meridian's size and budget constraints.

Network automation:

• How are switch configurations pushed? (Ansible/Netconf/manual)
• Is configuration stored in Git? (It should be.)
• Is there a network-as-code review process?

Section 8: NSM Deployment (2-3 pages)

Sensor placement: Place sensors at every point where threats can enter or where east-west movement is observable. Include:

• Internet ingress (between border router and firewall)
• VPN ingress (between VPN termination and internal network)
• Datacenter north-south (between server VLAN gateway and rest of LAN)
• Optional: SPAN port on clinical VLAN switch

Include a sensor placement diagram.

Suricata configuration:

• Rule sets enabled (ET Open minimum; any custom rules)
• Inline (IPS) or passive (IDS)? Justify
• At least one custom rule relevant to Meridian's environment (e.g., detect RDP brute force, detect DNS queries to newly-registered domains, detect TLS to self-signed certs)

Zeek configuration:

• Which logs enabled (conn, dns, http, ssl, files, x509 at minimum)
• Log retention: how long, how much storage?
• Any custom Zeek scripts (one example required)

Alert pipeline:

• Where do Suricata eve.json alerts go? (Local file, Elasticsearch, syslog, SIEM)
• Alert triage process: who reviews, how often?

PCAP retention:

• Which sensors store PCAP? How long?
• Storage estimate: at 10 Gbps link, full PCAP retention for 24 hours = ~108 TB. At 100 Mbps, 24 hours = ~1.08 TB. Show your math.

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

SLA targets:

• VoIP (SIP): < 150ms RTT, < 1% packet loss, < 30ms jitter
• Videoconference: < 100ms RTT
• Clinical workstation (remote desktop to datacenter): < 50ms RTT
• Internet browsing: no SLA; best effort

AQM configuration:

• Apply FQ-CoDel or CAKE to the Portland border router's outbound interfaces
• Configuration command (tc qdisc add dev eth0 root fq_codel OR cake bandwidth X)
• Verify with a Flent RRUL test: document expected pre/post latency improvement

TCP congestion control:

• CUBIC (default) or BBR? Justify for Meridian's link types (fiber primary, cable backup)
• DSCP marking: VoIP -> EF (46), videoconference -> AF41 (34), best-effort -> CS0 (0)

Monitoring:

• How is latency SLA monitored? (Prometheus Blackbox Exporter, synthetic ping, Flent cron)

Evaluation Rubric (40 points)

Binary Gates (automatic Incomplete)

• Missing more than 2 required sections
• BGP dual-ISP configuration that would create a routing loop
• TLS policy that permits TLS 1.0 without named exception + compensating control
• NSM section with no sensors deployed
• Document under 20 pages
• BGP AS numbers used without any private-ASN reservation rationale (e.g., using 1 or 65000)

Submission Format

• File name: net201-capstone-LASTNAME.pdf or net201-capstone-LASTNAME.md
• Diagrams: ASCII art or embedded images (PNG/SVG); diagrams must be readable in the submitted format
• Configuration blocks: fenced code blocks with appropriate syntax identifier (bash, conf, ```text)
• Page count: 25-35 pages when rendered as PDF at standard font size (11pt body, 10pt code)

Submit via the course LMS or directly to the instructor as specified in the Week 14 session.

Resources

These course resources should be referenced throughout the playbook:

• courses/net-201/week-{1-14}.md: all lecture notes and configuration examples
• handouts/cross-chapter-control-plane-architectures.md: SDN architecture comparison sidebar
• handouts/cross-chapter-docsis-quad-cross-cut.md: DOCSIS/SB6141 architecture (for datacenter context)
• handouts/cross-chapter-wireless-aka-progression.md: wireless AKA sidebar (for TLS comparison)
• RFC 8446 (TLS 1.3), RFC 4271 (BGP-4), RFC 4033-4035 (DNSSEC), RFC 7348 (VXLAN), RFC 7432 (EVPN)