Delay measures the time it takes for a packet to traverse a path, and it plays a very different role depending on which routing protocol is doing the measuring. EIGRP weighs delay directly in its composite metric by default. OSPF’s cost calculation, by contrast, is purely bandwidth-based and doesn’t factor in delay at all.
This guide covers exactly how delay is measured, configured, and validated — and it’s worth a brief transparency note up front: an earlier version of this article cited a specific vendor report, an anonymous “solutions architect” quote, a named academic study, and a research paper, none of which could be verified against any real publication. Those have been removed rather than repeated; what follows sticks to protocol mechanics and standards documentation that can be checked directly.
How Delay Fits Into EIGRP’s Composite Metric
EIGRP’s composite metric formula, in its default configuration, weighs delay equally alongside bandwidth: Metric = 256 × (BW + Delay). Delay is the cumulative sum of the delay values configured on every interface along the path, expressed in tens of microseconds — unlike bandwidth, which only considers the single worst link, delay adds up across the entire path.
This makes delay a genuinely useful lever for path tuning, since it can be adjusted on an interface independently of bandwidth:
Router(config)# interface Tunnel0
Router(config-if)# delay 2500This sets the interface’s delay contribution to 2,500 (in tens of microseconds — so 25,000 microseconds, or 25ms total). A worked, internally consistent example: comparing a 100 Mbps MPLS link with 5ms of latency (delay 500, in tens-of-microseconds units) against a 1 Gbps internet VPN tunnel with 25ms of real latency (delay 2500) — even though the tunnel has ten times the bandwidth, its much higher configured delay can prevent EIGRP from automatically preferring it purely because of the bandwidth advantage, which matters when the higher-bandwidth path also carries meaningfully worse latency due to encryption or internet transit overhead.
A note on adjusting K-values for delay sensitivity: it’s possible to change EIGRP’s K-value weighting via metric weights <tos> <k1> <k2> <k3> <k4> <k5>, but it’s worth being precise about what actually shifts the balance. Setting K1=1 and K3=1 — the values metric weights 0 1 0 1 0 0 produces — is simply EIGRP’s default weighting; it doesn’t increase delay’s influence relative to bandwidth at all, since both remain equally weighted.
To genuinely shift weighting toward delay and away from bandwidth, K1 would need to be reduced (potentially to 0, removing bandwidth from the calculation entirely) while K3 remains at 1. As covered in EIGRP Composite Metric, changing K-values also requires every neighboring router to match exactly, or adjacencies won’t form at all — a significant operational cost for a change that, in most designs, doesn’t actually need to happen, since the default equal weighting already accounts for both bandwidth and delay together.
OSPF: No Native Delay Sensitivity
OSPF’s cost calculation is based entirely on reference bandwidth divided by interface bandwidth — delay plays no role in the standard OSPF cost metric at all. Two links with identical bandwidth but very different latency (say, a low-latency fiber path and a high-latency satellite path of the same bandwidth) will compute to the exact same OSPF cost, and OSPF has no built-in mechanism to differentiate between them based on delay.
This is a meaningful design tradeoff worth understanding rather than a flaw: OSPF’s simplicity (one clear metric, purely bandwidth-derived) makes behavior predictable and easy to reason about across a large network, at the cost of being blind to latency differences that EIGRP’s composite metric would naturally capture. Where delay-aware path selection matters in an OSPF network, it typically has to be engineered around OSPF itself — through manual ip ospf cost adjustments on specific interfaces known to have latency issues, or by layering a separate SD-WAN or traffic-engineering solution on top that does account for measured latency.
BGP: Delay Has No Native Role Either
BGP’s path selection is driven by policy attributes — AS path length, local preference, MED, and community-based rules — none of which directly reflect measured link latency. As covered in Bandwidth Metric, this is the same fundamental gap BGP has with bandwidth: the protocol was designed around administrative policy between autonomous systems, not raw link performance characteristics. Delay-aware routing in a BGP-based design has to be handled outside BGP itself, typically through an SD-WAN overlay that actively measures path latency and steers traffic accordingly, independent of what BGP’s own best-path selection would otherwise choose.
Measuring Delay for Real: TWAMP and RFC 6374
Configured delay values (used by EIGRP’s composite metric) are static numbers an administrator sets — they don’t automatically reflect a link’s actual, current latency. For genuine, ongoing delay measurement, two real, standards-based mechanisms are worth knowing:
TWAMP (Two-Way Active Measurement Protocol), defined in RFC 5357, sends active probe packets between a sender and a responder to measure round-trip delay with precision, commonly implemented in tools like Cisco’s IP SLA and Performance Monitor features.
RFC 6374 defines a delay measurement mechanism specifically for MPLS networks, using probe packets in a defined format to measure link delay directly at the MPLS layer, which Cisco and other vendors implement in segment routing and traffic engineering features to feed real, measured delay into path selection decisions rather than relying purely on static configured values.
These mechanisms exist precisely because a statically configured delay value — like the one used in EIGRP’s composite metric — can drift out of sync with reality over time as actual network conditions change, and neither EIGRP nor OSPF automatically re-measures delay on their own.
When Delay Metrics and Modern TCP Behavior Diverge
Modern congestion control algorithms complicate the picture further. BBR (Bottleneck Bandwidth and Round-trip propagation time), developed by Google, is a genuinely real and increasingly adopted TCP congestion control algorithm — its third iteration, BBRv3, was publicly presented at IETF 117 in 2023 and has an active IETF standardization draft. BBR builds an explicit model of a path’s bandwidth and round-trip time to control how much data it sends, rather than relying on packet loss as the primary congestion signal the way older algorithms like Reno or CUBIC do.
Google’s own reported results for BBRv3 show a 12% reduction in packet retransmission rate, along with reduced queueing delay on bottlenecks with deep buffers — the phenomenon known as bufferbloat, where excessive buffering along a path inflates real-world latency well beyond what a simple configured delay value would suggest.
The practical implication: a network’s configured delay metrics reflect the network’s own view of path characteristics, but the actual end-to-end experience for TCP traffic increasingly depends on congestion-control behavior operating above the routing layer entirely. A routing protocol correctly selecting the lowest-delay path doesn’t guarantee an application actually experiences low latency if bufferbloat or congestion control behavior elsewhere in the path dominates the real user experience.
Validating Delay Configuration in Production
A few practical ways to confirm configured delay values match reality, rather than assuming a static configuration remains accurate indefinitely:
Compare configured vs. measured delay. show interfaces reveals the statically configured DLY value EIGRP uses; a TWAMP-based active measurement tool or Cisco’s IP SLA feature can measure the actual current round-trip delay on the same path, and comparing the two reveals whether the configuration still reflects reality.
Check EIGRP’s actual computed metric. show ip eigrp topology shows the Feasible Distance for each route, which reflects the delay value currently in effect — useful for confirming a delay change actually took effect as intended.
Use flow and NetFlow-style analytics to observe real path latency experienced by actual traffic, rather than relying solely on static routing-table configuration, particularly on paths where congestion or bufferbloat might be masking what the configured metric suggests.
Common Mistakes
Assuming a configured delay value stays accurate indefinitely. Since EIGRP’s delay is a static, manually configured value, it doesn’t automatically track real network conditions. A tunnel or WAN link that gets rerouted, upgraded, or degrades over time can leave its configured delay meaningfully out of sync with reality until someone actively remeasures and updates it.
Copy-pasting delay values between dissimilar links. A delay value tuned for a data-center interconnect or a well-controlled MPLS path doesn’t necessarily apply to a satellite link, a congested internet-based VPN tunnel, or any other path with fundamentally different latency characteristics. Applying a template delay value without adjusting it for the actual path’s real conditions can cause EIGRP to make confidently wrong path decisions.
Expecting OSPF to naturally avoid a high-latency path. Because OSPF cost is purely bandwidth-derived, a high-bandwidth but high-latency link can easily be preferred over a lower-bandwidth but low-latency alternative, since OSPF has no visibility into the latency difference at all. This is a design characteristic to plan around, not something that will self-correct.
Confusing a K-value change that restates the default with one that actually shifts weighting. As covered above, metric weights 0 1 0 1 0 0 is identical to EIGRP’s out-of-the-box default. Verifying the actual effect of a K-value change with show ip protocols before assuming it accomplished anything is a good habit, since the syntax alone doesn’t make it obvious whether a meaningful change was actually made.
Frequently Asked Questions
Does OSPF cost ever factor in delay?
No, not natively. OSPF cost is calculated purely from reference bandwidth divided by interface bandwidth. Any delay-aware behavior in an OSPF network has to be engineered separately, either through manual cost adjustments or an overlay solution like SD-WAN.
Why doesn’t increasing EIGRP’s K3 value alone do anything if K3 is already the default?
K3 already defaults to 1, alongside K1 also defaulting to 1 — both are already active and equally weighted in the standard formula. Setting K3 to a value it already has doesn’t change anything; genuinely shifting the balance toward delay requires changing the relative weighting, such as reducing K1.
What’s the difference between a configured delay value and measured delay?
A configured delay value (used in EIGRP’s composite metric) is a static number an administrator sets on an interface and doesn’t automatically update. Measured delay, via TWAMP (RFC 5357) or MPLS-specific mechanisms (RFC 6374), reflects the path’s actual, current round-trip latency through active probing, and can be used to feed real-time information into traffic engineering decisions rather than relying on a number that might be stale.
Is BBR relevant to routing protocol delay metrics?
Not directly — BBR operates at the TCP layer, controlling how a sending host paces its own traffic based on measured path characteristics, while routing protocol delay metrics operate at the network layer, controlling which path a router chooses. They’re solving related but distinct problems: BBR is about how much data to send on a chosen path; routing metrics are about which path to choose in the first place.
Why does EIGRP require matching K-values across all routers before changing delay weighting?
Because K-values (including which components are enabled and how heavily weighted) must match exactly for two EIGRP routers to form an adjacency at all. Changing weighting on one router without updating its neighbors doesn’t create a gradual shift in behavior — it breaks the adjacency outright until every router agrees.
Conclusion
Delay’s role varies sharply by protocol: EIGRP weighs it equally with bandwidth in its default composite metric, OSPF ignores it entirely in favor of a pure bandwidth-based cost, and BGP has no native concept of link performance at all. Real, active delay measurement — via TWAMP or MPLS-specific mechanisms — exists precisely because static configured values drift out of sync with actual network conditions over time. Getting delay metrics right matters, but it’s worth being precise about what a given configuration change actually does — as the K-value example here shows, a command that looks like it should shift weighting can sometimes just restate the default.
