永远雪山干网络这行十几年，路由重发布（路由重分发）是绕不开的活儿。两个协议域的互通，单点双向很多人都能上手，真正的分水岭在于双点双向路由重发布——两台边界设备、两个方向同时重发布，表面看是提高冗余，实际配置不当就是给自己埋雷。这篇文章我会用一个企业并购后OSPF与IS-IS双域互通的场景，把双点双向路由重发布的原理、套路和方法一次讲透，手把手给出华为设备下的可落地配置，再分享这些年遇到过的典型故障和排查命令。准备改配置的网络工程师、正在攻坚高级认证的考生，都能从里面直接拿走能用的东西。
1. 双点双向路由重发布到底是个什么活
1.1 从一个域到另一个域：路由重发布的本质
先把地基打牢。路由重发布的本质，就是让两个“语言不通”的协议域互相理解对方的路径信息。OSPF用LSA和Cost，IS-IS用LSP和Metric，RIP用跳数，它们各自维护一张独立路由表，互相之间没有任何交集。想让OSPF域的设备访问IS-IS域里的网段，不能靠祈祷，必须有个“翻译官”站在两个域的边界上，把一侧协议学到的路由条目，转换成另一侧协议能识别的格式，再注入进去。这个动作就是重发布，华为叫import-route，思科叫redistribute。
翻译不是免费的。重发布进目标协议的路由，默认会被打上“外部路由”的标记，在OSPF里就是ASE或ASE。外部路由的度量值并不是自动换算的，而是靠配置者手工指定一个种子度量（Seed Metric）。不指定的后果很直接：OSPF引入外部路由默认Cost是1，IS-IS引入默认是10，RIP引入默认是1。这两个数字和内部路径的真实开销完全没有可比性，后面所有选路问题，一大半都是从这里冒出来的。
还有一个基础点容易被忽略：重发布的路由必须存在于源协议的路由表里，并且状态是Active。如果设备通过OSPF只学到了路由，但没有放进核心路由表，那import-route命令执行了也不会引入任何东西。我见过不少新手在这上面卡壳：策略写了一大堆，结果源协议里那条路由就没有被优选，最后当然什么都引不出来。
1.2 双点：冗余的诱惑和代价
单点重发布的结构很简单：一台边界设备，A域和B域各接一个口，配置两条import-route命令，完事。但单点的隐患也摆在明面上——这台设备挂了，两个域直接物理隔离，下面的应用全部报错。所以很多人为了高可用，会在两个域之间部署两台甚至多台边界设备，同时做重发布，这就是“双点”。
双点的诱惑在于冗余，代价则是路径复杂性。两台边界设备同时向B域通告A域的路由，B域的设备就会收到两条指向同一目的地的外部路由；反向同理。这两条路由哪个优、哪个次，完全取决于你配置的种子度量和管理距离。如果没规划好，数据流量就会在两条边界路径之间“反复横跳”，甚至出现明明有千兆直连，流量却绕到百兆链路上的荒唐局面。
更重要的是，双边界之间往往会有一条互联链路，或直连三层口，或走内部备份线路。这条链路本来是用于故障切换的，但它同时成了路由回馈的“高速公路”。单点重发布之所以不易产生环路，就是因为缺少这样一条让路由绕回来的物理通路；双点结构天然具备这条通路，环路风险也随之而来。
1.3 双向：别把“双向”理解成两边都写命令
双向重发布，字面意思是A域路由进B域、B域路由进A域，两边边界设备都要配置。但往上想一步，它的真正含义是：每个域的路由器，都可能在另一条协议域的“绕行路线”上，再次学到自己域内的路由。
我用一个真实案例来说明。某公司并购了一家子公司，母公司核心网当初用的是OSPF，子公司的园区网建设早，一直跑IS-IS。两边要打通，自然想到在核心和园区之间放两台汇聚交换机，同时跑OSPF和IS-IS，各自做双向重发布。这个方案看着没毛病，但设备一上线，路由抖动、业务时断时续的现象立刻出现。原因就是双点双向之下，OSPF域里的某条路由被引入IS-IS后，从IS-IS域传播到了另一台边界，又被那台边界重新引回OSPF域。一台设备的OSPF路由表里同时出现了同一条路由的两个版本：一个来自本地OSPF域，一个来自“IS-IS域绕回来的OSPF外部路由”。两者管理距离不同、Cost不同、下一跳也不同，路由表就开始折腾了。
所以，双向的真正含义是“两个方向都要防回灌”，而不只是两条import-route命令。这一点想不明白，后面配置全是被动打补丁。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 双点双向为什么容易翻车：环路与次优路径拆解
2.1 路由回馈环路：绕一圈又回来，洪水倒灌
路由回馈是双点双向最经典的坑。严格说，它不是一条链路转一圈的死循环，更多表现为路由“往返震荡”和次优选路，但极端情况下的确有环的可能。
我画个文字拓扑：R2和R3是两台边界，都同时跑OSPF和IS-IS，R2-R3之间有一根二层或三层互联链路，两个协议都在上面启用。OSPF域里有R1，IS-IS域里有R4。
第一步，OSPF域里的10.10.0.0/16由R2重发布进IS-IS，R2给这条路由打上Cost种子值，IS-IS域里所有设备（包括R3）都学到了这条“IS-IS外部路由”。第二步，R3自己也配置了双向重发布，它把IS-IS路由表里学到的10.10.0.0/16当作IS-IS路由，再重发布回OSPF域。于是OSPF域里又出现了10.10.0.0/16的第二条通路，下一跳指向R3。第三步，R1收到R3通告的这条OSPF外部路由，而它原本从R2已经学到了10.10.0.0/16的OSPF内部路由。OSPF内部路由管理距离10，外部路由管理距离150，正常情况下内部路由优先，环可能还转不起来。但如果R1本身对10.10.0.0/16的直连或内部路径出现了问题，或者R3通告的是特定前缀、特定掩码汇总后的条目，外部路由就可能被优选，流量就会从R1跑到R3，再从R3经IS-IS域绕回R2，最终再到R1——整个环路就转起来了。
这过程很像小区有两个门，快递员从东门把包裹送进来，又有人从西门把这个包裹重新塞进快递柜，收件人拿到的包裹上贴了两个签，既说不清从哪来的，也说不清该往哪送。双点结构只要不做防回灌，路由回馈几乎必然发生，只是时间早晚的问题。
2.2 次优路径：度量值体系不可比
双点双向环境下，次优路径问题比环路更隐蔽，也更容易被忽略。原因在于两个协议的度量体系根本没法放在一起比。OSPF的Cost是参考带宽除以接口带宽，千兆接口Cost是1，百兆接口Cost是10；IS-IS的Metric默认情况下所有接口都是10；RIP干脆就是跳数。重发布时，翻译官按自己的习惯给外部路由一个种子度量，这个值和源协议里的真实链路质量一点关系都没有。
举个例子。IS-IS域里有条20.20.0.0/16的路由，R2重发布进OSPF时Cost设了50，R3重发布时Cost设了30。OSPF域里的R1一算，去20.20.0.0/16应该走R3，因为Cost小。但实际情况可能是R2到目标网段是千兆直连，R3到目标网段是跨了三条百兆链路的“远房亲戚”。由于R3的种子度量设置不当，业务流量全被引到了慢速链路上。
要治这个问题，一是把外部路由类型从Type 2改成Type 1。Type 2只比较种子度量，忽略内部路径开销；Type 1会在种子度量的基础上累加沿途的OSPF内部Cost，更接近真实路径质量。二是在两台边界上显式设置不同Cost，人为制造主备关系。很多工程师嫌麻烦，图上标了“双上行负载均衡”，配置里却不做任何区分，最后两条链路实际上是一条忙死一条闲死。
2.3 优先级打架：不同协议AD值带来的不一致
还有一个坑是协议优先级冲突。华为设备默认管理距离大致是：直连0、OSPF内部10、IS-IS 15、静态60、OSPF外部ASE 150。当一台边界设备同时在OSPF和IS-IS里学到同一个前缀，它会根据协议优先级决定谁进核心路由表。默认情况下，IS-IS路由比OSPF外部路由更优，所以如果OSPF外部路由勾引着数据走了一条绕行路径，而IS-IS原生的更优路径就在眼前，选路结果就会和预期完全相反。
这种问题比路由回馈更麻烦，因为它不会表现为“不通”，而是表现为“为什么老是绕路”。而且，一旦路由在OSPF外部和IS-IS之间来回切换，Ping包会在两个路径之间跳变，业务时好时坏，上层应用报“抖动”，底层看路由表却是“迂回振荡”。
3. 亲测可用的配置方案：Tag、过滤、AD值三板斧
3.1 动手之前先画流向图
双点双向配置最忌讳上来就敲命令。我给自己定的规矩是：先画一张流向图，标清楚这几个信息——哪些网段需要跨域互通；正常情况下希望流量走哪个边界；边界链路故障后允许流量切到哪个边界；哪些路由绝对不允许被“回灌”进原域。
把这个图做出来，后面的配置就是填空。以并购场景为例：OSPF域（母公司）有10.10.0.0/16和10.20.0.0/16两段；IS-IS域（子公司）有20.20.0.0/16和20.30.0.0/16两段；R2和R3均为边界，R2为主边界，R3为备边界。主备策略是：正常情况下，两个域间流量走R2；R2故障时切到R3。基于这个规划，R2上重发布的种子度量要优于R3，这个差异可以用Cost值体现，比如R2设100、R3设200，数值越小越优。
3.2 基础配置：OSPF与IS-IS双进程互通
先让两个协议跑起来，再做策略。以R2（主边界）为例，核心配置如下：
bash复制ospf 1
area 0
network 10.0.12.0 0.0.0.3
network 10.0.23.0 0.0.0.3
isis 1
is-level level-2
network-entity 49.0001.0000.0000.0002.00
interface GigabitEthernet0/0/0
ip address 10.0.12.1 255.255.255.252
ospf enable 1 area 0
interface GigabitEthernet0/0/1
ip address 10.0.24.1 255.255.255.252
isis enable 1
interface GigabitEthernet0/0/2
ip address 10.0.23.1 255.255.255.252
ospf enable 1 area 0
isis enable 1
注意R2和R3之间那条互联链路，我特意让OSPF和IS-IS都启用了。这样做的原因是模拟真实场景中边界之间的备份链路通常同时承载两个协议用于状态同步，也正因为如此，路由回馈才有物理通路。如果不启用双协议，环路风险会小一些，但真实的故障演练往往就是在你“以为没启用”的时候翻车。
R3的配置和R2基本对称，设备编号、接口IP、IS-IS System-ID换成R3的，OSPF区域和IS-IS Level保持一致即可。两边光配置完这些，双向重发布还没有做，协议域的邻居关系一旦正常，就可以进入策略阶段了。
3.3 方案A：用路由Tag给每一条重发布路由发“身份证”
我在现场最推荐的防回灌手段是路由Tag。它的思路简单粗暴：每一条重发布进对端域的路由，都打上一个专属标记；当其他边界设备试图把这类路由再引回原域时，看到Tag就拒绝引入。
具体设计如下。从OSPF引入IS-IS的路由，统一打Tag 100；从IS-IS引入OSPF的路由，统一打Tag 200。每台边界在把IS-IS路由引入OSPF时，拒绝带Tag 100的路由；在把OSPF路由引入IS-IS时，拒绝带Tag 200的路由。这样OSPF域里的路由不会被IS-IS域“绕一圈”后又回到OSPF，IS-IS域里的路由同理。
R2上的路由策略配置：
bash复制route-policy FROM_ISIS_M deny node 10
if-match tag 100
route-policy FROM_ISIS_M permit node 20
route-policy FROM_OSPF_M deny node 10
if-match tag 200
route-policy FROM_OSPF_M permit node 20
ospf 1
import-route isis 1 route-policy FROM_ISIS_M cost 100 type 1 tag 200
isis 1
import-route ospf 1 route-policy FROM_OSPF_M cost 100 tag 100
R3上的路由策略配置：
bash复制route-policy FROM_ISIS_B deny node 10
if-match tag 100
route-policy FROM_ISIS_B permit node 20
route-policy FROM_OSPF_B deny node 10
if-match tag 200
route-policy FROM_OSPF_B permit node 20
ospf 1
import-route isis 1 route-policy FROM_ISIS_B cost 200 type 1 tag 200
isis 1
import-route ospf 1 route-policy FROM_OSPF_B cost 200 tag 100
这段配置里的Routing Policy逻辑要仔细体会。以R2为例，它从OSPF引入了10.10.0.0/16进入IS-IS，这条路由带Tag 100。在IS-IS域里传播到R3后，R3准备把IS-IS路由引入OSPF时，FROM_ISIS_B的Deny节点发现Tag是100，直接拒掉——10.10.0.0/16就不会从R3绕回OSPF域了。反过来，R3把20.20.0.0/16从IS-IS引入OSPF时打Tag 200，R2在引入IS-IS路由进入OSPF时认出了Tag 200，也拒掉。两个方向都被堵死，环路在源头就被掐断。
我特别偏好Tag而不是ACL前缀过滤，是因为Tag跟着路由走，不依赖IP前缀。将来网络演进，某个网段被汇总、被分割、被重新规划，Tag不会失效；ACL里的前缀列表一旦没跟上变化，就是一次新的事故。
3.4 方案B：filter-policy限定重发布范围
有些场景需求很明确：我只想放行某几个网段跨域互通，其他路由一概不让出去。这时候route-policy配合IP前缀列表更直接。
比如我只要20.20.0.0/16从IS-IS引入OSPF，其他IS-IS路由都不引：
bash复制ip ip-prefix SITE_B index 10 permit 20.20.0.0 16 greater-equal 24 less-equal 28
route-policy FILTER_ISIS permit node 10
if-match ip-prefix SITE_B
ospf 1
import-route isis 1 route-policy FILTER_ISIS cost 100 type 1 tag 200
这个方案的好处是控制粒度细，坏处是需要严格知道所有网段，否则漏了一条，业务就断了。而且这里有个容易踩的坑：OSPF的filter-policy import和重发布用的route-policy不是一回事。filter-policy import只影响本机的OSPF路由表，不会阻止LSA在OSPF域内继续传播。如果想控制外部路由进入整个OSPF域，必须在引入点时用route-policy做过滤，而不是在入方向做filter-policy。
这个细节我吃过亏。有次为了屏蔽某段路由，在边界设备上加了一条ospf 1下的filter-policy import，结果本机路由表确实干净了，但下游路由器还是能从该边界设备学到那条LSA，照样通了不该通的路径。后来才意识到OSPF的LSA传播和路由表构建是两个层面的事。
3.5 方案C：AD值和Metric配合做路径规划
Tag解决的是环路，Metric负责的才是主备选择和负载均衡。在双点双向里，我希望正常情况下所有跨域流量都走R2，所以R2上重发布进入对端域的Cost必须是100，R3上是200。因为OSPF外部路由用的是Type 1，所以R1在比较两条外部路由时，还会累加从R1到R2、从R1到R3的OSPF内部Cost。只要R2的种子Cost优势够大，路径就能稳在R2上。
IS-IS域里同理，Metric默认情况下比较粗糙，两台边界都通告100时很容易出现等价负载。要强制主备，就必须把R2的入向Metric设小。不要指望IS-IS默认的Metric足够精确，它所有接口都是10，你不在重发布时显式设置Cost，等于把选择权交给了运气。
关于AD值，我做过的调整不多，因为这是全局行为，影响面太大。但有一种场景值得说：边界设备上同一条前缀同时有OSPF外部路由和IS-IS路由，默认情况下IS-IS的15比OSPF外部ASE的150更优先，可能导致边界设备自己的流量偏向了IS-IS路径。如果我的设计意图是“OSPF域内流量优先从本域转发”，可以通过preference命令调整：
bash复制isis 1
preference 20
这样IS-IS的优先级从15变成20，OSPF内部路由的10仍然是本域最优，OSPF外部路由的150反而最差。这种调整只在这台边界设备上生效，而且会影响所有IS-IS路由，所以改之前必须评估是不是有更细粒度的替代方案。我的经验是能不用AD值就不用，优先用Metric和Tag的组合拳解决问题。
3.6 现实中的组合拳：Tag加Metric双管齐下
把前面的方案合成一套可落地的完整配置，就是最稳妥的实践。核心思路是：Tag负责防环，Metric负责主备，前缀过滤只用来放行必须互通的网段。R2和R3按3.3节的配置实施后，OSPF域去往IS-IS域的路由会稳定优选R2，因为Type 1外部路由Cost是100对200的差距；IS-IS域去往OSPF域的路由同样优选R2。当R2整机故障时，IS-IS进程和OSPF进程同时消失，R3的Cost 200路由在缺少更优路径的情况下自然被选中，业务自动切换。
这套组合不需要依赖BFD也不会产生额外的路由震荡，因为Tag的Deny规则稳定地工作在每台边界的重发布入口处。很多人担心Tag在跨厂商环境下的兼容性，华为和思科对Tag的处理能力都没问题，思科在redistribute命令里用route-map设置set tag，华为用apply tag，两边对接时Tag值能正常传递。如果你跨的是更复杂的厂商环境，建议先做一遍Lab验证。
4. 故障实录：双点双向问题排查与验证
4.1 验证命令速查：路由表、LSDB、IS-IS数据库、路径确认
配置完成不等于万事大吉，我每次改完双点双向配置，必查四样东西：路由表、外部路由数据库、实际转发路径、策略命中情况。
最常用的是这几条：
bash复制display ip routing-table 20.20.0.0 16
display ip routing-table protocol ospf
display ospf lsdb | include ASE
display isis route
display current configuration configuration route-policy
display ip routing-table看的是最终优选结果，路由表里同时出现下一跳到R2和R3的同前缀条目，就要警觉了：如果两台边界的Cost设置不合理，这里会留下一个等价的隐患。display ospf lsdb | include ASE能直接看到OSPF域里有哪些外部路由，对应的Tag值可以通过后面的display current configuration核对。display isis route则是看IS-IS域内的路由视图。
验证路径最直接的工具还是tracert，从OSPF域内的终端去ping IS-IS域的服务器，观察第一跳是不是R2；再反向tracert一次，确认回程路径也是R2。如果来回路径不对称，多半是IS-IS域里的Metric设置没有形成主备。
4.2 故障一：路由震荡，同一个前缀在两张表里来回跳
一个典型的现网故障是：OSPF域里的某台核心设备，路由表里20.20.0.0/16一会儿下一跳指向R2，过几秒又指向R3，业务日志里出现过大量超时。这就是路由震荡。
排查思路按顺序走。第一步，看路由表里20.20.0.0/16的明细，确认两条路径都有还是只有一条。第二步，看OSPF LSDB里的ASE条目，确认R2和R3都在宣告这条外部路由。第三步，看Tag，确认是不是防回灌没生效——如果IS-IS域里有一条带Tag 100的OSPF引入路由，又有一条原生IS-IS路由，边界设备在重发布时没Deny，就会出现两个来源在协议间反复切换。第四步，核对AD值。
绝大多数情况下，路由震荡都是Tag策略漏了一条Deny导致的。我见过有人只在R2上做了Tag防回灌，R3上做了另一个版本的过滤策略，两边策略不一致，结果R2堵住了回灌，R3没堵住，路由从R3那边绕了回来。处理方式也很简单：统一两台边界的路由策略，Deny值必须一致，Tag规划全局统一，别各写各的。
4.3 故障二：业务流量绕远路，跨过边界再绕回来
还有一种现象是业务不通却不完全断，Ping包丢包率很低，但延迟从5毫秒涨到30毫秒，用户体感明显变差。tracert一看，从OSPF域到IS-IS域的流量，先到了R3，再从R3穿到边界互联链路到了R2，再从R2进入IS-IS域。明明R2是主边界，数据却从R3绕了个“U”字型。
这种情况的根源通常有两个。一个是OSPF外部路由类型设成了Type 2，导致R1比较两条去20.20.0.0/16的路由时只看种子Cost，不看内部路径质量；而R3虽然在物理链路质量上更差，但种子Cost设置成80，比R2的100小，就被选优了。另一个是IS-IS域里的Metric没有拉开差距，R2和R3通告的都是默认Metric，IS-IS域内的设备无法区分哪个边界更近。
处理办法是把R2、R3的重发布度量统一收口：R2设100，R3设200，且OSPF侧统一用Type 1。改完后必须重新核对路由表，确认下一跳已经切换到R2。如果Metric已经拉开但路径还是绕远，再看一下是不是有静态路由、策略路由把流量硬掰过去的可能。
4.4 故障三：某网段不通，看起来像黑洞
有时候双点双向配置完成后，域间大部分网段通了，偏偏某一个网段不通。现象是：在域内设备上ping对端网段超时，但在边界设备上ping对端是通的。这表明路路由没有在整个域内扩散完整。
排查时先看边界设备的路由表，确认该网段是不是在源协议路由表里存在且Active。如果边界设备上根本没有这条路由，检查另一侧的源协议邻居有没有把路由通告过来。如果边界设备路由表里有，但下游设备查不到，问题往往出在过滤策略上。
比较容易踩的坑是IP前缀列表的greater-equal和less-equal参数。比如我写20.20.0.0 16 greater-equal 24 less-equal 28，那20.20.0.0/16这个主网段本身就不会被匹配，只匹配掩码24到28位的明细路由。如果对端通告的正是这个16位主网段，它就被过滤策略误杀了。这种错误很难一眼发现，因为它绑在route-policy里，不是单独一条命令，不把整段策略过一遍根本看不到。
另一个隐蔽的场景是OSPF的filter-policy import：在边界设备上做入方向过滤后，本机路由表没有该路由，重发布自然也不会引入。但下游路由器可能通过其他边界仍然能学到这条路由，形成“部分通、部分不通”的诡异现象。处理这类故障，一定要分清楚“路由表里有没有”“路由策略允不允许”“数据库里有没有”三件事。
4.5 排查速查表：症状、原因、命令、对策
把常见的故障症状整理成一张速查表，现场排查效率高很多。
| 症状 | 可能原因 | 检查命令 | 处理建议 |
|---|---|---|---|
| 路由表同前缀频繁切换 | Tag防回灌策略缺失或两端不一致 | display ip routing-table 多次对比 |
统一两端Deny Tag，确保Tag规划一致 |
| 业务延迟增大，tracert多跳 | 外部路由Type 2未累加内部Cost | display ospf lsdb 查看ASE Type |
改用Type 1并拉开两端种子Cost |
| 某一个网段完全不互通 | 前缀列表greater-equal匹配错误 |
display route-policy核对 |
仔细核对掩码范围，必要时临时放通验证 |
| 双向都通但来回路径不对称 | IS-IS/OSPF Metric设置未拉开 | 双向tracert |
调整备用边界入向Metric，强制主备 |
| 边界设备通，下游设备不通 | OSPF filter-policy import误杀 |
display ospf lsdb与路由表对照 |
评估过滤方式，改用重发布入口策略 |
5. 写在最后：给马上要动手的人几条真实体会
双点双向路由重发布这套东西，理论说起来就那么几条，但真正在现网里配一遍、踩一遍、救一遍，和纸上谈兵完全是两码事。我个人的体会是：画流向图那一步省不得。哪怕是在纸上画个框，把R2、R3、主备方向、Tag数值标清楚，都比到了设备前边想边敲强十倍。很多现场事故，根本不是命令不会写，而是连“哪条路由该从哪个方向进来、哪个Tag该被谁拒绝”都没想明白。
再有一点，Tag值一定要全局统一规划，最好在项目文档里画一张表，写明100是谁的、200是谁的、Deny规则长什么样。别凭感觉给每台设备各写一套，等三个月后换人维护时，谁也不知道当初的Tag是什么意思。
最后分享一个小技巧：每次改完双点双向的重发布，别急着验收业务，先在OSPF域和IS-IS域各挑一台代表性设备，反复多查几次路由表，确认同前缀的路由条目稳定、下一跳符合主备规划，再让业务测试。路由表稳了，业务大概率就稳了。要是路由表还在跳，业务测试做得再多也是白忙。