Course: VCA-NET-201 Intermediate Networking
Version: v0.1 pilot
Duration: 14 weeks
1. Course Philosophy
NET-201 is a depth course, not a breadth survey. Every protocol introduced here was already named in NET-101. The job of NET-201 is to make students fluent at production inspection depth: they can configure OSPF multi-area, read a BGP RIB, author a DNSSEC zone, dissect a TLS handshake, and write a Suricata rule that fires on a real attack.
The capstone is explicitly constructive: students build and document a network before they attack one in PEN-101. This sequencing is intentional.
2. Lab Network Specification
Minimum hardware
- 1 Linux workstation per student (Ubuntu 24.04 LTS; 16 GB RAM; 100 GB disk; Intel VT-x or AMD-V enabled for nested virtualization in GNS3)
- Instructor machine with 32 GB RAM for GNS3 VM hosting
- 10 Mbps LAN (minimum; 1 Gbps preferred for Wireshark capture labs)
Software stack (pre-installed by lab prep)
# Run on each student machine before Week 1
sudo apt update && sudo apt install -y \
docker.io docker-compose-v2 wireshark tshark nmap \
traceroute python3-scapy python3-pip iproute2 \
frr frr-pythontools bind9 bind9-utils bind9-dnsutils \
suricata zeek iproute2 iputils-ping curl wget jq git \
iperf3 netperf flent mitmproxy openssl gnutls-bin \
openvswitch-switch mininet tayga
# Containerlab
bash -c "$(curl -sL https://get.containerlab.dev)"
# FRR Docker image
docker pull frrouting/frr:latest
# Python: Ryu SDN controller
pip3 install ryu flent playwright
playwright install chromium
# Routinator (RPKI validator) - requires Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
cargo install routinator
routinator init
Smoke test (run before Week 1 session)
containerlab version
docker run --rm frrouting/frr:latest vtysh --version
openssl s_client -connect cloudflare.com:443 -tls1_3 < /dev/null 2>&1 | grep "Protocol"
named -v
suricata --build-info | head -3
zeek --version
python3 -c "from scapy.all import IP, TCP; print('Scapy OK')"
3. Week-by-Week Instructor Notes
Weeks 1-2 (OSPF + IS-IS)
Lab 1 prep: containerlab topology file topo-ospf4.clab.yml should be pre-staged on student machines. The Containerlab approach is recommended; GNS3 VM is an alternative for students who want the Cisco-closer CLI experience.
The 4-router OSPF multi-area topology is the reference configuration. Do not pre-stage the configuration -- students type it in. The point is to watch the neighbor state machine go through Down -> Full.
Common student mistakes:
- Forgetting to set the
router-idin FRR (FRR auto-derives a Router ID but it may not be deterministic in Docker environments) - Mismatching Hello timers between peers (FRR defaults are correct; errors appear if students copy-paste from Cisco documentation with different defaults)
ip ospf area Xon the wrong interface (verify withshow ip ospf interface)
BFD note (Week 2 homework): FRR's BFD daemon (bfdd) must be enabled in /etc/frr/daemons (set bfdd=yes) and the service restarted. Students frequently miss this.
IS-IS depth: IS-IS does not need hands-on configuration time in this course. Week 2's IS-IS section is conceptual and comparative. Lab 1 covers convergence measurement with OSPF; IS-IS is covered via the Doyle-Carroll reading and lecture discussion.
Weeks 3-4 (BGP)
Lab 2 prep: three-AS BGP topology. Assign AS numbers: 65001 (student), 65002 (upstream ISP), 65003 (peer). Pre-stage IP addressing (keep it simple: /30 point-to-point links). Students configure the BGP neighbor relationships and observe.
Prefix hijack demo: the sandboxed hijack (AS 65003 announces AS 65001's prefix) is a lecture demo, not an unsupervised student exercise. Walk through it live; students observe the RIB change. This is not harmful in a Containerlab sandbox but students should understand why it is harmful in the real Internet.
RPKI: Routinator takes 5-10 minutes to complete its initial sync from the RIPE, APNIC, ARIN, LACNIC, and AFRINIC RPKI repositories. Pre-start Routinator at the beginning of the class session to ensure it is ready.
Week 5 (Switching)
Lab 3 note: Linux bridge + veth is a valid substrate for VLAN + STP labs, but it has quirks. The Linux kernel STP implementation (bridge protocol) may behave differently than Cisco or Juniper STP in subtle ways (priority default, timer defaults). Make students aware. Containerlab with FRR + bridge containers is the recommended substrate.
PVST+ is Cisco proprietary: if students ask about running per-VLAN STP in FRR, note that FRR does not implement PVST+ (Cisco proprietary). Standard 802.1Q/RSTP per-VLAN is achievable with Linux bridges. For true PVST+ behavior, GNS3 with Cisco IOS is needed (requires Cisco license).
Week 6 (TLS)
SSLKEYLOGFILE: demonstrate this on the instructor machine live. Open Firefox with SSLKEYLOGFILE=/tmp/keys.log firefox &, visit any HTTPS site, then open Wireshark with the key file. The decryption is a compelling visual demonstration of what TLS normally hides.
mitmproxy + certificate pinning: some modern web apps (especially banking and mobile apps) implement certificate pinning. Demonstrate that mitmproxy fails on a pinned app (browser showing a certificate error despite the CA trust). This foreshadows PEN-101's SSL pinning bypass techniques.
Lab 4 note: openssl s_client produces verbose output. Have students pipe to a file and analyze offline rather than reading the scrolling terminal. A pre-prepared annotation sheet (matching RFC 8446 section numbers to openssl s_client -msg output lines) accelerates the dissection exercise.
Week 7 (DNS + DNSSEC)
BIND 9 inline signing: the dnssec-policy default with inline-signing yes is strongly preferred over the legacy dnssec-signzone workflow. The manual workflow is documented for historical reference; do not spend lab time on it.
The broken chain exercise: this is the most valuable part of Lab 5. Students replace the KSK with a newly generated key (creating a mismatch between the published DS record in the parent and the active KSK in the zone). A validating resolver returns SERVFAIL. This makes DNSSEC's failure mode concrete and memorable.
DoT and firewall blocking: demonstrate that port 853 (DoT) can be blocked by a firewall while port 443 (DoH) cannot. Use iptables -A OUTPUT -p tcp --dport 853 -j DROP on the lab machine; verify that DoT stops working while DoH continues.
Week 8 (NAT + IPv6)
tayga installation note: tayga may not be in Ubuntu 24.04's default repositories in all configurations. If apt install tayga fails, build from source (github.com/danieldent/tayga; straightforward autotools build). Pre-stage the build on student machines if time is a concern.
IPv6 connectivity in the lab: student machines may or may not have native IPv6 connectivity depending on the lab network. For Lab 6, use Containerlab to simulate both the IPv6-only client and the IPv4-only server in containers -- no native IPv6 required.
Week 9 (SDN)
Ryu Python compatibility: Ryu 4.x is Python 3.x compatible but may have import issues with newer Python 3.11+ versions. Test the specific Python/Ryu version combination before the lab session. Alternative: use Faucet (a production-grade OpenFlow controller with better Python 3.11 support).
Mininet + OVS cleanup: Mininet leaves network namespaces and OVS state if not properly cleaned up. Always end Mininet sessions with mn -c. If a student's topology is broken, run mn -c before attempting to re-deploy.
Lab 9 (SDN vs. OSPF convergence): this lab is intentionally comparative. Students should observe that OSPF reconverges in under 1 second with BFD (tuned from Week 2), while SDN reconvergence depends entirely on controller liveness. A dead Ryu controller means no new flow entries can be installed -- existing flows continue until they time out. This trade-off is the key lecture point.
Week 10 (NSM)
NSM corpus distribution: the NSM corpus (20-30 PCAP files) is distributed via the course file share at the beginning of Week 10. Each file has a companion manifest.json listing the TTP, ground truth (what's in the file), and expected detection signals. Students run the corpus through Suricata and Zeek; the manifest is their answer key.
Zeek version note: Zeek from the OpenBuildService PPA (zeek package) installs into /opt/zeek/. Add /opt/zeek/bin to PATH. Zeek scripts in /opt/zeek/share/zeek/ are the base policy scripts; do not modify them directly -- place custom scripts in /opt/zeek/share/zeek/site/.
Suricata rule tuning: the Suricata community rules (ET Open, via suricata-update) generate a high volume of alerts on real traffic. In lab (PCAP replay on controlled corpus), the false positive rate is low. Warn students that tuning for production is a separate skill.
Weeks 11-12 (Performance + Cloud Networking)
Flent requires a netserver on the remote end: for RRUL tests, run netserver -D -p 12865 on the remote machine. If a dedicated remote machine is not available, use a loopback test (flent -H 127.0.0.1) for concept demonstration -- but note that loopback eliminates the network path, so bufferbloat will not be visible.
Lab 10 bottleneck simulation: use tc tbf or tc netem (network emulator) to create an artificial bottleneck. netem can also add packet loss, delay, and jitter for more realistic testing. Pre-configure the bottleneck on the lab machine's outbound interface; students will observe bufferbloat, apply FQ-CoDel, and measure the improvement.
Lab 11 (VXLAN-EVPN): the Containerlab + FRR approach is the most reliable. Arista cEOS is an optional advanced substrate -- it is free to download (registration required) and provides a more realistic EVPN implementation, but adds image download complexity.
Week 13 (Cross-Cuts)
No new lab. This week is conceptual synthesis. Use the class time for:
- Q&A on any labs from Weeks 1-12 that students found difficult
- Capstone planning workshop (students share their 1-page outline; peers provide feedback)
- SB6141 demo: if the instructor has a physical SB6141, demonstrate the HTTPS management interface, the SNMP MIB browser, and the
arp -a+conntrack -Lcommands from LAN side
Week 14 (Capstone Workshop)
The 3-hour lab is a working session. Circulate and provide real-time feedback. Common issues:
- Students conflating DNSSEC (integrity) with DoH/DoT (privacy); correct immediately
- BGP dual-ISP section that does not specify AS numbers or LOCAL_PREF values; require specificity
- NSM section that says "deploy Suricata" without specifying where; require diagram placement
- TLS policy that permits TLS 1.0 "for legacy compatibility" without naming the legacy system; require specificity
4. Grading
Lab grading (60% of course grade): Labs 1-11 are each graded on a 10-point scale (see individual lab files for rubrics). Lab 12 (capstone playbook) is worth 40 points.
Total lab points: 10×11 + 40 = 150 points (normalized to 60% of course grade).
Homework grading (20% of course grade): 14 homework assignments; each graded pass/fail (0 or 1 point). A minimum of 10 passing homework submissions is required to receive a passing grade in the course.
Participation (20% of course grade): assessed on in-class Toolchain Diary sharing, peer review quality, and question engagement.
5. Academic Integrity
All lab work must be individually completed unless the lab explicitly specifies pair work. Suricata rules and Zeek scripts submitted for grading must be authored by the student. Playbook text must be original.
Students may use LLM assistants as research tools (to look up protocol details, explain concepts, or suggest approaches) but submitted work must be in the student's own words and must demonstrate genuine understanding. The oral component of graded labs (brief verbal explanation of design choices) is the primary integrity checkpoint.
6. SB6141 Lab Device Policy
If a physical SB6141 is used as a lab device, the following policies apply:
- Device must be completely isolated from any live cable plant or Internet connection
- DOCSIS channel must be terminated into a test CMTS or dead-terminated
- Students may access the SB6141's HTTPS management interface, SNMP MIB, and ARP table from the LAN side
- Students may NOT attempt to modify the DOCSIS configuration file or flash alternate firmware
- Any network traffic generated toward the SB6141 must stay within the isolated lab segment
See CAPSTONE.md for the full engagement rules of engagement.
7. Equipment Notes
FRRouting default daemon state
In Ubuntu 24.04, FRR daemons are disabled by default. Enabling additional daemons:
# /etc/frr/daemons
zebra=yes
ospfd=yes
bgpd=yes
isisd=yes
bfdd=yes
Restart FRR after editing: sudo systemctl restart frr
Wireshark capture permissions
By default, Wireshark requires root to capture. On student machines:
sudo usermod -aG wireshark $USER
sudo dpkg-reconfigure wireshark-common # select "yes" for non-root capture
newgrp wireshark # or log out and back in
BIND 9 logging for lab debugging
# Add to named.conf logging block for detailed query logging
logging {
channel query_log {
file "/var/log/named/queries.log" versions 3 size 5m;
severity dynamic;
};
category queries { query_log; };
};
8. NSM Corpus Manifest
The course NSM corpus ships as labs/nsm-corpus/ with the following directory structure:
labs/nsm-corpus/
├── manifest.json # Ground truth for all corpus files
├── arp_poisoning.pcap # ARP poisoning + MITM
├── bgp_update_anomaly.pcap # BGP prefix hijacking simulation
├── dns_tunneling.pcap # DNS query-based data exfiltration
├── icmp_tunneling.pcap # ICMP payload encoding
├── lateral_movement_smb.pcap # SMB lateral movement
├── port_scan_syn.pcap # SYN scan across /24
├── ssl_stripping.pcap # SSL stripping attack on HTTP upgrade
├── tls_cert_anomaly.pcap # TLS to self-signed suspicious cert
├── vlan_hopping.pcap # 802.1Q native VLAN double-tagging attack
└── dns_cache_poison_attempt.pcap # DNS cache poisoning attempt
Note to instructors: the corpus PCAP files are generated using Scapy + tcpreplay on the lab network. Do not use real captures containing actual user data. The generation scripts are in labs/nsm-corpus/generate/.