目前用的集群是在应用层实现的，主要功能是实现在机器之间互转请求。今天在部署的时候，发现请求没有在节点之间互转，相同的请求发送一次后miss，第二次发送的时候还是miss。正常来说，第一次miss后会在集群内缓存一份，之后再有关于这个文件的请求不管发送到哪个机器都应该是hit的。
集群之间的探活用的是组播消息，出现这种问题肯定是因为接收组播报文出了问题。之前用的时候都没有问题，所以先从环境入手来查找问题。
先使用tcpdump抓包，看是否能够接收到组播报文。抓包的结果是，机器上接收到其他节点发送过来的组播报文。换了一台机器，结果也一样。现在是有数据包，下一步就是要找到数据包为什么被丢弃。之前遇到过一次是因为网关配置的不一致导致的。这次检查了几台机器，并且请运维的同事也帮忙看了一下，没有发现有啥问题。
接着在机器上安装了dropwatch，看看系统在哪些位置丢弃的数据包，结果如下图所示（这个图是在测试环境中重现问题后截的，结果是一样的）：
从上图看来，比较靠谱的位置是在ip_rcv_finish()中丢包。ip_rcv_finish()中在查找路由缓存失败和数据包IP首部出错时才会丢包。数据包损坏的可能性不大，因此确定是在查找路由缓存失败丢的包。
后面使用"netstat -gn"命令来查看当前网卡上加入的组播组。用这个命令在机器上查看，发现加入的组播地址224.0.1.37绑定在eth0上，而本来要接收组播消息的fd绑定的IP地址是eth1上的地址。觉得应该是这里的问题。
在 上看到，如果在加入组播组时，本地接口地址imr_interface设置的是INADDR_ANY时，选择默认的组播接口，也就是让内核来选择。根据现在的情况来看，内核在选择的时候会选择默认网关使用的设备，我这里使用的就是eth0。如果指定的接口地址的话，就会使用地址所在的网络接口作为组播组使用的网络接口。
现在基本可以确定丢包的原因了。两个机器的eth0和eth1网卡上设置的IP地址是不同网段的，eth0是9段的IP地址，eth1是4段的IP地址。发送组播消息时，使用的是4段的IP地址，所以接收组播消息的机器上数据包由eth1网卡来接收，但是加入组播组的网卡是eth0，所以数据包到达eth1时会查找路由失败，在ip_rcv_finish()中会将数据包丢弃。
找到问题原因，立即修改代码。在加入组播组时，将imr_interface设置为指定的本地IP地址。重新编译，启动后，用“netstat -gn”发现现在组播地址所在的设备和绑定的接口相同，测试没有问题。
为了验证上面的结论，写了一个systemtap脚本，如下所示（比较丑陋，没有封装成函数，海涵）：
%{ #include <linux/skbuff.h> #include <linux/netdevice.h> #include <linux/ip.h> %} global kaddr =0x250100e0 global iph global daddrs, saddrs function ip_rcv_finish_helper :long(arg :long) %{ struct sk_buff *skb = (typeof(skb))THIS - >arg; const struct iphdr *iph = ip_hdr(skb); THIS - >__retvalue = (long)iph; return; %} probe kernel.statement( "ip_rcv@net/ipv4/ip_input.c+12") { iph = ip_rcv_finish_helper($skb); func = probefunc(); saddrs[func] = @cast(iph, "iphdr") - >saddr; daddrs[func] = @cast(iph, "iphdr") - >daddr; } probe kernel.statement( "ip_rcv_finish@net/ipv4/ip_input.c+11") { iph = ip_rcv_finish_helper($skb); func = probefunc(); saddrs[func] = @cast(iph, "iphdr") - >saddr; daddrs[func] = @cast(iph, "iphdr") - >daddr; if ((daddrs[func] == kaddr) && $err) { printf( "err = %d\n", $err); } } probe kernel.statement( "ip_rcv_finish@net/ipv4/ip_input.c+35") { if (daddrs[func] == kaddr) { printf( "The result is unexpected\n"); exit(); } } probe kernel.function( "ip_rcv").return { func = probefunc(); if (daddrs[func] == kaddr) { printf( "Packet from 0x%X to 0x%X is droped in %s, return=%d\n", saddrs[func], daddrs[func], func, $return); } } probe kernel.function( "ip_rcv_finish").return { func = probefunc(); if (daddrs[func] == kaddr) { printf( "Packet from 0x%X to 0x%X is droped in %s, return=%d\n", saddrs[func], daddrs[func], func, $return); } }
输出结果如下所示：
从上图可以看出来，ip_rcv()和ip_rcv_finish()的返回值都是1，即为NET_RX_DROP，表示要丢掉数据包。"ip_rcv_finish@net/ipv4/ip_input.c+35"这个probe点没有任何输出，也就是说获取路由缓存项失败。不过这个错误码比较意外是22，即EINVAL，看了ip_route_input()在获取组播报文的路由缓存项时确实是返回这个错误码。这个输出结果验证了前面的结论。