Getting to the root of the problem.

From the “Learn something new every day” department…this one could actually be relevent to my studies.*  It was certainly relevant to my job.

In building a three-switch lab to simulate one site’s access-layer and test out some link bundling, I was seeing that my access switch’s uplink had a cost to the root of 16.  This did not make sense.  The path went through a Gigabit uplink to the secondary root, which is connected to the primary root by way of a two-link EtherChannel (two 100Mbps links).  I was expecting a cost related to the sum of costs for one 1Gb and one 100Mb link (4 + 19 = 23).

In looking up the path costs to try and work backwards, I found the cost for 200 Mb is 12.  This combined with the cost of the Gig uplink would give me my 16 value, but where was the 200 Mb coming from?

The answer was that the EtherChannel’s virtual interface gets its own bandwidth, equal to the product of the individual link bandwidth and the number of links in the channel.  Doing a “show interface port-channel” would display a bandwidth of 200 Mbps, and STP uses this interface’s characteristics to derive its path costing:

Port-channel21 is up, line protocol is up (connected)
Hardware is EtherChannel, address is 0019.5669.5382 (bia 0019.5669.5382)
Description: *** HQD_CORE_01 ***
MTU 1500 bytes, BW 200000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 2/255
Encapsulation ARPA, loopback not set
Full-duplex, 1000Mb/s, link type is auto, media type is unknown

This led me to wonder if this could be changed with the interface-level “bandwidth” command.  So for kicks, I changed the bandwidth of a random Gig link to 100 Mbps.  Here’s the before and after:

SW-1>sho span int gi2/0/9

Vlan             Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
VLAN0102         Desg FWD 4 128.61   P2p

Then the change…

SW-1(config)#int gi2/0/9
SW-1(config-if)#bandwidth 100000

Then the result:

SW-1>sho span int gi2/0/9

Vlan             Role Sts Cost Prio.Nbr Type
—————- —- — ——— ——– ——————————–
VLAN0102         Desg FWD 19 128.61   P2p

The cost to reach the root switch will be the primary determining factor in root-port selection, for any STP topology that involves uplinks to non-root switches. ** This can be influenced by the bandwidth of your links, which I knew already, but what I didn’t know was that the path-cost may inadvertently change with link-bundling or manual interface bandwidth configuration.

*Picture the following scenario: Given a topology consisting of three switches, make Fa0/1 on Switch-C the alternate port…but change nothing on its upstream switches; do not disable STP or employ FlexLinks; and do not manually change the port cost with any “spanning-tree” commands.

**If you’re merely running multiple uplinks from one switch to the root, given interfaces of equal bandwidth, your root bridge ID, path cost, and sender bridge ID will be equal.  The tie is broken based on port ID (2-tuple value consisting of Priority:Interface-Number).  Of course, if you’re doing that, you should really consider EtherChannel; additional path-redundancy and bandwidth, what’s not to love!