HCIP备考路上MGRE和OSPF的组合实验几乎是一道绕不过去的坎。很多人单独配置MGRE或者单独配置OSPF都没问题一旦把两者放在同一个实验里就开始出现各种奇怪的现象邻居明明配置了却起不来、路由表里缺条目、数据包走了一圈又绕回来。我当年练这个实验的时候也踩了不少坑今天就把整个练习过程、技术原理和排错思路完整梳理一遍给正在备考或者工作中需要用到类似组网的朋友做个参考。1. 这个实验到底在练什么1.1 从HCIP考试说起HCIP华为认证高级网络工程师的考试里路由交换方向一直是报考人数最多的方向之一。其中关于MPLS、BGP、OSPF、组播等高级特性的考察基本都会落在综合实验题里。MGRE多点GRE隧道和OSPF的结合是各培训机构练习册里极其常见的一道综合题也是我在备考时花了最多时间琢磨的一个实验。这道练习题的典型场景是这样的总部和多个分支机构通过运营商网络互联但是各分支之间没有直达的物理链路需要借助MGRE隧道构建一个逻辑上的全互联网络然后在隧道接口上运行OSPF让所有站点之间能够动态学习路由。听起来不复杂但实际操作中MGRE隧道的动态建立机制、OSPF在网络类型上的适配、以及多种路由协议共存时的路径选择处处都是考点。1.2 为什么要单独练习MGRE和OSPF的组合MGRE本质上解决的是“多站点动态隧道”的问题。传统的GRE隧道需要手工指定隧道对端地址每个站点之间都要建立一对一的关系站点多了以后配置量巨大。MGRE引入了一个中心节点Hub和一个注册机制NHRP分支节点Spoke只需要知道中心的地址就能动态注册并且可以动态学习到其他分支的信息从而在分支之间直接建立隧道。这种Hub-Spoke模型在实际组网中非常普遍尤其是分支机构多、链路动态变化的场景。而OSPF是当前使用最广泛的IGP协议之一它的邻居发现、LSA泛洪、DR/BDR选举等机制跑在普通以太网链路上没有任何问题。一旦把它移植到隧道接口上情况就变了。隧道接口下面是一个虚拟的逻辑链路底层可能是GRE封装也可能是MGRE动态建立的隧道OSPF在这条链路上怎么选DR、怎么建立邻居、怎么传递路由都需要认真设计。把这两个技术放在一起练习本质上是在训练一种组网思维如何在不可控的传输网络上构建一个可控、稳定、高效的路由体系。这个能力在真实项目里太重要了尤其是帮企业做多分支互联、总部到分支的冗余设计时几乎每天都要和这类问题打交道。1.3 适合谁练这个实验如果你是HCIP备考学员这个实验是必练的项目如果你已经工作了平时主要做园区网或企业网运维这个实验能够帮你把IP承载网和路由协议之间的关系理解得更透彻。我个人建议有一定OSPF基础的朋友再上手这个实验不然可能会在多个知识点之间来回打转。2. 实验环境与基础配置准备2.1 模拟器选择练习这个实验我推荐使用华为官方的eNSP模拟器原因很简单HCIP考试本身就在eNSP环境下操作提前熟悉模拟器环境对考试是有帮助的。eNSP里AR系列路由器对MGRE和OSPF的支持都比较完整模拟出来的行为和生产环境非常接近。有些朋友习惯用其他模拟器来练这个我不反对但有一点需要注意不同模拟器对GRE隧道报文的模拟粒度不同某些模拟器对NHRP协议的支持不完整会导致实验现象和理论不一致。我在练习过程中就遇到过模拟器里隧道起不来但同样的配置放到真机上完全正常的情况。所以如果条件允许优先选择eNSP。2.2 实验拓扑搭建这里我用一个最基本的Hub-Spoke拓扑来演示。三台路由器一台R1作为总部Hub两台R2、R3作为分支Spoke。R1和R2、R3之间通过运营商网络互联公网地址分别规划如下R1的G0/0/0接口地址是202.100.1.1/24R2的G0/0/0接口地址是202.100.1.2/24R3的G0/0/0接口地址是202.100.1.3/24。三台设备的Loopback接口分别作为各自的隧道源和OSPF Router ID规划为192.168.0.1/32、192.168.0.2/32、192.168.0.3/32。内网网段规划R1背后模拟一个总部内网网段172.16.1.0/24R2背后模拟分支1内网网段172.16.2.0/24R3背后模拟分支2内网网段172.16.3.0/24。2.3 基础配置脚本先把三台路由器的接口和Loopback地址配置好。这里我把公共部分写出来后面小节再分别补充隧道和OSPF的配置。R1的配置sysname R1 interface GigabitEthernet0/0/0 ip address 202.100.1.1 255.255.255.0 interface LoopBack0 ip address 192.168.0.1 255.255.255.255R2的配置sysname R2 interface GigabitEthernet0/0/0 ip address 202.100.1.2 255.255.255.0 interface LoopBack0 ip address 192.168.0.2 255.255.255.255R3的配置sysname R3 interface GigabitEthernet0/0/0 ip address 202.100.1.3 255.255.255.0 interface LoopBack0 ip address 192.168.0.3 255.255.255.255到这里三台设备的底层互联已经通了接下来就是本次实验的重头戏——MGRE隧道的配置。3. MGRE隧道配置实战3.1 MGRE隧道接口核心配置MGRE的隧道接口配置和在接口上启用一个隧道协议的逻辑是类似的只不过协议类型变成了GRE Multipoint。R1作为Hub节点只需要配置一个隧道接口定义隧道源和NHRP参数。关键在于隧道目的地址不需要配置因为NHRP会动态维护对端信息。R1的隧道配置如下interface Tunnel0/0/0 ip address 10.1.1.1 255.255.255.0 tunnel-protocol gre multipoint source LoopBack0 nhrp network-id 100 nhrp entry multicast dynamic重点解释一下这几个命令的含义。tunnel-protocol gre multipoint是让隧道接口工作在MGRE模式source LoopBack0指定隧道的源地址源地址可以是一个接口名也可以直接写IP地址这里用Loopback0是为了稳定nhrp network-id 100是NHRP的网络标识同一MGRE网络内的设备必须配置相同的network-idnhrp entry multicast dynamic表示动态学习到的对端都会加入到组播分发列表里这个命令在Hub节点上很重要后面会细说。R2和R3作为Spoke节点配置略有不同。它们除了NHRP network-id外还需要手工指定Hub节点的NHRP映射以便完成注册。R2的隧道配置interface Tunnel0/0/0 ip address 10.1.1.2 255.255.255.0 tunnel-protocol gre multipoint source LoopBack0 nhrp network-id 100 nhrp entry 10.1.1.1 192.168.0.1 registerR3的隧道配置interface Tunnel0/0/0 ip address 10.1.1.3 255.255.255.0 tunnel-protocol gre multipoint source LoopBack0 nhrp network-id 100 nhrp entry 10.1.1.1 192.168.0.1 register这里nhrp entry 10.1.1.1 192.168.0.1 register的意思是隧道对端IP是10.1.1.1对应的NBMA地址也就是物理网络地址是192.168.0.1并且要主动向这个对端注册。对于Spoke节点来说这个命令就是告诉设备Hub在哪里必须要配置。3.2 验证MGRE隧道建立状态配置完成后先别急着往下走一定要先验证隧道状态。在R1上执行display tunnel-info all这个命令能够看到所有隧道接口的信息重点关注Tunnel0/0/0是否处于UP状态。如果隧道状态是DOWN需要回到隧道接口下检查源地址是否可达、NHRP配置是否有遗漏。再执行display nhrp peer all在R1上正常应该能看到R2和R3的动态NHRP表项。每个表项会包含对端隧道IP、对端NBMA地址、以及表项的Flag状态。如果Flag里带有register字样说明注册已经完成。在R2上执行同样的命令正常情况下能够看到两条表项一条是手工配置的Hub节点映射Flag是static一条是动态学习到的对端Spoke节点Flag是remote。注意这里的动态学习是指Spoke节点之间通过NHRP的Resolution Request/Response机制学习到的。3.3 常见的隧道配置问题我在练习中遇到过几次隧道起不来的情况总结下来最常见的三个原因第一个原因是NHRP的network-id不一致。这个参数的作用域是整个MGRE网络一旦有设备的network-id配置错了注册就会失败隧道接口即使UP也无法正常转发数据。第二个原因是隧道源地址不可达。MGRE隧道的源地址可以是物理接口地址、Loopback地址但必须保证各设备之间能够通过这个地址互相访问。很多朋友把源地址配成下行接口的地址导致Spoke到Hub的报文无法到达隧道自然起不来。第三个原因是Spoke节点忘记配置nhrp entry。这个手工映射是Spoke注册的基础漏掉之后Spoke根本不知道向谁注册Hub上也看不到对应的NHRP表项。提示排查MGRE隧道问题时先看NHRP表再看隧道接口状态。多数情况下隧道接口UP却不通业务问题都出在NHRP映射不完整或者组播分发列表没有配置好。4. OSPF在MGRE隧道上的适配与调试4.1 OSPF网络类型的选择隧道接口配好之后接下来就是在隧道接口上运行OSPF。这一步的核心矛盾在于OSPF在默认的隧道接口网络类型是P2MP多点对多点但P2MP网络类型在很多场景下并不能满足需求。MGRE隧道本质上是NBMA非广播多路访问特性而OSPF对NBMA网络的处理需要格外小心。那么问题来了MGRE隧道的OSPF网络类型应该怎么选华为设备的隧道接口默认OSPF网络类型是P2MP。P2MP网络类型的特点是不允许选举DR/BDR邻居关系是自动发现的适合底层链路不具备广播能力的环境。但P2MP模式下OSPF的Hello报文是以组播方式发送的而MGRE隧道的底层是GRE封装GRE本身不具备广播能力所以组播报文在隧道里需要特殊处理。实操中常用两种方案。第一种是把OSPF网络类型改成Broadcast也就是模拟一个广播网络。这种方案最接近以太网的行为能够自动选举DR/BDR并且邻居发现靠组播Hello。但问题是MGRE隧道建立是动态的组播报文需要在所有Spoke之间都能传递这就离不开Hub节点上配置的nhrp entry multicast dynamic。说白了这条命令就是在告诉NHRP凡是注册上来的对端都要加入组播分发列表这样OSPF的组播Hello报文才能通过Hub转发给所有Spoke。第二种方案是把OSPF网络类型改成P2MP同时关闭组播Hello改为手工指定邻居。这种方案在Spoke之间没有直达隧道时也可以工作但配置量上升且邻居关系建立依赖手工配置不利于故障后的自动恢复。我个人在实际练习中更建议使用Broadcast类型。原因很简单HCIP考试中最常考的配置就是Broadcast类型下的DR选举和水平分割问题练熟了之后不仅考试有把握工作里遇到类似场景也能直接套用。4.2 OSPF邻居建立与DR选举问题OSPF网络类型改为Broadcast之后在R1上配置OSPFospf 1 router-id 192.168.0.1 area 0.0.0.0 network 10.1.1.0 0.0.0.255 network 172.16.1.0 0.0.0.255 interface Tunnel0/0/0 ospf network-type broadcast ospf timer hello 10R2的OSPF配置ospf 1 router-id 192.168.0.2 area 0.0.0.0 network 10.1.1.0 0.0.0.255 network 172.16.2.0 0.0.0.255 interface Tunnel0/0/0 ospf network-type broadcast ospf timer hello 10R3的OSPF配置和R2类似网段换成自己的内网。配置完之后在R1上执行display ospf peer正常情况下能够看到R1同时和R2、R3建立了Full状态的邻居关系。要注意的是Broadcast网络类型下会有DR/BDR选举选举结果取决于Router ID的大小。在我的实验环境里R1的Router ID最小它是DRR2和R3是DRother。DR一旦选举出来OSPF的组播Hello和LSA泛洪都要经过DR这也是为什么Hub节点最好成为DR的原因。这里有一个很重要的点在Hub-Spoke场景下最好把Hub节点配置为DR。方法有几种最简单的就是让Hub的Router ID最小。如果Hub不能成为DR那么DR可能在某个Spoke上如果这个Spoke的隧道因为NHRP老化被拆除整个OSPF邻居关系都会受影响。4.3 OSPF水平分割问题的典型表现与解法MGREBroadcast网络类型下最经典的问题是水平分割。RIP协议有水平分割OSPF虽然没有严格意义上的水平分割但NBMA网络里的LSA泛洪本身就存在限制。在Broadcast网络里DR负责将LSA泛洪给所有DRotherDRother之间不直接交换LSA。这个机制在MGRE隧道里会引发一个问题如果Hub是DRSpoke之间的LSA交换必须经过Hub而Hub会把从一个接口收到的LSA再从同一个接口泛洪出去。MGRE隧道接口底层是多点隧道接口本身只有一个这种“从同一接口进、再从同一接口出”的行为在物理环境中通常会被抑制但在MGRE这种逻辑多点网络中如果Hub没有正确配置组播分发列表Spoke之间就无法通过Hub转发组播报文邻居关系就无法建立。解决这个问题的方法正是前面提到的nhrp entry multicast dynamic。有了这条命令Hub节点会把所有注册的Spoke都加入组播分发列表OSPF的组播报文就能从Hub的隧道接口复制发送到每一个Spoke。从我实际操作的经验来看很多人在配置Hub节点时漏掉了这一条导致Spoke之间OSPF邻居一直停留在Init或者Attempt状态花了大把时间在OSPF配置上找问题实际上问题出在NHRP。如果坚持使用P2MP网络类型则需要通过ospf peer命令手工指定邻居并且在Hub节点上同样需要配置组播分发列表或者逐个指定邻居。P2MP模式还有一个问题它不支持DR选举所以LSDB同步完全依赖邻居关系手工指定邻居的数量越多配置维护成本越高。注意在MGRE隧道上运行OSPF不要想当然地按照物理以太网的习惯去配。一定要先确认隧道本身的组播转发能力再决定OSPF的网络类型。两者不匹配OSPF邻居关系永远不可能稳定。4.4 路由互通测试与观察OSPF邻居全部建立之后路由表应该能够正常工作。在R1上执行display ip routing-table可以看到10.1.1.0/24、172.16.1.0/24、172.16.2.0/24、172.16.3.0/24这些路由条目通过OSPF学习到。我练习时会习惯性在每台设备上执行display ospf lsdb查看链路状态数据库的内容。在Broadcast网络里应该能看到路由器对应的Type-1 LSA以及DR产生的Type-2 LSA。如果Type-2 LSA缺失大概率是DR选举出了问题或者组播泛洪不完整。接着可以做连通性测试。在R1上ping R2背后的内网网关地址172.16.2.1以及R3背后的172.16.3.1正常情况下应该全部通。如果R2和R3之间的内网也能互访说明Spoke之间的隧道已经动态建立起来OSPF路由也正确传递了。这里强调一下Spoke之间的隧道是动态建立的也就是说R2如果从来没有和R3通信过那么R2和R3之间可能没有直接的隧道数据包需要绕行Hub。只有当你从R2主动发起流量到R3时NHRP才会触发Resolution流程动态建立R2到R3的直达隧道。这个机制在实际组网中直接影响了带宽利用和时延值得反复体会。5. 实验中的经典故障与排查思路5.1 OSPF邻居无法建立这个排在第一位的故障几乎每个练这个实验的人都遇到过。我在练习群里经常看到有人问“为什么我的OSPF邻居一直是Down”。排查OSPF邻居问题我的顺序是固定的一是看隧道物理层是否UP。如果隧道接口是Down的OSPF配置再多也白搭。二是看NHRP表是否完整。如果Hub上显示NHRP peer缺失OSPF的Hello报文就发不出去。三是看OSPF的网络类型是否两端一致。Broadcast类型和P2MP类型是不能互相建立邻居关系的。四是看区域ID、认证配置是否一致。MGRE隧道里有时会配OSPF认证认证参数不一致同样会导致邻居无法建立。五是看Hello/Dead定时器是否一致。默认情况下Broadcast类型的Hello定时器是10秒P2MP是30秒两个类型下默认值也不同如果手工改过务必保持一致。5.2 路由表出现次优路径有时候OSPF邻居都能建立但路由表里的下一跳指向了Hub而不是直达的Spoke。这是因为OSPF在Broadcast网络类型下路由计算时会以DR作为下一跳如果DR是Hub即使Spoke之间有直达隧道OSPF仍旧会把流量引导到DR。这个现象在P2MP网络类型下不会出现因为P2MP没有DR的概念。解决这个问题的办法一是接受这种次优路径的存在毕竟Hub-Spoke模型下流量经过Hub未必是坏事尤其是需要统一安全策略的场景二是如果要让Spoke之间的流量走直达隧道可以考虑在隧道接口上使用OSPF的P2MP模式并配合路由策略进行调整。但我不建议在这个实验里过度追求Spoke之间的路径优化因为实际项目中Hub往往承担着集中管控的角色流量经过Hub反而便于审计和控制。5.3 NHRP表项频繁老化或丢失这个故障在实际配置中比较隐蔽。NHRP表项有老化时间默认情况下Spoke节点需要周期性地向Hub发送Registration请求来刷新表项。如果Hub上频繁出现Spoke的NHRP表项丢失需要检查两件事一是Spoke节点上nhrp entry ... register命令是否配置了二是周期刷新机制是否正常工作。还有一点容易忽略的是如果在Hub配置了nhrp entry multicast dynamic但某些Spoke的NHRP注册报文中没有正确携带组播标志那么即使表项存在组播泛洪也无法正常工作。遇到这种情况建议把NHRP的调试信息打开配合抓包工具观察Registration报文的交互过程。5.4 隧道接口UP但用户流量不通我遇到过一种情况隧道接口显示UPNHRP表也正常OSPF邻居也Full了但从内网ping对端内网就是不通。排查到最后发现问题是出在隧道接口的MTU上。GRE封装本身会引入24字节的开销加上IP头如果物理接口的MTU是1500隧道数据包容易出现分片问题。解决办法是适当调小隧道接口的MTU或者在物理接口上开启调整MSS的命令。这个坑在真实网络中很容易被忽视而且在HCIP考试中也是一个隐性考点。5.5 故障排查工具清单我在做这个实验时经常用到的排查命令集大概就是下面这一套。把它背下来基本能应对90%的故障场景。在接口层面用display interface Tunnel0/0/0查看隧道接口状态和封装信息用display ip interface brief快速检查所有接口的IP配置。在NHRP层面用display nhrp peer all查看NHRP表项用display nhrp entry all查看NHRP映射。在OSPF层面用display ospf peer查看邻居状态用display ospf lsdb查看链路状态数据库用display ospf interface查看接口的网络类型和定时器参数。另外display ip routing-table protocol ospf可以快速筛选出OSPF路由。6. 从实验到实战的几点体会6.1 理解协议之间的协作比背命令更重要这个实验练到最后我最大的收获不是把命令背熟了而是理解了MGRE和OSPF之间那种互相影响、彼此约束的关系。MGRE的动态隧道机制决定了底层网络的逻辑拓扑形态而OSPF的网络类型选择又必须去适配这种拓扑形态。两者不是独立的而是作为一个整体在协同工作。如果在设计阶段没有想清楚“隧道怎么建、路由怎么传”配置阶段一定会反复返工。6.2 Hub节点的角色定位在Hub-Spoke模型里Hub节点承担着NHRP注册中心、组播分发中心、DR选举中心等多重角色。任何一个角色出了问题整个网络都会受影响。所以我建议在练习时把R1单独拿出来认真研究把Hub的配置彻底吃透再去看Spoke的配置会轻松很多。实际工作中也是这样多分支组网的核心在中心节点中心稳了分支才有保障。6.3 用实验带动理论理解这个实验看起来是配置练习实际上覆盖了IGP协议工作机制、NBMA网络模型、组播转发原理、隧道封装技术等多个知识模块。练完之后再去读教材里关于OSPF网络类型的章节会明显感觉到理解得更透彻了。这是我个人比较推荐的学习路径先通过实验建立现象认知再回头看书补齐理论缺口比单纯啃书本要高效得多。6.4 最后说一个细节做这个实验时我习惯在每完成一步配置之后先保存配置再做验证。eNSP里如果不保存设备重启后所有配置都会丢失重新配置一遍非常浪费时间。另外整个实验过程中建议开着抓包工具观察一下NHRP和OSPF报文的交互过程这会让你对协议的理解提升一个台阶。我第一次看到OSPF的Hello报文在MGRE隧道里被封装成GRE报文、再被NHRP查表转发出去的时候很多之前想不通的问题瞬间就通了。