问题
为了提高网络的可用性，需要进行冗余和备份。但是冗余路径会产生环路
环路会导致以下问题
广播风暴：由于交换机会对广播、多播、和未知目标MAC的单播包进行泛洪，在存在环路的情况下，很短的时间内就会产生风暴
多帧拷贝、MAC地址表不稳定：当交换机刚刚启动时，MAC地址表是空的，所以，所有的单播帧都会进行泛洪操作。但是如果存在环路的话，交换机在特定情况下，会从不同的接口收到相同的MAC地址，这样的话，MAC地址表将不稳定
STP（spanning tree protocal，IEEE802.1D）就是通过软件防止环路的产生，通过逻辑的禁用接口，使得环路在逻辑上不存在；当线路出现故障时，将禁用的接口启用，使得网络能够发挥物理冗余路径带来的高可用性
STP协议的工作原理
STP协议的原则如下：
- 每个广播域中只有一个根网桥，根网桥的接口都是指定接口
- 每一个非根网桥上都有一个根接口，根接口就是到达根网桥最近（带宽最高，开销最小）的接口
- 每个网段中只有一个指定接口（发送方的桥ID较小的，或者端口优先级较小，或者端口ID较小的）
- 非指定接口不使用
假如上图的Switch X是根网桥，那么它的两个接口都是指定接口；Switch Y是非根网桥，由于100BASE的带宽更高，所以Switch Y上面的接口是根接口；上下两个segement中，s1和s2都已经有指定接口了，所以Switch Y下面的接口既不是根接口，也不是指定接口，那么将其阻断。
上述的过程是交换机通过STP协议和交换BPDU（Bridge Protocol Data Unit）桥接协议数据单元，自动协商得到的。BPDU每2秒钟发送一次。
BPDU的数据结构
Root ID（8Bytes）：根网桥ID，每个交换机通过桥ID进行标识，桥ID由桥优先级+MAC地址组成（64个字节）。桥优先级的默认值为32768，最大值为65535。桥ID最小的为根网桥
Cost of path（4Bytes）：接口的Cost值，端口速率对应的开销值如下：
Bridge ID（8Bytes）：本网桥（交换机）的桥ID
Port ID（2Bytes）：端口编号
Hellotime（2Bytes）：BPDU间隔发送时间，默认为2秒
Max age：详见下面
Forward delay：详见下面
上述四个字段，在交换机交换BPDU的过程中就能够协商出结果。
在STP协议故障转移过程中，交换机接口状态有如下四个状态
当某个指定接口出现故障时，需要将原先的非指定接口转为指定接口。如何检测故障呢？
一种情况是，直接端口故障，交换机能够立即得知这样的故障，则将Blocking的非指定接口立即切换到Listening状态
另一种情况是，线路故障，交换机无法直接检测到，此时通过BPDU检测。正常情况下两台交换机之间会每两秒钟收到对方的BPDU，如果在Max age时间后，仍然无法收到BPDU的话，需要进行重选举，将原先Blocking的非指定接口，切换到Listening状态。
Listening状态持续Forward Delay时间，这段时间后，选举完成。之后进入Learning状态，交换机在该端口上进行学习MAC地址，但是不转发数据，以防止对未知单播帧的广播，这个时间持续Forward Delay时间；最后进入正常的Forwarding状态
一般情况下根据超时时间的设置，最长有可能需要经过30-50秒，STP协议才能重新选举完成
总结：
- Blocking：非指定接口的状态，即不转发数据也不学习MAC地址
- Forwarding：指定接口或根接口，转发数据和学习MAC地址
- Listening：进入重选举的状态
- Learning：重选举完成后，进入MAC地址学习，但不转发数据
下面是一个例子
- SWR的网桥优先级最小，所以SWR为根网桥，其接口为指定接口
- SWA、SWD的上面的两个接口到SWR的开销最小（都是19），所以都是根接口；同理，可以得到SWB和SWC的根接口
- SWA和SWD下面的端口都是其各自segement的指定接口（每个segment有且只有一个指定接口）
- SWB和SWC组成的segement还没有指定接口，此时由于SWB的桥优先级较小，所以SWB侧的接口为指定接口，而SWC侧的接口即为非指定接口，进入Blocking状态
PortFast
如果终端设备直接连接在交换机上，也需要等待30秒的话，会出现问题，比如DHCP超时。所以，可以配置交换机的接口为PortFast模式，PortFast的接口不会介入STP选举的过程，不需要等待30秒的选举过程。但是不能用在Trunck接口上，因为如果用在Trunck接口上启用PortFast，交换机之间无法进行STP选举，极易产生环路。所以PortFast一般只用在直连终端的“接入接口”。
http://www.pchou.info/network/hardware/2013/12/19/52b293e0c4123.html
