happy最紧要上个月帮一家做智慧园区的集成商排障，他们的核心网络跑OSPF，核心层两台设备各启了一个OSPF进程，中间靠双向重发布打通。业务侧反馈视频监控平台时不时卡顿，核心交换机CPU偶尔冲到60%以上。我登录上去抓了一圈，第一眼就发现问题：LSDB里的LSA条目多到夸张，某些明细路由在两个进程之间翻来覆去地被通告——这就是“多进程OSPF+双向重发布”的典型并发症。
这个标题里的“多进程双向重发布”和“LSA更新量的优化”看起来是两个独立的知识点，其实是同一条链路的两端：多进程提供了网络融合的灵活性，双向重发布把进程之间的路由打通，但也把LSA更新和泛洪的负担成倍放大。如果只做配置不优化，短期能通，长期撑不住。
这篇文章围绕这两个点展开，以华为设备配置为主线，把原理、配置、防环、优化和验证串成一条完整的实验链路。适合正在学OSPF的网工，也适合那些已经上了多进程OSPF、但总感觉路由表不够干净、LSA数量偏高的朋友。
1. 哪些场景逼你开出第二个OSPF进程
1.1 单进程扛不住的三类网络
很多人刚开始学OSPF时有个误解：一个OSPF进程可以承载整个网络，为什么非要多开一个进程？正常情况下确实如此，但现实网络里总有一些特殊情况，逼着你不得不拆成多个进程。
第一类是公司并购或网络融合。两家原本独立运营的网络要打通，各自内部跑着OSPF，区域划分、网段规划、甚至Router ID都可能冲突。如果强行合并到同一个进程里，势必要动其中一方的全网配置，影响面太大。合理的做法是保留各自的OSPF进程，在边界设备上做双向重发布，先让业务互通，再逐步收敛。
第二类是租户隔离或多业务承载。比如运营商或大型企业给不同客户、不同业务部门提供网络承载，要求路由域互相隔离，一个业务的路由抖动不能影响到另一个。OSPF进程天然隔离了LSDB，进程之间互不可见，正好满足这个需求。
第三类是旧网络不能动、新区域又承载特殊需求。比如老旧的办公网跑着OSPF区域0，骨干链路带宽有限，不希望新接入的监控网段把LSA泛洪扩散到全网。这时把新区域放进另一个进程，连接点用重发布接入，旧网络基本不用改动。
多进程的代价是路由信息不能天然互通，必须靠重发布来“翻译”，而这个“翻译”过程会引入外部路由、产生LSA类型转换，还会带来环路风险。所以多进程不是随便开的，每个进程背后的业务边界、管理边界都要提前想清楚。
1.2 多进程与多区域的本质区别
理解多进程之前，必须先分清它和多区域的差异。OSPF多区域（Multi-Area）是在同一个进程下，通过划分Area来缩小LSA泛洪范围，区域间用ABR连接，骨干区域Area 0必须连续。多区域场景下，所有路由器共享同一个进程号，Router ID在同一进程内必须唯一，LSDB在区域层面隔离，但路由信息可以通过ABR汇总和传递。
多进程（Multi-Process）则完全不同。每个进程是独立的OSPF实例，拥有独立的LSDB、独立的SPF计算、甚至独立的Router ID空间。两个进程之间默认完全隔离，互相不知道对方的存在。想让两个进程互通，唯一的手段是在同时运行两个进程的边界设备上做路由重发布——把进程1的路由“翻译”成进程序2的外部路由通告出去。
我见过不少新手把多区域和多进程混在一起理解，其实大白话讲：多区域是一个OSPF网络内部的管理分区，多进程是多个互相隔离的OSPF网络的“拼接”。
1.3 多进程网络必须先想清楚的拓扑规划
实验开始之前，先画一张清晰的拓扑图比什么都重要。这里以我常用的基础拓扑为例：
- R1：运行OSPF 1，区域0，后端连PC1；
- R2：边界设备，同时运行OSPF 1和OSPF 2，充当两个进程的ASBR；
- R3：运行OSPF 2，区域0，后端连PC2；
- R4：运行OSPF 1，接入侧区域1，模拟终端网段；
- R5：运行OSPF 2，接入侧区域1，模拟另一侧终端网段。
PC1的网关在R1上，PC2的网关在R3上。要让PC1和PC2互通，必须在R2上完成双向重发布。实验里我只做单点边界设备，先把原理跑通；后续如果想模拟双点双向的环路场景，可以再加一台R6同时跑两个进程。
规划阶段还要提前确定三件事：Router ID分配规则、需要重发布的网段范围、防环tag的编号段。Router ID建议用环回口地址统一规划，比如1.1.1.1、2.2.2.2这样的格式，排障时一眼能认出是哪台设备。防环tag我习惯用200-300之间的整数，和业务tag区分开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 双向重发布怎么配才不返工
2.1 边界设备上的基础配置
边界设备R2同时运行两个OSPF进程，需要配置两套OSPF实例。
code复制<R2> system-view
[R2] ospf 1 router-id 2.2.2.2
[R2-ospf-1] area 0.0.0.0
[R2-ospf-1-area-0.0.0.0] network 10.0.1.0 0.0.0.255
[R2-ospf-1-area-0.0.0.0] quit
[R2-ospf-1] quit
[R2] ospf 2 router-id 2.2.2.2
[R2-ospf-2] area 0.0.0.0
[R2-ospf-2-area-0.0.0.0] network 20.0.1.0 0.0.0.255
[R2-ospf-2-area-0.0.0.0] quit
[R2-ospf-2] quit
注意一个细节：华为设备允许不同进程使用相同Router ID，但生产环境不建议这么干。一旦两个进程需要和外部的其他IGP协议互动，或者后续排障时从Router ID追溯设备，相同的ID会带来混淆。既然实验里R2是同一台物理设备，Router ID用同一个ID问题不大，但我还是建议用环回口地址来区分。
接下来配置双向重发布。在R2的OSPF 1里引入OSPF 2的路由，同时在OSPF 2里引入OSPF 1的路由。
code复制[R2] ospf 1
[R2-ospf-1] import-route ospf 2 type 1 cost 50
[R2-ospf-1] quit
[R2] ospf 2
[R2-ospf-2] import-route ospf 1 type 1 cost 50
[R2-ospf-2] quit
配置本身很简单，但千万别以为这样就算完了。如果不做类型、开销值和防环策略，后面LSA数量会爆炸，路由还可能绕远路。
2.2 外部路由type和cost的选型逻辑
重发布时最容易被忽略、也是最影响选路的两个参数：type和cost。
OSPF外部路由分两类。Type 1路由的开销值等于“外部引入时的cost + 到达ASBR的内部开销”，也就是说，外部开销和内部开销直接相加，适合对路径敏感的场景。Type 2路由的开销值只计算外部引入时的cost，到达ASBR的内部开销不计入，适合外部链路质量相对稳定的场景。
华为设备import-route默认生成Type 2外部路由，默认cost为1。这个默认值在实验环境里经常产生次优路径。举个例子，R2把OSPF 2的路由用默认方式引入OSPF 1，cost为1，R1上看到这条外部路由的cost就是1，而R1上另一条通过区域内部学到的相同路由cost可能是30。OSPF比较路由时优先看外部路由类型：Type 2路由直接比cost，Type 1路由则要加内部开销。默认的Type 2 cost 1很容易被选中，哪怕实际路径更长、带宽更差。
我的建议是实验环境统一用type 1，让外部路由的cost和内部实际路径挂钩，避免出现“看着很近实际绕路”的情况。cost给50是经验值，比内部路由大、又不会大到被忽略。如果希望重发布进来的路由在某些场景下被主动规避，可以把cost调高到200以上。
2.3 双点双向重发布的环路根因与tag防环
单点双向重发布（只有一台边界设备）的环路风险不大，因为重发布的方向只有一台设备在控制。但生产环境为了冗余，通常会在两台边界设备上都做双向重发布——这就是“双点双向”。实验里我建议先配单点跑通，再在旁边加一台R6模拟双点，观察发生了什么。
双点双向的环路是怎么产生的？假设R2和R6都同时运行OSPF 1和OSPF 2。R2先把10.1.0.0/24从OSPF 1引入了OSPF 2，R6在OSPF 2里学到这条外部路由。因为R6也配置了“从OSPF 2重发布到OSPF 1”，它会把这条外部路由再作为外部路由重新通告回OSPF 1。于是R1在OSPF 1里收到了R6通告的10.1.0.0/24的外部路由，这条路由本身就来自OSPF 1，绕了一圈又回来了。
更麻烦的是，这种回灌会让LSA不断刷新：R6通告LSA后，R2再更新LSA，R6又收到更新……在外部路由没有变化的情况下，LSA序号和校验和依然会周期性地翻滚，徒增网络负担。严重时配合不合理的cost和优先级，数据流量会在这个环路里打转。
解决手段是tag标签防环。核心思想只有一句话：在一侧进程里被引入的外部路由，打上一个特定tag；在另一侧进程做重发布时，凡是带着这个tag的路由一律拒绝引入。
配置分两步走。第一步，在重发布出去时打tag：
code复制[R2] route-policy SET_TAG permit node 10
[R2-route-policy] if-match nothing
[R2-route-policy] apply tag 200
[R2-route-policy] quit
[R2] ospf 2
[R2-ospf-2] import-route ospf 1 route-policy SET_TAG type 1 cost 50
[R2-ospf-2] quit
第二步，在接收方向拒绝带tag的路由回灌：
code复制[R2] route-policy DENY_LOOP deny node 10
[R2-route-policy] if-match tag 200
[R2-route-policy] quit
[R2] route-policy DENY_LOOP permit node 20
[R2-route-policy] quit
[R2] ospf 1
[R2-ospf-1] import-route ospf 2 route-policy DENY_LOOP type 1 cost 50
[R2-ospf-1] quit
注意permit node 20的写法：如果没有这条，所有路由都会被拒绝；加上它表示“除了带tag 200的路由，其他都正常引入”。R6上配置完全对称，但tag要换一个值，比如201，避免两个进程的管理域在tag上出现交叉。
2.4 路由优先级不调整的隐藏问题
另一类容易翻车的地方是路由优先级。华为设备OSPF内部路由默认优先级是10，外部路由默认优先级是150。当你做双向重发布时，OSPF 1里的路由器收到OSPF 2重发布进来的路由，是作为外部路由处理的，优先级150；而相同目标如果还存在于OSPF 1内部，优先级10的会胜出。
这个机制本身没问题，问题出在混合网络里。假如R2同时跑OSPF和静态路由，静态路由默认优先级60，比OSPF外部路由的150高。如果静态路由配置了缺省路由，OSPF重发布进来的外部路由在选路时可能永远排不上号，导致业务流量绕到静态路由的出口。
实验里我建议把外部路由优先级调到和内部一致或者略低，比如：
code复制[R2] ospf 1
[R2-ospf-1] preference 10 20
[R2-ospf-1] quit
这里preference 10 20的含义是：OSPF内部路由优先级10，外部路由优先级20。这样外部路由虽然有优先级差异，但不会完全被内部路由压制。生产环境调多低要根据业务需求来定，实验环境可以直接看现象调整。
3. LSA更新量为什么失控：先看OSPF更新机制
3.1 LSA家族与更新机制
优化LSA更新量之前，先得明白OSPF里有哪些LSA类型、各自干什么。
LSA类型大体分7种。1类Router LSA由每台路由器产生，描述自己的接口和邻居；2类Network LSA由DR产生，描述广播网络内的路由器成员；3类Summary LSA由ABR产生，用于区域间路由通告；4类ASBR Summary LSA由ABR产生，告诉其他区域如何到达ASBR；5类AS External LSA由ASBR产生，通告外部路由；7类NSSA External LSA由NSSA区域内的ASBR产生，用于在NSSA区域通告外部路由，最终由ABR转换成5类LSA泛洪到其他区域。
LSA的更新机制有两个关键点。第一，每类LSA都有老化计时器，默认3600秒；在老化前必须周期性刷新，刷新间隔默认1800秒。所以即使网络拓扑完全稳定，LSA也不会停止更新，只是更新频率低而已。第二，任何拓扑变化都会触发LSA的立即更新，然后通过泛洪机制传播到整个区域。泛洪的过程是每台路由器向所有邻居发送LSA，邻居再继续向它的邻居转发，直到全网LSDB同步。
理解这两个机制后，“LSA更新量大”的原因就清楚了：要么是LSA数量太多（类型多、条目多），要么是更新频率太高（拓扑频繁变化），要么是泛洪范围太大（区域没有合理收敛）。前两者和协议配置直接相关，第三条往往和多进程重发布有关——外部路由被引入后，会以LSA 5的形式在整个进程内泛洪，泛洪范围覆盖所有区域，效率很低。
3.2 多进程重发布把LSA数量放大了多少
做多进程双向重发布后，LSA数量是怎么翻倍的？我在实验环境里实际数过。
优化前，R1上OSPF 1的LSA数量大约是：1类LSA若干条（每台路由器一条）加2类LSA若干条加3类LSA若干条。R3上OSPF 2的LSDB同理。总量可控。
做了双向重发布之后，R2把OSPF 1的每一条明细路由都引入OSPF 2，每条路由生成一条5类LSA，泛洪到OSPF 2的所有区域；R2同样把OSPF 2的每一条明细路由引入OSPF 1，在OSPF 1里再生成一批5类LSA。如果两台边界设备都做双点双向，情况更糟：这些外部LSA不仅数量翻倍，还会因为回灌不断被刷新。
对路由器自身的影响也很直接。LSDB里堆满LSA后，SPF计算时间会随着LSA数量增加而变慢，CPU占用率上升。同时每一条LSA都有1800秒的周期刷新，LSA条目越多，单位时间内需要刷新的包就越多，网络里充斥的OSPF报文也更密集。
我把这个情况的后果总结成一句话：多进程解决了路由隔离和融合问题，但它把“链路状态”的代价从区域内部扩大到了整个进程，如果不优化，等于把所有区域的LSA泛洪压力集中到了重发布边界上。
3.3 可行的优化手段与效果对比
下面列几个我在实验中验证过、实际能压住LSA数量的手段，按“效果明显程度”排序。
第一是路由汇总。这是最立竿见影的一招。在ABR上对区域间路由做汇总，可以用abr-summary；在ASBR上对外部路由做汇总，可以用asbr-summary。配置后，多条明细路由聚合成一条汇总路由，LSA数量直接从N降到1。
code复制[R2] ospf 1
[R2-ospf-1] asbr-summary 10.1.0.0 255.255.252.0
[R2-ospf-1] quit
这条命令的意思是：OSPF 1里凡是10.1.0.0/22网段内的外部路由，通告时都汇总成一条10.1.0.0/22的LSA 5。R3上原本可能收到十几条外部LSA，现在只剩一条。
第二是特殊区域。把边缘区域配成stub或nssa，可以显著减少进入该区域的LSA类型和数量。stub区域会阻断4类和5类LSA，相当于外部路由进不来；nssa区域允许内部ASBR产生7类LSA，但不会让全网的5类LSA泛洪进来。
第三是静默接口。对于不需要建立邻居的接口，可以在进程里配置silent-interface。这个接口不再发送hello报文，也不会接收和泛洪任何LSA。接入侧、终端侧、上行互联但不需要OSPF邻居的接口，都可以这样处理。这一招在LSA数量优化上效果极其明显——很多接入层设备默认在全部接口上跑OSPF，如果静默掉非必要接口，LSA数量能降一半。
第四是LSA过滤。如果不想做特殊区域，可以通过filter lsa-out在ABR上过滤向指定区域通告的LSA。注意这个命令和filter-policy不一样：filter-policy import只影响本机路由表加载，不影响LSDB；filter lsa-out直接影响LSDB的内容。两者的区别我在后面排错部分会再详细说。
第五是计时器调整。把hello时间从10秒调大到30秒、dead时间从40秒调大到120秒，可以减少周期性hello报文的数量。这个手段不能减少LSA数量，但对网络带宽和CPU的消耗有轻微缓解。要注意：同一链路上两端的hello和dead必须一致，否则邻居建立不起来。
如果把这些手段叠加使用，比如“汇总+特殊区域+静默接口”，LSA数量的下降会非常明显，SPF计算频率和CPU占用也会随之回落。
4. 实验验证的关键命令与前后对比
4.1 看LSA和路由的六个核心命令
做完配置后，验证环节绝不能省。多进程OSPF的排障和验证，我每次必敲下面几条命令。
第一条是display ospf peer brief，看邻居状态是否Full。两个进程、多个区域，邻居状态是最直观的健康度指标。
第二条是display ospf lsdb，查看本进程的LSDB全貌。通过这条命令能看到LSA条的1类、2类、3类、5类等LSA内容，确认有没有异常的外部LSA被回灌。
第三条是display ospf lsdb asbr和display ospf lsdb ase，只看外部LSA条目，这是诊断重发布问题最快捷的入口。外部LSA的数量和来源如果异常，第一时间就在这里暴露。
第四条是display ip routing-table，看实际路由表的加载情况。路由表里出现了本不该出现的明细路由，可能是过滤策略失败；出现了汇总路由但下一跳指向自身，往往是黑洞路由问题（后面讲）。
第五条是display ospf routing，查看OSPF路由表。这条命令和display ip routing-table有区别，它更专注于OSPF路由及其cost、tag信息，防环是否生效用这条命令看tag最直接。
第六条是display ospf brief，看设备上所有OSPF进程的概要信息，包括Router ID、进程状态、区域数、邻居数。多进程环境里先确认每个进程都正常，再往下深挖。
4.2 优化前后LSA数量与SPF压力的对比
我在实验拓扑里做过一次优化前和优化后的LSA数量统计，数据能说明问题。
优化前：R1连接区域0和区域1，区域1里有多条终端网段，R4在区域1里通告了10条路由；R2把OSPF 1的这些明细路由全部引入OSPF 2；R3因此收到了10条外部LSA，加上R5在OSPF 2区域1里通告的明细，R3的LSDB里有十几条5类LSA。
优化后：在R2上把区域1的10条明细路由用abr-summary汇总成2条，再配合asbr-summary对外部路由做聚合；把R1接入侧接口配置silent-interface；把边缘区域改成totally nssa。最终R3看到的5类LSA从10条降到了2条，1类LSA的数量也因为静默接口减少而下降，整个LSDB条目数下降了约60%。
这个数据不是理论推演，是我在实验环境里真实抓出来的。LSA数量下降后，display ospf lsdb的输出短了一大截，SPF计算频率也明显降低。在模拟大量路由条目时，优化前后的差异会更大——LSA条目越多，优化收益越明显。
另外，display ospf cumulative可以查看OSPF的CPU时间统计和LSA生成次数。优化后LSA生成次数会显著下降，这比单纯看LSA数量更能说明“更新量”问题是否真正缓解。
5. 我在这个实验里踩过的坑和排错思路
5.1 邻居反复卡在ExStart：MTU不一致
多进程实验的排错，第一步往往是看邻居状态。我曾在做双进程重发布时，R2和R3的邻居状态一直卡在ExStart阶段，就是进不了Full。
这里要引出一个很经典的OSPF问题：接口MTU不一致。OSPF在ExStart阶段要协商Master/Slave关系，之后在Exchange阶段通过DBD报文交换LSDB摘要。DBD报文里携带接口MTU信息，如果两端MTU不一致，状态机会反复停留在ExStart，因为双方在数据库描述阶段无法确认对方的DBD报文大小。
排查方法很简单：对比两端的接口MTU。
code复制display interface GigabitEthernet0/0/0 | include MTU
华为设备默认MTU一般是1500，但如果某台设备的接口被改过MTU、或者做了QoS和MPLS相关的mtu调整，OSPF邻居就会卡住。解决办法是把两端MTU调成一致，或者在接口下配置ospf mtu-enable来忽略MTU检查（不推荐，生产环境要谨慎）。
这个坑在单进程实验里很少遇到，但在多进程综合实验里因为涉及多厂商设备、多条链路对接，反而很常见。如果发现DBD交换阶段持续重传，优先检查MTU。
5.2 汇总后出现黑洞路由
配置abr-summary或asbr-summary之后，另一个经典问题冒出来了：明细路由汇总后，如果下游出现了匹配汇总路由但实际不存在的子网，流量会直接被丢弃——黑洞路由。
我在实验里给R2配置了asbr-summary 10.1.0.0 255.255.252.0后，为了测试故意在OSPF 2里删除了其中一段明细路由，但汇总路由仍然存在。R3的流量如果发往那个已经不存在的网段，就转发到了R2，而R2没有更精确的路由，只能丢弃。
生产环境的做法是一定要有Null0接口作为汇总路由的防黑洞出口。华为设备在配置abr-summary时，如果开启null0选项，会自动生成一条指向Null0的汇总路由：
code复制[R2] ospf 1
[R2-ospf-1] asbr-summary 10.1.0.0 255.255.252.0 null0
[R2-ospf-1] quit
这样流量如果匹配不到明细路由，直接丢进Null0接口，不会在真实网络中绕圈。这个配置看起来反直觉，但恰恰是为了避免汇总带来的黑洞问题。
5.3 过滤策略把路由全滤没了
另一个坑是“过滤策略配错导致路由消失”。我见过最典型的一次：给OSPF配置了filter-policy 2000 import，本意是过滤不想加载的路由，结果路由表里所有OSPF路由都没了。
原因在于对filter-policy理解不到位。filter-policy的过滤动作发生在“路由表加载”阶段，它只能限制本机路由表里有没有这条OSPF路由，但不会影响LSDB。也就是说，它能防“本机选错路”，但不能防“邻居学到错误路由”。
如果想让某条LSA不被通告出去，或者不想让某个区域的LSA泛洪进另一个区域，应该用区域过滤或filter lsa-out，而不是filter-policy。
还有一个更隐蔽的问题：在双进程重发布的场景里，filter-policy import可能把重发布进来的外部路由也过滤掉。因为重发布后的路由在本地是外部路由，如果ACL只放行了某几条，其他重发布进来的路由就不会出现在路由表里，但LSDB里的LSA还在。这种情况排障时会看到“LSDB里有路由但路由表没加载”的诡异现象。
我的建议是：实验里先理清自己到底要过滤“路由表加载”还是“LSA泛洪”，再选择对应命令。如果只想让路由不进本机路由表，用filter-policy import；如果想让某个区域彻底不收某些LSA，用区域下的filter lsa-out；如果想在ASBR上过滤外部LSA的生成，配置filter-policy export。
5.4 tag防环配置后路由不学不发布
讲了这么多防环配置，最后说一个我在自己实验里反反复复遇到的“低级错误”：route-policy里只写了deny节点，忘了加permit空节点，导致所有路由都被拒绝。
具体现象是这样：配置了route-policy DENY_LOOP后，在OSPF进程下调用，结果路由表里所有从对端进程重发布过来的路由全部消失。这时display route-policy可以看到匹配计数一直在增长，但允许节点数为0。
原因很简单——route-policy的匹配逻辑是按节点顺序执行的，默认动作是拒绝。如果deny节点匹配了带tag的路由后，后面没有显式的permit节点，剩下的所有路由都会被拒绝。而我不小心把permit node 20漏掉了。
这个坑看起来基础，但在多进程多route-policy叠加的复杂配置里非常容易犯。每次调用route-policy之前，养成习惯用display route-policy确认节点数，至少在末尾加一个空permit节点做兜底。
还有一点：tag防环要配合display ospf routing来看效果。我排障时经常先确认路由表里有没有带tag的条目，再用这条命令确认路由是不是以期望的tag进了OSPF路由表。如果tag没打上，防环策略再漂亮也白搭。
我在实际项目里已经养成了一个习惯：交付前在所有核心设备上各抓一份display ospf lsdb和display ospf routing存档，拿它跟优化前的基线对比。LSA数量降下来多少、外部路由是不是还带着异常tag、有没有明细路由被汇总吞掉，全都清清楚楚。OSPF这套东西，配置上去不难，难的是把更新量压到合理水平、同时保证路由不绕路不出环。多进程加双向重发布的路，踩过一次坑，后面再配就有数了。