前阵子为了把IPv6过渡技术里最容易绕晕的部分——GRE隧道、OSPFv3、RIPng——串成一条完整链路我在模拟器上搭了一个基于华为设备的综合实验。拓扑不算大但折腾下来把不少零散的坑都补齐了比如隧道口为什么长时间UP不起来、OSPFv3为什么非要手动写Router-ID、RIPng在隧道上出现“路由表有但ping不通”该怎么收场。今天把整套配置过程和排错思路整理出来给正在啃IPv6路由实验的同学做一份能直接抄作业的参考。1. 实验场景设计与地址规划1.1 拓扑设计与这套方案要解决什么问题先说清楚这套实验的背景。现在组网里IPv4不会立刻消失IPv6业务也不可能推倒重来于是过渡技术里GRE隧道就是很务实的一招在现有IPv4骨干上叠一条虚拟的IPv6链路让IPv6路由协议能跑起来。这个实验我把它做成一段“由浅入深”的综合链路R1模拟一个只有IPv4出口的IPv6孤岛通过GRE隧道连接到R3R2是中间双栈骨干节点既转发IPv4报文又作为IPv6原生网络的一侧R3同时作为两条隧道的汇聚点一条隧道跑OSPFv3另一条跑RIPng。这样设计的好处是三个设备就能覆盖两类典型的GRE封装场景一类是IPv6载荷封装进IPv4外层即最常见的IPv6 over IPv4 GRE另一类是IPv6载荷封装进IPv6外层即IPv6 over IPv6 GRE。两条隧道并行存在既方便对比又能检验路由协议在不同隧道上的行为差异。物理连接上R1和R2之间只是纯IPv4链路R2和R3之间做成双栈链路。R1没有原生IPv6接口这意味着R1的IPv6业务必须依赖隧道才能到达外部场景贴近真实网络里“IPv6孤岛通过IPv4骨干互通”的诉求。1.2 IPv4/IPv6双栈地址规划表这是我最先落下来的表格地址规划不清晰后面配置必乱。整个实验所有地址都在测试网段内实际项目里替换成自己的规划即可。设备接口IPv4地址IPv6地址承载内容R1GE0/0/0192.168.12.1/24-物理IPv4链路R1LoopBack0-2001:DB8:10::1/128IPv6业务回环R1Tunnel0/0/0-2001:DB8:TUN::1/64IPv6 over IPv4 GRE隧道R2GE0/0/0192.168.12.2/24-IPv4物理链路R2GE0/0/1192.168.23.2/242001:DB8:23::2/64双栈物理链路R2LoopBack0-2001:DB8:20::2/128IPv6业务回环R2Tunnel0/0/1-2001:DB8:TUN2::2/64IPv6 over IPv6 GRE隧道R3GE0/0/0192.168.23.3/242001:DB8:23::3/64双栈物理链路R3LoopBack0-2001:DB8:30::3/128IPv6业务回环R3Tunnel0/0/0-2001:DB8:TUN::3/64IPv6 over IPv4 GRE隧道R3Tunnel0/0/1-2001:DB8:TUN2::3/64IPv6 over IPv6 GRE隧道隧道接口的地址段单独划开不跟业务地址混用这样在路由表和抓包里一眼就能分辨哪条流量走隧道、哪条流量是物理链路。回环接口这里的地址我建议写/128或者规划成一个真正的前缀模拟真实终端网段时用前缀更贴近实际。1.3 为什么两条隧道都选GRE而不是其他封装有人会问IPv6过渡方案那么多为什么要用GRE最直接的原因是GRE隧道天然支持组播。OSPFv3的Hello报文发往FF02::5RIPng的更新报文发往FF02::9这些组播报文如果不能穿越隧道动态路由协议根本起不来。GRE封装对组播、广播不做特殊限制内层协议号还能灵活标识IPv4或IPv6这是很多加密通道做不到的。另外GRE是手工隧道的典型代表源地址、目的地址、隧道协议全部由管理员指定可控性最强。相比自动隧道GRE不会因为目的地址的前缀特殊而产生歧义排错也简单。代价是隧道本身没有加密能力这在实验环境不是问题生产环境需要加密时再叠加其他安全措施即可。实验中我们关心的重点是隧道封装、协议协商和路由选路GRE是最合适的载体。2. GRE隧道原理与华为设备配置要点2.1 GRE封装的报文结构与小实验验证思路要理解后面所有的排错必须先想清楚GRE报文长什么样。以IPv6 over IPv4 GRE为例一个IPv6路由协议的报文要穿越IPv4骨干实际在物理链路上跑的结构是[IPv4头 Protocol47] [GRE头 Protocol0x86DD] [IPv6头IPv6载荷]外层IPv4头的协议号固定为47表示后面的载荷是GRE报文GRE头内部用0x86DD标识内层是IPv6报文。这个0x86DD就是IPv6的ethertype抓包时重点关注这个值就能判断隧道封装是否正确。我用一个生活化的类比GRE就是把完整的IPv6信件原封不动装进一个IPv4信封外层信封上写着隧道的源和目的地址。中间路由器看到外层IPv4信封只负责把它转到目的地根本不会拆开看里面的IPv6内容。等到目的设备解开外层取出IPv6信件才继续按正常IPv6路由转发。理解了这个模型就能解释为什么隧道口up与否跟“隧道目的地址在外层路由表里可达”强相关。2.2 IPv6 over IPv4 GRE配置全过程隧道A的配置要点是外层使用IPv4地址内层接口要启用IPv6。很多新手栽在最后一步隧道口只配了IPv6地址但忘了敲ipv6 enable导致接口处于“半残”状态。R1的关键配置如下interface GigabitEthernet0/0/0 ip address 192.168.12.1 255.255.255.0 # interface LoopBack0 ipv6 enable ipv6 address 2001:DB8:10::1/128 # interface Tunnel0/0/0 tunnel-protocol gre source 192.168.12.1 destination 192.168.23.3 ipv6 enable ipv6 address 2001:DB8:TUN::1/64 ipv6 mtu 1400 ospfv3 1 area 0 # ospfv3 1 router-id 1.1.1.1R3上对应的隧道方向要反过来源是192.168.23.3目的是192.168.12.1。这里有两处很容易忽略第一隧道目的地址必须是外层路由能到达的。R1要把192.168.23.3的报文交给192.168.12.2R3要把192.168.12.1的报文交给192.168.23.2所以R1和R3需要先有到达对方IPv4网段的路径。我在实验里显式写了静态路由# R1 ip route-static 192.168.23.0 255.255.255.0 192.168.12.2 # R3 ip route-static 192.168.12.0 255.255.255.0 192.168.23.2如果不写这两条隧道接口会一直卡在down的状态因为GRE的source和destination之间无法通信隧道链路就建立不起来。第二隧道接口的MTU要主动调小。物理链路的MTU是1500IPv4外层头至少20字节GRE头至少8字节留给内层IPv6报文的空间只剩1472字节左右。为了让IPv6报文不产生分片我在隧道口统一配了ipv6 mtu 1400留出足够余量。这个值不是拍脑袋定的是“物理MTU减外层头减GRE头”得出的可用值再向下取整留缓冲。2.3 IPv6 over IPv6 GRE配置及与IPv4承载的差异隧道B在R2和R3之间外层直接使用IPv6地址。华为设备上要让GRE跑在IPv6外层tunnel-protocol要换成gre ipv6。R2的配置interface GigabitEthernet0/0/1 ip address 192.168.23.2 255.255.255.0 ipv6 enable ipv6 address 2001:DB8:23::2/64 # interface LoopBack0 ipv6 enable ipv6 address 2001:DB8:20::2/128 ripng 1 enable # interface Tunnel0/0/1 tunnel-protocol gre ipv6 source 2001:DB8:23::2 destination 2001:DB8:23::3 ipv6 enable ipv6 address 2001:DB8:TUN2::2/64 ipv6 mtu 1400 ripng 1 enable # ripng 1R3上的Tunnel0/0/1同样把source和destination对调即可。这组配置和隧道A的差异我用一张表总结对比项IPv6 over IPv4 GREIPv6 over IPv6 GREtunnel-protocol命令gregre ipv6source类型IPv4地址IPv6地址destination类型IPv4地址IPv6地址外层头开销IPv4头20字节IPv6头40字节隧道接口MTU建议14001400典型场景IPv6孤岛穿越IPv4骨干原生IPv6网络中做逻辑隔离值得注意的是IPv6 over IPv6 GRE看起来有点“多此一举”但生产环境里它常被用来在已有IPv6网络中叠加虚拟拓扑比如在不同自治域之间建立逻辑隧道、隔离路由域或者配合策略路由做分流。实验环境下把它和IPv4承载的隧道放在一起对比能帮助分清“外层封装”和“内层承载”这两个概念。3. 隧道上的IPv6路由协议静态、RIPng与OSPFv33.1 先通链路再谈路由直连与IPv6静态路由所有动态路由协议都建立在下层链路可达的基础上这条原则在隧道上一样适用。隧道A和隧道B配置完成后第一时间应该ping隧道对端的IPv6地址比如从R1执行ping ipv6 2001:DB8:TUN::3这一步验证的是GRE隧道本身是否已经通了。如果ping不通先不要动OSPFv3和RIPng回头检查外层IPv4/IPv6的可达性、隧道源目地址配置是否正确。隧道链路属于直连网段一旦up隧道两端的IPv6地址就是直连路由不需要额外写静态路由。如果有跨隧道访问非直连网段的需求可以先用IPv6静态路由验证转发再切到动态协议。比如在R1上临时写一条静态路由去往R3的回环ipv6 route-static 2001:DB8:30::3/128 2001:DB8:TUN::3这种写法是把下一跳写成隧道对端地址。因为Tunnel是点对点逻辑接口也可以只写出接口但写成明确的下一跳更有利于在复杂拓扑里判断递归路由是否正常。静态路由作为“备胎”在排错时很好用动态协议起不来先写静态看隧道转发能力是否正常能快速缩小问题范围。3.2 RIPng生效流程与华为命令RIPng的思路和RIPv2很像都是距离矢量协议依据跳数选路。但RIPng的配置和IPv4的RIP完全不同最大的区别是没有network命令直接在接口下使能即可。原因是RIPng直接基于接口运行不需要像IPv4那样通过network声明参与协议的网段。R2上同时把LoopBack0和Tunnel0/0/1加入RIPng进程这样R2的IPv6回环地址才能被R3学到ripng 1 # interface LoopBack0 ripng 1 enable # interface Tunnel0/0/1 ripng 1 enableR3的Tunnel0/0/1同样使能RIPng。I验证时可以用display ripng 1 routeRIPng没有显式的邻居状态表它周期性地向组播地址FF02::9发送整个路由表更新报文承载在UDP 521端口上。这点跟OSPF不同很多同学第一次看RIPng总觉得“没有邻居”就是没配置好其实RIPng本来就不建立邻居状态只要接口使能正确、底层组播能通路由就能交换。RIPng还有一个硬限制是跳数最大15实验中设备少无所谓但设计大网时心里要有数。3.3 OSPFv3邻居建立与区域规划隧道A上跑的是OSPFv3。OSPFv3和OSPFv2最直观的区别之一就是必须手动配置Router-ID因为纯IPv6环境下没有IPv4地址可用来自动选举Router-ID。我第一次配OSPFv3时把R1和R3都忘了写Router-ID结果邻居一直起不来日志里全是Router-ID冲突的报错。R1和R3的OSPFv3配置# R1 ospfv3 1 router-id 1.1.1.1 interface LoopBack0 ospfv3 1 area 0 interface Tunnel0/0/0 ospfv3 1 area 0 # R3 ospfv3 1 router-id 3.3.3.3 interface LoopBack0 ospfv3 1 area 0 interface Tunnel0/0/0 ospfv3 1 area 0OSPFv3邻居使用组播地址FF02::5GRE隧道支持组播所以Hello报文可以穿越隧道。如果隧道口启用了OSPFv3但邻居状态卡在Down或者ExStart最常见的原因就是接口MTU不匹配导致数据库描述报文过大被丢弃。把隧道口MTU统一调成1400以后这类问题基本消失。当模拟器版本出现DR/BDR选举时一个细节是隧道接口在OSPFv3里默认的网络类型可能是broadcast点到点隧道理论上没必要选举DR/BDR。如果看到邻居状态长时间停留在Two-Way我一般会把隧道口的网络类型改成p2p减少无用开销命令大致是在隧道接口视图下调整network-type为p2p。具体命令格式因设备版本略有差异建议以自己环境里的?提示为准。3.4 双协议共存时的路由优先级细节实验里R3同时跑OSPFv3和RIPng两条隧道分别通告不同的业务前缀正常情况下路由表里互不干扰。但如果想模拟链路冗余也可以让两个协议通告相同的前缀这时候路由优先级就会起作用。华为设备上OSPFv3的路由优先级默认是10RIPng默认是100直连路由是0IPv6静态路由默认是60。优先级数字越小越优先。当R3从两条隧道学到同一条IPv6路由时OSPFv3的条目会毫无悬念地胜出。这既是优点也是隐患如果OSPFv3那条路径质量很差流量依然不会切到RIPng路径。生产环境中配置双协议互备时一定要结合路由策略调整优先级或者做等价负载分担不能想当然觉得“协议会自动选最优路径”。4. 综合验证路由表、隧道状态与报文分析4.1 用display命令确认隧道和路由状态配置全部完成后不要急着直接ping业务地址先逐层确认状态。我最常用的验证命令是这样一组验证目标命令预期结果隧道接口状态display ipv6 interface briefTunnel接口State和Protocol都是UP隧道封装详情display tunnel-info all能看到隧道类型、源目地址、隧道IDOSPFv3邻居display ospfv3 peerR1和R3邻居状态为FullRIPng路由display ripng 1 routeR2和R3互相看到对方前缀IPv6路由表display ipv6 routing-table能看到隧道网段和远端业务前缀display ipv6 interface brief里如果看到Tunnel接口的State是UP但Protocol是DOWN说明接口配置了IPv6但隧道封装或者底层链路有问题。这个命令输出的信息很直观基本能确定问题出在哪一层。display tunnel-info all是我在华为设备上特别推荐的一条命令它会列出所有隧道的详细信息包括外层源目地址、封装模式、隧道状态。排错时我习惯先在脑子里回答三个问题源地址对不对目的地址对不对外层路由通不通这三个问题回答完隧道起不来的原因基本能找到一半。4.2 从ping到traceroute验证端到端连通性隧道链路UP、路由协议邻居正常之后最后做端到端验证。从R1发起ping到R3的回环地址ping ipv6 -a 2001:DB8:10::1 2001:DB8:30::3其中-a指定源地址保证报文从R1的IPv6业务回环发出而不是从隧道接口的链路本地地址发出。这条验证说明R1的IPv6业务已经通过隧道A打通了R3的IPv6业务。如果想进一步看路径用traceroutetraceroute ipv6 2001:DB8:30::3输出里能看到R1发出的报文先经过Tunnel0/0/0到达隧道对端地址后进入R3的IPv6路由域再到达目标回环。对于隧道B的验证从R2执行同样的ping和traceroute命令目的地同样写R3的回环地址走的是Tunnel0/0/1。有一个容易踩的坑ping的时候如果目标地址是链路本地地址类型必须同时指定出接口否则设备不知道往哪个接口发包。业务地址是全局单播地址没有这个问题但实验里如果临时用FE80::开头的地址做测试记得把出接口也带上。4.3 抓包看GRE报文从外层到内层逐层解读验证连通性只是第一步想真正理解GRE隧道强烈建议在R2的物理接口上抓包看一次报文结构。在R2的GE0/0/1接口抓包同时从R1发起一个OSPFv3报文穿越隧道A会看到如下典型特征外层IPv4头源地址192.168.12.1目的地址192.168.23.3IPv4头里的Protocol字段值是47代表GRE封装紧接着是GRE头内部Protocol Type字段显示0x86DD代表内层是IPv6再往内层拆能看到IPv6头和OSPFv3的Hello报文。这个逐层拆解的过程非常直观。R2作为中间节点它看到的只是外层IPv4报文根本不会关心里面是什么内容。等到报文到达R3R3拆除GRE封装还原出IPv6报文才按照IPv6路由表继续转发。整个机制和物理链路上的普通IPv4转发没有区别这就是GRE“隧道”二字的含义在逻辑上把两个IPv6网络拉直物理上却不改变中间IPv4网络的行为。如果是隧道B的报文外层就会变成IPv6头源地址显示2001:DB8:23::2目的地址显示2001:DB8:23::3GRE头内部依然是0x86DD。通过对比这两种报文外层封装的差异就一目了然。5. 常见问题排查与避坑记录5.1 隧道起不来、邻居建立失败怎么办这条排错思路可以说是我在整个实验里踩坑最多的地方整理成清单隧道口down先检查tunnel-protocol是不是配置正确。如果写成了gre ipv6但source填的是IPv4地址接口会一直报错。目的的地址必须能在外层路由表里查到。R1必须知道怎么去192.168.23.3R3必须知道怎么去192.168.12.1。物理链路不通或者没有静态路由隧道永远起不来。隧道口配了IPv6地址但忘了ipv6 enable接口的IPv6能力没有激活后续OSPFv3/RIPng配置也会跟着出问题。OSPFv3邻居卡在ExStart优先检查隧道两端MTU是否一致。大包在MTU不一致的链路上被丢弃Hello报文小还能过数据库描述报文一上来就卡住。OSPFv3邻居还有一个隐蔽问题Router-ID冲突。两台设备Router-ID相同会互相拒绝建立邻居排查时不要只盯着接口状态也要看一眼进程里的Router-ID。5.2 MTU引发的“能ping通但业务丢包”这个问题的现象很经典小包ping通大包ping不通或者业务流量频繁丢包。根因在于GRE封装增加了额外开销原本1500字节的物理MTU被外层头挤占内层IPv6报文如果依然以1500字节发送就会在物理出口分片。华为设备上调整隧道接口MTU的命令是interface Tunnel0/0/0 ipv6 mtu 1400这个值怎么算最稳IPv6 over IPv4 GRE场景下1500减去IPv4外层头20字节再减去GRE头至少8字节可用1472字节IPv6 over IPv6 GRE场景下1500减去IPv6外层头40字节再减去GRE头8字节可用1452字节。实验环境为了省心我直接统一设1400留出40字节余量给可能出现的扩展头或者隧道封装变化。如果遇到更复杂的路径比如外层还有VLAN Tag或者MPLS标签MTU还得继续往下调甚至可以直接压到1280这是IPv6标准要求的最小链路MTU。验证MTU是否合理的办法很简单从R1执行一个带大载荷的pingping ipv6 -s 1400 2001:DB8:TUN::3能通说明隧道口的MTU配置生效如果加大到1500不通也不用慌这是正常现象MTU设计就是避免分片而不是强行塞满1500字节。5.3 直接给一张问题速查表现象可能原因处理办法Tunnel接口State/Protocol都DOWNsource/destination配置错误或外层路由不可达检查隧道配置和外层路由表确认源目地址能互通Tunnel接口UP但IPv6地址不生效漏配ipv6 enable隧道接口执行ipv6 enable后重新配置地址OSPFv3邻居卡在ExStart两端MTU不一致两端隧道口统一配置ipv6 mtu 1400OSPFv3邻居不建立Router-ID未配置或冲突在OSPFv3进程下配置唯一Router-IDRIPng路由表中看不到对端前缀接口未使能RIPng或组播不通检查接口下ripng 1 enable确认隧道支持组播ping小包通大包不通隧道MTU过大导致分片隧道口配置ipv6 mtu 1400或更低能ping通隧道对端但ping不通回环地址回环接口未加入路由协议或路由未通告确认LoopBack接口使能了对应路由协议这个表是我每次做类似实验都会贴在旁边的“懒人版排错手册”。大多数问题都集中在三层隧道封装本身、外层路由可达性、隧道接口参数一致性。6. 实验扩展和一点个人体会实验做到这里已经能完整覆盖IPv6 GRE隧道加路由协议的核心链路。如果需要继续往深处挖我有两个建议方向第一个方向是叠加BGP4。在隧道A的OSPFv3跑通之后可以把R1和R3之间的路由域切换成BGP4在IPv6地址族下建立邻居关系。BGP4适合模拟跨自治域的场景比如R1属于AS 65001R3属于AS 65002在隧道口建立IPv6 IBGP或EBGP会话能体会到GRE隧道作为逻辑链路在跨域互联时的价值。第二个方向是做双隧道冗余和流量切换。比如在R3上同时通过隧道A和隧道B学到R1的某个前缀观察OSPFv3和RIPng的优先级如何决定选路再通过人为down掉一条隧道验证路由收敛。这个实验能直观感受到动态路由协议在隧道故障时的行为差异对理解网络冗余设计非常有帮助。说一下个人在实际操作中的体会。这类综合实验最大的价值不在于背下多少条命令而是养成“逐层验证”的习惯先验证物理链路再验证隧道再验证路由协议最后验证业务流量。每完成一步马上用display命令确认不要一口气配完所有设备再来排错那样一旦出问题排查范围会膨胀到让人头大。我在第一次实验时就是一口气把三台设备的全部配置敲完结果隧道B起不来花了大半个小时才发现是source和destination写反了。从那以后我的习惯是配完一台设备立刻验证一台隧道建好先ping对端地址路由协议起来先看邻居状态最后才测业务连通性。GRE隧道加IPv6路由协议这个组合说难不难说简单也不简单。难在概念分层多外层封装、内层承载、路由协议、MTU计算每一层都可能出问题简单在于只要理解每一层的作用排错思路就非常清晰。希望这篇记录能帮你少走一些弯路。
