文档首页> 云容器引擎 CCE> 常见问题> 网络管理> 网络异常> 为什么登录虚拟机VNC界面会间歇性出现Dead loop on virtual device gw_11cbf51a, fix it urgently?
更新时间:2022-05-06 GMT+08:00
分享

为什么登录虚拟机VNC界面会间歇性出现Dead loop on virtual device gw_11cbf51a, fix it urgently?

问题现象

VPC网络模式的集群,登录虚拟机出现 Dead loop on virtual device gw_11cbf51a, fix it urgently,如图:

原因定位

VPC网络模式的集群采用了linux开源社区的ipvlan模块实现容器网络通信,这一日志打印与ipvlan的设计实现有关,ipvlan L2E模式它优先进行二层转发,再进行三层转发。

场景还原:

假定有业务Pod A,它持续对外提供服务,不断被同节点访问收发报文,通过本机k8s service经过容器gw接口进行访问,或者同属本节点的Pod间直接互相访问。在升级、缩容,或者其他原因导致的退出场景,容器A已停止运行,对应的网络资源被回收。此时同节点的报文仍持续尝试在往容器A的IP发送报文。内核中的ipvlan模块首先尝试根据目的IP来二层转发这些报文,但是由于Pod A已无法找到该IP所属的网卡,ipvlan模块判断它有可能是个外部报文,因此尝试进行三层转发,根据路由规则匹配上了gw口,因此gw口又收到此报文,再经由ipvlan模块转发,如此循环。内核中的dev_queue_xmit函数检测到重复进入发包过程达10次,报文被丢弃同时打印该日志。

发起访问端的在报文丢失后一般会进行几次退避重试,因此在这种场景下会连续打印几次条日志,直到发起访问端的容器内ARP老化或业务自身终止访问。

跨节点容器间通信,由于目的IP及源IP不属于同个节点级专属子网(注意此子网与VPC子网概念不同),报文不会重复走到此业务流程因此,不会触发此问题。

同集群不同节点间的Pod通过Cluster模式的NodePort来访问除外,它会被SNAT成被访问端容器gw接口的IP,因此也有可能触发此日志打印。

问题影响

被访问端容器正常运行时不会有影响。容器被销毁时,有一定影响,但影响较小,重复进入发包过程10次,然后被丢包,这个过程在内核中处理十分迅速,对性能影响可以忽略。

对于ARP老化或业务自身不再重试,或新容器会被拉起,容器service服务报文经过kubeproxy重定向到新业务。

开源现状

目前开源社区ipvlan L2E模式仍存在此问题,已向开源社区反馈,待确认更优方案。

解决方法

打印Dead loop问题本身无需解决。

但我们推荐服务Pod使用优雅退出,在业务真正终止服务前,优先将Pod设置为删除中的状态,待业务处理完毕请求后再退出。

详情可参考优雅删除

分享:

网络异常所有常见问题

more

close