BGP/OSPF互引路由环路成因与防环配置详解

简介：华为路由器三层路由防环专题第三部分聚焦BGP与OSPF协议互引场景下的路由环路问题，面向网络工程师、运维人员以及备考华为认证的读者，也可作为企业网与ISP边界组网设计的参考。资源以DeviceA发布的10.10.10.10/32路由为例，用四个阶段完整演示了稳定环路如何形成，并解释了MED值变化、OSPF与BGP路由优先级差异如何影响选路。文档进一步给出导致环路的错误配置示例与防止环路的建议配置示例，涵盖route-policy、MED值调整、AS_PATH及Loopback接口等防环机制，同时列出适用产品与版本、总结与建议，兼具原理深度和工程可操作性。资源为1个PDF文档，整体大小211KB，内容图文并茂，目录结构清晰，便于按需查阅。目前已有2129人在CSDN学习下载，适合需要深入理解三层防环机制的读者快速建立系统认知。

1. BGP/OSPF 互引：路由绕了一圈又回到自己手里

搞了几年网络，我见过太多在华为路由器上做 BGP 与 OSPF 互引翻车的案例。配置看着全对，协议邻居也都 Up，业务却莫名其妙丢包，最后抓包一查，路由 10.10.10.10/32 在 DeviceB 和 DeviceE 之间来回兜圈子，数据包绕了一圈又回到发起点。BGP/OSPF 互引本身不是问题，问题出在双向引入时没人管路由的“来路”和“去路”，环路就在两个协议边界上悄悄长出来。

这份三层路由防环专题拆的就是这个场景：DeviceB 把 BGP 引入 OSPF，DeviceE 把 OSPF 引入 BGP，中间没有路由策略把关，路由就在协议边界来回反射。文档把环路产生的四个阶段、错误配置、两条防环配置路线全讲透了，还带了完整的设备回显。适合做企业网出口、数据中心互联、ISP 域间互通的网络工程师，尤其是那些正准备在华为 AR 或 NE 系列路由器上做双协议互引的人，花半小时读一遍能少熬一个通宵。

2. 环路是怎么转起来的：MED 值、路由优先级与四阶段推演

2.1 为什么要在两个协议之间做互引

先说清楚动机。OSPF 域里跑的是内部路由，但网关上往往有条来自 BGP 的出口路由要下发给内网设备，这是BGP 引入 OSPF的典型诉求；反过来，BGP 侧要学习 OSPF 域内的用户网段，再通告给上层或对端 AS，这是OSPF 引入 BGP的场景。两个方向单独看都没问题，但放在同一台设备上做双向互引，中间又没有策略把关，路由就会从 BGP 进 OSPF、再从 OSPF 回 BGP，形成一个闭合的环。

在这个专题的组网里，DeviceB 和 DeviceE 就是两个“协议互引设备”。DeviceB 将 BGP 路由引入 OSPF 100，DeviceE 将 OSPF 路由引入 BGP 65500。注意这里 DeviceB 引入时用了permit-ibgp，说明它引入的是从 IBGP 邻居学来的路由，这正好是环路能闭环的关键之一——如果不允许引入 IBGP 路由，DeviceE 回灌的那条路由根本进不了 OSPF，环路的第二阶段就断了。

2.2 四阶段环路推演

以 DeviceA 发布的静态路由 10.10.10.10/32 为例。DeviceA 在 BGP 视图里通过import-route static把这条路由引入 BGP，并用出方向策略把 MED 设为 50，然后通告给 DeviceB。DeviceB 收到后通过 OSPF 100 引入 BGP 路由，传给 DeviceC、DeviceD，最后到达 DeviceE。这是第一阶段。

第二阶段的关键在 DeviceE。DeviceE 同时从两个方向收到 10.10.10.10/32：一条是 DeviceB 通过 IBGP 通告过来的 BGP 路由，另一条是 DeviceD 通过 OSPF 传来的外部路由。DeviceE 在 BGP 视图里配置了import-route ospf 100，会把 OSPF 路由引入 BGP。此时问题来了：OSPF 外部路由的优先级是 150，而 IBGP 路由的优先级是 255，OSPF 引入的路由优先级明显更高，DeviceE 优选从 OSPF 引入的这条，然后通过 BGP 又通告回 DeviceB。

第三阶段是最终翻车点。DeviceB 现在收到两条 BGP 路由，一条来自 DeviceA（MED 50），一条来自 DeviceE（MED 1）。在 AS 路径相同的情况下，BGP 会比较 MED 值，MED 越小越优，DeviceB 毫不犹豫地优选了来自 DeviceE 的那条。第四阶段，DeviceB 把这条“新”的最优路由再次引入 OSPF，传给 DeviceC、DeviceD、DeviceE，DeviceE 再引入 BGP 通告回 DeviceB。到此，稳定环路形成，路由在 BGP 和 OSPF 两个协议域之间无限循环。

这里有个容易被忽略的细节：为什么路由没有在 DeviceB 上被 BGP 自身的 AS_PATH 防环机制拦下来？因为所有设备都在同一个 AS 65500 内，跑的是 IBGP，AS_PATH 里根本没有 AS 号变化，BGP 的 AS 防环在这个场景里完全失效。这个场景里真正能挡路的，是路由优先级和 MED 值这两个参数，而它们恰恰被错误配置放行了。

2.3 数据准备：Router ID、AS 号与接口对应关系

复现这个场景前，先把设备参数整理清楚。下面这张表来自专题中的数据准备章节，按这个表格配置才能保证拓扑和路由行为完全一致。

接口对应关系上，DeviceA 的 GE0/1/0 连 DeviceB 的 GE0/1/0（10.1.1.0/24 网段），DeviceB 的 GE0/2/0 连 DeviceC 的 GE0/1/0（10.1.2.0/24），DeviceC 的 GE0/2/0 连 DeviceD 的 GE0/1/0（10.1.3.0/24），DeviceD 的 GE0/2/0 连 DeviceE 的 GE0/1/0（10.1.4.0/24），DeviceB 的 GE0/3/0 直连 DeviceE 的 GE0/2/0（10.1.5.0/24）。Router ID 必须全网唯一，否则 OSPF 邻居建立和 BGP 会话都会出乱子，这是排查环路前最先要确认的事。

3. 正确复现环路的错误配置：三台关键设备逐段拆解

3.1 DeviceA 的配置：静态路由进 BGP，出方向打 MED

复现环路的第一步，是让 DeviceA 把一条静态路由引入 BGP 并通告给 DeviceB。注意 DeviceA 用了一个出方向的 route-policy 给这条 BGP 路由设置 MED 为 50，目的是模拟“这条路由从外部学来、带有开销值”的真实场景。

# DeviceA 关键配置 interface GigabitEthernet0/1/0 undo shutdown ip address 10.1.1.1 255.255.255.0 # interface LoopBack0 ip address 1.1.1.1 255.255.255.255 # route-policy cost permit node 10 apply cost 50 # bgp 65500 router-id 1.1.1.1 peer 2.2.2.2 as-number 65500 peer 2.2.2.2 connect-interface LoopBack0 # ipv4-family unicast undo synchronization import-route static peer 2.2.2.2 enable peer 2.2.2.2 route-policy cost export # ospf 10 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 10.1.1.0 0.0.0.255 # ip route-static 10.10.10.10 255.255.255.255 NULL0

这里route-policy cost permit node 10里的apply cost 50，应用到 BGP 邻居的出方向后，会把通告给 DeviceB 的这条 BGP 路由 MED 改为 50。import-route static是引入静态路由的动作，ip route-static ... NULL0则是造一条指向空接口的静态路由，用于模拟外部用户网段。这个配置本身没有任何“错误”，它只是给后面的环路提供了一个“入口路由”，真正的隐患在 DeviceB 和 DeviceE 上。

3.2 DeviceB 的配置：BGP 引入 OSPF 时放行了 IBGP 路由

DeviceB 是第一个协议互引设备，它在 OSPF 100 进程里引入了 BGP 路由。这里的permit-ibgp是整条链路里最有争议的一个参数：它允许 OSPF 引入从 IBGP 学到的路由。如果去掉它，DeviceE 回灌的那条 IBGP 路由就不会被重新引入 OSPF，环路在第二阶段就断了。

# DeviceB 关键配置 interface GigabitEthernet0/1/0 undo shutdown ip address 10.1.1.2 255.255.255.0 # interface GigabitEthernet0/2/0 undo shutdown ip address 10.1.2.1 255.255.255.0 ospf enable 100 area 0.0.0.0 # interface GigabitEthernet0/3/0 undo shutdown ip address 10.1.5.2 255.255.255.0 # interface LoopBack0 ip address 2.2.2.2 255.255.255.255 # ospf 100 router-id 2.2.2.2 import-route bgp permit-ibgp area 0.0.0.0 # bgp 65500 router-id 2.2.2.2 peer 1.1.1.1 as-number 65500 peer 1.1.1.1 connect-interface LoopBack0 peer 5.5.5.5 as-number 65500 peer 5.5.5.5 connect-interface LoopBack0 # ipv4-family unicast undo synchronization peer 1.1.1.1 enable peer 5.5.5.5 enable peer 5.5.5.5 reflect-client

注意 DeviceB 给 DeviceE 配了reflect-client，它充当了 IBGP 路由反射器。这意味着 DeviceB 会把从 DeviceA 学到的 IBGP 路由反射给 DeviceE，同时也会把 DeviceE 回灌的 IBGP 路由反射给 DeviceA。路由反射器在这个场景里不仅没起到防环作用，反而成了环路传播的加速器。ospf 100里的import-route bgp permit-ibgp则是把 BGP 路由表全部灌进 OSPF，没有任何前缀限制，OSPF 域内的 DeviceC、DeviceD 会无条件学到这些外部路由。

3.3 DeviceE 的配置：OSPF 进 BGP 时选中了“错误”的那条路

DeviceE 是第二个协议互引设备，方向正好相反：OSPF 100 的路由被引入 BGP 65500。它的 BGP 配置里只有import-route ospf 100，没有加任何过滤条件，这就是环路闭环的最后一块拼图。

# DeviceE 关键配置 interface GigabitEthernet0/1/0 undo shutdown ip address 10.1.4.2 255.255.255.0 ospf enable 100 area 0.0.0.0 # interface GigabitEthernet0/2/0 undo shutdown ip address 10.1.5.1 255.255.255.0 # interface LoopBack0 ip address 5.5.5.5 255.255.255.255 # ospf 100 router-id 5.5.5.5 area 0.0.0.0 # bgp 65500 router-id 5.5.5.5 peer 2.2.2.2 as-number 65500 peer 2.2.2.2 connect-interface LoopBack0 # ipv4-family unicast undo synchronization import-route ospf 100 peer 2.2.2.2 enable # ospf 10 area 0.0.0.0 network 5.5.5.5 0.0.0.0 network 10.1.5.0 0.0.0.255

DeviceE 收到来自 DeviceD 的 OSPF 外部路由 10.10.10.10/32 后，因为要从 OSPF 引入 BGP，这条路由被放进了 BGP 表。与此同时 DeviceE 也从 DeviceB 那里通过 IBGP 学到了同一条 10.10.10.10/32。两条路由一对比，OSPF 引入的那条优先级 150 明显高于 IBGP 的 255，DeviceE 理所当然优选了 OSPF 引入的这条，并通过 BGP 通告给 DeviceB。这里不需要任何“错误”的 route-policy，仅仅是默认的路由优先级就足以让 DeviceE 选错路——这就是这个场景最阴险的地方：每个设备的配置都在规范内，组合起来却形成了环路。

3.4 从回显里读出“已经选错路”的信号

配置全部下发后，在 DeviceB 上执行display bgp routing-table 10.10.10.10，会看到两条 BGP 路由条目。下面这段回显是环路形成后的真实状态：

[~DeviceB] display bgp routing-table 10.10.10.10 BGP local router ID : 2.2.2.2 Local AS number : 65500 Paths: 2 available, 1 best, 1 select, 0 best-external, 0 add-path BGP routing table entry information of 10.10.10.10/32: From: 5.5.5.5 (5.5.5.5) Route Duration: 0d00h01m04s Relay IP Nexthop: 10.1.5.1 Relay IP Out-Interface: GigabitEthernet0/3/0 Original nexthop: 5.5.5.5 AS-path Nil, origin incomplete, MED 1, localpref 100, pref-val 0, valid, internal, best, select, pre 255, IGP cost 1 Advertised to such 1 peers: 1.1.1.1

回显里最关键的两行是From: 5.5.5.5和MED 1 ... best。From 5.5.5.5 表示这条路由是从 DeviceE 学来的，MED 1 说明它就是 DeviceE 从 OSPF 引入后回灌的那条。best标记则意味着 DeviceB 当前的最优路径指向 DeviceE，而不是原始发布者 DeviceA。再看下面的第二条条目，From: 1.1.1.1 ... MED 50 ... not preferred for MED，非常直白地告诉你，MED 50 被 MED 1 比下去了，这条原始路由被晾在一边。

这个回显就是环路的“犯罪现场”。正常情况下，DeviceB 应该优选来自 DeviceA 的那条，下一跳指向 GE0/1/0 方向；现在它优选了指向 GE0/3/0 的路径，数据包发到 DeviceE 后，DeviceE 又通过 OSPF 学回来的路径把包再送回 DeviceB，往返之间永远找不到出口。

4. 方法一：local-preference 改写路由优先级，把优选方向掰回来

4.1 防环思路与选型理由

搞清楚环路成因后，第一个防环思路是在 DeviceB 上动手脚：让它无论如何都优先选来自 DeviceA 的那条 BGP 路由，而不是来自 DeviceE 的回灌路由。BGP 选路规则里，本地优先级（local preference）是排在 MED 前面的属性，只在 IBGP 对等体之间传递，不会跨 AS 传播。给来自 DeviceA 的路由设置 local-preference 110，DeviceE 回灌的那条保持默认 100，DeviceB 就会稳定优选 110 的那条，不再被 MED 值带偏。

这个方案适合什么场景？当两侧路径都有存在的必要、你只是想让某个方向成为主用路径时，local-preference 是最干净的做法。它不改变路由的发布范围，不过滤任何前缀，只是调整了本设备的优选顺序，对业务的影响面最小。在华为设备上，本地优先级默认值是 100，通过入口方向路由策略修改后再传给 IBGP 邻居，整个 AS 内的选路结果都会跟着变。

4.2 关键配置：入口策略与 local-preference 110

DeviceB 上新增的核心配置是route-policy localPre，并且把它应用到 peer 1.1.1.1 的 import 方向。注意方向一定不能搞反——如果错误地应用到 export 方向，策略根本不会生效。

# DeviceB 防环关键配置（在原有配置基础上新增） route-policy localPre permit node 10 apply local-preference 110 # bgp 65500 router-id 2.2.2.2 peer 1.1.1.1 as-number 65500 peer 1.1.1.1 connect-interface LoopBack0 peer 5.5.5.5 as-number 65500 peer 5.5.5.5 connect-interface LoopBack0 # ipv4-family unicast undo synchronization peer 1.1.1.1 enable peer 1.1.1.1 route-policy localPre import peer 5.5.5.5 enable peer 5.5.5.5 reflect-client

route-policy localPre permit node 10没有写任何 if-match 条件，意味着它匹配所有从 DeviceA 进入的 BGP 路由，apply local-preference 110统一打上 110 的优先级。这里有个细节：如果只想针对特定前缀提升优先级，可以在 node 10 里加if-match ip-prefix精确匹配，其他路由放行到 node 20 不处理。但在这个场景里，对 DeviceA 来的所有路由统一提优先级是安全的，因为 DeviceA 就是这个 AS 内的路由源，它发布的路由本来就该优先被信任。

4.3 验证：看 localpref 和 best 标记是否同时落在 DeviceA 方向

配置完成后，回到 DeviceB 上执行同样的查询命令，回显会发生明显变化：

[~DeviceB] display bgp routing-table 10.10.10.10 BGP local router ID : 2.2.2.2 Local AS number : 65500 Paths: 1 available, 1 best, 1 select BGP routing table entry information of 10.10.10.10/32: From: 1.1.1.1 (1.1.1.1) Route Duration: 0d00h02m03s Relay IP Nexthop: 10.1.1.1 Relay IP Out-Interface: GigabitEthernet0/1/0 Original nexthop: 1.1.1.1 AS-path Nil, origin incomplete, MED 50, localpref 110, pref-val 0, valid, internal, best, select, pre 255, IGP cost 1 Advertised to such 1 peers: 5.5.5.5

对比前面的回显，两个关键变化：From变成了 1.1.1.1，说明优选路径回到了 DeviceA；localpref 110明确显示本地优先级策略生效。best标记现在落在正确的那条路由上，DeviceB 只会向 DeviceE 通告这一条。DeviceE 收到这条路由后再对比自己从 OSPF 引入的那条，因为来自 DeviceB 的这条 now 带有 Originator 1.1.1.1 和 Cluster list 2.2.2.2，它作为路由反射客户端的下游设备，也不会再把同一条路由以更低优先级回灌。

这套配置的完整验证还要在 DeviceE 上执行display bgp routing-table 10.10.10.10，正常情况下应该看到From: 2.2.2.2 ... localpref 110 ... best的条目，同时本地 OSPF 引入的那条标记为not preferred for Local_Pref。两条路由同时存在没问题，关键是 best 只会有一个，而且它指向正确的来源方向。

5. 避坑手册：BGP/OSPF 互引场景的常见问题与排查

5.1 路由策略方向配反，环路纹丝不动

现象：在 DeviceB 上配了apply local-preference 110，路由表里却看不到任何变化，环路依旧。

原因：route-policy 应用方向错了。local-preference 只对 IBGP 对等体的入方向生效，如果错误地配置在peer 1.1.1.1 route-policy localPre export上，策略只会影响 DeviceB 发给 DeviceA 的路由，DeviceB 自己收到的路由压根没经过这个策略。

解决：把策略改到 import 方向后重新验证。我一般会先执行display route-policy localPre确认策略里的动作是apply local-preference而不是apply cost，再执行display bgp routing-table 10.10.10.10看回显里的 localpref 值有没有变成 110。方向错了设备不会报任何错误，只能靠回显排查。

5.2 改了 MED 值但 BGP 根本不比较 MED，白忙一场

现象：按专题里的错误示例，想把 DeviceA 的 MED 调大或调小来改变优选结果，但 DeviceB 的选路结果纹丝不动。

原因：BGP 比较 MED 值是有前提条件的——多条路由的 AS 路径必须相同，且通常只在从 EBGP 邻居收到的路由之间比较。在这个场景里，DeviceB 收到的两条路由都来自 IBGP 邻居，虽然 AS 路径相同，但 MED 比较的优先级排在 local-preference、AS 路径之后。如果 local-preference 已经不同，MED 根本轮不到参与比较。

解决：先执行display bgp routing-table看详细属性，确认真正让路由分出优劣的是哪个属性。如果是 local-preference 不同，就调整 local-preference；如果是 AS 路径长度不同，就用apply as-path或过滤前缀；只有在所有前置属性都相同时，调 MED 才有意义。这条经验让我少走了很多弯路，现在每次调 MED 前都会先问自己一句：BGP 真的会走到比较 MED 这一步吗？

5.3 permit-ibgp 放行了不该放行的路由，OSPF 域内路由表暴涨

现象：在 OSPF 进程里配了import-route bgp permit-ibgp后，OSPF 域内的设备突然多出大量 O_ASE 路由，有些甚至是内网根本不需要的 BGP 全表路由。

原因：permit-ibgp允许 OSPF 引入从 IBGP 学到的路由。如果 BGP 表里既有从 EBGP 学到的外部路由，又有 IBGP 反射过来的内部路由，不加区分地全量引入，OSPF 域会被无关路由淹没，LSA 泛洪范围变大，设备 CPU 和内存压力直线上升。

解决：import-route bgp permit-ibgp后面跟上route-policy，用前缀列表或 tag 做精确过滤，只放行需要下发给 OSPF 域的那几条聚合路由。比如ip ip-prefix to-ospf permit 10.10.10.10 32，再配合 route-policy 里if-match ip-prefix to-ospf放行，其他全部 deny。这个教训来自一次现网事故，当时 OSPF 域内三百多台设备的路由表全部被撑爆，从那以后我引入路由必带过滤，绝不做无脑全量引入。

5.4 模拟器上验证通过，真机却出现环路

现象：在 eNSP 上搭了同样的拓扑，按专题配置验证 local-preference 防环方案，一切正常；在真机上配了同样的配置，环路却复现了。

原因：模拟器对 BGP 路由反射器、路由策略的某些实现细节与真机存在差异，尤其是老版本 eNSP 对reflect-client的行为模拟不完整，可能没有正确传递 Cluster List，导致环路在模拟器里被“掩盖”了。

解决：模拟器只用来验证配置语法和大致思路，最终必须以真实设备或最新版 VRP 模拟器的回显为准。真机上重点看display bgp routing-table里每条路由的Cluster list和Originator字段，确认反射器行为符合预期。我现在的习惯是，涉及路由反射器和互引的配置，先在模拟器跑通流程，再在实验室真机上完整验证一遍，最后才敢上现网。

5.5 清 BGP 会话验证环路，结果引发全网路由震荡

现象：为了验证环路的消除效果，执行了reset bgp 65500重置 BGP 会话，结果整网路由全部重新收敛，业务出现短暂中断。

原因：reset bgp会强制拆除并重建 BGP 邻居关系，期间所有通过 BGP 学到的路由全部失效并重新通告，在路由条目多的场景下会造成大范围路由震荡，对正在传输的业务是致命打击。

解决：验证路由策略效果时，用refresh bgp all export或refresh bgp all import做软刷新，只重新通告或重新接收路由，不拆邻居。华为设备上执行软刷新后，观察display bgp routing-table的变化即可确认策略是否生效，完全不需要重置会话。这个习惯让我再没因为验证配置而搞出过网络事件。

6. 方法二：地址前缀列表掐断回灌源头，一次配好不再复发

6.1 在 DeviceE 上做单向过滤

local-preference 方案的思路是“改变优选”，前缀列表方案的思路更直接：让不该回灌的路由在源头就进不了 BGP。环路是 DeviceE 把 OSPF 路由引入 BGP 后回灌给 DeviceB 造成的，那就在 DeviceE 的 BGP 引入处加一道过滤，把 10.10.10.10/32 这条路由挡在 BGP 门外。DeviceE 的配置修改集中在 BGP 视图的引入语句上：

# DeviceE 防环关键配置（在原有配置基础上新增） ip ip-prefix no_need_send index 10 permit 10.10.10.10 32 # route-policy no_need_send deny node 10 if-match ip-prefix no_need_send # route-policy no_need_send permit node 20 # bgp 65500 router-id 5.5.5.5 peer 2.2.2.2 as-number 65500 peer 2.2.2.2 connect-interface LoopBack0 # ipv4-family unicast undo synchronization import-route ospf 100 route-policy no_need_send peer 2.2.2.2 enable

ip ip-prefix no_need_send index 10 permit 10.10.10.10 32定义了一个精确匹配 10.10.10.10/32 的前缀列表，注意掩码写的是 32，只匹配这一条主机路由，不会误伤其他网段。route-policy no_need_send deny node 10用if-match ip-prefix no_need_send匹配这条前缀并拒绝它，node 20 用空的permit放行其余所有路由。最后在import-route ospf 100后面挂上这个策略，DeviceE 从 OSPF 引入 BGP 时，10.10.10.10/32 就被挡掉了，环路从源头被切断。

配置完成后在 DeviceE 上执行display bgp routing-table 10.10.10.10，回显里只剩从 DeviceB 学来的那条 BGP 路由，Imported route那条完全消失。DeviceB 侧自然也就收不到来自 DeviceE 的回灌路由了。

6.2 两种防环方案怎么选

两个方案没有绝对的好坏，取决于你的网络诉求。我把它们放在一起对比：

我的选择逻辑是：如果两侧路径都想留着，只分主备，用 local-preference；如果某些内网网段明确不应该被通告到 BGP 侧，用前缀列表在源头过滤。实际项目里经常两个方案配合使用——DeviceB 上用 local-preference 保证主路径方向正确，DeviceE 上用前缀列表挡住明确不该回灌的网段，双保险。

6.3 验证习惯：两条命令查遍互引设备

最后分享一个我养成的验证习惯。每次部署完 BGP/OSPF 互引配置，我会在每台协议互引设备上执行两条命令做交叉验证：

# 在互引设备上执行，检查 BGP 表优选项和 FIB 转发路径 display bgp routing-table 10.10.10.10 display ip routing-table 10.10.10.10

看 BGP 表的 best 条目下一跳方向，再看 IP 路由表里 FIB 的出接口方向，两个方向必须一致，而且必须指向路由源，而不是指向回灌方向。如果 BGP 优选和 FIB 出口方向不一致，说明还有一条隐藏路径在捣乱。从那以后我每次做协议互引，都会强制走一遍这两条命令，顺手再在模拟器上复现一次完整组网，确认无环才收工。这套动作帮我挡掉了至少三次潜在的环路事故，希望帮到你。

本文还有配套的精品资源，点击获取