今天一位同學給我打電話，說是重啓了客戶機房裏的一臺服務器A，重啓之後此臺服務器不能與B服務器通信了，要命的是A臺服務器上有關鍵數據需要與B服務器進行通信交互。客戶大發雷霆，同學的老闆也發火一再催促要儘快完工此次項目把錢收回來，做爲項目經理的同學陷入到了嚴重的焦慮當中，一方面因爲耽誤了客戶的業務感到愧疚，更一方面害怕公司的名譽受損，影響接下來的合作。這位同學已經一天一夜沒有休息了，他們公司的工程師也來了兩位依然沒有查到原因，無奈下向我求助，我能體會到這位同學進退兩難的境地，透過電話能感受到他低落的情緒，不親身經歷的人永遠無法體會這種感覺。我決定試一試幫他解決。
問題聽起來並不複雜，就是A服務器因重啓之後無法連接WEB服務器了，於是我收集了A服務器的網絡信息，如下：
[root@A~]# ifconfig | egrep "HWaddr|inet addr" eth0 Link encap:Ethernet HWaddr 00:0C:29:EC:9C:70 inet addr:192.168.80.124 Bcast:192.168.80.255 Mask:255.255.255.0 eth1 Link encap:Ethernet HWaddr 00:0C:29:EC:9C:84 inet addr:192.168.90.31 Bcast:192.168.90.255 Mask:255.255.255.0 eth2 Link encap:Ethernet HWaddr 00:0C:29:EC:9C:7A inet addr:192.168.100.31 Bcast:192.168.100.255 Mask:255.255.255.0 inet addr:127.0.0.1 Mask:255.0.0.0 [root@A ~]# route | grep default default 192.168.80.254 0.0.0.0 UG 0 0 0 eth0
而B服務器只有一個IP地址，沒有網關，地址如下：
[root@B~]# ifconfig | grep "inet addr" inet addr:192.168.10.9 Bcast:192.168.10.255 Mask:255.255.255.0
在這個環境當中，A服務器的三個網卡都與B服務器的網卡不在同一個網段，正常情況下，如果A想與B進行通信必須先將數據包交付給網關（192.168.80.254）進行轉發，於是我在A服務器ping了一下網關，發現A服務器與網關是可以通的，但無法與B通信，請求一直是超時，難道是網關沒有把包給轉發出去？或者是ICMP-request包到達了B服務器之後被iptables的INPUT鏈給DROP掉了，亦或者是ICMP-replay包到達了B服務器之後被iptables的OUTPUT鏈給DROP掉了？造成這個現象的原因有好多，我又不在現場，能排查的地方實在有限，我感覺自己已經走進了死衚衕，難道這次幫忙要以失敗告終？我不甘心。
在屏幕前面發呆了一會兒，我拿出A4紙，把造成這個現象所有的、我能想到的原因全部列了出來，列出來之後我發現我所列出的原因都是集中在數據包離開A服務器之後所經過的節點設備和B服務器上，卻沒有列出A服務器本身的原因，這時大腦當中忽然莫名奇妙的“蹦”出來一句話與這事不相干的話：“行有不得，反求諸已”，我好像抓住了什麼！我有種強烈的預感，問題就是出在這裏，A服務器與網關的通信已經能確認沒問題，但是A服務器與B服務器通信的數據包真的從A服務器正常發出去了嗎？這個我不確定，怎樣才能驗證一下呢？真是一波三折，正當發愁時，看到任務欄上的wireshark軟件，對呀！通過wireshark可以確認A服務器與B服務器通信情況，趕緊試一下。
於是我在A服務器ping B服務器時，在A服務器的三個網卡都抓了包，結果發現eth0網卡竟然一個ICMP包都沒有發，這不應該，A服務器與B服務器通信時，要通過eth0網卡才能將數據包交給網關，因爲A的eth0與網關是處在同一個子網，但是現在卻一個包都沒有。我又打開在eth1網卡上抓的包，結果驚訝的發現竟然有查找B服務器的ARP廣播包！！！如下所示：
這說明什麼問題呢？這說明A上存在一個符合192.168.10.9的路由表項，使得A通過eth1直接與B通信，而沒有匹配到默認路由。我趕緊一條條的仔細檢查路由表，果然發現有這麼一條！如下所示：
[root@A ~]# route -n | egrep "Dest|192.168.10.0" Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
因爲192.168.10.9默認也屬於192.168.10.9/24表項，所以默認就會走這條路由，而不同子網所配置的VLAN也不同，所以這些ARP請求包根本無法到達B服務器，PING包就更不用說了，我讓同學將這條路由刪除之後A服務器就與B服務器恢復通信了，同學和我都如釋重負，高興的不得了，同學說是回來一定要請我吃飯，我當然欣然答應了。我得到了同學的感謝，還得到了自己的認可，心中充滿了歡喜，真的像是打贏了一場硬仗，但我知道，我得到的遠不止這些……
同學知道了原因之後，確定這次事故錯不在他，便理直氣壯的質問客戶：爲什麼A服務器重啓之後多了這條莫名其妙的路由呢？根據客戶回憶，他們以前的確配置過該條路由，後來刪除了，這個刪除僅是刪除內存裏面的路由條目，而配置文件的路由條目依然存在，這次重啓服務器，恰好給了服務器重讀配置文件的機會，所以這條路由又出來了。
我們從這個案例當中可以學到什麼呢？最直接的啓動就是拿上簡歷，投奔甲方去，這樣就在搞砸系統的時候，理直氣壯要求乙方解決了。假如你依然還想繼續當己方的話，那麼就必須要好好學習wireshark了，因爲wireshark實乃網絡工程師居家必備的“甩鍋利器”。再有經驗的工程師也有犯迷糊的時候，而whireshar從來不會，它隨時隨地都能告訴你真相，不偏不倚。