Creating Delay to a Subnet Tech Tip

I received a question on how to create a delay to a subnet using GNS3.

 Emulating delay on a subnet allows engineers to replicate real-world latency conditions in a controlled lab environment. Production networks—especially broadband, MPLS, SD-WAN, Internet, satellite, or cellular transport paths—rarely behave like low-latency LANs. By introducing deterministic round-trip delay, you can observe how applications and protocols respond under realistic WAN conditions. This is critical for validating TCP congestion control behavior, retransmission logic, API timeout handling, and performance differences between transport protocols such as TCP and QUIC before deployment.

Latency also has a direct impact on quality of service and real-time applications. Voice, video, and interactive systems are highly sensitive to delay and jitter. Emulating delay allows you to verify QoS classification, queuing strategy effectiveness, traffic shaping policies, and end-to-end service level objectives. It also exposes how jitter buffers behave, how MOS scores degrade, and whether control-plane protocols converge within acceptable thresholds under impaired conditions.

From a performance engineering standpoint, delay directly affects throughput due to the bandwidth-delay product. High-capacity links with significant round-trip time require proper TCP window scaling and buffer sizing to achieve full utilization. Without delay emulation, lab tests often produce unrealistically optimistic results. Introducing controlled latency enables accurate modeling of long-haul fiber paths, cloud region separation, multi-site replication, remote VPN users, and distributed systems that depend on timing stability and consensus behavior.

Finally, delay emulation is invaluable for packet-level troubleshooting and training. Latency alters observable characteristics in packet captures, including RTT measurements, delta times, retransmission patterns, fast retransmit events, and timeout behavior. For structured testing, resilience validation, or advanced protocol analysis, introducing delay allows engineers to reproduce edge conditions, validate routing timers, and determine at what thresholds instability or SLA violations occur. In short, controlled delay transforms a lab from a best-case simulation into a realistic network validation environment.

Below is my answer:

You can also do this in Linux!

tc qdisc add dev eth0 root netem delay 50ms

Comments are welcomed below from registered users.  You can also leave comments at our Discord server

If you would like to see more content and articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!

Leave a Comment

Scroll to Top