让数据帧告诉你生成树的选举原则

                              让数据帧告诉你生成树的选举原则 

 

简单描述一下生成树选举原则：

1. 最小的根网桥ID（用于选举根桥）

2. 最小的根路径开销（用于选举根端口和指定端口）

3. 最小的发送者网桥ID（用于选举根端口和指定端口）

4. 最小的发送者端口ID（用于选举根端口和指定端口）

现在以图1的环境并结合数据帧的形式来说明上述的4种选举原则：

                                                      图1 实验环境

 从图1中可以看到，运行了生成树算法之后，S4选择阻塞F0/0，S5选择阻塞F0/2。为什么会选择阻塞这两个端口？一定是S4和S5看到根桥产生的BPDU后做出的选择。不对！应该是看到非根桥转发的BPDU后做的选择……。不说绕口令了，回到生成树选举原则上吧！首先是选择根桥，S1成为根桥没有争议，默认网桥优先级都是32768，S1的MAC最小所以成为根桥。第一条选举原则（最小的根网桥ID）没啥可说的。没啥可说就继续说绕口令吧！之前说到看到非根桥转发的BPDU后做的选择……

*注：最小网桥ID决定了S1是根桥。

非根桥转发的BPDU:

    传统生成树中只有根桥才能产生配置BPDU，非根桥只是转发根桥产生的BPDU。试想一下如果仅仅只是转发根桥的BPDU，不对BPDU做任何更改，就像转发常规数据帧一样。这样的话S4和S5怎么判断阻塞的端口，又凭啥要阻塞我的端口。这就引出了关键点——非根桥转发的BPDU。

                           图2：非根桥转发的BPDU和根桥产生的BPDU

从图2中可以看出非根桥转发根桥BPDU时做了如下修改：

1. 根路径开销

2. 发送者网桥ID

3. 端口标识

这三个修改的参数决定了S4和S5做出何种选择，下面通过三个步骤来分解S4和S5阻塞端口的过程。

第一步：S2和S3看到的BPDU：

                                    图3：S2和S3看到的BPDU

   当S2和S3看到图3的BPDU后心想，唉！只恨我MAC地址不如你，算了吧！天生的缺陷，暂时帮你转转报文吧！我看还是先不要把根端口定下来，万万不可操之过急，先看看还有没有更小的BID出现，就算没有更小BID，我还得看看会不会从别处也收到同样的BPDU，希望别收到了。最终S2和S3如愿了，将F0/0和F0/1置为根端口。

*注：根路径开销决定了S2和S3的根端口。

第二步：S4看到的BPDU：

                                       图4：S4看到的BPDU

    当S4看到图4中的BPDU后心想：我的梦想原本是成为根桥，可残酷的现实告诉我，我连根桥前三候选者都排不进去。唉！算了，先定夺根端口吧。老二（S2）告诉我到老大（S1）的开销是19，老三（S3）告诉我到老大（S1）的开销也是19，当然是选择老二的那条路了，老三那条路只能堵上了。

*注：网桥ID决定了S4的根端口，路径开销决定了阻塞端口。

第三步：S5看到的BPDU：

                                        图5：S5看到的BPDU

当S5看到图5中的BPDU后也没什么想法了，MAC地址比根桥的大太多了，只剩下选择根端口的问题了。S5的F0/3和F0/2收到S4发来的BPDU报文里唯一的不同只有端口ID，那就只有比较端口ID了，哪个端口接收到的端口ID大就阻塞该端口，就这么简单粗暴。

*注：端口ID决定了S5的根端口，路径开销决定了阻塞端口。

总结：不用死记硬背生成树选举原则，答案就在BPDU报文中。比如说S5为什么要通过比较发送者端口ID来选择根端口，S5的两个端口收到两份BPDU报文里唯一的不同点就是端口ID，不比较端口ID还比较啥?