ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

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 引入 OSPFDeviceE 把 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 100DeviceE 将 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 路由的优先级是 255OSPF 引入的路由优先级明显更高DeviceE 优选从 OSPF 引入的这条然后通过 BGP 又通告回 DeviceB。第三阶段是最终翻车点。DeviceB 现在收到两条 BGP 路由一条来自 DeviceAMED 50一条来自 DeviceEMED 1。在 AS 路径相同的情况下BGP 会比较 MED 值MED 越小越优DeviceB 毫不犹豫地优选了来自 DeviceE 的那条。第四阶段DeviceB 把这条“新”的最优路由再次引入 OSPF传给 DeviceC、DeviceD、DeviceEDeviceE 再引入 BGP 通告回 DeviceB。到此稳定环路形成路由在 BGP 和 OSPF 两个协议域之间无限循环。这里有个容易被忽略的细节为什么路由没有在 DeviceB 上被 BGP 自身的 AS_PATH 防环机制拦下来因为所有设备都在同一个 AS 65500 内跑的是 IBGPAS_PATH 里根本没有 AS 号变化BGP 的 AS 防环在这个场景里完全失效。这个场景里真正能挡路的是路由优先级和 MED 值这两个参数而它们恰恰被错误配置放行了。2.3 数据准备Router ID、AS 号与接口对应关系复现这个场景前先把设备参数整理清楚。下面这张表来自专题中的数据准备章节按这个表格配置才能保证拓扑和路由行为完全一致。设备Router IDAS 号 / 进程号关键接口DeviceA1.1.1.1BGP 65500GE0/1/0、Loopback0DeviceB协议互引设备2.2.2.2BGP 65500、OSPF 100GE0/1/0、GE0/2/0、GE0/3/0、Loopback0DeviceC3.3.3.3OSPF 100GE0/1/0、GE0/2/0DeviceD4.4.4.4OSPF 100GE0/1/0、GE0/2/0DeviceE协议互引设备5.5.5.5OSPF 100、BGP 65500GE0/1/0、GE0/2/0、Loopback0接口对应关系上DeviceA 的 GE0/1/0 连 DeviceB 的 GE0/1/010.1.1.0/24 网段DeviceB 的 GE0/2/0 连 DeviceC 的 GE0/1/010.1.2.0/24DeviceC 的 GE0/2/0 连 DeviceD 的 GE0/1/010.1.3.0/24DeviceD 的 GE0/2/0 连 DeviceE 的 GE0/1/010.1.4.0/24DeviceB 的 GE0/3/0 直连 DeviceE 的 GE0/2/010.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.255DeviceE 收到来自 DeviceD 的 OSPF 外部路由 10.10.10.10/32 后因为要从 OSPF 引入 BGP这条路由被放进了 BGP 表。与此同时 DeviceE 也从 DeviceB 那里通过 IBGP 学到了同一条 10.10.10.10/32。两条路由一对比OSPF 引入的那条优先级 150 明显高于 IBGP 的 255DeviceE 理所当然优选了 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 110DeviceE 回灌的那条保持默认 100DeviceB 就会稳定优选 110 的那条不再被 MED 值带偏。这个方案适合什么场景当两侧路径都有存在的必要、你只是想让某个方向成为主用路径时local-preference 是最干净的做法。它不改变路由的发布范围不过滤任何前缀只是调整了本设备的优选顺序对业务的影响面最小。在华为设备上本地优先级默认值是 100通过入口方向路由策略修改后再传给 IBGP 邻居整个 AS 内的选路结果都会跟着变。4.2 关键配置入口策略与 local-preference 110DeviceB 上新增的核心配置是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-clientroute-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说明优选路径回到了 DeviceAlocalpref 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 enableip 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 邻居入方向互引设备的 BGP 引入处影响范围影响整个 AS 内该路由的优选只影响本设备引入行为适用场景需要保留冗余链路、做主备切换明确知道哪些前缀不该回灌维护成本需要理解 BGP 选路规则前缀列表需要随业务更新我的选择逻辑是如果两侧路径都想留着只分主备用 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 出口方向不一致说明还有一条隐藏路径在捣乱。从那以后我每次做协议互引都会强制走一遍这两条命令顺手再在模拟器上复现一次完整组网确认无环才收工。这套动作帮我挡掉了至少三次潜在的环路事故希望帮到你。本文还有配套的精品资源点击获取
返回列表