翻到去年做的OSPF综合实验记录当时把OSPF多区域、特殊区域、MSTP、VRRP这几个东西全部揉进一张园区网拓扑里前后折腾了好几天。现在回头看这个实验最大的价值不在于敲会了多少命令而在于把协议之间的联动关系真正理清了。这篇文章就按实验的完整流程来写从拓扑规划、地址设计、OSPF部署、特殊区域配置到MSTP和VRRP联动调优最后是故障排查实录适合正在备考H3C/华为认证、或者正在做网络方向课程设计和园区网改造的朋友参考。我不会只贴配置还会把每一步的配置理由和验证结果写清楚毕竟纸上得来终觉浅。1. 实验规划与拓扑设计思路1.1 为什么要把OSPF、MSTP、VRRP放在一张拓扑里很多朋友做OSPF实验都是两台路由器一接宣告几个网段看到邻居状态变成Full就觉得完事了。但实际上作网络工程项目时OSPF很少单独存在它一定要和二层技术配合起来用。这次实验我搭了一个典型的中小型园区网两台核心交换机跑OSPF骨干区域下面挂汇聚交换机划分多个业务区域接入层交换机负责终端接入再用MSTP解决二层环路问题用VRRP做网关冗余。这三个技术放在一起是因为它们解决的问题完全不同但又互相依赖。OSPF解决的是三层路由怎么走终端访问服务器、跨VLAN互访、访问出口互联网都得靠路由表来指引。MSTP解决的是二层环路问题接入层交换机之间、接入和汇聚之间通常有冗余链路不做生成树就会形成广播风暴。VRRP解决的是网关冗余问题终端配置的网关地址如果是一个虚拟IP那么核心交换机挂掉一台另一台能无缝接管转发。真正的难点在于这三者不是孤立的。MSTP阻塞了某条二层链路之后OSPF看到的拓扑就会变化路由的下一跳和Cost值都可能跟着变VRRP主备切换后终端的默认网关换了转发路径OSPF必须能感知到这种变化并重新收敛。如果只是单独验证某一个协议这些联动问题永远发现不了。所以我从一开始就把实验目标定成全网VLAN间互访正常、任意单点链路或设备故障后业务恢复时间可接受、主备切换过程中不出现长时间丢包。这三个目标才是综合实验的意义所在。另外为什么选OSPF而不是静态路由或者RIP也是因为OSPF的收敛速度、无环特性和可扩展性更适合这种多区域的场景。OSPF把整个网络划分成Area 0骨干区域和多个非骨干区域ABR负责区域间的路由传递这种层次化设计和园区网的层次化架构天然匹配。RIP的跳数限制和慢收敛在大型网络里完全不够用静态路由在链路故障时又无法自动收敛。OSPF虽然配置复杂度高一些但换来的稳定性和可控性值得投入。1.2 地址规划与Router-ID设计做实验也好做项目也罢地址规划永远是第一步而且是最容易偷懒出问题的一步。这次实验我规划了三类地址互联地址、Loopback地址和业务VLAN地址分别用了不同的网段区分具体如下表。设备/区域网段规划用途说明核心-核心互联10.0.0.0/30两台核心交换机之间的三层互联链路核心-汇聚互联10.0.x.0/30核心与各汇聚之间的上行链路Router-ID地址1.1.1.1到1.1.1.x各设备Loopback 0用于OSPF Router-ID业务VLAN网段192.168.10.0/24等终端用户所在的业务子网配置在VLAN接口上这里要特别说一下Router-ID。OSPF的Router-ID是用来标识一台路由器的唯一身份类似于人的身份证号。如果不手动配置设备会从接口IP里自动选一个最大的IP作为Router-ID这在小型实验里碰巧能用但在生产网络里就非常危险。比如你新加了一个接口IP比原来的大重启OSPF进程后Router-ID变了所有邻居关系都重建一次整个网络要振荡一遍这在现网里是不可接受的。所以我所有设备都手动指定Router-ID规则也很简单核心交换机用1.1.1.1和1.1.1.2汇聚交换机用1.1.1.11到1.1.1.14这样看路由表的时候一眼就能认出是哪台设备。手动指定Router-ID还有一个好处就是Loopback接口的稳定性。Loopback接口只要不手动shutdown就永远不会Down用它做Router-ID比用物理接口地址稳定得多。在H3C平台上配置Router-ID的命令是ospf 1 router-id 1.1.1.1注意这里如果OSPF进程已经启动过修改Router-ID后必须重启OSPF进程才能生效。我当时就在模拟器上遇到过这个问题改了Router-ID之后邻居状态一直是Exchange后来查了才知道是进程没重启。还有一个细节是Router-ID必须全局唯一如果两台设备不小心配了一样的Router-ID邻居状态会出现反复振荡一会儿Down一会儿Full排查的时候非常头疼。2. OSPF基础配置与邻居建立要点2.1 从一条network命令理解OSPF的区域宣告配置OSPF的第一步是在每台设备上启动进程然后进入区域宣告接口网段。H3C的命令格式如下[Core-1] ospf 1 router-id 1.1.1.1 [Core-1-ospf-1] area 0.0.0.0 [Core-1-ospf-1-area-0.0.0.0] network 10.0.0.0 0.0.0.3 [Core-1-ospf-1-area-0.0.0.0] network 192.168.10.0 0.0.0.255很多初学者不理解network命令后面的反掩码是什么意思。0.0.0.3其实是一个通配符掩码0表示必须严格匹配255表示这一位可以任意。所以10.0.0.0 0.0.0.3表示匹配10.0.0.0到10.0.0.3这个范围内的IP地址正好覆盖一个/30的互联链路。192.168.10.0 0.0.0.255表示匹配整个/24网段。这里有一个我踩过的坑network宣告的是接口所在网段而不是具体接口IP所以写反掩码的时候一定要算清楚范围。比如一个接口是10.0.0.1/30你写network 10.0.0.1 0.0.0.3也能匹配上但如果你写成network 10.0.0.0 0.0.0.255就会把实际不存在的地址也宣告出去容易引起路由混乱。还有一个常见的错误是宣告范围过大。有些朋友图省事直接在一个区域里宣告核心设备的所有网段这在小实验里问题不大但一旦区域划分复杂起来就可能把本该属于Area 1的网段错误宣告进了Area 0导致路由路径不符合预期。我这次的做法是每台设备只宣告自己直连的网段而且对应的区域编号必须和规划一致。核心交换机的互联地址和业务VLAN接口地址宣告在Area 0汇聚交换机连接核心的上行接口和业务网段宣告在对应的非骨干区域。这样ABR的职责才清晰区域间的路由传递才有逻辑可言。配置完网络命令之后要养成check的习惯。H3C上先看display ospf peer确认邻居状态都变成Full再看display ospf routing确认路由表条目完整。我遇到过配置完全一样但邻居始终起不来的情况后来用display ospf error查看才发现是Hello报文里的认证字段不匹配。OSPF邻居建立的本质就是双方发送Hello包包里的参数必须协商一致否则邻居关系永远卡在Down或Init状态。2.2 邻居状态机和排障方法OSPF的邻居状态机从Down到Full一共经历七个状态Down、Attempt、Init、2-Way、ExStart、Exchange、Loading、Full。平时我们最需要关注的其实是几个转折点。从Init到2-Way说明双方已经在Hello包里看到了对方双向通信建立从2-Way到ExStart开始选举DR和BDR然后交换数据库描述报文从Exchange到Loading开始发送链路状态请求最后到Full说明LSDB同步完成。我测试时最喜欢用调试命令terminal debugging配合debug ospf packet来观察这些状态的切换看到状态一步步往前走心里的底就越来越足。在这七个状态中最容易出问题的就是2-Way之前。下面这个表格是我整理的邻居建立常见问题每一个都是我在实验中真实遇到过的故障现象可能原因排查命令邻居卡在Down或InitHello间隔或Dead间隔不一致display ospf interface邻居卡在Init区域ID不一致或接口掩码不匹配display ospf interface邻居卡在ExStart/Exchange接口MTU不一致display ospf peer verbose邻居反复Down/UpRouter-ID冲突或认证配置错误display ospf error单边邻居接口被防火墙或ACL过滤了组播报文display current-configuration一个特别隐蔽的问题是MTU不一致导致邻居卡在ExStart。OSPF会在数据库描述报文中携带接口MTU值如果两端MTU不一致会导致数据库同步永远无法完成邻居状态就卡在Exchange那里。我这次实验里有一次把核心互联接口的MTU改成1400做了模拟测试结果邻居状态就卡住了改回1500后立刻恢复正常。排障思路其实很简单先看display ospf peer的当前状态再逐层检查接口参数、区域配置和过滤策略问题基本都能定位。3. 特殊区域的设计与ABR行为3.1 什么样的区域适合配Stub什么样的适合配NSSAOSPF的区域类型直接影响LSDB的大小和路由表条目的多少。骨干区域Area 0是必须存在的所有非骨干区域都必须和Area 0相连。如果不做任何特殊配置每个非骨干区域都会收到来自其他区域的全部Type 3 LSA以及来自ASBR的外部路由Type 5 LSA区域内的设备要维护完整的外部路由信息这在区域很大时浪费资源。Stub区域的设计初衷就是过滤外部路由。Stub区域内部不允许存在ASBR所以Type 4和Type 5 LSA都不会进入这个区域ABR会向Stub区域内下发一条默认路由让区域内的设备访问外部网络时直接走默认路由出去。但Stub区域有个限制区域内不能引入外部路由也不能存在ASBR所以如果某个区域里有一台设备需要引入静态路由或者RIP路由就不能配成Stub。NSSA区域就是为解决这个限制而生的。NSSA区域允许区域内存在ASBR并引入外部路由引入的路由以Type 7 LSA的形式在区域内传播由NSSA的ABR转换成Type 5 LSA后通告到骨干区域。同时NSSA区域默认不接收来自其他区域的Type 5 LSAABR也可以下发默认路由。这次实验里的区域划分是这样的Area 1配置为Stub区域因为该区域只有接入终端和服务器不需要引入外部路由Area 2配置为NSSA区域因为该区域有一台边界设备需要引入一条指向出口设备的静态默认路由。两种区域的配置形成一个鲜明对比可以直观地看到LSA类型的变化。我特别想强调一个容易混淆的概念Stub区域和Totally Stub区域的区别。普通Stub区域仍然会收到其他区域汇总过来的Type 3 LSA只是过滤了Type 4和Type 5而Totally Stub区域把Type 3、Type 4、Type 5全部过滤掉ABR只下发一条默认路由。在H3C设备上配置Totally Stub需要在区域视图下加stub no-summary参数。我测试的时候一开始只在Area 1配了stub结果路由表里还是一大堆Type 3的明细条目后来加上no-summary才看到干净的路由表。3.2 特殊区域配置实验与LSA验证以Area 1为例H3C上的配置如下[Core-1] ospf 1 router-id 1.1.1.1 [Core-1-ospf-1] area 0.0.0.1 [Core-1-ospf-1-area-0.0.0.1] stub区域内的汇聚交换机也必须配置stub因为Stub区域内的所有路由器必须有相同的区域配置否则邻居关系无法建立。这个一致性要求我在实验中吃过亏只改了ABR没改区域内的设备结果整个区域的邻居全部Down掉排查了半天才想起来两边都要配。Area 2的NSSA配置稍微复杂一点[Core-2] ospf 1 router-id 1.1.1.2 [Core-2-ospf-1] area 0.0.0.2 [Core-2-ospf-1-area-0.0.0.2] nssa default-route-advertisedefault-route-advertise参数让ABR向NSSA区域内下发默认路由。如果不加这个参数NSSA区域内的设备访问外部网络时就没有默认路由可用因为Type 5 LSA默认被过滤掉了。而区域内的边界设备引入外部路由的配置则在ASBR上单独做比如import-route static加一个nssa相关的参数。配置完成后我做了两个关键验证。第一是在Area 1内的汇聚交换机上执行display ospf lsdb可以看到LSDB里只有Router LSA、Network LSA、Type 3的Summary LSA还有ABR下发的默认路由完全没有Type 4和Type 5。第二是在Area 2内的设备上执行同样的命令能看到Type 7 LSA出现。对比两个区域的LSDB对OSPF LSA类型的理解一下子就从抽象变具体了。还有一个细节是NSSA的转发地址问题。Type 7转换成Type 5时如果ASBR和ABR不在同一个网段转出来的Type 5 LSA可能包含一个不可达的转发地址导致其他区域的路由黑洞。我这次实验特意把ASBR和ABR放在了同一个互联网段里就是为了避免这个问题。如果实际网络里两者跨网段需要在ASBR上配置nssa translator-always之类的参数来确保转换行为稳定具体参数不同厂商略有差异务必以设备文档为准。4. OSPF与MSTP、VRRP的联动配置4.1 MSTP域配置与实例划分二层这块的配置目标是在存在冗余链路的接入层和汇聚层之间消除环路同时让不同VLAN的流量走不同的物理链路实现负载均衡。传统STP只有一棵生成树所有VLAN共享同一条转发路径另一个冗余链路被阻塞掉资源浪费严重。MSTP通过实例把VLAN映射到不同的生成树每个实例独立计算拓扑让不同VLAN的流量走不同链路。H3C设备上的配置如下[H3C] stp region-configuration [H3C-mst-region] region-name CAMPUS [H3C-mst-region] instance 1 vlan 10 to 20 [H3C-mst-region] instance 2 vlan 21 to 30 [H3C-mst-region] active region-configuration这里最关键的一点是整个二层网络的所有交换机必须配置相同的域名称和VLAN实例映射关系否则MSTP会把它们视为不同的域生成树计算就会出问题。实际经验是域名称最好在项目一开始就规划好不要用设备默认的NULL名称因为默认情况下所有没有配置过MSTP域的交换机都在一个默认域里一旦你改了区域配置而另一台没改两个域之间会通过边界端口互连可能出现意外的阻塞端口。实例划分完之后还要在核心交换机上指定根桥。H3C的命令是stp instance 1 root primary把核心交换机指定为实例的主根桥另一台核心做备份根桥stp instance 1 root secondary。这样设计的好处是终端访问网关的流量走汇聚到核心的路径在二层拓扑上就能保证最优。如果不指定根桥生成树的根桥选举可能选到接入层交换机上去流量路径绕远延迟和带宽都会受影响。MSTP和OSPF的联动是我这次实验重点关注的地方。当MSTP阻塞或放开某条链路时二层的物理拓扑发生变化OSPF的三层邻居关系也会一起变化。我在实验里模拟了汇聚交换机到核心交换机的主链路故障MSTP立刻把备份链路切换到转发状态同时OSPF感知到链路Down掉重新进行SPF计算把路由下一跳切到备份链路上。整个过程如果配置得当丢包只有几个这在只做二层冗余不跑动态路由的网络里是做不到的因为传统STP收敛要几十秒。4.2 VRRP网关冗余与OSPF的联动调优VRRP的作用是让多台路由器共用一个虚拟IP地址作为终端网关正常情况下主设备转发数据主设备故障时备份设备立即接管。配置相对简单在两台核心交换机上分别配置[H3C-Core-1] interface Vlan-interface 10 [H3C-Core-1-Vlan-interface10] vrrp vrid 1 virtual-ip 192.168.10.254 [H3C-Core-1-Vlan-interface10] vrrp vrid 1 priority 120核心交换机2上配置同样的VRRP组但优先级保持默认100这样核心交换机1成为主设备才是真正的转发网关。配置完VRRP之后要检查display vrrp确认主备状态正确虚拟IP都能ping通。测试时最直接的方法是把主设备的Vlan接口shutdown观察终端网关的转发是否无缝切换到备设备。真正让实验变得有价值的是把VRRP切换和OSPF路由联动起来。终端通过默认网关访问外部网络时如果核心交换机1是主网关那么终端发往外部的流量会先进核心交换机1再由它根据路由表转发出去。如果核心交换机1到上层出口的路由不好或者Cost值很大流量就可能从核心交换机1穿到核心交换机2再绕道上行性能下降不说还可能形成非对称路径。我在实验里遇到的真实情况是核心交换机1是VRRP主设备但它到出口设备的OSPF Cost值没有调整默认情况下所有环路接口Cost相同OSPF就出现了等价路由一部分流量从核心1走一部分从核心2走。由于核心2不是主网关从核心2出去的流量反而是由VRRP备份设备转发出去的虽然功能上没问题但路径不合理而且排障时会让人困惑。解决办法是在核心交换机1的上行接口上用ospf cost命令把Cost值调小让它成为出口流量的首选路径核心交换机2的上行接口Cost调大作为备份。这样VRRP的主备状态和OSPF的路由路径就保持一致了主网关的主设备同时也是出口流量的首选设备。这套联动机制验证起来也很直观。我在终端上持续ping外网地址然后手动切换VRRP主备观察丢包情况和路由表变化。配置合理的情况下丢包只有VRRP切换瞬间的那几包OSPF重新收敛之后路由很快恢复。如果丢包时间很长大多是因为OSPF的计时器配置不当或者VRRP的抢占延时设置得过长。VRRP抢占延时我设成了5秒这样备份链路稳定后再切换避免因为链路闪断导致VRRP频繁震荡。5. 综合验证与故障排查实录5.1 全网连通性验证清单实验做完不等于结束系统性的验证才是判断配置正确与否的依据。我整理了一份验证清单按顺序执行一遍基本上全网状态就摸清了。验证目标使用命令预期结果OSPF邻居状态display ospf peer所有邻居状态均为Full区域路由表display ospf routing各区域路由条目完整默认路由正确下发LSA类型display ospf lsdbStub区域无Type 4/5NSSA区域有Type 7MSTP实例状态display stp instance 1根桥正确端口角色符合预期VRRP状态display vrrp主备状态正确虚拟IP可ping通跨VLAN通信ping 192.168.20.1不同VLAN终端可以互通外部网络通信ping 出口设备接口地址经OSPF转发路径正常路由可达主备切换测试shutdown核心1相关接口VRRP快速切换OSPF重新收敛丢包可接受逐条执行清单的时候我最关注的是OSPF路由表。display ospf routing看到的不只是路由条目还能看到每条路由的下一跳和Cost值。比如业务网段192.168.10.0/24在核心交换机上看到的下一跳应该是对应汇聚交换机的互联地址Cost值应该符合链路带宽的默认计算规则。如果下一跳走错方向大概率是区域宣告错误或者Cost调整出了问题。除了路由表我还会在终端上做双向的tracert测试从终端A到终端B、从终端A到出口设备、从出口设备回访终端。tracert能直观地看到报文经过的每一跳如果路径和设计不一致很快就能发现是哪个环节出了问题。特别要提醒的是做完所有配置后一定要保存配置H3C上是save force不然模拟器或真机一断电全部配置就丢了。我实验时吃过这个亏调好的配置忘了保存重启后全部重来。5.2 这次实验里踩过的5个真实坑第一个坑是Router-ID没手动指定。实验初期有一台汇聚交换机没配Router-ID设备自动选了一个接口IP地址作为Router-ID。后来我给这台设备增加了一个Loopback地址并宣告进OSPF重启进程后Router-ID变成了新的Loopback地址所有邻居关系全部重建整网路由表刷了一遍业务中断了十几秒。教训就是Router-ID必须手动规划而且要选稳定接口的地址不能依赖自动选举。第二个坑是Stub区域配置不一致。我在Area 1的ABR上配了stub no-summary但区域内的汇聚交换机只配了stub结果ABR不向区域内下发Type 3 LSA区域的默认路由也没生成区域内所有设备的OSPF路由表几乎空了。因为ABR和区域内设备对区域类型的理解不一致OSPF会认为这不属于同一个区域配置有些设备直接中断了邻居关系。解决方法是保证特殊区域里所有路由器都配置相同的区域属性配置完成后用display ospf brief逐台核对。第三个坑是VRRP和OSPF的路径不一致。这个我在前面详细说过主网关设备的上行Cost值没调优导致一半流量从备份设备出去。当时排障时以为路由配置有问题查了接口状态、区域配置都很正常后来对照display ospf routing和实际转发路径才发现是等价路由的问题。这个坑在生产环境里特别容易踩因为功能上网络能用但性能不达标、排障困难调优方法就是通过Cost值控制路径。第四个坑是MSTP域名称不一致。我在模拟器里新增了一台接入交换机在图省事的情况下没有配置MSTP域直接启用了STP。结果这台交换机的端口变成了边界端口域内的生成树实例拓扑被意外改变部分VLAN的流量路径和预期不一致。排查时看display stp brief才发现其他交换机上的端口角色变了。最后在新增交换机上补齐了相同的MSTP域配置拓扑才恢复正常。第五个坑是OSPF计时器不匹配。我为了测试快速收敛把核心互联接口的Hello间隔改成了5秒Dead间隔保持默认40秒。另一端的接口还是默认的Hello间隔10秒由于Hello报文中的参数不一致邻居状态变得极不稳定一会儿Up一会儿Down。OSPF的Hello和Dead计时器并不需要两端完全一致但Dead计时器必须是Hello间隔的整数倍所以我调整两边配置后邻居才稳定下来。实验环境下乱改计时器问题不大生产环境一定要统一规划否则排查成本非常高。6. 写在实验之后这个综合实验做下来我最深的体会是网络排障不能只看一个协议要从整个数据转发的路径上去想问题。OSPF邻居正常不代表全网通畅MSTP拓扑健康也不代表流量路径最优VRRP主备状态正确更不代表网关转发一定没问题。三个协议叠加在一起任何一个环节的配置偏差都可能导致最终用户体验上的丢包和延迟。我后来在真实项目中遇到的很多故障根源往往不在某一个协议本身而是协议之间的配合出了问题比如VRRP切换和路由收敛的时序不一致或者MSTP的拓扑变化没有及时反映到三层路由中。最后再分享一个小建议实验做完之后把每台设备的配置导出存档配合验证结果形成一份完整的报告。以后网络出现问题翻配置记录比重新登录设备逐台排查要高效得多。我当时就是把每台设备的display current-configuration输出全部保存下来和验证命令的输出放在一起归档后来模拟器环境重置后恢复配置时派上了大用场。如果还想继续深入可以在这个实验基础上加入OSPF认证、BFD快速检测、路由引入过滤等内容把综合实验做成一个更完整的园区网演练项目。
