企业官网建设流程全解析

上周帮一位做运维的朋友看他那套园区网，核心双机、接入十几台交换机，冗余链路做得很齐整。可每次拔一根光纤，办公区就要卡上三四秒，视频会议直接掉线重连。他一口咬定是设备性能不够，我登上去看了三分钟：生成树跑的仍是传统STP，所有交换机优先级都是出厂默认，根桥完全是靠MAC地址大小“抽签”选出来的。把模式切成RSTP、核心优先级调到4096、接入侧配好边缘端口，再做同样的拔线动作，长ping只丢一个包。这就是RSTP（快速生成树协议，IEEE 802.1w）的价值——它不换硬件、不加带宽，只把原来“傻等定时器”的收敛过程改成了一次握手协商。这套东西的原理和配置加起来其实就那几页纸，但真正踩过坑、抓过包、被半双工链路和错配的边缘端口坑过的人并不多。这篇就把RSTP从我自己的理解角度拆开：先讲它到底改了什么，再讲握手机制怎么一步步跑起来，然后给一套可以直接抄的双核心接入网配置，最后是六个我实际遇到的排障场景和速查表。不管你是刚接触交换机的入门选手，还是想把生成树这块补扎实的老手，都能从里面挑到能用的东西。

1. 先算清账：RSTP到底修掉了STP的哪些硬伤

1.1 一次拔线丢三秒，时间被谁偷走了

传统STP收敛慢，根子不在算法笨，而在它把“状态迁移”完全托付给了三个固定定时器：Hello 2秒、Forward Delay 15秒、Max Age 20秒。链路断掉以后，下游交换机要等到Max Age超时才发现“上家的BPDU不来了”，这已经是20秒；接着端口从Blocking进Listening要等15秒，从Listening进Learning再等15秒，最后才Forwarding。哪怕一切顺利，30秒起步，稍微有点风吹草动就是50秒。

更要命的是故障发现的机制。STP里只有根桥周期性发BPDU，非根桥收到后往下转发，一旦根桥挂掉，第二台交换机必须靠“Max Age超时”来判断根桥没了。也就是说，收敛时间不是由故障大小决定的，而是由“等多久没消息算死掉”这个保守参数决定的。

我在一个老机房里实测过一次：断开根桥的上行链路，业务恢复用了32秒，期间ping丢了31个包。而换成RSTP之后，同样的操作只丢了1到2个包。差距不在硬件，在于RSTP把这个“等”的动作换成了“问”。

1.2 RSTP做的三件实事：不问定时器，改问邻居

RSTP的核心改动可以概括成三条，理解了这三条，后面所有细节都是它们的推论。

第一，每个交换机自己发BPDU，不等根桥喂。RSTP里所有运行该协议的设备都按Hello Timer（默认2秒）独立发送BPDU，内容是本机认为的根桥信息和自己的端口角色。这样一来，根桥一挂，邻居在3个Hello（约6秒）内就能从“收不到更优BPDU”判断出问题，而不是傻等20秒。

第二，BPDU里带上了端口角色信息。老STP的BPDU只传“我这条消息的优先级是多少”，下游只能靠推算和定时器判断自己该当什么角色。RSTP直接在Flags字段里写明“我这个端口是根端口、是指定端口还是替代端口”，下游收到就能立刻定位，不需要推理过程。

第三，用Proposal/Agreement握手替代监听学习等待。这是收敛能从30秒压到毫秒级的根本原因，下一节会完整推演一遍。简单说，上游发“我要开始转发了”，下游回“收到，我这边已经准备好了”，两边一确认，端口立刻进转发，中间不需要任何计时。

注意：RSTP的“快”有前提条件——点对点全双工链路。半双工、共享介质、或者对端是只支持STP的老设备，握手就退化成老机制，快不起来。这一点在排障时极其关键，后面会专门讲。

1.3 什么时候RSTP够用，什么时候必须上MSTP

经常有人问，既然有MSTP，RSTP是不是已经过时了。我的看法是，RSTP和MSTP不是替代关系，是包含关系——MSTP在RSTP的基础上做多实例，而单实例场景下RSTP跑得比MSTP更省资源、更简单。

判断标准我一般这样分：

我个人的偏好是：园区接入层用RSTP，核心到汇聚之间如果确实需要VLAN级的负载分担才上MSTP。很多项目上MSTP纯粹是“别人都这么配”，结果实例划分得乱七八糟，排查一次环路要画半天图，得不偿失。

2. 端口角色与状态：五种角色和三种状态背后的逻辑

2.1 从三种角色到五种：多出来的两种是干什么的

STP只有根端口、指定端口、阻塞端口三种角色，其中“阻塞端口”是个筐，什么都往里装——既包括本来就不该转发的备用路径，也包括正在等待状态的临时端口。RSTP把阻塞拆成了替代端口（Alternate）和备份端口（Backup），另外还有一个Disabled。

• 根端口（Root）：每台非根桥有且只有一个，是到根桥路径开销最小的端口，负责上行。
• 指定端口（Designated）：每条链路上开销更优的那一端，负责把BPDU往下游发，也是链路上下行数据的出口。
• 替代端口（Alternate）：收到了别的交换机发来的更优BPDU，但自己不是那条链路的最佳出口。它的意义是——一旦根端口故障，它能立刻顶上，因为转发状态的数据是准备好的。
• 备份端口（Backup）：同一台交换机上两个端口接到了同一个共享网段，其中一个被另一个的BPDU压住。现在基本都是全双工点对点，这种角色实务中极少见。
• Disabled：端口被关闭或链路down，不参与计算。

替代端口是RSTP收敛快的另一个隐藏功臣。因为拓扑收敛的过程中，计算好的备用路径已经处于“随时可切换”的状态，根端口一倒，替代端口立刻变成根端口进入转发，中间不需要重新算一遍。

角色判定的比较顺序必须记牢，排障时全指着它：

1. 先比根桥ID（优先级 + MAC），最小者胜；
2. 再比根路径开销（到根桥的累计开销）；
3. 再比发送者桥ID；
4. 再比发送者端口ID（端口优先级 + 端口号）；
5. 最后比接收端口ID。

这五步是严格顺序的，前面一步分出胜负就不看后面。我见过有人端口优先级配错了以为能改路径，实际上前面根路径开销早就定了胜负，白折腾。

2.2 五种状态压成三种：“丢弃”这个叫法的由来

STP的五个状态——Disabled、Blocking、Listening、Learning、Forwarding——在RSTP里被压成了三个：Discarding、Learning、Forwarding。

这个压缩不是文字游戏。原来Disabled、Blocking、Listening三个状态在行为上有区别，但对数据转发来说其实是一样的：都不转发、都不学MAC。RSTP直接把它们合并成Discarding，语义上更干净：这个端口现在什么都不干。Learning还是Learning，学MAC但不转发；Forwarding还是转发。

这个改动带来的直接好处是状态机和握手解耦了。老STP里端口必须走完Listening才能进Learning，这个时间由Forward Delay控制，没法跳过。RSTP里Discarding进Forwarding可以由握手协议直接推动，定时器只在少数回退场景下才起作用。

提示：RSTP里Forward Delay默认还是15秒，但它在正常收敛路径上基本用不到，只在“握手失败回退到老机制”或者“端口从阻塞老化为丢弃”这类边缘场景才生效。很多新手看到配置里还有15秒就以为没生效，实际抓包看BPDU握手，端口是毫秒级进转发的。

2.3 开销的取值：长整型还是短整型，别配混了

RSTP默认用长整型开销（IEEE 802.1t），取值跨度大，能区分高速链路：

短整型的问题是分辨力太差：1G和10G的取值是4和2，一条千兆和一条万兆的差距只有2，随便加两跳就把差距抹平了。长整型下1G是20000，10G是2000，差10倍，路径选择的意图能准确表达出来。

实际配置里我建议全网站一使用默认的长整型。混用会导致什么后果？A设备按短整型算出来路径开销19，B设备按长整型算出来20000，两边对“哪条路更优”的认知直接冲突，可能出现短暂的转发环路。这种坑非常隐蔽，出问题时用display stp看两端的Root Cost对不上，才知道是开销模式不一致。

3. 快速收敛的真身：Proposal/Agreement握手的完整推演

3.1 一场握手的全程：从根桥发出Proposal开始

这是RSTP最核心的机制，也是面试和实战里最常被问到的部分。我用一个两台交换机的场景完整推一遍，假设SW-A是根桥，SW-B是新接入或者链路刚恢复的交换机。

第一步，SW-A的指定端口（连接SW-B那一侧）准备进入转发，它在发出的BPDU里把Proposal标志位置1。这个动作的含义是：“我这条链路想立刻开始转发，你同意吗？”

第二步，SW-B的端口收到这个Proposal，先做一次优先级比较，确认SW-A确实是更优的邻居，于是把这个端口认定为根端口，但此时先置为Discarding，不发数据。

第三步，SW-B执行同步操作：除了收到Proposal的这个端口，把本机所有其它非边缘端口统统置为Discarding状态，防止在握手期间形成临时环路。这一步是同步的，瞬间完成。

第四步，SW-B从刚认定的根端口回送一个BPDU，把Agreement标志位置1。含义是：“我这边已经全部就绪，你转吧。”

第五步，SW-A收到Agreement，立刻把指定端口置为Forwarding，跳过原来要等的30秒。

第六步，SW-B的根端口在同步完成后也立即进Forwarding。同时，SW-B自己其它的指定端口会重复上述过程，向更下游的交换机发送Proposal，一级一级往下推。

整个过程是级联的，每一跳只花一个往返的时间，所以整网收敛时间取决于树的深度，而不是设备数量。三层结构下，实测通常在一百毫秒以内。

注意第三步的同步操作是“伤及无辜”的：它会把本机所有非边缘端口短暂拉进Discarding。如果边缘端口没配好，接入PC的端口也会被拉一下，表现就是链路恢复的瞬间业务全断一下。这就是为什么接入层必须配边缘端口，不只是为了快，也是为了不让它被同步操作波及。

3.2 为什么必须是点对点全双工：握手的物理前提

Proposal/Agreement能成立的前提有两个，缺一不可。

第一，链路必须是点对点。如果中间挂了一台集线器或者共享式设备，一个Proposal发出去，可能有三台交换机同时收到并同时回Agreement，握手就失去了“一对一确认”的意义。RSTP在这种情况下会检测到链路类型不是点对点，主动不发Proposal，退回传统收敛方式。

第二，链路必须全双工。半双工意味着收发共享介质，存在冲突检测，无法保证握手在确定的时间内完成。RSTP检测到半双工也会退化成老机制。

这两个条件在配置里对应的是stp point-to-point（多数设备默认auto，会根据双工状态自动判断）。我遇到过一种情况：光纤收发器一端自适应成了半双工，链路上看着是up的，但生成树死活快不起来。用display stp interface看端口状态，发现点对点属性是no，才找到根因。所以排“收敛慢”这类问题时，先看双工和链路类型，比看优先级有效得多。

另外还有一种“假快”的情况：端口是边缘端口，链路up直接进转发，看起来很快，但根本没过生成树计算。这种配置在有环路风险的场景下非常危险，下一节会讲怎么防。

3.3 拓扑变化传播：RSTP的TC机制比STP省事在哪

STP里拓扑变化是这么走的：发现变化的交换机往根桥方向发TCN，逐跳转发到根桥，根桥再把TC置位的BPDU广播全网，还要持续Max Age + Forward Delay的时间。一来一回，慢且啰嗦。

RSTP改成谁发现谁发起：检测到拓扑变化的交换机直接启动一个TC While Timer（默认是2倍Hello，即4秒），在这段时间内从所有指定端口（除收到BPDU的端口外）发出TC置位的BPDU，同时清空本机除该端口外的MAC表项。收到TC的交换机也照做，往自己下游扩散并清表。

什么算拓扑变化？RSTP定义得很克制：只有非边缘端口从Learning进入Forwarding才算。边缘端口的up/down不触发TC——这条极其重要，它意味着接入层用户插拔网线不会引起全网的MAC表刷新。这解决了STP时代一个常见的性能问题：一个员工反复插拔网线，全公司交换机MAC表跟着抖。

还有一点容易忽略：端口从Forwarding变成Discarding不算拓扑变化，不会触发TC。因为这条路径本来就不在转发，断了只是少了一条路，不需要全网重新学习MAC。

4. 配置落地：一套双核心接入网的完整过程

4.1 拓扑与规划：先把优先级和开销算出来

这一节直接给一套能抄的方案。场景如下：两台核心交换机CORE-A、CORE-B，四台接入交换机ACC-1到ACC-4，每台接入双上行分别接两台核心，形成全冗余。VLAN 10、20、30三个业务VLAN，不做VLAN级负载分担，整网一棵树。

根桥规划：CORE-A做根桥，CORE-B做备份根桥。优先级取值必须是4096的整数倍（因为优先级字段低12位留给系统ID扩展，只有高4位可配）。取值计算：

• CORE-A：优先级4096，桥ID = 4096 + MAC，全网最小，成为根桥；
• CORE-B：优先级8192，桥ID次小，成为备份根桥；
• 接入层：保持默认32768，MAC随机，不影响结果。

为什么不把CORE-A设成0？因为0是绝对最小值，一旦以后要插一台新的核心，没法再把优先级压得比它更低。留一档4096，给未来的扩展留余地。这个细节很多资料不讲，但实际运维时很管用。

路径开销：核心到接入是千兆光纤，长整型开销20000。接入到核心的根路径开销就是20000。备用路径（经CORE-B间接到CORE-A）还要再加一段，开销更大，所以CORE-A侧的端口成为根端口，CORE-B侧的端口成为替代端口。这是标准的主备结构。

边缘端口：所有连接终端设备的端口全部配成边缘端口，包括接PC、接打印机、接AP、接服务器的口。注意服务器如果做了网卡绑定或者跑虚拟化，可能需要保留生成树参与，这个要单独确认。

4.2 核心层配置：模式、优先级、根保护一步到位

先看CORE-A。以常见的CLI语法为例（不同厂商关键字略有差异，含义一致）：

system-view sysname CORE-A stp mode rstp stp priority 4096

CORE-B对应改成stp priority 8192。这里的关键点是stp mode rstp要在全局视图下、在接口配置之前就设好，避免中途切换模式引起短暂环路。

然后是下行接口配置。以接ACC-1的千兆口为例：

interface GigabitEthernet0/0/1 port link-type trunk port trunk allow-pass vlan 10 20 30 stp point-to-point

stp point-to-point建议显式配置，虽然多数设备默认自动判断，但显式配置能避免双工协商异常导致的握手退化。

核心层的上行口（如果有）不配根保护。根保护只配在指定端口上，用于防止下游设备抢走根桥身份：

interface GigabitEthernet0/0/1 stp root-protection

这个配置的含义是：如果我这个指定端口收到了比我更优的BPDU（说明下游有人在宣称自己是更优的根），我就把这个端口置为Discarding，进入root-inconsistent状态，等超时后自动恢复。这样能防止接入层某台设备被误配成高优先级后把根桥抢走，导致全网流量绕行。

再看一套另一种风格的等价配置，方便对照记忆：

spanning-tree mode rapid-pvst spanning-tree vlan 10 priority 4096 interface GigabitEthernet0/1 spanning-tree guard root

4.3 接入层配置：边缘端口是重点，BPDU保护是保险

接入交换机的配置分两部分。全局部分只设模式，不动优先级：

system-view sysname ACC-1 stp mode rstp stp bpdu-protection

stp bpdu-protection是BPDU保护开关，它的作用是：边缘端口一旦收到BPDU，立刻把端口down掉（或进入error-down状态）。正常终端设备不会发BPDU，收到BPDU说明这个口下面接的要么是误接的交换机，要么有人私接了路由器做桥接，两种情况都会引起环路。所以这条是接入层必备的保险丝。

接口部分，所有接终端的口：

interface GigabitEthernet0/0/2 port link-type access port default vlan 10 stp edged-port enable

上联核心的两个口：

interface GigabitEthernet0/0/24 port link-type trunk port trunk allow-pass vlan 10 20 30 stp point-to-point

上联口绝对不能配边缘端口。这个错误我见过不止一次：有的人图省事，在接口视图下批量敲stp edged-port enable，把上联口也带进去了。结果是上联口直接进转发、不参与计算，两条上行链路同时转发，环路立刻出现，全网广播风暴。所以批量脚本一定要用接口列表精确指定。

另一种风格的等价配置：

interface GigabitEthernet0/2 switchport mode access switchport access vlan 10 spanning-tree portfast spanning-tree bpduguard enable

4.4 验证：三个命令看状态，一次抓包看握手

配完必须验证，光看配置敲进去不算数。我常用三步：

第一步，看全局根桥身份：

display stp

输出里重点看CIST Root/ERPC那一行，如果Root ID对应的MAC是CORE-A，说明根桥选举正确。再看CIST Bridge，确认本机的桥ID。

第二步，看端口角色和状态：

display stp brief

这张表是我排障时打开最多的。重点核对三项：根端口是不是在预期的上行口上、替代端口（ALTE）是不是出现在备路上、边缘端口的状态是不是EDGE+FORWARDING。如果发现某个接入口角色是DESI但没有EDGE标记，说明边缘端口没配成功。

第三步，抓包看Proposal/Agreement。有条件的话在核心下行口做镜像抓包，过滤BPDU（二层协议，目的MAC是01:80:c2:00:00:00），看Flags字段。正常情况下链路恢复时能看到一个Proposal置位的包立即跟一个Agreement置位的包，间隔在毫秒级。如果只看到普通的周期Hello（2秒一个），说明握手没触发，多半是链路类型判断成了共享介质或者对端是STP设备。

5. 保护特性：让生成树从“能跑”到“扛得住”

5.1 BPDU保护：边缘端口的第一道闸

边缘端口的设计初衷是“相信这个口下面没有交换机”，但现实里这个信任经常被打破：员工从家里带来一台小路由器，LAN口随便一插，路由器自带的桥接功能就开始发BPDU；或者施工时把两根网线接成了环。这两种情况都会让边缘端口收到BPDU，如果不管，边缘端口也可能参与计算，引起端口震荡甚至环路。

BPDU保护的处理方式是直接掐断：边缘端口收到BPDU瞬间置为error-down，端口停止转发，同时产生日志和告警。这样环路最多影响这一个口，不会扩散。

端口down掉之后需要人工或自动恢复。自动恢复用这条：

error-down auto-recovery cause bpdu-protection interval 300

意思是300秒后自动尝试恢复。我建议开自动恢复，但要配合告警监控，否则端口反复down/up没人知道，等于隐患一直存在。

提示：BPDU保护只对边缘端口生效。非边缘端口收到BPDU是正常行为，不会触发。所以这条配置的前提是边缘端口配得准确，配错了就等于给自己埋雷。

5.2 根保护与环路保护：两个方向相反的防护

这两个特性经常被搞混，我用一句话区分：根保护防的是“别人来抢根”，环路保护防的是“我收不到BPDU还以为路通了”。

**根保护（Root Protection）**配在指定端口上。正常情况下，指定端口应该收到比自己差的BPDU，如果突然收到更优的，说明下游有设备想当根。根保护会把该端口置为root-inconsistent（本质是Discarding），既不转发数据也不转发BPDU，等一段时间没再收到更优BPDU就自动恢复。典型应用就是核心下行口、接入上行口。

环路保护（Loop Protection）配在根端口和替代端口上。它防的是单向链路：光纤断了一芯，或者收发器坏了一侧，端口物理上还是up，但BPDU只能收不能发，或者只能发不能收。这种情况下根端口收不到上游BPDU，会以为上游挂了，触发切换，而实际上链路还在单向传数据，环路就出来了。环路保护的做法是：根端口/替代端口在超时时间内收不到BPDU，就把它置为loop-inconsistent（Discarding），宁可断也不环。

interface GigabitEthernet0/0/1 stp loop-protection

这两个特性我一般成对部署：所有指定端口配根保护，所有根端口和替代端口配环路保护。看起来配得多，实际上就两条命令模板，滚一遍脚本的事。

5.3 TC-BPDU抑制：别让一次插拔刷爆整网MAC表

前面说过，RSTP的TC机制已经很克制了，只有非边缘端口进转发才触发。但如果有人恶意伪造大量TC BPDU，或者某台设备反复震荡，仍然可能造成全网的MAC表被反复清空，表现就是所有业务瞬间泛洪、CPU飙高。

TC-BPDU抑制的作用是限流：单位时间内只处理指定数量的TC BPDU，超出的部分直接丢弃，并在老化周期内统一处理一次。

stp tc-protection stp tc-protection threshold 10

含义是每2秒（一个Hello周期）最多处理10个TC，超出的忽略。这个值怎么定？小型网络默认10足够；大型园区如果有频繁的接入端口变化（比如大量无线AP重启），可以适当放宽到20，但别设太大，太大就失去保护意义了。

另外还有一个容易被忽略的点：边缘端口的up/down不触发TC，所以只要边缘端口配全了，TC的数量天然就少。很多TC风暴的根因不是攻击，而是边缘端口没配，几百个接入口每天正常的插拔就够把网络刷成筛子。

6. 排障实录：六个场景和一张速查表

6.1 场景一：切了RSTP还是慢，问题出在半双工

某次割接，全网模式切到RSTP，验证时拔线仍然要3秒以上。查了三遍配置都没问题，最后用display stp interface GigabitEthernet0/0/1看，发现Point-to-point: no。追下去是一台老光电转换器，自协商成了半双工。换成强制全双工后，收敛恢复到百毫秒级。

这个案例的教训是：RSTP的快速收敛是条件成立的结果，不是配置一敲就有的。排“收敛慢”的问题，检查顺序应该是：先看双工和链路类型，再看边缘端口是否配全，最后才看优先级。

6.2 场景二：环路没断，但MAC表一直翻

现象是全网业务时断时续，display stp tc看拓扑变化计数每秒都在涨。抓包发现大量TC置位的BPDU。根因是某个接入端口被误配成了边缘端口，下面接了一台小交换机，导致这个口的状态反复变化。

边缘端口收到BPDU本来应该被BPDU保护掐掉，但检查发现BPDU保护只在核心上配了，接入层没配。补上之后问题消失。

这个案例说明一件事：边缘端口和BPDU保护必须成对出现。只配边缘端口不配保护，等于把大门敞开还不上锁。

6.3 场景三：根桥被抢，全网流量绕远路

某天早上网络突然变慢，检查发现根桥变成了一台接入交换机。原因是前一天晚上新接入的一台设备出厂优先级配成了0。核心上的根保护救了场——下行口进入root-inconsistent，业务没有形成环路，只是绕行。

事后复盘：根保护应该在做根桥规划的那天就一起配上，不要等出事。另外，新设备入网前的配置核查清单里，应该有一条“确认生成树优先级为默认值”。

6.4 场景四：单向链路导致的诡异环路

光纤断了一芯，物理状态还是up。根端口收不到BPDU，触发了切换，但替代端口那侧的数据还能单向过去，形成环路。表现是广播包缓慢增长，几小时后才把带宽吃满，非常难定位。

这个问题的正解就是环路保护。配了之后，根端口超时收不到BPDU直接进loop-inconsistent，不会盲目切换。事后我们把所有根端口和替代端口统一加了环路保护，再没出现过这类问题。

6.5 场景五：与老设备混跑，新设备“被迫变慢”

网络里有一台老交换机只支持STP。RSTP设备连接到它的端口收到version 0的BPDU，会自动按STP方式处理这个端口，也就是放弃握手、回到30秒的老流程。整棵树的收敛时间被这一个端口拖住。

处理方式有两种：一是把那台老设备换掉或升级；二是把它放到网络的边缘位置，减少对主路径的影响。如果实在要混跑，至少在规划时给它单独划一个区域，别让它出现在根桥附近。

6.6 常见问题速查表

6.7 几条踩出来的经验

第一，先配边缘端口，再谈收敛。很多项目一上来就研究优先级和开销，结果几百个接入口没配边缘端口，同步操作每次都把终端拉一下，用户体验比不配还差。

第二，根桥优先级别配0。留一档给未来，这个习惯我保持了七八年，救过至少两次割接。

第三，排障从物理层往上查。生成树的绝大多数“玄学问题”，根因都在双工、光纤单芯、光模块误码这些地方。BPDU抓包看到的是结果，物理层才是原因。

第四，变更前先导出当前的生成树状态。display stp brief的输出存一份，改完之后对比，能立刻看出哪个端口角色变了。这个动作花不了一分钟，但能省掉事后两小时的排查。

第五，别迷信“配了就一定生效”。RSTP的很多特性有前置条件：P/A握手需要点对点全双工，BPDU保护需要边缘端口，TC抑制需要设备支持。配完必须验证，验证必须看实际状态而不是配置文件。

最后分享一个我自己的习惯：每次接手一套新网络，第一件事不是看路由表，而是把生成树的根桥、端口角色、边缘端口配置拉一张表出来。这张表能反映这套网络的设计意图到底有没有落地——很多时候配置文件和实际运行状态是两回事。至于RSTP再往上走，可以看看它和MSTP的实例映射怎么配合，以及在三层路由已经铺开的网络里，二层生成树到底该保留多大规模，这个话题改天再展开聊。