4.3 STP报文类型
STP的BPDU报文结构前文已经做了详细讲解，这里不再重复。STP的BPDU报文的类型一共有两种，分别是配置BPDU报文（BPDU报文中的BPDU类型值为0x00）和TCN BPDU报文（BPDU报文中的BPDU类型值为0x80），下面详解介绍这两种类型BPDU报文的区别。
4.3.1 配置BPDU报文
在配置BPDU报文中，BPDU类型（BPDU Type）的值被设置为0x00，主要作用如下所述。
① 用于选举根桥及端口角色。
② 通过定期发送（每两秒发送一次）配置BPDU报文维护端口状态。
③ 用于确认接收到的TCN BPDU报文。
④ 用于选举根桥及端口角色。
配置BPDU报文转发过程如图4-10所示，从该图中可知，STP收敛后只有根桥才会定期发送配置BPDU报文，其他非根桥收到BPDU报文后会进行转发，通过这种方式维护端口状态。
图4-10 配置BPDU报文转发过程
由图4-10可知，STP收敛后，SWA为根桥，每隔2秒发送一次配置BPDU报文，配置BPDU报文会从所有的指定端口发送出去，其他非根桥从根端口接收到根桥发送的配置BPDU报文后，将配置BPDU报文缓存到接收端口，并将配置BPDU报文从所有的指定端口转发出去。但是非根桥在接收到配置BPDU报文后，是否转发也需要进行判断。
非根桥收到配置BPDU报文后，会先将配置BPDU报文中的Message Age和Max Age进行比对，如果Message Age小于等于Max Age，则接收并转发配置BPDU报文；如果Message Age大于Max Age，则会丢弃配置BPDU报文，不接收也不转发。对于转发的配置BPDU报文会修改以下内容：
① 将网桥ID修改为转发者的网桥ID。
② 将端口ID修改为发送配置BPDU报文的端口ID（包括端口优先级和端口ID）。
③ 将Message Age加1（可以限制配置BPDU报文的传输范围）。
4.3.2 TCN BPDU报文
TCN BPDU报文中BPDU类型（BPDU Type）的值被设置为0x80，其作用是通告网络中拓扑发生了改变。首先需要说明通告TCN BPDU报文和STP的收敛没有任何的关系，那么通告拓扑改变的目的是什么呢?在如下场景中，网络拓扑改变带来的问题（一）如图4-11所示。
图4-11 网络拓扑改变带来的问题（一）
在图4-11中，STP收敛完后SWB的G0/0/2端口被选举为替代端口（AP）并被阻塞，主机A访问主机B的数据帧经过SWB转发给SWA，再由SWA转发给SWC。两台主机完成通信后，SWB的MAC地址表如图4-11中所示。那么如果现在SWA和SWC之间的链路发生故障，会出现什么问题呢?如图4-12展示了由于网络拓扑改变带来的问题（二）。
图4-12 网络拓扑改变带来的问题（二）
在图4-12中，由于SWA和SWC之间的链路发生故障，导致STP重新收敛，收敛后的各端口角色如图4-12所示，现在我们来分析主机A访问主机B的数据帧是如何转发的。SWB收到数据帧后通过查询MAC地址表将数据帧从G0/0/1端口转发出去，SWA收到数据帧后会直接丢弃掉，丢弃的原因是链路故障造成端口被关闭，数据帧无法被从G0/0/2端口发送出去，这样主机A和主机B也就无法通信了。主机A和主机B就一直无法通信了吗?其实并不是，300秒以后会发现主机A和主机B可以正常通信了。这是为什么呢?原因是等待300秒以后，SWB上G0/0/1端口绑定的主机B老化的MAC地址已被删除掉，此时如果SWB再接收到访问主机B的数据帧，由于现在的MAC地址表中没有主机B的MAC地址，该数据帧将被从除接收端口以外的其他端口（G0/0/2）转发出去，这样SWC就能收到数据帧了，主机A和主机B自然就恢复了通信。但是这种恢复正常通信的等待时间太长了，每一次拓扑变化都需要等待300秒后才能恢复通信。也许有人会说，这种情况可以通过将MAC地址表的老化时间改短来解决。真的是这样吗?其实不然，这种解决方案根本就是治标不治本，并且会引发大量的未知单播帧泛洪，为什么?因为MAC地址表老化时间短，刚刚学习的MAC地址如果没有一个持续的访问流量，MAC地址很快会老化并被删除，再次收到同一单播帧就会导致新一轮的泛洪，产生网络不稳定问题。有什么更好的方法能解决这个问题吗?答案是肯定的，这就是使用TCN BPDU报文的解决方案，如图4-13所示。
图4-13 使用TCN BPDU报文的解决方案
① SWC发现拓扑改变后会从根端口发送一个TCN BPDU报文，目的是要将发生拓扑改变的消息通知根桥。
② SWB从自己的指定端口收到了SWC发送的TCN BPDU报文，SWB会向SWC回复一个BPDU Flag被设置为TCA的配置BPDU报文，用于确认接收到了TCN BPDU报文。
③ SWB继续从自己的根端口转发TCN BPDU报文。
④ SWA收到TCN BPDU报文后同样向SWB回复一个BPDU Flag被设置为TC的配置BPDU报文，并将自己的MAC地址表老化时间修改为15秒（一个转发延时），加速MAC地址老化。同时向所有的指定端口发送一个BPDU Flag被设置为TC的配置BPDU报文，目的是告诉其他的非根桥拓扑已经发生了变化。该配置BPDU报文会连续发送35秒（Max Age+Forward Delay的时间）。
⑤ 非根桥在收到TC置位的配置BPDU报文后会从所有的指定端口转发，同时将自己的MAC地址表老化时间修改为15秒，加速MAC地址老化。
注：STP中TC置位的配置BPDU报文只能由根桥发送，而其他非根桥如果发现拓扑改变就需要以发送TCN BPDU报文的方式来告知根桥，再由根桥向全网发送TC置位的配置BPDU报文，目的是将所有交换机MAC地址表的老化时间修改为15秒，加速MAC地址老化，尽快恢复数据转发。
STP在以下3种情况下会发送TCN BPDU报文：
●端口从转发状态过渡到阻塞状态（Blocking）或者禁用状态。
●非根桥从一个指定端口收到 TCN BPDU报文后会从自己的根端口向根交换机转发。
●端口进入到转发状态并且桥设备已经存在一个指定端口。
4.3.3 STP收敛时间
STP完全收敛需要依赖定时器的计时，端口状态从Blocking状态迁移到Forwarding状态至少需要两倍的Forward Delay时间（需要30秒的时间），总收敛时间过长。STP网络收敛后，如果直连链路发生故障，重新收敛需要30秒的时间，如果是次优或者非直连链路故障，则需要经过50秒的时间重新收敛。STP直连链路故障收敛情况如图4-14所示。
图4-14 STP直连链路故障收敛情况
由图4-14可知，如果SWC和SWA之间的链路发生故障，SWC的替代端口会成为根端口，并且经过30秒的延时端口装将过渡到转发状态。次优配置BPDU报文造成50秒收敛延时，图4-15展示了STP非直连链路故障收敛情况。
图4-15 STP非直连链路故障收敛情况
由图4-15可知，如果SWB和SWA之间的链路发生故障，由于SWB连接根桥的端口被关闭，SWB会认为自己是根桥，并从指定端口发送配置BPDU报文，标识自己是根桥。SWC从替代端口收到SWB发送的配置BPDU报文后会和端口之前缓存的配置BPDU报文进行对比，发现两个配置BPDU报文不一致，并且接收到的是一个次优配置BPDU报文，SWC会直接忽略并继续等待接收端口缓存的配置BPDU报文。这样经过20秒的等待后超时，端口角色重新收敛成为指定端口，并经过30秒的转发延时进入转发状态，总收敛时间为50秒。非直连链路故障场景如图4-16所示。
图4-16 非直连链路故障场景
在图4-16中，SWB和SWA之间的链路出现了单链路故障，导致只能接收不能发送。这种故障多发生在光纤链路上，由于光纤链路是收发分离的，所以很容易出现单链路故障，只能发送不能接收，或者只能接收不能发送。光纤链路可以通过两端配置UDLD（Unidirectional Link Detection，单向链路检测）协议避免单链路故障。图4-16中的单链路故障造成SWC无法从替代端口收到根桥的配置BPDU报文，经过20秒的等待后超时，端口角色重新收敛成为指定端口，并经过30秒的转发延时后进入转发状态，总收敛时间为50秒。
如何解决直连故障和次优配置BPDU报文带来的收敛时间过长的问题呢?思科的解决方案是为STP打了两个补丁，分别是uplink-fast和backbone-fast。uplink-fast解决了直连故障导致的收敛慢问题，backbone-fast解决了次优配置BPDU报文导致的收敛慢问题。由于这两种技术是思科的私有技术，而华为并没有这种技术，华为的做法是在STP中引用了RSTP（Rapid Spanning Tree Protocol，快速生成树协议）解决方案，RSTP在STP基础上进行了许多改进，使得收敛时间大大减小，一般只需要几秒钟的时间。在现网中，STP几乎已经不用，取而代之的是RSTP，RSTP不是HCIA的内容，这里不再深究。