戈玄白今天要做题提到OSPF的多进程双向重发布，很多人第一反应是"这不就是个 import-route 的事吗"。确实，从配置命令上看，双向重发布就两条命令，但真正把它放到一个完整实验里，再叠加LSA更新量的优化，你会发现这里面的门道远比想象中多：路由回馈、次优路径、环路风险、LSA泛洪风暴，每一个都能让你在模拟器里折腾一整天。
这篇文章我用一个四台路由器的实验拓扑，把OSPF多进程、双向重发布、LSA更新量优化这三件事串起来做一遍完整的实验。整个过程会覆盖原理层面的"为什么"、配置层面的"怎么敲"，以及验证层面的"怎么看效果"。不管你是在准备H3C或华为的认证实验，还是在现网里真正遇到了多进程重发布的场景，这篇内容都可以直接参考。
1. 实验拓扑与整体设计思路
1.1 为什么需要多进程OSPF
先聊一个基础问题：一台路由器上为什么要跑多个OSPF进程？
很多人会在两个场景里遇到它。第一个是网络合并，比如两家公司合并，各自的网络规划都是独立的OSPF域，域内地址空间、区域划分、路由策略都完全不同，强行整成一个OSPF进程会导致LSDB冲突、区域设计推倒重来，风险太大。第二个是设备角色隔离，一台核心设备同时承担两个业务平面的路由，两个平面之间只希望路由可达，但不想让彼此的LSA互相干扰。
OSPF多进程的机制并不复杂：进程号在本地有意义，每个进程维护独立的LSDB、独立的邻居表、独立的SPF计算。进程之间默认互不相通，想通就得靠重发布。这个"隔离+桥接"的特性，正好适合做双向重发布的实验环境。
1.2 组网设计与地址规划
我设计的拓扑如下，用四台路由器组成两条OSPF域加一条RIP链路的结构：
- R1 的 LoopBack0 为 1.1.1.1/32，属于OSPF进程1的Area 0；
- R2 同时运行OSPF进程1和RIP进程，是第一个双向重发布点；
- R2 与 R3 之间跑RIP，网段 23.0.0.0/24；
- R3 同时运行RIP和OSPF进程2，是第二个双向重发布点；
- R3 与 R4 之间属于OSPF进程2的Area 0，R4 的 LoopBack0 为 4.4.4.4/32。
接口规划如下表：
| 设备 | 接口 | 地址 | 所属协议/进程 |
|---|---|---|---|
| R1 | G0/0 | 12.0.0.1/24 | OSPF 1 Area 0 |
| R1 | LoopBack0 | 1.1.1.1/32 | OSPF 1 Area 0 |
| R2 | G0/0 | 12.0.0.2/24 | OSPF 1 Area 0 |
| R2 | G0/1 | 23.0.0.2/24 | RIP 1 |
| R3 | G0/0 | 23.0.0.3/24 | RIP 1 |
| R3 | G0/1 | 34.0.0.3/24 | OSPF 2 Area 0 |
| R4 | G0/0 | 34.0.0.4/24 | OSPF 2 Area 0 |
| R4 | LoopBack0 | 4.4.4.4/32 | OSPF 2 Area 0 |
为什么选这个结构？两个OSPF进程分别挂在两个边界路由器上，中间用RIP桥接，这样可以完整展示"OSPF域1 -> 重发布 -> RIP -> 重发布 -> OSPF域2"的完整链路，也能把路由回馈问题暴露得最明显。如果在同一台路由器上跑两个OSPF进程做双向重发布，虽然也能演示，但缺少了跨协议的中转环节，对LSA更新的讨论会单薄很多。
1.3 实验目标拆解
这个实验要达成三个目标，从浅到深：
第一，打通全网路由，R1能学到R4的4.4.4.4，R4能学到R1的1.1.1.1，中间经过两次重发布，这是最基础的可达性目标。
第二，在双向重发布过程中，用路由策略控制重发布方向，防止路由回馈和环路。这是实验的核心难点，很多人在这里翻车。
第三，观察和分析优化前后LSA条目的变化。我会在实验里做三件优化：外部路由改成Type 1、在ASBR上做外部路由汇总、把末端区域配置为Stub区域，每一项都会对LSA更新量产生直接影响。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 基础配置：多进程OSPF与双向重发布实现
2.1 各设备基础配置
先从R1开始，配置OSPF进程1：
code复制[R1]ospf 1 router-id 1.1.1.1
[R1-ospf-1]area 0
[R1-ospf-1-area-0.0.0.0]network 12.0.0.0 0.0.0.255
[R1-ospf-1-area-0.0.0.0]network 1.1.1.1 0.0.0.0
R2的配置稍微复杂一点，同时跑OSPF 1和RIP，注意router-id要手动指定，不要让它自动选：
code复制[R2]ospf 1 router-id 2.2.2.2
[R2-ospf-1]area 0
[R2-ospf-1-area-0.0.0.0]network 12.0.0.0 0.0.0.255
[R2-ospf-1-area-0.0.0.0]quit
[R2-ospf-1]quit
[R2]rip 1
[R2-rip-1]network 23.0.0.0
R3的配置正好是R2的镜像，进程号换成2，同时跑RIP：
code复制[R3]ospf 2 router-id 3.3.3.3
[R3-ospf-2]area 0
[R3-ospf-2-area-0.0.0.0]network 34.0.0.0 0.0.0.255
[R3-ospf-2-area-0.0.0.0]quit
[R3-ospf-2]quit
[R3]rip 1
[R3-rip-1]network 23.0.0.0
R4就很简单了：
code复制[R4]ospf 2 router-id 4.4.4.4
[R4-ospf-2]area 0
[R4-ospf-2-area-0.0.0.0]network 34.0.0.0 0.0.0.255
[R4-ospf-2-area-0.0.0.0]network 4.4.4.4 0.0.0.0
到这里，R1和R2之间的OSPF邻居能建立，R3和R4之间的OSPF邻居能建立，R2和R3之间的RIP邻居能建立，但R1学不到R4的路由，R4也学不到R1的路由，因为OSPF 1和OSPF 2之间隔着RIP，还没有做任何重发布。
这里有个细节值得注意：R2的ospf进程号是1，R3的ospf进程号是2。如果R2和R3之间那根链路改跑OSPF，它们完全可以在同一个Area 0里建邻居，因为OSPF进程号只在本地有意义。这个"进程号本地有效"的概念，是多进程理解的基石。
2.2 双向重发布的配置与原理
现在开始做重发布。R2要把OSPF 1的路由发布进RIP，同时把RIP学到的路由发布进OSPF 1；R3同理，在OSPF 2和RIP之间做双向重发布。
R2的配置：
code复制[R2]ospf 1
[R2-ospf-1]import-route rip 1 type 1 route-policy RIP_TO_OSPF
[R2-ospf-1]quit
[R2]rip 1
[R2-rip-1]import-route ospf 1 route-policy OSPF_TO_RIP
[R2-rip-1]undo summary
R3的配置：
code复制[R3]ospf 2
[R3-ospf-2]import-route rip 1 type 1 route-policy RIP_TO_OSPF
[R3-ospf-2]quit
[R3]rip 1
[R3-rip-1]import-route ospf 2 route-policy OSPF_TO_RIP
[R3-rip-1]undo summary
注意我在这里先用了route-policy占位，不要急着直接敲命令，因为双向重发布如果不加控制，立刻就会出问题。裸奔的import-route在实验里能通，但在原理上是错的。
先说为什么要在RIP里执行 undo summary。RIP默认开启自动汇总，R2把OSPF 1的路由重发布进RIP后，RIP可能会把1.1.1.1/32这样的明细路由汇总成自然分类网段，导致R3收到的是1.0.0.0/8而不是明细路由，路由丢失是小事，更麻烦的是汇总带来的路由歧义和次优路径。所以做重发布实验，第一件事就是关掉RIP自动汇总。
再说双向重发布为什么必须配合路由策略。我们来看一个典型的回馈场景：R3把OSPF 2的路由（比如4.4.4.4/32）重发布进RIP，R2从RIP学到4.4.4.4，然后R2在做RIP到OSPF 1的重发布时，会把这条从RIP学到的4.4.4.4再扔进OSPF 1。这条4.4.4.4本来应该通过"OSPF 1 -> RIP -> OSPF 2"到达目的地，结果它绕了一圈被灌回了OSPF 1，成为一个外部路由。如果OSPF 1里没有原生的4.4.4.4路由，这个回馈路由会出现在所有OSPF 1设备的路由表里，路径却经过了两次重发布，完全是次优的。
更危险的是反向回馈：R2把OSPF 1的路由（比如1.1.1.1）重发布进RIP，R3从RIP学到1.1.1.1，R3又在OSPF 2里重发布这条RIP路由，1.1.1.1就出现在了OSPF 2域内。R4学到的1.1.1.1路径是 R4->R3->R2->R1，看起来正常，但如果R3上也有一条1.1.1.1的OSPF 2内部路由（假设将来R2也接入OSPF 2），那么RIP回馈的路由和OSPF内部路由会形成环路隐患。
2.3 用route-policy控制重发布方向
正确的做法是用route-policy明确标识路由来源，并过滤掉不该进入的路由。我的做法是用tag标记。
R3上先把OSPF 2的路由重发布进RIP，打上tag 300：
code复制[R3]route-policy OSPF_TO_RIP permit node 10
[R3-route-policy-ospf-to-rip-10]if-match tag 200
[R3-route-policy-ospf-to-rip-10]deny
[R3-route-policy-ospf-to-rip-10]quit
[R3]route-policy OSPF_TO_RIP permit node 20
[R3-route-policy-ospf-to-rip-20]apply tag 300
[R3-route-policy-ospf-to-rip-20]quit
这段策略的含义是：如果路由携带tag 200（说明它是从RIP侧重发布进来的OSPF外部路由），则禁止发布进RIP，避免回馈；其他路由允许发布，并在发布时打上tag 300。
对应地，R3在把RIP路由重发布进OSPF 2时，用route-policy把tag 300的路由拦掉：
code复制[R3]route-policy RIP_TO_OSPF permit node 10
[R3-route-policy-rip-to-ospf-10]if-match tag 300
[R3-route-policy-rip-to-ospf-10]deny
[R3-route-policy-rip-to-ospf-10]quit
[R3]route-policy RIP_TO_OSPF permit node 20
[R3-route-policy-rip-to-ospf-20]apply tag 200
[R3-route-policy-rip-to-ospf-20]quit
R2上做完全对称的配置。R2从OSPF 1重发布进RIP时，打tag 200？不对，这里要仔细理一下。R2的OSPF 1侧是"源"，RIP侧是"宿"，R2上：
- OSPF 1 重发布进 RIP：允许发布，打 tag 200（表示这条路由来自OSPF 1侧）；
- RIP 重发布进 OSPF 1：过滤掉 tag 200 的路由（即不给OSPF 1的路由回馈到OSPF 1的机会），允许其他路由（包括来自R3 tag 300的OSPF 2路由）进入OSPF 1。
等等，R2从RIP收到的来自R3重发布的路由，R3打的是tag 300，R2在RIP重发布进OSPF 1时应该放行，并可以改成tag 100或者保持300。R2从OSPF 1重发布进RIP时打tag 200，R3在RIP重发布进OSPF 2时会过滤tag 200，这样OSPF 1的路由就不会绕回OSPF 2。
这样tag的流转就清晰了：
| 设备 | 重发布方向 | 动作 | tag |
|---|---|---|---|
| R2 | OSPF 1 -> RIP | 放行 | 打tag 200 |
| R2 | RIP -> OSPF 1 | 过滤tag 200，放行其他 | 保持/打tag 100 |
| R3 | OSPF 2 -> RIP | 放行 | 打tag 300 |
| R3 | RIP -> OSPF 2 | 过滤tag 300，放行其他 | 保持/打tag 100 |
这个设计让"自己的路由"不会从对方重发布回来，从机制上杜绝了路由回馈。当然，RIP本身也有水平分割和毒性反转，但那是针对RIP接口层面的防环，重发布层面的环路必须靠路由策略解决，两者不能互相替代。
配置完之后，全网路由应该全部打通。在R1上应该能看到4.4.4.4/32，在R4上应该能看到1.1.1.1/32，中间跳数经过两次重发布。验证命令：
code复制[R1]display ip routing-table protocol ospf
[R4]display ip routing-table protocol ospf
如果看不到，优先检查route-policy的匹配方向是否写反了，这是最常见的错误。
3. LSA更新量的分析与优化思路
3.1 当前LSDB里有什么问题
双向重发布配置完成后，全网是通的，但如果你用 display ospf lsdb 看一眼R4的LSDB，会发现一个问题：LSA条目很多，而且很多是"不必要"的。
在R4的OSPF 2域内，除了原生OSPF的Type 1和Type 2 LSA之外，还多了：
- Type 5 LSA：R3作为ASBR引入的外部路由，包括从RIP学到的R2侧网段、R1的1.1.1.1/32等；
- Type 4 LSA：ABR通告的ASBR汇总LSA，用来告诉区域内路由器"ASBR在哪里"；
- 如果外部路由条数多，Type 5的条目数量会直接膨胀。
这些LSA会通过OSPF的泛洪机制传播到整个OSPF 2区域。每一条LSA都有老化计时器（默认1800秒刷新一次），刷新时会产生新的LSU报文在全域泛洪。LSA条目越多，网络中的更新报文就越多，占用链路带宽、消耗设备CPU和内存。在大规模网络里，LSA泛滥是OSPF性能劣化的常见原因。
3.2 LSA更新的三个层面
要理解LSA更新量优化，需要把"更新"拆成三个层面：
第一个层面是LSDB里的条目数量。条目越多，泛洪的基础量越大。优化方向是减少进入区域的LSA条目，手段包括路由汇总、Stub区域替代普通区域、默认路由替代明细路由。
第二个层面是LSA的刷新频率。OSPF的LSA默认每1800秒刷新一次，这个机制无法关闭，但可以通过调整接口的LSA传输延迟、重传间隔、组播应答等参数，降低单位时间内网络里的LSU数量。华为设备上对应的命令在接口视图下调整，比如 lsa-arrival-interval、lsa-group-ack-interval 等。
第三个层面是SPF计算的频率。LSA发生变化后，路由器要重新运行SPF算法。如果网络频繁震荡，每次震荡都触发SPF，CPU开销会非常大。现在的OSPF实现都支持智能定时器（SPF schedule interval），可以设置初始等待时间、最大等待时间和二次等待时间，把短时间内频繁的拓扑变化合并成一次SPF计算。
这个实验里，我重点做第一个层面，也就是减少LSDB条目数量，因为它效果最直观，也最容易验证。
3.3 外部路由Type 1和Type 2对更新的影响
在重发布配置里，import-route 命令后面有个 type 参数，可以指定外部路由的类型。很多人把它当作一个"选路偏好"的开关，但它对LSA更新行为也有影响。
默认情况下，重发布进OSPF的外部路由是Type 2。Type 2路由的外部开销（metric）在ASBR上固定，不会随域内路径变化而变化。也就是说，只要ASBR到外部目标的cost不变，域内任何链路变化都不会影响这条外部路由的cost。
Type 1路由则不同，它的总开销等于"ASBR到外部目标的cost"加上"本路由器到ASBR的cost"。当域内链路状态变化时，本路由器到ASBR的cost变了，Type 1路由的总cost也会跟着变，需要重新计算。
听起来好像是Type 2更稳定、更省计算量？但实际恰恰相反，Type 2在很多场景下会导致次优路径，而且它掩盖了真实的路径开销。更关键的是，当ASBR到外部目标的链路发生变化时，Type 1和Type 2都需要更新LSA；但当域内路径变化时，Type 1能计算出精确的新路径，Type 2则可能因为cost不敏感而继续保持次优路径，直到外部链路的刷新周期到来。
我在实验里把双向重发布的外部路由都改成了Type 1，这样整网的路径开销计算更精确，配合汇总和Stub区域，能显著降低不必要的LSA条目和SPF重算。
4. 优化实操：三种手段降低LSA更新量
4.1 手段一：外部路由汇总
路由汇总是最直观的LSA瘦身手段。在没有任何汇总的情况下，假设R3重发布进OSPF 2的外部路由有4条：12.0.0.0/24、23.0.0.0/24、1.1.1.1/32、2.2.2.2/32（R2侧直连及R1环回等），每条对应一条Type 5 LSA。如果这些路由能够被汇总成一条，Type 5的条目就从4条变成1条。
在H3C设备上，外部路由汇总在ASBR的OSPF进程视图下配置，用的是 summary-address 命令。华为设备上同样是 summary-address。
以R2为例，R2把RIP路由重发布进OSPF 1，OSPF 1收到的外部路由包括R3侧网段、R4环回等。为了演示，这里我们汇总R3和R4侧的连续地址段：
code复制[R2]ospf 1
[R2-ospf-1]summary-address 3.0.0.0 255.0.0.0
这里我用了3.0.0.0/8作为一个示例汇总，如果实际地址规划更细，比如R3侧有33.1.0.0/24、33.2.0.0/24、33.3.0.0/24，可以统一汇总为33.0.0.0/22，这样一条汇总路由覆盖三条明细。
R3上同理，对外部路由做汇总：
code复制[R3]ospf 2
[R3-ospf-2]summary-address 12.0.0.0 255.255.0.0
这里要注意一个问题：汇总之后的Type 5 LSA是一条，但如果ASBR收到了一条不连续的明细路由，无法被任何汇总前缀覆盖，它就还是会单独生成一条Type 5 LSA。所以汇总的有效性取决于地址规划的连续性。做实验时，建议在一开始就把地址段设计成可汇总的结构，这样效果最明显。
汇总的额外好处是：当明细路由在RIP域内震荡时，如果震荡的网段在汇总范围内，ASBR不会因为每一条明细路由的变化都重新泛洪Type 5 LSA，只有汇总路由本身发生变化时才需要更新。这个性质对网络稳定性很有价值。
验证方式：
code复制[R4]display ospf lsdb ase
优化前如果有4条Type 5 LSA，优化后应该只剩1到2条。
4.2 手段二：外部路由改Type 1
在route-policy已经就位的前提下，把 import-route 命令里的type参数从默认的2改成1：
code复制[R2-ospf-1]import-route rip 1 type 1 route-policy RIP_TO_OSPF
[R3-ospf-2]import-route rip 1 type 1 route-policy RIP_TO_OSPF
改成Type 1后，外部路由的cost计算会包含"本路由器到ASBR的开销"。以R4为例，它看到的4.4.4.4（OSPF 2内）是内部路由，但看到的1.1.1.1/32（经R3重发布进入）是外部路由。Type 1下，R4计算1.1.1.1的总cost = R4到R3的cost + R3到外部目标的cost，路径选择更精确。
这个改动在LSDB里不容易直接"看"出数量变化，但它改变了路由计算的精度和拓扑变化时的更新行为。在路径存在多条等价链路或者ASBR到外部有多个出口时，Type 1能避免次优路径，减少因为路径切换导致的额外LSA更新。
4.3 手段三：Stub区域减少进入LSA类型
Stub区域的原理是：在OSPF里，区域间的Type 3 LSA和外部路由的Type 5 LSA是明细路由的"搬运工"，而Stub区域不允许Type 5 LSA进入，ABR会自动向Stub区域内发布一条默认路由（Type 3），区域内路由器访问外部网络时统一走默认路由，不用维护每一条外部明细路由。
注意，Stub区域还有一个限制：不能引入外部路由。这意味着Stub区域内的路由器不能是ASBR。在我们的实验拓扑里，如果要把Area 0配置成Stub，R3作为ASBR就不符合条件。所以Stub区域更适合用在纯末梢区域，比如把R4单独放在Area 1，Area 1配置为Stub，R3作为ABR，这样Area 1内的R4就不会收到任何Type 5 LSA，只保留一条默认路由。
为了让实验完整，我们可以调整一下拓扑：R3和R4之间的链路放入Area 1，R3变成ABR（同时连接Area 0和Area 1），R4就是Area 1内的纯末梢路由器。然后把Area 1配置为Stub。
调整后的配置如下：
code复制[R3]ospf 2
[R3-ospf-2]area 0
[R3-ospf-2-area-0.0.0.0]network 34.0.0.0 0.0.0.255
[R3-ospf-2-area-0.0.0.0]quit
[R3-ospf-2]area 1
[R3-ospf-2-area-0.0.0.1]network 4.4.4.4 0.0.0.0
[R3-ospf-2-area-0.0.0.1]stub
等等，4.4.4.4是R4的环回，不能在R3上宣告。这里应该把R3连接R4的接口放进Area 1，R4的全部接口都在Area 1。R3上需要把34.0.0.0/24宣告到Area 1，R4上把34.0.0.0/24和4.4.4.4/32都宣告到Area 1。
R3上Area 1配置为stub后，所有接入Area 1的路由器（包括R4）在Area 1视图下都要配置stub，否则邻居建立不起来。
R4上：
code复制[R4]ospf 2
[R4-ospf-2]area 1
[R4-ospf-2-area-0.0.0.1]network 34.0.0.0 0.0.0.255
[R4-ospf-2-area-0.0.0.1]network 4.4.4.4 0.0.0.0
[R4-ospf-2-area-0.0.0.1]stub
配置完成后，R4的LSDB里不会再有Type 5 LSA，R4访问外部网络（比如1.1.1.1）时，走的是ABR（R3）下发的默认路由。你可以对比一下配置Stub前后R4上 display ospf lsdb 的条目数，效果立竿见影。
如果区域内既需要stub的LSA隔离效果，又需要引入少量外部路由，可以改用NSSA区域，NSSA允许自身区域内的ASBR引入外部路由，以Type 7 LSA的形式存在，ABR将其转换为Type 5 LSA转发到其他区域。NSSA的整体设计比Stub复杂，这里先不展开，想深入的朋友可以单独做实验验证。
4.4 手段四：调整SPF计算与LSA泛洪计时器
在H3C/华为设备上，OSPF进程下默认启用了智能定时器，可以针对网络震荡场景做优化。相关配置：
code复制[R2]ospf 1
[R2-ospf-1]spf-schedule-interval 5 50 200
[R2-ospf-1]lsa-arrival-interval 500
[R2-ospf-1]lsa-group-ack-interval 3
spf-schedule-interval 的三个参数分别表示：初次SPF计算的延迟时间（5秒，即收到LSA变化后最多等5秒再算）、下次计算的二次等待时间（50毫秒）、如果网络持续震荡，计算间隔被拉长到最大200毫秒。这样设计的好处是，网络短时间内的多次震荡会被吸收成一次SPF计算，不至于每次都全量重算。
lsa-arrival-interval 500 表示同一LSA在500毫秒内不会被重复接受，避免因为LSA反复刷新而触发无意义的泛洪。lsa-group-ack-interval 3 表示延迟3秒对一组LSA做批量确认，减少确认报文数量。
这些参数在链路频繁up/down的现网环境中非常有用，但在模拟器里效果不明显。做实验时，可以用 display ospf cumulative 查看SPF计算次数的统计，对比调整前后的变化。
5. 验证方法与问题排查实录
5.1 优化前后效果对比
整理一个表格，直观展示优化前后的变化：
| 验证项 | 优化前 | 优化后 |
|---|---|---|
| R4 LSDB中Type 5 LSA条目数 | 4条（明细外部路由） | 1条（汇总后）或0条（Stub场景） |
| R4 LSDB中Type 3 LSA条目数 | 多条区域间明细 | 1条默认路由 |
| R4 LSDB总条目数 | 较多 | 明显减少 |
| 外部路由类型 | Type 2 | Type 1 |
| 路径选择精度 | 可能次优 | 精确匹配实际开销 |
在R4上执行 display ospf lsdb，你会清楚地看到Stub区域配置完成后，外部LSA整体消失，取而代之的是一条Type 3的默认路由。这个效果在现网里意味着区域边界路由器不需要维护大量外部明细路由，内存和CPU占用显著下降。
5.2 常见问题一：邻居建立不起来的排查
做这个实验时，最常见的坑是Stub区域配置不一致。R3的Area 1配置了stub，R4的Area 1也必须配置stub，只要有一侧没配，OSPF邻居状态就会卡在ExStart或者Exchange，DD报文来回发但就是不能同步。排查步骤：
- 使用 display ospf peer 查看邻居状态；
- 使用 display ospf error 查看是否有认证错误、区域ID不匹配等记录；
- 确认双方的stub标志位一致，这一点在配置完成后用 display ospf lsdb 查看区域内的Type 9 Opaque LSA或者直接看邻居状态最直接。
5.3 常见问题二：路由回馈导致的路由环路
如果省略了route-policy，直接做了双向重发布，可能遇到的现象是：R1上看到去往4.4.4.4的下一跳在R2方向，但R2到R3的RIP链路其实经过了两次重发布，路径不是最优的。更严重的情况是，RIP域内出现跳数持续累加的路由，直到跳数超过15被标记为不可达。
验证方法：
code复制[R1]display ip routing-table 4.4.4.4
如果发现开销异常大，或者路径绕了远路，多半是回馈路由在起作用。带上route-policy重新配置后，用 reset ospf process 重置OSPF进程，观察路由表是否恢复正常。
5.4 常见问题三：RIP自动汇总导致路由缺失
很多人在做完重发布会发现R4学不到1.1.1.1/32的明细路由，只看到1.0.0.0/8。这就是RIP自动汇总在作怪。在RIP进程下执行 undo summary 可以解决。如果问题依旧，检查RIP的版本和network宣告范围，确保接口网段被正确宣告。
华为设备上RIP默认是v2，支持无类路由和自动汇总。H3C设备默认RIP版本可能因型号而异，建议显式指定：
code复制[R2-rip-1]version 2
[R2-rip-1]undo summary
5.5 实验后的三条心得
第一，双向重发布的本质是"信任边界"的设计。重发布不是简单地把路由表倒来倒去，而是在两个路由域之间建立一条受控的通道。用tag标记路由来源，是防止回馈和环路的最简单有效的手段，远比事后靠路由优先级救火可靠。
第二，LSA更新量的优化要分层做。汇总和Stub解决的是"条目数量"问题，Type 1/2的调整解决的是"计算精度"问题，SPF定时器的调整解决的是"计算频率"问题。三者叠加，才是一个完整的外部路由LSA优化方案。
第三，模拟器里验证不出性能问题，但能验证逻辑。LSA条目数的对比在模拟器上非常直观，SPF定时器的效果在现网才明显。做实验时一定要把显示命令和统计命令用起来，display ospf lsdb、display ospf cumulative、display ospf peer 这几个命令几乎贯穿整个排查过程。
这个实验做完，你对OSPF多进程重发布的控制逻辑应该有一个很完整的认识。如果还想深入，可以在现有拓扑上把RIP替换成IS-IS，或者把外部路由改成NSSA区域验证Type 7 LSA的转换行为，又是一轮新的实验。