网络故障显然是咱们网管们经常要面对的一种麻烦，虽然很多时候，它都是由一些看似荒唐的小错造成的，但每次问题爆发起来却常令大家焦头烂额，特别是当几个小错串成大问题时，更是让你无从下手。这里就有一个真实的案例，或许可以与大家共勉。
某公司租用一条10M的VPN专线用于连接总部和其下属的支公司(如下图所示)。该专线使用了一段时间后，突然于前不久发生中断了。按理专线的中断也是正常的。故障也无非就是光缆、设备
损坏，三层交换设备端口处于err-disable、或者Blocking等。但是该专线故障的排除也着实费了一番工夫。
在排除了光缆以及光端机的原因外，技术人员登录CISCO3560—A及CISCO3560—B，查阅了设备的端口信息，发现CISCO3560—A的端口出现LOOP 告警错误。而CISCO3560—B端口正常。检查客户端A侧的HUB。发现有人误将一根网线的两头都接到了HUB上了。这样的后果就是，当HUB收到一个广播数据包(例如ARP请求)，它就开始对它接受这个包的源端口以外的端口进行洪泛。这时候，被回环的端口1和2就会收到来自对方的广播包，就会产生二次洪泛。此时，由于源端口是1和2,所以同时也会对这个广播包原来的端口也进行洪泛，相应也会产生三次洪泛、四次洪泛等等。这样，上联的CISCO3560—A就会收到来自HUB大量的数据包，造成严重的拥塞以及资源消耗。
由于CISCO3560—A的BPDU GUARD功能开启后，在正常情况下, CISCO3560—A的端口是不会收到任何BPDU(协议数据单元(Bridge Protocol Data Unit))的。因为PC和HUB都不支持STP(生成树协议)，所以不会收发BPDU。当这个端口下如果有自回环的环路，那么它发出去的BPDU在HUB上回环后就会被自己接收到。这个时候BPDU GUARD就会把它立刻设为Error-Disabled状态，这个端口就相当于被关闭了，以保护了整个网络。
在HUB上的自环网线拆除，并且重新激活CISCO3560—A的端口后，我们发现网络仍然不能正常使用。技术人员在整个网络的A侧和B侧之间用笔记本电脑进行PING包测试，发现线路是通的。同时注意到一个非常奇怪的现象。就是在B侧的两端ISCOM2126交换机和CISCO3560—C之间，只要用网线一联，两侧的端口就不正常。更改两边端口的模式，如 100Mbps全双工、AUTO等均无效。
根据上面的现象，原因可能出在ISCOM2126交换机和CISCO3560—C的互通性上。登录客户的CISCO3560—C，查看日志信息，发现有以下告警信息：
Aug 1 08:12:35: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk FastEthernet0/43 VLAN5
*Aug 1 08:12:35: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking FastEthernet0/43 on VLAN5 Inconsistent port type.
察看CISCO的告警定义：3560G-C在non trunk端口收到了一个802.1Q类型的包。CISCO认为两端接口类型不一致(不同厂家的)，可能存在二层环路隐患，所以就将收到这个包的端口block。这是导致端口被block掉的直接原因。
进一步分析为什么FastEthernet0/43的access端口会收到802.1Q的包，而且是802.1Q的BPDU包呢?由于能产生802.1Q BPDU包的只有PVST协议。PVST BPDU的格式和STP/RSTP BPDU格式不一样。标准的BPDU配置消息是以以太网数据帧的格式进行传递的，采用多播MAC地址01-80-C2-00-00-00为目的MAC地址。而PVST的BPDU包的目的MAC地址为Cisco保留地址01-00-0C-CC-CC-CD，而且在VLAN Trunk的情况下，PVST BPDU会被打上了802.1Q Tag标签。
对于目的MAC地址为01-00-0C-CC-CC-CD的包，普通交换机(ISCOM2126)不识别，会把它当作普通的多播包转发，而不进行任何处理。
由于CISCO交换机上PVST是默认打开的，当3560G-A发出802.1Q BPDU包后，ISCOM2126交换机对它进行直接转发(无论ISCOM2126交换机是否启用STP的透传功能)。3560G-C的access上联口收到3560G-A上发送的802.1Q的BPDU包后，判断可能存在环路，所以将3560G-C的上联口FastEthernet0/43阻塞了。
于是我们在interface FastEthernet0/43上加了以下命令，问题解决。
spanning-tree bpdufilter enable
总结：
导致以上故障的原因是由于普通交换机不识别CISCO的PVST私有协议包，只是把它当做普通的多播包转发。从而导致CISCO交换机判断可能存在环路，将端口block。在类似的组网中其他型号的交换机和CISCO交换机一起组网也会产生相同的问题。
为此，我们建议：
1.由于CISCO交换机默认PVST协议是启用的，在做网络规划时需要考虑网络是否需要用到STP协议，如果不需要，建议将PVST关闭，或尽量采用标准的STP协议。
2.在CISCO交换机上不需要参与STP计算的端口启用spanning-tree bpdufilter enable。 这样端口可以直接将BPDU包丢弃。比如上图中CISCO交换机作为接入层交换机，它的上联端口可以确认不需要参与STP计算。
3.由于普通交换机会将目的MAC地址为01-00-0C-CC-CC-CD多播包直接转发，在如上组网中如果可以确认不需要T64G来传递BPDU信息，可以在T64G上配置ACL对01-00-0C-CC-CC-CD进行过滤。
转自：www.net130.com