1. 从一个真实故障场景说起：为什么路由和隧道会互相“打架”
先描述一个我在实际网络运维中遇到过多次的典型场景。某公司有两个数据中心，中间通过一条逻辑隧道（也就是大家常说的“为屁嗯”，本文统一用“隧道”代称）打通，隧道两端各自跑着OSPF，用来把两个站点的内网路由互相通告。平时一切正常，直到某天有人调整了一条静态路由，整个网络开始出现间歇性丢包，部分网段时通时不通，排查了大半天才发现是路由环路。
这个问题的根源，在于OSPF和隧道联动时，路由的“来源”和“出口”发生了重叠。简单说，OSPF从隧道里学到了对端站点的路由，然后又把这条路由通过隧道通告回去，或者把本该走隧道的流量指向了本地物理口，形成来回打转。这就是标题里说的“防环问题”。
这篇文章适合谁看？如果你正在做多站点互联、分支组网、或者任何涉及“路由协议跑在逻辑隧道之上”的架构，那这篇内容基本就是为你准备的。我会从原理讲起，把环路是怎么产生的、为什么常规的防环手段会失效、以及实际配置中怎么规避，一层层拆开讲清楚。全程用从业者的视角，不堆术语，尽量让你看完就能上手排查。
需要先说明一点：本文讨论的“隧道”泛指各类点对点或点对多点的逻辑链路技术，具体实现方式不影响防环逻辑本身。核心矛盾始终是——路由协议的通告范围和隧道的转发路径之间，边界没有划清楚。
2. 环路是怎么长出来的：OSPF与隧道联动的三层矛盾
2.1 第一层矛盾：路由来源与转发出口的重叠
OSPF的工作逻辑是“我学到了什么，就告诉邻居什么”。当OSPF进程同时运行在物理接口和隧道接口上时，它会从隧道接口学到对端的路由，然后默认又会把这些路由从其他接口（包括隧道接口本身）通告出去。
这里有个关键点：OSPF本身有水平分割机制，从某个接口学到的路由不会再从同一个接口通告回去。但问题在于，隧道接口和物理接口在OSPF看来是两个不同的接口。所以从隧道学到的路由，完全可以从物理接口通告出去，反之亦然。一旦两端配置不对称，环路就出现了。
打个比方：A站点通过隧道告诉B站点“我这里有192.168.1.0/24”，B站点学到后，又通过物理链路告诉了中间路由器C，C再把这条路由传回给A。A一看，自己明明直连的网段，怎么从外面又学回来一条？如果管理距离和度量值没配好，A就可能把这条“外来的”路由装进表里，导致流量绕圈。
2.2 第二层矛盾：管理距离与度量值的“信任错位”
OSPF默认管理距离是110，静态路由是1，直连是0。看起来直连和静态优先级更高，应该不会出问题？实际恰恰相反。
当隧道两端都跑OSPF时，如果某一端把隧道接口的OSPF开销（cost）配得很低，而对端物理接口的cost配得较高，那么从隧道学来的路由就会“击败”本地直连或静态路由，被优选进路由表。这时候流量就会走隧道，但隧道本身又依赖底层物理链路，如果底层链路的路由也是通过OSPF学来的，就形成了路由递归依赖——隧道需要路由才能建立，而路由又需要隧道才能学到。
这种递归依赖是环路最隐蔽的形态。表面上看路由表正常，ping也通，但一旦底层链路抖动，整个隧道和其承载的路由会同时失效，恢复时又互相等待，造成长时间中断。
2.3 第三层矛盾：多区域与虚链路的边界模糊
如果两个站点之间的OSPF跨越了多个区域，或者使用了虚链路（Virtual Link），问题会更复杂。虚链路本身是一种逻辑连接，它依赖OSPF骨干区域的路由可达性。当虚链路和隧道叠加时，相当于“逻辑链路跑在逻辑链路之上”，防环边界几乎消失。
我见过一个案例：某网络用虚链路打通了两个非骨干区域，同时这两个区域之间又有一条隧道直连。结果OSPF的SPF计算把虚链路和隧道都当成可达路径，但两者的开销计算方式不同，导致路由在两条路径之间反复切换，形成路由震荡。这种震荡不会产生传统意义上的“环路”，但会造成持续的丢包和延迟抖动，排查难度更大。
3. 常规防环手段为什么在隧道场景下会“失灵”
3.1 水平分割与毒性逆转的局限性
OSPF的水平分割（Split Horizon）规则是：从某个接口学到的路由，不会再从同一个接口通告回去。毒性逆转（Poison Reverse）则是把学到的路由标记为不可达（度量值设为无穷大）再通告回去。
这两个机制在物理接口上工作得很好，但在隧道场景下有个致命问题：隧道接口的“同一接口”判断是基于逻辑接口的，而不是基于底层物理路径的。也就是说，从隧道A学到的路由，从隧道B通告出去时，OSPF认为这是两个不同的接口，水平分割不生效。如果隧道A和隧道B的底层物理路径有重叠，环路就绕过了水平分割的检查。
3.2 区域边界与LSA类型的混淆
OSPF用LSA（链路状态通告）来描述网络拓扑。不同类型的LSA有不同的传播范围：Type 1和Type 2只在区域内传播，Type 3由ABR（区域边界路由器）生成并在区域间传播，Type 5由ASBR（自治系统边界路由器）生成并在整个OSPF域内传播。
当隧道连接的两个站点属于不同区域时，隧道接口上跑的OSPF会把对端的LSA类型“透传”过来。如果配置不当，Type 3 LSA可能被错误地当成Type 1处理，或者Type 5 LSA在隧道两端反复重生成，导致LSA年龄（Age）异常刷新，路由表频繁变动。
我实测过一个场景：隧道两端都配置了redistribute connected，结果直连网段的路由被反复重分布进OSPF，LSA序列号不断递增，最终触发OSPF的LSA刷新限制，路由直接失效。这种问题在纯物理网络中很少见，因为物理接口的直连路由不会跨设备重分布。
3.3 路由过滤与分发列表的“盲区”
很多人会用分发列表（Distribute List）或路由映射（Route Map）来过滤OSPF路由，试图阻止某些网段被通告。但在隧道场景下，过滤规则的作用点很关键。
如果你在隧道接口的入方向做过滤，只能阻止从隧道学来的路由进入本地路由表，但无法阻止这些路由被再次通告出去。如果你在出方向做过滤，又可能把本该通告的合法路由也挡掉。更麻烦的是，OSPF的过滤是基于LSA的，而不是基于路由条目的。你过滤了一条路由，但对应的LSA可能还在数据库里，其他路由器依然能通过SPF计算出这条路径。
4. 实战配置：如何划清OSPF与隧道的边界
4.1 接口层面的隔离：被动接口与接口类型选择
最直接有效的手段，是把不需要跑OSPF的接口设为被动接口（Passive Interface）。被动接口不发送也不接收OSPF报文，但会把接口网段作为直连路由通告出去。
在隧道场景下，我的建议是：隧道接口本身不跑OSPF，只跑静态路由或BGP。如果必须跑OSPF，那至少要把隧道接口的OSPF网络类型设为point-to-point，避免DR/BDR选举带来的额外LSA交互。
配置示例（以常见网络设备命令风格为例）：
interface Tunnel0 ip address 10.0.0.1 255.255.255.252 ip ospf network point-to-point ip ospf cost 100 ! router ospf 1 passive-interface GigabitEthernet0/1 network 10.0.0.0 0.0.0.3 area 0这里的关键是passive-interface把物理接口设为被动，只让隧道接口参与OSPF。但这样又带来一个新问题：物理接口的网段不会被通告，如果对端需要访问这个网段，就得用静态路由补上。
4.2 路由标记与过滤：用Tag区分路由来源
更精细的做法是用路由标记（Route Tag）来区分路由来源。比如，从隧道学来的路由打上Tag 100，从物理接口学来的打上Tag 200，然后在路由映射里根据Tag决定是否通告。
route-map FROM-TUNNEL permit 10 match tag 100 set tag 100 ! route-map TO-PHYSICAL deny 10 match tag 100 ! router ospf 1 redistribute static subnets route-map FROM-TUNNEL distribute-list route-map TO-PHYSICAL out GigabitEthernet0/1这套配置的逻辑是：从隧道方向来的路由（Tag 100）不允许从物理接口通告出去，从而切断环路路径。实测下来，这种基于Tag的过滤比基于网段的ACL更灵活，因为网段可能会变，但Tag是跟着路由来源走的。
4.3 度量值与管理距离的精细化调整
如果无法完全隔离，那就通过度量值和管理距离来“引导”路由选择。核心原则是：让隧道学来的路由度量值始终高于本地直连或静态路由，这样即使路由被学回来，也不会被优选。
具体操作：
- 隧道接口的OSPF cost设为最大值（65535），确保隧道路由不会被优先选择。
- 对于必须走隧道的网段，用静态路由指向隧道，并设置较低的管理距离。
- 在OSPF进程中，用
distance命令调整OSPF的管理距离，使其高于静态路由。
router ospf 1 distance 200 ! ip route 192.168.2.0 255.255.255.0 Tunnel0 1这样，192.168.2.0/24的流量会优先走静态路由（管理距离1），而不是OSPF学来的路由（管理距离200）。即使OSPF从隧道学回了这条路由，也不会被装进路由表。
5. 排查链路：当环路已经发生，怎么一步步定位
5.1 第一步：确认路由表的“异常条目”
环路发生时，路由表里通常会出现一些“不该存在”的条目。比如，本地直连的网段却从OSPF学来了一条路由，或者同一网段有两条来源不同的路由在交替出现。
用show ip route查看路由表，重点关注：
- 同一网段是否有多个下一跳。
- 直连网段是否被标记为O（OSPF学来）。
- 路由的Age字段是否异常（频繁刷新）。
如果发现某条路由的下一跳指向隧道接口，但该网段明明是本地直连的，那基本可以确定环路已经形成。
5.2 第二步：追踪LSA的传播路径
用show ip ospf database查看LSA数据库，重点关注Type 3和Type 5 LSA。如果同一个网段的LSA在隧道两端反复出现，且序列号不断递增，说明LSA在循环传播。
进一步用show ip ospf database external查看Type 5 LSA的Advertising Router字段。如果这条LSA的起源路由器是本地，但你又从隧道方向收到了它，那就是路由重分布导致的环路。
5.3 第三步：用Traceroute验证转发路径
Traceroute是验证环路最直观的工具。如果traceroute的结果显示数据包在两个或多个下一跳之间反复跳转，那就是典型的转发环路。
但要注意：OSPF的环路不一定表现为TTL递减的转发环路，更多时候是路由震荡——数据包一会儿走路径A，一会儿走路径B，造成丢包和延迟抖动。这种情况下，traceroute可能显示正常，但ping会出现间歇性超时。
这时候可以用debug ip routing观察路由表的变动频率。如果某条路由在短时间内反复添加和删除，那就是路由震荡。
5.4 第四步：检查隧道接口的OSPF邻居状态
用show ip ospf neighbor查看隧道接口的邻居状态。如果邻居状态在FULL和DOWN之间反复切换，说明隧道本身不稳定，可能是底层物理链路的路由也在震荡。
这时候需要先解决底层链路的路由稳定性，再处理OSPF和隧道的联动问题。否则就是“地基不稳，楼上怎么修都没用”。
6. 几个容易踩的坑和我的实操心得
6.1 坑一：隧道两端OSPF区域号不一致
这个坑很隐蔽。如果隧道两端配置的OSPF区域号不同，隧道接口上的OSPF邻居关系可能建立不起来，但两端又会通过其他物理路径建立邻居。结果就是：隧道虽然通了，但OSPF路由不走隧道，而是绕道物理路径，造成次优路由。
更麻烦的是，如果物理路径和隧道路径同时存在，OSPF会同时学到两条路径，但区域号不同导致LSA类型不同，SPF计算时可能选择错误的路径。
心得：隧道两端的OSPF区域号必须一致，且建议把隧道接口划入骨干区域（Area 0），避免区域间LSA转换带来的复杂性。
6.2 坑二：MTU不匹配导致OSPF邻居卡在EXSTART
OSPF在建立邻居时会协商MTU。如果隧道接口的MTU和物理接口不一致，邻居关系可能卡在EXSTART状态，无法进入FULL。
这个问题的表现是：隧道能ping通，但OSPF邻居就是起不来。用show ip ospf neighbor看到状态一直是EXSTART或EXCHANGE。
解决办法：在隧道接口上显式设置MTU，或者用ip ospf mtu-ignore忽略MTU检查。但后者只是权宜之计，根本方案还是统一MTU。
6.3 坑三：路由重分布时的“自环”
如果隧道两端都配置了redistribute connected或redistribute static，很容易形成自环。因为A站点把自己的直连路由重分布进OSPF，通过隧道传给B；B站点又把这些路由重分布回OSPF，通过隧道传回A。A一看，自己直连的网段怎么从OSPF学回来了？如果管理距离没配好，就会装进路由表。
心得：在隧道场景下，尽量避免双向重分布。如果必须重分布，一定要用Route Tag标记来源，并在重分布时过滤掉带特定Tag的路由。
6.4 坑四：隧道Keepalive与OSPF Hello的冲突
某些隧道技术有Keepalive机制，会定期发送探测包。如果Keepalive的间隔和OSPF Hello的间隔不匹配，可能导致隧道接口在OSPF看来“时好时坏”，邻居关系频繁重置。
建议：把隧道Keepalive间隔设为OSPF Hello间隔的2-3倍，避免两者互相干扰。比如OSPF Hello是10秒，Keepalive可以设30秒。
7. 一个可复用的防环配置模板
基于上面的分析，我整理了一个在实际项目中验证过的配置模板。这个模板的核心思路是：隧道接口只跑OSPF，物理接口设为被动，用Route Tag标记隧道路由，并在物理接口出方向过滤掉带Tag的路由。
! 隧道接口配置 interface Tunnel0 ip address 10.0.0.1 255.255.255.252 ip ospf network point-to-point ip ospf cost 1000 ip ospf mtu-ignore ! ! 物理接口设为被动 router ospf 1 passive-interface GigabitEthernet0/1 network 10.0.0.0 0.0.0.3 area 0 ! ! 路由标记与过滤 route-map TAG-TUNNEL permit 10 set tag 100 ! route-map BLOCK-TUNNEL deny 10 match tag 100 ! ! 在物理接口出方向应用过滤 distribute-list route-map BLOCK-TUNNEL out GigabitEthernet0/1这套配置的逻辑链条是：
- 隧道接口跑OSPF，物理接口被动，确保OSPF路由只从隧道方向学来。
- 从隧道学来的路由打上Tag 100。
- 物理接口出方向过滤掉Tag 100的路由，防止环路。
实测下来，这套配置在多点互联场景下也能工作，只需要把Tag和接口号对应调整即可。
8. 写在最后：防环的本质是“划边界”
折腾了这么多，我最大的体会是：OSPF和隧道联动的防环问题，本质上不是技术问题，而是边界划分问题。你得清楚地定义：哪些路由该走隧道，哪些不该走；哪些接口该跑OSPF，哪些不该跑；哪些LSA该传播，哪些该过滤。
边界划清楚了，环路自然就没了。边界模糊，再多的防环机制也只是打补丁。
最后分享一个小技巧：在正式部署前，先用一个简单的实验环境模拟隧道两端的OSPF交互，用debug ip ospf adj和show ip ospf database观察LSA的传播路径。如果发现LSA在隧道两端反复出现，那就说明边界没划好，赶紧调整配置，别等到生产环境出问题了再排查。
这个内容后续还可以这样扩展：如果隧道技术换成了其他类型的逻辑链路（比如VXLAN或GRE），防环逻辑是否需要调整？答案是核心逻辑不变，但LSA的传播路径和接口类型判断会有所不同，需要针对具体技术做适配。
