MGRE与RIP实验排错：NHRP注册、水平分割与Spoke互通全解析

做网络实验做到 MGRE 和 RIP 这个组合时绝大多数人都会被两个问题卡住隧道明明起来了Spoke 之间却互 Ping 不通路由协议也配了路由表却一直缺条目。这个实验看似只是“多点 GRE 隧道 动态路由”的组合实际上牵扯到 NHRP 注册、NBMA 网络特性、水平分割、下一跳解析等一连串底层机制。我把这套实验完整跑了几遍把每个节点的配置行为和排错过程都捋了一遍这篇就记录一下完整的配置思路、关键原理和实际操作中容易踩的坑。1. 这个实验解决什么多点分支互访的典型组网需求1.1 为什么要用 MGRE 而不是多条点对点 GRE 隧道先聊一个最容易被忽略的问题实验拓扑为什么要用 MGRE 而不是多条 GRE最常见的分支互联场景是这样总部有一台核心路由器下面挂了十几个分支站点分支之间也要互访。如果走传统的点对点 GRE 隧道总部每接入一个分支就要额外建一条 Tunnel 接口接口数量随分支数线性增长配置量大、管理繁琐。更麻烦的是分支之间的流量如果也要直达就得在分支和分支之间单独拉隧道隧道数量变成 N×(N-1)/2这种方案在分支超过五六个之后基本不可维护。MGRE 的思路完全不同。总部只需要部署一个 multipoint 类型的隧道接口所有分支通过 NHRP 协议动态注册到总部总部维护一张“隧道地址到公网地址”的映射表。分支之间在没有数据流量时不需要维持隧道真正要通信时由 NHRP 动态解析对端公网地址自动产生一条临时直连隧道。这样隧道数量从手动维护变成按需建立逻辑拓扑仍然是 Hub-Spoke但数据平面可以做到 Spoke 之间直接转发。1.2 实验拓扑与地址规划这里的实验拓扑我用三台路由器模拟R1 作为总部 HubR2、R3 作为两个分支 Spoke三个站点通过一个模拟公网互联。公网部分只保证路由可达不做过多配置。设备公网接口地址隧道接口地址内网用户网段R110.1.1.1/2410.10.10.1/24192.168.1.0/24R210.1.1.2/2410.10.10.2/24192.168.2.0/24R310.1.1.3/2410.10.10.3/24192.168.3.0/24RIP 进程内部声明三台设备的全部直连网段包括公网接口网段、隧道网段和各自内网网段。注意实际生产环境中公网网段通常不会宣告进内网路由协议实验为了简化拓扑可以直接宣告也可以使用静态路由代替但既然实验核心是“RIP over MGRE”把全部网段通过 RIP 跑起来更方便观察路由更新行为。拓扑结构可以简单理解为R1 通过模拟公网分别连接 R2、R3R1 是中心节点R2、R3 是分支节点。隧道网段 10.10.10.0/24 是所有站点隧道接口共用的逻辑网段这也是 MGRE 和点对点 GRE 最大的区别之一——多个隧道端点处于同一个逻辑子网中而不是每个链路一个独立子网。后续所有路由协议行为、水平分割、NHRP 解析都围绕这个共享逻辑网段展开。2. 隧道能起来的关键NHRP 协议的工作机制与配置2.1 NHRP 在 MGRE 中的两种角色MGRE 隧道建立依赖 NHRP这是因为 GRE multipoint 隧道没有天然的对端信息。普通 GRE 隧道配置里必须写 tunnel destination明确“隧道要封装的远端口地址”。而 MGRE 的 Hub 端面对几十个 Spoke不可能逐个静态指定 destination所以需要一套动态解析机制这就是 NHRP。NHRP 在组网里承担两种角色Hub 端配置为 NHS也就是 Next Hop Server负责接收分支的注册、维护映射数据库、回应解析请求Spoke 端配置为 NHC启动后主动向 NHS 注册自己的隧道地址与公网地址映射。说得直白一点Hub 端是一本“电话簿”Spoke 端是“打电话去登记自己当前号码的人”。当 Spoke 需要访问另一个 Spoke 的隧道地址时如果本地映射表里没有对应关系就会发起 NHRP Resolution Request。这个请求可以发给 Hub也可以直接发往目标地址Hub 作为 NHS 会基于已知映射表返回 Resolution Reply。Reply 里携带的是目标 Spoke 当前使用的公网地址源 Spoke 拿回这个映射后就具备了对目标 Spoke 直接封装 GRE 数据包的条件。2.2 实际配置命令与注册过程Hub 端 R1 的隧道配置如下interface Tunnel0 ip address 10.10.10.1 255.255.255.255 ip nhrp network-id 100 ip nhrp map multicast dynamic tunnel source 10.1.1.1 tunnel mode gre multipoint几个关键点解释一下。隧道接口地址写 32 位掩码在 Hub 端是常见做法因为多点网络里所有节点共享同一个逻辑子网掩码太大会带来一些不必要的广播开销但实验环境写 24 位也能跑通重点在于各个 Spoke 都能把 10.10.10.x 解析到同一逻辑子网。ip nhrp map multicast dynamic这一条非常关键。RIP 更新是广播或组播报文而 MGRE 隧道本身不支持天然的广播复制。Hub 需要把组播报文复制给所有已注册 Spoke就必须动态维护一张组播目标列表dynamic 关键字表示“组播复制列表从 NHRP 动态注册信息里学习”。没有这条配置广播类型路由协议很难在多点隧道上正常工作。Spoke 端 R2 的配置如下interface Tunnel0 ip address 10.10.10.2 255.255.255.0 ip nhrp network-id 100 ip nhrp map 10.10.10.1 10.1.1.1 ip nhrp map multicast 10.1.1.1 ip nhrp nhs 10.10.10.1 tunnel source 10.1.1.2 tunnel mode gre multipointip nhrp map 10.10.10.1 10.1.1.1表示手动指定 Hub 隧道地址对应的公网地址因为 Spoke 在注册前不可能动态知道 Hub 的公网入口这是“种子映射”。ip nhrp map multicast 10.1.1.1表示本接口发出的组播流量封装后发给 10.1.1.1也就是发给 Hub这样 Spoke 发出的 RIP 更新会先到达 Hub再由 Hub 复制给其他 Spoke。ip nhrp nhs 10.10.10.1明确注册目标。Spoke 启动后会自动向该地址发送 NHRP Registration RequestHub 收到后把“10.10.10.2 对应 10.1.1.2”写入映射表。注册过程可以通过show ip nhrp查看正常时 Hub 上能看到两个 Spoke 的动态映射条目。2.3 注册不成功时的排查思路注册不成功是这个实验最常遇到的问题我排查过几次之后总结出一个固定检查顺序。先在 Spoke 上用show ip nhrp看本地映射表确认是否已经学习到 Hub 的映射。如果显示 “no entries”说明 Spoke 根本没有发出注册请求或者请求发出后没收到回应。接着检查ip nhrp network-id是否一致这个编号只在本隧道接口本地有效但不同节点必须配置相同值否则协议报文会被忽略。再检查 Hub 地址映射是否正确ip nhrp map 10.10.10.1 10.1.1.1这里的公网地址必须是 Hub 真实出接口地址而且 Hub 上tunnel source 10.1.1.1与映射的地址必须对应。还要提醒一点模拟器和真机对tunnel destination的处理不同。部分模拟器环境里 Spoke 的 Tunnel 接口即使配置了tunnel mode gre multipoint如果完全没有 destination 信息某些实现下接口可能处于 up/up 但无法封装数据。稳妥的做法是在 Spoke 的隧道接口额外指定tunnel destination 10.1.1.1这样 Spoke 与 Hub 之间的基础 GRE 封装始终可用NHRP 注册报文也能正常送达。生产环境通常不写这个 destination完全依赖 NHRP 动态解析但实验阶段写上能减少很多无谓的排错。3. RIP 在 NBMA 隧道上常见的坑水平分割与广播限制3.1 为什么 Spoke 之间拿不到彼此路由隧道建立之后就该让 RIP 跑起来了。在很多初学配置里RIP 只需要在每台设备的 Tunnel 和物理接口上启用进程再宣告相应网段看起来很简单。但真正敲完之后会发现一个非常典型的现象R2 能看到 192.168.1.0/24 也就是 HQ 的内网路由R3 也能看到 192.168.1.0/24但 R2 和 R3 互相看不到对方的内网网段。问题出在 RIP 的水平分割规则和 Tunnel 接口的拓扑特性上。RIP 的水平分割规定从某个接口学习到的路由不会再从这个接口通告出去。这种机制在普通以太网多路访问环境里很有意义能防止两台路由器之间相互传递从对方学来的路由避免路由环路。问题在于 Hub 的 Tunnel0 是唯一一个逻辑接口但在数据平面却对应多个 Spoke。R2 发来的路由更新从 Tunnel0 进入 R1R1 的路由表学到 192.168.2.0/24下一跳指向 10.10.10.2。当 R1 想把这条路由通告给 R3 时按照水平分割规则它不能从学习到该路由的接口 Tunnel0 再通告出去。R1 确实是从 Tunnel0 学到的所以 R3 就永远收不到 192.168.2.0/24 这条路由。这跟物理多路访问网络的区别在于在以太网交换机环境下一台路由器连接多台邻居是通过不同物理接口或不同 VLAN 子接口水平分割不会误伤而在 MGRE 环境中所有邻居共享同一个逻辑隧道接口水平分割就把所有从邻居学来的路由都拦了下来。3.2 解决方案关闭隧道接口的水平分割解决办法很简单在 Hub 的隧道接口下关闭水平分割interface Tunnel0 no ip split-horizon这个命令在 RIP 进程对应的接口下直接生效。no ip split-horizon关闭后R1 从 Tunnel0 学到的所有路由仍然可以通过 Tunnel0 通告给其他 Spoke。由于 Tunnel0 是 NBMA 接口R1 会把路由更新封装成 GRE 数据包分别发往 R2 和 R3本质上是通过点对点复制实现的“逻辑广播”。关闭水平分割会不会导致环路在纯 Hub-Spoke 拓扑下不会因为只有 Hub 一个中心节点Spoke 之间没有直接相互通告 RIP 更新的必要。如果组网从单 Hub 变成多 Hub甚至 Spoke 之间再互相连接形成更复杂的偏互网络关闭水平分割就需要更谨慎地结合路由过滤、反向水平分割等手段控制实验阶段可以先不深究。3.3 RIP 更新包在 MGRE 链路中的转发特性RIP 更新默认是广播发送的少量实现会使用组播地址。广播报文进入 MGRE 隧道后需要在 Hub 端被复制成多份点对点 GRE 报文分别发往每个已知 Spoke。这个复制机制依赖配置在 R1 上的ip nhrp map multicast dynamic它决定了“把广播复制给谁”。Spoke 端没有动态组播映射配置的是ip nhrp map multicast 10.1.1.1这表示把组播流量定向发送给 Hub。于是 RIP 更新在网络里的传播路径是R2 广播更新到 Tunnel0封装后发给 R1 的公网地址R1 解封装后把路由表更新再重新封装并复制给 R3R3 收到更新后学习到 R2 内网路由。整个过程并不存在真正的广播只是 Hub 做了依次复制。这也是我建议实验时在 Hub 端show ip nhrp确认两个 Spoke 都已经注册的原因。如果某个 Spoke 没有完成 NHRP 注册Hub 的组播复制列表里就不会包含它RIP 更新自然也不会到达这个 Spoke即使它物理上能 Ping 通 Hub。很多“有路由但部分站点缺路由”的问题本质上不是路由协议配置错而是 NHRP 注册不完整导致广播复制目标缺失。4. Spoke 到 Spoke 数据流的最终形态与 NHRP 动态解析4.1 数据平面两条路径对比路由学齐之后R2 的内网设备要访问 R3 的内网设备数据包默认怎么走这取决于 R2 本地是否有到 10.10.10.3 的 NHRP 映射。第一种情况没有映射R2 将数据报文封装进 GRE 隧道时需要在本地查找目的隧道地址 10.10.10.3 对应的公网地址查不到映射就无法封装此时数据报文会交给默认的“解析机制”处理。R2 上配置了ip nhrp nhs 10.10.10.1同时还有静态映射ip nhrp map 10.10.10.1 10.1.1.1没有现成映射时最直接的兜底方式是把报文先发往 Hub。Hub 解封装后看到内层目的隧道地址是 10.10.10.3查询自己的 NHRP 表找到 10.10.10.3 对应 10.1.1.3再重新封装转给 R3。这就是典型的经 Hub 中转转发。第二种情况R2 已经学习到了 10.10.10.3 到 10.1.1.3 的 NHRP 映射R2 直接以 10.1.1.3 为外层目的地址封装 GRE 报文R3 收到后解封装数据包的转发路径就是从 R2 到 R3 直连不再经过 Hub。这是 MGRE 相对普通 Hub-Spoke 结构的核心优势——控制平面仍由 Hub 统一管理数据平面却能按需优化。4.2 让数据流量动态触发 Spoke 间直连隧道那 Spoke 之间第一次通信时那个直连映射是怎么建立的这是整个实验里最有意思的过程。当 R2 第一次向 10.10.10.3 发送数据时R2 的 NHRP 缓存里没有对应表项。NHRP 会触发一个 Resolution Request这个请求可以是广播到组播映射列表里的所有 Spoke也可以定向发给 NHS。实验配置里 R2 的组播目标是 HubR2 会向 Hub 发出解析请求请告诉我 10.10.10.3 的公网地址。Hub 作为 NHS 查表后返回 Resolution ReplyR2 拿到 10.1.1.3建立动态 NHRP 映射随后的数据包就直接封装发往 R3。要注意的是这个动态映射有生命周期NHRP 老化时间默认为 7200 秒左右实验过程中如果长时间没有流量映射会过期删除。再次通信时又会重复解析过程但首包已经能通过 Hub 中转兜底所以对应用的影响通常只有第一个包会稍慢或者触发一次 OSPF 邻居重建之类的震荡并不至于断流。如果希望首包就能直连可以在 R2 和 R3 上手动添加彼此的公网地址映射但这种做法违背了 MGRE 动态实现的初衷几十个分支之间两两手动添加映射同样不现实。所以在实际组网中我更倾向于接受“首包经 Hub后续包直连”的行为或者通过配置 NHRP 重定向机制让 Hub 在转发过程中主动提示 Spoke 改进直连路径。4.3 多分支场景下的路由与映射表维护路由表和 NHRP 映射表是两套不同维度的表项这个一定要分清楚。RIP 路由表告诉 R2“去 192.168.3.0/24 的下一跳是 10.10.10.3”解决的是逻辑路由问题NHRP 映射表告诉 R2“封装数据包发送给 10.10.10.3 时外层 GRE 头应该用 10.1.1.3 作为目的地址”解决的是物理封装问题。两层表项必须同时正确Spoke 间数据流才能真正建立。在实验拓扑里只有两个 Spoke手动排查相对容易。一旦分支数量上升到几十个Hub 上的 NHRP 表项和 RIP 路由条目都会显著增加。建议实验完成后重点观察 Hub 上的show ip nhrp输出确认动态映射全部来自各 Spoke 的注册信息而不是杂乱的手动映射。如果看到大量非预期的映射条目优先检查是否有 Spoke 配置了重复的公网地址或隧道地址这也是 NHRP 层面最常见的地址冲突问题。5. 验证命令解读与常见故障对照5.1 关键验证命令的实际输出怎么读实验做完后不要急于收工花几分钟把下面几条命令的输出逐行读一遍对这个实验的理解会完全不同。show ip nhrp是最该先看的。在 Hub 上执行后正常会看到类似下面这样的信息10.10.10.2/32 via 10.10.10.2 Tunnel0 created 00:12:34, expire 01:47:26 Type: dynamic, Flags: authoritative unique registered NBMA address: 10.1.1.2 10.10.10.3/32 via 10.10.10.3 Tunnel0 created 00:10:02, expire 01:49:58 Type: dynamic, Flags: authoritative unique registered NBMA address: 10.1.1.3每一行代表一个远端隧道端点的映射关系。Type 是 dynamic 说明这条映射是通过 NHRP 注册动态建立NBMA address 是公网封装地址。flags 里的 registered 字段非常关键它表明 Spoke 主动向 Hub 注册过而不是仅仅被解析过。如果有些 Spoke 只有 learned 而没有 registered说明 Spoke 侧注册配置有问题。show ip route rip在 R2 和 R3 上执行确认对端内网路由是否为 RIP 学习而来并记录路由的 metric。默认情况下 R2 从 Hub 学到 192.168.3.0/24度量值可能是 2 或 3取决于 Hub 通告时递增的次数。如果 Spoke 之间期望直连通信路由协议通告时必须保证下一跳是目标 Spoke 的隧道地址而不是 Hub 的隧道地址否则数据流仍然会先绕到 Hub。debug nhrp适合排查映射建立过程。这个命令会输出 NHRP 注册请求、解析请求、响应等详细信息观察一次 Spoke 间首次通信时触发解析的过程比单纯看静态输出直观得多。不过 debug 输出量较大实验完成验证后务必关闭否则控制台日志会被刷屏。5.2 实验中最常见的三类故障故障现象根因定位处理方式Spoke 能 Ping 通 Hub 逻辑地址但 RIP 查询不到任何远端路由Hub 未配置ip nhrp map multicast dynamic广播更新无法复制到所有 SpokeHub 隧道接口补上该命令并确认 Spoke 已注册成功Spoke 之间从路由表看得到对端内网路由但 Ping 不通对端内网地址NHRP 映射缺失数据包无法封装检查 Spoke 是否发起 NHRP 解析确认 Hub 的 NHS 功能正常RIP 路由只有直连网段Spoke 学不到任何远端路由Spoke 的 RIP 更新没有送达 Hub或水平分割导致更新被抑制检查 Spoke 的组播映射配置并在 Hub 隧道接口关闭水平分割补充一个很容易被忽略的点如果实验环境里模拟的公网区域使用了 NATMGRE 隧道会变得更加复杂。NHRP 注册的 NBMA 地址如果经过 NAT 转换Hub 记录的可能是转换后的地址Spoke 之间解析出来的也是转换后地址此时 GRE over IP 的直接封装可能因为 NAT 映射不合规而失败。这已经超出基础实验范围但脑子里要有这根弦生产环境排错时遇到类似现象先朝 NAT 方向想。另外RIP 的更新定时器默认 30 秒在 MGRE 环境下因为广播复制和多点封装路由收敛时间会比普通以太网链路稍微长一点。实验过程中看到路由没有立刻出现很正常等 30 秒到 60 秒左右再观察。不要因为着急就去改定时器实验环境下默认参数能更真实地反映协议行为。最后再分享一个我实际操作中的体会做这类“隧道 动态路由”实验配置顺序很重要。先把公网互通验证好再开启 MGRE用ping 10.10.10.x确认各隧道端点逻辑可达最后才启 RIP。RIP 边界不清晰时往往不是 RIP 本身配错而是底层隧道和 NHRP 注册没有完全就绪。如果一开始就在模拟器上把所有命令一把梭敲完出问题后很难分清到底是哪一层掉了链子。把每一层逐级踩实这个实验的价值才算真正拿到了。