Where Bandwidth Lives in the Routing Table Decision

A network engineer stares at a traceroute that defies logic — traffic flows across a 10 Mbps satellite link while a 1 Gbps fiber path sits idle. The root cause isn’t a hardware fault. It’s a misconfigured bandwidth metric. Across every major routing protocol and QoS framework, the bandwidth metric quietly dictates which path packets take, how much traffic a link can reserve, and whether an SLA survives the next congestion spike. For CCNA and CCNP candidates, understanding how bandwidth is measured, advertised, and manipulated separates textbook knowledge from troubleshooting skill. Cisco, Juniper, and Arista platforms all expose bandwidth values as a numeric representation of link capacity — but the way each protocol translates that number into a routing decision varies sharply.

Where Bandwidth Lives in the Routing Table Decision

Routing protocols do not read physical interface speeds directly. They consult a configured bandwidth value — often set in kilobits per second — that acts as the protocol’s view of link capacity. On a Cisco IOS device, the bandwidth interface command overrides reality: interface GigabitEthernet0/1 followed by bandwidth 10000 tells EIGRP and OSPF that this link is 10 Mbps, regardless of the actual 1000 Mbps line rate.

EIGRP and OSPF both use bandwidth, yet their formulas produce radically different outcomes. EIGRP computes a composite metric where bandwidth is combined with delay, load, reliability, and MTU (though only bandwidth and delay are standard). OSPF derives a single cost value based solely on reference bandwidth divided by interface bandwidth. BGP, notably, does not natively carry a bandwidth metric — a gap that forces engineers to rely on MED, local preference, or community-tagged policies to steer traffic across AS boundaries.

EIGRP’s Bandwidth-Driven Arithmetic

The Enhanced Interior Gateway Routing Protocol (EIGRP) treats bandwidth as a scaled inverse value. In the classic formula for calculating EIGRP metric, the metric equals 256 multiplied by (10⁷ / minimum bandwidth along the path plus the sum of delays divided by 10). Minimum bandwidth is the bottleneck along the entire path, measured in kbps. A single 100 Mbps link in a chain of 10 Gbps links forces the computation to use 100,000 kbps — pulling the metric up sharply.

The consequence: an engineer can tune EIGRP path selection by adjusting bandwidth on an interface without touching delay. Changing bandwidth 50000 to bandwidth 5000 inflates the composite metric roughly tenfold, diverting traffic elsewhere. However, the delay parameter is typical for fine-tuning because bandwidth changes also influence QoS policies that rely on the same configured value. CCNA labs frequently ask candidates to compare outputs of show ip eigrp topology before and after such modifications, while CCIE troubleshooting scenarios require pinpointing a metric mismatch caused by stale bandwidth statements on GRE tunnel interfaces.

OSPF Cost: When Reference Bandwidth Breaks Tie-Breaking

OSPF computes cost as reference bandwidth divided by interface bandwidth. The default reference bandwidth on Cisco devices is 100 Mbps (10⁸ bps), which caps any link faster than 100 Mbps at a cost of 1. This creates a problem: a 1 Gbps interface and a 10 Gbps interface both appear identical to OSPF. To restore differentiation, administrators set auto-cost reference-bandwidth 10000 under the OSPF process, raising the reference to 10 Gbps.

OSPF cost calculation based on reference bandwidth becomes critical in multi-vendor environments. Juniper’s Junos uses a reference bandwidth of 100 Mbps as well, but allows per-VRF cost scaling. When configuring OSPF across VLAN subinterfaces carrying different QoS classes, a mismatch in reference bandwidth between two routers can cause asymmetric routing — traffic out via a low-cost path returns through a high-cost path, breaking stateful firewalls. A show ip ospf interface brief command instantly announces the computed cost per interface, and the fix often involves aligning the reference bandwidth across all devices before fine-tuning individual link costs with ip ospf cost.

The BGP Blind Spot: No Native Bandwidth Metric

BGP does not advertise link bandwidth. A BGP next hop represents only reachability, not capacity. This absence becomes acute in SD-WAN fabrics and MPLS L3VPN designs where multiple paths exist with vastly different bandwidth profiles. Providers such as Palo Alto Networks’ SD-WAN and Cisco SD-WAN introduce a bandwidth overlay: the edge device measures path bandwidth through active probing and inserts a bandwidth metric into the SD-WAN policy, steering VoIP traffic toward low-latency paths and bulk backup onto high-bandwidth circuits.

In traditional BGP, engineers approximate bandwidth awareness by tagging prefixes with communities that map to a local preference or MED value. For example, a prefix learned from a 1 Gbps MPLS PE link might carry the community 64512:100, which the route-map translates to a local preference of 150, while the backup VRF path via a GRE tunnel over a 100 Mbps internet link receives local preference 90. The absence of an explicit bandwidth metric demands careful documentation — a point stressed in CCIE Service Provider lab tasks involving inter-AS QoS.

QoS and Bandwidth Reservation: Metric Becomes Guarantee

In QoS frameworks, bandwidth transforms from a routing factor into a resource reservation. CBWFQ (Class-Based Weighted Fair Queuing) on Cisco platforms uses the bandwidth and bandwidth remaining percent commands to allocate at least a specified amount of link capacity to a class. A classic LLQ (Low Latency Queuing) configuration for voice on a 2 Mbps serial interface might look like:

policy-map WAN-EDGE
class VOICE
priority percent 25
class CRITICAL-DATA
bandwidth percent 30

Here, 25% of the bandwidth metric — 500 kbps — is policed but prioritized, while 30% is guaranteed. If the actual throughput due to congestion dips below the reserved bandwidth, packets for CRITICAL-DATA still get dequeued ahead of best-effort traffic. The catch: the policy-map’s bandwidth percentages refer to the configured bandwidth on the interface, not the real clock rate. Setting bandwidth 2048 on a 2 Mbps serial link ensures the math works, but a 1 Gbps Ethernet interface defaults to 1,000,000 kbps — a 30% allocation would reserve 300 Mbps. A network engineer deploying QoS on an ACL-filtered VLAN must match the interface bandwidth statement to the actual policed rate, or the reservation logic fails silently.

Bandwidth vs Throughput: Why the Metric Lies Without Context

The bandwidth metric represents link capacity, not the achievable data rate. Throughput — the actual bits per second crossing the interface — is always lower due to protocol overhead, retransmissions, and congestion. The difference between bandwidth and throughput becomes critical when interpreting SNMP monitoring or flow data. An interface that reports a configured bandwidth of 1 Gbps but shows 150 Mbps of throughput on a monitoring dashboard isn’t broken; it may be limited by a 100 Mbps policer upstream or by TCP windowing across a high-latency path.

Network engineers can check actual utilization with show interface summary or SNMP OIDs. When troubleshooting why EIGRP selected a path with 10 Mbps bandwidth over one with 100 Mbps, a quick look at the delay metric often announces the answer. EIGRP’s composite metric gives bandwidth a scaled inverse value, but delay — measured in tens of microseconds — can swing the metric further than bandwidth differences alone. A link with 10 Mbps bandwidth and 1000 microseconds of delay can beat a 100 Mbps link with 20,000 microseconds of delay. The delay metric article explains this interaction with real-world lab examples.

Manipulating Bandwidth Metric in the Lab and Production

CCNP and CCIE candidates encounter bandwidth metric manipulation in routing protocol labs and design tasks. A common scenario: an enterprise runs OSPF between two sites connected by a primary MPLS link and a backup GRE tunnel over the internet. The tunnel interface defaults to a bandwidth of 9 kbps (the GRE default), giving OSPF a cost of over 11,000 with default reference bandwidth. The result: all traffic prefers the MPLS path. To make the GRE path usable as an active/standby, the engineer sets bandwidth 10000 on the tunnel interface, lowering the cost. Combined with OSPF’s ip ospf cost command, fine-grained control emerges.

STP (Spanning Tree Protocol) also uses bandwidth to assign path cost — 200 Gbps links get a cost of 2, 100 Gbps get 4, and so on. A misconfigured port bandwidth on a switch can skew STP root port election, diverting traffic through a slower uplink. VLAN trunks with LACP port-channels combine bandwidth additively; modifying the bandwidth statement on a port-channel interface adjusts routing protocol metrics for that logical bundle. In VRF-aware networks, a separate routing table per VRF can have distinct OSPF or EIGRP bandwidth settings, allowing multi-tenant isolation while sharing physical links.

Sustainable SLAs and the Bandwidth Metric Feedback Loop

Modern SD-WAN platforms close the loop between bandwidth metric and application performance. A Fortinet FortiGate SD-WAN rule can measure link latency, jitter, and packet loss, then map the results to a bandwidth score. If a 100 Mbps MPLS link begins dropping 2% of packets, its effective bandwidth metric in the SD-WAN policy falls, and the edge device shifts voice and video to a healthier broadband circuit. This active metric outperforms static bandwidth numbers in routing tables — a lesson that reshapes how CCIE Enterprise Infrastructure candidates prepare for design questions.

The takeaway for any network professional: the bandwidth metric is a configurable variable, not a fixed property. Whether it shapes EIGRP composite values, OSPF cost, QoS reservations, or SD-WAN path selection, its power lies in deliberate alignment with real-world capacity and policy intent. Ignore it, and the network silently routes traffic through bottlenecks that the CLI says should never exist.