一些Linux中常用操作指令及大鲨鱼的使用（二）：ping的应用

客户一不小心重启了服务器A，然后就导致其再也无法与服务器B通信了。

考虑到起因是因为A的重启导致的，故优先收集他的网络配置，见图1.

服务器 B 的网络配置则简单很多，只有一个 IP 地址 192.168.182.131，子网掩码也是 255.255.255.0。

一般情况下，像 A 这类多 IP 的服务器是这样配路由的：假如自身有一个 IP和对方在同一子网，就从这个 IP 直接发包给对方。假如没有一个 IP 和对方同子网，就走默认网关。在这个环境中，A 的 3 个 IP 显然都与 B 属于不同子网，那就应该走默认网关了。

此时从A上ping了一下网关，结果却是通的。难道是因为网关没有把包转发出去？或者是 ping 请求已经被转发到 B 了，但 ping 回复在路上丢失？

于是分别在eth0、eth1、和 eth2 上抓了包。最先查看的是连接默认网关的 eth0，出乎意料的是，上面竟然一个相关网络包都没有。而在 eth1 上抓的包却是图 2 的表现: A 正通过 ARP 广播查找 B（192.168.182.131）的 MAC 地址，试图绕过默认网关直接与 B 通信。

通过分析图二的数据，可以说明在A上存在一项符合 192.168.182.131 的路由，促使 A 通过 eth1 直接与
B 通信。于是逐项查看路由表，发现果然有这么一项（见图3）：

因为 192.168.182.131 属于 192.168.182.0/255.255.255.0，所以就会走这条路由。由于不同子网所配的 VLAN 也不同，所以这些 ARP 请求根本到达不了 B。ping包就更不用说了，它从来就没发出来过。赶紧删除了这条路由，两台服务器的通信也随即恢复。

你也许会问，为什么不从一开始就仔细检查路由表呢？这样就不至于走错胡同，连抓包和 Wireshark 都省了。我当时也是这样反省的，但现实中要做到并不容易。且不说一开始并没有怀疑到路由表，就算怀疑了也不一定能看出问题来。在这个案例中，系统管理员和现场工程师都检查过路由表，但无一例外地忽略了出问题的一项。这是因为真实环境中的路由表有很多项，在紧张的环境下难以注意到多出了异常的一项。而且子网掩码也不是 255.255.255.0 那么直观。假如本文所用的 IP 保持不变，但子网掩码变成 255.255.248.0，路由表就成了图 4 所示的样子。

在这个输出中，难以一眼注意到 192.168.176.0 就适用于目标地址 192.168.182.131，至少对我来说是这样的。