OSPF 这个协议搞网络的人基本都绕不开。不管是在企业网、园区网还是数据中心OSPF 都是最常见的动态路由协议之一。前阵子我搭了一套 OSPF 综合实验拓扑把多区域、ABR 路由汇总、特殊区域以及和 MSTP、VRRP 的联动全部揉在一起做了验证期间踩了不少坑也把排查手段重新捋了一遍。这篇文章把整个实验过程写出来给准备考数通认证、做毕业设计或者刚接手网络维护的朋友一个可复现的参考。这套实验很典型一组设备跑 OSPF 多区域底层用 MSTP 做二层防环网关用 VRRP 做冗余三层出口再让 OSPF 把路由传出去。整体考察的其实是一个网络工程师最核心的组网能力——不是会敲命令而是要能解释清楚每一步配置为什么这么做出问题的时候怎么顺着链路一层层找到病根。1. 综合实验组网需求拆解与整体规划先说清楚这张拓扑要解决什么问题。很多朋友一开始做综合实验容易犯一个毛病设备一堆协议一堆配置敲完了 ping 通就以为实验做完了。实际上综合实验的价值在于还原真实网络中的联动关系而不是简单堆叠协议。所以我在做规划的时候先问了三个问题二层怎么防环、网关怎么冗余、跨区域路由怎么传。1.1 为什么把 OSPF、MSTP、VRRP 组合在一张拓扑里这三个技术组合起来是有现实逻辑的。真实园区网络通常是分层架构接入层负责终端接入汇聚层跑网关和冗余核心层跑路由。接入层设备数量多如果每一台都跑动态路由路由条目管理复杂协议开销也大所以接入到汇聚这段一般用二层靠 STP 类协议防环。汇聚层直接面向终端网关不能单点故障所以要用 VRRP 做虚拟网关冗余。汇聚到核心这一段要承载跨楼宇、跨园区的路由通信OSPF 自然就成了核心路由协议的候选。这种组合也是我故意为之的。OSPF 解决的是“路由怎么走”的问题MSTP 解决的是“二层环路怎么防”的问题VRRP 解决的是“网关挂了怎么办”的问题。三个问题在实际运维中经常会同时出现在一次故障里如果你只在模拟器里单独验证过某一个协议碰到三者的交互故障时很容易毫无头绪。另一个原因是实验的真实感。我记得自己以前只搭一个纯 OSPF 环境三台路由器跑起来看一看邻居关系看一下路由表五分钟结束总觉得差点什么。后来去项目现场处理一次双核心设备重启的故障才发现 OSPF、VRRP、STP 的收敛过程是纠缠在一起的二层拓扑变化会影响三层邻居VRRP 切换会引发 ARP 表变化进而影响 OSPF 报文转发。所以我现在做综合实验一定会把这三层的东西都放进去。1.2 地址、区域与设备角色规划规划永远排在配置前面。我这张拓扑用了 6 台设备按角色分成三类两台核心交换机两台汇聚交换机两台路由器和一组终端 PC。拓扑不算复杂但能覆盖绝大多数综合实验考点。区域规划上我设计了 OSPF 的三区域结构核心设备部署在区域 0两台汇聚交换机分别下沉到区域 1 和区域 2。这样一来汇聚交换机天然承担 ABR 角色负责把非骨干区域的直连路由以 Type 3 LSA 的形式通告进骨干区域同时也把骨干路由下发到各自区域。这个设计能让你实实在在感受到 ABR 的工作过程而不是在单区域环境里纸上谈兵。地址规划我遵循几个原则Loopback 地址全部用设备编号做第四段方便记忆和排错互联地址用 10.0.x.x 的 30 位掩码业务网段单独规划成 24 位段并且保证与设备管理地址、互联地址不在一个网段内。这样一来每条路由从哪来、去往哪光看网段就能有个大概判断。下面是当时用到的核心规划表设备角色设备名称区域归属关键地址主要职责核心交换机Core-1 / Core-2Area 01.1.1.1 / 2.2.2.2骨干路由、OSPF 进程边界汇聚交换机Agg-1 / Agg-2Area 1 / Area 23.3.3.3 / 4.4.4.4ABR、业务网关、VRRP 成员出口路由器R1 / R2Area 05.5.5.5 / 6.6.6.6模拟外部网络、区域边界有了这张表后面的配置就非常省心。每个网段、每台设备该干什么心里清清楚楚不会出现配置到一半忘了哪个接口属于哪个区域的情况。2. OSPF 多区域关键配置与原理细节OSPF 本身配置不难难在理解区域之间的关系和 LSA 的传递逻辑。这一节我把配置过程拆开讲重点是 Router ID、进程号、区域划分和 ABR 行为。2.1 进程号与 Router ID 的选择逻辑很多新手对ospf 1 router-id 1.1.1.1这行命令只停留在“要写”的层面其实背后有几个容易踩坑的细节。进程号在华为设备上的作用范围是本地有效的只在单台设备上有意义两台设备之间并不要求进程号一致它们建立邻居关系时看的是 Router ID、区域 ID、认证等信息而不是进程号。不过在实际工程中我还是建议全网统一进程号省得后续排查时混淆。进程号那么好记吗其实不然统一成ospf 1或者ospf 100都可以关键是让所有设备保持同一个习惯。Router ID 则相反它必须全网唯一且实际传递在很多报文交互中。OSPF 路由器会使用 Router ID 来标记自己比如在 Type 1 LSA 中就用 Router ID 标识始发路由器。如果两台设备 Router ID 相同会出现邻居震荡、路由表异常等非常隐蔽的问题。Router ID 的选取规则是优先使用手工配置的router-id命令其次选择最大 Loopback 接口地址最后选择最大物理接口地址。实战中我永远会手动指定因为自动选择的结果不一定符合规划比如某个接口地址被 DHCP 改掉了或者设备上新增了一个更大的地址Router ID 发生改变会导致邻居全部重建这是一次严重的业务中断隐患。当初我在实验里给核心交换机配置ospf 1 router-id 1.1.1.1 area 0.0.0.0 network 10.0.0.0 0.0.255.255这里我用了一条比较粗的通配符把整个 10.0.0.0 网段都宣告进了区域 0。好处是配置简洁坏处是如果设备上有其他网段不想参与 OSPF比如管理网段就会误宣告。更严谨的写法是把互联网段和 Loopback 地址分别宣告。不过实验环境为了效率我用了模糊宣告反正整个设备都在 OSPF 域内问题不大。生产环境里可别这么干。2.2 ABR 的角色与区域间路由优化ABR 在 OSPF 里的地位很特殊。它同时连着骨干区域和非骨干区域是区域间路由的唯一中转点。非骨干区域的所有 Type 3 LSA 都只能由 ABR 产生而且 OSPF 规定非骨干区域之间不能直接传递路由必须经过骨干区域中转。因此ABR 的设计直接决定路由收敛速度和路由表规模。在这套实验里Agg-1 和 Agg-2 就是 ABR。它们把各自区域内的网段转换为 Type 3 LSA注入到 Area 0再由 Area 0 转发到对端区域。在 Agg-1 上我可以用下面命令看到它生成的 Type 3 路由display ospf lsdb summary输出里可以看到 Link State ID 是网段地址Adv Router 是 Agg-2 的 Router ID而 Metric 会根据 ABR 到目标网段的开销计算。看到这条 LSDB 的时候你对“区域间路由由 ABR 代理通告”这句话才算真正理解。ABR 还有一个常见动作是路由汇总。区域间路由汇总必须在 ABR 上做不能在普通路由器上做。比如 Agg-1 区域内的业务网段是 172.16.1.0/24 到 172.16.8.0/24如果不做汇总ABR 会向 Area 0 通告 8 条 Type 3 LSA做了汇总之后只通告一条172.16.0.0/21。这在区域网段特别多时能大幅压缩核心设备的路由表项也能避免具体网段震荡影响整个骨干区域。我在实验里配置汇总ospf 1 area 1 abr-summary 172.16.0.0 255.255.248.0注意汇总命令所在的视图华为设备上是在区域视图下配置的不是进程视图也不是接口视图。很多朋友在这里配错导致汇总没有生效排查半天发现命令位置不对。2.3 特殊区域与路由汇总的取舍继续往深处讲OSPF 还有 NSSA 和 Stub 区域两种特殊区域设计。Stub 区域不允许 Type 5 LSA 进入ABR 会自动下发一条默认路由给区域内的设备从而让区域内设备访问外部网络时不需要维护大量外部路由。NSSA 允许部分外部路由通过 Type 7 LSA 引入再由 ABR 转换成 Type 5 LSA。在实际实验中区域 2 我配置成了 NSSA这样我可以把一台模拟外部网络的路由器通过引入静态路由的方式注入外部路由同时观察 Type 7 转 Type 5 的过程。需要特别提醒的是骨干区域Area 0绝对不能配置成 Stub 或 NSSA这是 OSPF 明确禁止的行为。一旦配置邻居关系就无法建立因为骨干区域必须承载所有类型的 LSA。虚拟链路也需要穿过骨干区域普通特殊区域根本不能满足虚拟链路的要求。这是我最早学 OSPF 时犯过的错误在 Area 0 上配了 stub结果整个区域邻居全 down一度以为是设备兼容问题后来才发现是对协议理解不到位。特殊区域的本质是拿“路由完整性”换“路由表简洁性”。如果设备性能足够、路由条数不多其实没必要做特殊区域。我在实验里做 NSSA主要是为了学习 Type 7 的转换机制实战中如果只是接入少量外部路由直接在 ABR 上做静态路由重发布也能达到效果。3. MSTP 与 VRRP 配合 OSPF 的高可用性实践在真实网络里路由协议不是独立工作的。二层环网的收敛、网关的冗余切换都会直接或间接影响 OSPF 的收敛。这一部分我重点讲 MSTP 多实例、VRRP 主备切换以及它们和 OSPF 的联动关系。3.1 MSTP 多实例消除环路与负载均衡接入到汇聚这一段是典型的二层环网结构。如果不做环路防护广播风暴立刻就能把整张网络打垮。传统 STP 收敛慢而且整网只有一个生成树实例容易导致链路利用率低。MSTP 的好处是可以把不同 VLAN 映射到不同实例每个实例独立计算生成树从而让不同的 VLAN 流量走不同的链路。我在实验里创建了实例 1 和实例 2把业务 VLAN 一分为二。VLAN 10、20 映射到实例 1VLAN 30、40 映射到实例 2。Agg-1 在实例 1 里是根桥Agg-2 在实例 2 里是根桥这样两条 uplink 链路都能跑流量同时互为备份。这是关键配置片段stp region-configuration region-name TEST instance 1 vlan 10 20 instance 2 vlan 30 40 active region-configuration stp instance 1 root primary stp instance 2 root secondary需要注意MSTP 域内的配置必须要一致特别是区域名称和 VLAN 与实例的映射关系。如果两台汇聚设备配置不一致它们会被划分到不同的 MST 域BPDU 交互会不正常生成树计算就会出现混乱。我见过不少现场故障就是因为区域名大小写不一致导致的。3.2 VRRP 虚拟网关与主备切换汇聚交换机作为终端的网关必须提供冗余能力。VRRP 的原理是多个设备共用一个虚拟 IP终端把网关指向虚拟地址由主设备实际转发流量备份设备在主设备故障后接替。核心配置如下interface Vlanif10 ip address 172.16.1.254 255.255.255.0 vrrp vrid 10 virtual-ip 172.16.1.1 vrrp vrid 10 priority 120 vrrp vrid 10 preempt-mode timer delay 5优先级 120 意味着 Agg-1 在正常情况下是主设备。另一个关键点是 preempt 模式我设置了延时抢占 5 秒。原因很实际如果没有延时抢占主设备恢复后立刻抢回流量可能导致短时间内出现双主或路由震荡。加了一个延时让链路和 OSPF 先稳定下来再切换业务受影响的程度会小很多。这里还有一个容易忽略但很实用的点VRRP 的虚拟 MAC 是固定的00-00-5e-00-01-xx其中 xx 是 VRID。当主备切换时新主设备会发送免费 ARP通知交换机刷新 MAC 表项终端的 ARP 表也会随之更新。如果你在实验中 ping 网关出现短暂中断多半是在等 ARP 表和 MAC 表收敛这是正常现象。3.3 倒换场景下 OSPF 的收敛验证重点来了VRRP 切换发生时OSPF 会发生什么。如果 OSPF 是独立运行的VRRP 切换期间路由协议并不需要重新收敛因为 OSPF 邻居是基于三层地址建立的只要两台核心和汇聚之间的三层链路还在OSPF 邻居就不会断。但是如果 VRRP 切换导致去往某个网段的下一跳地址变化比如原来下一跳是 172.16.1.1虚拟地址切换后下一跳仍然是 172.16.1.1因为虚拟地址没有变所以终端流量并不会感知。这就是 VRRP 的价值所在——它把网关的变化屏蔽在了终端之外。为了让实验更有观察价值我在两台核心和汇聚之间使用了独立的互联接口OSPF 邻居关系建立在真实接口地址上。然后我手动把 Agg-1 的 VRRP 优先级调低或者直接把 Agg-1 的 uplink 接口 shutdown观察整个收敛过程。在核心设备上执行display ospf peer brief正常情况下可以看到邻居状态为 Full。切换之后如果 OSPF 在汇聚和核心之间建立了多条等价路径路由表里会出现两条等价下一跳OSPF 会自动做负载分担。当其中一条 down 掉OSPF 在几秒内就会把失效路径从路由表中移除业务恢复。VRRP 切换引发的是二层链路变化这个过程在三层 OSPF 看来只是丢了一条底层链路不会产生大范围路由震荡。这也是我推荐把 OSPF、VRRP、MSTP 放在一起实验的原因——你能直观看到各层协议各司其职而不是互相干扰。4. 故障排查错误表、调试命令与抓包的实践心得再好的实验总会遇到问题。一个综合实验的价值一半在于配置另一半在于排查。下面这部分我重点分享实际操作中用得最顺手的排查链路。4.1 OSPF 错误表排查问题的第一站有句话说得好OSPF error 表里面查问题老清晰了。这句话一点不夸张。OSPF 协议本身有完善的差错统计机制很多邻居建立失败、报文交互异常的问题其实都能在错误计数里看到蛛丝马迹。用一条命令就能搞定display ospf error这条命令会列出接口收到的各类错误报文计数包括 Bad Version、Area Mismatch、Authentication Failures 等。我排查邻居无法建立的问题时第一件事就是看 error 表而不是直接抓包。为什么因为 OSPF 自己已经把错误类型分好了比如Area Mismatch计数暴涨说明邻居两端的区域 ID 不匹配。Authentication Failures说明认证密码或认证类型不一致。Bad Network Mask说明接口在掩码类型上有冲突比如一个是点到点、一个是广播。Unknown Neighbor说明收到了来自未知邻居的报文通常是 Router ID 冲突或者接口宣告范围错误。我在实验里故意把 Agg-2 的区域写错对接接口配置到了 Area 0而 Agg-1 那边还是 Area 1。结果是邻居一直显示 ExStart 或者 Down查看 error 表后立刻看到Area Mismatch持续增加。配合display ospf peer查看邻居状态几分钟就能定位问题。这块的经验是看 error 表一定要看趋势而不是只看当前数值。如果计数是持续增长的说明问题还在发生如果计数稳定不变说明可能是历史残留重点排查当前状态。还有error 表是每接口统计的如果你觉得有问题却又不确定是哪个接口可以先用display ospf interface确认接口列表再逐个看。4.2 debug 命令的精准使用技巧当 error 表不能完全解释问题时就该上 debug 了。很多老工程师说“直接 debug抓包都不用”这个说法虽然略显极端但确实有道理——debug 能直接在设备上输出协议交互的详细过程省去抓包后还要过滤分析的步骤。OSPF debug 最常用的是事件和报文两类debugging ospf event debugging ospf packet事件调试可以看到邻居状态机的迁移过程比如从 Down 到 Init、到 2-Way、再到 Full。这条命令非常直观能帮你判断邻居是卡在哪个阶段。报文调试则能看到 Hello 报文收发、DBD 报文的序列号交互等。如果邻居一直卡在 ExStart多半是 DBD 报文交互有问题这时打开报文调试立刻就能看到双方在互相推诿——通常是因为 MTU 不一致。这里有一个非常实用的 MTU 排查经验。华为设备在 OSPF 接口上默认开启ospf mtu-enable时会检查 DBD 报文中的接口 MTU 值。如果两端 MTU 不一致比如一端是 1500另一端是 1400DBD 报文的交互就会卡住邻居无法进入 Full 状态。你从 error 表不一定能看出问题但 debug 里能看到 DBD 重传不断发生。解决方案是把两端接口 MTU 统一或者去掉其中一端的 mtu-enable 配置。使用 debug 时我还要强调一个纪律生产设备上不要随便开 debug因为 debug 输出会占用大量 CPU严重的会让设备死机。实验环境无所谓但在真实设备上我一般只在确认问题后小范围打开特定协议 debug并且设置一个定时关闭比如undo debugging ospf packet还有一个小习惯是配合terminal monitor和terminal debugging使用否则在远程登录时看不到任何输出。4.3 对抓包的正确认识与高效使用不是说 debug 够用就不用抓包而是很多场景下抓包定位问题更快。比如 OSPF 报文发出了吗对端收到了吗报文内容有没有被改动这类问题靠设备自身的 debug 往往只能看到本端情况抓包则可以从全局视角确认。不过我真的不建议一开始就抓包。原因很简单抓包工具很多时候会给你大量无关信息而且需要你手动过滤、分析效率反而低。我自己的习惯是先用 error 表缩小范围再用 debug 确认协议交互细节最后实在需要看端到端传输情况时才抓包。这样层层递进问题定位速度最快。抓包时要注意OSPF 报文是直接封装在 IP 报文里的协议号是 89目的地址是组播地址 224.0.0.5所有 OSPF 路由器或 224.0.0.6指定路由器。在 Wireshark 里用ospf作为过滤条件即可。重点看 Hello 报文里的 Dead Interval、Area ID、认证字段以及 DBD 报文里的 MTU 和描述性信息。我记得第一次抓包看到 DD 交换过程时才真正理解了 OSPF 主从关系是怎么通过序列号协商出来的这比单纯看文档印象深刻得多。在我这张实验里有一次两个核心设备之间 OSPF 邻居一直起不来error 表和 debug 都没发现明显报错最后抓包发现设备之间隔了一台防火墙防火墙把组播报文丢掉了。这个案例说明协议层面没问题不代表路径上没问题抓包能帮你看到真实报文到没到、对不对。这也是为什么我不建议完全放弃抓包而是把它作为逐层排查的最后一道关。5. 实验收尾时必做的几项验证实验配置完成后不能只看 ping 通就宣布大功告成。这里分享几个我每次必做的验证动作。第一查看 OSPF 邻居状态。所有邻居必须稳定在 Full。用display ospf peer brief看全部邻居比一个个接口看效率高得多。第二查看路由表里的关键路由条目。用display ip routing-table确认区域间路由、外部路由都正确出现。如果某条路由缺失回到 LSDB 里查看对应的 LSA 是否产生是哪个设备通告的顺着这条链路就能定位问题。第三做故障演练。把主核心的 uplink 接口 shutdown观察 VRRP 是否切换到备核心观察终端 ping 网关的中断时间有多长。把汇聚设备的 OSPF 接口也 shutdown观察路由是否快速切换。这类演练能逼着你去思考和理解协议收敛细节而不是仅仅满足于“通了就行”。第四保存配置并记录日志。实验用的设备最好定期保存配置避免设备重启后所有工作白费。日志里记录的每次 shutdown、每次 debug 输出都是后续复盘的好素材。最后再说一点个人体会做 OSPF 综合实验我觉得最大的收获不是学会几条命令而是建立起一套“从现象到原因”的排查思维。以前看到邻居 down我的第一反应是重新配置一遍后来知道先看 error 表再看 debug最后抓包——层层剥茧往往几分钟就能定位问题。这套方法论比记住任何一条命令都值钱。如果你也是刚开始做综合实验我建议你别急着抄配置先花一小时把拓扑、地址、区域规划想清楚再用我上面的步骤一步步搭。配置遇到问题的时候优先看协议自己的反馈信息别一上来就怀疑设备兼容或者链路物理故障。我做这行这么多年发现大部分 OSPF 问题都是配置细节问题真正需要抓包才能定位的比例非常低。希望这篇文章能帮你少走点弯路把实验做到真正理解每一个协议动作背后的逻辑。