前两天一位做网络集成的朋友给我发消息说他在实验环境里做了一个OSPF与IS-IS双点双向路由引入的验证结果发现OSPF域里所有路由器的外部LSA数量几乎翻了一倍。更诡异的是明明只有两台ASBR可路由表里同一个前缀却出现了两条外部路由一条来自源边的R1另一条居然来自另一台ASBR R2——问我是哪里配错了。这个现象就是双点双向路由引入里最经典也最容易踩的坑路由回馈。只要拓扑里出现两个边界点做双向引入回馈链路几乎是必然形成的。这篇文章我把成因、复现、解决方案和落地经验一次讲透。无论你是刚学路由引入、正在准备网络割接还是已经在现网里遇到类似诡异现象这篇文章都能帮你省下不少排查时间。1. 先看懂回馈链路双点双向引入里最不该出现的转发1.1 回馈是怎么一步步形成的先明确一个概念路由回馈全称应该叫路由被重新引入回源协议域。它和我们常说的路由环路有关联但又不完全一样。环路是数据包转发层面的死循环而回馈是路由信息层面的回流污染——回馈严重到一定程度才会演变成真正的环路和路由震荡。我用OSPF和IS-IS双点双向引入来拆解。假设R1、R2同时运行两种协议且都配置了双向引入也就是R1把OSPF路由引入IS-IS也把IS-IS路由引入OSPFR2同样把OSPF路由引入IS-IS也把IS-IS路由引入OSPF现在OSPF域内有一条前缀1.1.1.1/32由R1在OSPF里发布。这条路由在R1上被import-route ospf引入到了IS-IS域通过IS-IS的LSP传播R2学到了它。到这里一切正常。问题出在第二步。R2上面配置了把IS-IS路由引入OSPF所以R2在IS-IS域里学到的这条1.1.1.1/32会被当作一条普通的IS-IS外部路由再次注入OSPF域。于是OSPF域里出现了两条1.1.1.1/32的外部LSA一条是R1最初发布的另一条的通告者变成了R2。这就是回馈的本质路由在引出源协议域的那一刻原始协议的身份信息已经被格式化了。IS-IS不会关心这条路由的娘家在OSPF它只知道自己学到了一条外部路由OSPF再次接收时看到的只是一个由R2新引入的外部路由完全不知道它原本就来自自己域内。1.2 为什么双点和双向缺一不可我把这个坑拆开讲是因为很多初学者会问我只在一台路由器上做双向引入为什么没有出现回馈单点双向引入确实不会形成回馈。因为只有一台ASBR时路由引出去再引回来本质上还是同一台设备在处理它至少能从接口、邻居、路由表状态上判断出这条路由是自己刚引出去的不会傻到再引回来一遍形成循环。回馈需要两个点参与一台引出去另一台引回来这样才能在协议域之间搭起一条完整的闭环。双向则是另一个必要条件。如果只有R1做OSPF到IS-IS的引入、R2做IS-IS到OSPF的引入那么R1引出的OSPF路由会经过IS-IS域到达R2再由R2引回OSPF。这同样构成回馈。也就是说严格来说并不需要每一台ASBR都做双向引入只需要存在A引出去、B引回来的交叉路径。只不过实际工程里为了两个方向的互通性大家几乎都是两台设备同时做双向引入所以双点双向就成了这个问题最典型的发生场景。1.3 回馈带来的三种典型危害回馈不是多了一条路由那么简单它的危害体现在三个层面。第一外部路由表膨胀。OSPF域里每个路由器都会多出一批外部路由表项原本只有几条外部路由翻倍甚至翻几倍。设备内存和路由表容量被白白浪费。第二次优路径。回馈路由进入OSPF后会参与选路。如果原始那条1.1.1.1/32是OSPF域内路由优先级是10回馈路由是外部路由优先级是150正常情况下大家还是会走原始路径回馈路由只是躺在那不生效。但如果原始路由本身就是外部引入的Type 5路由优先级同样是150那两台ASBR就要比metric了。一旦回馈路径的metric算出来比原始路径更小全网的流量就会莫名其妙被引到对端ASBR去绕一个大圈。第三LSA反复刷新导致全网震荡。这是最隐蔽也最麻烦的。回馈路由在OSPF域里传播后R1会再次学到那条被R2引回的相同前缀路由。R1的IS-IS域里此时可能还残留着这条路由的旧LSP信息或者因为路由表变化、cost变化而触发重新引入。两个ASBR之间你来我往OSPF的Type 5 LSA和IS-IS的LSP不断被刷新每一次刷新都会触发SPF重算。轻则CPU飙高重则全网路由震荡表现就是业务间歇性丢包。打个比方你在微信群里发了一条消息朋友把这条消息截图转发到另一个群另一个群的人又把截图转发回你的原群你还以为这是别人发的新内容于是又转发了一次。消息在几个群之间反复转发刷屏最后每个人手机里都多了好几份相同内容——这就是路由回馈在协议世界里的即视感。2. 最小化复现eNSP里的双ASBR场景搭建与现象确认理论讲完了一定要动手复现一次。我建议用eNSP或者GNS3都行重点是亲眼看到回馈路由是怎么出现的后面配Route Tag方案时才不会被现象绕晕。2.1 拓扑与IP规划整个拓扑不需要复杂三台设备足够R1与R2通过GE0/0/0互联这条链路上同时运行OSPF Area 0和IS-IS Level-2R1的Loopback0地址是1.1.1.1/32R2的Loopback0地址是2.2.2.2/32两个Loopback都宣告进OSPF代表OSPF域内的业务网段R3是OSPF域内的一台普通路由器接在R1的GE0/0/1上R3上有一个Loopback0地址3.3.3.3/32用来观察域内其他路由器视角设备接口规划如下设备接口IP地址所属协议R1GE0/0/010.0.12.1/24OSPF Area 0 IS-ISR1GE0/0/110.0.13.1/24OSPF Area 0R1Loopback01.1.1.1/32OSPF Area 0R2GE0/0/010.0.12.2/24OSPF Area 0 IS-ISR2Loopback02.2.2.2/32OSPF Area 0R3GE0/0/010.0.13.3/24OSPF Area 0R3Loopback03.3.3.3/32OSPF Area 0这里说句题外话一条物理链路上同时跑两种IGP实验环境里没问题现网里几乎没人这么干。生产环境一般会分开链路或者用子接口但复现回馈问题这样最省设备。2.2 核心配置双向引入是关键R1和R2的OSPF、IS-IS基础配置就不完整贴了重点看引入部分。R1的关键配置ospf 1 router-id 1.1.1.1 import-route isis 1 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 10.0.12.1 0.0.0.0 network 10.0.13.1 0.0.0.0 # isis 1 is-level level-2 network-entity 49.0001.0000.0000.0001.00 import-route ospf 1 # interface GigabitEthernet0/0/0 isis enable 1 ip address 10.0.12.1 255.255.255.255R2的配置和R1对称只是router-id和network-entity不同同时把is-is的网络实体改为49.0001.0000.0000.0002.00引入方向也保持一致ospf 1 router-id 2.2.2.2 import-route isis 1 area 0.0.0.0 network 2.2.2.2 0.0.0.0 network 10.0.12.2 0.0.0.0 # isis 1 is-level level-2 network-entity 49.0001.0000.0000.0002.00 import-route ospf 1 # interface GigabitEthernet0/0/0 isis enable 1R3就只跑OSPF什么都不引入。注意实验时先别急着把引入命令敲上去。先把OSPF、IS-IS邻居都建立好查看路由表确认没有引入前一切正常然后再添加import-route命令这样出现的现象才是回馈导致的而不是你基础配置错了。2.3 两个命令看清回馈现象配置完成并等OSPF收敛之后在R3上查看1.1.1.1/32的路由R3display ip routing-table 1.1.1.1 32 Route Destination: 1.1.1.1/32 Known via ospf-1, distance: 10, metric: 1, type: intra area Last update : 00:01:23 ago NextHop : 10.0.13.1 Interface: GigabitEthernet0/0/0 Route Destination: 1.1.1.1/32 Known via ospf-1, distance: 150, metric: 1, type: extern Last update : 00:00:05 ago NextHop : 10.0.12.2 Interface: GigabitEthernet0/0/0看到了吗同一台路由器上同一个前缀出现了一条OSPF域内路由distance 10下一跳是R1和一条OSPF外部路由distance 150下一跳是R2。这条distance 150的外部路由就是回馈路由。用OSPF LSDB命令看得更清楚R3display ospf lsdb ase Type : External LS ID : 1.1.1.1 AdvRouter : 1.1.1.1 LS age : 20 Metric : 1 Tag : 0 Type : External LS ID : 1.1.1.1 AdvRouter : 2.2.2.2 LS age : 200 Metric : 1 Tag : 0同一个LS ID通告路由器一个写着1.1.1.1一个写着2.2.2.2。这就是回馈路由最直观的指纹前缀没变通告者却换了一台设备。在这个实验里因为原始路由是OSPF域内路由distance 10优先级高于外部路由distance 150所以实际转发不会出问题。但R3的LSDB和路由表已经被污染了。如果原始路由也是外部路由或者IS-IS域里引入了更大的OSPF域回馈路由就会开始干扰正常选路出现次优路径甚至环路。3. Route Tag标记法给引出去的路由贴出生证再接回来解决回馈业界最标准的做法是Route Tag也就是路由标记。思路一句话引出去的路由打上一个约定好的标签引回来的时候凡是带这个标签的一律拒绝。3.1 标记法的核心流程还是用刚才的实验拓扑我定义回馈标签值为100两台设备上的处理逻辑完全对称R1在把OSPF路由引入IS-IS时给所有引入路由打上Tag 100R2从IS-IS学到这些路由时路由上带着Tag 100R2在把IS-IS路由引入OSPF时凡是匹配Tag 100的路由直接拒绝引入R2自己把OSPF引入IS-IS时同样给路由打上Tag 100R1在把IS-IS路由引入OSPF时同样拒绝Tag 100的路由这样整个闭环就被切断了R1引出去的路由带Tag 100到R2那里想引回OSPF时被拦截R2引出去的路由带Tag 100到R1那里想引回OSPF时也被拦截。而OSPF域内那些没有Tag 100的原始路由仍然可以正常被引入IS-IS两个协议域的互通不受影响。这个方案的关键在于对称。如果R1检查Tag 100R2引入回OSPF时却没打Tag、或者打了别的值那R1的过滤就永远匹配不到东西回馈照旧。3.2 华为VRP上的具体配置R1上的配置如下# 打标签的策略所有放行的路由统一打Tag 100 route-policy TAG_100 permit node 10 apply tag 100 # 拒绝回馈的策略Tag 100的路由直接拒绝其余放行 route-policy DENY_TAG_100 deny node 10 if-match tag 100 route-policy DENY_TAG_100 permit node 20 # IS-IS引入OSPF时打Tag 100 isis 1 import-route ospf 1 route-policy TAG_100 # OSPF引入IS-IS时拒绝Tag 100 ospf 1 import-route isis 1 route-policy DENY_TAG_100R2上的配置和R1完全一样。对你没看错两台ASBR用的是同一套route-policy这也是运维上推荐的做法所有边界设备的Tag规则保持一致降低理解和维护成本。配置完成后记得敲一条reset ospf process重置OSPF进程或者等LSA老化让OSPF域重新收敛。再回到R3上看路由表和LSDBR3display ospf lsdb ase Type : External LS ID : 1.1.1.1 AdvRouter : 1.1.1.1 LS age : 15 Metric : 1 Tag : 0现在只剩一条由R1发布的1.1.1.1/32了R2发布的那条回馈LSA已经消失。R3的路由表里也只剩OSPF域内那条distance 10的路由一切恢复正常。3.3 一个隐蔽的坑Tag会不会在跨协议时丢失Route Tag方案的理论很干净但我在真实设备上踩过一个坑必须提醒你不同协议对Tag的传递行为有细微差异不能默认它一定带得过去。OSPF的外部LSA里Tag是External Route Tag字段32位标准支持。IS-IS的LSP里也有路由Tag TLV。但问题在于从OSPF引入IS-IS时Tag会不会从OSPF路由原封不动带进IS-IS从IS-IS引入OSPF时IS-IS的Tag又会不会自动填进OSPF外部LSA的Tag字段不同厂商、不同软件版本的行为不完全一样。华为设备上实测OSPF和IS-IS之间的Tag传递基本是可靠保留的但有些老版本或者跨厂商设备对接时Tag可能在你没注意到的环节被重置为0。一旦Tag丢了回馈路由就变成了无标签路由你的DENY策略匹配不到回馈直接漏进来。稳妥的做法是**在每一个引入方向上都显式处理Tag不要指望上一步打好的Tag能自动带过来。**比如引入IS-IS到OSPF时除了拒绝Tag 100还可以给所有从IS-IS进入OSPF的路由重新打一个内部管理Tag比如Tag 200方便后续运维排查这条路由到底从哪进来的。# 更稳的写法拒绝Tag 100的同时给其他路由打上内部管理标签 route-policy DENY_TAG_100 deny node 10 if-match tag 100 route-policy DENY_TAG_100 permit node 20 apply tag 200 ospf 1 import-route isis 1 route-policy DENY_TAG_100这样即使个别路由的Tag传递有异常你也可以通过查看最终路由表里的Tag值快速判断是哪一段丢的。4. 如果不想用Tag前缀过滤与AD优先级调整的适用边界Route Tag是标准解法但有些场景下你未必能用它。比如设备版本太老不支持跨协议Tag传递或者你只是临时止血还没有时间规划Tag方案。这时候有两类替代手段前缀过滤和AD优先级调整。4.1 前缀过滤治标快但维护成本高思路很简单直接在引入方向上把那些回馈过来的特定前缀拒掉。# 定义前缀过滤拒绝1.1.1.1/32放行其余 ip ip-prefix FILTER_RETURN index 10 deny 1.1.1.1 32 ip ip-prefix FILTER_RETURN index 20 permit 0.0.0.0 0 less-equal 32 # OSPF引入IS-IS时调用 ospf 1 import-route isis 1 route-policy FILTER_RETURN这个方案直观配置量小前缀少的时候非常高效。但它的维护成本和Tag方案完全是两回事每新增一个OSPF域内网段你都要同步修改所有ASBR上的过滤列表。漏掉一个回馈就在那个网段上重新出现。而且它只是从方向上阻断回馈路由进入OSPF如果IS-IS域里本身有一条合法的同前缀路由比如用户网络规划上刻意让两边有重叠前缀这种过滤会连同合法路由一起拒掉。所以我的结论是前缀过滤只适合解决明确知道回馈前缀且路由表规模小的临时场景不适合作为长期运维手段。4.2 AD优先级调整止血可以根除不行AD优先级调整的思路是让回馈路由即使进入了OSPF域优先级也低于原始路由永远选不上它。在华为设备上可以这样调# 把OSPF外部路由优先级从150调大到200 ospf 1 preference ase 200这样回馈路由在OSPF域内选路时会被原始域内路由或者原始的Type 5路由压住不会成为最优路径。如果原始路由的优先级也是150回馈路由进来后两者平级会去比较metric把回馈路由所在的协议整体调低至少能保证回馈路由不会翻盘。但你要明白AD调整解决的是选路结果解决不了表项污染。LSDB里依然会有回馈产生的Type 5 LSASPF依然要重算路由表里依然躺着一条多余的外部路由。该震荡还是震荡该占内存还是占内存。所以它只适合变更割接期间的临时止血不能作为最终方案。4.3 组合拳割接场景下的最小干预流程现实里我处理过的一个割接场景是这样的交接班时发现现网已经出现了明显的回馈现象OSPF域内LSA刷屏但这时再从头规划Tag方案已经来不及了。我当时的操作顺序是先在两台ASBR上同时用前缀过滤把已经识别的回馈前缀拒掉先让LSDB稳定下来同时把OSPF ASE优先级调大到200防止个别漏网的回馈路由影响转发路径观察15分钟确认LSA不再增长、路由表稳定等第二天变更窗口再把Tag方案完整落上去撤掉临时的前缀过滤这个临时方案保稳定、正式方案换根因的思路在现网里比一上来就推倒重来要实用得多。5. 方案落地的取舍与几个容易翻车的细节最后把三种方案放一起做个对比再讲讲实际操作中我踩过的坑。5.1 方案对比方案阻断效果运维成本适用场景风险点Route Tag彻底阻断回馈链路中需全ASBR对称配置长期稳定运行多ASBR复杂网络跨协议Tag传递依赖设备实现前缀过滤按前缀定向阻断高新增网段要同步维护前缀少、短期方案漏配即回馈复发AD优先级调整不阻断仅控制选路低两条命令临时止血表项污染和震荡仍在5.2 版本差异与协议特性最容易翻车的地方先说设备版本差异。不同版本的VRProute-policy的匹配行为在细节上可能有差异。比如有些版本里if-match tag对引入路由的匹配是只匹配外部路由Tag有些版本会把内部路由的Tag也带进来。遇到这种情况最稳妥的办法是先在模拟器里搭一个一模一样的双ASBR拓扑把Tag方案完整跑通再上生产设备操作。我坚持的原则是涉及路由策略的变更永远先在模拟器里验证一遍绝不直接在生产设备上试错。第二是OSPF特殊区域。如果OSPF域里有NSSA或Stub区域回馈路由和7类LSA的转换逻辑会叠加一层复杂度。比如NSSA区域里ABR会把7类LSA转换成5类LSA这个转换过程中Tag字段的保留行为、区域间的ADR都和普通Area 0不同。只要拓扑里出现NSSA我建议你把Tag方案仔细推演一遍重点观察7转5时Tag是否保留。很多回馈问题的隐藏变种就藏在这种区域边界转换里。第三是路由震荡期间的LSDB基线。回馈爆发的时候LSA序列号会不停自增你根本看不出正常的LSA长什么样。我建议在任何涉及双ASBR引入的变更前先抓一次LSDB和路由表作为基线变更后对比外部LSA数量是否和基线一致。我在割接规范里加了一条硬性要求配置完成后间隔5分钟统计两次LSDB中ASE数量两次结果必须一致——这能快速暴露隐藏的回馈循环。5.3 一个值得养成的设计习惯说句大实话回馈问题一旦出现排查起来最花时间的往往不是敲命令而是理清路由到底是从哪个方向、以什么身份进入另一个协议域的。所以我后来给自己定了一个规矩任何双点双向引入的拓扑动手配置前先画一张路由流向图。这张图上必须标注清楚有哪些路由前缀需要从OSPF跨到IS-IS有哪些路由前缀需要从IS-IS跨到OSPF每个引入方向使用什么Tag策略打什么Tag、拒什么Tag是否存在不需要跨协议的路由比如纯内部管理网段把这张图画完Tag方案其实就已经设计好了剩下的配置只是把图画内容翻译成route-policy。这张图同时还是变更评审和排障时的最重要的参考资料。回馈问题看似复杂捋清楚路由走向之后解决方案往往就是几行route-policy的事。我最后再分享一个感受回馈问题最麻烦的地方不在于技术本身而在于它总喜欢在你以为一切正常的时候悄悄出现。外部LSA数量缓慢增长、OSPF进程CPU偶发跳高、某些业务路径在割接后才暴露问题——这些温和的表象背后可能都是回馈链路在慢慢发酵。把Tag方案、基线和验证步骤提前固化到流程里比出了故障再到处翻命令要划算得多。希望这篇文章能帮你少走这些弯路。