Committed Bandwidth vs Port Speed: Sizing and Auditing Circuit Capacity

Every circuit is described by two rates that sound interchangeable and are not. One is the rate you bought, written into the contract and enforced by the carrier’s policer. The other is the rate the physical interface can pass, set by the optic and the port you plugged into. When they match, nothing needs explaining. When they diverge, as they usually do, the gap becomes a documentation problem long before it becomes a performance problem, because a team reading the wrong number will either accept a ceiling that should not exist or expect throughput nobody sold them.

The fix is mechanical rather than clever. Read each number from the source that owns it, measure what the link actually carries, and compare the three on a schedule. This guide is the procedure for doing that: the commands that read port speed, the queries that read committed bandwidth, a percentile method that will survive a capacity review, a worked sizing example, and the mismatch queries worth running every quarter.

At a Glance: Four Capacity Numbers on One Circuit

Read the port speed off the device

Port speed is a hardware fact, so the device is the only trustworthy source. On Cisco and NX-OS the interface line prints the bandwidth and the negotiated rate, and the summary view is enough to find the ones that do not match what you expected.

rtr-nyc-01# show interfaces GigabitEthernet0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
  Hardware is ..., address is ...
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec
  ...
  Full-duplex, 1000Mb/s, media type is RJ45

The BW value is the bandwidth the routing protocols will use for path cost, and the trailing 1000Mb/s is the real negotiated speed. On a 10 Gbps handoff the same line reads BW 10000000 Kbit/sec and 10000Mb/s. If the line reports a speed lower than the optic supports, the problem is the fiber, the optic, or the negotiation, not the contract.

On a Linux host the equivalent is a single command, and the module data tells you whether the optic is running at the speed you paid for.

ethtool eth0 | grep -E "Speed|Duplex|Link detected"
cat /sys/class/net/eth0/speed

If you monitor with SNMP, the two useful objects are the classic interface speed and the high capacity version added for links above 4 Gbps. The first is ifSpeed at 1.3.6.1.2.1.2.2.1.5 and the second is ifHighSpeed at 1.3.6.1.2.1.31.1.1.1.15, measured in Mbps.

snmpget -v2c -c "$COMMUNITY" "$ROUTER" 1.3.6.1.2.1.31.1.1.1.15.5

Whichever source you use, the result belongs beside the circuit, because the contract will never tell you the port speed and the port will never tell you what you bought.

Read committed bandwidth from the record

Committed bandwidth is commercial, so it comes from the contract or from the circuit record you maintain for it. If you keep circuits in a structured inventory, one query gives you the committed side for the whole fleet, with the terminating interface attached.

export OBELINF_API_KEY="your_read_only_key"
export OBELINF_ORG="acme-netops"

curl --fail --silent --show-error -H "Authorization: Bearer ${OBELINF_API_KEY}" \
  "https://api.obelinf.com/${OBELINF_ORG}/circuits?limit=500" > circuits.json

jq -r '.circuits[]
  | [.name, (.bandwidth // "unset"), .type_name, .provider_name,
     (.interface_a_device_name // ""), (.interface_a_name // "")] | @tsv' circuits.json

The rate is stored in Mbps, so a 10 Gbps service reads 10000 and a 500 Mbps service reads 500. Keeping the unit explicit in the field definition prevents the classic mistake of recording a rate as 10 and later reading it as ten megabits.

If a circuit has no committed rate recorded, that is the first finding, and it is worth fixing before any capacity review. A blank is worse than a wrong number, because a wrong number invites scrutiny and a blank invites assumption.

Measure what the link actually carries

The third number is the one that changes, and the only honest way to use it is as a peak rather than an average. Sample the interface counters at a fixed interval, then take the 95th percentile of the samples so a single busy minute does not drive the conclusion and a quiet night does not hide the evening peak.

On a Linux host, sar can produce a day of five minute samples in one command. Check the column order for your version before trusting the awk pipeline, because the interface and byte rate columns differ between distributions.

sar -n DEV 300 288 \
  | awk '$3 == "eth0" { print $5 }' \
  | sort -n \
  | awk '{ v[NR] = $1 } END { printf "p95 inbound: %.0f Mbps\n", v[int(NR * 0.95)] * 8 / 1000 }'

On network gear, the same result comes from sFlow or NetFlow against the circuit interface, and either is a better fit than polling counters when the link carries a lot of short flows. Whichever route you take, keep the sample interval and the window consistent between reviews. A percentile taken over five minute samples and a percentile taken over one minute samples will disagree, and the disagreement will be blamed on the network.

A worked sizing example

Sizing starts from demand, not from a product list. Suppose the circuit serves a branch office and the measured numbers are unremarkable. The table below is the calculation, and each row is a decision you should be able to justify.

The order matters. Choosing the port first and then buying the rate that matches it produces a circuit that is either overpriced or permanently at its ceiling, and it hides the one number you will need at the next review. The committed rate is what the link is worth, and the port speed is a delivery detail.

A worked oversubscription example

Oversubscription is the same arithmetic seen from the provider’s side, and it is a number you can compute for your own aggregation links. Take twenty four 1 Gbps access circuits sharing one 10 Gbps uplink.

The lesson for an operator is that the ratio is a design decision, not an accident, and it deserves to be written down. A 2.4 to 1 link is fine if peak simultaneous demand stays under seventy percent of the uplink. When it does not, the fix is capacity, not shaping, because buffers only move the loss around.

Audit the inventory with two queries

Once both numbers exist, the review is a comparison. Export the committed side and flag the suspicious rows first, since those are the ones that need a device read to finish the check.

# Committed rate missing
jq -r '.circuits[] | select(.bandwidth == null)
  | [.name, .provider_name, .type_name, .status] | @tsv' circuits.json

# Rate far below the port anyway, or a suspiciously round value: list for review
jq -r '.circuits[] | select(.bandwidth != null)
  | [.name, (.bandwidth|tostring), (.interface_a_device_name // ""), (.interface_a_name // "")] | @tsv' circuits.json \
  | sort -k2 -n > committed.tsv

Then read the port side from each device into the same shape and join on device plus interface. Any circuit whose committed rate exceeds the port speed is an error, and any circuit whose committed rate equals the port speed deserves an overhead check.

ssh rtr-nyc-01 'show interfaces description' > speed-rtr-nyc-01.txt

# Flag circuits where the committed rate left no room for overhead at the stated port
awk -F'\t' '$2 == 1000 && $4 != "" { print $1": committed equals a 1G handoff, verify overhead" }' committed.tsv

The last comparison is against measurements, and it is the one that decides whether anything changes. A circuit at a comfortable committed rate but a measured peak near the ceiling needs an upgrade. A circuit with a comfortable measured peak but a committed rate that was never recorded needs a record. Sorting those two outcomes apart is what keeps a capacity review from turning into a purchasing conversation every time.

A quarterly review you can finish in an hour

The procedure is short enough to run on a schedule rather than after an incident.

1. Pull the circuit list and read every row with a blank bandwidth, then fill those in from the contracts.
2. Read port speed for each terminating interface and compare it with the committed rate, flagging rates above the port speed and rates equal to it.
3. Pull the 95th percentile for each circuit over the same window you used last time, and record it against the circuit.
4. Group the results into comfortable, watch closely, and plan the upgrade using the utilization zones, comparing against committed bandwidth rather than port speed.
5. Recompute the oversubscription ratio on each aggregation link and confirm the measured peak still leaves room.

Keeping the previous numbers next to the current ones turns the review into a diff, and the diff is where the value is. A circuit that moved from forty percent to eighty two percent of its committed rate between two reviews is the one that deserves attention, and it is invisible if each review is read on its own.

The point of storing committed bandwidth and the terminating interface together is that a record cannot mislead you about which number is which. When the rate, the handoff, and the interface live on one row, a capacity review is a single pass over the inventory rather than a reconciliation of a contract folder, a diagram, and a monitoring system. Obelinf keeps the purchased rate in Mbps on the circuit and links each circuit to the interfaces it lands on, which is what makes those comparisons a query instead of a project.