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 作为总部 Hub，R2、R3 作为两个分支 Spoke，三个站点通过一个模拟公网互联。公网部分只保证路由可达，不做过多配置。

RIP 进程内部声明三台设备的全部直连网段，包括公网接口网段、隧道网段和各自内网网段。注意实际生产环境中公网网段通常不会宣告进内网路由协议，实验为了简化拓扑可以直接宣告，也可以使用静态路由代替，但既然实验核心是“RIP over MGRE”，把全部网段通过 RIP 跑起来更方便观察路由更新行为。

拓扑结构可以简单理解为：R1 通过模拟公网分别连接 R2、R3，R1 是中心节点，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 multipoint

ip 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 Request，Hub 收到后把“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 进入 R1，R1 的路由表学到 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 解封装后把路由表更新，再重新封装并复制给 R3；R3 收到更新后学习到 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 的组播目标是 Hub，R2 会向 Hub 发出解析请求：请告诉我 10.10.10.3 的公网地址。Hub 作为 NHS 查表后返回 Resolution Reply，R2 拿到 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 实验中最常见的三类故障

补充一个很容易被忽略的点：如果实验环境里模拟的公网区域使用了 NAT，MGRE 隧道会变得更加复杂。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 注册没有完全就绪。如果一开始就在模拟器上把所有命令一把梭敲完，出问题后很难分清到底是哪一层掉了链子。把每一层逐级踩实，这个实验的价值才算真正拿到了。