最近被一个网络改造项目逼着把IPv6过渡技术重新过了一遍两个站点内部已经跑起了IPv6业务骨干网络却还是纯IPv4客户要求在不动骨干的前提下让两边的IPv6网段彻底打通。我最后选了GRE隧道做承载在隧道上叠加OSPFv3和BGP4让路由自动学习整套东西用华为设备在模拟环境里完整跑了一遍。这个组合听上去不算难真正敲命令的时候才发现细节很多尤其是MTU和BGP的IPv6族这两个地方稍不注意就会原地卡住。这篇文章就是这套IPv6 GRE隧道加路由协议综合实验的完整记录适合正在备考华为认证、做IPv6过渡改造或者单纯对隧道技术感兴趣的网工朋友参考。1. 这个实验要解决的现实问题IPv6孤岛之间为何要挖一条GRE隧洞1.1 先看场景IPv6业务都跑起来了骨干却还是IPv4很多单位目前就是这种状态新建的机房、办公网、业务系统已经支持IPv6甚至已经单独分配了IPv6网段但连接各站点的骨干链路还是多年前建的IPv4网络运营商侧也没完全铺开IPv6。于是两个能正常访问IPv6互联网的“孤岛”互相之间反而连不通业务系统要跨站点调用时只能退回IPv4或者走各种别扭的绕行方案。我这次模拟的就是最典型的两个孤岛互联场景站点A有IPv6业务网段站点B也有IPv6业务网段中间隔着一台纯IPv4转发的骨干路由器。最终目标是让A能直接访问B的IPv6网段且两边路由完全动态学习不能靠人工一直敲静态路由。1.2 过渡技术的三条路双栈、隧道、翻译为什么这里选隧道IPv4到IPv6的过渡方案大体分三类双栈、隧道、翻译。双栈最理想所有设备同时跑IPv4和IPv6但这需要整条链路都支持骨干改造周期长、成本高客户明显不想等翻译方案也就是NAT64这类适合IPv6终端访问IPv4服务器的场景但两个IPv6站点之间互联用翻译反而绕了远路。剩下最实用的就是隧道把IPv6报文封装进IPv4报文里借用现成IPv4骨干搬运IPv6数据。隧道本身也分很多种除了GRE还有6to4、ISATAP、6in4等。GRE属于“显式配置的点到点隧道”你明确告诉设备隧道起点在哪、终点在哪它就在这两点之间挖一条逻辑直连链路。这个特点让它和动态路由协议的配合非常自然。1.3 GRE隧道与6to4、ISATAP的关键差别6to4和ISATAP更多是自动隧道设备根据IPv4地址自动计算出IPv6前缀和隧道关系适合早期过渡、公网地址相对宽松的场景。但它们大多数情况下只能承载单播IPv6报文想在上面跑依赖组播的路由协议非常费劲。GRE不一样。GRE封装本身不关心内层是什么协议IPv6单播、组播它都照单全收。OSPFv3建立邻居和泛洪LSA用的是组播GRE隧道恰恰能把组播报文也封装进IPv4包里运过去所以OSPFv3这种“挑链路”的路由协议在GRE上跑得很稳。这个差别就是我在这个实验里不用6to4、坚持用GRE的核心原因。2. 拓扑、地址规划与几个容易被忽略的设计决策2.1 拓扑长什么样实验拓扑是典型的三台路由器串成一串[IPv6站点A] [IPv6站点B] | | R1 ---- IPv4骨干 ---- R2 ---- R3R1代表站点A的出口路由器下挂Loopback0模拟IPv6业务网段R3代表站点B的出口路由器同样下挂Loopback0模拟业务网段R2是中间的IPv4骨干路由器只配置IPv4负责转发GRE封装后的流量。R1和R3之间通过GRE隧道建立一条逻辑上的IPv6直连链路。R1、R2、R3之间的物理接口地址全用IPv4这是为了模拟“骨干还是IPv4”的真实环境而R1和R3上的业务网段、隧道接口地址全用IPv6。2.2 地址规划表设备接口IPv4地址IPv6地址用途R1GE0/0/0192.168.12.1/24-连接骨干R2R1Loopback0-2001:db8:10::1/64模拟站点A IPv6业务网段R1Tunnel0/0/1-2001:db8:12::1/64通往R3的GRE隧道R2GE0/0/0192.168.12.2/24-纯IPv4骨干R2GE0/0/1192.168.23.2/24-纯IPv4骨干R3GE0/0/0192.168.23.3/24-连接骨干R2R3Loopback0-2001:db8:30::3/64模拟站点B IPv6业务网段R3Tunnel0/0/1-2001:db8:12::2/64通往R1的GRE隧道隧道地址我单独规划了2001:db8:12::/64这个网段和业务网段彻底分开。别小看这个习惯后续跑OSPFv3、BGP4、排障时地址段一眼就能分清哪个是隧道链路、哪个是业务网段比全挤在一个地址池里舒服得多。2.3 设计决策为什么源用物理接口IP、地址要单独划分GRE隧道在外层IPv4头里需要源地址和目的地址。华为VRP的Tunnel接口配置里source可以填接口名也可以填IPdestination只能填IP。我这次直接用物理接口的IPv4地址作为隧道源这样最直观排障时一眼能看到封装起点如果以后骨干里还有可路由的Loopback地址把隧道源改成Loopback会更稳物理接口断了也不影响隧道状态。另外两个决策值得多说一句一是R2完全不参与IPv6它只按IPv4路由转发GRE封装后的包这对模型很有意义说明GRE隧道方案可以在不改骨干设备的前提下完成IPv6打通二是业务网段用Loopback模拟好处是接口永远up排除了物理链路抖动对实验的干扰你可以把精力完全放在协议调试上。3. VRP命令行逐条拆解GRE隧道本身怎么搭才能稳3.1 两个关键前提接口启用IPv6与GRE封装参数华为设备上创建Tunnel接口后默认协议就是GRE但显式写出来更稳也方便后来人看配置。真正容易漏的是两个点一是接口下要敲ipv6 enable否则Tunnel接口根本没有IPv6能力后续配IPv6地址、起OSPFv3都会报错二是source和destination必须互为镜像R1的source要对应R3的destinationR3的source要对应R1的destination只要有一个方向配错隧道就是单向通的。3.2 R1和R3的核心配置R1的GRE隧道配置interface Tunnel0/0/1 tunnel-protocol gre source 192.168.12.1 destination 192.168.23.3 ipv6 enable ipv6 address 2001:db8:12::1/64R3的GRE隧道配置interface Tunnel0/0/1 tunnel-protocol gre source 192.168.23.3 destination 192.168.12.1 ipv6 enable ipv6 address 2001:db8:12::2/64注意R1的destination填的是192.168.23.3这是R3连接骨干的物理接口地址不能填成R3的隧道IPv6地址。GRE外层封装是IPv4的源目地址必须都是IPv4地址。同样R3的destination填的是192.168.12.1。两边的Tunnel接口编号不要求一致左边叫Tunnel0/0/1右边叫Tunnel0/0/1只是巧合不同编号不影响通信。3.3 验证隧道是否真的通了配置完先看的不是路由协议而是隧道本身display tunnel-info all display ip interface brief display ipv6 interface Tunnel0/0/1display tunnel-info all能看到隧道协议是GRE、源地址、目的地址display ip interface brief确认Tunnel0/0/1状态是updisplay ipv6 interface Tunnel0/0/1能看到接口自动生成的链路本地地址和手工配置的全局地址。隧道地址通不通用ping验证ping ipv6 2001:db8:12::2 -a 2001:db8:12::1这里-a指定源IPv6地址必须写隧道接口自己的地址不要偷懒省略否则走的可能是别的IPv6出口。3.4 踩坑提醒GRE隧道不会自动“握手成功”GRE隧道默认没有握手机制不像BGP那样有个明显的状态机。你看到Tunnel接口up只代表本端配置存在、源地址对应的物理接口up并不代表对端一定可达。隧道真正可用必须建立在“IPv4路由双向可达”和“两端配置镜像”之上。实验里最容易犯的错有三个一是忘了ipv6 enable结果去配IPv6地址时报错二是destination填成了对端Tunnel接口的IPv6地址外层封装直接失败三是只配了一端另一端没建Tunnel接口ping隧道地址当然不通。这些坑都不难理解但实操时非常容易混我建议每次改完配置都先跑一遍display tunnel-info all确认源目和协议都正常再往下走。4. 隧道上跑OSPFv3路由自动学习与MTU这个隐形杀手4.1 为什么一定是OSPFv3而不是OSPFv2OSPFv2只支持IPv4所以IPv6隧道上必须用OSPFv3。OSPFv3的协议号、报文结构都是为IPv6设计的邻居之间通过链路本地地址通信组播地址用的是FF02::5和FF02::6。关键点在于OSPFv3同样依赖组播而GRE隧道恰恰能承载组播IPv6报文所以在GRE上跑OSPFv3是合理且稳定的组合。华为VRP默认把GRE Tunnel接口当作点到点链路处理OSPFv3邻居建立时不需要选举DR/BDR配置简单邻居起来也快。如果你以前在思科设备上做过类似实验这个模型应该很熟悉。4.2 OSPFv3配置Router-ID与接口宣告OSPFv3进程的Router-ID仍然是一个32位的数字实验设备上有IPv4地址会自动取接口地址当Router-ID但我还是建议手动指定避免以后加接口导致Router-ID变化。配置如下R1ospfv3 1 router-id 1.1.1.1 interface Loopback0 ospfv3 1 area 0 interface Tunnel0/0/1 ospfv3 1 area 0R3ospfv3 1 router-id 3.3.3.3 interface Loopback0 ospfv3 1 area 0 interface Tunnel0/0/1 ospfv3 1 area 0这里有个很容易漏的操作业务网段接口Loopback0也要宣告进OSPFv3。很多人只把隧道接口加进区域结果邻居起来了、路由表里只有隧道直连路由业务网段始终学不到最后绕一大圈才发现是Loopback没宣告。业务接口宣告后R1的路由表里应该能看到2001:db8:30::/64R3能看到2001:db8:10::/64。4.3 邻居状态、路由表验证OSPFv3的验证命令和OSPFv2很像display ospfv3 peer display ospfv3 routing display ipv6 routing-table protocol ospfv3正常情况下邻居状态是Fulldisplay ospfv3 routing能看到对端业务网段display ipv6 routing-table里对应条目带有OSPFv3标志。然后从R1用业务网段地址ping对端业务地址ping ipv6 2001:db8:30::3 -a 2001:db8:10::1能通就说明GRE隧道OSPFv3这条路已经完整跑通了。4.4 MTU问题ExStart反复横跳的根因与解法这个坑我几乎每次都踩值得单独拎出来讲。GRE隧道建立后接口MTU直接影响OSPFv3邻居建立。OSPFv3在ExStart阶段交换DD报文DD报文不能分片如果接口MTU不一致或封装后总长度超过物理链路MTUDD报文就会在传输中丢失结果邻居状态在ExStart和Init之间反复跳看起来“快好了但永远起不来”。解决办法是把两端Tunnel接口的MTU统一调小。我一般习惯设为1400interface Tunnel0/0/1 mtu 1400注意两端都要设且数值保持一致。这样GRE封装后外层IPv4头加GRE头大概有24到32字节的额外开销1400的净荷加上开销不会超过物理口的1500DD报文也能完整送达。改完MTU后重置OSPFv3进程或者等邻居超时重建状态很快就到Full。顺便说一句华为VRP在某些Tunnel接口配置里还提供MTU忽略选项比如OSPF接口下的mtu-ignore之类。实验里你可以开这个选项跳过MTU检查但生产环境我强烈不建议因为这不是解决问题只是掩盖问题大报文照样会被黑洞。4.5 给GRE隧道加keepalive状态更真实GRE不像BGP或OSPF有周期性报文维护邻居状态要是对端设备掉电了本端Tunnel接口可能还是up静态路由或下一跳就会一直往一个黑洞里丢。华为VRP的Tunnel接口支持配置keepalive发送探测报文检测对端可用性。不同VRP版本命令措辞略有差异但基本都是在Tunnel接口下配置keepalive参数。实验里如果你希望隧道状态能真实反映对端是否可达加一个keepalive是个好习惯生产环境尤其是配合静态路由收尾时这个探测作用很大。5. 叠加BGP4跨AS站点间的IPv6路由交换5.1 既然OSPFv3已经通了为什么还要BGP4OSPFv3把路由学到后站点A和站点B已经能互通理论上实验可以结束了。但实际组网里跨站点互联往往涉及不同自治域需要BGP来控制路由策略、前缀数量、选路等。BGP4就是BGP的IPv6扩展也叫MP-BGP通过Update消息携带IPv6前缀是IPv6网络中跨AS路由交换的标准手段。这个实验里我把R1归到AS 100R3归到AS 200建立EBGP IPv6对等体各自通过network命令宣告自己的业务网段这样两个站点不仅通过OSPFv3能互通还能通过BGP学到一个带AS路径的冗余路由便于以后做策略控制。5.2 BGP4配置最容易漏掉的是“在IPv6族里激活对等体”BGP配置最大的坑就在这儿。华为设备默认的BGP视图里对等体关系是给IPv4单播用的你只写peer 2001:db8:12::2 as-number 200对等体根本不会起来因为BGP4的会话属于IPv6地址族。必须进入ipv6-family unicast视图把对等体enable一次。R1的BGP配置bgp 100 router-id 1.1.1.1 peer 2001:db8:12::2 as-number 200 ipv6-family unicast peer 2001:db8:12::2 enable network 2001:db8:10::0 64R3的BGP配置bgp 200 router-id 3.3.3.3 peer 2001:db8:12::1 as-number 100 ipv6-family unicast peer 2001:db8:12::1 enable network 2001:db8:30::0 64network 2001:db8:10::0 64在IPv6族里宣告的是业务网段前提是路由表里已经有这条路由否则BGP不会凭空产生它。这里路由表里的条目来自OSPFv3或直连所以顺序应该是OSPFv3先跑通再叠BGP别反着来。5.3 验证BGP邻居和路由前缀验证命令display bgp ipv6 unicast peer display bgp ipv6 unicast routing-table邻居状态显示EstablishedR1的BGP路由表里能看到对端宣告的2001:db8:30::0/64下一跳是2001:db8:12::2。如果路由表和OSPFv3同时存在两条相同前缀注意比较优先级实验环境无所谓生产环境要考虑路由引入和回灌策略。实际效果验证ping ipv6 2001:db8:30::3 -a 2001:db8:10::1通说明BGP4路径也完全可用。5.4 排错速查BGP邻居起不来先看这几项现象常见原因处理邻居一直Idle没有在ipv6-family unicast下enable对等体进入对应地址族执行peer enable邻居Active打转对端AS号配置不一致核对两边的as-number邻居Established但路由为空network宣告的前缀不在路由表先确认OSPFv3/直连路由再宣告邻居Established但业务不通路由策略或出口过滤检查对端是否宣告了业务网段双向确认6. 组合排错实战从“邻居起不来”到“全网路由通”这一章写的是我在这套实验里真实踩过、也帮身边人排过的一串故障完整还原当时是怎么一步步查下去的。6.1 故障一OSPFv3邻居卡在ExStart小包却全通现象很诡异GRE隧道起来后ping隧道对端IPv6地址是通的但display ospfv3 peer一直显示邻居在ExStart偶尔跳到Init就是不进Full。排查链路我走了一遍先看隧道display tunnel-info all隧道up源目正确。再测隧道内IPv6单播ping ipv6 2001:db8:12::2 -a 2001:db8:12::1 -c 20全部通。看OSPFv3报文交互在PC上做镜像抓包发现内层OSPFv3的DD报文反复发送对端没有回应或者回应了但本端丢弃。想到MTU。查两端隧道接口MTU一边默认1500另一边也是1500看似一致但GRE封装后总长度超过物理接口1500DD报文在物理口被分片或丢弃。两端统一mtu 1400后邻居状态几秒内进入Full。这个案例说明隧道接口up、小包能通不代表协议报文能通。OSPFv3的DD报文大又不可分片MTU稍有不适立刻卡在ExStart。所以做IPv6 over GRE实验我现在的习惯是先统一隧道MTU再配路由协议能省一晚上排障时间。6.2 故障二BGP邻居一直Idle毛病在IPv6族激活GRE和OSPFv3全通业务也能互相ping但BGP邻居死活起不来状态一直是Idle。刚开始以为是隧道问题反复查隧道状态后来静下心看了BGP配置才发现只写了peer 2001:db8:12::2 as-number 200完全没进ipv6-family unicast视图。BGP4对等体必须在IPv6地址族里激活这一步不写设备永远不会用IPv6建立TCP 179端口会话。补上激活命令后邻居从Idle变成Active再变Established整个过程不到一秒钟。这个问题很典型尤其对从IPv4 BGP转过来的人习惯了只配置BGP视图一转到IPv6就漏掉地址族这一步。6.3 故障三路由表好看业务流量却回不来还有一次是R1的BGP路由表里已经有2001:db8:30::0/64了ping业务地址仍然不通。抓包发现请求包到达了R3但R3没有回包。查R3的路由表发现2001:db8:10::0/64并不存在。原因是R3的Loopback0在OSPFv3里宣告没问题但BGP的network宣告没做或者R3上没有这条前缀的直连路由导致network命令无效。IPv6网络里回包路由和IPv4一样关键甚至更容易漏因为地址族概念多了一层。加上宣告后回包路径通了再ping就正常。6.4 一张表说清实验里常见的五个坑现象优先检查点根因与处理Tunnel接口up隧道IPv6 Ping不通source/destination镜像检查两端封装参数不一致改为互为镜像OSPFv3邻居ExStart反复隧道接口MTU两端统一MTU建议1400OSPFv3邻居Full但业务网段不可达业务接口OSPFv3宣告Loopback接口加入对应区域BGP邻居Idleipv6-family unicast配置执行peer enableBGP路由有业务Ping不通对端是否宣告了反向前缀双向业务网段都必须进入路由表7. 实验复盘GRE隧道的适用边界与下一步扩展方向7.1 综合实验做完后你能带走什么这套实验做完你基本掌握了三条硬技能一是GRE隧道在华为VRP上的完整配置与验证方法二是OSPFv3在点到点隧道链路上的运行特点与MTU排障思路三是BGP4跨AS宣告IPv6前缀的完整流程。这三条正好覆盖IPv6过渡场景里隧道承载加动态路由的核心组合。从更宏观的角度看你应该能理解为什么GRE隧道在过渡方案里仍然有一席之地它不依赖运营商、不改造骨干只要两端设备支持就能在IPv4网络上拉通IPv6配合OSPFv3和BGP4还能做到全动态路由。对小规模站点互联、临时链路、实验环境来说成本低、见效快。7.2 GRE隧道的边界哪些场景该换方案GRE隧道并不完美。它是手工配置的站点增多后隧道数量呈线性膨胀运维压力大它没有原生加密能力裸跑GRE等于明文传输涉密或不安全的链路需要叠加IPsecGRE协议本身对NAT不友好协议号47在很多NAT设备上不被识别跨运营商NAT场景容易出问题MTU问题也需要全程关注自动调节机制不够智能。如果业务规模大、对安全或自动化要求高可以考虑更现代的方案数据中心内部或大型园区用VXLAN做隧道承载骨干网有条件时考虑SRv6安全要求高的链路用IPsec或GRE over IPsec。但无论换哪种GRE隧道作为理解“隧道路由协议”的基础模型仍然值得每一个网工亲手做一遍。7.3 三个扩展玩法静态路由兜底、多区域OSPFv3、隧道QoS实验做完别急着拆我建议再补三个练习。第一个是静态路由兜底在R1上写一条指向Tunnel接口的IPv6静态路由比如ipv6 route-static 2001:db8:30::0 64 Tunnel0/0/1然后和OSPFv3动态路由并存观察路由优先级和路由表选路结果。这能帮你理解动态路由不可用时静态路由如何兜底。第二个是多区域OSPFv3改造把R1的Loopback0放进Area 1隧道接口放进Area 0让R1既当ABR又当ASBR观察区域间路由泛洪和路由汇总对OSPFv3的骨干区域概念会有更直观的体会。第三个是隧道QoS在Tunnel接口上配置简单队列策略给IPv6语音或视频流量单独标记再制造一点背景流量看看GRE封装后的内层优先级是否能被外层IPv4头继承。这个练习对以后做跨站点视频会议很有用。实验做完最大的体会是IPv6隧道实验的排错顺序非常关键。隧道本身、单播可达、路由协议、业务验证每一步都必须确认无误再进入下一步别指望一次配完直接全通。MTU问题会在你完全没防备的时候冒出来而BGP的IPv6族激活则是从IPv4习惯转过来的人最容易漏的一环。如果你接下来也要做类似改造先把拓扑和地址规划画清楚再动手敲命令能少走一大半弯路。