简介这份华为路由器三层路由防环专题资料聚焦BGP与OSPF协议互引场景面向负责企业网、运营商边缘网络设计与运维的初中级网络工程师以及备考华为认证的学习者用于排查和规避因双点双向引入产生的三层路由环路。文档围绕典型组网展开梳理DeviceA至DeviceF的角色分工逐步还原10.10.10.10/32路由在BGP与OSPF间反复传递、因MED值与优先级差异形成稳定环路的四个阶段并给出错误配置示例、route-policy过滤、MED调整及AS_PATH等防环思路同时说明适用产品与版本。资源包仅含1个PDF文件大小约211KB篇幅紧凑、便于随查随用。目前已有2127人学习适合作为BGP/OSPF互引防环的专题参考资料与排错索引。1. 一条 /32 主机路由在 BGP 与 OSPF 之间来回横跳问题出在哪割接窗口里最难处理的一类故障BGP 邻居全部 EstablishedOSPF 邻居全部 Full链路告警一条没有但某个业务网段的下一跳每隔几秒换一次抓包看流量在两个方向之间反复横跳。翻配置也没写错什么import-route就那么两行。华为路由器三层路由防环专题把这类问题单独拆出来讲其中 03 篇盯着 BGP 与 OSPF 协议互引这个具体场景。所谓互引指的是同一台设备上一边import-route bgp把 BGP 路由灌进 OSPF 进程另一边import-route ospf把 OSPF 路由重新灌回 BGP。两个方向同时打开路由就在协议之间被反复洗一遍MED、Local_Pref、OSPF 外部度量这些属性每次转换都会被重新赋值选路结果随之反转。刚接手历史遗留配置的网络工程师或者正在做双协议边界割接的人最容易踩在这里。2. BGP/OSPF 协议互引的组网模型与路由传递链路2.1 典型组网的设备角色与协议分工这类组网的骨架很清楚AS 65500 内 DeviceA、DeviceB、DeviceE、DeviceF 跑 BGPDeviceB、DeviceC、DeviceD、DeviceE 之间跑 OSPF 100 计算域内路由。DeviceB 和 DeviceE 是两台协议互引设备一台负责 BGP 到 OSPF 的方向另一台负责 OSPF 到 BGP 的方向中间夹着 DeviceC、DeviceD 组成的 OSPF 传递路径。IBGP 邻居一律用 Loopback0 作为connect-interface这就要求每台设备的 Loopback 地址必须被 IGP 通告出去否则 BGP 邻居会话建立不起来。DeviceB 上还额外配了peer 5.5.5.5 reflect-client把 DeviceE 当作反射客户端这条命令在后面看回显时会反复出现——DeviceB 一旦成为 RR它收到的 IBGP 路由会带上Cluster list这也成了判断路由绕了几圈的旁证。2.2 互引设备的引入方向与 RIB 优先级对照理解环路的前提是先搞清楚华为路由器本地路由表RIB里各类路由的默认优先级。同一个前缀同时被多个协议学到时优先级数值小的进主路由表这是第一层裁决跟 BGP 的选路规则没有任何关系路由来源默认优先级说明Direct0直连OSPF 内部10域内/域间Static60静态OSPF 外部ASE150import-route引入产生IBGP255同 AS 内 BGP 邻居学习DeviceE 上会同时存在两条 10.10.10.10/32一条从 OSPF 学到的外部路由150一条从 DeviceB 发来的 IBGP 路由255。150 小于 255所以 DeviceE 的主路由表里选的是 OSPF 那条。而 DeviceB 上两条候选路由都是 IBGP优先级同为 255进不了优先级裁决只能交给 BGP 自己的选路顺序去比——这就是后面 MED 决定胜负的根本原因。2.3 数据准备Router ID、AS/Process ID 与接口规划动手之前把地址和标识列清楚能省掉一半的排错时间。互引场景里 Router ID 冲突是隐蔽性最高的一种错误两台设备 Router ID 相同会导致 OSPF 邻居震荡同时 BGP 会话反复重建现象很像环路但完全不是一回事设备Router IDAS / Process关键接口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、Loopback0DeviceA 的基础配置里有个容易忽略的点它并不需要跑 OSPF 来承载业务但必须把 Loopback0 通告进 OSPF 或其它 IGP否则 DeviceB 无法通过 Loopback 建立 IBGP 会话# DeviceABGP 路由的来源设备同时负责让 Loopback0 可达 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 # bgp 65500 router-id 1.1.1.1 peer 2.2.2.2 as-number 65500 peer 2.2.2.2 connect-interface LoopBack0 # ospf 10 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 10.1.1.0 0.0.0.255connect-interface Loopback0决定了 BGP 报文的源地址是 1.1.1.1同时更新下一跳也锚定在这个地址上所以 1.1.1.1 必须从 DeviceA 到 DeviceB 全程可达network 1.1.1.1 0.0.0.0这行就是干这个的。DeviceA 侧同时跑 OSPF 10 和 BGP 65500 并不构成互引因为它没有在任意一侧执行import-route只通告自己的直连网段和 Loopback方向是单向的。3. 环路是怎么一步步稳住的MED 不对等触发四阶段回灌3.1 DeviceA 侧的 BGP 出口策略与 MED 注入还原环路要先给 DeviceA 注入一个有明显属性的路由。用静态路由模拟上游业务网段再用一条出口策略给发布的 BGP 路由统一打上 MED 50制造出一个人为不占优的度量值# DeviceA用静态路由模拟上游业务出口策略统一打 MED 50 route-policy cost permit node 10 apply cost 50 # bgp 65500 ipv4-family unicast undo synchronization import-route static peer 2.2.2.2 enable peer 2.2.2.2 route-policy cost export # ip route-static 10.10.10.10 255.255.255.255 NULL0import-route static只把静态路由引入 BGProute-policy cost export作用在出口方向对发往 2.2.2.2 的所有 BGP 更新统一附加apply cost 50即 MED 值 50。MED 只在相邻 AS 之间或者 IBGP 内部传递作用是在 AS_PATH 等属性完全相同时作为次级比较依据数值越小越优。这里刻意设成 50 而不是默认值是为了让后面从 OSPF 绕回来的路由有机会赢过它。3.2 DeviceB 双向引入的关键配置DeviceB 是环路的支点问题出在 OSPF 进程下那行没有加任何策略的引入命令# DeviceBOSPF 100 直接把 IBGP 路由引入且不加任何过滤 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-clientimport-route bgp permit-ibgp中的permit-ibgp是必需的默认情况下 OSPF 只引入 EBGP 路由不加这个关键字 IBGP 学到的路由根本进不了 OSPF 进程这也是很多人误以为没配错的原因。代价是 IBGP 路由一切属性在跨协议转换时全部丢弃MED 50 到 OSPF 里变成了外部开销默认值 1。DeviceE 侧同样裸奔import-route ospf 100后面没有任何 route-policyOSPF 学到的全部外部路由无条件回灌进 BGP。3.3 四阶段演化过程与 BGP 选路顺序阶段动作结果一DeviceA 发布 BGP 路由MED 50DeviceB 引入 OSPFOSPF 域内泛洪 10.10.10.10/32外部开销 1二DeviceE 同时有 OSPF 外部150与 IBGP255主路由表选 OSPFBGP 引入后回灌 DeviceB三DeviceB 收到 MED 1 与 MED 50 两条 IBGPMED 小者优选来自 DeviceE 的路由四DeviceB 选路变更触发 OSPF 重新引入DeviceC/D/E 刷新DeviceE 再回灌状态锁定第三阶段是分水岭。BGP 选路顺序大致是 Weight、Local_Pref、本地始发、AS_PATH、Origin、MED两条路由的 Local_Pref 都是默认 100AS_PATH 都为空同 AS 内 IBGPOrigin 都是 incomplete于是比到 MED来自 DeviceA 的是 50来自 DeviceE 的是 1后者取胜。之所以是 1是因为 OSPF 外部开销默认从 1 起算回灌 BGP 时直接变成了 MED。3.4 用 display 命令定位环路的三个观察点第一条观察命令是在互引设备上看 BGP 表的完整候选[~DeviceB] display bgp routing-table 10.10.10.10回显里会同时列出两条候选。来自 5.5.5.5 的那条带MED 1, localpref 100, valid, internal, best, select来自 1.1.1.1 的那条带MED 50并且明确标注not preferred for MED。这个not preferred for MED就是环路成立的直接证据——如果是正常的单向引入这个位置只会有一条路由或者两条路由的 From 指向不同方向且不会互相回灌。第二条命令在 DeviceE 上执行display bgp routing-table 10.10.10.10会看到一条Imported routeFrom: 0.0.0.0MED 1local标志说明这条路由不是从邻居学的是本机从 OSPF 引入产生的。第三条命令是display ip routing-table 10.10.10.10重点看 NextHop 和 Interface 两列隔几秒执行一次如果下一跳在两个物理口之间切换配合前面两条命令就能确定切换的原因是 BGP 优选变化引起的而不是链路震荡。4. 两种防环配置落地local-preference 提升与 ip-prefix 过滤4.1 方案一入口策略抬高本地优先级压住回灌路由思路是在 DeviceB 的 BGP 入口方向动手把来自 DeviceA 的路由 Local_Pref 抬到 110让它在选路顺序上直接越过 MED 比较这一关# DeviceB对来自 DeviceA 的路由入口抬高 Local_Pref route-policy localPre permit node 10 apply local-preference 110 # bgp 65500 ipv4-family unicast peer 1.1.1.1 route-policy localPre importapply local-preference 110只在 IBGP 内部传递不会跟着路由传出本 AS所以不会影响外部选路。之所以是 110 而不是 100是因为从 DeviceE 回灌的那条默认是 100抬到 110 就形成了明确的高低差。BGP 选路先比 Local_Pref 再比 MED只要 Local_Pref 分出胜负MED 是 1 还是 50 都不再参与判断。这条策略的隐患在于没有if-match等于把来自 1.1.1.1 的所有 BGP 路由全部抬高。如果 DeviceA 还发布了别的网段且希望按 MED 优选这个策略就会误伤。生产环境常见做法是补一条if-match ip-prefix限定前缀范围。配置后在 DeviceB 上复查回显中来自 1.1.1.1 的路由变成MED 50, localpref 110, best, select同时Advertised to such 1 peers: 5.5.5.5说明这条优选路由被正常通告出去。DeviceE 侧收到的路由也带着localpref 110它本机从 OSPF 引入的那条pref-val 0会显示not preferred for Local_Pref主路由表跟着回到 OSPF 外部路由链路恢复单向。4.2 方案二在引入点用 ip-prefix 过滤掉本域始发路由第二种思路更彻底不去比属性直接在回灌的源头把这条路由掐掉。DeviceE 的 BGP 引入方向上加一条前缀过滤# DeviceEBGP 引入 OSPF 时过滤掉由 BGP 域始发的前缀 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 ipv4-family unicast undo synchronization import-route ospf 100 route-policy no_need_sendroute-policy的匹配逻辑是自上而下deny node 10命中 10.10.10.10/32 后直接丢弃permit node 20是必须写的兜底节点没有它的话其余 OSPF 路由会一并被隐式拒绝等于把整条引入链路砍断。这类漏写 permit 的失误在现场很常见现象是环路没了但业务也没了。4.3 配置后的回显校验与差异对比对比维度local-preference 方案ip-prefix 过滤方案作用位置DeviceB 的 BGP 入口DeviceE 的 BGP 引入点控制粒度属性级需配合 if-match前缀级精确到 /32环路消除方式让回灌路由选不上让回灌路由不存在风险点无 if-match 时误伤同源路由漏写 permit 兜底节点适用场景前缀多、只想改优选顺序前缀明确、可枚举两种方案落地后DeviceB 的 BGP 表中 10.10.10.10/32 只剩一条候选Paths: 1 available, 1 best, 1 select不再出现not preferred for MED这类竞争痕迹。这是判断环路是否真正解除最直接的量化指标——候选数从 2 回到 1。5. 互引防环的通用检查清单与割接验证技巧5.1 引入动作必配策略的三条硬规则第一条任何import-route后面都必须挂 route-policy哪怕当前只想放行全部也要显式写permit node 10把默认放行变成显式放行后续加过滤时不会因为节点顺序踩坑。第二条引入点要有兜底 permit 节点deny节点永远只针对明确要拦的前缀。第三条跨协议引入时给路由打标记华为 OSPF 支持apply tag回到 BGP 时用if-match tag或者 community 判断来源比单纯匹配前缀更能应对网段扩张。# OSPF 引入 BGP 时打 tag回灌 BGP 时按 tag 过滤 ospf 100 import-route bgp permit-ibgp route-policy set_tag # route-policy set_tag permit node 10 apply tag 65500 # # DeviceE 侧按 tag 识别来源后再决定是否回灌 route-policy no_back permit node 10 if-match tag 65500 # route-policy no_back deny node 20这段模板的价值在于它不依赖具体前缀。业务网段新增或变更时只要 tag 机制不变过滤规则就不需要跟着改这是前缀列表方案做不到的。5.2 收敛后必须复查的四条回显检查项命令期望结果BGP 候选数display bgp routing-table prefix1 available, 1 best选路原因同上看 best 行的属性标注无not preferred for MED/Local_PrefOSPF 外部路由display ospf lsdb ase prefix引入设备数量符合预期主路由下一跳display ip routing-table prefix连续三次执行 NextHop 不变BGP 表的候选数是判断环路最灵敏的指标因为环路形成的物理条件是同一条前缀在互引设备上出现两条来源不同的 IBGP 候选。如果候选数长期维持在 1即使属性看起来不那么干净也不会形成稳定环路。5.3 多点互引场景下的一个实操技巧当 DeviceB 和 DeviceE 都配置了双向引入单靠一台设备上的 Local_Pref 调整往往会失效——另一台设备可能把它自己学到的路由以更高的 Local_Pref 发回来。处理办法是在所有互引设备上统一使用同一条 route-policy 命名和同一套 tag 规则把防环逻辑从设备本地策略提升为域级策略。割接前的最后一步动作值得固化下来在互引设备上执行display bgp routing-table并保存全量输出同时记录每台设备display ip routing-table中关键前缀的 NextHop。收工后按同样的命令再抓一遍用 diff 对比 From 字段和 Advertised to 列表是否发生变化。From 字段指向的邻居一旦和割接前不一致哪怕业务暂时正常也说明优选路径已经被改写环路的种子已经埋下了。本文还有配套的精品资源点击获取 BGP与OSPF协议互引防环：MED回灌环路定位与配置方案
简介这份华为路由器三层路由防环专题资料聚焦BGP与OSPF协议互引场景面向负责企业网、运营商边缘网络设计与运维的初中级网络工程师以及备考华为认证的学习者用于排查和规避因双点双向引入产生的三层路由环路。文档围绕典型组网展开梳理DeviceA至DeviceF的角色分工逐步还原10.10.10.10/32路由在BGP与OSPF间反复传递、因MED值与优先级差异形成稳定环路的四个阶段并给出错误配置示例、route-policy过滤、MED调整及AS_PATH等防环思路同时说明适用产品与版本。资源包仅含1个PDF文件大小约211KB篇幅紧凑、便于随查随用。目前已有2127人学习适合作为BGP/OSPF互引防环的专题参考资料与排错索引。1. 一条 /32 主机路由在 BGP 与 OSPF 之间来回横跳问题出在哪割接窗口里最难处理的一类故障BGP 邻居全部 EstablishedOSPF 邻居全部 Full链路告警一条没有但某个业务网段的下一跳每隔几秒换一次抓包看流量在两个方向之间反复横跳。翻配置也没写错什么import-route就那么两行。华为路由器三层路由防环专题把这类问题单独拆出来讲其中 03 篇盯着 BGP 与 OSPF 协议互引这个具体场景。所谓互引指的是同一台设备上一边import-route bgp把 BGP 路由灌进 OSPF 进程另一边import-route ospf把 OSPF 路由重新灌回 BGP。两个方向同时打开路由就在协议之间被反复洗一遍MED、Local_Pref、OSPF 外部度量这些属性每次转换都会被重新赋值选路结果随之反转。刚接手历史遗留配置的网络工程师或者正在做双协议边界割接的人最容易踩在这里。2. BGP/OSPF 协议互引的组网模型与路由传递链路2.1 典型组网的设备角色与协议分工这类组网的骨架很清楚AS 65500 内 DeviceA、DeviceB、DeviceE、DeviceF 跑 BGPDeviceB、DeviceC、DeviceD、DeviceE 之间跑 OSPF 100 计算域内路由。DeviceB 和 DeviceE 是两台协议互引设备一台负责 BGP 到 OSPF 的方向另一台负责 OSPF 到 BGP 的方向中间夹着 DeviceC、DeviceD 组成的 OSPF 传递路径。IBGP 邻居一律用 Loopback0 作为connect-interface这就要求每台设备的 Loopback 地址必须被 IGP 通告出去否则 BGP 邻居会话建立不起来。DeviceB 上还额外配了peer 5.5.5.5 reflect-client把 DeviceE 当作反射客户端这条命令在后面看回显时会反复出现——DeviceB 一旦成为 RR它收到的 IBGP 路由会带上Cluster list这也成了判断路由绕了几圈的旁证。2.2 互引设备的引入方向与 RIB 优先级对照理解环路的前提是先搞清楚华为路由器本地路由表RIB里各类路由的默认优先级。同一个前缀同时被多个协议学到时优先级数值小的进主路由表这是第一层裁决跟 BGP 的选路规则没有任何关系路由来源默认优先级说明Direct0直连OSPF 内部10域内/域间Static60静态OSPF 外部ASE150import-route引入产生IBGP255同 AS 内 BGP 邻居学习DeviceE 上会同时存在两条 10.10.10.10/32一条从 OSPF 学到的外部路由150一条从 DeviceB 发来的 IBGP 路由255。150 小于 255所以 DeviceE 的主路由表里选的是 OSPF 那条。而 DeviceB 上两条候选路由都是 IBGP优先级同为 255进不了优先级裁决只能交给 BGP 自己的选路顺序去比——这就是后面 MED 决定胜负的根本原因。2.3 数据准备Router ID、AS/Process ID 与接口规划动手之前把地址和标识列清楚能省掉一半的排错时间。互引场景里 Router ID 冲突是隐蔽性最高的一种错误两台设备 Router ID 相同会导致 OSPF 邻居震荡同时 BGP 会话反复重建现象很像环路但完全不是一回事设备Router IDAS / Process关键接口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、Loopback0DeviceA 的基础配置里有个容易忽略的点它并不需要跑 OSPF 来承载业务但必须把 Loopback0 通告进 OSPF 或其它 IGP否则 DeviceB 无法通过 Loopback 建立 IBGP 会话# DeviceABGP 路由的来源设备同时负责让 Loopback0 可达 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 # bgp 65500 router-id 1.1.1.1 peer 2.2.2.2 as-number 65500 peer 2.2.2.2 connect-interface LoopBack0 # ospf 10 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 10.1.1.0 0.0.0.255connect-interface Loopback0决定了 BGP 报文的源地址是 1.1.1.1同时更新下一跳也锚定在这个地址上所以 1.1.1.1 必须从 DeviceA 到 DeviceB 全程可达network 1.1.1.1 0.0.0.0这行就是干这个的。DeviceA 侧同时跑 OSPF 10 和 BGP 65500 并不构成互引因为它没有在任意一侧执行import-route只通告自己的直连网段和 Loopback方向是单向的。3. 环路是怎么一步步稳住的MED 不对等触发四阶段回灌3.1 DeviceA 侧的 BGP 出口策略与 MED 注入还原环路要先给 DeviceA 注入一个有明显属性的路由。用静态路由模拟上游业务网段再用一条出口策略给发布的 BGP 路由统一打上 MED 50制造出一个人为不占优的度量值# DeviceA用静态路由模拟上游业务出口策略统一打 MED 50 route-policy cost permit node 10 apply cost 50 # bgp 65500 ipv4-family unicast undo synchronization import-route static peer 2.2.2.2 enable peer 2.2.2.2 route-policy cost export # ip route-static 10.10.10.10 255.255.255.255 NULL0import-route static只把静态路由引入 BGProute-policy cost export作用在出口方向对发往 2.2.2.2 的所有 BGP 更新统一附加apply cost 50即 MED 值 50。MED 只在相邻 AS 之间或者 IBGP 内部传递作用是在 AS_PATH 等属性完全相同时作为次级比较依据数值越小越优。这里刻意设成 50 而不是默认值是为了让后面从 OSPF 绕回来的路由有机会赢过它。3.2 DeviceB 双向引入的关键配置DeviceB 是环路的支点问题出在 OSPF 进程下那行没有加任何策略的引入命令# DeviceBOSPF 100 直接把 IBGP 路由引入且不加任何过滤 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-clientimport-route bgp permit-ibgp中的permit-ibgp是必需的默认情况下 OSPF 只引入 EBGP 路由不加这个关键字 IBGP 学到的路由根本进不了 OSPF 进程这也是很多人误以为没配错的原因。代价是 IBGP 路由一切属性在跨协议转换时全部丢弃MED 50 到 OSPF 里变成了外部开销默认值 1。DeviceE 侧同样裸奔import-route ospf 100后面没有任何 route-policyOSPF 学到的全部外部路由无条件回灌进 BGP。3.3 四阶段演化过程与 BGP 选路顺序阶段动作结果一DeviceA 发布 BGP 路由MED 50DeviceB 引入 OSPFOSPF 域内泛洪 10.10.10.10/32外部开销 1二DeviceE 同时有 OSPF 外部150与 IBGP255主路由表选 OSPFBGP 引入后回灌 DeviceB三DeviceB 收到 MED 1 与 MED 50 两条 IBGPMED 小者优选来自 DeviceE 的路由四DeviceB 选路变更触发 OSPF 重新引入DeviceC/D/E 刷新DeviceE 再回灌状态锁定第三阶段是分水岭。BGP 选路顺序大致是 Weight、Local_Pref、本地始发、AS_PATH、Origin、MED两条路由的 Local_Pref 都是默认 100AS_PATH 都为空同 AS 内 IBGPOrigin 都是 incomplete于是比到 MED来自 DeviceA 的是 50来自 DeviceE 的是 1后者取胜。之所以是 1是因为 OSPF 外部开销默认从 1 起算回灌 BGP 时直接变成了 MED。3.4 用 display 命令定位环路的三个观察点第一条观察命令是在互引设备上看 BGP 表的完整候选[~DeviceB] display bgp routing-table 10.10.10.10回显里会同时列出两条候选。来自 5.5.5.5 的那条带MED 1, localpref 100, valid, internal, best, select来自 1.1.1.1 的那条带MED 50并且明确标注not preferred for MED。这个not preferred for MED就是环路成立的直接证据——如果是正常的单向引入这个位置只会有一条路由或者两条路由的 From 指向不同方向且不会互相回灌。第二条命令在 DeviceE 上执行display bgp routing-table 10.10.10.10会看到一条Imported routeFrom: 0.0.0.0MED 1local标志说明这条路由不是从邻居学的是本机从 OSPF 引入产生的。第三条命令是display ip routing-table 10.10.10.10重点看 NextHop 和 Interface 两列隔几秒执行一次如果下一跳在两个物理口之间切换配合前面两条命令就能确定切换的原因是 BGP 优选变化引起的而不是链路震荡。4. 两种防环配置落地local-preference 提升与 ip-prefix 过滤4.1 方案一入口策略抬高本地优先级压住回灌路由思路是在 DeviceB 的 BGP 入口方向动手把来自 DeviceA 的路由 Local_Pref 抬到 110让它在选路顺序上直接越过 MED 比较这一关# DeviceB对来自 DeviceA 的路由入口抬高 Local_Pref route-policy localPre permit node 10 apply local-preference 110 # bgp 65500 ipv4-family unicast peer 1.1.1.1 route-policy localPre importapply local-preference 110只在 IBGP 内部传递不会跟着路由传出本 AS所以不会影响外部选路。之所以是 110 而不是 100是因为从 DeviceE 回灌的那条默认是 100抬到 110 就形成了明确的高低差。BGP 选路先比 Local_Pref 再比 MED只要 Local_Pref 分出胜负MED 是 1 还是 50 都不再参与判断。这条策略的隐患在于没有if-match等于把来自 1.1.1.1 的所有 BGP 路由全部抬高。如果 DeviceA 还发布了别的网段且希望按 MED 优选这个策略就会误伤。生产环境常见做法是补一条if-match ip-prefix限定前缀范围。配置后在 DeviceB 上复查回显中来自 1.1.1.1 的路由变成MED 50, localpref 110, best, select同时Advertised to such 1 peers: 5.5.5.5说明这条优选路由被正常通告出去。DeviceE 侧收到的路由也带着localpref 110它本机从 OSPF 引入的那条pref-val 0会显示not preferred for Local_Pref主路由表跟着回到 OSPF 外部路由链路恢复单向。4.2 方案二在引入点用 ip-prefix 过滤掉本域始发路由第二种思路更彻底不去比属性直接在回灌的源头把这条路由掐掉。DeviceE 的 BGP 引入方向上加一条前缀过滤# DeviceEBGP 引入 OSPF 时过滤掉由 BGP 域始发的前缀 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 ipv4-family unicast undo synchronization import-route ospf 100 route-policy no_need_sendroute-policy的匹配逻辑是自上而下deny node 10命中 10.10.10.10/32 后直接丢弃permit node 20是必须写的兜底节点没有它的话其余 OSPF 路由会一并被隐式拒绝等于把整条引入链路砍断。这类漏写 permit 的失误在现场很常见现象是环路没了但业务也没了。4.3 配置后的回显校验与差异对比对比维度local-preference 方案ip-prefix 过滤方案作用位置DeviceB 的 BGP 入口DeviceE 的 BGP 引入点控制粒度属性级需配合 if-match前缀级精确到 /32环路消除方式让回灌路由选不上让回灌路由不存在风险点无 if-match 时误伤同源路由漏写 permit 兜底节点适用场景前缀多、只想改优选顺序前缀明确、可枚举两种方案落地后DeviceB 的 BGP 表中 10.10.10.10/32 只剩一条候选Paths: 1 available, 1 best, 1 select不再出现not preferred for MED这类竞争痕迹。这是判断环路是否真正解除最直接的量化指标——候选数从 2 回到 1。5. 互引防环的通用检查清单与割接验证技巧5.1 引入动作必配策略的三条硬规则第一条任何import-route后面都必须挂 route-policy哪怕当前只想放行全部也要显式写permit node 10把默认放行变成显式放行后续加过滤时不会因为节点顺序踩坑。第二条引入点要有兜底 permit 节点deny节点永远只针对明确要拦的前缀。第三条跨协议引入时给路由打标记华为 OSPF 支持apply tag回到 BGP 时用if-match tag或者 community 判断来源比单纯匹配前缀更能应对网段扩张。# OSPF 引入 BGP 时打 tag回灌 BGP 时按 tag 过滤 ospf 100 import-route bgp permit-ibgp route-policy set_tag # route-policy set_tag permit node 10 apply tag 65500 # # DeviceE 侧按 tag 识别来源后再决定是否回灌 route-policy no_back permit node 10 if-match tag 65500 # route-policy no_back deny node 20这段模板的价值在于它不依赖具体前缀。业务网段新增或变更时只要 tag 机制不变过滤规则就不需要跟着改这是前缀列表方案做不到的。5.2 收敛后必须复查的四条回显检查项命令期望结果BGP 候选数display bgp routing-table prefix1 available, 1 best选路原因同上看 best 行的属性标注无not preferred for MED/Local_PrefOSPF 外部路由display ospf lsdb ase prefix引入设备数量符合预期主路由下一跳display ip routing-table prefix连续三次执行 NextHop 不变BGP 表的候选数是判断环路最灵敏的指标因为环路形成的物理条件是同一条前缀在互引设备上出现两条来源不同的 IBGP 候选。如果候选数长期维持在 1即使属性看起来不那么干净也不会形成稳定环路。5.3 多点互引场景下的一个实操技巧当 DeviceB 和 DeviceE 都配置了双向引入单靠一台设备上的 Local_Pref 调整往往会失效——另一台设备可能把它自己学到的路由以更高的 Local_Pref 发回来。处理办法是在所有互引设备上统一使用同一条 route-policy 命名和同一套 tag 规则把防环逻辑从设备本地策略提升为域级策略。割接前的最后一步动作值得固化下来在互引设备上执行display bgp routing-table并保存全量输出同时记录每台设备display ip routing-table中关键前缀的 NextHop。收工后按同样的命令再抓一遍用 diff 对比 From 字段和 Advertised to 列表是否发生变化。From 字段指向的邻居一旦和割接前不一致哪怕业务暂时正常也说明优选路径已经被改写环路的种子已经埋下了。本文还有配套的精品资源点击获取