前言
Weave 作为 Docker 跨主机集群网络解决方案的一种，可以用于连接部署在多台主机上的 Docker 容器，使用网络的应用程序不必去配置端口映射等信息，Weave的通信支持加密，所以用户可以从一个不受信任的网络连接到主机。Weave 在控制层面和 Calico 类似，在数据层面通过UDP封装实现 L2 overlay 。 Weave 在 1.2 版本之前都是使用 usersapce 实现，在 weave-1.2版本后， weave 结合了内核的 openvswitch 模块，实现了 open vSwitch datapath（odp）功能，结合 kernel 的 vxlan 特性，在网络性能上有较大的提升。 由于 odp 功能和内核相关模块结合较为紧密，在实际使用中可能遇到一些和内核相关的坑，本文描述的两个问题都和内核有关系。
坑一：weave fastdp造成虚拟机网络中断
问题描述
在 weave 1.2 版本之后，考虑到原先 sleeve 模式的网络性能较差，增加了 fastdp 的模式，该模式成为了 weave 启动时的默认模式，在 fastdp 模式中使用了 kernel 中的 openvswitch 模块，做报文封装时使用了 vxlan 协议。在使用 qemu-kvm 创建的云主机上， 如果安装的是 centos7.0 ，内核版本为 kernel-3.10.123 ，在启动 weave 并使用 fastdp 模式时，会造成 virtio_net 虚拟网卡无法发送数据，进而导致整个虚拟机的网络中断的问题。
问题分析
造成网络断开的原因是因为触发了内核的一个 bug ，该内核 bug 的 commit 链接地址：https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=8a0cafc9a8131cc545dc9924aed38f7176ee4ad7。
触发该 bug 主要是由于 Weave 在初始化时会发送一个 60000 字节的 UDP 数据包进行 PMTU 的探测，并且 Weave 发送使用的套接字为 raw socket ，导致了 virtio_net 使用的内存被污染，表现的现象就是无法通知到宿主机上 vhost 取数据，在接口上看到发送报文的计数始终不会增加。
该问题不是只有 weave 才能触发，使用普通的应用程序只要在建立 socket 时，使用是 raw socket ，并且在发送数据时，发送的数据大于接口的 MTU 值，接口的 UFO 功能是打开的，都极有可能触发该问题，造成网络的中断。
图1：fastdp 模式的数据流原理
解决方案
有两种方式可以解决该问题：
1）升级内核，保证内核版本大于等于 3.13 ，
2）关闭虚拟机网卡的 ufo 特性，centos7.1 的 kernel-3.10.229 内核已经修复了该问题。
图2：guest 通知 vhost 读取数据流程
坑二：Weave无法使用fastdp模式
问题描述
在内核版本 CentOS Linux (3.10.0-327.10.1.el7.x86_64) 7 (Core) 上 ，weave 版本大约 1.2 ，如果云主机的 MTU 值为 1450 或者小于 1474 ， weave 启动时无法正常的选择 fast data path模式。在 weave 启动后一直选择 sleeve 模式，本应该默认模式为 fastdp ，该问题也和内核的版本相关。
问题分析
Weave的fast data path路径使用到了 odp 技术，也就是内核中的OVS模块，在 Container 中直接发送数据包到 ovs 模块。在启动 Weave 时，会自动选择使用 sleeve 模式还是 fastdp 模式，这里通过发送心跳包来决定的，出现该问题时，在云主机通过 docker logs weave 的日志可以看到这样出错的信息：fastdp timed out waiting for vxlan heartbeat。
这个 heartbeat 的数据包，是一个 UDP 包，目的端口号为 6784 ，在某些云主机上接口的MTU值为 1454 ，但是在发送 UDP 的 heartbeat 数据包时，发送的是 1474 字节，这样就会对报文在IP层进行分片，但在主机上发现心跳报文发送不出，当 MTU 的值修改为 1500 后，就可以发送出去，在 MTU 为 1454 的情况下，会出现下面的 ICMP 的错误报文。
图3: 出现的错误icmp报文
出现上面错误的 icmp 报文，是内核中的 ip_fragment 函数调用 icmp_send 函数发送的，
if (unlikely(((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) ||
(IPCB(skb)->frag_max_size &&
IPCB(skb)->frag_max_size > mtu))) {
IP_INC_STATS(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
htonl(mtu));
kfree_skb(skb);
return -EMSGSIZE;
}
通过上面的代码可以看出，如果出现上面出错的 ICMP 报文，下面的判断条件 iph->frag_off & htons(IP_DF)) && !skb->ignore_df 需要成立，通过对抓取的报文分析可知 iph->frag_off & htons(IP_DF)) 的值为真，那么 skb->ignore_df 值需要为 0 ，这里的关键在于 skb->ignore_df 的值是何时赋值为0的。
通过分析 weave 发送心跳包的流程可知，在 vxlan_tnl_send 函数中，对 skb->ignore_df 赋值为 1 ; 在最后调用 tunnel 的发送函数 iptunnel_xmit 时，调用了 skb_scrub_packet 函数，在该函数中又重新对 skb->ignore_df 赋值为0.（ kernel 版本为：3.10.0-327.el7 ），造成后续发送报文时，发送了 ICMP 目的不可达，并且错误码为 ICMP_FRAG_NEEDED 的报文。
void skb_scrub_packet(struct sk_buff *skb, bool xnet)
{
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->skb_iif = 0;
skb->ignore_df = 0;
skb_dst_drop(skb);
secpath_reset(skb);
nf_reset(skb);
nf_reset_trace(skb);
if (!xnet)
return;
skb_orphan(skb);
skb->mark = 0;
}
上面代码是 centos 7 的 3.10.0 - 327.el7 ，而在老一些的内核版本 3.10.0 - 123.el7 上， iptunnel_xmit 调用的是 secpath_reset(skb) 函数，在该函数中并没有对 skb->local_df （低版本的内核使用的是 local_df ）进行重新的初始化，也就是 skb->local_df 值仍旧为1，因此在该版本上不会出现该问题。
static inline void
secpath_reset(struct sk_buff *skb)
{
#ifdef CONFIG_XFRM
secpath_put(skb->sp);
skb->sp = NULL;
#endif
}
图4：内核版本不同造成设置不同
在新的内核版本中存在该问题，但是内核本身是没问题的，还是 weave 用户态的管理 datapath 的程序和内核的适配上有问题(它并不是使用 ovs-switchd ），在 ovs 中的对 tunnel 类型可以设置为 df_default = false 进行分片。
解决方案
保证接口 MTU 值为默认的1500.
总结
Weave 的 odp 功能使用了内核的特性，在使用 weave 的 fastdp 功能时遇到上面两个问题，都是和内核有着紧密联系，通过对内核层面的分析，可以定位到问题的根因。在后续遇到类似问题时，可以多从内核的角度进行考虑。
本文由『UCloud内核团队』原创，作者：曾福振。
未经允许不得私自转载，比心~
