You're staring at the lab instructions. But again. Module 09, Lab 9.2: Test WAN Throughput. The simulation loads. Here's the thing — you configure the traffic generator. You hit start. And then... you wait. The numbers crawl across the screen. Throughput. Latency. Jitter. Now, packet loss. You write them down. You answer the questions. You submit. Done Simple, but easy to overlook..
But here's the thing — did you actually understand what just happened? Or did you just follow the steps like a recipe and hope the grade comes back green?
I've watched dozens of students blow through this lab in twenty minutes. Day to day, i've also watched them fail the follow-up quiz because they couldn't explain why the TCP throughput dropped when latency doubled. The simulation isn't the point. Now, the numbers aren't the point. The point is building an intuition for how WANs actually behave under load — and why "bandwidth" on a datasheet almost never matches what you see in production.
Let's walk through it properly. Not the click-path. The why.
What Is Simulation Lab 9.2 Module 09 Test WAN Throughput
This lab shows up in a few networking curricula — most commonly Cisco Networking Academy's Enterprise Networking, Security, and Automation (ENSA) course, but also in similar WAN-focused modules from other vendors. The exact topology varies, but the core task is always the same: generate traffic across a simulated WAN link, measure the results, and analyze how link characteristics affect real throughput It's one of those things that adds up..
You're typically working with a router-to-router connection over a serial or Ethernet WAN interface. Even so, you capture throughput, latency, jitter, and loss. The lab gives you a traffic generator — sometimes built into the simulation (like Cisco's Traffic Generator tool), sometimes an external tool like iperf3 running on simulated endpoints. You run tests. Then you change something — add latency, reduce bandwidth, enable QoS, tweak TCP window size — and run it again.
The simulation abstracts the physical layer. That's the gift. No cable faults. No ISP congestion. Now, no BGP flapping. On the flip side, just clean, controllable variables. It lets you isolate one thing at a time.
The Typical Topology
Most versions of this lab use a simple two-site setup:
- Site A: Router + end device (PC or server)
- Site B: Router + end device
- WAN link: Serial (HDLC/PPP) or Ethernet with shaped bandwidth
- Traffic generator: Built-in or iperf3 on the endpoints
You'll see bandwidth constraints like 1.544 Mbps (T1), 100 Mbps with a policer, or 1 Gbps with artificial latency injected. The lab walks you through baseline tests, then "what if" scenarios.
Why It Matters / Why People Care
Here's the honest answer: most students treat this lab as a checkbox. They run the tests, copy the numbers, answer the multiple-choice questions, and move on. So three weeks later, they're in a job interview and someone asks, "We have a 100 Mbps circuit but only get 12 Mbps throughput over a single TCP flow to our cloud backup. Why?
Blank stare.
This lab — if you actually engage with it — is where you learn to answer that question. WAN throughput isn't about the circuit speed. It's about the interaction between bandwidth, latency, transport protocol, window sizing, and application behavior. The simulation strips away the noise so you can see each factor in isolation Worth knowing..
In the real world, you'll troubleshoot:
- Cloud replication stalling over a 50 ms RTT link
- VoIP quality tanking when a backup job starts
- TCP throughput collapsing because the receiver window never scaled
- Asymmetric routing causing out-of-order packets and retransmissions
This lab is the sandbox where you break things safely. So when they break in production, you recognize the pattern Most people skip this — try not to..
How It Works (and How to Actually Learn From It)
Don't just follow the steps. Think about it: treat each test run as an experiment. Predict the outcome before you hit start. Write it down. Then compare.
Baseline Test: Establish the Reference
The first run is usually a clean baseline — no added latency, no QoS, default TCP settings. You're measuring raw throughput over the configured WAN bandwidth.
What to watch:
- Does throughput match the link bandwidth? (Spoiler: rarely, even in simulation)
- What's the CPU utilization on the routers?
- Are there any drops in the interface counters?
Run it long enough. A 10-second iperf test tells you nothing about steady state. Run 60 seconds minimum. But 300 seconds if the sim allows. Watch the throughput graph — does it ramp up? Oscillate? Flatline?
Test 2: Add Latency — The Bandwidth-Delay Product Hits You
This is the big one. That's why the lab usually has you inject 50–100 ms of one-way latency (so 100–200 ms RTT). Run the same test.
Prediction time: What happens to throughput?
If you said "it stays the same because bandwidth didn't change" — that's the intuitive answer. And it's wrong for TCP Worth knowing..
Here's why: TCP throughput is bounded by the Bandwidth-Delay Product (BDP).
BDP (bits) = Bandwidth (bps) × RTT (seconds)
On a 100 Mbps link with 100 ms RTT:
BDP = 100,000,000 × 0.1 = 10,000,000 bits = 1.25 MB
That's the minimum window size needed to fill the pipe. Even with window scaling (RFC 1323), the OS has to negotiate and grow the window. Default TCP windows (64 KB without scaling) can't do it. If the simulation uses a stock Linux or Windows TCP stack with conservative defaults, you'll see throughput plummet — sometimes to single-digit Mbps.
Watch for:
- Retransmissions in the packet capture
- Slow window growth in the TCP stream graph
- Throughput stabilizing well below link capacity
This is the single most important lesson in the lab. Write it on a sticky note: Latency kills TCP throughput unless the window scales.
Test 3: UDP vs TCP — The Protocol Matters
Same latency. Switch to UDP. Blast traffic at line rate (or slightly above) Worth keeping that in mind..
What happens?
- UDP doesn't care about latency. It just sprays packets.
- Throughput hits the link limit (or the policer limit).
- But — packet loss appears. Jitter spikes. The receiver gets overwhelmed.
This is why VoIP and video use UDP (with RTP) — they need low latency and can tolerate loss. But they also need QoS. Which brings us to...
Test 4: Enable QoS — Prioritize the Right Traffic
Most versions of this lab have you configure a basic QoS policy: prioritize a "voice" class (UDP, DSCP EF) over a "data" class (TCP, best effort). Then run both simultaneously Most people skip this — try not to. Nothing fancy..
What to observe:
- Voice traffic: low latency
throughput, minimal loss — because QoS ensures it’s prioritized.
Think about it: - TCP data traffic: higher latency, potential congestion, but survives because it’s buffered and retransmits lost packets. Still, - Without QoS, voice packets get dropped, jitter spikes, and the call becomes unintelligible. With QoS, voice traffic maintains quality even as data traffic floods the link.
Test 5: TCP Window Scaling — Fixing the BDP Problem
After seeing TCP’s collapse under latency, force window scaling (RFC 1323) on both ends. Retest with the same 100–200 ms RTT Simple, but easy to overlook..
- Throughput should now approach the link bandwidth. The larger TCP window fills the pipe, allowing sustained data transfer.
- Watch for: Smoother window growth curves, fewer retransmissions, and throughput stabilizing near the link’s capacity.
- Key takeaway: TCP’s performance isn’t just about bandwidth — it’s about balancing latency, window size, and congestion control.
Test 6: Congestion Control in Action
Inject a bottleneck (e.g., reduce the WAN link to 10 Mbps mid-test) while TCP is active.
- Observe how TCP reacts: slow start, congestion avoidance, and retransmissions.
- Compare this to UDP, which ignores congestion and floods the link, causing buffer overflows and loss.
- Lesson: TCP’s congestion control adapts to network conditions, but it’s not magic. Misconfigured thresholds or excessive latency can still cripple performance.
Test 7: Real-World Scenario — Mixing Traffic Types
Simulate a production environment: voice, video, and HTTP traffic competing for bandwidth. Apply QoS policies to prioritize voice/video, throttle HTTP, and enforce minimum bandwidth guarantees.
- Expected results: Voice/video remains stable, HTTP traffic experiences latency spikes during congestion but doesn’t starve other traffic.
- What to break: Disable QoS and watch voice packets drop. Re-enable it and see the difference.
Conclusion
This lab isn’t just about tweaking knobs — it’s about understanding the interplay of latency, bandwidth, protocol design, and policy. You’ll see why TCP’s default settings fail under real-world conditions, why UDP is a double-edged sword, and how QoS isn’t a luxury but a necessity for modern networks. The takeaways are clear:
- Latency matters more than you think — especially for TCP.
- Bandwidth isn’t free; congestion control and window scaling are critical.
- QoS isn’t optional when mixing latency-sensitive and bulk traffic.
- Simulation ≠ reality — even in a controlled lab, surprises lurk (e.g., CPU spikes, buffer bloat).
By the end, you’ll have a visceral understanding of why network engineers obsess over RTT, BDP, and traffic prioritization. And if you’re designing a network, you’ll think twice before slapping “1 Gbps” on a link and calling it a day. The real work starts when the traffic starts flowing Simple, but easy to overlook..
