1. 从一个真实故障说起为什么路由协议和隧道会“打架”几年前我在一个中型园区网做割接核心层两台设备跑OSPF接入层通过一条隧道把两个异地机房拉成一个逻辑二层域。割接完成后业务侧反馈时通时断抓包发现核心设备上OSPF邻居反复震荡日志里全是“Received invalid packet: Wrong area ID”和“Dead interval mismatch”之类的报错。当时排查了整整一个通宵最后定位到的问题根源是隧道接口的MTU和OSPF的DD报文长度不匹配导致邻居关系卡在ExStart状态而隧道本身又承载了OSPF的Hello报文形成了一个“路由依赖隧道、隧道依赖路由”的死循环。这个案例让我意识到OSPF和隧道联动这件事表面上看只是“把两个协议叠在一起跑”实际上暗藏着大量环路风险。今天这篇文章我就把这类场景下防环的核心思路、实操配置和踩坑经验完整梳理一遍。无论你是刚接触动态路由的新手还是做过几年网络运维的老手只要你的网络里同时存在OSPF和隧道接口这篇文章里的内容大概率能帮你少走弯路。先明确一下本文讨论的范围所谓“OSPF-隧道联动”指的是OSPF进程的邻居关系或路由计算依赖于隧道接口如GRE、IPsec、VXLAN等逻辑接口同时隧道本身的建立又依赖于OSPF学习到的底层路由。这种相互依赖关系一旦处理不当就会产生路由环路、邻居震荡、流量黑洞三类典型问题。本文会围绕这三类问题从原理到配置到排查逐一拆解。2. 联动场景下的环路是怎么产生的2.1 先搞清楚“依赖倒置”这个核心矛盾正常情况下OSPF跑在物理接口上底层链路状态是确定的路由计算不依赖上层协议。但当你把OSPF跑在隧道接口上或者让隧道的目的地址通过OSPF学习时依赖关系就变成了双向的OSPF需要隧道接口Up才能建立邻居隧道接口需要OSPF学到目的地址的路由才能Up这就是典型的依赖倒置。如果两边同时启动或者一边先于另一边收敛就会出现“鸡生蛋、蛋生鸡”的问题。更危险的是当网络中存在多条路径时OSPF可能把隧道接口本身作为到达隧道目的地址的下一跳形成自指路由——数据包从隧道进去又从隧道出来循环往复。我用一个简化拓扑来说明。假设有两台设备R1和R2之间通过物理链路互联同时建立了一条GRE隧道。R1的隧道源地址是Loopback0通过OSPF发布隧道目的地址是R2的Loopback0。如果R1的OSPF进程同时把物理链路和隧道接口都加入Area 0那么R1去往R2 Loopback0的路由可能有两个下一跳物理链路直连或者隧道接口。如果OSPF选路时优先选了隧道接口作为下一跳而隧道接口的封装又需要先到达R2的Loopback0这就形成了环路。2.2 三类典型环路场景拆解根据我实际遇到过的案例联动场景下的环路可以归纳为三类第一类隧道接口参与OSPF导致的自指路由。这是最常见的一种。隧道接口的网段被发布进OSPF后远端设备学习到该网段的路由下一跳指向隧道而隧道本身又需要这条路由才能建立形成闭环。表现症状是隧道接口流量持续增长但业务不通traceroute显示数据包在隧道接口和物理接口之间来回跳。第二类双点双向重分发引起的次优路径和环路。当网络中存在两个路由域比如OSPF和BGP且在两台设备上同时做双向重分发时从OSPF域进入BGP域的路由可能又从另一台设备重分发回OSPF域形成路由环路。如果隧道接口恰好跨越这两个域问题会更复杂。第三类隧道冗余场景下的OSPF邻居震荡。当有多条隧道互为备份时如果OSPF的Hello和Dead定时器配置不当或者隧道接口的Cost值没有正确设置会导致OSPF邻居在两条隧道之间反复切换每次切换都触发SPF重计算进而影响隧道底层路由的收敛形成震荡循环。2.3 为什么常规的防环机制在这里会失效OSPF本身有一套防环机制区域内通过SPF算法保证无环区域间通过骨干区域强制规则防止环路外部路由通过Type 1/2的度量值避免环路。但这些机制的前提是路由计算的输入是稳定的。当隧道接口的状态依赖于OSPF路由时输入本身就在变化SPF算法再完美也无法保证无环。打个比方OSPF的防环机制就像交通规则前提是道路本身是固定的。但如果道路的走向会根据车流量动态变化那交通规则就失效了。隧道接口就是那条“会变化的道路”。3. 防环设计的核心原则与方案选型3.1 原则一打破依赖循环让隧道底层路由不依赖OSPF最根本的防环思路是切断依赖链。具体做法是隧道的目的地址不要通过OSPF学习而是通过静态路由或直连路由指定。这样隧道接口的Up/Down就不依赖OSPFOSPF的邻居建立也就不依赖隧道接口的路由收敛。在实际配置中我通常会在隧道源和目的设备上各写一条静态路由指向对端隧道目的地址。比如# R1上的配置 ip route 10.255.255.2 255.255.255.255 192.168.1.2 interface Tunnel0 ip address 172.16.0.1 255.255.255.252 tunnel source 10.255.255.1 tunnel destination 10.255.255.2这里10.255.255.2是R2的Loopback地址通过静态路由指向R2的物理接口地址192.168.1.2。这样即使OSPF进程重启隧道接口也不会DownOSPF邻居关系也就不会因为隧道接口状态变化而震荡。注意静态路由的优先级要高于OSPF学习到的路由否则OSPF可能仍然会把隧道接口作为下一跳。建议使用管理距离更小的静态路由或者用路由策略过滤掉隧道目的地址的OSPF路由。3.2 原则二隧道接口不参与OSPF或者只作为被动接口如果隧道接口只是用来承载业务流量不需要在隧道上跑OSPF邻居那么最安全的做法是把隧道接口配置为OSPF的被动接口passive interface。这样OSPF不会在隧道接口上发送Hello报文也就不会建立邻居关系自然避免了自指路由。router ospf 1 passive-interface Tunnel0但如果隧道接口确实需要跑OSPF比如两个异地机房需要通过隧道建立OSPF邻居那就必须配合其他防环措施。这种情况下我通常会把隧道接口单独划到一个非骨干区域并且在区域边界做路由汇总减少路由震荡的影响范围。3.3 原则三用路由策略精确控制重分发在双点双向重分发场景下防环的关键是给重分发路由打标记。具体做法是从OSPF重分发到BGP时给路由打上Community或Tag从BGP重分发回OSPF时匹配这个Tag并拒绝。这样就能防止路由在两个域之间来回反弹。# 从OSPF重分发到BGP时打Tag route-map OSPF-to-BGP permit 10 set tag 100 # 从BGP重分发到OSPF时拒绝带Tag的路由 route-map BGP-to-OSPF deny 10 match tag 100 route-map BGP-to-OSPF permit 20这个配置看起来简单但实际部署时有一个坑Tag值必须在整个路由域内唯一且一致。如果不同设备用了不同的Tag值或者Tag在传递过程中被清除防环就会失效。我建议在规划阶段就统一分配Tag号段并且在每台边界设备上验证Tag的传递情况。3.4 方案选型对比方案适用场景优点缺点静态路由指定隧道目的地址隧道目的地址固定的场景彻底切断依赖稳定性最高灵活性差目的地址变化需手动调整隧道接口设为被动接口隧道仅承载业务流量配置简单无环路风险隧道上无法建立OSPF邻居路由策略打Tag防环双点双向重分发场景灵活适应复杂拓扑配置复杂Tag规划需谨慎隧道接口单独划区路由汇总隧道需跑OSPF且拓扑较大减少震荡影响范围区域规划要求高4. 实操配置一个完整的防环部署案例4.1 拓扑说明与地址规划假设有一个典型场景某公司有两个机房A和机房B各自有一个OSPF域通过两条GRE隧道互联。机房A的核心设备R1和机房B的核心设备R2之间建立主隧道R1和R3之间建立备隧道。R3是机房B的另一台核心设备。要求主隧道故障时自动切换到备隧道且不能产生环路。地址规划如下R1 Loopback0: 10.0.0.1/32R2 Loopback0: 10.0.0.2/32R3 Loopback0: 10.0.0.3/32R1-R2物理链路: 192.168.12.0/30R1-R3物理链路: 192.168.13.0/30主隧道Tunnel0: 172.16.0.0/30备隧道Tunnel1: 172.16.1.0/304.2 第一步配置隧道底层路由在R1上为R2和R3的Loopback地址配置静态路由ip route 10.0.0.2 255.255.255.255 192.168.12.2 ip route 10.0.0.3 255.255.255.255 192.168.13.2在R2和R3上为R1的Loopback地址配置静态路由# R2 ip route 10.0.0.1 255.255.255.255 192.168.12.1 # R3 ip route 10.0.0.1 255.255.255.255 192.168.13.1这一步的关键是静态路由的下一跳必须是物理接口地址不能是隧道接口地址。否则又会形成依赖循环。4.3 第二步配置隧道接口并设置Cost值# R1上的主隧道 interface Tunnel0 ip address 172.16.0.1 255.255.255.252 tunnel source 10.0.0.1 tunnel destination 10.0.0.2 ip ospf cost 10 # R1上的备隧道 interface Tunnel1 ip address 172.16.1.1 255.255.255.252 tunnel source 10.0.0.1 tunnel destination 10.0.0.3 ip ospf cost 100这里把主隧道的OSPF Cost设为10备隧道设为100确保OSPF优先选择主隧道。Cost值的设置需要根据实际带宽和延迟来调整一般建议主备隧道的Cost值差距在10倍以上避免路由抖动时频繁切换。4.4 第三步配置OSPF并设置防环策略router ospf 1 router-id 10.0.0.1 network 10.0.0.1 0.0.0.0 area 0 network 172.16.0.0 0.0.0.3 area 0 network 172.16.1.0 0.0.0.3 area 0 passive-interface GigabitEthernet0/0 passive-interface GigabitEthernet0/1注意这里把物理接口设为被动接口只发布网段但不建立邻居。OSPF邻居只在隧道接口上建立。这样做的好处是物理链路只作为隧道的底层承载不参与OSPF邻居关系减少了震荡源。4.5 第四步验证与切换测试配置完成后用以下命令验证show ip ospf neighbor show ip route ospf show interface Tunnel0正常情况下R1应该通过Tunnel0和R2建立Full状态的邻居通过Tunnel1和R3建立Full状态的邻居。路由表中去往机房B的网段应该优先走Tunnel0。然后手动关闭Tunnel0观察OSPF是否在30秒内切换到Tunnel1interface Tunnel0 shutdown切换完成后检查路由表和邻居状态确认没有环路。最后再恢复Tunnel0观察是否自动切回主隧道。实操心得切换测试一定要在业务低峰期做并且提前准备好回滚脚本。我有一次在高峰期做切换测试结果备隧道的MTU没调对导致大包丢失业务侧直接炸了。后来学乖了所有隧道接口的MTU都统一设为1400并且在切换前先用ping -s 1400测试连通性。5. 常见问题排查与避坑指南5.1 邻居卡在ExStart/Exchange状态这是隧道上跑OSPF最常遇到的问题。根本原因通常是MTU不匹配。OSPF在ExStart状态会交换DD报文如果两端接口的MTU不一致DD报文长度不同邻居关系就会卡住。解决方法有两种一是统一两端隧道接口的MTU二是在OSPF进程下配置ip ospf mtu-ignore。我推荐第一种因为MTU不一致本身就会导致大包丢失即使OSPF邻居起来了业务流量也会出问题。interface Tunnel0 ip mtu 1400 ip tcp adjust-mss 1360ip tcp adjust-mss这个命令很关键它会让经过隧道的TCP连接协商一个较小的MSS值避免分片。1360的计算方式是1400MTU减去20IP头减去20TCP头 1360。5.2 路由表中出现自指路由症状是show ip route中看到某条路由的下一跳指向隧道接口但该路由的目的地址正是隧道目的地址。这种路由一旦被安装数据包就会在隧道里循环。排查方法是先确认隧道目的地址是否被OSPF发布。如果是用distribute-list或route-map过滤掉。然后在隧道源设备上写一条更精确的静态路由指向物理下一跳。ip route 10.0.0.2 255.255.255.255 192.168.12.2 1最后的1是管理距离比OSPF的110小确保静态路由优先。5.3 双点双向重分发导致的次优路径这个问题比较隐蔽表现是流量走了绕路但网络不中断。排查时可以用traceroute看路径如果发现数据包从一台边界设备进入另一个路由域后又从另一台边界设备绕回来那就是重分发环路。解决方法除了前面说的打Tag之外还可以用分发列表在边界设备上过滤掉特定路由。比如在R1上从BGP重分发到OSPF时拒绝掉那些下一跳指向R2的路由。5.4 常见问题速查表问题现象可能原因排查命令解决方法OSPF邻居卡在ExStartMTU不匹配show interface Tunnel0统一MTU或配置mtu-ignore路由表中出现自指路由隧道目的地址被OSPF发布show ip route 10.0.0.2静态路由指定下一跳或过滤OSPF路由隧道接口频繁Up/Down底层路由震荡show log检查底层物理链路和静态路由流量绕路但不中断双点双向重分发环路traceroute打Tag或分发列表过滤OSPF邻居反复切换Cost值配置不当show ip ospf interface调整Cost值差距启用BFD5.5 几个容易忽略的细节第一个细节隧道接口的Keepalive。有些厂商的隧道接口默认没有Keepalive机制隧道一端物理链路断了另一端可能还认为隧道是Up的。这会导致OSPF邻居关系不能及时断开流量被黑洞。建议在隧道接口上启用Keepalive或者配置BFD for OSPF。第二个细节OSPF的SPF定时器。在隧道震荡场景下默认的SPF定时器5秒可能导致路由收敛过慢。可以适当调小但不要小于1秒否则会加重CPU负担。router ospf 1 timers throttle spf 100 1000 5000第三个细节路由汇总的位置。如果隧道接口所在的区域有大量明细路由建议在ABR上做路由汇总。汇总不仅能减少路由表规模还能在隧道震荡时减少SPF计算的范围。第四个细节日志和告警。建议在隧道接口和OSPF进程上配置日志当邻居状态变化或路由震荡时能及时收到告警。我通常会用log-adjacency-changes detail来记录邻居状态变化。router ospf 1 log-adjacency-changes detail6. 进阶话题当OSPF遇到VXLAN和Segment Routing前面讨论的主要是GRE隧道场景。现在越来越多的网络开始用VXLAN做Overlay底层用OSPF或IS-IS做Underlay。这种场景下防环的思路又有所不同。VXLAN的VTEP地址通常通过Loopback接口发布到Underlay路由域。如果VTEP地址通过OSPF学习而VXLAN隧道又承载了OSPF的邻居关系比如在VXLAN上跑OSPF作为Overlay路由协议那就又回到了“依赖倒置”的问题。我的建议是Underlay和Overlay的路由协议要严格分离。Underlay用OSPF或IS-IS只负责VTEP地址的可达性Overlay用BGP EVPN负责租户路由的传递。这样Underlay的路由收敛不依赖OverlayOverlay的路由计算也不依赖Underlay的拓扑变化从根本上避免了环路。如果非要在VXLAN上跑OSPF那至少要做到VTEP地址用静态路由指定VXLAN接口不参与Underlay的OSPF进程Overlay的OSPF进程用独立的进程号并且配置严格的路由过滤策略。Segment Routing场景下OSPF用于分发Segment ID如果隧道接口也参与OSPF可能会导致Segment ID的冲突或环路。这种情况下建议把隧道接口排除在SRGBSegment Routing Global Block之外或者用独立的OSPF进程处理隧道接口的路由。这些进阶场景我还在持续实践中后续有新的经验再补充。网络技术变化很快但打破依赖循环这个核心原则是不变的。只要记住“隧道的底层路由不要依赖隧道上跑的路由协议”大部分环路问题都能避免。7. 写在最后几条用血泪换来的经验第一任何涉及隧道和动态路由的割接必须在实验室环境完整验证一遍。我见过太多人直接在现网配结果一个MTU问题搞到半夜。实验室环境不需要很复杂两台设备加一条隧道就能复现大部分问题。第二静态路由是防环的最后一道防线。不管你的动态路由协议配置得多完美关键节点的静态路由一定要写。特别是隧道目的地址、Loopback地址这些关键前缀静态路由能保证在动态路由震荡时网络仍然可达。第三监控和告警比配置更重要。配置是一次性的但网络状态是动态变化的。建议对隧道接口状态、OSPF邻居状态、路由表变化设置监控一旦异常立即告警。我用的是一个简单的脚本每5分钟采集一次show ip ospf neighbor和show interface Tunnel的输出发现状态变化就发邮件。第四文档和回滚方案。每次变更前把当前配置备份把回滚命令写好。我现在的习惯是变更前先show run保存一份变更后如果10分钟内业务没恢复立即回滚。这个习惯救过我很多次。网络这行经验都是踩坑踩出来的。希望这篇文章能帮你少踩几个坑。如果你在OSPF和隧道联动场景下遇到过其他奇葩问题欢迎一起交流。 
长河君 · 2026/10/15 19:56:01 · 阅读 1.2k OSPF与隧道联动防环实战：从环路原理到配置避坑指南
1. 从一个真实故障说起为什么路由协议和隧道会“打架”几年前我在一个中型园区网做割接核心层两台设备跑OSPF接入层通过一条隧道把两个异地机房拉成一个逻辑二层域。割接完成后业务侧反馈时通时断抓包发现核心设备上OSPF邻居反复震荡日志里全是“Received invalid packet: Wrong area ID”和“Dead interval mismatch”之类的报错。当时排查了整整一个通宵最后定位到的问题根源是隧道接口的MTU和OSPF的DD报文长度不匹配导致邻居关系卡在ExStart状态而隧道本身又承载了OSPF的Hello报文形成了一个“路由依赖隧道、隧道依赖路由”的死循环。这个案例让我意识到OSPF和隧道联动这件事表面上看只是“把两个协议叠在一起跑”实际上暗藏着大量环路风险。今天这篇文章我就把这类场景下防环的核心思路、实操配置和踩坑经验完整梳理一遍。无论你是刚接触动态路由的新手还是做过几年网络运维的老手只要你的网络里同时存在OSPF和隧道接口这篇文章里的内容大概率能帮你少走弯路。先明确一下本文讨论的范围所谓“OSPF-隧道联动”指的是OSPF进程的邻居关系或路由计算依赖于隧道接口如GRE、IPsec、VXLAN等逻辑接口同时隧道本身的建立又依赖于OSPF学习到的底层路由。这种相互依赖关系一旦处理不当就会产生路由环路、邻居震荡、流量黑洞三类典型问题。本文会围绕这三类问题从原理到配置到排查逐一拆解。2. 联动场景下的环路是怎么产生的2.1 先搞清楚“依赖倒置”这个核心矛盾正常情况下OSPF跑在物理接口上底层链路状态是确定的路由计算不依赖上层协议。但当你把OSPF跑在隧道接口上或者让隧道的目的地址通过OSPF学习时依赖关系就变成了双向的OSPF需要隧道接口Up才能建立邻居隧道接口需要OSPF学到目的地址的路由才能Up这就是典型的依赖倒置。如果两边同时启动或者一边先于另一边收敛就会出现“鸡生蛋、蛋生鸡”的问题。更危险的是当网络中存在多条路径时OSPF可能把隧道接口本身作为到达隧道目的地址的下一跳形成自指路由——数据包从隧道进去又从隧道出来循环往复。我用一个简化拓扑来说明。假设有两台设备R1和R2之间通过物理链路互联同时建立了一条GRE隧道。R1的隧道源地址是Loopback0通过OSPF发布隧道目的地址是R2的Loopback0。如果R1的OSPF进程同时把物理链路和隧道接口都加入Area 0那么R1去往R2 Loopback0的路由可能有两个下一跳物理链路直连或者隧道接口。如果OSPF选路时优先选了隧道接口作为下一跳而隧道接口的封装又需要先到达R2的Loopback0这就形成了环路。2.2 三类典型环路场景拆解根据我实际遇到过的案例联动场景下的环路可以归纳为三类第一类隧道接口参与OSPF导致的自指路由。这是最常见的一种。隧道接口的网段被发布进OSPF后远端设备学习到该网段的路由下一跳指向隧道而隧道本身又需要这条路由才能建立形成闭环。表现症状是隧道接口流量持续增长但业务不通traceroute显示数据包在隧道接口和物理接口之间来回跳。第二类双点双向重分发引起的次优路径和环路。当网络中存在两个路由域比如OSPF和BGP且在两台设备上同时做双向重分发时从OSPF域进入BGP域的路由可能又从另一台设备重分发回OSPF域形成路由环路。如果隧道接口恰好跨越这两个域问题会更复杂。第三类隧道冗余场景下的OSPF邻居震荡。当有多条隧道互为备份时如果OSPF的Hello和Dead定时器配置不当或者隧道接口的Cost值没有正确设置会导致OSPF邻居在两条隧道之间反复切换每次切换都触发SPF重计算进而影响隧道底层路由的收敛形成震荡循环。2.3 为什么常规的防环机制在这里会失效OSPF本身有一套防环机制区域内通过SPF算法保证无环区域间通过骨干区域强制规则防止环路外部路由通过Type 1/2的度量值避免环路。但这些机制的前提是路由计算的输入是稳定的。当隧道接口的状态依赖于OSPF路由时输入本身就在变化SPF算法再完美也无法保证无环。打个比方OSPF的防环机制就像交通规则前提是道路本身是固定的。但如果道路的走向会根据车流量动态变化那交通规则就失效了。隧道接口就是那条“会变化的道路”。3. 防环设计的核心原则与方案选型3.1 原则一打破依赖循环让隧道底层路由不依赖OSPF最根本的防环思路是切断依赖链。具体做法是隧道的目的地址不要通过OSPF学习而是通过静态路由或直连路由指定。这样隧道接口的Up/Down就不依赖OSPFOSPF的邻居建立也就不依赖隧道接口的路由收敛。在实际配置中我通常会在隧道源和目的设备上各写一条静态路由指向对端隧道目的地址。比如# R1上的配置 ip route 10.255.255.2 255.255.255.255 192.168.1.2 interface Tunnel0 ip address 172.16.0.1 255.255.255.252 tunnel source 10.255.255.1 tunnel destination 10.255.255.2这里10.255.255.2是R2的Loopback地址通过静态路由指向R2的物理接口地址192.168.1.2。这样即使OSPF进程重启隧道接口也不会DownOSPF邻居关系也就不会因为隧道接口状态变化而震荡。注意静态路由的优先级要高于OSPF学习到的路由否则OSPF可能仍然会把隧道接口作为下一跳。建议使用管理距离更小的静态路由或者用路由策略过滤掉隧道目的地址的OSPF路由。3.2 原则二隧道接口不参与OSPF或者只作为被动接口如果隧道接口只是用来承载业务流量不需要在隧道上跑OSPF邻居那么最安全的做法是把隧道接口配置为OSPF的被动接口passive interface。这样OSPF不会在隧道接口上发送Hello报文也就不会建立邻居关系自然避免了自指路由。router ospf 1 passive-interface Tunnel0但如果隧道接口确实需要跑OSPF比如两个异地机房需要通过隧道建立OSPF邻居那就必须配合其他防环措施。这种情况下我通常会把隧道接口单独划到一个非骨干区域并且在区域边界做路由汇总减少路由震荡的影响范围。3.3 原则三用路由策略精确控制重分发在双点双向重分发场景下防环的关键是给重分发路由打标记。具体做法是从OSPF重分发到BGP时给路由打上Community或Tag从BGP重分发回OSPF时匹配这个Tag并拒绝。这样就能防止路由在两个域之间来回反弹。# 从OSPF重分发到BGP时打Tag route-map OSPF-to-BGP permit 10 set tag 100 # 从BGP重分发到OSPF时拒绝带Tag的路由 route-map BGP-to-OSPF deny 10 match tag 100 route-map BGP-to-OSPF permit 20这个配置看起来简单但实际部署时有一个坑Tag值必须在整个路由域内唯一且一致。如果不同设备用了不同的Tag值或者Tag在传递过程中被清除防环就会失效。我建议在规划阶段就统一分配Tag号段并且在每台边界设备上验证Tag的传递情况。3.4 方案选型对比方案适用场景优点缺点静态路由指定隧道目的地址隧道目的地址固定的场景彻底切断依赖稳定性最高灵活性差目的地址变化需手动调整隧道接口设为被动接口隧道仅承载业务流量配置简单无环路风险隧道上无法建立OSPF邻居路由策略打Tag防环双点双向重分发场景灵活适应复杂拓扑配置复杂Tag规划需谨慎隧道接口单独划区路由汇总隧道需跑OSPF且拓扑较大减少震荡影响范围区域规划要求高4. 实操配置一个完整的防环部署案例4.1 拓扑说明与地址规划假设有一个典型场景某公司有两个机房A和机房B各自有一个OSPF域通过两条GRE隧道互联。机房A的核心设备R1和机房B的核心设备R2之间建立主隧道R1和R3之间建立备隧道。R3是机房B的另一台核心设备。要求主隧道故障时自动切换到备隧道且不能产生环路。地址规划如下R1 Loopback0: 10.0.0.1/32R2 Loopback0: 10.0.0.2/32R3 Loopback0: 10.0.0.3/32R1-R2物理链路: 192.168.12.0/30R1-R3物理链路: 192.168.13.0/30主隧道Tunnel0: 172.16.0.0/30备隧道Tunnel1: 172.16.1.0/304.2 第一步配置隧道底层路由在R1上为R2和R3的Loopback地址配置静态路由ip route 10.0.0.2 255.255.255.255 192.168.12.2 ip route 10.0.0.3 255.255.255.255 192.168.13.2在R2和R3上为R1的Loopback地址配置静态路由# R2 ip route 10.0.0.1 255.255.255.255 192.168.12.1 # R3 ip route 10.0.0.1 255.255.255.255 192.168.13.1这一步的关键是静态路由的下一跳必须是物理接口地址不能是隧道接口地址。否则又会形成依赖循环。4.3 第二步配置隧道接口并设置Cost值# R1上的主隧道 interface Tunnel0 ip address 172.16.0.1 255.255.255.252 tunnel source 10.0.0.1 tunnel destination 10.0.0.2 ip ospf cost 10 # R1上的备隧道 interface Tunnel1 ip address 172.16.1.1 255.255.255.252 tunnel source 10.0.0.1 tunnel destination 10.0.0.3 ip ospf cost 100这里把主隧道的OSPF Cost设为10备隧道设为100确保OSPF优先选择主隧道。Cost值的设置需要根据实际带宽和延迟来调整一般建议主备隧道的Cost值差距在10倍以上避免路由抖动时频繁切换。4.4 第三步配置OSPF并设置防环策略router ospf 1 router-id 10.0.0.1 network 10.0.0.1 0.0.0.0 area 0 network 172.16.0.0 0.0.0.3 area 0 network 172.16.1.0 0.0.0.3 area 0 passive-interface GigabitEthernet0/0 passive-interface GigabitEthernet0/1注意这里把物理接口设为被动接口只发布网段但不建立邻居。OSPF邻居只在隧道接口上建立。这样做的好处是物理链路只作为隧道的底层承载不参与OSPF邻居关系减少了震荡源。4.5 第四步验证与切换测试配置完成后用以下命令验证show ip ospf neighbor show ip route ospf show interface Tunnel0正常情况下R1应该通过Tunnel0和R2建立Full状态的邻居通过Tunnel1和R3建立Full状态的邻居。路由表中去往机房B的网段应该优先走Tunnel0。然后手动关闭Tunnel0观察OSPF是否在30秒内切换到Tunnel1interface Tunnel0 shutdown切换完成后检查路由表和邻居状态确认没有环路。最后再恢复Tunnel0观察是否自动切回主隧道。实操心得切换测试一定要在业务低峰期做并且提前准备好回滚脚本。我有一次在高峰期做切换测试结果备隧道的MTU没调对导致大包丢失业务侧直接炸了。后来学乖了所有隧道接口的MTU都统一设为1400并且在切换前先用ping -s 1400测试连通性。5. 常见问题排查与避坑指南5.1 邻居卡在ExStart/Exchange状态这是隧道上跑OSPF最常遇到的问题。根本原因通常是MTU不匹配。OSPF在ExStart状态会交换DD报文如果两端接口的MTU不一致DD报文长度不同邻居关系就会卡住。解决方法有两种一是统一两端隧道接口的MTU二是在OSPF进程下配置ip ospf mtu-ignore。我推荐第一种因为MTU不一致本身就会导致大包丢失即使OSPF邻居起来了业务流量也会出问题。interface Tunnel0 ip mtu 1400 ip tcp adjust-mss 1360ip tcp adjust-mss这个命令很关键它会让经过隧道的TCP连接协商一个较小的MSS值避免分片。1360的计算方式是1400MTU减去20IP头减去20TCP头 1360。5.2 路由表中出现自指路由症状是show ip route中看到某条路由的下一跳指向隧道接口但该路由的目的地址正是隧道目的地址。这种路由一旦被安装数据包就会在隧道里循环。排查方法是先确认隧道目的地址是否被OSPF发布。如果是用distribute-list或route-map过滤掉。然后在隧道源设备上写一条更精确的静态路由指向物理下一跳。ip route 10.0.0.2 255.255.255.255 192.168.12.2 1最后的1是管理距离比OSPF的110小确保静态路由优先。5.3 双点双向重分发导致的次优路径这个问题比较隐蔽表现是流量走了绕路但网络不中断。排查时可以用traceroute看路径如果发现数据包从一台边界设备进入另一个路由域后又从另一台边界设备绕回来那就是重分发环路。解决方法除了前面说的打Tag之外还可以用分发列表在边界设备上过滤掉特定路由。比如在R1上从BGP重分发到OSPF时拒绝掉那些下一跳指向R2的路由。5.4 常见问题速查表问题现象可能原因排查命令解决方法OSPF邻居卡在ExStartMTU不匹配show interface Tunnel0统一MTU或配置mtu-ignore路由表中出现自指路由隧道目的地址被OSPF发布show ip route 10.0.0.2静态路由指定下一跳或过滤OSPF路由隧道接口频繁Up/Down底层路由震荡show log检查底层物理链路和静态路由流量绕路但不中断双点双向重分发环路traceroute打Tag或分发列表过滤OSPF邻居反复切换Cost值配置不当show ip ospf interface调整Cost值差距启用BFD5.5 几个容易忽略的细节第一个细节隧道接口的Keepalive。有些厂商的隧道接口默认没有Keepalive机制隧道一端物理链路断了另一端可能还认为隧道是Up的。这会导致OSPF邻居关系不能及时断开流量被黑洞。建议在隧道接口上启用Keepalive或者配置BFD for OSPF。第二个细节OSPF的SPF定时器。在隧道震荡场景下默认的SPF定时器5秒可能导致路由收敛过慢。可以适当调小但不要小于1秒否则会加重CPU负担。router ospf 1 timers throttle spf 100 1000 5000第三个细节路由汇总的位置。如果隧道接口所在的区域有大量明细路由建议在ABR上做路由汇总。汇总不仅能减少路由表规模还能在隧道震荡时减少SPF计算的范围。第四个细节日志和告警。建议在隧道接口和OSPF进程上配置日志当邻居状态变化或路由震荡时能及时收到告警。我通常会用log-adjacency-changes detail来记录邻居状态变化。router ospf 1 log-adjacency-changes detail6. 进阶话题当OSPF遇到VXLAN和Segment Routing前面讨论的主要是GRE隧道场景。现在越来越多的网络开始用VXLAN做Overlay底层用OSPF或IS-IS做Underlay。这种场景下防环的思路又有所不同。VXLAN的VTEP地址通常通过Loopback接口发布到Underlay路由域。如果VTEP地址通过OSPF学习而VXLAN隧道又承载了OSPF的邻居关系比如在VXLAN上跑OSPF作为Overlay路由协议那就又回到了“依赖倒置”的问题。我的建议是Underlay和Overlay的路由协议要严格分离。Underlay用OSPF或IS-IS只负责VTEP地址的可达性Overlay用BGP EVPN负责租户路由的传递。这样Underlay的路由收敛不依赖OverlayOverlay的路由计算也不依赖Underlay的拓扑变化从根本上避免了环路。如果非要在VXLAN上跑OSPF那至少要做到VTEP地址用静态路由指定VXLAN接口不参与Underlay的OSPF进程Overlay的OSPF进程用独立的进程号并且配置严格的路由过滤策略。Segment Routing场景下OSPF用于分发Segment ID如果隧道接口也参与OSPF可能会导致Segment ID的冲突或环路。这种情况下建议把隧道接口排除在SRGBSegment Routing Global Block之外或者用独立的OSPF进程处理隧道接口的路由。这些进阶场景我还在持续实践中后续有新的经验再补充。网络技术变化很快但打破依赖循环这个核心原则是不变的。只要记住“隧道的底层路由不要依赖隧道上跑的路由协议”大部分环路问题都能避免。7. 写在最后几条用血泪换来的经验第一任何涉及隧道和动态路由的割接必须在实验室环境完整验证一遍。我见过太多人直接在现网配结果一个MTU问题搞到半夜。实验室环境不需要很复杂两台设备加一条隧道就能复现大部分问题。第二静态路由是防环的最后一道防线。不管你的动态路由协议配置得多完美关键节点的静态路由一定要写。特别是隧道目的地址、Loopback地址这些关键前缀静态路由能保证在动态路由震荡时网络仍然可达。第三监控和告警比配置更重要。配置是一次性的但网络状态是动态变化的。建议对隧道接口状态、OSPF邻居状态、路由表变化设置监控一旦异常立即告警。我用的是一个简单的脚本每5分钟采集一次show ip ospf neighbor和show interface Tunnel的输出发现状态变化就发邮件。第四文档和回滚方案。每次变更前把当前配置备份把回滚命令写好。我现在的习惯是变更前先show run保存一份变更后如果10分钟内业务没恢复立即回滚。这个习惯救过我很多次。网络这行经验都是踩坑踩出来的。希望这篇文章能帮你少踩几个坑。如果你在OSPF和隧道联动场景下遇到过其他奇葩问题欢迎一起交流。