实验八：验证以太网交换机的生成树协议STP

一、 实验导读与目的

1.1 实验目的

本实验依托 Cisco Packet Tracer 模拟器，旨在通过直观的动态数据包抓取与连通性测试，完成以下两大核心验证：

1. 防环与冗余验证（正向）： 探究并验证生成树协议（STP）的工作机制，观察其如何在引入"冗余链路"以保障网络高可用性的同时，智能地阻塞特定接口，从而消除物理环路，构建出无环的逻辑网络拓扑。

2. 灾难现象验证（反向）： 直观验证"二层网络环路"的致命危害。通过人为关闭交换机的防环机制，观察广播帧在物理环路中发生"指数级复制"与"永久兜圈"的完整过程，深刻理解"广播风暴"对网络带宽和设备资源的毁灭性消耗。

1.2 核心概念预备

为了更好地理解接下来的实验现象，我们需要先了解以下四个核心网络概念：

• 冗余链路（Redundant Links）： 简单来说就是网络中的"备胎"线路。为了防止一根网线断裂导致整个网络瘫痪（单点故障），网络工程师会刻意在交换机之间多连几根线，比如连成一个三角形。这样一条路不通，还可以走另一条路。

• 网络环路（Network Loop）： 冗余链路带来的"副作用"。当交换机被连成闭环（如三角形或圆环）时，物理环路就诞生了。如果没有特殊机制加以控制，数据包就有可能在这个环圈里无限打转。

• 广播风暴（Broadcast Storm）： 这是二层网络的"绝症"。与三层 IP 数据包拥有 TTL（生存时间，每经过一个路由器减1，归零则销毁）不同，二层以太网帧没有寿命限制。一旦网络中存在物理环路，交换机会将收到的广播包盲目地向所有端口转发（泛洪），导致数据包在环路中无限复制、疯狂兜圈，瞬间耗尽设备的 CPU 资源和链路带宽，致使网络彻底瘫痪。

• 生成树协议（STP, Spanning Tree Protocol）： 拯救网络的"交通警察"。它会自动计算网络拓扑，在发现物理环路时，逻辑上强行关闭（阻塞）其中一个接口。这就好比在环形公路上设了一个路障，让死循环变成一条单行道。而当主线路发生故障时，STP 又能迅速撤销路障（重新启用接口），让"备胎"线路顶上，恢复网络通信。

二、 实验准备：构建网络基础设施

在开始"制造灾难"或"观察防环"之前，我们需要先搭建一个具备"物理冗余（环路）"特征的底层网络环境，并为所有设备分配好网络地址。

2.1 搭建物理冗余拓扑（构建物理环路）

操作目标： 使用 Cisco Packet Tracer 搭建一个由三台交换机组成的三角形闭环网络，并接入三台测试终端。

具体步骤：

1. 放置设备： 在逻辑工作区中，拖入 3 台型号为 PC-PT 的个人计算机（分别命名为 PC0、PC1、PC2），以及 3 台型号为 2960 的以太网交换机（分别命名为 Switch0、Switch1、Switch2），摆放成三角形结构。

2. 线缆连接： 在左下角的线缆工具箱中，为了简便，可选择带有闪电图标的"自动选择连接类型"工具，将交换机两两相连形成闭环，并将每台 PC 分别连接到离自己最近的交换机上。

3. 观察接口状态： 连接完成后，您会发现交换机之间连线的某些接口处出现了橙色的小圆圈。这并非线路故障！这是因为交换机默认开启了生成树协议（STP）。当它检测到物理环路时，为了防止广播风暴，正在进行复杂的计算，并将部分接口暂时置于"阻塞（Blocking）"状态。

4. 加速收敛： STP 的计算通常需要几十秒。为了节省时间，可以点击软件左下角的"快进时间（Fast Forward Time）"按钮（或使用快捷键 Alt+D），橙色圆圈很快就会变成绿色的向上箭头，表示接口已准备就绪。

2.2 IP地址规划与终端配置（分配网络身份）

操作目标： 将所有 PC 划分到同一个局域网网段内，以便后续进行连通性测试。

具体步骤：

1. 养成良好习惯（放置注释）： 使用顶部工具栏的"放置注释（Place Note）"工具，在每台 PC 旁边标注其即将配置的 IP 地址和子网掩码。这在复杂的网络拓扑中是极其重要的工程习惯。

   PC0：IP 192.168.0.1，子网掩码 255.255.255.0

   PC1：IP 192.168.0.2，子网掩码 255.255.255.0

   PC2：IP 192.168.0.3，子网掩码 255.255.255.0

2. 配置终端： 单击 PC0 图标，在弹出的配置窗口中选择 Desktop（桌面） 选项卡，点击 IP Configuration（IP配置）。

3. 在 Static（静态）模式下，依次输入上述规划好的 IP 地址和子网掩码。完成后关闭窗口，并以同样的方法完成 PC1 和 PC2 的配置。

2.3 仿真模式与协议监听设置（排除背景干扰）

操作目标： 配置模拟器的抓包过滤器，让画面中只显示我们关心的特定协议数据包，避免被其他后台协议（如 CDP、STP 报文）干扰视线。

具体步骤：

1. 切换模式： 在软件界面的右下角，将工作模式从 Realtime（实时模式）切换为 Simulation（模拟模式）。

2. 清空默认监听： 在弹出的 Simulation Panel（模拟面板）中，点击下方的 Show All/None（显示全部/无） 按钮。此时面板中的监听列表会被清空。

3. 精准过滤： 点击旁边的 Edit Filters（编辑过滤器） 按钮。在弹出的选项卡中选择 IPv4 ，然后仅勾选 ICMP（网际控制报文协议，即 Ping 命令使用的协议）。

   新手提示： 真实网络中每秒钟都有成百上千的后台数据包在乱飞。通过配置过滤器，我们就像戴上了"透视眼镜"，接下来只盯着我们亲手发出的测试包看，这样能让实验现象更加清晰易懂。

三、 阶段一：有 STP 守护的"秩序网络"（防环与冗余验证）

在这一阶段，我们将观察在默认开启生成树协议（STP）的情况下，网络是如何在保持"连通性"的同时，巧妙化解"环路危机"的。

3.1 观察 STP 的默认防环行为（化环为树）

操作目标： 观察 STP 协议如何自动切断逻辑环路。

具体观察与原理：

1. 现象观察： 仔细观察构建好的三角形拓扑。您会发现，绝大多数交换机接口指示灯都是绿色的（表示处于转发状态），但必定有一个接口的指示灯呈现橙色小圆圈（如图片标注的"阻塞"位置，通常在 Switch1 或 Switch2 上）。

2. 核心原理： 此时，Cisco 交换机后台正在默默工作。它们通过互相发送 STP 数据单元（BPDU），运行生成树算法（STA），找出了这个拓扑中的环路，并主动将其中一个接口置于"阻塞（Blocking）"状态。

   小白提示： 物理网线虽然连着，但在逻辑上，这条路已经被 STP 设了"路障"。原本的"三角形"环路，在数据包眼里变成了一个"V"字形的树状结构。这样既保证了所有的电脑都能互相连通，又从根本上杜绝了广播帧无限兜圈的可能。

3.2 全网连通性测试与 MAC 表"热身"（排除实验干扰）

操作目标： 验证防环后的网络依然全网互通，并让设备提前学习好 MAC 地址，为后续的"风暴实验"提供纯净的观察环境。

具体步骤：

1. 切换模式： 确保软件右下角处于 Realtime（实时工作模式）。

2. 执行 Ping 测试： 点击 PC0，进入 Command Prompt（命令行提示符）。

   • 输入 ping 192.168.0.2（测试与 PC1 的连通性），观察是否有 4 个 Reply 响应。

   • 输入 ping 192.168.0.3（测试与 PC2 的连通性），同样观察响应。

     ping 192.168.0.2 //测试PC0和PC1的连通性
     ping 192.168.0.3 //测试PC0和PC2的连通性

3. 原理解析（为什么这一步至关重要？）：

   • 验证成功： 即使有一个端口被阻塞，PC0 依然能 ping 通 PC1 和 PC2，证明 STP 成功找出了"连通子集"，网络没有断网。

   • 隐性目的（热身）： 这一步不仅仅是为了测试！在 Ping 的过程中，PC 之间会发送 ARP 请求来获取对方的 MAC 地址，同时交换机也完成了"自学习"（记录了 PC0、PC1、PC2 分别在哪个接口）。提前完成这一步，可以防止在下一阶段的"模拟模式"中混入大量的 ARP 解析包，影响我们对广播风暴纯粹现象的观察。

3.3 模拟链路故障：STP 的智能收敛（验证冗余备份）

操作目标： 验证当主链路断开时，"备胎"链路能否自动顶上，保证网络的高可靠性。

具体步骤：

1. 制造故障： 在上方工具栏选择"删除（Delete）"工具（红色的叉号），人为删除 Switch0 与 Switch1 之间的直连网线。

2. 观察收敛过程： 此时，原本负责通信的主路断了。网络中的交换机会立刻察觉到拓扑发生了变化。

3. 加速与验证： 点击左下角的"快进时间（Fast Forward Time）"按钮。您会神奇地发现：原本处于橙色阻塞状态的那个接口，变成了绿色的转发状态！

4. 再次 Ping 测试： 在 PC0 的命令行中再次 ping 192.168.0.2（PC1）。网络依然是通的！

   ping 192.168.0.2   //测试PC0和PC1的连通性
   ping 192.168.0.3   //测试PC0和PC2的连通性

   新手提示： 这就是网络工程师非要接成三角形的原因！当主线路（Switch0-Switch1）遭遇挖掘机挖断等物理故障时，STP 会自动撤销"备用线路"上的路障。数据包会自动绕道 Switch2 到达 Switch1。整个过程无需人工干预，网络实现了自我修复。

3.4 故障修复：STP 的重新计算（闭环验证）

操作目标： 验证网络恢复物理连线后，STP 能够再次识别环路并恢复防环状态。

具体步骤：

1. 重新接线： 使用线缆工具，重新将 Switch0 与 Switch1 连接起来。

2. 观察恢复： 此时物理环路再次出现。STP 会再次进行生成树计算，为了防止环路，它会极其果断地再次将 Switch1（或 Switch2）上的那个冗余接口变成橙色的阻塞状态。

四、 阶段二：失去 STP 保护的"灾难网络"（广播风暴验证）

在现实中，网络设备的防环机制（如 STP）默认是开启的。为了探究物理环路到底有多可怕，我们现在要人为扮演一次"破坏者"，拆除网络的护城河。

4.1 拆除网络护城河：全局禁用 STP

操作目标： 关闭所有交换机上的生成树协议，让人为制造的物理环路（三角形接线）变成真正致命的逻辑环路。

具体步骤：

1. 单击 Switch0，进入 CLI（命令行界面）选项卡。

2. 依次输入以下命令，禁用 VLAN 1（默认 VLAN）上的 STP 功能：

   Switch>enable                                //初次进入Switch0的命令行后，默认处于用户执行模式，在用户执行模式的命令行提示符后输入命令enable进入特权执行模式
   Swicth#configure terminal                    //在特权执行模式的命令行提示符后，输入命令configure terminal即可从特权执行模式进入全局配置模式
   Switch(config)#no spanning-tree vlan 1       //在全局配置模式的命令行提示符后，输入命令，禁用Switch0的VLAN1上的生成树协议STP

3. 极度重要： 重复上述操作，依次关闭 Switch1 和 Switch2 的 STP 功能。

   核心警示： 只有当环路上的所有设备都失去了防环能力，风暴才会真正成型。此时，网络看似平静，实则已经变成了一个随时会被引爆的"火药桶"。

4.2 "慢动作"回放：广播风暴的成型始末

操作目标： 利用 Simulation（模拟模式）发送一个广播包，逐帧观察它是如何失控的。

具体步骤： 切换到 Simulation 模式。使用上方工具栏的"添加复杂 PDU（Add Complex PDU）"工具，或者让 PC0 尝试 Ping 一个不存在的地址以触发 ARP 广播。点击"单步向后/向前（Capture/Forward）"按钮，我们来逐帧解析这场灾难：

第一阶段：风暴的起源与初次泛洪

• 现象： 绿色的数据包（信封）停留在 PC0 图标上。

• 原理： 此时，源主机 PC0 刚刚构建好一个广播帧（例如一个 ARP 请求包）。这个数据帧的核心特征是：它的二层目的 MAC 地址被设置为全局广播地址（FF:FF:FF:FF:FF:FF）。此刻数据帧还在 PC0 的网卡中，正准备发送到物理链路上。

第一步：准备发送

• 现象： 绿色的数据包沿着连线，从 PC0 移动到了与其直连的接入交换机 Switch0 上。

• 原理： 数据包完成了第一段物理传输。Switch0 的对应端口接收到了该帧。此时，交换机内部正在进行"读表"操作：

  1. 学习： 交换机会读取该帧的"源 MAC 地址"，并将其与接收该包的端口绑定，记录到自己的 MAC 地址表（CAM 表）中。

  2. 决策： 交换机会读取该帧的"目的 MAC 地址"。因为它看到目的是全 F 的广播地址，所以它准备执行交换机的核心机制之一------泛洪（Flooding）。

第二步：到达网关

• 现象： 原本在 Switch0 上的 1 个绿色信封消失了，变成了 2 个信封，分别出现在上方的 Switch1 和右侧的 Switch2 上。

• 原理： 这完美印证了交换机处理广播帧的泛洪（Flooding）机制。Switch0 读取到该帧的目的 MAC 地址是 FF:FF:FF:FF:FF:FF（广播地址）。根据规则，Switch0 会将该数据帧从除了接收端口（连接 PC0 的端口）之外的所有处于转发状态的端口复制并发送出去。因此，一份副本沿着左侧的虚线链路发给了 Switch1，另一份副本沿着底部的虚线链路发给了 Switch2。

第三步：初次泛洪

第二阶段：致命的交叉与环路闭合

• 现象： 画面变得更加复杂，这是最核心的转折点。上方：PC1 收到了信封。右侧：PC2 收到了信封。关键点： 在底部的 Switch2 上，信封重叠了。如果你仔细看动态模拟，实际上是 Switch1 把收到的信封发给了 Switch2 和 PC1；同时，Switch2 把收到的信封发给了 Switch1 和 PC2。这两台交换机正在互相发送同一个广播包的副本。

• 原理： 当 Switch1 收到来自 Switch0 的广播包时，它同样执行泛洪规则，向其连接的 PC1 和 Switch2 转发。当 Switch2 收到来自 Switch0 的广播包时，它也执行泛洪规则，向其连接的 PC2 和 Switch1 转发。因为物理拓扑中存在一个环路（Switch0-Switch1-Switch2 构成了一个三角形闭环），导致广播帧不仅没有在边缘设备（PC）处终结，反而交叉进入了对方的链路，这就为接下来的"无限循环"埋下了伏笔。

第四步：交叉感染

第三阶段：指数级放大与设备抓狂

• 现象： 上方 Switch1 和右侧 Switch2 上出现了带有红色"X"的信封。关键点： 底部 Switch0 上再次出现了一个绿色的正常信封，并且右侧 Switch2 旁边也有一个绿色信封准备发出。

• 原理：

  • 红色"X"的出现： 在 Packet Tracer 模拟器中，交换机上出现红叉通常意味着它丢弃了某个特定的帧。在产生环路的情况下，这通常是因为MAC地址漂移（MAC Flapping）。当 Switch1 从 Switch0 收到 PC0 的包时，它记录 PC0 在左侧接口；紧接着它又从右侧的 Switch2 收到了同样源自 PC0 的包，它会发现同一个源 MAC 地址竟然从不同的端口进来了，这会导致交换机的 MAC 地址表不断错误刷新。同时，部分同一时刻到达的完全重复的冲突包也可能被模拟器丢弃。

  • 绿色信封的"倒流"： 尽管有报错和丢包，但泛洪并没有停止。Switch1 和 Switch2 将之前收到的广播包，顺着左下和右下的网线，反向发回给了底部的 Switch0。这就彻底完成了物理环路上的逻辑闭环。

第五步：反向倒流与丢包

• 现象： 令人震惊的一幕出现了：最左侧的源主机 PC0 上居然出现了一个绿色的信封！同时，顶部的 Switch1 和右侧的 PC2 也再次收到了信封。

• 原理：

  • 发件人收到了自己的信： 底部的 Switch0 收到了从上方或右侧交换机"兜兜转转"回来的广播帧。此时 Switch0 再次死板地执行交换机的泛洪规则（向除了接收该包的其他所有端口转发）。于是，它把这个广播帧发给了 PC0。这就直接证明了环路的存在：PC0 竟然收到了自己最初发出的广播包。

  • 风暴的全面爆发： 与此同时，各个交换机依然在把收到的包向其他端口（比如发给 PC2 和 Switch1）盲目转发。此时，这个最初始的那个广播包已经像病毒一样被复制成了无数份，开始在三台交换机之间顺时针、逆时针地疯狂兜圈，并且不断地去"骚扰"边缘的电脑（PC0、PC1、PC2）。

第六步：反噬发送者

• 现象： 顶部的 PC1 再次收到了一个绿色的信封；同时，右下角的 Switch2 正在丢弃一个数据包（显示为红色的"X"）。

• 原理：

  • 持续轰炸： 这说明刚才在环路中兜圈的广播包，又一次流经了 Switch1。Switch1 依旧遵循泛洪规则，将这个复制品又塞给了 PC1。对于 PC1 来说，它什么都没做，却在不断被迫接收无用的网络垃圾。

  • 设备"抓狂"： Switch2 上的红叉，生动地展示了交换机此时的内部状态。由于同一个广播包在环路里疯狂正反向游走，交换机会发现同一个源 MAC 地址（比如最初发包的 PC0 的 MAC）前一秒从左边端口进来，下一秒又从右边端口进来。这会导致交换机的 MAC 地址表发生高频的MAC地址漂移（MAC Flapping），设备处于极度混乱的状态，从而引发冲突和丢包。

第七步：全面失控

• 现象： 画面再次变得拥挤！最初的发件人 PC0，以及右侧的 PC2，同时又一次收到了绿色的信封。底部的 Switch2 上有绿色的信封正在流转，而顶部的 Switch1 上又出现了代表丢包的红叉。

• 原理：

  • 无 TTL 限制的灾难： 这是整个演示中最核心的知识点！在三层网络（如路由器处理的 IP 包）中，有一个叫 TTL（生存时间）的机制，每过一跳减 1，减到 0 包就消失了。但在这里的二层以太网帧中，根本没有 TTL 字段！这意味着这些在环路中的广播包具有"无限的生命力"。

  • 指数级放大： 每当一个广播包到达任何一台交换机，它不仅会顺着环路继续往下传，还会被复制一份"砸"向连接的边缘电脑。PC0 和 PC2 再次收到包，就是因为交换机在无休止地执行盲目的泛洪复制。网络带宽正在被这些几何级数倍增的"幽灵数据包"迅速吞噬。

第八步

• 现象： 最左侧的发送源 PC0 和最右侧的 PC2 再次同时收到了绿色的信封，与此同时，顶部的 Switch1 也正在处理一个绿色的数据包。

• 原理：

  • 无死角的"垃圾"覆盖： 此时的交换机已经完全退化成了盲目的"复印机"。因为没有类似 IP 数据包中 TTL（生存时间）的防环机制，数据帧在三台交换机组成的环路中双向狂奔。

  • 反噬发送者： 只要这个包到达任何一台交换机，它就会被无情地复制，并"溢出"到连接终端的链路上。这也是关键点------在二层环路中，没有一台终端能幸免于难，连最初发送正常请求的 PC0 都在不断被自己发出的数据包反噬，被迫消耗 CPU 去处理这些无效包。

第九步

• 现象： 这一秒"炮火"发生了转移，顶部的 PC1 再次收到了信封。最值得注意的是，右下角的 Switch2 上出现了红色的"X"包与正常的绿色信封重叠的极度混乱状态。

• 原理：

  • 持续轰炸与设备崩溃边缘： PC1 再次收到包，证明了泛洪是一刻不停的。而 Switch2 上红绿交织的现象，生动地体现了交换机内部逻辑的彻底紊乱。

  • MAC 地址表崩溃（教学高光点）： 由于同一个广播包（带着 PC0 的源 MAC 地址）正在极高频地从 Switch2 的左侧端口和上方端口交替涌入，Switch2 的 MAC 地址表在疯狂地改写："PC0在左边...不对，PC0在上面...不对，又在左边..."。这种现象叫做 MAC 地址漂移（MAC Flapping）。这会导致交换机 CPU 占用率瞬间飙升，设备在盲目转发和逻辑冲突引起的丢包之间痛苦挣扎，真实物理环境下的网络此时已经完全瘫痪了。

第十步

第四阶段：全网瘫痪

• 现象： 底部的两台交换机（Switch0 和 Switch2）上同时正在处理绿色的信封。最左侧的发件人 PC0 又一次收到了信封（带有绿色小勾，表示接收）。而顶部的 Switch1 上再次出现了代表丢包的红色"X"。

• 原理：

  • 设备不堪重负： 顶部 Switch1 的红叉反复出现，生动地展示了交换机在高频的 MAC 地址漂移（MAC Flapping）和数据包冲突下，内部处理机制已经严重受挫。

  • 无情的"复印机"： 尽管顶部设备在报错，底部的 Switch0 和 Switch2 依然在机械、死板地执行泛洪操作。每次泛洪，都会在网络中额外产生新的副本。广播帧就像"细胞分裂"一样，在三条链路上不断成倍增生。

第十一步

• 现象： 这一帧画面中，信封的位置又发生了轮转。顶部的 Switch1 正在处理绿色的信封；而最左侧的 PC0 和最右侧的 PC2 双双再次被绿色的信封"击中"。

• 原理：

  • **全网覆盖的灾难：**PC0 和 PC2 不断地重复接收同一个数据包的副本，说明广播风暴已经没有死角地充斥了整个网络。

  • 终端资源的无谓消耗： 对于边缘的电脑（如 PC2）来说，网卡中断会不断被触发，CPU 被迫不断去拆解这些二层广播帧，然后发现不是自己的业务数据再丢弃。网络不仅无法传输正常业务，连电脑本身的运行都会被拖慢。

第十二步

• 现象： 顶部的 PC1 又一次 被迫接收到了绿色的信封。而画面的焦点在于右下角的 Switch2，它上面出现了严重重叠的数据包，并且伴随着一个非常醒目的红色"X"。

• 原理：

  • 终端的无尽折磨： 处于网络边缘的 PC1 再次收到广播帧，这向学生们直观地展示了广播风暴的"溢出效应"。虽然环路发生在交换机之间，但每一次交换机执行泛洪，都会把这些垃圾数据"倾泻"给连接着的终端电脑。PC1 的网卡和 CPU 不得不持续被打断，用来处理这些根本不是发给自己的垃圾信息。

  • 交换机的"宕机"边缘（红叉解析）： Switch2 上出现的红绿交叠和红叉，是由于顺时针和逆时针两个方向兜圈的广播包，在极短的时间内同时涌入了这台交换机。

    1. MAC 地址表错乱： 交换机发现同一个源 MAC 地址在两个不同的端口上疯狂横跳（MAC Flapping），导致内部转发表极度混乱。

    2. 资源耗尽： 大量的无用数据包瞬间塞满了交换机的缓存（Buffer），超出了它的处理能力，设备只能被迫丢弃数据包（显示为红叉）。

第十三步

4.3 终极后果：网络资源耗尽与彻底断联

操作目标： 切回真实时间，验证风暴对正常通信的毁灭性打击。

具体步骤与现象：

1. 切回实时模式： 点击软件右下角的 Realtime（实时模式） 按钮。

2. 物理惨状观察： 您会立刻看到，所有交换机的接口状态指示灯都在极速、疯狂地闪烁。这在真实的机房中是非常恐怖的现象，表明链路正承受着满载的垃圾流量轰炸。

3. 通信瘫痪验证： 再次打开 PC0 的命令行，执行 ping 192.168.0.2。

   • 结果： 之前畅通无阻的测试，现在会显示 Request timed out（请求超时）。

   • 原理总结： 虽然物理网线连得好好的，但网络带宽已经被兜圈的广播帧100%挤占，正常的 ICMP 测试包根本排不上队，也无法被交换机处理。网络在物理上连通，但在逻辑上已经彻底"死亡"。

五、 实验总结 (Conclusion)

通过本次实验的正反对比，我们深刻验证了以下网络工程核心真理：

1. 冗余与环路的矛盾体： 为了防止单线故障导致断网，我们在网络设计中必须引入"冗余链路"（如环形或网状接法）。但冗余必然带来物理环路，而二层网络的泛洪机制加上无 TTL 限制的特性，使得物理环路必定引发毁灭性的"广播风暴"。

2. STP 协议的不可或缺： 生成树协议（STP）是化解这一矛盾的完美钥匙。它像一位不知疲倦的交警，在物理上保留了所有的备用道路，但在逻辑上巧妙地设置"路障"（阻塞端口）打破环路。当主路不通时，又能迅速移开路障，实现网络的平滑自愈。

搞网络，线不能乱连，连成了圈必定死机；如果要连成圈保命（冗余），就绝对不能关掉 STP（生成树）！