Lab 12: Capstone -- Enterprise Operational Playbook Workshop

Chapter: Capstone
Duration: 270 minutes (3 hours)
Tools: All course tools
Points: 40

Overview

Lab 12 is the capstone laboratory session for NET-201. It is not a step-by-step guided exercise -- it is a structured workshop where you build and document a functional multi-protocol network environment and produce the Enterprise Operational Playbook described in CAPSTONE.md.

This lab session provides guided time to build the technical evidence that your playbook documents. You must actually configure working systems, not just write theory.

Minimum Technical Demonstrations

Your playbook must be grounded in at least the following working demonstrations, each of which you complete during this session and capture as evidence:

Demonstration 1: Multi-Area OSPF or BGP Dual-ISP (60 min)

Build and document ONE of the following (your choice, justified in the playbook):

Option A: OSPF Multi-Area with ABR

# Deploy Lab 1 topology (or your own variant)
containerlab deploy -t topo-ospf4.clab.yml

# Capture evidence:
docker exec clab-ospf4-r2 vtysh -c "show ip ospf database" > /tmp/capstone/ospf-lsdb.txt
docker exec clab-ospf4-r3 vtysh -c "show ip route ospf" > /tmp/capstone/ospf-routes.txt

Option B: BGP Dual-ISP with LOCAL_PREF Policy

# Deploy Lab 2 topology (or your own 2-ISP variant)
# Configure AS 65001 (Meridian) peering with AS 65002 and AS 65003
# Implement LOCAL_PREF 200 for AS 65002 (primary ISP)

# Capture evidence:
docker exec clab-bgp-r1 vtysh -c "show ip bgp" > /tmp/capstone/bgp-rib.txt
docker exec clab-bgp-r1 vtysh -c "show ip bgp neighbors" > /tmp/capstone/bgp-neighbors.txt

Playbook evidence required:

• Screenshot or terminal output showing the working routing configuration
• Configuration file (vtysh running-config) saved to /tmp/capstone/
• At least one route map configuration that implements your stated policy

Demonstration 2: TLS Configuration and Certificate Chain (30 min)

Configure nginx or openssl s_server with your TLS policy:

mkdir -p /tmp/capstone/tls

# Option A: Use openssl to create a self-signed internal CA + leaf cert
# (simulates Meridian's internal PKI)
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \
  -out /tmp/capstone/tls/ca-key.pem

openssl req -new -x509 -key /tmp/capstone/tls/ca-key.pem \
  -out /tmp/capstone/tls/ca-cert.pem -days 3650 \
  -subj "/CN=Meridian Internal CA/O=Meridian Health Partners"

# Generate leaf key + CSR + sign
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \
  -out /tmp/capstone/tls/server-key.pem

openssl req -new -key /tmp/capstone/tls/server-key.pem \
  -out /tmp/capstone/tls/server.csr \
  -subj "/CN=intranet.meridian.local/O=Meridian Health Partners"

openssl x509 -req -in /tmp/capstone/tls/server.csr \
  -CA /tmp/capstone/tls/ca-cert.pem \
  -CAkey /tmp/capstone/tls/ca-key.pem \
  -CAcreateserial -out /tmp/capstone/tls/server-cert.pem \
  -days 365 -sha256 \
  -extfile <(echo "subjectAltName=DNS:intranet.meridian.local,DNS:portal.meridian.local")

# Start test TLS server
openssl s_server -cert /tmp/capstone/tls/server-cert.pem \
  -key /tmp/capstone/tls/server-key.pem \
  -tls1_3 -port 4433 &

# Verify connection
openssl s_client -connect localhost:4433 \
  -CAfile /tmp/capstone/tls/ca-cert.pem \
  -tls1_3 < /dev/null 2>&1 | \
  grep -E "(Protocol|Cipher|subject|issuer|Verify)" > /tmp/capstone/tls/verification.txt

Playbook evidence required:

• Certificate chain (CA + leaf) saved to /tmp/capstone/tls/
• verification.txt showing TLS 1.3 negotiated and certificate verified
• Your nginx TLS configuration block (even if nginx is not running -- it must be syntactically correct)

Demonstration 3: DNSSEC Zone (30 min)

Build on Lab 5 or create a new zone:

mkdir -p /tmp/capstone/dns

# Create virtuslab.local zone (or meridian.local if you prefer)
# Generate keys + sign zone (per Lab 5 instructions)
# Save outputs:
dig +dnssec virtuslab.local DNSKEY @127.0.0.1 > /tmp/capstone/dns/dnskey.txt
dig +dnssec www.virtuslab.local A @127.0.0.1 > /tmp/capstone/dns/signed-record.txt

Playbook evidence required:

• DNSKEY response showing ZSK + KSK
• Signed A record with RRSIG
• Your named.conf zone declaration (with dnssec-policy)

Demonstration 4: NSM Sensor Deployment (30 min)

Run the NSM corpus through Suricata with your custom rule from Lab 8:

mkdir -p /tmp/capstone/nsm

# Run corpus through Suricata with custom rules
sudo suricata -c /etc/suricata/suricata.yaml \
  -r /tmp/nsm-corpus/dns_tunneling.pcap \
  -l /tmp/capstone/nsm/ 2>/dev/null

# Run Zeek with detection script
cd /tmp/capstone/nsm
zeek -C -r /tmp/nsm-corpus/dns_tunneling.pcap /tmp/dns-tunnel-detect.zeek

# Save evidence
cat /tmp/capstone/nsm/fast.log > /tmp/capstone/nsm/suricata-alerts.txt
ls /tmp/capstone/nsm/*.log > /tmp/capstone/nsm/zeek-logs-list.txt

Playbook evidence required:

• Suricata alert output showing your custom rule firing
• Zeek conn.log and dns.log present
• Your NSM sensor placement diagram (ASCII art in the playbook)

Demonstration 5: Bufferbloat Test (30 min)

Run a quick version of Lab 10's bufferbloat comparison:

mkdir -p /tmp/capstone/perf

# 15-second Flent test with TBF (bufferbloat scenario)
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
sudo tc qdisc del dev $IFACE root 2>/dev/null
sudo tc qdisc add dev $IFACE root tbf rate 10mbit burst 32kbit latency 400ms
iperf3 -s -D
flent rrul -H 127.0.0.1 -t "Bufferbloat" -l 15 -o /tmp/capstone/perf/bloat.png 2>/dev/null

# Apply FQ-CoDel
sudo tc qdisc del dev $IFACE root
sudo tc qdisc add dev $IFACE root fq_codel
flent rrul -H 127.0.0.1 -t "FQ-CoDel" -l 15 -o /tmp/capstone/perf/fqcodel.png 2>/dev/null

sudo tc qdisc del dev $IFACE root 2>/dev/null

Playbook evidence required:

• Both Flent plots saved to /tmp/capstone/perf/
• Your AQM configuration command (tc qdisc add)
• Measured RTT improvement (from your plots)

Playbook Assembly (90 min)

With your technical evidence gathered, write the playbook. Each section must reference at least one piece of captured evidence.

Section template to follow:

## Section N: [Topic]

### Design Decision
[State your choice and justify it in 2-3 sentences]

### Technical Configuration
[Show the relevant configuration excerpt]

### Verification
[Reference or paste the verification output from your evidence files]

### Trade-offs Accepted
[What did you give up by making this choice?]

Evidence Archive

Before submitting, archive all your evidence:

tar -czf net201-capstone-evidence-$(whoami).tar.gz /tmp/capstone/
echo "Evidence archive: net201-capstone-evidence-$(whoami).tar.gz"

Submit the archive alongside your playbook document. The grader will spot-check that your playbook's claims match the evidence.

Grading (40 points)

See CAPSTONE.md for the full rubric. Summary:

Binary gates (automatic Incomplete):

• Missing more than 2 required sections
• BGP configuration that would loop
• TLS policy permitting TLS 1.0 without exception
• No NSM sensors placed
• Document under 20 pages

Timeline Guidance

Submission Checklist

• Playbook document (PDF or Markdown): net201-capstone-LASTNAME.pdf
• Evidence archive: net201-capstone-evidence-LASTNAME.tar.gz
• All 9 required sections present
• At least 25 pages
• At least one configuration excerpt per section
• At least one diagram (can be ASCII art)
• Executive summary written for non-technical reader