1. 先把场景摆出来：区域间路由为什么要单独算一遍
1.1 一个两区域拓扑和它暴露出来的问题
假设手上有四台设备，R1 在骨干区域，R3、R4 挂在另一个区域里，R2 夹在中间，一台设备两块网卡，一边插骨干区域，一边插非骨干区域。每台设备跑 OSPF，接口按网段使能，几行配置下去邻居全起来了，区域内的路由一两秒就收敛干净。这时候去看 R3 的路由表，会发现几条标着O IA的东西：1.1.1.1/32、10.0.12.0/30都从 R2 那个方向学过来，而 R3 本地所在区域里的网段标的是O。同一台设备、同一个协议，两个完全不同的前缀标识，背后是两条完全不同的计算路径——O是区域内路由，靠 Type 1 和 Type 2 做标准 SPF 算出来的；O IA是区域间路由，靠 Type 3 做一次"基于距离矢量思想的补充计算"得出的。
OSPF 区域间路由计算这个主题，说白了就一句话：ABR 把自己区域里学到的路由，翻译成 Type 3 LSA 转述给别的区域，接收方在 SPF 树上再加一段开销。但真要落到排错和规划设计上，中间那些细节——ABR 凭什么资格发 Type 3、Type 3 里到底装了几个字段、Cost 怎么累加、为什么要绕骨干区域一圈——每一条都能让线上出问题。我用这套机制处理过园区互联、机房之间的汇聚打通、多厂商设备对接的边界路由，也见过太多"区域间路由不通"最后发现是 ABR 资格不成立、或者 Type 3 被汇总规则吞掉的案例。
这篇内容适合三类人看：刚学完 OSPF 基础、对O IA一脸茫然的入门者；要在多区域网络上做规划、算 Cost、做汇总的运维；以及排查过区域间路由但始终没搞清 Type 3 传播边界的老手。需要提前说明的是，下面所有配置命令统一采用常见网络设备的通用命令行语法，输出示例是模拟的，重点看机制和判断逻辑，换任何一家设备，命令名字不一样，行为是一样的。
1.2 区域划分不是为了省 CPU，是为了把变化关进笼子
很多人对区域的理解停留在"设备太多 SPF 算不动所以分区"，这个说法对但只是表层。真实的生产环境里，区域设计的核心价值是把拓扑变化的传播范围压到最小。骨干区域里某条链路抖了三秒，如果全网一个区域，那么每一台设备的 LSDB 都要更新、每一台设备都要重跑一次 SPF；但如果那台抖动的设备在区域 2 里，只有区域 2 内的设备跟着重算，其他区域只看到 ABR 发来的一条 Type 3 变化，甚至如果做了汇总，连 Type 3 都不用发。
这个设计带来一个必然的副作用：区域内是链路状态，区域之间被迫退化成距离矢量。为什么会这样？因为在区域间传递完整拓扑的意义不大，其他区域里的设备对骨干区域内部长什么样并不关心，它只需要知道"往哪个 ABR 走、大概多远"。Type 3 就是承载这个"大概多远"的载体，它只有前缀、掩码和一个 Metric，没有任何拓扑描述。这也解释了为什么 OSPF 区域间天然存在一条隐含规则：非骨干区域之间的流量必须穿过骨干区域，因为区域间的路径信息只在 ABR 和骨干那一层汇总，非骨干区域之间压根没有互通的通道。
我在实际规划里踩过的一个坑：早期为了省事，把两个分支区域直接用一个区域号打通，指望分支之间直接通信，结果发现路由怎么都不通。原因很简单，两台 ABR 之间如果没经过骨干区域，那条 Type 3 传不过去——发出去也没有地方承载。后来老老实实把骨干区域延伸到中间的互联链路，通信立刻正常。这个事的教训是，区域号不是标签，是路径结构的一部分，画拓扑的时候先想清楚谁在骨干、谁是非骨干，再动笔配。
2. Type 3 LSA 到底装了什么：ABR 的"转述"逻辑
2.1 从 Router LSA 到 Network Summary LSA 的翻译过程
一个 ABR 的脑子里有两份账本：一份是它所在各个区域的 LSDB，另一份是它自己算出来的路由表。生成 Type 3 的过程，本质上是"拿着路由表去写公告"：遍历自己通过区域内路由学到的每一条前缀（标记为O的那些），为每一条生成一个 Type 3 LSA，发给除了源区域之外的其他连接区域。
这里关键词是"除了源区域"。一条在区域 1 里学到的路由，ABR 不会把它的 Type 3 又发回区域 1——发了也没有意义，区域 1 里的设备本来就有一条更精确的区域内路由。更严格地说，ABR 只对**区域内路由（O）**生成 Type 3，对于它从其他区域学来的区域间路由（O IA），以及从外部引入的路由（O E1/E2），都不会再生成 Type 3 往外发。这条规则是防环的第一道闸门，后面还会细讲。
Type 3 LSA 就三个关键字段值得盯：
| 字段 | 含义 | 实际影响 |
|---|---|---|
| Link State ID | 目的网络的地址（不是网络号+掩码的组合） | 同一地址配不同掩码会生成多条 LSA，收敛时容易紊乱 |
| Advertising Router | 发出这条 Type 3 的 ABR 的 Router ID | 多 ABR 场景下，同一个前缀会有多条 LSA，靠它区分来源 |
| Network Mask / Metric | 掩码和到达该前缀的开销 | Metric 是 ABR 从自己出发算出来的距离，接收方要在此基础上再加 |
Link State ID 这个字段是老版本设备最坑的地方。早期 OSPF 实现里，如果 Type 3 不携带掩码，接收方只能按有类地址推断，10.0.1.0/24会被当成10.0.0.0/8，路由表里就会出现一条范围巨大、指向错误位置的条目。现在的设备基本都在 LSA 体里塞进了 32 位的 Network Mask 字段，但这条历史遗留提醒我们一件事：如果对接的低版本实现出现前缀范围异常，先去看这条 LSA 的掩码字段是否有效，而不是去怀疑 SPF 算法。
2.2 ABR 的判定资格：配了两个 area 不等于就是 ABR
这是我见过最高频的误判。很多人在一台设备上配了area 0和area 1，接口都使能了 OSPF，就默认它是 ABR，结果 Type 3 一条没发出去，区域间路由全是空的。
ABR 的成立有硬条件：必须至少有一个处于 UP 状态且参与 OSPF 的接口在骨干区域（area 0）里，同时至少有一个处于 UP 状态且参与 OSPF 的接口在其他区域。两个条件同时成立，设备才被认定为 ABR，才会为那些非骨干区域生成 Type 3。
实践里踩的坑通常有三种形态。第一种是骨干区域的接口 LO 了或者被关掉了，设备只剩 area 1 和 area 2 两个接口，配置上写着 area 0 但那个接口不 up，ABR 资格直接失效，整片区域的区域间路由全断——这种故障很隐蔽，因为邻居关系可能看起来都正常。第二种是骨干区域的接口网段被别人静默抑制了，silent-interface一开，接口还在 up 但 OSPF 不参与，同样丢资格。第三种是骨干区域只靠一条虚连接维持逻辑上连通，物理上没有任何接口落在 area 0 里，某些实现里 ABR 的判定会更严格，不认这种虚拟连接。
注意：排查"区域间路由不通"的时候，第一件事不是看 LSDB，是在 ABR 上看它到底被识别成了什么角色。绝大多数平台的邻居明细或 OSPF 概要里会直接告诉你这台设备是不是 ABR，如果那里写着不是，后面所有 LSA 分析都是白费。
所以我给别人做培训时经常强调，判断 ABR 不要看配置，要看状态。配置只表达意图，状态才代表结果。
2.3 Type 3 的生成粒度：一条路由一条 LSA
Type 3 是按前缀逐条生成的，不是按区域汇总生成。区域 1 里有 20 条网段，ABR 就会向区域 0 生成 20 条 Type 3；如果这个 ABR 同时连着区域 2，那区域 2 也会收到这 20 条。这意味着一个大规模网络里，如果不对区域做汇总，骨干区域的 LSDB 里会堆满 Type 3，ABR 的 CPU 和内存都跟着遭殃。
这也是为什么汇总（area range）在区域间设计里不是可选项而是必选项。汇总之后，20 条 Type 3 会被压成 1 条覆盖它们的大网段，Metric 取这 20 条里最小的那个开销。这个取最小值的细节很重要，它意味着汇总之后的路径选择可能变得不精确：如果这 20 条网段的真实开销差异很大，汇总之后所有流量都会走向开销最小的那个方向，即便某些流量原本应该走另一条路。
我做过一个跨机房的网络，两个机房通过双 ABR 互联，每个 ABR 后面挂着上百个网段，为了控制 LSA 数量做了大范围汇总，结果发现从某个方向过来的流量全挤在一条链路上。查到最后就是这个"取最小 Metric"的问题——汇总把两条链路的开销差异抹平了，SPF 只能选一条。最后的解法是把汇总粒度切细一点，按业务分成两三个汇总段，让流量跟着各自的 Metric 分布走。汇总的范围越大，选路的精度就越低，这个取舍需要在设计阶段就定下来。
3. 路由计算全过程：接收方怎么把 Type 3 变成 O IA
3.1 区域间 SPF 和区域内 SPF 不是一回事
区域内的 SPF 是完整的最短路径树计算：设备手里有全区域的链路状态，跑 Dijkstra，算出到每个节点、每条网段的最短路径。区域间的计算是另一套逻辑，叫区域间路由计算，它的流程是：
- 先用区域内的 SPF 算出到自己区域内每个 ABR 的最短路径开销；
- 遍历 LSDB 里所有的 Type 3 LSA，对每条 LSA 找到它通告的那个 ABR；
- 把"本设备到该 ABR 的开销"加上"LSA 里携带的 Metric"，得到这条区域间路由的总开销；
- 如果同一个前缀有多条来自不同 ABR 的 Type 3，就比较各自的总开销，选小的。
关键在第 3 步和第 4 步。接收方做的是"加法"而不是"重算"，它不需要知道 ABR 那边拓扑长什么样，只需要知道"我到那个 ABR 多远"和"那个 ABR 离目的多远"。这两段一加，就是一条粗略但有效的路径。
所以在 R3 上看路由表，看到O IA 1.1.1.1/32 [110/20]，这个 20 拆开就是：R3 到 R2 的接口开销 10，加上 R2 通告的 Type 3 里携带的 Metric 10（R2 到 R1 环回口的开销）。如果有人问你"这个 20 是怎么来的"，答案是两段加出来的，而不是 SPF 直接算出来的，这个区别在排错时非常关键。
3.2 Cost 的累加规则和一次实测
默认参考带宽 100 Mbps 的设定下，千兆接口的 cost 是 1，两条千兆链路加起来的差异根本体现不出来，看路由表完全分不清路径。为了让计算过程可见，实验环境里通常把参考带宽调到 10 Mbps，让千兆口 cost 变成 10，这样每一跳的开销一眼就能对上。
| 链路 | 带宽 | 参考带宽 100M 下 cost | 参考带宽 10M 下 cost |
|---|---|---|---|
| R1—R2 | 1 Gbps | 1 | 10 |
| R2—R3 | 1 Gbps | 1 | 10 |
| R3 环回口 | — | 0（环回口固定按 1 计算部分实现有差异） | 同上 |
在参考带宽 10M 的环境里，R3 学到的1.1.1.1/32开销是 20，R2 学到的开销是 10，R1 本地是 0。三台设备上同一条前缀的开销依次递减，这个递减关系可以当作一条经验法则来记忆：同一条前缀在不同区域的路由器上，开销只会沿着传播方向单调增加。如果发现某台设备的开销反而比上游小，那一定是收到了别的 ABR 发来的 LSA，或者本地有更优路径，不要去怀疑加法算错了。
另外一个容易忽略的点：Type 3 LSA 里的 Metric 是 ABR 为它计算的区域内开销，不是接口带宽的原始值。如果 ABR 后面的路径做了汇总，或者是通过虚连接学到的，Metic 的语义会变。看 LSDB 的时候不要拿它跟物理链路带宽直接对比。
3.3 多 ABR 场景下的选路：同一条前缀，两条 LSA
真实网络里，一个非骨干区域通常有至少两台 ABR 挂在骨干上，目的是冗余。这时候区域内的路由器会收到同一个前缀的两条 Type 3，Advertising Router 分别是两个 ABR 的 Router ID。
选择逻辑仍然是最短总开销。假设 R3 到 R2 开销 10、到 R5 开销 20，R2 通告的 Metric 是 10、R5 通告的 Metric 也是 10，那 R3 选 R2 方向，总开销 20。但如果 R5 那条路径的 Metric 是 5（比如 R5 的骨干侧链路更短），总开销变成 25，仍然选 R2。要是把 R3 到 R5 的链路换成短链路，开销降到 5，那 R5 就反超了。
这里有个细节值得注意：两条 Type 3 只有 Metric 不同、其他都一样时，设备不会做负载均衡，只会选小的。要形成等价多路径，需要两个方向的总开销完全相等，并且设备的 ECMP 数量上限允许。我在做双 ABR 冗余的时候就吃过这个亏，两台 ABR 的骨干侧链路带宽不一样，收敛之后永远只有一条路径承载流量，另一条完全闲置。后来把两条链路的开销人为调平（改参考带宽或者手工设 cost），才实现真正的分流。
还有一种更麻烦的场景：两个 ABR 之间的骨干区域内部有高开销链路，导致同一个目的地在两台 ABR 上算出的区域内 Metric 不一样。这时候如果骨干区域内部出现抖动，Type 3 的 Metric 会跟着变，非骨干区域的路由就会来回切换。做设计时尽量让骨干区域的链路开销扁平化，能减少这种"路由乒乓"。
4. 动手做一遍：两区域拓扑的配置与验证
4.1 地址和区域规划
拓扑很简单：R1 在 area 0，R2 是 ABR 同时连 area 0 和 area 1，R3、R4 在 area 1。规划如下：
| 设备 | 接口 | 地址 | 区域 |
|---|---|---|---|
| R1 | 环回 | 1.1.1.1/32 | area 0 |
| R1 | 连 R2 | 10.0.12.1/30 | area 0 |
| R2 | 连 R1 | 10.0.12.2/30 | area 0 |
| R2 | 连 R3 | 10.0.23.2/30 | area 1 |
| R3 | 连 R2 | 10.0.23.3/30 | area 1 |
| R3 | 连 R4 | 10.0.34.3/30 | area 1 |
| R4 | 连 R3 | 10.0.34.4/30 | area 1 |
| R4 | 环回 | 4.4.4.4/32 | area 1 |
四台设备的 Router ID 分别定为 1.1.1.1、2.2.2.2、3.3.3.3、4.4.4.4，用环回口地址更稳，别用物理口地址，接口一抖 Router ID 变了整片 LSA 全要重来，这个教训值得单拎出来说一遍。
参考带宽统一改成 10 Mbps，让千兆链路 cost = 10，这样算出来的数字好看也好看懂。这个操作在所有设备上都要做，不一致会导致同一条链路两端算出的开销不同，路由看起来莫名其妙。
4.2 逐台配置，只写关键部分
R1 的配置最干净，一个区域两个网段：
router ospf 1 router-id 1.1.1.1 auto-cost reference-bandwidth 10 network 1.1.1.1 0.0.0.0 area 0 network 10.0.12.0 0.0.0.3 area 0R2 是重点，它是唯一的两区域设备：
router ospf 1 router-id 2.2.2.2 auto-cost reference-bandwidth 10 network 10.0.12.0 0.0.0.3 area 0 network 10.0.23.0 0.0.0.3 area 1注意 R2 的环回口没有使能 OSPF，这是故意的，避免引入额外变量。R3 和 R4 都只在 area 1 里：
router ospf 1 router-id 3.3.3.3 auto-cost reference-bandwidth 10 network 10.0.23.0 0.0.0.3 area 1 network 10.0.34.0 0.0.0.3 area 1R4 按同样的方式配，加上环回 4.4.4.4。配置完等邻居全 Full，这一步别急着看路由，先确认 R2 被识别成 ABR，这是整件事的前提。
4.3 看 LSDB 和路由表，把每个数字对上台
在 R3 上看区域 1 的 Type 3：
show ip ospf database summary OSPF Router with ID (3.3.3.3) Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum 1.1.1.1 2.2.2.2 120 0x80000001 0x00A1B2 10.0.12.0 2.2.2.2 120 0x80000001 0x00C3D4两条 Type 3，都是 R2 发的，分别对应 R1 的环回口和 R1-R2 的那个互联网段。R2 自己在 area 0 里学到的路由，被翻译成了两个公告。这里能看出一个规律：区域 1 里的设备看不到 R1 的 Router LSA，只能看到 R2 转述的这两条摘要。如果 R1 又新增了一个网段，R2 会多出一条 Type 3，R3 收到之后只是新增一条路由，SPF 树不变，这正是分区带来的好处。
接着看 R3 的路由表：
show ip route ospf O IA 1.1.1.1/32 [110/20] via 10.0.23.2, 00:03:21 O IA 10.0.12.0/30 [110/20] via 10.0.23.2, 00:03:21 O 10.0.34.0/30 [110/10] via 10.0.34.4, 00:01:02两条O IA的开销都是 20，拆开看：R3 到 R2 的接口开销 10，加上 Type 3 里带的 Metric 10。区域内那条10.0.34.0/30标着O，开销 10，因为 R3 和 R4 直连，一跳就到。
再看 R2 自己的路由表，1.1.1.1/32应该标O，开销 10，因为 R2 和 R1 是同区域。同一条前缀在 R2 上是 O、在 R3 上是 O IA，这个对比最能说明区域边界在哪里起作用。
4.4 抓包看 Type 3 的传播范围
这一步很多人跳过，但我觉得特别值得做。在 R2 和 R3 之间的链路上抓包，过滤 OSPF 的 LSA Update，会看到 R2 周期性发送的 Type 3。再把抓包口换到 R1 和 R2 之间的链路上，看不到任何指向 area 1 的 Type 3。这就是前面说的"不发回源区域"。
更进一步，在 R2 上查 area 0 的 Type 3 数据库，会发现里面也有 Type 3——那是别的 ABR 发来的（如果拓扑里有），或者为空。R2 只把 area 1 的路由翻译成 Type 3 发给 area 0，把 area 0 的路由翻译成 Type 3 发给 area 1，两头都要发，但都不往源区域发。
这个实验做一遍，比看十页文档都管用。我当时第一次做的时候盯着抓包结果看了半天，才真正理解"ABR 是双向翻译官，但翻译完只给对面看"。
5. 防环机制：三道闸门一个都不能少
5.1 第一道闸门：Type 3 不会跨区域再转述
前面提过，ABR 只对区域内路由（O）生成 Type 3。也就是说，如果 R2 从 area 0 学到了 R1 的1.1.1.1/32（标记为 O），它可以发给 area 1；但假如 area 1 里还有第三个 ABR（比如 R3 也连着另一个区域 area 2），R3 从 area 1 学到的是 R2 发的 Type 3（标记为 O IA），它不会再为这条 O IA 生成新的 Type 3 发给 area 2。
这条规则斩断了一个很典型的环路：区域 A 的路由经过 ABR 传到区域 B，再从区域 B 传回区域 A。如果没有这条限制，一条路由可以在多个区域之间无限转述，Metric 一路累加，最后形成一条永远追不到源头的路径。
实际影响是什么？一个非骨干区域里的路由，最多只能被传到骨干区域和这个 ABR 直接相连的其他区域，再远就断了。这也是为什么跨多个非骨干区域的网络必须靠骨干区域中转，不能绕行。
5.2 第二道闸门：非骨干区域之间必须穿过骨干
这条规则的表述有点绕，但理解起来不难：一个非骨干区域（区域号不为 0）的路由信息，必须经过骨干区域，才能到达另一个非骨干区域。物理上两个非骨干区域之间哪怕有直连链路，只要这条链路不在 area 0 里，路由就是过不去。
原因还是回到 LSA 的传播路径上：区域 1 的路由被 ABR 翻译成 Type 3 之后，只能进入 area 0 或者和这个 ABR 直接相连的其他区域。要从区域 1 到区域 2，路径必须是"区域 1 的 ABR 发到 area 0，再由另一个 ABR 从 area 0 发到区域 2"。中间那个 area 0 是必经的枢纽。
生产里最常见的应对方式是用虚连接在两个 ABR 之间打一条逻辑链路，让它们能在 area 0 里对话。但虚连接本质上是把一条物理链路"借"给骨干用，传输路径仍然依赖底层的非骨干区域，稳定性差，我一般只把它当临时方案，真正要长期跑的话还是把物理架构改成星型，让所有区域都能直连骨干。
5.3 第三道闸门：路由优先级和 LSA 类型的顺序
一台路由器从不同途径学到同一条前缀时，OSPF 内部有个明确的优先级：区域内路由（O）> 区域间路由（O IA）> 外部路由（E1/E2）。这个规则保证了当一条前缀既在区域内能学到、又能通过 Type 3 学到时，永远选区域内的那条，因为区域内的信息更精确、更可靠。
这个规则的重要性在于它化解了一种冲突：如果某台设备在一个区域内有一条指向10.0.1.0/24的路由，同时它的 ABR 又从别的区域发来这个前缀的 Type 3，它不会在两条路由之间犹豫，直接选区域内的。这个机制配合前两道闸门，基本可以把区域间的环路风险压到很低。
不过有个例外要提醒：如果 Type 3 的掩码比区域内的路由更精确，那就会走 Type 3。比如区域内有一条10.0.0.0/16，ABR 从其他区域发来一条10.0.1.0/24的 Type 3，两条同时进路由表，各自按最长匹配生效。设计汇总的时候要留意这个，汇总出来的大网段和区域内的小网段可能形成重叠，出现流量走偏。
6. 常见问题排查实录
6.1 一张速查表先扫一遍
区域间路由出问题，绝大多数就那几个成因。我把处理过的案例整理成一张表，先按现象定位方向，再深入看具体模块：
| 现象 | 高概率原因 | 第一动作 |
|---|---|---|
| 区域间路由一条都没有 | ABR 资格不成立，或骨干区域接口未 UP | 确认设备是否被识别为 ABR |
| 部分前缀有、部分没有 | 汇总或过滤规则吞掉了 | 查 area range 和 filter-list |
| 路由存在但 ping 不通 | 目的区域的 Router LSA 没传到，或往返路径不对称 | 两端接口和路由表对查 |
| 开销异常大 | 参考带宽不一致，或路径绕行 | 核对各设备的参考带宽配置 |
| 双 ABR 场景只有一条路径 | 两条路径 Cost 不等，或 ECMP 上限为 1 | 查链路开销和 ECMP 配置 |
| 汇总后流量全走一条链路 | 汇总取最小 Metric 导致选路粗化 | 细化汇总粒度或调整链路开销 |
| 骨干区域抖动导致路由翻动 | 骨干区域内部链路开销不均 | 扁平化骨干区域链路开销 |
6.2 三个典型踩坑现场
第一个坑：路由在 LSDB 里有，但路由表里没有。有一回在 R3 上查 LSDB，Type 3 明明躺着，路由表里就是没有对应条目。查了半天发现是这条 LSA 对应的前缀跟本地一条更精确的直连路由冲突了——本地有个10.0.23.0/30的直连网段，ABR 发来的汇总路由是10.0.0.0/16，虽然汇总路由存在，但本地已经有更精确的匹配，路由表里显示的是直连那条，属于正常现象。如果确实需要用汇总路由覆盖，得先把汇总的掩码调细。LSDB 里有不代表路由表里会显示，这个区别在排查时经常被忽略。
第二个坑：加了汇总之后，区域间路由消失了。这个更吓人。原因通常是汇总的命令配在了错误的设备上，或者汇总的网段范围跟实际前缀不匹配。汇总（area 1 range）只能在连接该区域的 ABR 上配置，配置的网段必须能覆盖该区域内的所有明细路由，否则不匹配的那些明细照样逐条发出去，而匹配的那些被汇总成一条，看起来就像"少了一部分"。还有种情况是汇总的掩码写得太粗，比如把几条10.1.x.x的路由汇总成10.0.0.0/8，结果骨干区域里多出一条范围巨大、却指向不存在的地址的建议路由，两边都不对。
第三个坑：完全末梢区域（Totally Stubby）把区域间路由全掐了。有些网络为了压缩 LSDB，把非骨干区域配成完全末梢，ABR 只向该区域下发一条默认路由，其他 Type 3 全部被过滤掉。这个行为的后果是，该区域内的设备只能靠默认路由出去，如果网内存在两条以上出口，选路就是瞎猜。我在一个园区网里见过这种配置，分支机构的设备全部用默认路由指向上级，结果某条链路故障时流量不会自动切换到另一条，因为默认路由只有一条。
6.3 汇总和过滤的正确姿势
汇总和过滤是区域间路由优化的两个主要手段，用对了能省大量 LSA，用错了能让网络瘫一片。
汇总的规则是：在 ABR 上、针对某个源区域配置，作用是对该区域内的明细路由做聚合，然后以聚合后的形式通告给其他区域。命令形态是area 1 range 10.1.0.0 255.255.0.0。注意两个细节：只对 Type 3 生效，该区域内部的设备看到的还是明细路由；汇总的网段必须是覆盖所有明细的超网，写错网段不会报错，但汇总不生效。
过滤的规则是：在 ABR 上按进入或离开区域的 Type 3 做过滤。生产里常用的是把某些前缀挡在区域外面，比如把测试网段挡在生产区域之外。过滤的副作用是被过滤的前缀彻底消失，不会留下任何默认路由，所以过滤之前一定要确认被挡掉的流量有别的出路。
注意：汇总和过滤的组合很容易造成"以为过滤了实际上没过滤"的情况。汇总先生效、过滤后生效的情况下，如果你按明细前缀做过滤，而汇总已经把这些明细合成了一个大网段，那过滤规则就匹配不上了。要么先过滤后汇总，要么直接针对汇总后的网段做过滤。
还有一个我自己的习惯：任何汇总或过滤上线之前，先在实验环境里用同样的拓扑把命令跑一遍，看路由表的变化，再动生产。这些命令不像接口配置那么直观，改错一行可能让一整片区域的业务中断，代价太大。
7. 几个能省时间的工程习惯
第一件事是把 Router ID 固定成环回口地址，并且在所有设备上显式配置。默认选举会选最大的接口地址，一旦物理口地址变化，Router ID 跟着变，这个 ABR 发出去的所有 Type 3 的 Advertising Router 都会变，非骨干区域的设备要重新收敛一遍。做规划的时候把 Router ID 当基础设施一样管起来。
第二件事是参考带宽全网统一。这个参数默认是 100 Mbps，千兆链路全变成 cost 1，手工调链路开销时又跟它对不上，两边加出来的总开销经常出现对不上的情况。统一改成 10 Mbps 或者 1000 Mbps，视网络规模定，然后所有设备一致。这个小动作能省掉大量"这个开销怎么算出来的"的疑问。
第三件事是给区域的 Type 3 数量设一个观察指标。骨干区域的 LSDB 里，Type 3 的数量大约等于所有非骨干区域的明细网段数之和，一旦这个数字突破几百条，就该考虑上汇总了。我习惯在监控里把 Type 3 的数量趋势画出来，某次发布之后它突然翻倍，八成是某个区域新加了一批网段但忘了做汇总。
第四件事是梳理清楚"谁是 ABR"这张名单。区域间路由的行为完全由 ABR 决定，一台设备是不是 ABR、它的骨干接口是否稳定、它的汇总规则是什么，这些信息应该在网络文档里写死。故障时的第一句话往往是"查一下 ABR 现在还是不是 ABR"，有了这张名单，定位速度能快好几倍。
最后提一个容易被忽略的点：老设备或者打过补丁的实现里，Type 3 对同一条前缀可能同时存在多条来自同一 ABR 的实例，收敛时会短暂出现两条路由。这不是配置错误，是时序问题，等收敛完成就消失了。如果持续存在，那才需要去查是不是有重复的区域配置或者接口双 IP 冲突。
说回最开始的那台 R3，它现在路由表里1.1.1.1/32那条O IA开销 20，只要 R2 不失去 ABR 资格、area 0 不挂、汇总规则不改，这条路由就会一直稳定地待在那里。区域间路由这套机制的美感就在这儿——它用一个简单的前缀加开销，把复杂的骨干拓扑屏蔽在边界之外，让每个区域各自安好。只要ABR守好门，其余设备就不必关心门外的世界。
