优化IPv6业务可用性全过程

binwenli • 2023-01-02 • 云技术社区 • 294 阅读

导语| 截止到2020年5月，中国IPv6活跃用户已经高达2.83亿，云服务平台中完成IPv6改造的云产品占比超过64%。越来越多的用户会使用IPv6的CLB（云负载均衡），以及IPv6的CVM（云服务器），本文主要详细介绍使用IPv6建连导致的偶发超时问题以及对应优化方案。

本文作者：腾讯云售后架构师李彬文

一、访问CLB的原理概述

如果您的业务使用腾讯云CLB作为接入点，那么IPv6客户端访问的路径大致如下图：

正常的一次IPv6访问过程如下:

1.用户通过80或443端口访问abc.test1.com的主页，会先向本地DNS服务器发起域名解析，默认支持双栈的终端解析请求优先指定解析类型为IPv6；

2.当本地DNS解析abc.test1.com 域名时，将查找出的CLB（腾讯云负载均衡）公网IPv6地址返回给用户；

3.用户向CLB的IPv6地址发送TCP建连请求，发送TCP三次握手的第一个syn报文通过运营商IPv6网络路由到腾讯云CLB；

4.腾讯云CLB收到syn报文后根据四层负载均衡的规则，最终转发到部署业务的RS（云服务器）上；

5.云服务器收到syn报文后，查看是否有对应侦听的业务端口，然后回复syn+ack报文给到用户的IPv6地址；

6.最终用户与部署业务的RS（云服务器）建立正常的TCP连接，然后进行正常的业务数据请求与交付直到断开本次TCP连接。

二、问题现象

业务域名：abc.test1.com 针对海南、内蒙、江西、贵州、广西5省的省会城市做的拨测，网络质量不高，IPV6的首页拨测可用性只有90%左右。

3.观察一天7月15日 10:50 发现听云拨测节点又出现之前的可用性下降问题，需要继续排查。

4.可用性下降是因为拨测发现很多TCP建连失败导致，而建连失败的syn报文是否到了CLB是很关键的一个点，如果到了CLB，说明就不是运营商问题。

5.在7月15日15:00协调好听云拨测节点以及腾讯云的CLB一起复现抓包，截止16:30大概复现了三次，抓包发现报文到了CLB:

拨测节点抓包：

CLB所在集群抓包：入长度86字节，转给RS封装GRE=12字节，IP头部=20字节

6.确定不是运营商问题后，在物理机和CVM抓包：tcpdump -i any host 2408:825c:6a1:afe9:89e7:d5f6:250:d470 -w rs1.pcap，抓包点分别是 Client-->CLB集群-->物理机-->CVM，通过全链路抓包分析发现报文已经到CVM。

CVM以及母机的抓包：从下面截图可以看出syn报文给到了CVM后没有回复syn+ack

CLB地址：2402:4e00:1200:2c9:0:8f53:4166:f4c8

CVM地址：2402:4e00:1200:2c9:0:8f69:41a7:5392

7.通过报文分析，CVM收到syn报文没有回复syn+ack，建议看一下系统日志是否有什么报错？dmesg发现直接刷屏提示邻居表（类似IPv4的ARP表）满了：

8.建议查看邻居表限制数量cat /etc/sysctl.conf | grep ipv6发现规格是4096，建议先调整到8192恢复可用性：vim /etc/sysctl.conf （修改命令）

9.调整阀值这是临时解决方案，要解决根本问题，还要找到为什么邻居表增长这么快？

IPv6中的邻居表类似于IPv4的ARP表，具体原理就是CVM回复报文找不到目标IPv6地址对应网关MAC，所以需要发送NS（Neighbor Solicitation）报文去解析目标IPv6地址MAC。关于NS解析MAC的原理参考我之前发表的这个文章：https://cloud.tencent.com/developer/article/1572432

而CVM邻居表增长快是因为每次新的Client请求到CVM，CVM回复报文时找不到目标IPv6地址对应的网关MAC，所以每次新建连接的请求都需要重新解析IPv6地址对应的网关MAC。由于该业务是短连接，那么新建连接数相对长连接会更高很多，最终导致邻居表快速增长。通过查看邻居表可以发现大量Client地址对应的网关MAC都是同一个：

10.如何优化IPv6的邻居表快速增长的问题？

为了避免CVM每次都去解析Client的Pv6地址对应的网关MAC，通过将IPv6默认路由指定默认网关，然后通过默认网关递归出网关MAC，如此一来就不用每次新建连接都去解析网关MAC。

确认默认路由没有指定默认网关：ip -6 route show 发现指定的是出接口