H3C多区域OSPF配置与排障：区域划分、LSA与LSDB实战

“区域”这两个字，很多人第一次敲OSPF配置的时候，是把它当成一个必填字段随手填上去的，等网络从五台设备扩到三十台、五十台，才发现当初把全部接口都塞进 Area 0 有多难受——链路一抖，全公司的路由表跟着重算，运维群里一片问号。H3C 设备上的多区域 OSPF 基本配置，命令层面真的不复杂，ospf 1 router-id、area、network三件套敲完，邻居就起来了；真正让人在凌晨割接窗口前反复确认的，是另外几件事：哪个接口该划归哪个区域、ABR 上到底要宣告哪些网段、三类 LSA 为什么没按预期出现、路由表里明明有跨区域路由但业务就是不通。这篇内容就是围绕这些落地点展开的，从区域划分的底层逻辑讲到五台设备的完整配置、LSDB 的逐条解读、排障时反复踩到的坑，再到区域间汇总和虚连接这类让网络跑得更省心的操作。刚接触 OSPF 的读者可以照着拓扑一步步敲，已经能配通单区域但被多区域卡住的朋友，可以直接跳到 LSA 和排障那两节找答案。

1. 先把区域划分的逻辑想明白，比敲命令重要

1.1 单区域跑久了会撞上的三堵墙

单区域 OSPF 在实验室里几乎无懈可击，五台设备、十来条链路，拓扑一画、命令一敲，收敛速度快得让人舒服。但只要网络规模上去，问题会从三个方向冒出来，而且大多是渐进式的，前期根本察觉不到。

第一堵墙是 LSDB 的膨胀。OSPF 是链路状态协议，同一个区域内每台路由器都持有完全一致的拓扑数据库，任何一条链路的状态变化都会触发泛洪。区域内设备数量和链路数量增加，每台设备要维护的 LSA 条数就线性上涨，SPF 计算的输入规模也跟着涨。二十台设备的时候无所谓，两百台的时候一次接口翻动就可能让一台中低端设备的 CPU 冲到百分之七八十。

第二堵墙是故障域的失控。单区域意味着所有链路共享同一个拓扑视图，一条本来只影响某个楼层的链路抖动，会像涟漪一样扩散到整个域，所有路由器都要重算最短路径树。业务部门感知不到原理，只会反馈“网络又卡了一下”，而运维这边翻日志翻到眼花。

第三堵墙是路由策略缺乏落点。所有网段混在一起，想做汇总、想做过滤、想把某些网段挡在外面，都没有天然的边界可用。区域边界恰好提供了这样一个抓手，ABR 天然就是策略执行点，问题是你得先把区域切出来。

1.2 骨干区域为什么必须是连续的

区域划分有一条铁律：所有非骨干区域都必须直接或间接连接到骨干区域 Area 0，而 Area 0 本身必须连续。这条规则不是厂商的规定，而是 OSPF 协议用来防环的底层设计。

原因在于路由信息的传递方式。区域内的路由靠 Type 1、Type 2 LSA 描述真实拓扑，走 SPF 算法算出来，路径是确定的。但跨区域路由不是这样传的，ABR 把区域内的路由换算成 Type 3 汇总 LSA 通告出去，接收方只是简单地“照着 ABR 说的地址加一条路由”，中间没有拓扑计算，本质上变成了距离矢量行为。距离矢量协议天生有环的风险，OSPF 用“所有区域间路由必须穿过骨干区域”这条规则把环路掐死——信息只能从普通区域上到 Area 0，再从 Area 0 下到另一个普通区域，不允许在两个非骨干区域之间直接横向传递。

这条规则带来一个实践上的约束：如果你的物理拓扑里，某个区域被其他区域隔开、够不着 Area 0，那就配不通。常见的补救手段是虚连接，把一条穿越普通区域的逻辑链路“伪装”成骨干链路，后面会单独讲。另一种做法是重新规划区域，让骨干区域物理连续，这是更干净的选择，但往往受限于现网布线，改造窗口不好排。

顺带提一句，ABR 的定义里有两个条件必须同时满足：至少一个接口在骨干区域，且至少一个接口在其他区域。只满足一个的不算 ABR，不会产生 Type 3 LSA。很多“配了但没生效”的问题，根源就是设备压根没成为 ABR。

1.3 实验拓扑与地址规划

动手之前,把拓扑和地址先钉死,后面所有命令都围绕这张表来。这套规划用的是五个私网网段加五台路由器,规模不大但足够覆盖多区域的三个关键场景:骨干与非骨干的对接、一台设备同时挂两个非骨干区域、以及跨两个区域的端到端可达性验证。

拓扑结构是这样的:R1 位于 Area 0,R1 和 R2 之间用 10.1.12.0/24 互联;R2 是第一个 ABR,一側接 Area 0,一側接 Area 1;R3 是第二个 ABR,同时连接 Area 1 和 Area 2;R4 位于 Area 2。每台设备再加一个 Loopback 口作为 Router ID 和稳定性测试目标。

这张表里,192.168.1.0/24 是 Area 0 的业务网段,192.168.3.0/24 是 Area 1 的业务网段,192.168.4.0/24 是 Area 2 的业务网段。验证目标很简单:R1 的 Loopback 能 ping 通 R4 的 Loopback,反方向也一样,同时每条跨区域路由在路由表里都能找到对应的 Type 3 LSA 来源。地址规划特意让每个互联网段的前两段保持一致、只有最后一段区分,敲命令时不容易串行。

提示:实验环境用 10.x 和 192.168.x 这类私网地址,如果要在现网操作,务必先核对地址规划表,把区域归属和网段对应关系写在纸上贴在显示器边上,比记在脑子里靠谱得多。

2. 敲命令前先定三件事:Router ID、宣告方式、开销基准

2.1 Router ID 的选择与稳定性

Router ID 在 OSPF 里不只是一个名字,它是选举 DR、标识 LSA 产生者、建立邻居关系的唯一依据。两台设备的 Router ID 撞车,邻居根本建不起来,日志里会直接报冲突。所以第一步就是把它规划好,而不是交给设备自己选。

H3C 设备的默认行为是:如果手工指定了 Router ID,就用指定的;如果没有,从所有接口地址里挑最大的那个。这个“自动挑选”在实验环境里省事,在生产环境里是隐患——你把某个大地址的接口删了,Router ID 会重新选,OSPF 进程跟着重启,全网邻居重建。所以我的习惯是永远手工指定,而且用 Loopback 地址,因为 Loopback 永远不会 down。

配置写法是在进程视图下带参数:

[R1] ospf 1 router-id 1.1.1.1

这里1是进程号,本地有效,不要求全网一致,但对多进程场景要留出扩展空间。router-id后面跟点分十进制地址,建议和 Loopback 地址保持一致,方便记忆和排障。如果设备已经在运行且 Router ID 需要改,必须重置进程才会生效,reset ospf process会造成短暂断网,务必安排在窗口期。

注意:Router ID 冲突的典型现象是邻居反复 Up/Down,display ospf peer里看到对方状态来回跳,同时日志区出现 Router ID 冲突提示。遇到这种反复抖动先别怀疑链路,先查两台设备的 Router ID 是不是撞了。

2.2 network 与 interface 两种宣告方式的取舍

H3C 支持两种把接口纳入 OSPF 的方式,一种是在进程视图下用network命令,另一种是直接进接口敲ospf 1 area 0。两种方式最终效果一样,但操作手感和出错概率差别不小。

network方式的写法是网段加反掩码:

[R1-ospf-1] area 0 [R1-ospf-1-area-0.0.0.0] network 10.1.12.0 0.0.0.255

反掩码这个概念新手最容易绕进去。它和子网掩码是反着来的,掩码里 1 表示网络位,反掩码里 0 表示要匹配的位、1 表示不关心的位。24 位掩码对应的反掩码就是0.0.0.255。想精确匹配单个地址,用0.0.0.0 255.255.255.255。想一次性匹配一大片,反掩码就往后缩,但缩得越狠风险越大,一不小心把不该宣告的网段带进来了。

接口方式更直观:

[R1-GigabitEthernet0/1] ospf 1 area 0

这行命令的意思是“这个接口参与 1 号进程的 0 区域”,所见即所得,删接口配置时也不会误伤别的网段。缺点是批量操作时要在多个接口之间来回切,而且接口删了配置也跟着没,回滚时要重新想。

我个人的取舍是:互联链路和点对点接口用接口方式,业务网段和 Loopback 用 network 方式,理由是这样能在进程视图里一眼看清业务网段都宣告到哪个区域去了,查漏补缺方便。两种方式可以在同一台设备上混用,不冲突。

2.3 参考带宽与开销计算

OSPF 的接口开销决定了最短路径的走向,而开销是算出来的,不是拍脑袋定的。H3C 的计算公式很简单:接口开销等于参考带宽除以接口带宽,结果取整,最小值 1。默认参考带宽是 100Mbps,也就是说百兆口开销是 1,十兆口是 10,千兆口算出来是 0.1,取整后也是 1。

问题就出在这个取整上。千兆口和百兆口都算 1,万兆口还是 1,链路带宽差了一百倍而开销完全一样,SPF 根本区分不出来,选路只能靠运气。解决办法是调大参考带宽:

[R1-ospf-1] bandwidth-reference 10000

10000的单位是 Mbps,也就是 10Gbps。这样百兆口开销变成 100,千兆口变成 10,万兆口变成 1,层级拉开了,选路才有意义。

这项配置有个坑:参考带宽是进程级参数,全网所有设备必须配成同一个值,否则各算各的,同一段链路在两端算出来的开销不一致,可能出现单向路径不对称,排障时非常难受。所以规划阶段就把这个值定下来,写进基线配置模板。

如果不想动参考带宽,也可以在接口上手工指定开销:

[R1-GigabitEthernet0/1] ospf cost 10

手工指定优先级高于自动计算,适合个别链路需要人为干预的场景,比如双出口做主备。但手工值一多就没人记得住当初为什么这么定,建议在接口描述里写清楚原因。

3. 五台设备的多区域配置全过程

3.1 基础配置与接口地址

所有设备的第一步都一样:改名、配接口地址、指定 Router ID。这一步没有区域的事,纯粹是把地基打好。H3C 设备从用户视图进系统视图用system-view,提示符从<R1>变成[R1],后续配置都在方括号状态下完成。

以 R1 为例:

<H3C> system-view [H3C] sysname R1 [R1] interface GigabitEthernet 0/1 [R1-GigabitEthernet0/1] port link-mode route [R1-GigabitEthernet0/1] ip address 10.1.12.1 24 [R1-GigabitEthernet0/1] quit [R1] interface GigabitEthernet 0/2 [R1-GigabitEthernet0/2] port link-mode route [R1-GigabitEthernet0/2] ip address 192.168.1.1 24 [R1-GigabitEthernet0/2] quit [R1] interface LoopBack 0 [R1-LoopBack0] ip address 1.1.1.1 32 [R1-LoopBack0] quit

port link-mode route这行在多款 H3C 设备上是必须的,接口默认可能是二层模式,不切成三层就没法直接配 IP。有些型号和版本默认就是三层,敲了也不报错,但养成习惯敲上更稳妥,省得换设备时踩坑。

四台设备照此办理,地址按第 1.3 节的表来。地址配完先用ping直连对端确认二层三层都通,连通性没确认就开始配 OSPF,后面邻居起不来你分不清是路由问题还是地址问题。这一步花两分钟,能省后面半小时。

3.2 R1 与 R2 的骨干区域对接

R1 是纯 Area 0 内部路由器,配置最干净:

[R1] ospf 1 router-id 1.1.1.1 [R1-ospf-1] area 0 [R1-ospf-1-area-0.0.0.0] network 10.1.12.0 0.0.0.255 [R1-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255 [R1-ospf-1-area-0.0.0.0] quit [R1-ospf-1] quit

注意area 0后面进到[R1-ospf-1-area-0.0.0.0]这个视图,提示符里 0 被展开成 0.0.0.0,这是正常现象,区域 ID 支持两种写法,配0和0.0.0.0是一回事。network命令必须在这个视图下敲,敲在进程视图里会报错。

R2 是 ABR,配置要分两段,分别进两个区域视图:

[R2] ospf 1 router-id 2.2.2.2 [R2-ospf-1] area 0 [R2-ospf-1-area-0.0.0.0] network 10.1.12.0 0.0.0.255 [R2-ospf-1-area-0.0.0.0] quit [R2-ospf-1] area 1 [R2-ospf-1-area-0.0.0.1] network 10.1.23.0 0.0.0.255 [R2-ospf-1-area-0.0.0.1] quit [R2-ospf-1] quit

这里有个高频错误需要点出来:很多人配 ABR 时图省事,把两个网段都宣告进 Area 0,结果 R2 就不是 ABR 了,而是一个所有接口都在骨干区域的内部路由器。这样 Area 1 压根不存在,Type 3 LSA 一条都不会产生,R3 那边自然学不到 Area 0 的路由。判断依据很简单,配完敲display ospf brief,看区域列表里是不是真的有多个区域,以及 ABR 标志位是否置位。

R2 的 Loopback 2.2.2.2 要不要宣告?我的做法是宣告,放在 Area 0 里。理由是路由器 ID 对应的地址可路由,排障时能直接 ping 通,而且这个地址稳定不震荡,不会引起路由波动。

3.3 R3 上两个区域的宣告顺序

R3 是第二个 ABR,连接 Area 1 和 Area 2。它的配置比 R2 多一层,因为要同时处理两个非骨干区域。写法上先配 Area 1,再配 Area 2,顺序不影响结果,但按编号顺序写便于核对:

[R3] ospf 1 router-id 3.3.3.3 [R3-ospf-1] area 1 [R3-ospf-1-area-0.0.0.1] network 10.1.23.0 0.0.0.255 [R3-ospf-1-area-0.0.0.1] network 192.168.3.0 0.0.0.255 [R3-ospf-1-area-0.0.0.1] quit [R3-ospf-1] area 2 [R3-ospf-1-area-0.0.0.2] network 10.1.34.0 0.0.0.255 [R3-ospf-1-area-0.0.0.2] quit [R3-ospf-1] quit

关键点在于 R3 没有任何接口落在 Area 0。这符合规则,因为 Area 2 是通过 Area 1 间接连到骨干区域的——路径是 Area 2 → R3 → Area 1 → R2 → Area 0。OSPF 允许这种间接连接,但要求中间区域必须是普通区域,不能是末梢区域或完全末梢区域,否则 Type 3 LSA 进不去,间接连接就断了。这个限制在设计阶段就要想清楚,别等配完了再改区域类型。

R3 上 Loopback 3.3.3.3 建议宣告进 Area 1,因为它是 Router ID,宣告后其他区域能通过 Type 3 学到这条主机路由,便于做连通性测试。

3.4 R4 收尾与全网验证命令

R4 是 Area 2 内部路由器,配置和 R1 同构:

[R4] ospf 1 router-id 4.4.4.4 [R4-ospf-1] area 2 [R4-ospf-1-area-0.0.0.2] network 10.1.34.0 0.0.0.255 [R4-ospf-1-area-0.0.0.2] network 192.168.4.0 0.0.0.255 [R4-ospf-1-area-0.0.0.2] quit [R4-ospf-1] quit

全部敲完,邻居关系需要几十秒收敛。验证按顺序来,先看邻居,再看路由,最后看 LSA:

[R1] display ospf peer [R1] display ospf peer verbose [R1] display ospf interface [R1] display ip routing-table protocol ospf [R1] display ospf lsdb

display ospf peer的输出里,关键看 State 字段。正常情况下应该是 Full,表示邻接关系完全建立。如果是 2-Way,说明两台设备都是非 DR/BDR 角色,这在广播网络里是正常状态,不一定是故障。如果卡在 Init、ExStart 或 Exchange,那就是有问题,下一节会展开讲。

路由表验证的目标是:R1 上有 192.168.4.0/24 和 10.1.34.0/24 的路由,下一跳指向 10.1.12.2。再看 R4 上有 192.168.1.0/24 的路由,下一跳指向 10.1.34.3。这两条路由都是跨区域的,如果不存在,说明 Type 3 LSA 没传到位,问题出在 ABR 上。

最后用ping -a 1.1.1.1 4.4.4.4做端到端验证,源地址指定 Loopback,避免走默认路由出去回不来。通了就说明多区域转发路径完整,不通就往回查路由表。

4. 看LSDB才看得懂多区域OSPF

4.1 五类LSA各自的势力范围

多区域 OSPF 和单区域最大的差别不在配置,在 LSA 的种类和传播范围。单区域只有 Type 1 和 Type 2,多区域会引入 Type 3、Type 4、Type 5,每一类都有自己的边界,搞清楚边界在哪,排障时才能快速定位。

Type 1 是 Router LSA,每台路由器在每个有接口的区域里产生一条,描述自己在这个区域内的接口、邻居和链路开销。它的传播范围严格限制在产生它的区域内,不跨区域。所以同一个 Router ID 在不同区域里会看到多条 Type 1 LSA,这不算冲突,而是正常现象。

Type 2 是 Network LSA,由广播网络上的 DR 产生,描述这个网段上都有哪些路由器。它同样只在区域内传播。以太网接口默认网络类型就是广播,所以每条共享链路都会有一个 DR 和一条 Type 2 LSA。

Type 3 是 Summary LSA,由 ABR 产生,作用是把一个区域内的路由以网段的形式通告到其他区域。注意它是“网络摘要”而不是拓扑信息,接收端拿到 Type 3 只是加一条路由,不参与 SPF 计算。这也是 OSPF 内部区域间路由被归类为距离矢量行为的原因。

Type 4 是 ASBR Summary LSA,由 ABR 产生,用来告诉其他区域“ASBR 在哪”。只有当网络里存在 ASBR(引入外部路由的设备)时才会出现,单纯跑内部 OSPF 看不到它。

Type 5 是 External LSA,由 ASBR 产生,描述外部引入的路由,一般情况下泛洪到整个 OSPF 域,只有末梢区域和完全末梢区域不接收。

4.2 Type 3 与 Type 4 的配合关系

Type 3 和 Type 4 经常被混为一谈,因为都是 ABR 产生的汇总类 LSA,但它们的用途完全不同。Type 3 描述的是“某个网段在哪里”,Type 4 描述的是“某个 ASBR 在哪里”。前者用来转发业务流量,后者用来解决外部路由的下一跳问题。

举个具体场景。假设 R4 引入了外部路由成为 ASBR,Area 2 的路由器要把流量送到外部,它需要两样东西:一条指向外部网段的 Type 5 LSA,以及一个能到达 ASBR 的下一跳。这个下一跳信息就是 Type 4 提供的——ABR 会对每个已知的 ASBR 产生一条 Type 4 LSA,告诉本区域的设备“要去找这个 ASBR,先到我这儿来”。没有 Type 4,Type 5 虽然收到了却算不出可用的下一跳,LSA 在数据库里但路由表里没有条目,这是典型现象。

我们这套拓扑里没有 ASBR,所以只会看到 Type 1、Type 2、Type 3。想看 Type 4 需要额外做外部路由引入,后面在默认路由下发那一节会顺带提到。

还有一条容易忽略的规则:ABR 不会把从某个区域学到的 Type 3 再通告回这个区域。这属于区域间路由的水平分割机制,目的是防环。所以你在 R2 上查 LSDB,Area 1 里不会看到 R2 自己从 Area 1 学来又发回 Area 1 的 Type 3,这是正常现象。

4.3 用 display 命令顺藤摸瓜

光看 LSA 类型不够,得会用命令把它们和路由对应起来。我排障时的习惯是三层递进:先看 LSDB 里有什么,再看 OSPF 路由表算了什么,最后看全局路由表有没有被选中。

第一步看 LSDB:

[R1] display ospf lsdb

输出会按区域分组,每行显示 LSA 类型、LinkState ID、产生者 Router ID 和老化时间。R1 只有 Area 0,所以只能看到 Type 1 和 Type 2。要看 Type 3,得上 R2 或者 R4。

第二步按类型过滤,精准定位:

[R2] display ospf lsdb summary [R2] display ospf lsdb router [R2] display ospf lsdb network

summary就是 Type 3,router是 Type 1,network是 Type 2。在 R2 上敲display ospf lsdb summary,能看到 R2 为 Area 1 和 Area 0 互相通告的网段条目,每条的 LinkState ID 就是一个网段地址,Advertising Router 是 2.2.2.2,这说明这条 Type 3 是 R2 自己产生的。

第三步看 OSPF 内部路由表:

[R1] display ospf routing

这个命令输出的是 OSPF 协议算出来的路由,还没和静态路由、直连路由竞争,能看到每条路由的 Cost 和 NextHop。如果这里有条目而全局路由表里没有,说明被优先级更高的路由覆盖了,查display ip routing-table的 Protocol 列就能看出来。

第四步看进程概况:

[R1] display ospf brief

这里有进程号、Router ID、区域列表、SPF 计算次数、各种 LSA 数量。SPF 计算次数是个很有价值的指标,如果这个数字在持续快速增长,说明网络里有频繁的拓扑变化,可能某条链路在闪断,也可能有设备在反复重启进程。

提示:排障时把display ospf lsdb和display ip routing-table protocol ospf两条命令的输出摆在一起看,路由表里缺哪条,就到 LSDB 里找对应网段的 LSA,找到了说明是路由计算问题,找不到说明是 LSA 根本没传过来。这个二分法能省掉大量瞎猜。

5. 邻居起不来、路由通不了:排障实录

5.1 邻居卡在 Init 或 ExStart

邻居状态机卡住是最常见的求助场景,不同卡点对应的原因完全不同,区分清楚才能对症下药。

卡在 Init 意味着本端收到了对方的 Hello 报文,但从对方的 Hello 里没看到自己的 Router ID,也就是说对方没收到本端的 Hello。单向不通的可能性最大:可能是本端接口没宣告进 OSPF,也可能是链路单向故障,或者是 ACL 把组播报文拦了。OSPF 的 Hello 报文发往 224.0.0.5,检查中途有没有安全策略卡组播是第一步。

卡在 ExStart 或 Exchange 基本只有两个原因:MTU 不一致,或者 Router ID 冲突。MTU 不一致是经典坑,两台设备的接口 MTU 一边是 1500 一边是 9000,DD 报文协商阶段就会僵住。H3C 设备默认不检查 MTU,需要在接口上手工开启:

[R1-GigabitEthernet0/1] ospf mtu-enable

开了之后两端 MTU 不一致会直接拒绝建邻居,日志里能看得很清楚。但这也是双刃剑,现网里如果两端 MTU 本来就不一致但又必须能通,开这个命令反而把本来能跑的邻居搞断了,开启前先确认全链路 MTU 一致。

其他几个高频原因一起列出来:Hello 和 Dead 间隔不一致、区域 ID 不一致、认证方式或密钥不一致、网络类型不一致。网络类型这个最隐蔽,一端是以太网默认的广播类型,另一端被人改成点对点,Hello 报文格式都对不上,邻居停在 2-Way 或者根本不动。用display ospf interface能看到每个接口的网络类型和 Hello/Dead 时间,两端对比一眼就能看出差异。

5.2 路由表里有条目但业务不通

这种情况最费时间,因为每一层看起来都是对的。邻居 Full,LSDB 有 LSA,路由表有条目,ping 就是不通。

第一个要查的是下一跳可达性。跨区域路由的下一跳是 ABR 的互联接口地址,如果这个地址本身不可达,路由条目虽然存在但是无效路由,设备不会把它装进转发表。H3C 上可以用display ip routing-table 10.1.12.2确认下一跳地址所在的网段是否有直连或有效路由。

第二个要查的是回程路由。单向通是跨区域场景的高发问题,尤其当某个区域的路由没被正确通告出去时。比如 R1 能 ping 通 R4 的 Loopback,但 R4 回不来,原因是 R1 的 Loopback 或者业务网段没在 Area 0 里宣告,导致 ABR 没有为它生成 Type 3 LSA。判断方法很直接:在 R2 上敲display ospf lsdb summary,看有没有 R1 那个业务网段对应的条目,没有就是宣告漏了。

第三个要查的是区域类型。如果某个区域被配成了末梢区域或完全末梢区域,它不接收 Type 3(完全末梢)或者不接收 Type 4、Type 5(末梢),那么外部路由和部分跨区域路由天然进不来。配末梢区域必须两端一致,H3C 上如果只有一端配了stub,另一端没配,邻居会直接建不起来,现象比路由不通更明显。

第四个要查的是过滤策略。ABR 上如果配了filter-policy或者区域间的filter,某些网段会被静默丢弃,LSDB 里看不到,路由表里也没有,一切都“正常”但就是不通。查配置用display current-configuration configuration ospf把 OSPF 相关配置整段拉出来过一遍。

5.3 常见问题速查表

把上面这些散落的经验整理成一张表,出问题时按顺序过一遍,大部分场景能在十分钟内定位。

关于 Loopback 那条多说一句。H3C 的 Loopback 接口默认 OSPF 网络类型是点对点,通告出去的是 32 位主机路由,不管接口上配的掩码是多少。很多人配了ip address 192.168.100.1 24到 Loopback 上,期望通告 24 位网段,结果路由表里只有 32 位。要通告实际掩码,得在接口上改网络类型:

[R1-LoopBack0] ospf network-type broadcast

改完之后通告的就是接口掩码对应的网段。这个改动要慎重,因为 Loopback 改成广播类型后会参与 DR 选举,一般场景下没必要,直接用 32 位主机路由反而更精确。

5.4 几个只有踩过才知道的细节

配置顺序会影响判断。有人习惯先把 OSPF 进程建好,再慢慢配接口地址,结果中途邻居起起落落,日志刷屏。正确顺序永远是先把所有接口地址配完、直连 ping 通,再统一开 OSPF。这样邻居一次建好,日志干净,出问题也好定位。

reset ospf process是个危险命令。它会清空整个进程的邻居和 LSDB,全网重新收敛,在生产环境里等于一次小型断网。改 Router ID、改参考带宽这类参数确实需要重置才生效,但一定要评估影响面,别在业务高峰期动手。

进程号不需要全网一致,但建议统一。虽然协议上进程号本地有效,但排障时看到五台设备用了五个不同的进程号,敲命令都要先想一下敲哪个,纯属给自己找麻烦。

区域号用十进制还是点分形式,两者等价。area 1和area 0.0.0.1是一回事,但同一个网络里最好统一写法,不然查配置时容易看花眼。

6. 让多区域 OSPF 跑得更省心的几项配置

6.1 区域间路由汇总

区域划分带来的一个直接好处是可以做汇总。ABR 天然是汇总点,把某个区域内的连续网段合并成一条 Type 3 通告出去,能显著减小其他区域的 LSDB 规模和路由表条目。

H3C 的汇总命令配在源区域的视图下,这点很关键——汇总的是“这个区域里的路由”,所以要在被汇总路由所属的区域里配:

[R3-ospf-1] area 2 [R3-ospf-1-area-0.0.0.2] abr-summary 192.168.4.0 255.255.252.0

abr-summary后面跟汇总后的网段和掩码,注意这里是正常掩码而不是反掩码,和network命令的写法不一样,这一点经常有人搞混。配完之后 R2 和 R1 上看到的就不是 192.168.4.0/24 了,而是 192.168.4.0/22 这一条。

汇总的前提是地址规划本身要连续。如果 Area 2 里的网段是 192.168.4.0/24 和 192.168.7.0/24 这种不连续的,强行汇总成 /22 会把中间不属于本区域的地址也带出去,造成黑洞路由。所以地址规划阶段就要为汇总留好空间,按区域分配连续的地址块,这是网络设计的基本功。

汇总还有一层隐含作用:屏蔽区域内部的路由震荡。Area 2 内部某条链路抖动,只要汇总路由不变,Area 0 和其他区域完全感知不到,故障域被限制在区域内。这也是分区最实际的价值之一。

6.2 虚连接与不连续区域

前面说过非骨干区域必须连到 Area 0,但现网里经常遇到物理上连不上的情况,比如某个区域是后来并购进来的,出口只连到另一个普通区域。这时候用虚连接可以打通。

虚连接的配置是在穿越区域的两端 ABR 上互相指定对方的 Router ID,并且要在穿越区域的视图下配:

[R2-ospf-1] area 1 [R2-ospf-1-area-0.0.0.1] vlink-peer 3.3.3.3

R3 上对称配置:

[R3-ospf-1] area 1 [R3-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2

配完之后,逻辑上 R2 和 R3 之间多了一条属于 Area 0 的链路,R3 上的 Area 2 就通过这条虚链路接上了骨干区域。

虚连接能用但不该滥用。它的本质是把穿越区域当成了一个“隧道”,这个区域里的路由必须可达,否则虚连接起不来;而且虚连接不参与 DR 选举,也不传递 Hello 组播,配置错一点就很难查。更重要的是,它把两个区域的耦合度拉高了,穿越区域出问题,两边一起受影响。有条件重新规划物理链路的话,优先考虑改架构而不是加虚连接。

虚连接还有一个限制:穿越区域不能是末梢区域或完全末梢区域,因为末梢区域里没有到其他区域的 Type 3 路由,虚连接的对端地址根本不可达。这个限制在设计阶段就要考虑到。

6.3 默认路由下发与静默接口

边缘区域的路由器通常不需要知道全网明细,给一条默认路由就够了。这在 OSPF 里靠 ASBR 下发 Type 5 实现,或者在末梢区域靠 ABR 下发 Type 3 默认路由实现。

先看 ASBR 下发的方式。在引入外部路由的设备上配:

[R4-ospf-1] default-route-advertise always

always参数的作用是即使本地没有默认路由也强制下发,不加这个参数的话,设备必须自己有一条默认路由才会通告出去。很多人在实验环境里敲完命令发现没生效,就是因为本机没有默认路由指向外部。

如果区域是末梢区域,做法更简洁。ABR 上把区域标成 stub:

[R2-ospf-1] area 1 [R2-ospf-1-area-0.0.0.1] stub

R3 上必须对称配置同样的stub。配完之后 ABR 会自动往这个区域里注入一条 Type 3 的默认路由,区域内的路由器只保留区域内的明细路由和一条默认路由,LSDB 大幅瘦身。

末梢区域里如果还有外部路由要引入,就得用 NSSA:

[R3-ospf-1-area-0.0.0.1] nssa

NSSA 允许区域内有 ASBR 存在,外部路由以 Type 7 LSA 在区域内传播,到 ABR 再转换成 Type 5 发出去。这个转换过程在 H3C 上是自动的,但转换后的 Type 5 只有 P 位被置位的才会转,细节比较多,一般场景配nssa默认参数就够用。

最后提一下静默接口。接终端或者接服务器的接口不需要跑 OSPF,但如果你用network命令把整个大网段宣告进来了,这些接口也会开始发 Hello,纯属浪费资源还增加安全面。把不需要跑 OSPF 的接口设成静默:

[R1-ospf-1] silent-interface GigabitEthernet0/2

静默接口不收发 Hello,但接口网段照样会被通告出去,这个行为正好符合“让其他路由器知道这个网段存在,但不要在接口上建邻居”的需求。如果想把所有接口先静默、再逐个放开,用silent-interface all打底更省事。

我个人的体会是,多区域 OSPF 真正难的地方不在配置命令,而在“信息边界”的把握上——哪些 LSA 该出现在哪个区域、哪些路由该被汇总、哪些接口不该冒泡。把display ospf lsdb和display ospf brief这两条命令用熟,遇到问题先看数据库再看路由表,大部分情况不用重启进程也能定位到根因。至于区域划分本身,别等到网络规模撑不住了才想起来重构,规划阶段多花半天时间把地址块按区域分配好,后面几年都能省心。