This should explain the reason for the port cost/bridge priority change.
Changes Implied by Uplink Fast
In order to be effective, the feature needs to have blocked ports providing redundant connectivity to the root. As soon as Uplink Fast is configured on a switch, switch automatically adjusts some STP parameters are adjusted to help achieve this:
* The bridge priority of the switch is increased to a significantly higher value than the default. This ensures that the switch is not likely to be elected root bridge, which does not have any root ports (all ports are designated).
* All the ports of the switch have their cost increased by 3000. This ensures that switch ports are not likely be elected designated ports.
UplinkFast is a Cisco specific feature that improves the convergence time of the Spanning-Tree Protocol (STP) in the event of the failure of an uplink.
The UplinkFast feature is designed to run in a switched environment when the switch has at least one alternate/backup root port (port in blocking state), that is why Cisco recommends that UplinkFast be enabled only for switches with blocked ports, typically at the access-layer. Do not use on switches without the implied topology knowledge of a alternative/backup root link typically to distribution and core switches in Cisco multilayer design.
With the default STP parameters, the recovery takes up to 30 seconds, and with aggressive timer tuning, this lapse of time can be reduced to 14 seconds. The UplinkFast feature is a Cisco proprietary technique that reduces the recovery time further down to the order of one second.
The UplinkFast feature dramatically decreases the convergence time of the STP in the event of the failure of an uplink on an access switch. UplinkFast interacts with other switches that would have a strict standard STP. UplinkFast is only effective when the configured switch has some non-self-looped blocked ports. To increase the chances of having blocked ports, the port cost and bridge priority of the switch are modified. This tuning is consistent for an access switch, but would not be useful on a core switch.
UplinkFast only reacts to direct link failure. A port on the access switch must physically go down in order to trigger the feature. Another Cisco proprietary feature, Backbone Fast, can help to improve convergence time of a bridged network in case of indirect link failure.
If the switch were to become the root one can assume it will not block any ports. Therefore if the switch is a root switch, the uplinkfast feature is rendered ineffective on this switch. This is because the are no blocking ports that can be affected by a direct link failure between itself and its root switch, it is the root of spanningtree in this scenario.
That's right. There are 4 STP roles (that were only defined with RSTP but that we still display, even with regular STP):
Designated, Root, Alternate and Backup.
Uplinkfast only works between Root and Alternate ports.
A root bridge only has Designated or Backup ports... Not really the best candidate for uplinkfast. So we increase the root priority to reduce the "risk" of this bridge becoming the root bridge.
A non root bridge will benefit from Uplinkfast if it has a redundant connection to the root bridge. That means that at least two of its ports can lead to the root. One of them is the root port. The other one can be Designated or Alternate. When uplinkfast is configured, the port priority is increased on all the ports in order to increase the change of having an Alternate port vs Designated. Think of the simplest uplinkfast topology with 3 bridges: Root (R), secondary root (SR) and access bridge (A). A port will block on the segment A-SR. It could block on either side in theory, but we want to force our topology so that it's rather the access bridge that is blocking. By increasing the port priority of the access bridge, the BPDUs sent by A will be much more likely to be worse that the one sent by SR (on which uplinkfast is not configured). This will result in A having an alternate blocking port.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...