It’s interesting to notice how one of the most used protocol in LANs STP (Spanning Tree Protocol) is so weak from a security standpoint. What I want today is to put a simple test scenario build in a Packet Tracer lab that illustrate what can happen if by mistake (or by an informed hacker) and some specific switch configuration a new switch is introduced into an existing network. Let assume the network topology illustrated in picture below (a screen taken from a running simulation in Packet Tracer apps). As can be seen, the topology is based on Cisco’s layered model with dedicated switches for network core and distribution/access (actually a particular case with distribution and access layers collapsed in a single one). Usually, switches used in core are more powerful in term of performance than other – these should have sufficient capacity to switch all aggregated traffic between network modules interconnected by core (in our simple topology the network core connect user’s access switch with data center distribution/access module). The network is fully redundant and protected from single-point-of-failure – there are redundant paths as well as spare switches. As a result of redundancy the network topology inevitably forms physical loops, which without a proper handling are translated in a logical loops. As is known, logical loops ca be detrimental for network performance and operations (if not completely destructive). In such a condition, once caught, a broadcast frame will spin endless in closed loop, more, they will tend to accumulate and form what is known as a broadcast storm (in typical size network is a matter of seconds, even just by ARP requests). As a result of storm, broadcast traffic will eat precious switch/link bandwidth resources leaving less (or nothing) for legitimate traffic. Above that, other negative effects of loops are: MAC address table entries flapping, occurrence of duplicate unicast frames, flooding connected end-nodes with looped broadcast and others.
The role of STP protocol is to prevent logical loops creations by ensuring one logical path in a network with multiple physical paths. The STP protocol will intentionally block all off the redundant paths that could cause a loop and in case of active path failure will dynamically react by re-activating (put in forwarding state) of some previously blocked paths. The STP is a distributed protocol, which run on all switches and that use a special format frames named BPDU (Bridge Protocol Data Units) for inter-switch coordination. The logic of STP is based on following two steps: (a) a root bridge (master switch) election and (b) a spanning tree algorithm (STA) running in determination what paths should be open for forwarding and what should be left blocked. Election of Root Bridge take place by comparing bridge priority together with switch MAC address of each switch involved in a specific STP instance (values are exchanged by BPDU messages). The switch with lower value Priority/MAC will win the election. The bridge priority, is a configurable parameter and by default has the value of 32768 on all switches, if not changed in advance the only factor that influence the root bridge election remain switch MAC address. Usually, an administrator will involve and change bridge priority in such a way that a specific switch can be designated as a Root Bridge – normally one of the core switches (more on why those will come). In second stage, the STA on every switch will calculate the cost of each logical path to the root bridge, select the path with least cost and use that path for traffic forwarding, other paths that do not form a best way to Root Bridge for other switches are left in blocking state. Path costs are calculated as a sum port cost consecutive to the root bridge. Port costs is based on values predefined by IEEE standard for each possible Ethernet bandwidth (e.g. 100Mbps have a port cost of 19, 1GbE cost of 4, lower speed higher cost).
In our topology, we can already observe the results of STP protocol actions: some links are active (ports on both ends are in forwarding state, shown by green circle) and some other links are blocked (one port at one of the end of link are leaved in blocked state shown by orange color circle). In that state, there are no any of L2 logical loops. Let’s try to explain how STP did that. If briefly:
- One of the core switches (in picture from left) are designated as a Root Bridge. That was done by setting a lower (245776) bridge priority than the default value of 32768. Without that, Root Bridge can become any of switches from the topology (actually that with lower switch MAC address table). For backup purposes, the other core switch is configured with a bridge priority (28672) greater than first switch but lower than default value. In case of primary core switch failure the second core switch will gain (trough STP election) the Root Bridge role. The Root Bridge role assignment and configured bridge priority value can be checked from the output of show spanning-tree privileged mode command (see picture below, show command on SW1).
- Every switch in topology will calculate the cost of every path leading to the Root Bridge switch and choose the least cost one as a forwarding path. It can be seen by one active path from every switch to root bridge (e.g. for SW3 F0/2 to F0/2 on SW1). Not for this topology, but in case of multiple paths with the same cost the STP algorithm will choose the path that begin with a port whose port_priority/port_ID is lower. The path cost can be viewed from the output of show spanning-tree command (in picture below see at show command for SW3).
- For the remaining physical links, switches at both ends will negotiate who will leave the port in blocked state (switch with higher Bridge ID). On a link, only one end is leave blocked while the other end is always is passed in forwarding state. See proof on topology screen, here, none of physical links blocked at both ends at the same time. Let’s see for example what happens on the segment between SW3 and SW4, here, SW4 have a lower Bridge ID than SW3 therefore this one will pass his port ]n forwarding state (F0/4). Given that bridge priority of both switches are the same (default value of 32768) result that the factor that make difference when comparing Bridge Priority is MAC addresses – SW4 have a MAC address lower than that of SW3.
If now, we will re-draw the topology so that only active paths are shown then a nice tree (hence the term Spanning Tree) can be observed (picture below, left side). As can be seen all traffic flows are aggregated in one of core switch.
If now, intentionally or by mistake, a new switch with a lower than existed bridge priority is inserted then a suboptimal STP topology can form. Let’s suppose that the new switch with pre-configured bridge priority of 20480 (lowest in topology) is connected directly to SW3. In that case, after STP re-calculation, a new root bridge will be elected (that new switch) and another active/blocked links topology will be established. If compare this topology (shown in picture below) to initial one then differences are obvious. As show in previous picture (right side) all the traffic are now aggregated in SW3 – a switch that is less powerful than the core switches, so a inevitable bottleneck point will occur in this network.
If to look at cost of path from SW3 to root bridge then, now, it become more expensive, which means that path is crossing along more ports. In show spanning-tree command, the value of 57 added by 3 time cost of FastEthernet port (19 as of IEEE standard).
Obviously such scenarios should be avoided. There are techniques like BPDU guard/filter that once configured can automatically block the ports or cancel any BPDU swapping toward such unexpected switches, but this is a subject for another post so enough for today.