别被扩展系统ID迷惑了
扩展系统ID的作用:
二层交换机使用STP技术来防止网络中的桥接环路,STP算法的核心在于交换机发送的BPDU(桥接协议数据单元),BPDU报文里有交换机的BID(网桥优先级),BID由2字节(16位)网桥优先级和6字节MAC地址组成。每台交换机的BID都是唯一的,但是这只能为所有VLAN去维护一棵生成树,如果要为每个VLAN都维护一棵生成树的话,那么必须使每个VLAN的BID都不同,这就引入了系统扩展ID。使用系统扩展ID后,将网桥优先级(2字节)的前四位用来表示交换机优先级,后12位作为系统ID扩展,也就是对应每个VLAN的编号。
系统扩展ID
实验:扩展系统ID引发的奇怪现象:
图1:实验环境
实验环境:如图1所示,IOU1,IOU2,IOU3都运行PVRST生成树,都划分了VLAN1和VLAN2,IOU1的E0/0-1属于VLAN2,IO2的E0/0,E0/2属于VLAN2,IOU3的E0/1-2属于VLAN1,交换机之间并没有TRANK链路。
实验说明:假设交换机之间的链路都是TRANK链路,那么IOU1将成为VLAN1和VLAN2的根桥,因为IOU1的MAC地址最小,根据生成树算法的原则,当网桥优先级相同时(默认是相同的),MAC地址小的将成为根桥。三台交换机VLAN1的网桥优先级都是32768/1/MAC,VLAN2网桥优先级都是32768/2/MAC。IOU3将阻塞E0/2端口,因为IOU3的BID比IOU2的大(MAC地址更大)。这样的选举结果无可非议,不过现在将环境改成图1的情况,再次观察生成树选举的情况。
实验步骤:
第一步:查看三台交换机 VLAN1生成树选举情况,结果每台交换机都认为自己是VLAN1的根桥。如下图:
IOU1认为自己是VLAN1的根桥
IOU2认为自己是VLAN1的根桥
IOU3也认为自己是VLAN1的根桥
分析:由于IOU1和IOU2都没有VLAN1的活动接口,也没有TRANK接口,只有VLAN1的非活动端口(默认所有接口属于VLAN1),它们俩发送BPDU报文的接口属于VLAN2,所以只能发出VLAN2的BPDU。IOU3发送BPDU的两个接口是属于VLAN1的,捕获IOU3 E0/1接口的数据帧,如图所示:
IOU3E0/1接口发送的BPDU
从BPDU中可以看到IOU3说自己是VLAN1(扩展系统ID=1)的根桥,E0/1接口属于VLAN1,发出VLAN1的BPDU很正常,同理E0/2接口发出的BPDU和E0/1接口发出的相同(端口标识不一样)。现在问题来了,IOU1和IOU2收到IOU3发来的BPDU会作何处理?IOU3说我是VLAN1的根桥,可是IOU1和IOU2都认为自己VLAN1的根桥,难道它们对IOU3发来的BPDU置之不理?问题的答案就在一个奇怪的BPDU报文中。
第二步:查看三台交换机VLAN2生成树选举结果,如下图:
IOU1认为IOU3是VLAN2的根桥
IOU2认为IOU3是VLAN2的根桥
分析:IOU1和IOU2都认为IOU3是VLAN2的根桥,IOU3显示没有运行VLAN2的生成树实例(图片忘了截),这里有两个问题:
问题1:为何IOU1和IOU2会认为IOU3是VLAN2的根桥,IOU3发送的BPDU明明是针对VLAN1(系统ID=1)。
问题2:既然IOU1和IOU2都认为IOU3是VLAN2的根桥了,为何IOU3显示没有运行VLAN2生成树实例?
分析问题2:IOU3没有属于VLAN2的活动端口,没有TRANK端口,连非活动端口都没有,所以IOU3不会运行VLAN2的生成树实例(这也解释了IOU1和IOU2为什么认为自己是VLAN1根桥的原因)。
分析问题1:当IOU1和IOU2收到IOU3发送针对VLAN1(系统ID=1)的BPDU时,它们不认为这是VLAN1的BPDU,即便系统扩展ID=1。因为它们的接口是属于VLAN2的,它们认为这是针对VLAN2的BPDU。通过捕获IOU1从E0/0接口发出的数据帧可以看到特殊的BPDU:
IOU1从E0/0接口发的BPDU
注:*32768+1<32768+2*
从BPDU中可以看到,IOU1认为IOU3是VLAN2的根桥是因为32768/1/MAC(IOU3的BID)小于32768/2/MAC(IOU1的BID),IOU2也是这样认为的。之所以说这是针对VLAN2的BPDU,是因为数据帧打上了VLAN2的标记。交换机ACCESS接口打标记是够奇葩的。
实验总结:
1.交换机为每个VLAN运行生成树时,如果交换机没有任何接口属于某个创建的VLAN,那么该VLAN的生成树实例将无法运行。
2.交换机不通过系统扩展ID识别VLAN的BPDU,而是通过VLAN标记来识别,系统扩展ID只是让每个VLAN具有不同的BID。
3.以上结论只是个人的YY。
转载于:https://blog.51cto.com/pkimin3/1792518