企业官网建设流程全解析

上篇那套三台设备全塞进 area 0 的配置发出去之后，被问得最多的不是命令怎么敲，而是拆成多区域以后到底哪里要改、哪些地方会突然不通。标题里那个 osps 是我自己敲岔了，说的就是 OSPF，这里按多区域 OSPF 讲。多区域 OSPF 配置在华为 VRP 平台上并不复杂，麻烦的是拆完之后 ABR 该放哪、LSA 该怎么收敛、特殊区域要不要上。这篇接着上篇的代码往下走，把单区域扩成三个区域，把 ABR、区域间汇总、stub 和 NSSA 一次跑通，顺带把邻居起不来、路由突然消失这类问题的排查链路完整走一遍。手里有单区域配置基础的朋友可以直接抄配置，刚接触 OSPF 的也能从“为什么要拆”这一节看懂动机。

1. 单区域跑得好好的，为什么还要拆

1.1 一个区域塞下全部网段之后发生的事

上篇那套配置里，所有接口都在 area 0，邻居全 Full，路由全通，看起来没有任何问题。但它有一个隐性的代价：区域内每一台路由器持有的链路状态数据库是完全一样的，拓扑里任何一条链路抖动，全区域每一台设备都要重新跑一遍 SPF。十几台设备的时候你感觉不到，到了几十台、上百台，一次接口闪断引发的 SPF 计算和 LSA 泛洪，足以让部分设备的 CPU 出现明显尖峰，收敛时间也会从毫秒级被拉到秒级。

这就是多区域存在的第一个理由：把拓扑变化的影响范围框住。区域内部的 Type 1 和 Type 2 LSA 只在区域内泛洪，不会跨区域传播，区域之间的信息由 ABR 压缩成 Type 3 汇总 LSA 传递。区域 1 里某台设备的一根线断了，区域 2 的设备根本不知道，也不需要重算 SPF，这就是隔离的价值。

第二个理由更现实：路由表规模。单区域下所有明细网段都会被泛洪，一台接入层设备可能被迫维护几百条跟自己毫无关系的路由。拆区域之后配合区域间汇总，边缘设备看到的可能就剩几条聚合路由，内存和转发表压力一下降下来。

第三个理由跟运维有关：故障域和变更域。某个区域做割接、加设备、改网段，影响面基本锁在自己区域内，不会波及全网。

需要提醒的是，多区域不是拆得越细越好。区域数量上去之后，ABR 的负担、虚连接的复杂度、汇总设计的难度都会跟着涨。我的经验是：先按地理或者按业务模块划分，一个区域控制在十几到几十台设备之间，不要为了拆而拆。

1.2 骨干区域与 ABR 那条绕不过去的硬规则

OSPF 有一条不能违反的规则：所有非骨干区域必须直接和骨干区域 area 0 相连，区域间的路由必须经过 area 0 中转。原因在于 OSPF 是距离矢量加链路状态的混合体，区域间的路由计算依赖 ABR 的 Type 3 LSA，而 Type 3 只在骨干区域和非骨干区域之间单向流动，非骨干区域之间不会互传。如果 area 1 和 area 2 都想通过一个中间区域互联而不经过 area 0，路由就会断掉——这是经典的水平分割设计。

对应的角色定义也要清楚：

• 内部路由器：所有接口都在同一个区域
• ABR（区域边界路由器）：同时接入 area 0 和至少一个非骨干区域，负责生成 Type 3 和 Type 4 LSA
• ASBR（自治系统边界路由器）：引入了外部路由（静态、直连、其他协议），生成 Type 5 或 Type 7 LSA

注意 ABR 的判定条件里，“接入 area 0”这一条是硬性的。一台设备同时接了 area 1 和 area 2 但没有 area 0 的接口，它不会成为 ABR，也就不会给两个区域生成 Type 3，两个区域之间依然不通。这时候要么调整物理连接，要么用虚连接把逻辑链路补到 area 0 上——虚连接的具体写法在最后一节展开。

2. 接着上篇的代码，把区域划分落到配置上

2.1 先出拓扑和网段分配表

接着上篇的三台设备，这次扩到五台：R1 作为骨干核心，R2 作为 area 1 的 ABR，R3 挂在 area 1，R4 挂在 area 2 并和 R1 直连，R5 作为 area 2 里的 ASBR 引入外部路由。地址规划先定死，后面的配置全部照着这张表来，别一边敲一边改，改到后面自己都记不住哪个网段在哪个区域。

这张表里有两点是特意设计的。一是Router ID 全部用 LoopBack0 地址并且放进 area 0，保证唯一且稳定，避免用物理口导致接口 down 之后 Router ID 重选引发邻居重建。二是area 2 里同时挂了 R4 和 R5，就是为了演示后面 NSSA 的效果——如果全部区域都是普通区域，特殊区域这一节就没法验证了。

2.2 Router ID 与区域归属的确定顺序

敲配置之前，先把这两个东西定下来，顺序反了要返工。

Router ID 的确定顺序：手工router-id指定 > 全局 router id > 接口地址最大的。现网强烈建议每一个进程都手工指定，并且全区域唯一。我见过两次 Router ID 冲突引发的诡异现象：两台设备邻居反复重建，display ospf peer看着 Full 又掉，日志里刷Router ID conflict，查了半天才发现一台设备的环回口是从别的设备复制配置带过来的同一个地址。

区域归属的确定顺序：先定接口属于哪个区域，再决定用什么方式宣告。这个顺序很重要，因为宣告方式决定了后续排错时你去哪里看。

R1 的配置相对简单，两个物理口都在 area 0：

system-view sysname R1 interface LoopBack0 ip address 172.16.0.1 255.255.255.255 interface GigabitEthernet0/0/0 ip address 10.0.12.1 255.255.255.0 interface GigabitEthernet0/0/1 ip address 10.2.14.1 255.255.255.0 quit ospf 1 router-id 172.16.0.1 area 0.0.0.0 network 10.0.12.0 0.0.0.255 network 10.2.14.0 0.0.0.255 network 172.16.0.1 0.0.0.0

R2 是 ABR，两个接口分属不同区域，注意network命令要分别落在两个 area 视图下面：

ospf 1 router-id 172.16.0.2 area 0.0.0.0 network 10.0.12.0 0.0.0.255 network 172.16.0.2 0.0.0.0 area 0.0.0.1 network 10.1.23.0 0.0.0.255

R3、R4、R5 同理，按上面的表各自落到对应区域。这里有个新手常犯的错误：把两条不同区域的 network 都写进同一个 area 视图，或者只写了主网段没写反掩码。华为的network后面跟的是反掩码，10.1.23.0 0.0.0.255对应的是 /24，写成255.255.255.0会直接报错或者匹配不上。

配置敲完之后，敲一条display ospf brief看进程状态，重点看两行：Router ID是不是你指定的那个、SPF Schedule Delay之后有没有区域列表。然后再敲display ospf interface确认每个接口的 Area 字段对不对得上表。

3. ABR 上真正需要斟酌的几个配置点

3.1 network 宣告和接口下使能，选哪个

华为 VRP 支持两种把接口纳入 OSPF 的方式，很多人随手选一个就完事，其实两者的行为有差异，值得说清楚。

第一种是进程视图下用network宣告网段，这是从上篇一直沿用下来的写法：

ospf 1 router-id 172.16.0.2 area 0.0.0.1 network 10.1.23.0 0.0.0.255

它的匹配逻辑是：拿接口地址去和 network 命令做匹配，命中的接口被使能 OSPF，同时这条 network 的网段会被当作一条区域内路由发布出去。反掩码写错一位，可能把本来不该进 OSPF 的接口也带进来，这是它最大的风险点——network 10.0.0.0 0.255.255.255这种写法会把 10 段所有接口一网打尽，包括管理口和互联口。

第二种是在接口视图下直接使能：

interface GigabitEthernet0/0/1 ip address 10.1.23.2 255.255.255.0 ospf enable 1 area 0.0.0.1

这种方式精确到接口，不存在误匹配的问题，而且接口上可以顺带配ospf cost、ospf dr-priority、ospf timer hello这些参数，可读性强。缺点是接口多的时候要一个个进去敲。

我的实际选择是：新建网络一律用接口下ospf enable，老网络割接沿用原有network写法不做无谓改动。混用是被允许的，但同一个区域里不要两种方式交叉覆盖同一个接口，否则排错时你得两边都查一遍，非常耗时间。

3.2 三类 LSA 在 ABR 上怎么流动

拆完区域，最值得盯的就是 LSA 的边界。区域内部靠 Type 1（Router LSA）和 Type 2（Network LSA）描述拓扑，ABR 把区域内的路由信息压缩成 Type 3（Summary LSA）通告到其他区域，如果区域内有 ASBR，ABR 还会生成 Type 4 告诉其他区域“怎么找到那个 ASBR”。

拿上面的拓扑举例，R4 的环回 172.16.2.4/32 在 area 2 里是一条 Type 1，R1 作为 ABR 会把它转成 Type 3 通告进 area 0，R2 再把它转成 Type 3 通告进 area 1。你在 R3 上display ospf lsdb summary能看到这条，但display ospf lsdb router里绝对看不到 R4 的 Router LSA——这就是区域隔离的直接证据。

这里有个容易误解的点：Type 3 是“路由”不是“拓扑”。ABR 只告诉其他区域“到我这边有个 172.16.2.0/24，距离是多少”，不告诉对方区域内部的链路长什么样。所以跨区域的路由计算本质上是距离矢量行为，这也是 OSPF 被称作“混合型协议”的原因。理解了这一点，后面遇到“跨区域路由选路不符合预期”就不会懵——跨区域路径只看 ABR 报告的 cost，不看真实带宽。

验证 LSA 边界最简单的办法是两边对照：

# 在 R3（area 1 内部）上看 display ospf lsdb display ospf lsdb summary # 在 R1（ABR）上看同一时刻的 LSDB display ospf lsdb

对比 Type 3 的数量和内容，能立刻确认 ABR 有没有正常工作。如果 R3 上完全看不到 area 2 的 Type 3，先别怀疑路由，先确认 R2 的 area 0 邻居是不是 Full。

3.3 区域间汇总什么时候做、怎么做

区域间汇总在 ABR 上配置，命令是abr-summary，作用是把本区域内的一批明细网段聚合成一条，再以 Type 3 通告到其他区域。语法是：

ospf 1 area 0.0.0.1 abr-summary 172.16.0.0 255.255.0.0

这条命令要配在源区域的视图下，这一点很多人搞错，跑到目标区域里去配，结果发现没有任何效果。逻辑是：汇总的是 area 1 里的明细，所以命令挂在 area 1 下面。

什么时候该做汇总？三个判断标准：

1. 区域内有大量连续网段，且这些网段的路由策略一致（比如整个片区都由同一台出口设备承载）
2. 边缘设备的路由表已经明显偏大，影响转发性能
3. 区域内网段有变动预期，希望外部感知稳定

什么时候不该做？区域内存在双出口或者多路径负载的时候要谨慎。汇总之后，外部只知道聚合路由指向 ABR，如果实际有两条不等价路径，汇总会把其中一条路径的细节抹掉，可能导致流量全部压到一台 ABR 上。这种情况要么把汇总范围收小，要么用abr-summary ... not-advertise配合明细控制。

还有一个细节：汇总之后，被聚合的明细如果全部失效，聚合路由会自动消失；只有部分明细失效时，聚合路由依然存在。这个行为是正确的，但排查时容易误判为“汇总没生效”，需要看display ospf lsdb summary里那条聚合 LSA 的 Metric 有没有变化。

4. 特殊区域实测：stub 与 NSSA 的差别到底在哪

4.1 stub 区域把 Type 4 和 Type 5 挡在门外

area 1 是典型的末梢区域——只挂了一台 R3，没有任何外部路由引入，也没有其他区域的出口。这种区域最适合配成 stub。配置要在区域内所有路由器上一致地敲，包括 ABR：

# R2（ABR） ospf 1 area 0.0.0.1 stub # R3（内部路由器） ospf 1 area 0.0.0.1 stub

配完立刻能观察到两个变化：一是 R3 的 LSDB 里 Type 4 和 Type 5 全部消失，二是 R3 的路由表里凭空多出一条0.0.0.0/0指向 R2。这条默认路由是 ABR 自动下发的，用 Type 3 的形式传递，cost 是 1。这就是 stub 的核心机制：用一条默认路由换掉所有外部明细。

如果连区域间的明细也不想要，用stub no-summary（也就是 totally stubby），ABR 会连 Type 3 也一起过滤掉，只留一条默认路由。R3 那种只有单出口的场景，no-summary是最省资源的做法：

ospf 1 area 0.0.0.1 stub no-summary

这里有个必须强调的点：stub和stub no-summary只需要在 ABR 上配置no-summary，区域内其他路由器配普通stub就行。两边都配no-summary不会报错，但没必要，而且有些版本对一致性检查比较严格，容易出问题。另外，区域里一旦有 ASBR，就不能配成 stub，配了会直接报错——因为 stub 区域禁止 Type 5 进入，ASBR 没法工作。

4.2 NSSA 让区域能引入外部路由又不收外部路由

area 2 的情况不一样：R5 需要把一条静态路由引入 OSPF，但 area 2 又不想接收其他区域的外部路由。这种“我要往外说，但我不听别人说”的场景就是 NSSA。配置同样要区域内一致：

# R1（ABR） ospf 1 area 0.0.0.2 nssa # R4（内部路由器） ospf 1 area 0.0.0.2 nssa # R5（ASBR） ospf 1 area 0.0.0.2 nssa import-route static

R5 上再补一条静态路由指向一个不存在的下一跳或者 Null0，用来模拟外部网段：

ip route-static 192.168.100.0 255.255.255.0 NULL0

配完之后看 R4 的 LSDB，会发现外部路由以Type 7的形式出现，而不是 Type 5。Type 7 只在 NSSA 内部泛洪，到了 ABR（R1）那里，R1 会把 Type 7 翻译成 Type 5 再通告进 area 0。这个翻译动作由 ABR 自动完成，但有个条件：Type 7 LSA 里的 P bit 必须置位。R5 用import-route引入的路由默认 P bit 是置位的，所以能正常翻译。如果是通过nssa ... default-route-advertise下发的默认路由，行为又不一样，需要单独确认。

NSSA 里还有一个实用配置：ABR 上敲nssa default-route-advertise，可以让 ABR 向 NSSA 内下发一条 Type 7 的默认路由，效果类似 stub 的默认路由，但保留了引入外部路由的能力：

ospf 1 area 0.0.0.2 nssa default-route-advertise

4.3 四种区域类型的实测对比

把这些区域类型放在一起对比，配置时就不容易选错：

实测中我最常遇到的问题是区域类型不一致导致的邻居卡在 ExStart。华为设备在 Hello 报文里带了 stub/NSSA 的标志位，两边不一致时邻居根本建不起来，display ospf error里能看到Area type mismatch之类的计数增长。所以改区域类型一定要区域内所有设备一起改，或者至少先改 ABR 再改边缘，中间会短暂中断，安排在窗口期做。

5. 邻居起不来、路由不通的排查链路

5.1 从邻居状态机逐级往下看

OSPF 排错的第一条命令永远是display ospf peer，看状态卡在哪一级。状态机的顺序是 Down → Init → 2-Way → ExStart → Exchange → Loading → Full，卡在不同阶段对应的原因完全不同：

display ospf peer display ospf peer brief display ospf interface GigabitEthernet0/0/1 display ospf error

卡在 Init：本端收到了对端的 Hello，但对端的 Hello 里没有本端的 Router ID。典型原因是单向通信、 ACL 挡了组播、或者一端配了认证另一端没配。先ping一下对端接口地址确认双向可达，再看两端认证配置。

卡在 2-Way：广播网络上这是正常状态，非 DR/BDR 之间就是 2-Way，不用管。但如果所有邻居都是 2-Way，说明 DR 选举有问题，通常是ospf dr-priority 0把所有设备都设成了不参选。

卡在 ExStart：这是最经典的一个坑，MTU 不一致。华为设备在 DD 报文里带了接口 MTU，两端不一致时主从协商永远完不成，状态就死死停在 ExStart。解决办法有两个：一是把两端接口 MTU 调一致，二是在接口下敲ospf mtu-ignore强制忽略。我一般选第一种，因为 MTU 不一致往往意味着链路层真的有问题（比如一边是 1500 一边是 9000 的 jumbo frame 配置），忽略它只是掩盖症状。

卡在 Exchange/Loading：通常是 LSA 头部信息错误，可能是 Router ID 冲突或者 LSDB 里存在异常 LSA。这时候display ospf error会给出具体计数。

5.2 LSDB 和路由表交叉验证

邻居 Full 了但路由不通，那就是 LSA 或者路由计算的问题。验证顺序是：先看本区域 LSDB 全不全，再看路由表有没有，最后看转发路径对不对。

display ospf lsdb router display ospf lsdb summary display ospf routing display ip routing-table protocol ospf

一个典型场景：R3 上能看到 172.16.2.4/32 的 OSPF 路由，但 ping 不通。这时候要看下一跳指向谁、下一跳是否可达。跨区域路由的下一跳是 ABR 的接口地址，如果 ABR 那个接口恰好被silent-interface静默掉了，路由存在但转发不通，这个坑很隐蔽。

另一个高频场景：路由表里有，但display ospf routing里没有。这说明这条路由是从别的协议来的，或者是直连。华为设备上display ip routing-table protocol ospf只显示 OSPF 来源的路由，如果一条路由在全局路由表里存在但协议字段显示 Static，说明 OSPF 那条被优先级压掉了。

5.3 几类高频故障的定位路径

把实际踩过的坑整理成一张对照表，遇到问题时按图索骥比漫无目的地敲命令快得多：

这张表里我最想强调“下一跳被静默”这一条。silent-interface配置的本意是让某个接口不参与 OSPF，但它同时会阻止该接口地址被宣告为可到达的下一跳，而路由本身可能已经从其他路径学到了。表现出来就是路由在、ping 不通、tracert 到一半消失，非常难查。

6. 落地时才体会到的几个细节

6.1 虚连接：骨干区域不连续时的补救

现网改造中经常遇到 area 0 被物理割裂的情况。比如两个数据中心之间新增了一个中转区域，导致 area 0 不再是连续的。OSPF 的硬规则要求 area 0 连续，这时候用虚连接把两段 area 0 逻辑上接起来：

# 在穿过的中转区域（area 1）的两台 ABR 上互相指 ospf 1 area 0.0.0.1 vlink-peer 172.16.0.2

虚连接的本质是把一条区域内路径伪装成 area 0 的链路，所以它必须配置在穿越区域的视图下，指定的对端地址是对方的 Router ID（注意是 Router ID，不是接口地址）。两个方向都要配，单边配不会生效。

虚连接能救急，但不建议长期依赖。它的 cost 是穿越区域的路径 cost 累加，路由选路可能变得反直觉，而且排查问题时多了一层逻辑链路，故障定位难度明显上升。有条件还是调整物理拓扑，让 area 0 真正连续。

6.2 cost 与 DR 选举这两个隐式因素

华为设备 OSPF 接口默认 cost 的计算公式是bandwidth-reference / 接口带宽，默认参考值是 100Mbps。这意味着千兆口、万兆口的 cost 都是 1，完全体现不出带宽差异。如果你的网络里有千兆和万兆混合链路，又希望万兆优先，必须手工调整：

# 方式一：全局改参考值（推荐，一次生效） ospf 1 bandwidth-reference 10000 # 方式二：单接口改 cost interface GigabitEthernet0/0/1 ospf cost 10

我倾向于用第一种，因为全局参考值改了之后所有接口自动按带宽重新算，逻辑一致；单接口改 cost 容易在扩容时漏改，导致新旧链路 cost 倒挂。

DR 选举方面，广播网络（比如交换机互联的以太网段）默认按优先级和 Router ID 选 DR，优先级默认是 1。生产环境建议手工指定 DR，把核心设备的接口优先级调高：

interface GigabitEthernet0/0/0 ospf dr-priority 200

不指定的话，一台新接入的设备如果 Router ID 更大，可能把原来的 DR 顶掉，引发一次全网 LSA 重泛洪。这个动作在业务高峰期是致命的。

6.3 变更操作该按什么顺序来

多区域改造是有顺序讲究的，顺序错了会出现中间态黑洞。我的习惯是：

1. 先备份：display current-configuration整份导出，别嫌麻烦，返工的时候能救命
2. 先加后删：先把新区域的接口和 network 加上，确认邻居 Full、路由学到，再去删旧的
3. ABR 最后动：区域中间设备先改，ABR 后改，因为 ABR 一改会影响多个区域
4. 特殊区域一起改：stub/nssa这类参数必须在区域内所有设备上一致，要么全改要么不改，中间态会导致邻居断开
5. 汇总最后配：等所有明细路由都稳定了再加abr-summary，避免汇总把还没收敛的路由一起盖掉

第 2 条“先加后删”是我吃过亏之后养成的习惯。早期做区域拆分时图快，先把旧区域的 network 删了再加新的，中间那段时间这条链路完全不在 OSPF 里，业务直接中断了十几秒。如果反过来先加新的，路由平滑切换过去之后再删旧的，用户侧基本感知不到。

另外，改完之后不要只看display ospf peer是不是 Full 就收工。至少再跑一遍display ip routing-table protocol ospf，确认路由条数和预期一致；再挑几个跨区域的地址tracert一下，确认流量真的走了你设计的路径。OSPF 收敛快，但“收敛完成”和“收敛到你想要的路径”是两回事，尤其是存在等价多路径的时候，选路结果可能和你规划的完全不一样。

最后分享一个我自己常用的小技巧：改区域之前先在设备上开terminal monitor和terminal debugging，把 OSPF 的日志打开，然后一边改一边看日志。邻居建立、LSA 泛洪、SPF 计算的每一步都会打出来，比事后去查状态快得多，也能第一时间发现“邻居起来了又掉”这种不容易察觉的抖动。