1. 项目背景与网络需求拆分1.1 为什么偏偏是MGRE和OSPF组合先把这个项目的核心诉求说清楚。“MGRE”全称是多点GRE也就是Multipoint GRE它解决的是分支节点多、隧道配置量大的问题。传统GRE要在每两个站点之间各建一条隧道五个站点就是五乘四除以二是十条隧道配置量直接爆炸而且后续每加一个分支都得把全网链路捋一遍。MGRE的思路是只有一个中心节点hub配置固定的隧道目标地址其他分支节点spoke通过注册机制动态学习到彼此的路由信息隧道自动建立分支之间也能直接通信不需要逐条手工配置。而OSPF选型主要是因为它作为动态路由协议在传统组网里调度灵活、收敛快、支持等价负载均衡教科书和实际工程里都大量使用。问题是OSPF在设计阶段根本没见过MGRE这种“半广播半非广播”的二层链路环境默认行为和实际物理环境对不上于是就有了本项目要解决的核心矛盾怎么让OSPF在MGRE隧道形成的NBMA网络中既不像点对点那样只认一个邻居又不像物理广播网那样选出个不合适的DR同时还要解决路由下一跳指向错误等一系列连锁问题。1.2 目标场景与实验拓扑设计这个项目适合的典型场景是一家公司有总部和多个分支分支之间需要直接互访不想绕总部转发。最常见的是三层网络架构总部路由器和分支路由器之间跑OSPF底层用MGRE隧道承载。实验环境我用的是三台路由器模拟命名依次为AR1总部hub、AR2分支A、AR3分支B实际工作中规模扩大到几十台spoke也完全适用配置逻辑是一样的。拓扑规划如下表设备角色接口地址隧道源说明AR1hub物理口G0/0/0202.100.1.1/24隧道口T0/0/010.1.1.1/24202.100.1.1总部核心隧道唯一固定目标AR2spoke物理口G0/0/0202.100.2.1/24隧道口T0/0/010.1.1.2/24202.100.2.1分支A通过MGRE注册到中心AR3spoke物理口G0/0/0202.100.3.1/24隧道口T0/0/010.1.1.3/24202.100.3.1分支B同上需要注意的是模拟器里写隧道配置时202.100.x.x这类公网地址是内网实验室环境里模拟出来的接口地址实际工程中对应的应该是运营商分配的合法公网IP或专线地址。原理和配置流程一致只是地址替换的问题。1.3 项目核心难点预判这个项目最尴尬的点在于OSPF的默认行为在MGRE环境下几乎处处出错。先梳理几个重点一个是DR选举问题MGRE默认网络类型是broadcast所有spoke之间都能建立邻居关系但spoke之间的隧道可能是按需建立的DR选择不当会导致路由信息无法被正确转发再一个是下一跳问题OSPF在广播多路访问网络里会把路由的下一跳指向DR但MGRE环境下DR可能是某台spoke其他spoke根本没有到这台spoke的直达隧道路由表就废了还有一个是邻居建立静态配置问题OSPF在NBMA环境中默认不会主动发送Hello包去探测对端只能被动等这直接导致邻居起不来。把这几个点列出来项目的整体思路就清楚了通过配置调整让OSPF在MGRE环境下正常工作。目标明确后面再展开配置就有的放矢了。2. MGRE隧道原理与配置底层逻辑2.1 隧道技术的演进路线要真正理解MGRE最好把它放在隧道技术的演进路线里看。普通的GRE也叫点到点GRE配置时两端都必须指定对端的真实IP地址这要求管理员对全网每一个站点的公网地址都了如指掌并且地址一旦变化就要重新配置。对于三四台设备可能无所谓但分支机构如果是几十个光是后期排查断链问题就够喝一壶的。NHRP下一跳解析协议的引入改变了这一切。NHRP相当于一个动态寻址系统每个spoke启动后主动到hub注册自己的公网地址和隧道地址的映射关系hub端维护一张NHRP映射表。当某个spoke想要和另一个spoke通信时它向hub查询目标隧道地址对应的公网地址拿到后直接建立一条到目标spoke的动态隧道。这就是MGRE最核心的价值隧道不再是一根根提前拉好的网线而是按需生长的网络。2.2 MGRE隧道配置的关键参数解析这个项目里三台设备的隧道起配逻辑是相同的下面直接给整段配置然后逐行说明用意。先看AR1的隧道配置interface Tunnel0/0/0 ip address 10.1.1.1 255.255.255.0 tunnel-protocol gre multipoint source 202.100.1.1 nhrp network-id 100 nhrp entry multicast dynamic第一处重点是tunnel-protocol gre multipoint这条命令把隧道类型指定为多点GRE。如果没有这条命令而是默认的GRE后面很多功能选项根本不会出现。第二处是nhrp network-id 100这个100是NHRP的标识符相当于给NHRP域起个名字同一个域里的所有隧道口必须配置一致否则压根不认对方。第三处是nhrp entry multicast dynamic这条命令的含义是允许动态注册过来的spoke接收组播包。OSPF的Hello报文是以组播地址224.0.0.5发送的默认情况下NHRP不会把组播包转发给动态注册的spoke不配置这条OSPF邻居永远起不来。这是本项目最容易踩的坑没有之一。再看spoke端的配置以AR2为例interface Tunnel0/0/0 ip address 10.1.1.2 255.255.255.0 tunnel-protocol gre multipoint source 202.100.2.1 destination 202.100.1.1 nhrp network-id 100 nhrp entry 10.1.1.1 202.100.1.1spoke端多了两条命令。destination 202.100.1.1指定了hub的真实地址这是为了建立初始隧道和注册。nhrp entry 10.1.1.1 202.100.1.1则是静态配置了一条hub的NHRP映射告诉spoke去往隧道地址10.1.1.1的下一跳物理地址是202.100.1.1。如果spoke不配置这条静态映射它不知道到哪去注册因为NHRP本身不能自举。2.3 为什么说MGRE隧道是NBMA网络理解MGRE环境下的OSPF问题必须先理解NBMA这个属性。NBMA全称是非广播多路访问意味着网络拓扑上虽然是多个节点可以互相访问但底层没有一个广播信道天然不具备Hello组播的传播条件。MGRE隧道就是标准的NBMA多个spoke共享同一个网段10.1.1.0/24理论上任何两台都能通信但hello报文到了hub之后该往哪转发hub需要根据NHRP表来决定而不是像交换机那样直接把流量从所有端口复制出去。这就带来一个OSPF认知上的重大偏差OSPF接口默认使用网络类型来推算链路特性而MGRE隧道口往往被自动识别为broadcast这让OSPF以为自己在一条正常的以太网链路上于是兴高采烈地开始选DR、发组播Hello结果nbma的底层现实直接让邻居关系无法建立、路由下一跳指向错误。整个项目的核心工作就是纠正这个偏差让OSPF的行为贴合NBMA的真实环境。3. 实验环境准备与接口配置完整流程3.1 模拟器选型与基础配置建议做这个实验我用的是HCL某厂商的图形化模拟器用eNSP等模拟器也可以核心命令基本通用。模拟器有一个需要提前注意的点MGRE隧道配置在某些模拟器版本里对报文封装的支持不完整可能出现隧道up但NHRP注册不成功的情况建议选较新的版本并且在布拓扑前先把所有物理接口的IP配置好确保物理层连通性这是排查后面所有问题的前提。三台设备的基础接口配置如下AR1上system-view sysname AR1 interface GigabitEthernet0/0/0 ip address 202.100.1.1 255.255.255.0AR2和AR3上同理把接口地址分别配置为202.100.2.1和202.100.3.1即可。还要给模拟器中的路由器加上loopback接口用来模拟内部业务网段。AR1上加一个LoopBack0地址1.1.1.1/32AR2加LoopBack0地址2.2.2.2/32AR3加LoopBack0地址3.3.3.3/32。这些环回口后续会通过OSPF宣告出去用来验证分支之间的路由学习情况。3.2 隧道配置逐行细节解释隧道配置阶段最容易出现的疑问是“为什么spoke要配destination而hub不配”。因为hub是全网唯一一个公网地址固定的节点它不需要向任何人学习它本身就是被注册的对象。而spoke必须知道hub在哪才能完成注册。有个类比很贴切hub就像是公司前台的座机号码所有人新入职都要先打这个号码报到而前台接了你的电话就会把你的分机号和工位记下来下次别人找你前台直接把分机号告诉对方让对方直接找你。AR1完整配置interface Tunnel0/0/0 ip address 10.1.1.1 255.255.255.0 tunnel-protocol gre multipoint source 202.100.1.1 nhrp network-id 100 nhrp entry multicast dynamic注意source后面的参数可以是接口名也可以是IP地址这里直接用IP更方便理解。如果源接口物理down了隧道也会跟着down所以检查物理接口状态是排查隧道故障的第一步。AR2和AR3在各自隧道口配好地址后SPOKE还需要一条到Hub的NHRP映射。AR2的NHRP映射配置已经在前面给出AR3完全照搬把地址替换成自己的即可。3.3 配置完成后的验证思路隧道配置完后先不要急着进入OSPF务必先验证NHRP注册是否成功。在AR1上执行命令display nhrp entry如果能看到两条动态注册的表项内容类似于10.1.1.2对应202.100.2.1、10.1.1.3对应202.100.3.1说明NHRP注册链路是通的。如果表项是空的直接配OSPF等于在沙子上盖楼后面所有问题都会从这里爆发。同样在AR2上用display nhrp entry应该能看到两条记录一条是静态配置的hub映射10.1.1.1对应202.100.1.1另一条是从hub动态学习到的AR3映射如果有通信需求产生的话。NHRP表正常后再追一次ping 10.1.1.1测试隧道连通性确认GRE封装正常然后再进入路由协议配置阶段。4. OSPF在MGRE环境下的配置与验证全流程4.1 OSPF网络类型选型对比到了这一步需要对OSPF接口网络类型做一个系统性的对比。OSPF接口网络类型主要有四种broadcast、non-broadcast、point-to-multipoint、point-to-point。每种类型对应不同的邻居发现机制和DR选举规则。网络类型发送Hello方式是否选举DR适用场景在MGRE下表现broadcast组播224.0.0.5选举以太网默认类型会产生DR问题不推荐non-broadcast单播手工指定邻居选举帧中继等需要手配邻居麻烦且DR问题仍在point-to-multipoint组播224.0.0.5不选举MGRE最优解邻居动态建立无DR路由正常从这个表能直观看出point-to-multipoint就是为MGRE这种链路量身定做的类型。因为P2MP模式下每个邻居都被视为一条点对点链路天然规避了NBMA环境下的“伪广播”问题。但默认的broadcast类型在部分设备上依然是MGRE隧道口的默认值不动它直接宣告OSPF就会出现各种谜之故障这也是项目名称核心的关键所在。4.2 推荐方案OSPF network-type point-to-multipoint配置在隧道口上把网络类型显式改成point-to-multipoint这是全网公认的最佳实践。配置命令如下三台设备都要做以AR1为例interface Tunnel0/0/0 ospf network-type p2mp在AR2和AR3上也同样执行确保ASBR/ABR的链路行为一致。然后进入OSPF进程宣告网段ospf 1 router-id 1.1.1.1 area 0.0.0.0 network 10.1.1.0 0.0.0.255 network 1.1.1.1 0.0.0.0AR2的router-id设为2.2.2.2network里加2.2.2.2AR3的router-id设为3.3.3.3network里加3.3.3.3。注意area 0.0.0.0等价于area 0写法上没问题为了清晰可以全写。为什么要把网络类型改成p2mp而不是non-broadcast呢non-broadcast虽然也是NBMA的标准网络类型但它要求管理员手工指定所有邻居而且还是会选举DR绕了一圈问题没少只是把组播Hello改成单播了。而p2mp天然不选DR也不依赖手工邻居列表OSPF会把每个NHRP学习到的spoke都当成一个点对点邻居对待逻辑干净利落。4.3 验证命令与预期结果配置完成后需要做一套完整的验证。最基本的邻居状态查看命令是display ospf peer。正常情况下AR1上能看到两个Full状态的邻居分别是2.2.2.2和3.3.3.3。AR2上能看到两个邻居一个是hub的1.1.1.1另一个是经过NHRP解析出来的AR3的3.3.3.3。如果你在AR2上只看到hub邻居而看不到AR3邻居不是配置挂了而是NHRP的动态解析还没有被OSPF的Hello消息触发稍等片刻或者ping一下3.3.3.3地址隧道建立后再看就出来了。路由表验证方面在AR2上执行display ip routing-table应该能看到1.1.1.1/32和3.3.3.3/32的OSPF路由下一跳分别是10.1.1.1和10.1.1.3。这一步是项目成功的关键指标说明OSPF通过MGRE隧道学习到了分支站点的内部路由。4.4 验证OSPF DR选举现象对比实验为了加深理解可以做一个对比实验先在默认broadcast网络类型下启动OSPF观察现象再改成p2mp。默认情况下在hub上执行display ospf peer会看到三个邻居状态卡在ExStart/Exchange这是因为hello组播包到了hub之后不会自动转发给两个spoke只有先和hub建立邻居的spoke才有机会选举DR而DR选举本身又依赖全通链路最终形成死锁。这种对比实验的价值在于它把文档里抽象的概念变成肉眼可见的故障现象做一次比看十遍理论都管用。很多同事问我为什么一定要用p2mp我说你先把p2mp改成默认跑一遍OSPF看到ExStart卡死状态你自己就明白了。5. 核心问题排查实录与常见坑位总结5.1 邻居状态卡在Init/ExStart的根因分析实际配置过程中最常见的故障是OSPF邻居状态卡住不动。一种是卡在Init状态这说明收到了对方的Hello但对方没有收到你的Hello多半是NHRP组播转发没配好回查一下hub上是否配置了nhrp entry multicast dynamic。另一种是卡在ExStart状态这说明DR选举出问题了或者MTU不一致。MTU问题很容易被忽略。GRE隧道封装会额外增加24字节头部开销默认情况下隧道口MTU是1500字节但物理口的MTU可能是1500加上GRE头部和IP头部后实际报文就超了。如果两端MTU不一致DBD报文会在半路被丢弃OSPF邻居状态反复横跳。解决办法是保证隧道口两端MTU一致最好设置为1476字节物理链路MTU保持1500这样封装后正好等于物理MTU。5.2 路由表有路由但数据包不通的排查这是第二个高发问题。在AR2上能看到OSPF路由但ping不通3.3.3.3。第一步先查NHRP表看AR2有没有AR3的动态映射。如果映射不存在原因是两个spoke之间还从没发生过直接通信NHRP查询还没有触发。最简单的触发方式是ping一下目的地址让OSPF或者NHRP触发动态隧道建立。如果映射存在但ping还是不通下一步抓包看GRE封装目的地址。执行display ip routing-table 3.3.3.3看路由下一跳是10.1.1.3还是10.1.1.1。如果下一跳指向hub的10.1.1.1说明OSPF还在沿用broadcast网络类型的逻辑把流量先送到DR再转发。这个问题正是前面把网络类型改成p2mp要解决的核心矛盾配置没有生效时就会出现这种半吊子状态。5.3 配置不一致引发的连带故障NHRP network-id不一致是最隐蔽的坑。如果AR2配置的network-id是100AR3配置的是200两者虽然都能和hub建立隧道但彼此之间无法通过NHRP互相解析。从hub上看NHRP表似乎都是正常的但分支互访永远失败。排查思路是逐台设备查验display current-configuration interface Tunnel0/0/0重点对比network-id、隧道模式、源地址和NHRP映射。另外一个常见问题是OSPF和NHRP使用的区域不一致。比如hub把隧道口宣告进area 1而spoke把隧道口宣告进area 0结果邻居虽然能建立但由于区域划分逻辑错误路由汇总出问题远端站点学不到目标网段。建议全网隧道网段统一放进同一个area省去类型3LSA过滤的烦恼。5.4 物理链路闪断对MGRE隧道的影响与对策最后说一个生产环境才容易遇到的问题物理链路闪断导致NHRP表项老化隧道被动拆除但OSPF邻居可能还在Dead Timer倒计时内没有察觉。当物理链路恢复时spoke会重新注册但OSPF的Hello是组播发送的hub没有主动向spoke发起Hello的能力导致邻居关系迟迟无法恢复。解决办法是合理配置NHRP的注册周期、保持时间以及与OSPF Hello/Dead Timer的配合。见过不少工程师在这里折腾半天最后发现是NHRP保持时间设得太短表项频繁失效导致的连锁问题。6. 生产环境中的应用经验与实践建议6.1 从实验到生产需要补充的细节实验做完后切换到生产环境有几个细节必须额外处理。一是安全加固MGRE隧道本身没有加密能力GRE报文在公网上明文传输生产环境通常需要叠加IPsec加密这个在HCL模拟器里虽然也能模拟出部分效果但真正部署时要注意IPsec和GRE的嵌套顺序。二是NHRP认证在NHRP配置里加上认证密钥防止伪造注册报文这在多分支网络中尤其重要。生产环境的规模扩大后hub的NHRP表规模和OSPF邻居数量会上升建议给hub设备做性能基线测试。当spoke数量超过100个时hello报文处理和NHRP查询的压力会显著增加有条件的可以在hub上做冗余部署配合VRRP实现网关冗余同时两个hub之间也通过MGRE互备。6.2 关于网络类型选型的补充思考虽然p2mp是MGRE环境下的推荐选择但也存在一种特例如果你的设备侧有多条链路捆绑的需求希望流量负载均衡可以考虑把隧道口设为broadcast并手工指定所有邻居但让hub做DR且把所有spoke的优先级调成0保证永远不会被选为DR。这种方案在纯Hub-Spoke模型中勉强可用但分支间需要直接通信时隧道的动态建立和OSPF的DR选举机制会产生冲突建议还是优先p2mp。还有一种更简单的替代方案如果分支数量确实不多比如三五个OSPF直接跑在GRE over IPsec隧道上每条隧道一对一的点对点配置网络类型设成point-to-point逻辑和排障都比MGRE简单得多。但分支数量增长后隧道配置量爆炸的问题会重新出现所以到底选哪种方案还是要看规模和运维成本。6.3 运维排查速查表现象排查点修复手段NHRP表为空物理链路、network-id、source地址核对配置查看物理接口状态邻居卡在Inithub缺少multicast dynamic配置在hub隧道口补上该命令邻居卡在ExStartMTU不一致统一隧道口MTU推荐1476分支互访不通检查NHRP表、路由下一跳触发NHRP解析或启用p2mp路由表无远端路由区域宣告遗漏、Hello被过滤核对area配置和过滤策略链路恢复后邻居不恢復NHRP保持时间太短调整NHRP保持时间匹配OSPF计时器6.4 后续扩展方向做完了基本的OSPF over MGRE后面还可以继续扩展不少方向。比如在分支数量增加后引入BGP作为路由承载用BGP的IBGP over MGRE替代OSPF规避OSPF在大规模NBMA下的收敛压力也可以把OSPF区域设计成多个areahub作为ABR连接各区域spoke接入骨干区域实现更精细的路由策略控制。另一个方案是把OSPF改成路由策略下发在hub上配置路由过滤控制不同分支之间的互访权限这是一种比较典型的安全需求。我个人在实际项目中体会最深的一点是排障时永远不要先怀疑协议配置从物理层到隧道到NHRP再到OSPF逐层排查哪怕模拟器里也是这样。重配置之前先看现有状态状态输出解释一切问题。这个项目做完以后你对OSPF网络类型、NHRP注册机制、GRE封装的报文流转过程都会有一个脱胎换骨的认识这比背十遍协议状态机口诀都有用。