IPv6排障工具之ping6完整过程细节剖析

qcloudcommunity · · 1717 次点击 · 开始浏览    置顶
这是一个创建于 的主题,其中的信息可能已经有所发展或是发生改变。

> 导语 | 关于ping的原理详解,网上可以搜索出很多相关内容,而ping6的详解,则很少看见高质量的文章。希望本文能够让更多朋友了解ping6的原理。通过本文你将了解到什么是ICMPV6协议,以及一个完整的ping6过程究竟是怎样发生的。(本文作者:腾讯云售后架构师 李彬文) ### 一、ICMPv6简介 ICMPv6(Internet Control Message Protocol for the IPv6)是IPv6的基础协议之一。ICMPv6具备向源地址报告关于向目的地传输IPv6数据包过程中的差错信息和控制信息。 ICMPv6定义了一些消息,如:目的不可达、数据包超长、超时、响应请求和响应应答等。在IPv6中,ICMPv6除了提供ICMPv4常用的功能之外,还有其它一些功能,如邻接点发现、无状态地址配置(包括重复地址检测)、PMTUD等。 ### 二、ICMPv6报文格式 ICMPv6报文格式如下图所示: ![alt](https://pic3.zhimg.com/80/v2-5bbc460f1e1d1a9af9cee6634fb083d6_hd.jpg) ICMPv6属于OSI七层协议栈的网络层,虽然和IPv6属于同一层,但是封装时必须先封装IPv6报文头部。 ICMPv6字段注释: Type:表明消息的类型,0至127表示差错报文类型,128至255表示信息报文类型。 Code:表示此消息类型细分的类型。 Checksum:表示ICMPv6报文的校验和。 ### 三、ICMPv6差错报文 ICMPv6差错报文用于报告在转发IPv6数据包过程中出现的错误,可以分为以下4种: #### 1. 目的不可达错误报文 在IPv6中间设备转发IPv6报文过程中,当设备发现目的地址不可达时,就会向发送报文的源地址发送ICMPv6目的不可达错误报文,同时报文中会携带引起该错误报文的具体原因。 目的不可达错误报文的Type字段值为1,根据错误具体原因又可以细分为: Code=0:没有到达目标设备的路由。Code=1:与目标客户端的通信被管理策略禁止。Code=2:未指定。Code=3:目的IP地址不可达。 Code=4:目的端口不可达。 #### 2. 数据包过大错误报文 在IPv6中间设备转发IPv6报文过程中,发现报文超过出接口的链路MTU时,则向发送报文的源地址发送ICMPv6数据包过大错误报文,其中携带出接口的链路MTU值。数据包过大错误报文是Path MTU发现机制的基础。 数据包过大错误报文的Type字段值为2,Code字段值为0。 #### 3. 时间超时错误报文 在IPv6报文收发过程中,当设备收到Hop Limit字段值等于0的数据包,或者当设备将Hop Limit字段值减为0时,会向发送报文的源地址发送ICMPv6超时错误报文。对于分段重组报文的操作,如果超过定时时间,也会产生一个ICMPv6超时报文。 时间超时错误报文的Type字段值为3,根据错误具体原因又可以细分为: Code=0:在传输中超越了跳数限制。 Code=1:分片重组超时。 #### 4. 参数错误报文: 当目的节点收到一个IPv6报文时,会对报文进行有效性检查,如果发现问题会向报文的源地址回应一个ICMPv6参数错误差错报文。 参数错误报文的Type字段值为4,根据错误具体原因又可以细分为: Code=0:IPv6基本头或扩展头的某个字段有错误。 Code=1:IPv6基本头或扩展头的NextHeader值不可识别。 Code=2:扩展头中出现未知的选项。 ### 四、ICMPv6信息报文 ICMPv6信息报文提供诊断功能和附加的主机功能,比如组播侦听发现和邻居发现。 常见的ICMPv6信息报文主要包括回应请求报文(Echo Request)和回应应答报文(Echo Reply),这两种报文也就是通常使用的Ping6报文。可以分为以下2种: #### 1. 回应请求报文 回应请求报文用于发送到目标地址,以使目标地址立即发回一个回应应答报文。回应请求报文的Type字段值为128,Code字段的值为0。 #### 2. 回应应答报文 当收到一个回应请求报文时,ICMPv6会用回应应答报文响应。回应应答报文的Type字段的值为129,Code字段的值为0。 ### 五、ping6 完整过程梳理 如下图所示,云主机CVM1要和CVM2通信(假设CVM的IPV6地址和VPC已经按文档https://cloud.tencent.com/document/product/213/40010正常配置且IPV6路由和地址检查都正常)。 ![alt](https://pic2.zhimg.com/80/v2-885ad57fe1bfc33ff2f52c08d5c3a6d5_hd.jpg) 从CVM1输入命令 ping6 2402:4e00:1200:2001::2020 -c 10,输出的结果如下图所示: ![alt](https://oscimg.oschina.net/oscnet/up-6467bef4c3598f69b0d59d1bc300690a610.JPEG) 这是一次成功的ping6测试,但是这次ping6的细节大家也许不太了解。接下来我们主要按OSI协议栈来剖析整个ping6的工作过程以及整个过程会用到的相关报文。 ![alt](https://oscimg.oschina.net/oscnet/up-3a0b6768689ad34929b43730eaf9a03811e.JPEG) **Step1:**ICMPv6创建一个56字节的回应请求: ![alt](https://oscimg.oschina.net/oscnet/up-2df9543f10ca2b76e07258cd6691cea29bd.png) **Step2:**ICMPv6在56字节的请求数据基础上加上ICMPv6头部: ![alt](https://oscimg.oschina.net/oscnet/up-7b8a33f6bf4522e2eaaec60664c0a31f4c4.JPEG) 回应请求报文的Type字段值为128,Code字段的值为0,然后交给IPv6协议封装; **Step3:**IPv6协议在ICMPv6基础上增加IPv6头部:(网络层封装) ![alt](https://oscimg.oschina.net/oscnet/up-6e92a769db046107b88b75c4679a370d557.JPEG) 封装的源IPv6地址是接口网卡v6地址:2402:4e00:1200:2002::2011 封装的目标IPv6地址:2402:4e00:1200:2001::2020 **Step4:**根据目标IPv6地址和本地网段前缀做对比,发现目标地址不属于本地网段2402:4e00:1200:2002::/64。只能查路由表进行跨网段路由,查找路由表发现没有匹配的明细路由,最终只能选择默认路由::/0进行转发。 ![alt](https://oscimg.oschina.net/oscnet/up-2ff4dc22e75751adc9dce3ebb131454fdb4.png) **Step5:**通过默认路由找到可以通过网卡eth0进行转发,但是需要数据链路层封装成功后才能从网卡转发出去。数据链路层封装的源MAC就是出接口eth0的MAC地址,目标MAC地址要从ip -6 neigh 表(类似IPv4的ARP表)中查询到。 ![alt](https://oscimg.oschina.net/oscnet/up-2f084a39d2c30275fed01adca64b4a5a45c.JPEG) 这里并没有学习到目标IPv6地址2402:4e00:1200:2001::2020对应的MAC地址,导致无法进行数据链路层封装。 **Step6:**为了学习到目标地址2402:4e00:1200:2001::2020对应的MAC地址,首先发送NS报文:Type字段值为135,Code字段值为0,在地址解析中的作用类似于IPv4中的ARP请求报文。 ![alt](https://oscimg.oschina.net/oscnet/up-a8dfd5bca872761aa9ce34d3c5a659050c6.JPEG) 这里面存在着两个问题,下面我们也会给出相应的解释: (1)被请求节点组播IPv6地址FF02::1:FF00:2020如何生成? IPv6中没有广播地址,也不使用ARP。但是仍然需要从IP地址解析到MAC地址的功能。 在IPv6中,这个功能通过邻居请求NS(Neighbor Solicitation)报文完成。当一个节点需要解析某个IPv6地址对应的MAC地址时,会发送NS报文,该报文的目的IP就是需要解析的IPv6地址对应的被请求节点组播地址,只有具有该组播地址的节点会检查处理。 被请求节点组播地址由前缀FF02::1:FF00:0/104和目标单播地址的最后24位组成。由于目标单播地址是2402:4e00:1200:2001::2020,所以生成的被请求节点组播地址是:FF02::1:FF00:2020。 (2)被请求节点组播MAC地址33:33:ff:00:20:20如何生成? 组播MAC地址48bit的前24bit默认固定是33:33:ff,后半部分是被请求节点组播地址的后24bit,所以生成的组播MAC地址是33:33:ff:00:20:20。 **Step7:**CVM1发送的NS请求报文给到虚拟网关路由器,虚拟网关路由器收到NS报文后查看路由表匹配到路由2402:4e00:1200:2001::/64,代理目标地址回复一个NA报文:Type字段值为136,Code字段值为0,在地址解析中的作用类似于IPv4中的ARP应答报文。 ![alt](https://oscimg.oschina.net/oscnet/up-b600eba1ab7eaa1e6e3926dedddfc7c932c.JPEG) IPv6地址解析示意图: ![alt](https://oscimg.oschina.net/oscnet/up-acdc2bc6f5b989239884280bd0810344090.JPEG) 学习到目标地址2402:4e00:1200:2001::2020对应的MAC地址是fe:ee:1e:1b:cb:e0。学习到的MAC存入到IPV6邻居表中: ![alt](https://oscimg.oschina.net/oscnet/up-8770f202fa9c373bb9e8c9410f469870cba.png) **Step8:**回到Step5有了目标IPv6地址2402:4e00:1200:2001::2020对应的MAC地址可以进行数据链路层封装,然后从网卡eth0发出第一个ICMPv6的回应请求报文: ![alt](https://oscimg.oschina.net/oscnet/up-3ef8b78e8e46852833eec55e1b21573c5db.png) 从第一个NS到第一个ICMPv6回应请求的发出顺序如下:(CVM1的网卡抓包) ![alt](https://oscimg.oschina.net/oscnet/up-98c77884737a49b9b0d9922fca0a76e04c5.png) **Step9:**该回应请求报文到达虚拟网关路由器A后查路由表找到对应的overlay网络隧道(这里的虚拟网关和overlay网络暂不用展开)转发到目标虚拟网关路由器B,然后由虚拟网关路由器B转发给CVM2的eth0网卡。 ![alt](https://oscimg.oschina.net/oscnet/up-7fd224aaf6f686ff40e4b5054cad887da23.JPEG) **Step10:**CVM2的网卡eth0收到回应请求报文后通过二层帧头的type字段,确认递交给IPv6协议处理。 ![alt](https://oscimg.oschina.net/oscnet/up-9ec29cff68fab9ae9a682dc62fbfd6e99b7.png) **Step11:**IPv6协议处理头部,检查目标IP正确,检查下一个协议头部类型是ICMPv6。 ![alt](https://oscimg.oschina.net/oscnet/up-9f92cda3cd6b0490b72a7d1033fa738b8e2.JPEG) ![alt](https://oscimg.oschina.net/oscnet/up-f1088cfe039b1d302942b9881c1ba3ab0f5.JPEG) **Step12:**当收到一个回应请求报文时,ICMPv6会用回应应答报文响应。回应应答报文的Type字段的值为129,Code字段的值为0。 CVM2按同样的方式去查路由表封装网络层报文,按Step5到Step7解析到MAC后,查ipv6 邻居表封装数据链路层的目的MAC。 具体CVM2从收到第一个回应请求报文到发出第一个回应应答报文顺序如下: ![alt](https://oscimg.oschina.net/oscnet/up-63e3e77ea071c0dcee136570ffb95bd1478.png) NS报文: ![alt](https://oscimg.oschina.net/oscnet/up-08c566c2959c9122a9b87d5c6170b53fcf2.JPEG) NA报文: ![alt](https://oscimg.oschina.net/oscnet/up-2945a028062d2f20a158bbaf44a0d790882.JPEG) 学习到MAC后发送回应应答报文: ![alt](https://oscimg.oschina.net/oscnet/up-5337c8027ea1f7db3b25514b76d0a860e13.JPEG) **Step13:**该回应应答报文到达虚拟网关路由器B后查路由表找到对应的overlay网络隧道转发到目标虚拟网关路由器A,然后由虚拟网关路由器A转发给CVM1的eth0网卡。 **Step14:**CVM1和CVM2以及虚拟路由器A和B都已经缓存了对应IPv6地址的MAC,后续封装无效再发送NS与NA,直接数据链路层封装后路由转发即可。 CVM1完整的10个ping6报文截图如下: ![alt](https://oscimg.oschina.net/oscnet/up-ed4fe8d961e6ed3f141868167dd7fab35cc.JPEG) CVM2完整的10个ping6报文截图如下: ![alt](https://oscimg.oschina.net/oscnet/up-be037fbb5d60f866d165d3c56fe313ff39a.JPEG) CVM1的ping6成功的截图如下: ![alt](https://oscimg.oschina.net/oscnet/up-e0c0f2a7399a24d1ac7e72007af2f9b7d67.JPEG) 到此一次完整的ping6的过程就结束了,同样的道理,其他协议报文也是有这样的一个封装和解封装过程,希望本文能够让对大家有所帮助。 ![alt](https://oscimg.oschina.net/oscnet/up-fcee485dd23e135dd715abb00650ea2d194.gif)

有疑问加站长微信联系(非本文作者)

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1717 次点击  ∙  1 赞  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传