优化IPv6业务可用性全过程
原创
导语| 截止到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%左右。
三、信息收集
lb：lb-3ykhifin 域名：abc.test1.com 短连接业务
地域：北京
CLB地址：2402:4e00:1255:2c9:0:8f53:4166:f4c8
后端有3台rs：
ins-6efa6351 10.32.0.11 2402:4e00:1255:2c9:0:8f53:4072:6edb
ins-7ihum1in 10.32.0.55 2402:4e00:1255:2c9:0:8f53:4038:b936
ins-81dqqajl 10.32.0.22 2402:4e00:1255:2c9:0:8f69:41a7:5392
四、问题分析
1.由于拨测的复现点都是联通节点（唐山联通，贵阳联通，银川联通等），开始怀疑运营商问题，分析后认为应该提供MTR给运营商报障，当时MTR结果如下：（从拨测结果看第十跳开始100%丢包）
1 | 2408:826a:20:66d5::(中国, 中国联通) | 85% | 100 | 1 | 0.3 | 1 | 1 | 0.4 |
|---|---|---|---|---|---|---|---|---|
2 | 2408:8001:8001::612(中国, 中国联通) | 0% | 100 | 3 | 3.9 | 1 | 31 | 3.8 |
3 | 2408:8001:8001:233::3(中国, 中国联通) | 1% | 100 | 4 | 4.5 | 2 | 45 | 6.1 |
4 | 2408:8001:8000:16::(中国, 中国联通) | 0% | 100 | 2 | 3.0 | 1 | 25 | 3.1 |
5 | 2408:8000:2:5a::1(中国, 中国联通) | 0% | 100 | 19 | 20 | 18 | 52 | 4.6 |
6 | 2408:8000:2:357::(中国, 中国联通) | 0% | 100 | 45 | 45 | 44 | 63 | 3.3 |
7 | 2408:8000:1100:308::3(北京市, 中国联通) | 0% | 100 | 45 | 46 | 44 | 60 | 3.0 |
8 | 2408:8000:1f10:6410::3(北京市, 中国联通) | 0% | 100 | 53 | 54 | 52 | 89 | 4.2 |
9 | 2408:80f0:4100:300c::3(北京市, 中国联通) | 0% | 100 | 57 | 57 | 56 | 80 | 3.4 |
10 | *(N/A) | 100% | 100 | 0 | 0.0 | 0 | 0 | 0.0 |
11 | *(N/A) | 100% | 100 | 0 | 0.0 | 0 | 0 | 0.0 |
2.从MTR来看确实到了北京联通后丢包，联通经过排查确实发现有部分链路出现问题，联通给出的结论：
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 发现指定的是出接口
五、综上所述问题根因
建连失败根因是高峰期新建连接数很多，导致很快就将邻居表打满。当CVM邻居表被打满后，CVM在回复syn+ack时由于查找不到目标IPv6地址对应的MAC，最终导致CVM无法正常回复syn+ack而表现出TCP建连失败。
六、解决方案
1.临时解决方案，将IPv6邻居表缓存限制数量，在原来基础上增加一倍；
调整邻居表限制数量：vim /etc/sysctl.conf 将 net.ipv6.neigh.default.gc_thresh3 = 8192
2.彻底优化方案，指定IPv6默认路由的默认网关：
新增默认网关配置：ip -6 route add default dev eth0 via fe80::feee:ffff:feff:ffff
替换原有默认网关配置：ip -6 route replace default dev eth0 via fe80::feee:ffff:feff:ffff
为了重启后不丢失配置：vim /etc/sysconfig/network-scripts/route6-eth0 下添加一条指令default dev eth0 via fe80::feee:ffff:feff:ffff
七、优化后的效果：（蓝色的线就是IPv6可用性拨测）
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。