OSPF 是我日常工作里打交道最多的动态路由协议没有之一。做网络这一行如果连 OSPF 的邻居关系、LSA 类型、区域设计都说不清楚面试和排障的时候都会很被动。前阵子我搭了一套实验环境把 OSPF 从单区域到多区域、再到和 MSTP、VRRP 联动的情况完整跑了一遍顺手把过程中踩过的坑、查过的 error 表、debug 输出都记录下来整理成这份实验报告。不管你是在准备认证考试还是刚接手园区网想要理清 OSPF 的选路逻辑这份内容都值得你花点时间过一遍。1. 实验目的与拓扑规划1.1 为什么要做这个 OSPF 实验很多人学 OSPF 就是背概念——邻居状态机有几个状态、LSA 类型有哪几种、ABR 和 ASBR 的区别是什么。但真到了设备上对着 disp ospf peer 的输出却看不懂邻居卡在 ExStart 或者 Loading 半天不知道从哪里查起。我搭这套环境的目的很直接把协议运行的每个阶段都变成可以观察、可以验证的对象让状态机、LSA、路由计算这些抽象概念在命令行输出里找到对应关系。这次实验的场景设定是一个典型的三层园区网络。核心层两台设备跑 VRRP 做网关冗余汇聚层设备启用 MSTP 防止二层环路同时全网运行 OSPF 打通三层路由。这个组合非常贴近真实项目——你随便找个中大型企业的网络大概率就是这个架构。与其在模拟器里跑一个孤零零的单区域 OSPF不如直接把冗余网关和生成树协议都加进来看看它们和 OSPF 之间会产生什么化学反应。实验用的设备是华为的 eNSP 模拟器AR 路由器用 AR2220交换机用 S5700。选华为生态是因为生产环境里华为设备占有率确实高而且 eNSP 免费、上手快命令和真实设备几乎没差别。你如果手头有真机或者用 GNS3 跑 IOSv思路完全一样命令格式稍作映射就行。1.2 拓扑设计与地址规划我画了一个不算复杂但足够典型的拓扑两台上行核心交换机SW-Core-1 和 SW-Core-2作为 OSPF 骨干区域的一部分下接三台汇聚交换机分别跑在区域 0 和区域 1 里。核心和汇聚之间用三层链路互联每个 VLAN 网关放在核心交换机上通过 VRRP 实现主备切换。地址规划这块我刻意做得规整一些方便后续配置和排障时一眼看出问题。设备接口IP 地址所属区域说明SW-Core-1GE0/0/110.0.0.1/30Area 0连接 SW-Acc-1SW-Core-1GE0/0/210.0.1.1/30Area 0连接 SW-Acc-2SW-Core-1Vlanif10192.168.10.254/24-业务网关VRRP MasterSW-Core-2GE0/0/110.0.0.2/30Area 0连接 SW-Acc-1SW-Core-2Vlanif10192.168.10.253/24-业务网关VRRP BackupSW-Acc-1GE0/0/110.0.0.5/30Area 1上行到 Core-1SW-Acc-1GE0/0/210.0.0.6/30Area 1上行到 Core-2SW-Acc-2GE0/0/110.0.1.5/30Area 0直连核心为什么要把 Router-ID 单独拿出来规划因为 OSPF 的 Router-ID 一旦选举出来就不会变除非进程重启或配置手动修改。如果让设备自动选通常取 loopback 接口地址最大者其次取物理接口最大地址。但生产环境里接口地址改动频繁自动选的 Router-ID 容易乱排障时看到邻居的 Router-ID 根本不知道对应哪台设备。所以我的习惯是给每台设备手动指定比如核心交换机就用 1.1.1.1 和 2.2.2.2汇聚设备依次往下排。后面排障的时候看到 OSPF 邻居表里的 Router-ID马上就能对应到具体设备和位置。ospf 1 router-id 1.1.1.1 这行配置虽然简单但它是整个 OSPF 排障体系里最容易被忽视的基础。2. 基础配置与邻居状态机2.1 进程、区域与接口宣告OSPF 的配置从进程开始。华为设备上一条 ospf 1 router-id 1.1.1.1 就进入了 OSPF 视图后面的 1 是进程号本地有效不要求邻居之间一致。Router-ID 必须是全网唯一否则邻居关系建立不起来或者建立后频繁震荡。这一点我用大白话解释就是OSPF 靠 Router-ID 识别每一台路由器就像身份证号两个人身份证号一样系统就乱了。宣告网段用 network 命令需要同时指定反掩码。反掩码和普通掩码是反着来的比如 192.168.10.0 对应 24 位掩码反掩码就是 0.0.0.255。很多人第一次配 OSPF 会在这里卡住——把 0.0.0.255 写成 255.255.255.0结果宣告进去的网段完全不对。反掩码的每一位0 代表必须匹配1 代表可以不同这个逻辑搞清楚就不会错了。我在实验里把每个互联链路都宣告进了 OSPF[SW-Core-1] ospf 1 router-id 1.1.1.1 [SW-Core-1-ospf-1] area 0 [SW-Core-1-ospf-1-area-0.0.0.0] network 10.0.0.0 0.0.0.3 [SW-Core-1-ospf-1-area-0.0.0.0] network 10.0.1.0 0.0.0.3注意我并没有把 Vlanif10 的业务网段宣告进 OSPF。这是刻意为之——业务网关地址是 VRRP 的虚拟 IP 192.168.10.254这个地址本身就不能作为 OSPF 的 Router-ID 或者接口主地址来跑协议。网关冗余由 VRRP 负责OSPF 只负责三层的路由可达性两者分工明确。如果你把业务网段也宣告进 OSPF可能会导致下游设备学到两条等价路由一条指向虚拟 IP一条指向物理接口反而造成转发路径的混乱。2.2 邻居关系建立的完整过程观察配完基础配置后我习惯先看接口状态确认 OSPF 有没有正常启用[SW-Core-1] display ospf interface输出会列出所有宣告了 OSPF 的接口以及接口所属的区域、网络类型、Cost 值。如果这里列出的接口和你预期的不一致大概率是 network 命令写错了——要么反掩码出错要么宣告的网段没有精确匹配到接口地址。OSPF 的 network 是拿接口 IP 去和宣告条目做匹配的不是把网段里的所有地址都宣告出去这个逻辑要转过来。然后是观察邻居状态机。OSPF 邻居从 Down 到 Full 要经历 Init、2-Way、ExStart、Exchange、Loading 这几个状态。我在 SW-Core-1 上持续观察和 SW-Acc-1 的邻居建立过程[SW-Core-1] display ospf peer稳定后应该看到 State 是 Full如果看到 2-Way 或者 ExStart说明链路有问题或者参数不匹配。邻居状态机描述的是两台设备之间从互不认识到达成路由信息同步的全过程Down初始状态没有收到对端任何 Hello 报文。Init收到了 Hello但自己的 Router-ID 不在对方的邻居列表里。2-Way双方都在对方的邻居列表里此时广播网络会开始选举 DR/BDR。ExStart协商主从关系确定 DD 报文的序列号。Exchange交换链路状态通告摘要即 DD 报文。Loading根据 DD 摘要向邻居请求缺失的完整 LSA。Full链路状态数据库完全同步路由计算完成。排障的时候邻居卡在哪个状态就能反推是哪一层的问题。比如一直停在 Init多半是收到了对端的 Hello 但 Hello 里的参数不对常见的有 Hello/Dead 间隔不一致、区域 ID 不匹配、认证失败。华为设备在接口视图下用 ospf timer hello 10 可以改时间间隔但除非特殊场景不建议动这个值默认的 Hello 10 秒、Dead 40 秒已经能满足绝大多数情况。3. 多区域设计、ABR 角色与 LSA 类型3.1 为什么要拆区域单区域 OSPF 在小规模网络里完全够用但一旦网络规模上来——比如上千台设备——所有路由器都在同一个区域里每台设备都要维护全网所有的链路状态信息。链路状态数据库会变得非常大SPF 计算频繁CPU 和内存压力随之而来。拆区域的本质是把网络分层。区域内部的路由器只需要维护本区域的链路状态数据库区域之间的路由信息由 ABRArea Border Router汇总转发。ABR 是连接骨干区域和非骨干区域的设备它同时维护多个区域的链路状态数据库并负责在区域间传递路由信息。我在实验拓扑里把 SW-Acc-1 单独划到区域 1SW-Core-1 和 SW-Core-2 留在区域 0。这样一来区域 1 内部的链路状态变化不会引起区域 0 内所有设备重新计算 SPF只有 ABR 需要处理和转发这个变化。这就是多区域最核心的价值——故障屏蔽和计算范围隔离。不过多区域有个铁律非骨干区域必须直接连接到骨干区域 0而且在华为设备上所有 ABR 的骨干区域连接不能中断。OSPF 规定非骨干区域之间的路由传递必须经过骨干区域所以 ABR 之间的虚链路、非骨干区域直连之类的做法都会引入设计问题。我在实验里没有做虚链路虚链路本身是一个应急手段正常情况下应该通过物理链路把区域连接到骨干。3.2 ABR 上的 LSA 类型变化与控制区域间路由的传递靠 Type 3 LSASummary LSA由 ABR 生成。ABR 把自己知道的区域内部路由汇总后以 Type 3 LSA 的形式通告到其他区域。这样做的好处是显著削减了链路状态数据库的规模——骨干区域的路由器不需要知道区域 1 内部每一条链路的细节只需要知道去那些网段该往哪走。我在核心交换机上执行[SW-Core-1] display ospf lsdb summary就能看到 Type 3 LSA 的列表每一行包含通告路由器、链路状态 ID 和 Metric。链路状态 ID 是目标网段的地址Metric 是 ABR 到该网段的 cost。Type 3 LSA 在区域间传递时会叠加 cost每经过一个 ABRMetric 就累加一次这个机制决定了区域间选路的结果。ABR 还可以对 Type 3 LSA 做汇总或者过滤。在 ABR 的区域视图下配置 abr-summary 可以手动汇总网段[SW-Core-1-ospf-1-area-0.0.0.1] abr-summary 192.168.20.0 255.255.254.0这个命令会把区域内连续的网段汇总成一条 Type 3 LSA 通告出去。好处是路由表条目少、邻居的 LSDB 更小坏处是如果汇总网段里有断链可能会出现路由黑洞——数据包被发到一个实际不可达的范围内。所以做汇总前必须确认网段的连续性宁缺毋滥。实验里我还特意验证了 Type 1 Router LSA。在区域 1 内部的设备上每台路由器都会生成一条 Type 1 LSA描述自己的接口和邻居关系。区域 1 内部的设备只知道区域 1 内所有设备的 Type 1 LSA区域 0 的设备通过 Type 3 LSA 间接学习到区域 1 的路由——这就是区域隔离的直观体现。ospf abr 的配置本身不复杂但理解清楚 ABR 上 LSA 的生成和转发逻辑是理解整个 OSPF 多区域运行的核心。4. DR/BDR 选举与路由计算4.1 广播链路 DR/BDR 的选举逻辑在以太网这种广播多路访问链路上如果每台路由器都和链路上其他所有路由器建立邻接关系会形成 n 平方的连接风暴。OSPF 的解决办法是选举 DRDesignated Router和 BDRBackup Designated Router。所有设备只需要和 DR、BDR 建立邻接关系DR 负责收集全网链路状态并广播出去BDR 是备胎随时准备接替。选举规则很简单Hello 报文里携带的优先级最高者胜出优先级相同则 Router-ID 最大者胜出。优先级范围 0 到 2550 表示永远不参与选举。默认优先级都是 1所以大 Router-ID 通常会成为 DR。我在实验环境里的广播链路上Core-1 的 Router-ID 是 1.1.1.1Acc-1 的是 3.3.3.3假设最终 DR 的角色由优先级或 Router-ID 决定。注意DR 和 BDR 是接口级别的概念不是设备级别。同一台设备不同接口可以分别担任不同链路的 DR。可以通过修改接口优先级来控制选举结果[SW-Core-1-GigabitEthernet0/0/1] ospf dr-priority 255必须强调一点DR 选举不是抢占式的。一旦 DR 选定即使后面加入一台优先级更高的设备也不会立刻替换现有 DR。只有当前 DR 故障或者 OSPF 进程重启BDR 才会晋升为新的 DR然后重新选举 BDR。这个机制是为了避免 DR 频繁变化导致链路状态数据库反复同步。4.2 Cost 计算与路径选择实验OSPF 的 Cost 是接口开销值默认公式是参考带宽除以接口带宽华为设备参考带宽默认 100Mbps。所以 GE 接口的 Cost 是 100/10001FE 接口是 100/1001这个结果其实有点尴尬——百兆和千兆的 Cost 都是 1只有到了万兆才能看出区别。我在实验里用默认值然后手动改一条链路的 Cost 来观察路径切换。在接口下配置[SW-Core-1-GigabitEthernet0/0/2] ospf cost 100把 Core-1 到 Acc-2 的链路 Cost 从 1 改成 100然后看核心交换机到 Acc-2 的路由表变化[SW-Core-1] display ip routing-table 10.0.2.0 24路由会从直连的 GE0/0/2 切换到经 Core-2 再到 Acc-2 的路径。这就是 OSPF 按 Cost 选路的核心逻辑——选最小的、不数跳数。路由器只看整个路径的 Cost 总和每条链路都会被叠加计算。生产环境里调整 Cost 比策略路由更优雅。比如想让去某个网段的流量优先走某一条链路直接把那条链路的 Cost 调低就行如果链路带宽升级了也可以用 auto cost 让设备自动计算。华为设备上配置 auto cost 参考带宽的命令是[SW-Core-1-ospf-1] bandwidth-reference 1000把参考带宽改成 1000Mbps 后GE 口的 Cost 变成 1000/10001万兆口是 1000/100000.1 取整为 1百兆口变成 1000/10010。这样一来不同速率链路的 Cost 就能拉开差距选路也更合理。这个命令要整网统一配置否则不同设备对同一条链路的 Cost 计算标准不一致容易产生次优路由。5. 与 MSTP、VRRP 的联动实战5.1 网关冗余与 OSPF 路由协议的分工三层园区网里终端用户的网关通常配置在核心交换机上。为了网关冗余我用两台核心交换机跑 VRRP一组业务 VLAN 配置一个 VRRP 组。VRRP 的原理是多个路由器共享一个虚拟 IPMaster 负责转发流量Backup 随时待命Master 故障时 Backup 无缝接管。我把 VRRP 的虚拟 IP 放在了业务网段里比如 Vlanif10 的 VRRP 虚拟 IP 是 192.168.10.254。终端网关指向这个虚拟地址完全感知不到背后有两台物理设备。VRRP 通过发送组播报文来协商主备状态Master 每 1 秒发一次 AdvertisementBackup 如果 3 个周期没收到就切换为 Master。VRRP 和 OSPF 的配合逻辑要理清楚VRRP 解决的是网关层面的冗余终端发往其他网段的流量先到虚拟网关然后由物理设备依据路由表转发OSPF 解决的是路由层面的可达性保证无论哪一台核心交换机成为 Master都能通过最优路径把流量送到目的地。两者各管一段但需要关注一个细节当某台核心设备同时是 VRRP Master 和 OSPF 次优路径的拥有者时流量会先进来再由路由协议送出去这是没问题的反过来如果 Master 没有到目的网段的路由就会直接丢包。5.2 二层环路防护对 OSPF 运行的影响MSTP 和 OSPF 的联动比想象中更微妙。MSTP 工作在二层负责阻断以太网环路OSPF 运行在三层负责路由寻址。表面上互不相干但二层拓扑的变化会直接影响三层链路的通断进而触发 OSPF 邻居震荡。我的实验环境里汇聚交换机到核心交换机有两条物理链路初期没有做任何二层防护时会产生广播风暴。启用 MSTP 之后STP 会阻塞其中一个端口两条物理链路变成只有一条可用。这时如果 OSPF 恰好跑这两条链路上STP 阻塞端口就意味着 OSPF 邻居关系断裂流量路径被迫切换。MSTP 引入更多的变量MSTP 的实例划分不同同一个物理端口在不同实例里的角色可能不同导致某些 VLAN 的流量通、另一些 VLAN 的流量断。OSPF 的 Hello 报文如果需要跨越多个 VLAN 互联就会受到 MSTP 实例状态的影响。实验里最典型的问题就是OSPF 邻居建立不起来排查了一圈发现是 STP 把互联端口阻塞了底层二层的通信都没有三层的 OSPF 当然无从谈起。所以配 OSPF 之前先确认所有互联接口在 STP 里都是 Forwarding 状态。我习惯把 OSPF 互联接口的 STP 开销调小确保三层链路在生成树计算中处于最优路径减少 MSTP 阻塞 OSPF 链路的风险。这个动作可以用接口下的 stp cost 命令实现[SW-Acc-1-GigabitEthernet0/0/1] stp cost 10另外一个实用的做法是把 OSPF 的互联接口配置为 Trunk 并放行必要的 VLAN但不要让业务 VLAN 在这些接口上泛滥。控制二层域的范围既能减小 MSTP 的计算压力也更容易定位 OSPF 的排障边界。ospf mstp vrrp 这个组合是园区网的标准配方但配得好不好、稳不稳定完全看对底层二层状态和三层路由协议之间耦合关系的理解深度。6. 故障排查实战error 表、debug 与抓包6.1 从 error 表快速定位问题前面说了这么多配置和机制真正到了排障现场最快的东西其实是 error 表。华为设备上查 OSPF 错误一条命令就够了display ospf error这条命令输出的是一个计数器表记录各种 OSPF 异常报文的数量。每次邻居震荡、路由丢失先别急着抓包先看这张表问题基本能对号入座。我在实验里见过最常见的几类错误Hello 间隔不匹配在广播网络上OSPF 默认 Hello 10 秒、Dead 40 秒。如果一台设备改了间隔另一台没改两边 Hello 报文会周期性互发但永远不能建立邻居关系。error 表里会看到 Hello interval 相关的计数在增长。区域 ID 不匹配接口宣告到了错误的区域比如一边是 area 0另一边是 area 1邻居关系起不来。error 表里的 Area Mismatch 计数会增长看到这个基本就可以锁定问题方向。认证类型或密钥不匹配配置了区域认证或者接口认证后密钥不一致Hello 报文虽然能收到但认证失败被丢弃。error 表里 Authentication 计数快速增长。重复 Router-ID两台设备配置了相同的 Router-ID邻居建立后震荡。error 表里可能看到 Duplicate Router-ID 相关计数。我在实验里故意把 Acc-2 的 Router-ID 从 2.2.2.2 改成和 Core-1 相同的 1.1.1.1然后观察核心设备上的邻居表发现邻居状态在 Full 和 Down 之间反复横跳。执行 display ospf error 后杜撰的 Router-ID 冲突计数开始增长定位问题非常快。这种场景如果不看 error 表直接抓包要分析的时间要多好几倍。error 表的好用之处在于它把大量协议层面的异常都沉淀成了计数排障时可以快速地、量化地判断问题类型和严重程度。我遇到 OSPF 相关问题第一反应永远是三连display ospf peer、display ospf error、display ospf lsdb。这三条命令走完80% 的问题都能定位。6.2 debug 与抓包的实践对比error 表能告诉你问题类型但想知道具体报文内容和交互细节需要 debug 或者抓包。我在实验里分别试过两种方式各有适用场景。华为设备的 OSPF debug 命令很有用debugging ospf 1 packet开启后控制台会滚动输出 OSPF 的报文收发记录包括 Hello、DD、LSR、LSU 等报文类型以及报文的源地址、目的地址、长度和关键字段。我在排障邻居卡在 Exchange 状态时用 debug 输出能直接看到 DD 报文协商的过程主从关系是否确立、序列号是否一致都能实时看到。但 debug 有个现实问题在真实的生产设备上开启 debug尤其是 debug ospf packet会产生大量日志直接冲击设备 CPU。如果设备本身性能就一般大流量下跑 debug 几分钟可能把控制面打挂。所以生产环境里 debug 一定要慎用开一下确认问题就要立刻关掉。相比之下在模拟器里实验就没有这个顾虑可以随便玩。抓包是另一种思路。我在实验里用 eNSP 自带的抓包功能在核心交换机的互联接口上抓 OSPF 报文。抓到之后用 Wireshark 分析可以清晰看到 Hello 报文里的 Router-ID、区域 ID、Hello/Dead 间隔、认证字段、邻居列表等信息。报文级别的细节比 debug 更全面因为 Wireshark 能按协议解析每一个字段的偏移和含义方便做对比。对于初学者我的建议是先学会看 error 表再看 debug 输出最后才是抓包。error 表是速查debug 是动态跟踪抓包是终极证据。如果遇到问题只会上来就抓包分析半天还看不明白说明协议状态的判断功底还不到位。我自己的习惯是 error 表定位方向debug 确认过程抓包只在需要本质证据或者 debug 信息不足以判断的时候才用。博主圈子里流传的那句话其实很有道理ospf error 表里面查问题老清晰了或者直接 debug抓包都不用。不是抓包没用而是大多数问题到不了需要看报文那一步。7. 实验中的抗毁性与收敛时间验证7.1 主备切换与路由收敛VRRP 和 OSPF 的联动在一开始配置的时候就埋了伏笔——终端访问外部网络的路径是依赖 OSPF 选路的网关冗余由 VRRP 承担。我在实验后半段做了一项关键测试把 VRRP Master 的互联链路直接 shutdown观察业务中断时间以及路由收敛情况。先说 VRRP 的收敛。Master 故障后Backup 最多 3 秒内就能升为新的 Master因为 Advertisement 间隔 1 秒3 个周期没收到报文就切换。这个时间对终端用户而言感知不明显但如果是视频会议或者长连接业务3 秒也是不可接受的所以园区网里一般还会配合接口联动以及链路检测等手段把切换时间压缩到毫秒级。OSPF 的收敛时间则取决于链路故障检测机制和 Hello 定时器。如果把接口直接 shutdown接口状态变化会立刻触发 OSPF 发送 LSU 报文告知邻居链路不可达。邻居在收到 LSU 后重新计算 SPF收敛时间通常在几百毫秒到 1 秒之间。我在实验里实际观测到的是从 shutdown 接口到核心交换机路由表更新大约耗时 800 毫秒左右。相比之下如果只是链路故障但没有物理接口 down——比如中间交换机断电或者光模块异常——OSPF 要等到 Dead 定时器超时才能认定邻居不可达默认 40 秒。这 40 秒之内数据包都往死链路上送业务完全中断。所以生产环境里针对关键链路会开启 BFD 联动 OSPFBFD 的检测间隔可以做到 100 毫秒以内配合 OSPF 的快速收敛机制大幅缩短故障恢复时间。BFD 在华为设备上配置比较简单[SW-Core-1] bfd [SW-Core-1-bfd] interface GigabitEthernet0/0/1 [SW-Core-1-GigabitEthernet0/0/1] ospf bfd enable配置完 BFD 后我又做了一次同样的 shutdown 测试路由收敛时间从 800 毫秒降到了接近 50 毫秒。这个实验数据对比非常直观同样的故障有没有 BFD业务中断的差别是数量级的。7.2 等价路由与负载分担验证多区域设计加核心双机天然会产生等价路由。我在核心交换机上看到的典型场景是去往某个业务网段有两条路径Cost 相同形成两条等价路由ECMP。华为设备默认对等价路由做负载分担逐包转发还是逐流转发取决于设备的转发策略。我通过 display ip routing-table 查看路由表看到同一个目的网段有两条下一跳不同的条目Cost 都是 10。然后用 display ospf routing 确认这两条路由的详细来源。OSPF 协议在华为设备上默认支持等价路由的负载分担但需要注意如果开启了快速重路由FRR或者策略路由可能会改变默认行为。等价路由在实际项目里的价值是实现链路利用率的提升但也带来一个隐患如果其中一条链路质量劣化——比如光模块误码率高、丢包增加——OSPF 的 Cost 并没有变化流量依然均匀分担用户感知到的是间歇性卡顿而不是完全中断。要发现这类问题单纯靠 OSPF 是不行的需要结合链路质量监控手段比如用 NQA 探测或者 NetStream 流量分析。我在实验里还验证了在等价路由存在的情况下对其中一条链路手动调整 Cost让路由收敛到单条路径再用 ping 测试丢包情况。整个过程验证了 OSPF 路由计算的收敛性和稳定性也没有出现路由环路的问题。这部分的结论是OSPF 的多路径能力为网络提供了天然的冗余和负载分担基础但真正的质量保障还是要靠设备状态监控和应用层探测来补充。8. 实验收获与配置心得整套实验做下来我对 OSPF 的理解提升是非常明显的。纸上谈兵的时候LSA 类型、邻接状态机都是一些需要背的名词真正在设备上跑完一遍之后每一个名词都有了对应的命令输出和报文交互过程。比如说 Type 1 LSA 的 AdvRouter 字段和 Router-ID 的关系不看 display ospf lsdb 的输出很难形成直观认知。我个人的最大体会是OSPF 排障真的要先看 error 表再动其他工具。之前遇到邻居起不来总是直接开抓包在 Wireshark 里看 Hello 报文、看 DD 报文费时费力还不一定能定位。后来被有经验的同事点醒改成先看 display ospf error几秒钟就能锁定方向再结合 targeted 的 debug 输出确认细节效率高了一大截。ospf error 表里面查问题老清晰了或者直接 debug抓包都不用——这句话只有自己踩过坑才会真正信服。对于准备把 OSPF 用到生产环境的同行我有几条建议可以给到。一是 Router-ID 一定要手工规划统一不要依赖自动选举能在前期减少很多识别成本。二是区域划分要从网络规模和故障域角度出发不要为了多区域而多区域有时候一个整洁的单区域比一个混乱的多区域更好维护。三是和 MSTP 联动时先确认二层转发正常再排查三层协议问题。四是关键链路上尽早启用 BFDOSPF 的 40 秒 Dead 超时在业务面前太慢了。五是所有变更前先保存当前配置OSPF 调整往往涉及多条命令操作失误时能回退很重要。最后说一个调试小技巧华为设备上 display ospf lsdb 输出的每条 LSA 都有 Age 字段观察它是否持续增长可以判断链路状态信息是否还在正常老化更新。如果 Age 一直停在某个值不动说明 LSDB 的刷新机制出了问题多半是设备间的时间不同步或者网络中存在单向通信故障。这类细节虽然不起眼但真正遇到诡异故障时可能就是突破口。 OSPF实验指南：邻居状态机、LSA、多区域与VRRP/MSTP联动排障实践
OSPF 是我日常工作里打交道最多的动态路由协议没有之一。做网络这一行如果连 OSPF 的邻居关系、LSA 类型、区域设计都说不清楚面试和排障的时候都会很被动。前阵子我搭了一套实验环境把 OSPF 从单区域到多区域、再到和 MSTP、VRRP 联动的情况完整跑了一遍顺手把过程中踩过的坑、查过的 error 表、debug 输出都记录下来整理成这份实验报告。不管你是在准备认证考试还是刚接手园区网想要理清 OSPF 的选路逻辑这份内容都值得你花点时间过一遍。1. 实验目的与拓扑规划1.1 为什么要做这个 OSPF 实验很多人学 OSPF 就是背概念——邻居状态机有几个状态、LSA 类型有哪几种、ABR 和 ASBR 的区别是什么。但真到了设备上对着 disp ospf peer 的输出却看不懂邻居卡在 ExStart 或者 Loading 半天不知道从哪里查起。我搭这套环境的目的很直接把协议运行的每个阶段都变成可以观察、可以验证的对象让状态机、LSA、路由计算这些抽象概念在命令行输出里找到对应关系。这次实验的场景设定是一个典型的三层园区网络。核心层两台设备跑 VRRP 做网关冗余汇聚层设备启用 MSTP 防止二层环路同时全网运行 OSPF 打通三层路由。这个组合非常贴近真实项目——你随便找个中大型企业的网络大概率就是这个架构。与其在模拟器里跑一个孤零零的单区域 OSPF不如直接把冗余网关和生成树协议都加进来看看它们和 OSPF 之间会产生什么化学反应。实验用的设备是华为的 eNSP 模拟器AR 路由器用 AR2220交换机用 S5700。选华为生态是因为生产环境里华为设备占有率确实高而且 eNSP 免费、上手快命令和真实设备几乎没差别。你如果手头有真机或者用 GNS3 跑 IOSv思路完全一样命令格式稍作映射就行。1.2 拓扑设计与地址规划我画了一个不算复杂但足够典型的拓扑两台上行核心交换机SW-Core-1 和 SW-Core-2作为 OSPF 骨干区域的一部分下接三台汇聚交换机分别跑在区域 0 和区域 1 里。核心和汇聚之间用三层链路互联每个 VLAN 网关放在核心交换机上通过 VRRP 实现主备切换。地址规划这块我刻意做得规整一些方便后续配置和排障时一眼看出问题。设备接口IP 地址所属区域说明SW-Core-1GE0/0/110.0.0.1/30Area 0连接 SW-Acc-1SW-Core-1GE0/0/210.0.1.1/30Area 0连接 SW-Acc-2SW-Core-1Vlanif10192.168.10.254/24-业务网关VRRP MasterSW-Core-2GE0/0/110.0.0.2/30Area 0连接 SW-Acc-1SW-Core-2Vlanif10192.168.10.253/24-业务网关VRRP BackupSW-Acc-1GE0/0/110.0.0.5/30Area 1上行到 Core-1SW-Acc-1GE0/0/210.0.0.6/30Area 1上行到 Core-2SW-Acc-2GE0/0/110.0.1.5/30Area 0直连核心为什么要把 Router-ID 单独拿出来规划因为 OSPF 的 Router-ID 一旦选举出来就不会变除非进程重启或配置手动修改。如果让设备自动选通常取 loopback 接口地址最大者其次取物理接口最大地址。但生产环境里接口地址改动频繁自动选的 Router-ID 容易乱排障时看到邻居的 Router-ID 根本不知道对应哪台设备。所以我的习惯是给每台设备手动指定比如核心交换机就用 1.1.1.1 和 2.2.2.2汇聚设备依次往下排。后面排障的时候看到 OSPF 邻居表里的 Router-ID马上就能对应到具体设备和位置。ospf 1 router-id 1.1.1.1 这行配置虽然简单但它是整个 OSPF 排障体系里最容易被忽视的基础。2. 基础配置与邻居状态机2.1 进程、区域与接口宣告OSPF 的配置从进程开始。华为设备上一条 ospf 1 router-id 1.1.1.1 就进入了 OSPF 视图后面的 1 是进程号本地有效不要求邻居之间一致。Router-ID 必须是全网唯一否则邻居关系建立不起来或者建立后频繁震荡。这一点我用大白话解释就是OSPF 靠 Router-ID 识别每一台路由器就像身份证号两个人身份证号一样系统就乱了。宣告网段用 network 命令需要同时指定反掩码。反掩码和普通掩码是反着来的比如 192.168.10.0 对应 24 位掩码反掩码就是 0.0.0.255。很多人第一次配 OSPF 会在这里卡住——把 0.0.0.255 写成 255.255.255.0结果宣告进去的网段完全不对。反掩码的每一位0 代表必须匹配1 代表可以不同这个逻辑搞清楚就不会错了。我在实验里把每个互联链路都宣告进了 OSPF[SW-Core-1] ospf 1 router-id 1.1.1.1 [SW-Core-1-ospf-1] area 0 [SW-Core-1-ospf-1-area-0.0.0.0] network 10.0.0.0 0.0.0.3 [SW-Core-1-ospf-1-area-0.0.0.0] network 10.0.1.0 0.0.0.3注意我并没有把 Vlanif10 的业务网段宣告进 OSPF。这是刻意为之——业务网关地址是 VRRP 的虚拟 IP 192.168.10.254这个地址本身就不能作为 OSPF 的 Router-ID 或者接口主地址来跑协议。网关冗余由 VRRP 负责OSPF 只负责三层的路由可达性两者分工明确。如果你把业务网段也宣告进 OSPF可能会导致下游设备学到两条等价路由一条指向虚拟 IP一条指向物理接口反而造成转发路径的混乱。2.2 邻居关系建立的完整过程观察配完基础配置后我习惯先看接口状态确认 OSPF 有没有正常启用[SW-Core-1] display ospf interface输出会列出所有宣告了 OSPF 的接口以及接口所属的区域、网络类型、Cost 值。如果这里列出的接口和你预期的不一致大概率是 network 命令写错了——要么反掩码出错要么宣告的网段没有精确匹配到接口地址。OSPF 的 network 是拿接口 IP 去和宣告条目做匹配的不是把网段里的所有地址都宣告出去这个逻辑要转过来。然后是观察邻居状态机。OSPF 邻居从 Down 到 Full 要经历 Init、2-Way、ExStart、Exchange、Loading 这几个状态。我在 SW-Core-1 上持续观察和 SW-Acc-1 的邻居建立过程[SW-Core-1] display ospf peer稳定后应该看到 State 是 Full如果看到 2-Way 或者 ExStart说明链路有问题或者参数不匹配。邻居状态机描述的是两台设备之间从互不认识到达成路由信息同步的全过程Down初始状态没有收到对端任何 Hello 报文。Init收到了 Hello但自己的 Router-ID 不在对方的邻居列表里。2-Way双方都在对方的邻居列表里此时广播网络会开始选举 DR/BDR。ExStart协商主从关系确定 DD 报文的序列号。Exchange交换链路状态通告摘要即 DD 报文。Loading根据 DD 摘要向邻居请求缺失的完整 LSA。Full链路状态数据库完全同步路由计算完成。排障的时候邻居卡在哪个状态就能反推是哪一层的问题。比如一直停在 Init多半是收到了对端的 Hello 但 Hello 里的参数不对常见的有 Hello/Dead 间隔不一致、区域 ID 不匹配、认证失败。华为设备在接口视图下用 ospf timer hello 10 可以改时间间隔但除非特殊场景不建议动这个值默认的 Hello 10 秒、Dead 40 秒已经能满足绝大多数情况。3. 多区域设计、ABR 角色与 LSA 类型3.1 为什么要拆区域单区域 OSPF 在小规模网络里完全够用但一旦网络规模上来——比如上千台设备——所有路由器都在同一个区域里每台设备都要维护全网所有的链路状态信息。链路状态数据库会变得非常大SPF 计算频繁CPU 和内存压力随之而来。拆区域的本质是把网络分层。区域内部的路由器只需要维护本区域的链路状态数据库区域之间的路由信息由 ABRArea Border Router汇总转发。ABR 是连接骨干区域和非骨干区域的设备它同时维护多个区域的链路状态数据库并负责在区域间传递路由信息。我在实验拓扑里把 SW-Acc-1 单独划到区域 1SW-Core-1 和 SW-Core-2 留在区域 0。这样一来区域 1 内部的链路状态变化不会引起区域 0 内所有设备重新计算 SPF只有 ABR 需要处理和转发这个变化。这就是多区域最核心的价值——故障屏蔽和计算范围隔离。不过多区域有个铁律非骨干区域必须直接连接到骨干区域 0而且在华为设备上所有 ABR 的骨干区域连接不能中断。OSPF 规定非骨干区域之间的路由传递必须经过骨干区域所以 ABR 之间的虚链路、非骨干区域直连之类的做法都会引入设计问题。我在实验里没有做虚链路虚链路本身是一个应急手段正常情况下应该通过物理链路把区域连接到骨干。3.2 ABR 上的 LSA 类型变化与控制区域间路由的传递靠 Type 3 LSASummary LSA由 ABR 生成。ABR 把自己知道的区域内部路由汇总后以 Type 3 LSA 的形式通告到其他区域。这样做的好处是显著削减了链路状态数据库的规模——骨干区域的路由器不需要知道区域 1 内部每一条链路的细节只需要知道去那些网段该往哪走。我在核心交换机上执行[SW-Core-1] display ospf lsdb summary就能看到 Type 3 LSA 的列表每一行包含通告路由器、链路状态 ID 和 Metric。链路状态 ID 是目标网段的地址Metric 是 ABR 到该网段的 cost。Type 3 LSA 在区域间传递时会叠加 cost每经过一个 ABRMetric 就累加一次这个机制决定了区域间选路的结果。ABR 还可以对 Type 3 LSA 做汇总或者过滤。在 ABR 的区域视图下配置 abr-summary 可以手动汇总网段[SW-Core-1-ospf-1-area-0.0.0.1] abr-summary 192.168.20.0 255.255.254.0这个命令会把区域内连续的网段汇总成一条 Type 3 LSA 通告出去。好处是路由表条目少、邻居的 LSDB 更小坏处是如果汇总网段里有断链可能会出现路由黑洞——数据包被发到一个实际不可达的范围内。所以做汇总前必须确认网段的连续性宁缺毋滥。实验里我还特意验证了 Type 1 Router LSA。在区域 1 内部的设备上每台路由器都会生成一条 Type 1 LSA描述自己的接口和邻居关系。区域 1 内部的设备只知道区域 1 内所有设备的 Type 1 LSA区域 0 的设备通过 Type 3 LSA 间接学习到区域 1 的路由——这就是区域隔离的直观体现。ospf abr 的配置本身不复杂但理解清楚 ABR 上 LSA 的生成和转发逻辑是理解整个 OSPF 多区域运行的核心。4. DR/BDR 选举与路由计算4.1 广播链路 DR/BDR 的选举逻辑在以太网这种广播多路访问链路上如果每台路由器都和链路上其他所有路由器建立邻接关系会形成 n 平方的连接风暴。OSPF 的解决办法是选举 DRDesignated Router和 BDRBackup Designated Router。所有设备只需要和 DR、BDR 建立邻接关系DR 负责收集全网链路状态并广播出去BDR 是备胎随时准备接替。选举规则很简单Hello 报文里携带的优先级最高者胜出优先级相同则 Router-ID 最大者胜出。优先级范围 0 到 2550 表示永远不参与选举。默认优先级都是 1所以大 Router-ID 通常会成为 DR。我在实验环境里的广播链路上Core-1 的 Router-ID 是 1.1.1.1Acc-1 的是 3.3.3.3假设最终 DR 的角色由优先级或 Router-ID 决定。注意DR 和 BDR 是接口级别的概念不是设备级别。同一台设备不同接口可以分别担任不同链路的 DR。可以通过修改接口优先级来控制选举结果[SW-Core-1-GigabitEthernet0/0/1] ospf dr-priority 255必须强调一点DR 选举不是抢占式的。一旦 DR 选定即使后面加入一台优先级更高的设备也不会立刻替换现有 DR。只有当前 DR 故障或者 OSPF 进程重启BDR 才会晋升为新的 DR然后重新选举 BDR。这个机制是为了避免 DR 频繁变化导致链路状态数据库反复同步。4.2 Cost 计算与路径选择实验OSPF 的 Cost 是接口开销值默认公式是参考带宽除以接口带宽华为设备参考带宽默认 100Mbps。所以 GE 接口的 Cost 是 100/10001FE 接口是 100/1001这个结果其实有点尴尬——百兆和千兆的 Cost 都是 1只有到了万兆才能看出区别。我在实验里用默认值然后手动改一条链路的 Cost 来观察路径切换。在接口下配置[SW-Core-1-GigabitEthernet0/0/2] ospf cost 100把 Core-1 到 Acc-2 的链路 Cost 从 1 改成 100然后看核心交换机到 Acc-2 的路由表变化[SW-Core-1] display ip routing-table 10.0.2.0 24路由会从直连的 GE0/0/2 切换到经 Core-2 再到 Acc-2 的路径。这就是 OSPF 按 Cost 选路的核心逻辑——选最小的、不数跳数。路由器只看整个路径的 Cost 总和每条链路都会被叠加计算。生产环境里调整 Cost 比策略路由更优雅。比如想让去某个网段的流量优先走某一条链路直接把那条链路的 Cost 调低就行如果链路带宽升级了也可以用 auto cost 让设备自动计算。华为设备上配置 auto cost 参考带宽的命令是[SW-Core-1-ospf-1] bandwidth-reference 1000把参考带宽改成 1000Mbps 后GE 口的 Cost 变成 1000/10001万兆口是 1000/100000.1 取整为 1百兆口变成 1000/10010。这样一来不同速率链路的 Cost 就能拉开差距选路也更合理。这个命令要整网统一配置否则不同设备对同一条链路的 Cost 计算标准不一致容易产生次优路由。5. 与 MSTP、VRRP 的联动实战5.1 网关冗余与 OSPF 路由协议的分工三层园区网里终端用户的网关通常配置在核心交换机上。为了网关冗余我用两台核心交换机跑 VRRP一组业务 VLAN 配置一个 VRRP 组。VRRP 的原理是多个路由器共享一个虚拟 IPMaster 负责转发流量Backup 随时待命Master 故障时 Backup 无缝接管。我把 VRRP 的虚拟 IP 放在了业务网段里比如 Vlanif10 的 VRRP 虚拟 IP 是 192.168.10.254。终端网关指向这个虚拟地址完全感知不到背后有两台物理设备。VRRP 通过发送组播报文来协商主备状态Master 每 1 秒发一次 AdvertisementBackup 如果 3 个周期没收到就切换为 Master。VRRP 和 OSPF 的配合逻辑要理清楚VRRP 解决的是网关层面的冗余终端发往其他网段的流量先到虚拟网关然后由物理设备依据路由表转发OSPF 解决的是路由层面的可达性保证无论哪一台核心交换机成为 Master都能通过最优路径把流量送到目的地。两者各管一段但需要关注一个细节当某台核心设备同时是 VRRP Master 和 OSPF 次优路径的拥有者时流量会先进来再由路由协议送出去这是没问题的反过来如果 Master 没有到目的网段的路由就会直接丢包。5.2 二层环路防护对 OSPF 运行的影响MSTP 和 OSPF 的联动比想象中更微妙。MSTP 工作在二层负责阻断以太网环路OSPF 运行在三层负责路由寻址。表面上互不相干但二层拓扑的变化会直接影响三层链路的通断进而触发 OSPF 邻居震荡。我的实验环境里汇聚交换机到核心交换机有两条物理链路初期没有做任何二层防护时会产生广播风暴。启用 MSTP 之后STP 会阻塞其中一个端口两条物理链路变成只有一条可用。这时如果 OSPF 恰好跑这两条链路上STP 阻塞端口就意味着 OSPF 邻居关系断裂流量路径被迫切换。MSTP 引入更多的变量MSTP 的实例划分不同同一个物理端口在不同实例里的角色可能不同导致某些 VLAN 的流量通、另一些 VLAN 的流量断。OSPF 的 Hello 报文如果需要跨越多个 VLAN 互联就会受到 MSTP 实例状态的影响。实验里最典型的问题就是OSPF 邻居建立不起来排查了一圈发现是 STP 把互联端口阻塞了底层二层的通信都没有三层的 OSPF 当然无从谈起。所以配 OSPF 之前先确认所有互联接口在 STP 里都是 Forwarding 状态。我习惯把 OSPF 互联接口的 STP 开销调小确保三层链路在生成树计算中处于最优路径减少 MSTP 阻塞 OSPF 链路的风险。这个动作可以用接口下的 stp cost 命令实现[SW-Acc-1-GigabitEthernet0/0/1] stp cost 10另外一个实用的做法是把 OSPF 的互联接口配置为 Trunk 并放行必要的 VLAN但不要让业务 VLAN 在这些接口上泛滥。控制二层域的范围既能减小 MSTP 的计算压力也更容易定位 OSPF 的排障边界。ospf mstp vrrp 这个组合是园区网的标准配方但配得好不好、稳不稳定完全看对底层二层状态和三层路由协议之间耦合关系的理解深度。6. 故障排查实战error 表、debug 与抓包6.1 从 error 表快速定位问题前面说了这么多配置和机制真正到了排障现场最快的东西其实是 error 表。华为设备上查 OSPF 错误一条命令就够了display ospf error这条命令输出的是一个计数器表记录各种 OSPF 异常报文的数量。每次邻居震荡、路由丢失先别急着抓包先看这张表问题基本能对号入座。我在实验里见过最常见的几类错误Hello 间隔不匹配在广播网络上OSPF 默认 Hello 10 秒、Dead 40 秒。如果一台设备改了间隔另一台没改两边 Hello 报文会周期性互发但永远不能建立邻居关系。error 表里会看到 Hello interval 相关的计数在增长。区域 ID 不匹配接口宣告到了错误的区域比如一边是 area 0另一边是 area 1邻居关系起不来。error 表里的 Area Mismatch 计数会增长看到这个基本就可以锁定问题方向。认证类型或密钥不匹配配置了区域认证或者接口认证后密钥不一致Hello 报文虽然能收到但认证失败被丢弃。error 表里 Authentication 计数快速增长。重复 Router-ID两台设备配置了相同的 Router-ID邻居建立后震荡。error 表里可能看到 Duplicate Router-ID 相关计数。我在实验里故意把 Acc-2 的 Router-ID 从 2.2.2.2 改成和 Core-1 相同的 1.1.1.1然后观察核心设备上的邻居表发现邻居状态在 Full 和 Down 之间反复横跳。执行 display ospf error 后杜撰的 Router-ID 冲突计数开始增长定位问题非常快。这种场景如果不看 error 表直接抓包要分析的时间要多好几倍。error 表的好用之处在于它把大量协议层面的异常都沉淀成了计数排障时可以快速地、量化地判断问题类型和严重程度。我遇到 OSPF 相关问题第一反应永远是三连display ospf peer、display ospf error、display ospf lsdb。这三条命令走完80% 的问题都能定位。6.2 debug 与抓包的实践对比error 表能告诉你问题类型但想知道具体报文内容和交互细节需要 debug 或者抓包。我在实验里分别试过两种方式各有适用场景。华为设备的 OSPF debug 命令很有用debugging ospf 1 packet开启后控制台会滚动输出 OSPF 的报文收发记录包括 Hello、DD、LSR、LSU 等报文类型以及报文的源地址、目的地址、长度和关键字段。我在排障邻居卡在 Exchange 状态时用 debug 输出能直接看到 DD 报文协商的过程主从关系是否确立、序列号是否一致都能实时看到。但 debug 有个现实问题在真实的生产设备上开启 debug尤其是 debug ospf packet会产生大量日志直接冲击设备 CPU。如果设备本身性能就一般大流量下跑 debug 几分钟可能把控制面打挂。所以生产环境里 debug 一定要慎用开一下确认问题就要立刻关掉。相比之下在模拟器里实验就没有这个顾虑可以随便玩。抓包是另一种思路。我在实验里用 eNSP 自带的抓包功能在核心交换机的互联接口上抓 OSPF 报文。抓到之后用 Wireshark 分析可以清晰看到 Hello 报文里的 Router-ID、区域 ID、Hello/Dead 间隔、认证字段、邻居列表等信息。报文级别的细节比 debug 更全面因为 Wireshark 能按协议解析每一个字段的偏移和含义方便做对比。对于初学者我的建议是先学会看 error 表再看 debug 输出最后才是抓包。error 表是速查debug 是动态跟踪抓包是终极证据。如果遇到问题只会上来就抓包分析半天还看不明白说明协议状态的判断功底还不到位。我自己的习惯是 error 表定位方向debug 确认过程抓包只在需要本质证据或者 debug 信息不足以判断的时候才用。博主圈子里流传的那句话其实很有道理ospf error 表里面查问题老清晰了或者直接 debug抓包都不用。不是抓包没用而是大多数问题到不了需要看报文那一步。7. 实验中的抗毁性与收敛时间验证7.1 主备切换与路由收敛VRRP 和 OSPF 的联动在一开始配置的时候就埋了伏笔——终端访问外部网络的路径是依赖 OSPF 选路的网关冗余由 VRRP 承担。我在实验后半段做了一项关键测试把 VRRP Master 的互联链路直接 shutdown观察业务中断时间以及路由收敛情况。先说 VRRP 的收敛。Master 故障后Backup 最多 3 秒内就能升为新的 Master因为 Advertisement 间隔 1 秒3 个周期没收到报文就切换。这个时间对终端用户而言感知不明显但如果是视频会议或者长连接业务3 秒也是不可接受的所以园区网里一般还会配合接口联动以及链路检测等手段把切换时间压缩到毫秒级。OSPF 的收敛时间则取决于链路故障检测机制和 Hello 定时器。如果把接口直接 shutdown接口状态变化会立刻触发 OSPF 发送 LSU 报文告知邻居链路不可达。邻居在收到 LSU 后重新计算 SPF收敛时间通常在几百毫秒到 1 秒之间。我在实验里实际观测到的是从 shutdown 接口到核心交换机路由表更新大约耗时 800 毫秒左右。相比之下如果只是链路故障但没有物理接口 down——比如中间交换机断电或者光模块异常——OSPF 要等到 Dead 定时器超时才能认定邻居不可达默认 40 秒。这 40 秒之内数据包都往死链路上送业务完全中断。所以生产环境里针对关键链路会开启 BFD 联动 OSPFBFD 的检测间隔可以做到 100 毫秒以内配合 OSPF 的快速收敛机制大幅缩短故障恢复时间。BFD 在华为设备上配置比较简单[SW-Core-1] bfd [SW-Core-1-bfd] interface GigabitEthernet0/0/1 [SW-Core-1-GigabitEthernet0/0/1] ospf bfd enable配置完 BFD 后我又做了一次同样的 shutdown 测试路由收敛时间从 800 毫秒降到了接近 50 毫秒。这个实验数据对比非常直观同样的故障有没有 BFD业务中断的差别是数量级的。7.2 等价路由与负载分担验证多区域设计加核心双机天然会产生等价路由。我在核心交换机上看到的典型场景是去往某个业务网段有两条路径Cost 相同形成两条等价路由ECMP。华为设备默认对等价路由做负载分担逐包转发还是逐流转发取决于设备的转发策略。我通过 display ip routing-table 查看路由表看到同一个目的网段有两条下一跳不同的条目Cost 都是 10。然后用 display ospf routing 确认这两条路由的详细来源。OSPF 协议在华为设备上默认支持等价路由的负载分担但需要注意如果开启了快速重路由FRR或者策略路由可能会改变默认行为。等价路由在实际项目里的价值是实现链路利用率的提升但也带来一个隐患如果其中一条链路质量劣化——比如光模块误码率高、丢包增加——OSPF 的 Cost 并没有变化流量依然均匀分担用户感知到的是间歇性卡顿而不是完全中断。要发现这类问题单纯靠 OSPF 是不行的需要结合链路质量监控手段比如用 NQA 探测或者 NetStream 流量分析。我在实验里还验证了在等价路由存在的情况下对其中一条链路手动调整 Cost让路由收敛到单条路径再用 ping 测试丢包情况。整个过程验证了 OSPF 路由计算的收敛性和稳定性也没有出现路由环路的问题。这部分的结论是OSPF 的多路径能力为网络提供了天然的冗余和负载分担基础但真正的质量保障还是要靠设备状态监控和应用层探测来补充。8. 实验收获与配置心得整套实验做下来我对 OSPF 的理解提升是非常明显的。纸上谈兵的时候LSA 类型、邻接状态机都是一些需要背的名词真正在设备上跑完一遍之后每一个名词都有了对应的命令输出和报文交互过程。比如说 Type 1 LSA 的 AdvRouter 字段和 Router-ID 的关系不看 display ospf lsdb 的输出很难形成直观认知。我个人的最大体会是OSPF 排障真的要先看 error 表再动其他工具。之前遇到邻居起不来总是直接开抓包在 Wireshark 里看 Hello 报文、看 DD 报文费时费力还不一定能定位。后来被有经验的同事点醒改成先看 display ospf error几秒钟就能锁定方向再结合 targeted 的 debug 输出确认细节效率高了一大截。ospf error 表里面查问题老清晰了或者直接 debug抓包都不用——这句话只有自己踩过坑才会真正信服。对于准备把 OSPF 用到生产环境的同行我有几条建议可以给到。一是 Router-ID 一定要手工规划统一不要依赖自动选举能在前期减少很多识别成本。二是区域划分要从网络规模和故障域角度出发不要为了多区域而多区域有时候一个整洁的单区域比一个混乱的多区域更好维护。三是和 MSTP 联动时先确认二层转发正常再排查三层协议问题。四是关键链路上尽早启用 BFDOSPF 的 40 秒 Dead 超时在业务面前太慢了。五是所有变更前先保存当前配置OSPF 调整往往涉及多条命令操作失误时能回退很重要。最后说一个调试小技巧华为设备上 display ospf lsdb 输出的每条 LSA 都有 Age 字段观察它是否持续增长可以判断链路状态信息是否还在正常老化更新。如果 Age 一直停在某个值不动说明 LSDB 的刷新机制出了问题多半是设备间的时间不同步或者网络中存在单向通信故障。这类细节虽然不起眼但真正遇到诡异故障时可能就是突破口。