网卡mtu值引起的服务访问异常处理过程

一、现象说明
我们在k8s集群上部署服务,发现在72段主机上的服务访问是都没有问题的;但是在161段主机有的服务可以访问;有的访问没有返回值;其中在161段主机访问没有返回值的服务;到服务所在的主机是可以访问的。
二、解决过程
针对上述现象,我们确定了这两个段的ip是在一个vpc的,互相访问是没有问题的,不然也不可能存在有的访问有返回值,有的没有返回值,截图如下: 在这里插入图片描述
在这里插入图片描述上图是我把grafana调到161段主机上curl就不正常了,重新把它调度到72段就能正常访问,后面我们部署了个nginx到161段发现也能正常访问,包括已经部署的redis集群和kafka集群以及其他服务都能正常访问,这些redis的管理web页面访问就不能正常返回,只能说太邪门了。
对比了下72段主机和161段的主机只是发现主机内核不一样还有主机网卡的mtu值是不一样的,因为我们之前部署calico因为mtu值不对造成服务不可以正常访问的问题,看了下自己的calico配置,因为我们calico用的是ip-ip模式,所示calico的mtu值应该是所在主机的网卡mtu值减去20,因为我们主机72段的主机和161段的主机mtu值是不一样的;只能选择按主机最小的mtu来定义calio的mtu值,发现配置的是没有问题的,难道按照主机mtu值最小的来算calico的mtu值是不行的吗,想着就把calico的mtu值改为了72段主机的mtu值来算了,创建更新calico,再去访问服务,发现情况依然没有改变,只能通过分别抓包看看了,抓包截图如下: 在这里插入图片描述在这里插入图片描述通过抓包发现不正常的服务发送出去的包,没有回应,并且不断重试发送,这个时候怀疑可能是主机的mtu值导致的,发现72段主机的mtu值是1500;发出的数据包都有很快的返回;而161段主机就无法正常返回,并且不断重试,然后改下161段主机的mtu值到1500,发现再去访问服务就都是能正常返回了。

mtu: 工作在数据链路层,在IP层下面的每一种数据链路层都有自己的帧格式,其中包括帧格式中的数据字段的最大长度,这称为最大传送单元 MTU(Maximum Transfer Unit)。
当一个数据报封装成链路层的帧时,此数据报的总长度(即首部加上数据部分)一定不能超过下面的数据链路层的MTU值。

### 解决ZeroTier网络中Ping命令链接超时的问题 在处理Windows与Linux之间的高延迟和不稳定的网络连接问题时,已经尝试调整了防火墙设置中的ICMPv4入站规则[^1]。然而这些更改并未显著改善情况。 对于ZeroTier网络内的ping超时现象,可能的原因包括但不限于: - **路径MTU发现失败**:当数据包大小超过路径上最小最大传输单元(MTU),而该路径又不允许分片时会发生丢弃。这可能导致某些情况下看似无响应的行为。 - **NAT穿越问题**:即使在同一虚拟网络内,如果设备位于不同的物理位置并通过互联网通信,则可能会遇到由路由器或ISP引起的复杂NAT环境下的连通性挑战[^2]。 针对上述可能性,建议采取如下措施来排查并解决问题: #### 调整MTU设置 可以通过降低接口上的MTU来进行测试,以排除由于过大的帧尺寸引发的数据包丢失。具体操作方法取决于操作系统版本,在大多数Linux发行版中可以使用`ip link set dev <interface> mtu <value>`命令;而在Windows下则需通过适配器属性界面完成相应配置。 ```bash # Linux 设置eth0网卡MTU为1400字节 sudo ip link set dev eth0 mtu 1400 ``` #### 检查路由表项 确认两端主机都拥有正确的默认网关以及指向对方子网的具体静态路由条目。错误或者缺失的目标网络可达信息会阻碍正常通讯过程。 #### 测试TCP端口连通性 除了依赖于ICMP协议外,还可以利用telnet或其他工具验证目标节点开放的服务端口号是否可访问。因为有时候尽管ICMP被阻塞,但其他类型的流量仍能顺利通行。 #### 审核日志记录 查阅系统和服务的日志文件寻找任何异常活动迹象或是警告消息,它们往往能够提供关于潜在障碍的重要线索。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值