很多人学OSPF时单区域配置玩得很溜一到多区就懵了明明就是两条network命令的事为什么还要分骨干区、特殊区甚至搞出一堆LSA类型更麻烦的是多区之后再看路由表你会发现区域间的路由不再是SPF算出来的完整路径而是ABR“翻译”过来的汇总信息——理解这个转变才是看懂多区的关键。这篇是OSPF详解系列的第二篇默认你已经掌握了邻居建立、DR/BDR、单区域LSDB和基本配置。我们专门聊多区的原理和配置包括为什么一个区域不够用、Type3/Type4/Type5 LSA怎么在区域间传、Stub和NSSA到底怎么选、实际配置命令长什么样以及我在网络改造中踩过的坑。适合正在学OSPF或者准备把单区域改成多区域的朋友对照着看。1. 从单区到多区为什么一个区域不够用1.1 单区域OSPF的扩展性瓶颈先打个比方。单区域OSPF就像一个小团队开会每次所有人都必须到场任何一个人调整工作计划全公司都要重新开会同步。人数少的时候效率没问题可一旦上百人会议频率和资源消耗就把人拖垮了。OSPF也一样单区域里所有路由器都维护同一份LSDB任何链路抖动都会触发全区域泛洪和SPF重算。具体到数据上区域内每台路由器产生一条Router LSA每个广播网段由DR产生一条Network LSA整个区域的信息量约等于“路由器数量网段数量”。当路由器从几十台涨到几百台LSDB大小和SPF计算量都成倍增加。如果网络里还有大量抖动链路每抖一次全网所有路由器同时重算整个OSPF域都会处于不稳定状态。单区域的另一个问题是故障隔离能力差。一台边缘路由器误配置产生的错误LSA能泛洪到全网影响所有业务。另外所有网段在同一个区域里你想按业务、按部门、按地理位置做路由策略几乎无从下手因为OSPF默认不区分这些逻辑边界。所以当网络规模到一定程度单区域无论如何都绕不开“一锅端”的瓶颈。1.2 多区划分解耦的管理与转发边界多区域OSPF的核心是把一个大网拆成若干个相对独立的区域并且强制所有区域都挂在Area 0骨干区上。逻辑上是一个以Area 0为中心的星型结构每个非骨干区域都必须与Area 0物理或逻辑相连区域间路由必须经过Area 0中转。在这个结构里区域边界上的路由器叫ABRArea Border Router。ABR同时属于多个区域为每个区域维护独立的LSDB并在区域之间传递经过“翻译”的路由信息。如果这个网络还要引入外部路由那连接外部网络的设备叫ASBRAutonomous System Boundary Router负责把外部路由送进OSPF。多区带来的好处是立竿见影的泛洪范围被限制在各自区域内一个区域的拓扑变化不会让另一个区域做完整SPF重算ABR可以做路由汇总和过滤把大量明细路由压成少量路由条目不同区域还可以按需配置不同类型的特殊区域实现存储与计算资源的精细化控制。代价则是配置复杂度上升ABR成为关键节点而且跨区路径不一定是最优物理路径。1.3 多区域不是越多越好划分区域时有个常见误区“既然多区能减小LSDB那就把所有网段都拆成小区域。”这会让ABR变得非常多区域间路由传递链变长跨区通信绕路反而增加延迟和故障点。比较合理的思路是把核心设备、核心互联、以及那些流量大且必须快速收敛的链路放进Area 0把可独立管理、故障时不需要惊动全网的边缘网段划成普通非骨干区域把只上联、无外部路由需求的末梢区域配置成Stub系列。区域边界最好放在“流量穿越少”的位置而不是单纯按照物理拓扑一刀切。2. 三类LSA与区域间路由的传递逻辑2.1 LSA类型速览谁在区域内谁在区域间多区OSPF最难理解的部分就是LSA类型的流转。我当年也是背了很多遍才真正想明白后来发现只要抓住两个维度就行这个LSA是在一个区域内泛洪还是跨区域传播。区域内计算路径靠的是Type1 Router LSA和Type2 Network LSA。Type1描述每台路由器的接口和邻居关系Type2由DR生成描述广播网段上有哪些路由器。这两类LSA只在所属区域内泛洪SPF就是基于它们构建出本区域的完整拓扑图。跨区传播的核心是Type3 Summary LSA。ABR把自己某个区域内的路由整理成Type3通告到其他区域。这里要注意Type3不是把拓扑信息传过去而是把“目的网段开销”这样的路由信息传过去。所以多区后的跨区选路不再依赖完整拓扑而是依赖精简后的路由这是OSPF从链路状态协议转向“类距离矢量”的过程。Type4是ASBR Summary LSA用来告诉其他区域“ASBR在哪里”。外部路由本身由ASBR生成Type5 AS External LSA在整个AS内泛洪但其他区域要找到ASBR必须靠Type4定位。NSSA区域里还有一个Type7只在NSSA内泛洪由ABR转换成Type5后传给其他区域。2.2 ABR如何工作路由汇总与隔离机制ABR是多区设计的核心。它同时维护多个区域的LSDB每个区域的SPF计算相互独立。当某个区域内部拓扑变化时ABR只需要更新对应区域的LSDB并把受影响的Type3路由重新通告给其他区域其他区域不需要重新计算完整SPF只更新相关路由条目。ABR默认不做自动聚合。它会把所连接区域里的每个子网都转换成Type3通告出去。假如Area 1里有10.1.0.0/24到10.1.15.0/24一批连续子网不在ABR上配置汇总的话其他区域会收到15条Type3而不是一条10.1.0.0/20。配置汇总的语法在不同厂商设备上不太一样常见的是在ABR上针对某个区域配置range或summary-address指定汇总后的网段和掩码。隔离机制上ABR是天然的策略实施点。你可以在ABR上做路由过滤只允许某些子网进入Area 0也可以在ABR上对特定区域注入默认路由。很多实际的区域安全策略都是在ABR上完成的。需要注意的是ABR上承载了多个LSDB性能和内存的要求会比内部路由器高生产环境里别拿低端设备当ABR用。2.3 区域间防环设计的直觉理解OSPF多区为什么不会产生环路这是很多人问过我的问题。答案一句话所有区域间路由必须经过Area 0非骨干区域之间不直接交换Type3。具体到ABR行为上从非骨干区域学到的Type3 LSA不会被重新通告回骨干区域。换句话说区域间路由的传递方向是受控的非骨干区域的内部路由进入Area 0再由Area 0进入其他非骨干区域。所有跨区路径都被迫在逻辑上形成一个以Area 0为中心的树树状结构天然无环。这种设计在直觉上很像“所有城市之间的高速路都要先经过首都中转站”。虽然绕路但换来了无环的确定性。所以如果你在设计中让两个非骨干区域直接互连或者用虚链路把Area 0弄成网状都会破坏这个防环模型轻则次优路径重则路由环路。3. 特殊区域类型Stub、NSSA与Totally系列的设计取舍3.1 Stub区域原理与配置注意Stub区域很好理解它不允许Type4和Type5 LSA进入。外部路由的路由条目不会被泛洪到Stub区域区域内的路由器只需要保留区域内部路由再加上一条由ABR自动注入的默认路由0.0.0.0/0。外部流量全部走默认路由出去大幅缩减边缘设备的路由表。配置Stub区域有几个硬性条件区域内不能有ASBR区域不能是Area 0不能作为虚链路的穿越区域。这些条件其实都很好理解既然不允许外部LSA进来你自然不能在区域里引入外部路由。还有一个特别容易踩的坑Stub区域里所有路由器都必须明确配置同样的区域类型。如果Area 1里有一台设备忘了配置Stub另一台配了两者Hello报文中的Option字段对不上邻居状态就会卡在ExStart附近或者反复抖动。这个问题在故障排查里经常出现后面我会专门展开。3.2 NSSA的Type7 LSA与转换机制NSSANot-So-Stubby Area解决的场景是这个区域不想接收外部Type5路由但自己又要引入外部路由。比如一个分支网络需要把本地的一条静态路由发布到OSPF又不想让全网大量外部明细灌进来NSSA就非常合适。NSSA内部的ASBR把外部路由以Type7 LSA的形式发布这个Type7只在NSSA区域内泛洪。当NSSA有多台路由器时会选举一台ABR作为转换路由器把Type7转换成Type5再通告到其他区域。默认情况下Router ID较大的路由器会成为转换者你也可以通过命令指定谁来做转换这点在生产环境中建议显式指定避免切换ABR时路由震荡。NSSA不同于Stub它默认不会自动注入默认路由。如果你希望NSSA区域内的路由器访问外部网络时走默认路由需要额外配置一条默认路由注入命令。很多人在配置NSSA后发现区域内设备没有默认路由原因就是少配了这一步。3.3 特殊区域选型对比区域类型允许的LSA外部路由默认路由典型适用场景标准区域Type1/2/3/4/5正常接收无核心区域或需要完整路由的区域StubType1/2/3不接收自动注入边缘区域只访问内部和外部默认出口Totally StubType1/2不接收自动注入路由条目需要极简的末梢区域厂商扩展NSSAType1/2/3/7本地可引入Type7需配置注入本地要引入外部路由但不接收全局外部明细Totally NSSAType1/2/7本地可引入Type7需配置注入同时过滤Type3需要最小路由表的NSSA场景选型经验上我一般这样判断如果这个区域纯粹是末端上联出口固定用Totally Stub最舒服路由表干净如果这个区域需要自己发一条外部路由又不希望接收全网外部明细用NSSA或Totally NSSA如果区域里设备性能足够而且需要灵活选路那标准区域反而更省心。特殊区域省了资源但也牺牲了灵活性和可见性别为了“看起来高级”去乱用。4. 多区配置实战从规划到验证4.1 实验拓扑与地址规划理论讲完直接上配置。我自己习惯用一个非常简单的三区域拓扑验证多区行为结构如下Area 0R1、R2、R3Area 1R3、R4R3作为ABRArea 2R2、R5R2作为ABR其中R1和R3之间通过R2转发R1、R2、R3之间互联链路都声明在Area 0。R4挂在R3下面R5挂在R2下面。所有Loopback地址用Router ID作为规划基准方便后续验证。地址规划表设备Router IDLoopback互联接口所属区域R11.1.1.110.0.1.1/3210.0.12.1/24Area 0R22.2.2.210.0.2.2/3210.0.12.2/24、10.0.23.2/24、10.0.25.2/24Area 0、Area 2R33.3.3.310.0.3.3/3210.0.23.3/24、10.0.34.3/24Area 0、Area 1R44.4.4.410.0.4.4/3210.0.34.4/24Area 1R55.5.5.510.0.5.5/3210.0.25.5/24Area 24.2 核心配置步骤我以通用命令行风格为例不同厂商的关键字略有差异但逻辑一致。R1的配置如下Router(config)# router ospf 1 Router(config-router)# router-id 1.1.1.1 Router(config-router)# network 10.0.12.1 0.0.0.0 area 0 Router(config-router)# network 10.0.1.1 0.0.0.0 area 0注意network后面的反掩码0.0.0.0表示精确匹配这个IP地址。初学者喜欢用0.0.0.255这种宽匹配去覆盖整个网段但如果接口地址规划不连续很容易把不该进OSPF的接口也宣告进来。我的建议是能精确匹配就精确匹配一个接口一条命令虽然敲起来多几步但后期少踩很多坑。R2同时连接Area 0和Area 2命令如下Router(config)# router ospf 1 Router(config-router)# router-id 2.2.2.2 Router(config-router)# network 10.0.12.2 0.0.0.0 area 0 Router(config-router)# network 10.0.23.2 0.0.0.0 area 0 Router(config-router)# network 10.0.2.2 0.0.0.0 area 0 Router(config-router)# network 10.0.25.2 0.0.0.0 area 2R3类似把连接R4的接口放到Area 1Router(config)# router ospf 1 Router(config-router)# router-id 3.3.3.3 Router(config-router)# network 10.0.23.3 0.0.0.0 area 0 Router(config-router)# network 10.0.3.3 0.0.0.0 area 0 Router(config-router)# network 10.0.34.3 0.0.0.0 area 1R4和R5配置就简单了只涉及一个区域。R4的Loopback、连接R3的接口都放在Area 1R5的Loopback、连接R2的接口都放在Area 2。如果你使用的是直接支持接口宣告方式的设备可以简化为在接口视图下指定OSPF进程和区域。无论哪种方式最终生效的网段集合必须和规划表一致。4.3 配置后的验证命令与预期输出配置完成后第一件事是检查邻居状态。常见命令是查看OSPF邻居表R2上应该能看到R1、R3、R5三个邻居R3上应该能看到R2、R4两个邻居所有邻居状态应为Full。接着看OSPF路由表。R4应该能看到R5的Loopback地址5.5.5.5/32路径是经R3到R2再转发R5也应该能看到R4的Loopback地址4.4.4.4/32。这里有两个细节值得验证一是下一跳是不是指向正确的ABR二是开销是否符合预期。再看LSDB。在R3上查看LSDB你能同时看到Area 0和Area 1的LSA。你会发现跨区路由在LSDB里是以Type3 Summary LSA存在的而不是完整拓扑。这正是多区“精简”的体现。如果你在ABR上配置了汇总Type3的数量会进一步减少。最后做一次跨区Ping测试从R4 ping R5的Loopback通的话说明区域间路由正常工作。如果不同优先检查ABR上的邻居状态和路由过滤配置。5. 多区场景下常见的故障根因与排查思路5.1 骨干区域断开导致区域间路由消失多区最典型的问题就是Area 0断了。因为所有区域间路由必须经过Area 0一旦骨干断开两个非骨干区域之间立刻失去联系但各自区域内部可能一切正常。我遇到过一个案例某个网络的Area 0由两台核心路由器之间的两条链路承担其中一条链路误被更改到另一个区域导致骨干只剩单链路另一侧区域的路由大面积缺失。排查时发现ABR邻居状态正常但Type3路由数量明显减少顺着LSDB一查才定位到骨干链路被错误改区。这类问题的排查思路是先在ABR上确认Area 0邻居是否Full再看路由表里有没有应有的Type3最后检查骨干接口到底声明在哪个区域下。别一上来就怀疑特殊区域配置。5.2 汇总路由掩码/范围错误导致黑洞ABR汇总配置错误是第二个高发问题。假设Area 1内有172.16.1.0/24和172.16.2.0/24ABR上配置了汇总路由172.16.0.0/16。如果Area 2里还有一个172.16.3.0/24它恰好落在/16汇总范围内那么其他区域访问172.16.3.0/24时会优先匹配ABR通告的汇总路由把流量引向Area 1可Area 1根本没有这个网段数据包就被黑洞了。所以汇总前必须确认地址块是否连续、是否完全包含在目标区域内。如果只是相邻但不连续宁可多汇总几条也不要一条大范围汇总覆盖所有。排查黑洞时用traceroute逐跳看流量走向然后在疑似黑洞设备的路由表里找覆盖路由基本能很快定位。5.3 Stub/NSSA区域配置不一致导致邻居异常特殊区域类型必须全网一致这是最容易被忽略的规则。同一个区域里如果一台设备配置了Stub另一台没配两台路由器发送的Hello报文Option字段不一致邻居状态会反复卡在ExStart或Exchange甚至形成不停重置的邻居关系。NSSA还多一个坑多个ABR同时存在时Type7到Type5的转换者如果不稳定会导致部分路由器一会儿有外部路由一会儿没有。解决办法是显式指定转换路由器或者确保Router ID选举结果稳定。另外NSSA区域里如果有设备不支持Type7也会出现兼容性问题。排查时先看邻居状态卡在哪一步再对比两端区域类型配置。注意有些设备显示stub区域为“Stub”NSSA为“NSSA”如果区域类型不一致在状态信息里能看到Option字段差异。5.4 邻居卡在ExStart/Exchange检查MTU多区配置新增链路后邻居状态卡在ExStart/Exchange很常见根因十有八九是链路两端MTU不一致。OSPF在DD报文交换阶段会协商MTU如果两端不一致数据库描述报文无法完成交换邻居就一直起不来。这个问题的排查优先级很高因为很多人会先去检查区域配置结果发现都没问题浪费不少时间。处理方式也很简单把链路两端MTU调成一致或者在不影响业务的前提下配置忽略MTU检查。实际组网里不同品牌、不同接口类型的设备默认MTU可能不同新增链路时最好提前拉齐。6. 我在多区迁移中踩过的坑与优化建议6.1 区域划分不能只看拓扑图还要看业务流我第一次做多区规划时纯粹按楼层划分区域一楼Area 10、二楼Area 20、三楼Area 30全部挂在Area 0上。配置好了才发现有些业务系统跨了好几个楼层大量流量需要在区域间穿来穿去每一跳都要经过Area 0延迟和路径都没优化。后来我把同一个业务链路的网段尽量放进同一个区域区域边界放在业务流最少的位置整体路由才清爽起来。区域划分的本质是“故障域和策略边界”不是简单的物理位置标签。6.2 从单区改多区必须小步走有一回我把一个运行中的单区域网络改成多区域直接在核心设备上把原来的Area 0改成Area 1结果整个区域的路由表清空重建业务中断了好几分钟。后来学乖了改成小步迁移先新建一条链路声明成新区域等邻居稳定后再把要迁移的接口一条条从旧区域切到新区域每切一条观察一会儿路由收敛情况。迁移顺序也很重要。建议先把边界设备的下行接口迁移到新区域最后迁移骨干链路。不要在业务高峰期做这种操作即使OSPF能快速收敛也扛不住反复修改。6.3 汇总不是越狠越好ABR汇总能大幅缩减路由表但汇总必须建立在连续地址规划的基础上。如果地址不连续强行汇总轻则次优路由重则黑洞。我的习惯是核心设备路由表大一点没关系边缘区域路由表尽量精简精确汇总优于粗糙汇总。另外汇总会掩盖明细路由的变化。当某条明细发生故障时其他区域可能仍然看到汇总路由存在直到汇总路由本身的Cost发生变化。所以依赖汇总做高可用切换时一定要确认ABR是否感知到底层明细变化。6.4 虚链路只用于过渡不要用于长期支撑非骨干区域无法直接连接Area 0时虚链路可以充当逻辑骨干。它可以解决临时连通问题但也带来不少隐患虚链路穿越的区域一旦不稳定OSPF骨干逻辑就跟着不稳定虚链路上的LSA处理也容易产生次优路径。我在一次区域调整中用过虚链路做过渡当时感觉像抓住一根救命稻草后面连续出了很多诡异的路由问题。后来想明白虚链路本质上是在“欺骗”OSPF让它以为有一个不存在的物理骨干。长期运行的网络还是尽早补上真正的物理连接更踏实。6.5 一个小习惯配置完多区后核对Type3最后分享一个我自己的习惯每次多区配置完成我都会在ABR上查看Type3 LSA列表再和规划表逐条核对。数一下Type3的数量看有没有多余的路由、有没有缺失的子网再验证一下汇总后的路由是否和预期一致。这个习惯帮我提前发现过好几次汇总范围错误和误宣告问题。多区OSPF的原理其实不复杂但细节非常碎用这样的核对方法能挡住大多数配置层面的坑。