What is the difference between short and long spanning tree path costs?

They are two different tables for turning a link speed into a number. Short is the set of values from IEEE 802.1D-1998, held in a range of 1 to 65,535, and it assigns 100 to 10 Mbps, 19 to 100 Mbps, 4 to 1 Gbps, and 2 to 10 Gbps. Long is the set from IEEE 802.1t, folded into 802.1D-2004, computed as 20,000,000,000 divided by the link speed in Kbps and held in a range of 1 to 200,000,000, so 1 Gbps is 20,000 and 10 Gbps is 2,000. Switches add these numbers up along a path and pick the lowest total, so the choice of table decides which path forwards and which one blocks.

Should I use long spanning tree path costs?

Yes, on any network with links faster than 1 Gbps, which is nearly all of them. Short stops distinguishing speeds above 10 Gbps, where it assigns a cost of 2, and it gives 25 Gbps, 40 Gbps, and 100 Gbps the same cost of 1. Long keeps the ratio between speeds correct, so the path the protocol picks matches the path with the most bandwidth. The one requirement is that every switch in the same layer 2 domain uses the same method.

Does changing the path cost method change costs I set by hand?

No. The method decides the default a port gets, and a cost you configured explicitly stays the number you typed. That is the trap in a migration. A port set to `spanning-tree cost 100` under short was made much less attractive than its neighbors, because their defaults were 4 and 19. Change the domain to long and that port keeps its 100 while the neighbors jump to 20,000, so the least attractive port in the building becomes the most attractive one by a factor of two hundred.

TRANSLATION

Short or long spanning tree path costs: which one to run and what mixing them does

Q: What happens if some switches use short and others use long?

You get a wrong topology and no error message. The path cost method is local to each switch and is never compared with a neighbor, and the root path cost field in the BPDU is 4 octets regardless of the method, so a short-mode switch happily adds its cost of 4 to a received total of 20,000. Every long-mode switch adds thousands to the running total while every short-mode switch adds single digits, so paths that stay inside the short-mode part of the network always look cheaper. Blocking ends up wherever the long-mode switches are, which means the topology follows the config rollout instead of the link speeds.

Q: Does MST use long or short path costs?

MST always uses long. There is no setting for it and the short method does not apply to MST instances. This shows up at a region boundary: if an MST region sits next to switches running PVST+ or Rapid PVST+ with the default short method, the domain is already running both methods and nobody typed a command to make that happen.

Short path costs come from a 1998 table that runs out of room at 10 Gbps and gives every faster link the same cost of 1, so a single gigabit link can beat three 10 Gbps hops. Long costs fix the arithmetic. Nothing in the protocol notices a network running both methods, because the number on the wire is only a number.

Reading this, you will:

Read either cost table and work out which path a switch will choose.
Spot the topologies where short costs pick the slower path.
Change the method across a layer 2 domain without leaving it in the half-migrated state.

A switch works out its path to the root bridge by adding up the cost of every link along the way and taking the lowest total. Where those per-link numbers come from is a configuration setting, and there are two answers to it. Short is the table from IEEE 802.1D-1998. Long is the table from IEEE 802.1t, which was folded into 802.1D-2004. Most switches still default to short.

The two tables produce numbers thousands of times apart, and nothing in the protocol notices when a network is running both.

What the two methods are

Short assigns each port a value from a fixed table, and the whole accumulated cost lives in a range of 1 to 65,535.

Long computes the value as 20,000,000,000 divided by the link speed in Kbps, with a per-port range of 1 to 200,000,000. That upper limit is deliberate. Capping one port at 200,000,000 keeps a long path from overflowing the 32 bits the BPDU carries for the running total.

The two cost tables

Link speed	Short cost	Long cost
10 Mbps	100	2,000,000
100 Mbps	19	200,000
1 Gbps	4	20,000
10 Gbps	2	2,000
25 Gbps	1	800
40 Gbps	1	500
100 Gbps	1	200

Read the short column downward and you can see where it runs out. Between 10 Mbps and 1 Gbps it has room to work with. By 10 Gbps it is down to 2, and at 25 Gbps and above every speed is the same number.

Where short costs stop working

Costs are added along a path, so what decides a topology is the total, not any single link.

Under short, a 1 Gbps link costs 4 and a 10 Gbps link costs 2. Take an access switch that can reach the root two ways, over 10 Gbps uplinks or over an old gigabit run that nobody removed:

Two 10 Gbps hops total 4, and the single 1 Gbps link also totals 4. The two paths tie, and the switch falls back to comparing bridge IDs and port IDs, which have nothing to do with speed. Which path forwards comes down to a MAC address somebody burned into a switch years ago, and not to bandwidth.
Three 10 Gbps hops total 6, and that single 1 Gbps link still totals 4, so the gigabit link wins outright and the 10 Gbps path blocks.

Under long, both comparisons come out the way you would expect. Two 10 Gbps hops total 4,000 and three total 6,000, against 20,000 for the one gigabit link.

It gets worse at the speeds shipping now. Under short a 100 Gbps link costs 1, so four 100 Gbps hops total 4 and tie with that same gigabit link. Under long they total 800 against 20,000.

This is the failure that gets blamed on a bad optic, a duplex mismatch, or a misbehaving uplink. The link is fine, and the switch is doing exactly what it was told to do. The table it was told to use was written when 10 Gbps was the top of the range.

What happens if some switches use short and others use long

Nothing in the protocol complains, and that is the part the network team keeps missing.

The root path cost field in a configuration BPDU is 4 octets, and it has been 4 octets since the protocol was standardized. The method itself does not travel in the BPDU and is never compared with a neighbor. It only decides what number a switch assigns to its own ports before adding that to the total it received.

So a switch running short receives a root path cost of 20,000 from a long-mode neighbor, adds its own 4, and advertises 20,004. There is no error, no log line, and no mismatch counter anywhere.

What you get is a topology that follows the config rollout instead of the link speeds. Every long-mode switch adds thousands to the running total and every short-mode switch adds single digits, so any path that stays inside the short-mode part of the network looks cheap, and any path crossing a long-mode switch looks enormously expensive. Blocking lands wherever the long-mode switches happen to be.

The usual way into this state is a hardware refresh. The new switches arrive built from a current template that sets long, the older switches in the same domain were never touched, and the domain now has two halves that disagree about arithmetic.

MST always uses long, so a region boundary can be mixed by default

MST always uses long path costs. There is no setting for it, and the short method does not apply to MST instances.

That means a region boundary can put you in the mixed state without anybody configuring it. If an MST region sits next to switches running PVST+ or Rapid PVST+ on the default short method, the domain is already running both methods, and the mismatch arrived with the protocol choice rather than with a command someone typed.

Costs you set by hand do not scale with the method

The method decides the default a port gets. A cost you configured explicitly stays exactly the number you typed.

That is the trap in a migration. Under short, an engineer types spanning-tree cost 100 on a port to push traffic away from it, and 100 is a sensible choice there because it is worse than the 19 a 100 Mbps link gets and much worse than the 4 a gigabit link gets. Switch the domain to long and that port keeps its 100 while every neighbor jumps to 20,000. The port that was configured to be the least attractive in the building becomes the most attractive one by a factor of two hundred.

Changing the method on a live network

The command is global and applies to every VLAN on the switch:

switch(config)# spanning-tree pathcost method long

show spanning-tree summary reports which method the switch is using, so run it before the change and again afterward to confirm.

There are four things to settle before the change window.

Cover the whole layer 2 domain in one change. The half-migrated state is the broken state, so a rollout done one closet per night spends every night in it.

Inventory the explicit costs. Every spanning-tree cost in the domain needs a translated value ready before you start, per the callout above.

Decide where the root is and confirm it does not move. Changing every port cost at once can move the root bridge if root placement was ever left to the default priority, and a root move produces far more topology change than the cost change alone.

Expect a recalculation. Every port gets a new cost, so the tree recomputes and forwarding pauses while it does. On Rapid PVST+ or MST that is quick, and on classic PVST+ it is not.

Finding out what you run today, without touching a device

If you keep config backups in git, the answer is already in the repo:

grep -rl "pathcost method long" configs/
grep -rn "spanning-tree cost" configs/

The first command splits the fleet into the switches that were changed and the switches that were not. If both lists have members in the same layer 2 domain, you have found the problem before anybody goes looking for a bad optic. The second gives you the list of explicit costs somebody will have to translate.

Long is the right method for anything built in the last decade, and it is the only one of the two with room for the speeds shipping now. Changing it takes one line of config, and most of the effort goes into the inventory you do before typing that line.