1. 为什么要把OSPF跑在MGRE上场景、收益与坑HCIP-Datacom阶段的进阶实验不少但“基于MGRE的OSPF动态路由配置”这套组合拳值得单独拿出来复盘。MGRE解决的是多点隧道自动建立的问题OSPF解决的是隧道之上动态路由同步的问题两件事单独看不难一旦叠在一起就会出现DR选举、组播映射、下一跳处理这些在普通以太网上很少碰到的细节。我最初做这个实验时也是照着网上零散的配置片段敲结果邻居状态一会儿卡在ExStart一会儿路由表里出现“看起来能通但实际封装不了”的下一跳折腾了整整一个晚上才把底层逻辑理顺。这篇文章就是我重新整理后的完整操作记录适合正在备考HCIP的人也适合在实际分支互联项目中需要设计MGRE承载OSPF的工程师。先说明这个实验解决的真实问题。一家公司总部和多个分支组网最简单粗暴的方案是每两个节点之间建一条点对点GRE隧道形成全互联。但分支数量一旦增加到十个以上隧道数量会按排列组合增长配置和维护成本直接爆炸。MGRE的价值在于所有分支只需要和中心节点建立隧道分支之间的流量默认通过中心转发新分支上线时只需要在本地配置一条指向中心的NHRP注册条目中心甚至不用预先知道分支的公网地址。这使得“分支动态接入”成为可能。而OSPF在这些隧道上的作用是把各节点的内部网段动态通告出去避免每条路由都靠手工静态配置。不过OSPF放在MGRE上有两个天然摩擦点。第一MGRE本质是NBMA非广播多点接入环境OSPF在设计之初默认网络类型是广播型或点对点型对NBMA的支持需要专门配置网络类型。第二OSPF的Hello报文默认走组播地址224.0.0.5而MGRE隧道底层并不天然支持组播必须借助NHRP建立“组播映射”才能让组播报文被正确封装。很多人在这一步没搞明白直接把Tunnel接口宣告进OSPF结果邻居始终建立不起来。后面我会逐步拆开讲。实验环境我建议用模拟器完成拓扑不复杂三台AR路由器就够了。R1作为中心节点Hub模拟总部出口R2、R3作为分支节点Spoke模拟两个远端分支。三台设备的物理接口接入同一个广播域模拟一个简单的承载网络保证底层IP互通。这样能最大限度聚焦MGRE和OSPF本身不被复杂的底层链路干扰。2. 动手之前地址规划、隧道模式与NHRP的关系2.1 地址规划表先定角色再定地址很多实验翻车不是配置敲错而是IP地址规划混乱。MGRE隧道上要跑OSPF需要预留一个独立的隧道子网同时每个节点还需要一个稳定的环回地址用来当Router ID和测试连通性。我的规划如下设备角色物理接口地址环回地址Tunnel接口地址R1Hub中心100.1.1.1/241.1.1.1/3210.1.1.1/24R2Spoke分支100.1.1.2/242.2.2.2/3210.1.1.2/24R3Spoke分支100.1.1.3/243.3.3.3/3210.1.1.3/24物理网段有两点需要注意。第一承载网地址不要宣告进OSPF区域否则隧道和物理路径同时参与路由计算很容易出现次优路径甚至让故障排查变得混乱。第二Tunnel地址必须和底层物理地址完全区分开二者属于不同的逻辑层面混用的话NHRP注册和OSPF邻居关系都会变得非常难理解。环回地址在这里不只是用来测试。OSPF必须有一个稳定的Router ID手工指定为环回地址是最稳妥的做法。同时分支内部的业务网段我会用环回地址来模拟比如R2的环回就是“分支2的业务网段”这样验证路由时可以直接ping到2.2.2.2非常直观。2.2 隧道模式别混淆点到点GRE和GRE P2MP华为路由器上Tunnel接口的默认隧道协议是GRE但默认模式更接近点到点。要做MGRE必须在Tunnel接口下显式执行tunnel-protocol gre p2mp。这句话的意思是把这台设备的隧道接口配置为“多点GRE”即允许一个隧道接口下动态建立多个对端。没有这条命令后续的NHRP配置基本不生效或者会出现一些非常诡异的现象。理解这一点你需要把GRE和MGRE分开看。普通GRE隧道是“一根管子连两端”配置时必须指定对端隧道地址和源接口数据流向是确定的。MGRE则是“一个会合点加多个动态成员”隧道接口只是定义一个逻辑入口真正的对端关系由NHRP动态学习。中心节点不需要提前知道有多少分支分支通过注册消息把自身的公网地址告诉中心中心再把映射关系记录到NHRP表中。所以配置顺序必须是先切换Tunnel协议模式再设置本端源地址最后配置NHRP参数。如果顺序反了有些版本会提示命令冲突或者即使配置成功也不会按预期工作。2.3 NHRP为什么是MGRE的控制面NHRP下一跳解析协议在MGRE里的角色可以理解成“动态通讯录”。分支节点启动后向中心节点发送注册请求中心在自己的NHRP表里记录下“隧道地址10.1.1.2对应公网地址100.1.1.2”这条映射。后续分支要向某个隧道地址发包时先查NHRP表决定以太网报文封装到哪个真实的IP地址。OSPF跑在MGRE上还需要解决组播问题。OSPF的Hello报文是组播的但GRE隧道不是天然组播链路不可能像交换机那样把组播报文“广播”给所有分支。解决办法是在中心节点配置nhrp entry multicast dynamic这句的意思是所有动态注册上来的分支自动加入中心节点的组播发送列表。这样中心把组播Hello发给R2、R3时会分别封装成两个单播包送出去。分支节点默认不会向其他分支发送组播所以整个OSPF邻居关系只会发生在中心和每个分支之间分支之间不直接建立OSPF邻居这其实是我们要的结果。3. 配置实录Hub与Spoke的完整命令3.1 中心节点R1的完整配置先登录R1设置设备名并配置物理接口和环回口system-view sysname R1 interface GigabitEthernet0/0/0 ip address 100.1.1.1 255.255.255.0 undo shutdown interface LoopBack0 ip address 1.1.1.1 255.255.255.255然后创建Tunnel接口。这是我的核心配置每一条都有目的interface Tunnel0/0/0 ip address 10.1.1.1 255.255.255.0 tunnel-protocol gre p2mp source 100.1.1.1 nhrp network-id 100 nhrp entry multicast dynamicsource 100.1.1.1指定了隧道报文的源地址也就是本端物理接口地址。nhrp network-id 100定义了一个NHRP域同一个MGRE网络内的所有节点必须配相同的network-id否则互相不认。这里我选100实际生产环境用网段序号或区域编号都行关键是要全网络一致。最后配置OSPF。我只宣告环回和Tunnel网段物理接口100.1.1.1不宣告ospf 1 router-id 1.1.1.1 area 0.0.0.0 network 1.1.1.1 0.0.0.0 network 10.1.1.0 0.0.0.255为什么要用区域0因为MGRE网络本身可以看成一条逻辑上的骨干链路所有节点都应该在同一个OSPF区域最自然的选择就是区域0。如果分支很多且各自有大量内部明细路由后续可以再拆区域但在基础实验里保持区域0最简单也最容易排查问题。3.2 分支节点R2、R3的配置差异分支节点和中心节点最大的不同在于分支需要主动向中心注册并且要指定中心的NHRP条目。R2的配置如下system-view sysname R2 interface GigabitEthernet0/0/0 ip address 100.1.1.2 255.255.255.0 undo shutdown interface LoopBack0 ip address 2.2.2.2 255.255.255.255 interface Tunnel0/0/0 ip address 10.1.1.2 255.255.255.0 tunnel-protocol gre p2mp source 100.1.1.2 nhrp network-id 100 nhrp entry 10.1.1.1 100.1.1.1 register关键在最后一行nhrp entry 10.1.1.1 100.1.1.1 register。前半部分是中心的隧道地址和公网地址后半部分的register表示本端要向这个地址发送NHRP注册消息。如果没有register关键字这条条目只是静态映射NHRP不会主动注册中心节点的组播列表里也不会出现这个分支OSPF邻居很可能起不来。R3的配置完全类似把物理接口、环回和Tunnel地址换成对应网段即可。这里我强调一下分支节点之间不需要配置对方的NHRP条目。默认情况下分支之间的数据要经过中心转发因此分支只需要认识中心就够了。3.3 配置完成后如何快速验证配置完不要急着看OSPF先验证NHRP注册是否成功。在R1上执行display nhrp peer all正常情况下可以看到两条对端记录状态为up。R2和R3的NHRP表里应该能看到一条指向中心的记录。如果NHRP表是空的后面OSPF一定起不来这时候首先检查network-id、source地址以及承载网连通性。然后验证OSPF邻居display ospf peer brief我在R1上看到的输出大致是这样的OSPF Process 1 with Router ID 1.1.1.1 Peer Statistic Information Area Id Interface Neighbor Id State 0.0.0.0 Tunnel0/0/0 2.2.2.2 Full/ - 0.0.0.0 Tunnel0/0/0 3.3.3.3 Full/ -两个邻居都达到Full状态说明OSPF正常建立了邻接关系。再查看路由表R2上应该能看到2.2.2.2自己的路由同时也能看到3.3.3.3的路由下一跳是10.1.1.1也就是中心节点的Tunnel地址。这个下一跳非常重要后面我会专门讲它为什么不是分支地址而是中心地址。最后做一次跨分支连通性测试。在R2上ping 3.3.3.3能通就算成功。我建议同时加上-a 2.2.2.2指定源地址确保测试走的是环回而不是物理接口。3.4 顺手做的收敛调优实验能跑通之后我习惯调整一下OSPF Timer让收敛速度更快。Tunnel接口在P2MP网络类型下OSPF默认Hello间隔是30秒Dead间隔是120秒。如果分支数量多这个默认值偏保守故障感知会非常慢。我会统一改成10秒和40秒interface Tunnel0/0/0 ospf timer hello 10 ospf timer dead 40需要提醒的是同一OSPF广播域内所有节点的Timer必须一致否则邻居建立会失败。所以三个设备都要改不能只改中心节点。4. 把OSPF网络类型选对P2MP、Broadcast还是NBMA4.1 先确认Tunnel接口的OSPF网络类型这是整个实验里最容易踩坑的一步。很多人在Tunnel接口下配置完OSPF后不会去主动查接口网络类型直接去看邻居结果出了问题根本不知道从哪排查。在华为VRP上Tunnel接口运行OSPF时默认网络类型是P2MP。用下面这条命令可以确认display ospf interface Tunnel0/0/0如果发现显示的网络类型不是P2MP而是Broadcast或NBMA不要慌手动指定为P2MP即可interface Tunnel0/0/0 ospf network-type p2mp为什么P2MP是MGRE下的最优选择因为P2MP网络类型允许一个接口连接多个节点但不需要像NBMA那样手工指定邻居列表也不需要像Broadcast那样进行DR选举。它天然适合“一个中心带多个分支分支之间不建立邻接关系”的拓扑。4.2 别轻易改成BroadcastDR选举会把路由搞乱我在网上看到过不少配置教程把Tunnel接口的OSPF网络类型改成Broadcast理由是“模拟以太网环境让所有节点自动建立邻居”。这个思路在物理拓扑完全互联的场景下可行但在MGRE这种逻辑上非广播的链路里非常危险。原因是Broadcast网络类型会触发DR和BDR选举。在物理以太网中所有路由器都在同一个二层域DR的选择不会影响连通性因为即使不是DR也能通过交换机直接发送组播。但MGRE底层没有这种广播能力组播报文必须依赖NHRP组播映射一条条封装。如果某个分支被选成DR中心节点未必会向它发送组播Hello导致OSPF邻居建立不上或者即使建立了路由表的完整度也完全不可控。更进一步说就算你强行把中心节点配置成DROSPF在Broadcast网络类型下只会让DR和BDR与其他路由器建立Full邻接关系非DR之间只停留在2-Way状态。如果某两个分支之间的路由要靠二者直接交换这条路径就断了。P2MP模式则不同OSPF不会区分DR/BDR中心与每个分支都形成Full邻接路由完整度有保障。4.3 P2MP模式下下一跳为什么会被“强制改写”这是P2MP网络类型最容易被忽略的细节。在R2的路由表里到达R3环回3.3.3.3的下一跳是10.1.1.1而不是10.1.1.3。很多初学者会困惑明明R3的Tunnel地址是10.1.1.3为什么下一跳指向中心这是因为在P2MP网络中OSPF默认把通过该接口通告出去的路由的下一跳设置为“到达目的节点的相邻接口地址”。对于R2来说它和R3之间没有直连的OSPF邻居关系R3的路由LSA是由中心R1中转的。R1为了让R2能把数据正确地封装到中心会在LSA转发时把下一跳改写为自己的接口地址。这样R2发送到3.3.3.3的数据包隧道目的地址是10.1.1.1再由中心通过自己的NHRP表转发给R3。理解了这一点你就明白了为什么中心节点的nhrp entry multicast dynamic如此关键它不仅是OSPF组播Hello的发送机制也是数据面转发时把隧道地址“翻译”成真实公网地址的查询依据。如果没有中心这个翻译角色R2就算知道下一跳是10.1.1.1也不知道这个地址在物理网络上该封装到哪个目的IP。4.4 通过Cost控制分支互访路径在默认配置下分支之间的流量全部经过中心转发。这个路径是否符合预期取决于业务需求。如果分支之间有大量实时流量不想绕行中心可以考虑在全互联的MGRE环境下让分支间直接建立OSPF邻居或者在中心启用NHRP的shortcut特性。但基础实验中让流量经过中心反而是最简单稳定的设计。不过有一点值得注意Tunnel接口的OSPF Cost如果设置不当可能让分支认为“直连隧道”比“走中心”更优从而产生非预期的路径选择。实际环境中我建议明确给Tunnel接口配置一个统一的Cost值比如interface Tunnel0/0/0 ospf cost 10这样无论底层物理链路带宽有多少差异OSPF在计算隧道内路由时都有一个确定的开销基准不会因为承载网走的是千兆还是百兆产生歧义。5. 真实排障实录从“邻居卡在ExStart”说起5.1 现象一邻居卡在ExStart/Exchange我最初配置完在R1上执行display ospf peer brief发现R2的邻居状态一直卡在ExStart就是不进Full。当时我第一反应是隧道问题查了NHRP表发现注册都正常物理链路也通于是陷入困惑。后来才意识到是MTU问题。Tunnel接口默认MTU是1500字节但GRE封装会额外增加至少24字节的报文头。OSPF的DD报文如果按1500字节发送经过GRE封装后会超过物理接口的MTU导致对端收不到完整报文邻居协商就卡在ExStart阶段。解决办法是统一降低Tunnel接口的MTU。我在三台设备上都执行了interface Tunnel0/0/0 mtu 1400然后重启OSPF进程或清除接口状态邻居马上就从ExStart推进到Full。这个坑在物理链路带宽不高时格外明显建议做实验一开始就把MTU设置好不要等出了问题再排查。5.2 现象二邻居Full了路由却缺胳膊少腿还有一次我明明看到R1上有两个Full邻居但R2的路由表里只有中心的路由看不到R3的环回。当时我怀疑是OSPF区域配置不一致检查了一圈都没问题。最后用display ospf interface Tunnel0/0/0一看才发现接口网络类型被之前的配置脚本改成了Broadcast。这种情况下R2和R3之间没有建立OSPF邻接关系R3的路由LSA能否传到R2完全取决于DR选举结果和中心节点的转发能力。如果不巧R2或R3被选成了DR而中心节点又不是DR就很容易出现路由不完整。我当时的解决办法很简单把那台设备上的Tunnel接口网络类型改回P2MP清掉OSPF进程重新协商所有路由就正常了。这里要强调一个习惯修改接口网络类型后一定执行reset ospf process或者把接口先shutdown再undo shutdown否则旧邻居关系不会立刻重建状态可能一直停留在旧的网络类型判断上。5.3 现象三ping通了但traceroute路径和预期不符路由表看起来完全正常跨分支ping也通了但客户问我“分支互访的路径是不是直连”我在R2上执行traceroute 3.3.3.3发现第一跳就是R1的Tunnel地址第二跳才是R3的Tunnel地址。这其实不是故障而是MGRE默认的hub-spoke转发模型。如果确实需要分支间流量不绕中心需要额外启用NHRP的shortcut功能让分支在转发时主动向中心查询目的地的真实公网地址然后建立直连隧道。这个功能涉及更多配置参数建议放到实际有需求的场景中再研究。基础实验阶段看到traceroute路径经过中心说明数据面工作正常不需要怀疑配置有误。我通常在交付文档里会主动写清这一点避免后续运维人员把正确的路径当成环路去排查浪费大量时间。5.4 排查命令速查表为了方便排障我把常用命令整理成一张速查表排查目标关键命令关注点底层IP连通ping 100.1.1.x物理链路是否正常NHRP注册状态display nhrp peer all对端映射是否upflag是否为register隧道组播映射display nhrp entry multicast中心是否有分支的动态组播条目OSPF接口状态display ospf interface Tunnel0/0/0网络类型、MTU、Timer是否匹配OSPF邻居状态display ospf peer brief状态是否FullArea是否一致路由表完整性display ip routing-table protocol ospf各环回路由是否存在下一跳是否合理数据面转发路径traceroute 某个环回地址是否按预期经过hub转发6. 几个能让配置更稳的小技巧6.1 把Tunnel地址设在独立子网别偷懒我见过有人为了省地址把Tunnel接口配置成ip address unnumbered interface LoopBack0让隧道地址直接复用环回地址。这个配置在纯GRE点对点下能用但在MGRE环境下会让NHRP表项的逻辑变得混乱尤其是中心节点要做组播映射时区分“环回地址”和“隧道协议地址”的边界会非常模糊。建议老老实实划一个独立子网给隧道后续加分支也方便。地址规划省下来的那点资源往往会在排障时加倍还回去。6.2 BFD联动OSPF让隧道故障暴露更快OSPF在网络故障后主要靠Dead Timer来感知邻居失效。如果按前面调优设置了Dead 40秒在分支业务敏感的组网里仍然太慢。这种情况下可以启用BFD联动OSPFinterface Tunnel0/0/0 ospf bfd enable启用后OSPF会为每个邻居建立BFD会话当承载链路出现中断或严重丢包时BFD能在毫秒级检测到并把故障通告给OSPF实现秒级甚至毫秒级收敛。需要注意BFD报文本身也要经过NHRP映射所以在中心节点要确保组播映射和NHRP表项是完整的否则BFD会话可能起不来。6.3 物理接口千万别顺手宣告进OSPF这是我觉得最值得强调的生产经验。无论是实验还是实际项目总有人因为“想省事”直接把所有接口都宣告进OSPF结果物理接口和Tunnel接口同时出现在路由表里。这个时候流量到底走隧道还是走物理链路完全取决于OSPF Cost对比一旦物理链路Cost更小分支间的流量就会绕到奇怪的路径上甚至出现来回路径不一致的问题。正确的做法是OSPF只宣告Loopback和Tunnel网段。物理承载网保持一个独立的IGP域或者干脆用静态路由保证底层互通。这个原则不仅适用于MGRE任何隧道叠加场景都应该遵守。6.4 模拟器与真机的几个差异我用模拟器做实验时遇到过几个和真机行为不完全一致的地方。比如模拟器里NHRP注册速度很快几乎没有延迟真机上如果中心节点负载高注册可能出现稍许延迟导致OSPF邻居建立慢。另外模拟器对MTU问题表现得非常“宽容”我甚至见过默认1500 MTU也能正常协商的情况但真机上一般不行。所以实验做完后如果有条件建议在真机或仿真程度更高的环境里再跑一遍重点验证MTU、BFD和NHRP注册超时这三个点。最后说一点我自己的操作体会。MGRE加OSPF这套组合本质上是一个“信令面”和“数据面”解耦的网络模型NHRP负责动态发现OSPF负责路由同步GRE负责封装转发。把每一层负责的事情在脑子里拆清楚配置和排障都会轻松很多。做实验时不要急着敲命令先画一张拓扑图标注好每个节点的角色、隧道地址和NHRP映射再动手配置这样的人为失误至少能减少八成。
