耗时半个月排查问题的小结

这次是最近遇到的比较 tricky 问题的升级版本,当然他们二者没什么关系了,基本上我这半个月的时间都耗在这上面了,尝试了各种手法,包括 systemtap, dropwatch(感谢 @bitstream 的帮忙),不管如何,最终还是在我们 director 的帮助下一起解决了,虽然最后的 root cause 不是什么很高深的理论,懂点 TCP/IP 的应该都能理解,但是整个排查的过程我认为还是很值得参考的。本次 debug 仅仅涉及到 IP 层以下的内容,跟上层应用没有什么关系,对 IP、MAC 等数字不敏感的建议不要读了,即使要读也务必理清楚了再往下,下面会涉及大量的 VLAN IP 段,如果想知道最终的结果,直接跳到最后就好了。

在升级完我们所有的 10G 网络之后,出现了如下的现象。
1. 所有只配有一个内网的机器没有任何的问题,通过默认的 GW 可以访问其他 VLAN 机器,比如这个,默认都通过 10.118.10.250 出去:
[email protected]:~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.118.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         10.118.10.250    0.0.0.0         UG    0      0        0 eth1

2. 所有配有公网的服务器到一部分内网的 VLAN 不通而到另外一部分内网 VLAN 则是通的:
[email protected]:~$ ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 78:2b:cb:53:d6:55 brd ff:ff:ff:ff:ff:ff
    inet 111.111.111.230/26 brd 111.111.111.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 78:2b:cb:53:d6:56 brd ff:ff:ff:ff:ff:ff
    inet 10.118.10.20/24 brd 10.118.10.255 scope global eth1

[email protected]:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
111.111.111.192 0.0.0.0         255.255.255.192 U     0      0        0 eth0
10.118.20.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.118.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.111.0.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         111.111.111.193 0.0.0.0         UG    100    0        0 eth0

[email protected]:~# ping 10.118.20.1
PING 10.118.20.1 (10.118.20.1) 56(84) bytes of data.
64 bytes from 10.118.20.1: icmp_seq=1 ttl=63 time=43.6 ms
64 bytes from 10.118.20.1: icmp_seq=2 ttl=63 time=30.4 ms
^C
— 10.118.20.1 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 30.453/37.054/43.655/6.601 ms

[email protected]:~# ping 10.111.0.1
PING 10.111.0.1 (10.111.0.1) 56(84) bytes of data.
From 10.118.10.21 icmp_seq=2 Destination Host Unreachable
From 10.118.10.21 icmp_seq=3 Destination Host Unreachable
From 10.118.10.21 icmp_seq=4 Destination Host Unreachable
^C
— 10.111.0.1 ping statistics —
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4008ms
, pipe 3

当时我在现场发现了这个问题,看路由表,写的好像有些问题。抱着试一试的态度,反正也是不通,死马当活马医,找了一台有问题的机器把之前的:
[email protected]:~# route add -net 10.111.0.0 netmask 255.255.255.0 eth1
改成了下面的这种方式:
[email protected]:~# route add -net 10.111.0.0 netmask 255.255.255.0 gw 10.118.10.250

「神奇」的是,竟然 work 了。现场任务繁重,没有那么时间仔细考虑,恢复系统要紧,我很快把我们剩余的出现问题的机器都按照这种方式修改了 route。至此,线上的机器总算能恢复正常了,虽然当时不清楚为什么。回来之后,当然要做详细分析了。为了复现当时的问题,我又找了几台机器。

Continue reading