RSTP与STP的主要区别

1. 收敛速度非常快，毫秒级别，不限于2s的hello时间
2. 网络变动时，用新的TCN机制去完成拓扑改变，不像STP需要等待30s
3. 对于RSTP来说，它是点到点的协议，因为在同步时会暂时block其他端口然后完成BPDU的对比。

RSTP收敛时遇到到一些问题

1. 当用户用RSTP和UDLD时，就需要注意，UDLD的收敛在7s以上，远远大于RSTP，这时可能就会有问题，所以建议在用UDLD时，可以考虑使用fast UDLD，但需要版本的支持（SXI4以上）。
2. 当一个端口收到更优的BPDU时，他会发生SYNC时，会block其他的指定端口，直到这个SYNC的端口收到对端的BPDU，注意如果收不到对端的BPDU，他会降级到STP的收敛机制等待30s然后使端口变成转发。这时如果有SVI仅仅属于这些被block的端口，那么SVI就会出现down/down的状态。如下图所示，此处是官网文档。

3. RSTP Dispute，dispute机制类似于UDLD，也是检测链路单通的，当根收到次优的BPDU时，他会认为此链路是单通的，对端没有收到自己更优的BPDU，因此会造成环路，所以会把此端口block，直到收到对端发来的aggrement，或等30s，端口才会FW。关于Dispute可以看思科的官方文档：

举例说明

SW1(root)—-port-channel—SW2
SW1上发现某个SVI出现down/down的现象，没有其他任何异常信息。这个SVI仅仅属于这个port-channel。在这个port-channel上 allow几个VLAN，其他VLAN还属于其他的端口。查看物理端口状态没有看到异常，CPU memory都是正常。对端设备有一些bpdu异常的信息，可惜不是问题发生时抓的，所以没有太多参考价值。

从现象来判断，很有可能出现以下几种情况，由于信息不足，无法确认最根本的原因：
1. SYNC导致的block问题不可能出现在例子中，SYNC确实会导致物理端口block，但条件是当其他端口收到更优的BPDU，他才会SYNC这个port-channel并block端口。思科的RSTP是基于PVST的，在这里，此端口是该SVI的末节端口，所以不会出现SYNC导致端口block。

2. Dispute导致的block。由于port-channel是由2根link组成的，发送、接受bpdu可能会用不同的link。所以问题可以归咎于当时port-channel的其中一个link不是很稳定，导致发送bpdu失败。对端收不到root的bpdu，自己认为是根了，此时通过port-channel的另一根link发送bpdu更新。此时SW1认为满足dispute触发的条件，block端口，SVI down掉，发送proposal，此时link还没完全恢复，所以收不到aggrement。过了一段时间后，这个link恢复了，SW1收到aggrement，SVI恢复。由于lacp的hello时间大概在10s左右（抓包得出），而SVI down的时间要少于10s，所以port-channel没有down的信息。另外客户配置了UDLD，默认的UDLD收敛时间大于7s，也大于SVI down的时间，所以UDLD也没有触发。

这里有两个问题：
1. 如何在LAB中重现SYNC？
答：sw1—X–(A)sw2(B)——sw3，sw2是root，sw1的pid要优于sw2，当联通sw1和sw2时，sw2发现有更优的bpdu，因此SYNC除接收端口外的所有端口，这时sw2的portB被block，并发送proposal，注意，RSTP是基于VLAN的，如果他发送的是VLAN2的proposal，让SW3仅allow VLAN3，这样SW3就会忽略这个proposal，sw2发现没有人回应，他就会降级到普通STP，把端口block掉并等待30s，30s后恢复正常转发。

2. 如何在LAB中重现Dispute？
答：造成单通，可以实现这个效果，另外应该还会有其他的重现方法，会是什么呢？

我这里有IEEE802.1w的PDF，由于比较大，我就不直接上传了。里面写的更细，可以分析在什么情况下会出现block，如果在网上下不到的，可以ping我。

版权声明：

---

本文链接：RSTP需要注意的一些问题
版权声明：本文为原创文章，仅代表个人观点，版权归 Frank Zhao 所有，转载时请注明本文出处及文章链接