Under 802.1D spanning tree, how do the short and long port path cost tables differ, and what breaks when bridges mix them?

## What a port path cost is Every 802.1D bridge port has a **path cost**: RFC 4188 describes it as "the contribution of this port to the path cost of paths towards the spanning tree root which include this port". A bridge's **root path cost** is the root path cost its upstream neighbour advertises plus the cost of its own receiving port, so costs accumulate as BPDUs travel away from the root. The standard only *recommends* defaults, which RFC 4188 summarises as "in inverse proportion to the speed of the attached LAN"; an administrator can set any value in range. ## The two tables Both tables are IEEE recommendations; neither is an RFC rule. | Link speed | Short value (802.1D-1998) | Long value (802.1t, then 802.1D-2004) | |---|---|---| | 10 Mb/s | 100 | 2,000,000 | | 100 Mb/s | 19 | 200,000 | | 1 Gb/s | 4 | 20,000 | | 10 Gb/s | 2 | 2,000 | | 100 Gb/s | no distinct value | 200 | | 1 Tb/s | no distinct value | 20 | The long values follow one rule: 20,000,000 divided by the speed in Mb/s. The short values were chosen when 10 Gb/s was the far horizon. ## Where the short table runs out - A cost is a positive integer, so below 2 there is only 1. Links at 10, 40 and 100 Gb/s end up costing 2 or 1, depending on the implementation, and the protocol can no longer prefer the faster one. - A 1 Gb/s link costs 4 and a 10 Gb/s link costs 2: one 1 Gb/s hop costs as much as two 10 Gb/s hops, which is rarely what a designer meant. - The long table spreads the same speeds over four orders of magnitude, and RFC 4188 had to add `dot1dStpPortPathCost32`, range 1..200,000,000, because the original 16-bit `dot1dStpPortPathCost` (1..65,535) cannot hold 200,000 or 2,000,000. Where the real cost is larger, the old object reports 65,535. ## Mixing tables: a worked failure Implementations differ in which table they use by default — an implementation choice, not the standard's. Suppose root R, and bridge X with two ways up: | Path | Hops and speeds | Advertising bridge's table | X's root path cost | |---|---|---|---| | via Y | R–Y 1 Gb/s, Y–X 1 Gb/s | Y uses long: advertises 20,000 | 20,000 + 4 = **20,004** | | via Z | R–Z 100 Mb/s, Z–X 1 Gb/s | Z uses short: advertises 19 | 19 + 4 = **23** | X uses short values for its own ports (4 for 1 Gb/s). It compares 20,004 with 23 and chooses the path through Z — across a 100 Mb/s link — while an all-gigabit path sits blocked. Nothing is misconfigured on any one bridge; the sums are on different scales. No bridge rescales a cost it receives, because a BPDU carries only a number. ## Keeping costs coherent 1. **Choose one table for the whole layer-2 domain** and set it on every bridge, rather than trusting defaults. 2. **Set costs explicitly on inter-switch links** where the design cares which path forwards. 3. **Check the result:** RFC 4188 exposes each bridge's `dot1dStpRootCost` and each port's cost; a root cost far out of line with its neighbours' is the signature of a mixed table. 4. **Remember that a cost is policy.** Raising one port's cost changes the root path cost of every bridge downstream of it. ## Common slips - Quoting the cost values as an RFC's: they are the IEEE's; RFC 4188 only manages them. - Assuming the long values are a fixed multiple of the short ones: 19 against 200,000 and 4 against 20,000 are not the same ratio. - Believing a bridge only compares its own ports, so mixing is harmless: the advertised part of every sum comes from other bridges.