http://packetlife.

net/blog/2009/oct/15/stp-your-friend/ Page 1
STP is your friend
By stretch | Thursday, October 15, 2009 at 4:36 p.m. UTC
Every once in a while I encounter someone who wants to disable Spanning Tree Protocol (STP) on their LAN switches. This is a
bad idea. Consider the typical LAN topology below:
The two access switches are trunked, and Switch 1 maintains a trunk to the local router. All access ports are assigned to VLAN 10.
An admittedly simplistic but valid design. Let's observe what happens when a redundant layer two connection is introduced
between the two access switches, first with STP enabled and then without.
In out first scenario, STP is left to its default configuration, with one exception: Switch 1 has been manually configured as the STP
root for clarity.
Switch1# show spanning-tree summary
Switch is in pvst mode
Root bridge for: VLAN0001, VLAN0010
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001 0 0 0 1 1
VLAN0010 0 0 0 1 1
---------------------- -------- --------- -------- ---------- ----------
2 vlans 0 0 0 2 2
Now imagine that after some office furniture was rearranged, two cable drops have been mistakenly cross-wired by end users.
(Note that newer Auto-MDIX-enabled switches such as the Catalyst 2960 and 3560 will form a link even with a normal
http://packetlife.net/blog/2009/oct/15/stp-your-friend/ Page 2
non-crossover cable.) Port F0/19 on Switch 1 has been connected to F0/8 on Switch 2, forming a layer two loop within VLAN 10.
With STP enabled, this isn't a problem; the redundant connection is marked as an alternate path to root on Switch 2 and
subsequently blocked to prevent a switching loop:
Switch2# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 10
Address 000f.345f.1680
Cost 19
Port 1 (FastEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 000e.8316.f500
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Root FWD 19 128.1 P2p
Fa0/8 Altn BLK 19 128.8 P2p
This makes for a happy network. But now we'll test what happens if STP is disabled by a negligent administrator.
Switch1(config)# no spanning-tree vlan 10
Switch2(config)# no spanning-tree vlan 10
http://packetlife.net/blog/2009/oct/15/stp-your-friend/ Page 3
When a redundant connection is made again, we immediately being receiving MAC address flapping notifications:
%SW_MATM-4-MACFLAP_NOTIF: Host 001d.60b3.0184 in vlan 10 is flapping between
port Fa0/8 and port Fa0/1
These are triggered by the never-ending broadcast storm initiated by every layer two broadcast (such as an ARP request) from any
host on the VLAN. Because STP is not present, neither switch can detect the switching loop. Ethernet frames have no concept of
TTL, so they circle the loop endlessly.
We can confirm the occurence of a broadcast storm by examining the traffic counters on either of the inter-switch links:
Switch2# show interfaces f0/1
FastEthernet0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 000e.8316.f501 (bia 000e.8316.f501)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 57/255, rxload 57/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:08, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 22566000 bits/sec, 13031 packets/sec
5 minute output rate 22569000 bits/sec, 12969 packets/sec
4655802 packets input, 1003268438 bytes, 0 no buffer
Received 4654349 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 4637 multicast, 0 pause input
0 input packets with dribble condition detected
4609557 packets output, 1003475840 bytes, 5676 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
5676 output buffer failures, 0 output buffers swapped out
You may note that the observed throughput is only about 20% of the maximum speed (22 out of 100 Mbps). This is because the
average throughput is calculated over a five-minute interval by default, and the above capture was taken roughly a minute into the
storm. (As an aside, the default five-minute interval can be modified with the load-interval command under interface
configuration.)
One might be tempted to argue that a network is invulnerable to this effect if routed links are used between all access switches.
Wrong. It is still possible for a layer two loop to occur if two or more erroneous connections are made (versus just the one in this
example).
Bottom line: STP exists for a reason. Let it be.
http://packetlife.net/blog/2009/oct/15/stp-your-friend/ Page 4
Posted in Design, Switching