Core: Layer 3 Control Plane

Metric-based traffic engineering

Miro Kosut

Miro Kosut

— 3 min read
Share

In one line

Steer traffic by manipulating routing metrics/attributes - the cheapest TE lever, before you reach for tunnels (SR-TE / RSVP-TE).

The levers

  • IGP - cost/metric tuning: OSPF reference-bandwidth and per-link cost, IS-IS wide metrics, EIGRP delay/K-values; used to set primary vs backup paths.
  • BGP - local-preference (outbound), AS-path prepend / MED / communities (inbound), weight (local). See BGP in enterprise design.
  • Third-party next hop - advertise a next hop other than yourself (e.g. on a shared segment / IX) so traffic forwards directly and skips an extra hop.

Limits

Metric-based TE is coarse and global - changing a link cost shifts everything that uses it, sometimes with side effects. For deterministic, per-flow, or bandwidth-aware steering you need SR-TE / RSVP-TE (Network Virtualization batch).

A protocol-specific limit: classic EIGRP metrics saturate on fast links. The original composite scales bandwidth in kbps and delay in 10-microsecond units, so above ~10 Gbps the arithmetic bottoms out - an 11 Gbps and a 20 Gbps interface produce the same metric, and 1G/10G interfaces report identical delay - meaning path preference silently stops resolving exactly where modern designs need it. Wide metrics (64-bit, picosecond delay - a named-mode capability) restore the differentiation; alongside dual-stack address families, this is the second reason named mode is the modern EIGRP default (IGP selection - OSPF vs IS-IS vs EIGRP).

Two EIGRP traps on hybrid WANs

Steer with delay, never with bandwidth. Both feed the composite metric, but the interface bandwidth parameter is overloaded: EIGRP paces its own updates to a fraction of it, QoS percentage-based policies compute from it, and PfR reads it for load sharing - so bending it for path preference silently re-tunes three other systems. Delay feeds only the metric; it is the side-effect-free lever, applied per interface to rank otherwise-equal paths.

Administrative distance decides before your metric does. On an MPLS-primary / DMVPN-backup WAN, the MPLS routes arrive by redistribution from eBGP -> EIGRP external (AD 170), while an overlay running the same EIGRP AS delivers the backup as internal (AD 90) - the backup wins outright, and no metric tuning can help because AD is compared first. The fix is structural: run a separate EIGRP AS (or process) over the overlay and redistribute it at the hub, so both WAN paths arrive as external 170 - only then does the metric matter, and a delay bias on the overlay quietly ranks MPLS first (Redistribution and route manipulation).

Why it matters for design

Know when metric tuning is enough (simple primary/backup, basic load distribution) versus when the requirement (guaranteed bandwidth, explicit paths) forces real traffic engineering.

IPv6 / dual-stack note

Metrics are per-topology; verify v6 steers the same way as v4 (especially with separate OSPFv3).

Spaced repetition

For BGP, the outbound traffic-engineering lever is [...]; the inbound levers are AS-path prepend / communities / more-specifics.

For BGP, the outbound traffic-engineering lever is local-preference; the inbound levers are AS-path prepend / communities / more-specifics.

Advertising a next hop other than yourself so traffic forwards directly (skipping a hop) is the [...].

Advertising a next hop other than yourself so traffic forwards directly (skipping a hop) is the third-party next hop.

The main limitation of metric-based TE versus SR-TE/RSVP-TE is that it is [...] (no per-flow or bandwidth-aware paths).

The main limitation of metric-based TE versus SR-TE/RSVP-TE is that it is coarse and global (no per-flow or bandwidth-aware paths).

Classic EIGRP metrics [...] (11G and 20G links get the same metric) - wide metrics in named mode (64-bit, picosecond delay) restore path differentiation.

Classic EIGRP metrics saturate above ~10 Gbps (11G and 20G links get the same metric) - wide metrics in named mode (64-bit, picosecond delay) restore path differentiation.

Why is delay (not bandwidth) the EIGRP path-preference lever?

The bandwidth parameter is overloaded - EIGRP update pacing, QoS percentage policies, and PfR load sharing all read it - so changing it has side effects; delay feeds only the metric.

MPLS routes arrive as EIGRP-external 170 yet the DMVPN backup wins - why, and what is the fix?

The overlay runs the same EIGRP AS, so its routes are internal AD 90 and beat external 170 before metrics are even compared; split the overlay into its own AS/process and redistribute, making both paths external 170, then bias with delay.

Sources

  • Cisco Live BRKRST-2041 (2013): delay-vs-bandwidth rule, hybrid-WAN AD trap and split-AS fix.
  • Cisco Press, Optimal Routing Design; Routing TCP/IP Vol II.
  • Cisco Press, CCNP ENARSI 300-410 OCG (Edgeworth/Lacoste) - EIGRP wide metrics.

domain: Core · blueprint-ref: Core 3.7 Metric-based traffic flow and modification · type: concept · status: complete · tags:

Read more