1. 这次实验到底在验证什么：别把综合实验做成命令默写
先说个现象。身边不少朋友做OSPF实验，习惯照着一张配置表敲命令，敲完show ip ospf neighbor看到Full就觉得自己会了。结果到面试或实际项目里，被问一句“为什么这里要配多区域”“为什么这条路由走的是这个出口”，一下就卡壳。我这次搭的OSPF综合实验，就是想把这些“知其然不知其所以然”的地方一次性补齐。
实验的核心目标很简单：用一组路由器搭建一个多区域OSPF网络，让所有网段互通，同时验证区域划分、路由汇总、认证、特殊区域、默认路由注入这些在生产环境里真正会用到的东西。适合刚学完OSPF基础、想系统做一次综合练习的人，也适合准备网络认证考试、想梳理知识体系的同学。
之所以强调“综合”，是因为单区域实验掩盖了太多问题。比如单区域里你根本感受不到LSA类型之间的区别，也不理解为什么ABR（区域边界路由器）是关键节点，更不会意识到DR/BDR选举在广播链路里带来的收敛差异。这些都是综合实验才能逼你面对的。
我做实验用的环境是纯命令行模拟器，三台核心路由器组成骨干区域，两台分支路由器挂在区域1下面，另外还有一台模拟外部网络的设备。拓扑不复杂，但每个知识点都能落到位。
2. 动手前的关键铺垫：OSPF核心机制里最影响实验结果的几个点
2.1 邻居关系建立的底层逻辑：Hello与Dead间隔
综合实验最容易翻车的地方就是邻居起不来。而邻居起不来的头号原因，就是相邻接口的Hello间隔或Dead间隔不一致。OSPF通过周期性发送Hello报文来发现和维护邻居关系，默认情况下Hello间隔是10秒，Dead间隔是Hello间隔的4倍，也就是40秒。
如果一侧改了Hello时间而另一侧没改，两边会一直互相发Hello，但就是无法进入Two-Way状态，因为彼此都认为对方的参数不匹配。这个机制很像两个人约见面，一个说“每10分钟报个到”，另一个说“每30秒报个到”，节奏对不上就永远确认不了对方还在。
实验里我特意把其中两台路由器的接口Hello时间改了，让学员先看一眼症状：邻居状态卡在Init，来回翻。再把参数改回来，状态立刻就恢复到Full。这个环节值得亲手做一遍，比背十遍理论都管用。
2.2 DR/BDR选举：广播链路里的隐形老大
在以太网这类广播型多路访问链路上，OSPF会选举DR（指定路由器）和BDR（备份指定路由器），其他路由器只和DR、BDR建立Full邻居关系，DR与BDR之间也建立Full关系，而普通路由器之间保持Two-Way状态。
这个机制的核心价值是减少邻接关系的数量和LSA泛洪的重复。打个比方，一屋子人开会，如果每个人都要发言一遍，信息会乱套；选出主持人（DR）和记录员（BDR）后，其他人只需要和主持人沟通，再由主持人统一传达，效率高得多。
实验中我在骨干区域接了一台交换机组，三台路由器在上面。连续做两次clear ip ospf process，观察Router ID最大的那台总是成为DR。原因在于选举的优先级规则：先比接口优先级，默认都是1；再比Router ID，数值大者胜出。这就是为什么很多生产环境会用Loopback地址的IP来设定Router ID——比物理接口的稳定性更高，且便于记忆和排错。
2.3 COST计算：为什么千兆口和百兆口走的路不一样
OSPF选路的核心指标是COST，默认计算公式是100Mbps除以接口带宽。这意味着百兆接口COST是1，千兆接口COST是0.1，取整后也是1。这就是个坑：如果你沿用默认参考带宽，所有千兆和百兆链路算出来COST都是1，完全看不出差异。
所以综合实验里必须在进程下配置auto-cost reference-bandwidth，把参考带宽调成10000（单位Mbps，对应10G），这样千兆口COST是10，百兆口COST是100，路由计算才有区分度。我在两台核心设备之间跑了一条千兆链路，重叠一条百兆链路，调完参考带宽后观察路由表，下一跳自动选择了千兆链路。这个细节直接关系到生产环境中链路负载不均的问题，值得单独拿出来验证。
3. 按部就班搭环境：从接口IP到全网路由全通
3.1 地址规划与接口配置
先交代一下地址规划。骨干区域（Area 0）放三台设备：R1、R2、R3。区域1挂R3、R4、R5。R2额外接一台模拟外部网络的设备，用来验证默认路由注入。Loopback地址统一用设备编号：R1是1.1.1.1/32，R2是2.2.2.2/32，依此类推。
互联地址我习惯用10.0.x.y/30这类前缀，既能节省地址，也能逻辑清晰地标识是哪两台设备之间的链路。比如R1与R2之间用10.0.12.0/30，R1接口10.0.12.1/30，R2接口10.0.12.2/30。前缀里的“12”就代表R1和R2之间的链路，排错时看地址就知道拓扑关系。
业务网段方面，R4下面挂一个模拟用户的VLAN网段192.168.10.0/24，R5下面挂192.168.20.0/24。这两个网段就是最终要跨区域互通的“用户业务”。
接口配置没什么特殊，就是进接口视图配IP地址和启用。需要提醒的是，物理接口一定要确认状态是up/up，很多实验做到一半发现路由不通，回头一看是接口没插线或者被shutdown了。
3.2 OSPF基础配置与进程参数
每台设备上创建一个OSPF进程，进程号可以本地有效不用全局统一，但要保持Router ID全局唯一。Router ID我喜欢用手工指定的方式，避免因接口地址变动导致Router ID漂移，从而引发邻居关系重建和不必要的路由震荡。
宣告网段时使用的是反掩码。例如宣告Loopback地址，用network 1.1.1.1 0.0.0.0 area 0；宣告互联地址，用network 10.0.12.0 0.0.0.3 area 0。很多人容易把反掩码配成子网掩码，比如写成255.255.255.252，这会导致宣告的网段范围完全错乱，OSPF进程无法正常工作。
各设备的区域划分如下：R1、R2、R3的Loopback和互联接口全部落在Area 0；R3与R4、R5互联的接口落在Area 1；R4、R5连接用户的接口也宣告在Area 1。R3作为ABR，同时维护Area 0和Area 1的LSDB，承载跨区域路由的转换职责。
配置完成后，先看邻居状态和路由表：
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 Full/DR 00:00:37 10.0.12.2 GigabitEthernet0/0/0 3.3.3.3 1 Full/DR 00:00:38 10.0.13.3 GigabitEthernet0/0/1这段输出意思是R1和R2、R3都建立了Full邻居关系。因为R2、R3的Router ID更大，所以它们在这两条链路上担任DR。再看路由表，应该能看到1.1.1.1、2.2.2.2、3.3.3.3这几条Loopback路由以及各互联网段的路由，且来源标识为OSPF。
3.3 跨区域路由的类型差异：O E2和O IA
全网互通后，重点看路由表里的O和O IA。区域内的路由是O，带OSPF内部路由属性；跨区域的路由则显示为O IA，含义是Inter-Area路由，表示这条路由是从其他区域学习来的。
R1上查看192.168.10.0/24这条路由，来源是O IA，下一跳指向R3。这个现象背后是OSPF的区域化设计理念：末梢区域不需要了解骨干区域的拓扑细节，ABR将区域内的路由以汇总的形式（Type 3 LSA）通告给骨干区域，再由骨干区域转发给其他区域。区域划分的本质就是把故障域和路由计算范围隔离，降低每台设备维护LSDB的规模。
验证链路是否真的通了，在R1上ping 192.168.10.1，能通说明跨区域的LSA传播和路由计算都正常。我还会顺手在R1上跟踪一下路径：traceroute 192.168.10.1，看到路径经过R3的互联地址，逻辑就完整了。
4. 进阶配置：把综合实验做出“生产环境”的味道
4.1 区域认证与接口认证：给邻居关系加一把锁
生产环境里，OSPF邻居关系需要认证保护，防止非法设备接入后伪造路由信息。综合实验里我分别在骨干区域启用了区域认证，在Area 1单独配置了接口认证。区域认证是在区域视图下统一开启，所有加入该区域的接口都必须配置相同的认证密钥；接口认证则更灵活，可以在某一对链路单独启用，不影响区域内其他接口。
配置时用的口令是密文形式，设备不会在配置里明文显示。做个模拟场景：我把R4的密钥悄悄改掉，然后观察R3与R4的邻居关系，状态会从Full变成Down，然后反复尝试建立认证，一直在Attempt或Init状态打转。直到把密钥改回去，邻居关系才恢复。
这一步在实际维护中意义很大。很多OSPF网络异常，最后查出来都是新增设备时密钥敲错了一个字符，或者区域认证和接口认证混用导致参数对不上。实验里亲手制造一次这种故障，以后遇到就能快速定位。
4.2 路由汇总：让Area 1的路由干净利落地进入骨干
R4挂着192.168.10.0/24，R5挂着192.168.20.0/24。如果不做汇总，ABR R3会通告两条Type 3 LSA给Area 0，泛洪范围扩大，每台设备的路由表也要多维护两条条目。在R3的Area 1视图下配置汇总命令后，两条具体路由被聚合为192.168.0.0/16通告出去。
配置完成后，回R1上看路由表，192.168.10.0/24和192.168.20.0/24都不见了，取而代之的是一条192.168.0.0/16的O IA路由。这个效果非常直观——路由汇总能把区域边界上的明细路由收敛成一条聚合路由，显著减少骨干区域的路由条目数量和LSA泛洪。
但汇总不是万能的，它要求区域内部的地址规划本身具备连续性。如果R4上挂的网段是192.168.10.0/24，而R5上挂的是172.16.20.0/24，那无论如何都汇总不到一条干净的聚合路由里。所以地址规划阶段就要考虑汇总需求，否则后面再调整会很痛苦。
4.3 Stub区域与完全Stub区域：切断外部路由的传播
Stub区域的作用是阻挡Type 4和Type 5 LSA进入，区域内设备无法学习到外部路由，只保留区域内部和跨区域路由，并由ABR自动注入一条默认路由。这样做的价值很明显：区域内设备的路由表大幅瘦身，CPU与内存开销降低，收敛也更快。
我把Area 1配置为Stub区域，在R3和R4、R5上都做了对应配置。配置完在R4上查看路由表，192.168.0.0/16这条汇总路由还在，但任何外部路由的明细都看不见，取而代之的是一条0.0.0.0/0的默认路由指向R3。
如果还嫌不够彻底，可以进一步配置完全Stub区域。完全Stub区域不仅阻止外部路由，还阻止跨区域明细路由，只保留一条默认路由。我把Area 1改成完全Stub后，R4的路由表里连192.168.0.0/16都没有了，只有一条默认路由。内部设备访问外部任何网段，都把流量交给ABR，由它去做实际转发决策。
这个设计方案在生产中很适合那些只承载终端用户、不需要知道全网拓扑的分支机构网络。
4.4 默认路由注入：让全网访问外部网络
R2上有一条通向外部模拟网络的静态路由，但OSPF进程本身不会传播静态路由，需要在R2的OSPF进程里配置default-route-advertise always。加了always参数后，即使本地没有默认路由，也会强制通告一条默认路由给OSPF域内其他设备。
配置完在R1上观看路由表，能看到一条O*E2的默认路由，表示它是一条OSPF外部默认路由，管理距离和开销都按外部路由规则处理。此时R1上任何目的地址不在OSPF域内的流量，都会被引导到R2，再由R2交给外部网络。
这个场景就是典型的企业出口网络：内部跑OSPF做动态路由，出口设备上有到运营商的默认路由，然后注入OSPF，全网设备都自动获得上网路由。比在每台设备上手动配默认路由省事太多，而且出口切换时，只要R2上的路由变化，OSPF会自动更新。
5. 故障复现与排查链路：邻居起不来，到底卡在哪一步
5.1 第一轮排查：从物理层到参数层
做实验的过程中，R4一直无法和R3建立邻居关系。我按常规排查思路一步步走：先看接口状态，up/up正常；再检查IP地址和反掩码，没问题；接着看两端OSPF区域ID，都是Area 1，一致；检查认证配置，两边密钥相同，也一致。
随后再看两端接口的Hello和Dead间隔，发现R4的Hello间隔被改成5秒，Dead间隔20秒，而R3上仍是最初的10秒/40秒。这就是“参数不匹配”导致的邻居无法建立。把R4的间隔改回10秒/40秒后，邻居关系在几十秒内建立起来，状态进入Full。
排查中我刻意没有一开始就看OSPF参数，而是按物理层、链路层、网络层、OSPF层的顺序逐层推进。这个顺序在真实项目里非常重要——如果接口都没up，后面所有的OSPF配置检查都是白费功夫。越是熟练的工程师，越要克制“直接看OSPF配置”的冲动。
5.2 第二轮排查：网络类型不一致引发的问题
第二处故障出在R3与R5之间。两台路由器互联接口的OSPF网络类型不一致：R3上因历史配置被设为了point-to-point，而R5上保持默认的broadcast。结果两边能收到Hello报文，却始终无法建立Full邻居关系。
原因是网络类型影响Hello报文的发送方式和邻居发现机制。point-to-point网络不会进行DR/BDR选举，而broadcast网络会先选举DR/BDR再建立邻接关系。两者状态机不能对齐，就一直僵持在Two-Way左右。把R3的接口网络类型改成broadcast，或者把R5也改成point-to-point，问题立刻消失。
这个故障在生产里很多见，尤其是涉及不同厂商设备互联时，默认的OSPF网络类型可能不同，比如一种链路默认是point-to-point，另一种默认是broadcast。两边没人协调，就会莫名其妙邻居起不来。做实验时手动制造一次这种不匹配，比看十遍文档都入脑。
5.3 第三轮排查：Router ID冲突的隐蔽性
第三处故障隐蔽性最强。R5和R4的Router ID都被配成了5.5.5.5，刚开始两台设备之间的邻居关系能建立，但过一会儿就断开，还伴随频繁的“Duplicate Router ID”日志。
原因是OSPF要求域内Router ID唯一，冲突会导致LSDB中的路由器信息混乱，进而影响SPF计算和路由稳定性。把R4的Router ID改成4.4.4.4并重启OSPF进程后，一切恢复正常。
这个坑提示了一件事：综合实验里一定要养成统一规划Router ID的习惯。我通常会用Loopback地址的最后一段作为Router ID，比如Loopback是4.4.4.4/32，Router ID就配4.4.4.4，形成“编号即地址，地址即身份”的对应关系，后期排错一眼就能看出是哪台设备。
6. 验证清单与几个容易忽略的细节
6.1 一套可复用的验证顺序
实验做完后，我习惯按顺序过一遍验证清单，避免漏掉隐性错误。首先是show ip ospf neighbor，确认每个邻居关系都是Full，DR/BDR角色符合预期；其次是show ip route ospf，观察O、O IA、O*E2路由类型是否和设计一致；最后是show ip ospf database，检查LSA类型与数量。
具体到每个Session的检查点，可以参考下面这个表格：
| 验证项 | 期望结果 | 说明 |
|---|---|---|
| 邻居状态 | 全部Full | 若有卡在Init或Two-Way的接口，优先查Hello间隔、区域ID、认证、网络类型 |
| 路由表内容 | 明细路由+汇总路由并存 | 区域1内看到明细，骨干区域看到汇总，符合设计 |
| 默认路由 | R1上有静态默认经R2注入 | 通过default-route-advertise always实现 |
| 路径选择 | 千兆链路优先于百兆链路 | 通过调整参考带宽使COST差异显性化 |
| 故障恢复 | 断开R3与R5直连链路后，流量走R3-R4-R5备份路径 | OSPF收敛时间受Hello Dead间隔影响，避免频繁抖动 |
6.2 容易被忽略的配置细节与经验心得
有一个细节特别容易遗漏：Passive接口。如果某台路由器连着一个只接终端用户的接口，又不想让这个接口发送OSPF报文，应该在OSPF进程里把它配置为Passive。但如果误把互联接口也配成Passive，邻居就直接起不来了。排查时看到某个接口状态正常但邻居始终不存在，要记得看一眼是不是被设成了Passive。
还有一个细节是手工指定Router ID之后重启OSPF进程的时机。修改Router ID后，如果不重启OSPF进程，新Router ID不会立即生效，常导致排错时的误判。所以每次改动身份类参数后，最好明确重启进程，让配置真正生效。
最后一个心得关于实验记录。我习惯每完成一个阶段的配置，就截一下邻居状态和路由表输出。之后做故障复现时，对比正常状态和故障状态的路由表、邻居表差异，排查起来效率极高。这也是工作中排查真实网络故障最实用的习惯——没有基线数据，就不知道异常从哪一步开始。
