對那些整天喊着“玩大的，玩狠的”口號的人來說，我下面要說的這點事兒，根本就不算事兒。所以，如果你正好喜歡喊口號，就不要往下看了，因為我要講述的，你可能不感興趣，也可能看不懂。
今天，是我加入I公司3個多月以來最有成就感的一天，因為打贏了一個硬仗。1個多月以前，我所在的項目小組給我分配了一個bug, 該bug可簡單描述為：兩張Intel 82599的萬兆網卡，通過光纖背靠背連接后，彼此ping不通。從接受任務到今天，一共持續了33天，其間多次被各種雜事兒各種突發任務所打斷，但總的投入時間累計起來也至少有8個工作日。直到今天，我才真正定位了這個bug的root cause(I公司稱之為“根因” Orz)，真是“山重水復疑無路，驀然回首，那人卻在燈火闌珊處”。 既然玩不了大的，也玩不了狠的，咱就玩點實在的吧。
1. 問題概述
應用結點Ann和存儲結點Ben上各有一張Intel 82599萬兆網卡（ixgbe), 網卡與網卡之間使用光纖背靠背連接。在Ann和Ben上都給網卡的Interface配置上IPv4地址，彼此無法ping通。
[Ann: Application Node]
eth1 90:e2:ba:85:fc:b8 192.168.53.100/24
eth2 90:e2:ba:85:fc:b9 192.168.54.100/24
[Ben: Storage Node]
eth1 90:e2:ba:a9:58:f0 192.168.53.110/24
eth2 90:e2:ba:a9:58:f1 192.168.54.110/24
注意： 存儲結點Ben上神馬工具都沒有，沒有vim, 沒有wireshark, 沒有tcpdump, 總之，你需要的一切工具都沒有。但是，應用結點Ann上什么工具都可以有，只要需要，都可以自由地安裝。
2. 定位過程
- 01 在應用結點Ann上ping -I 192.168.53.100 192.168.53.110; 然后在Ann上使用tcpdump抓包，用wireshark查看，發現arp請求包從Ann發出，但未收到arp響應包； （令人痛苦的是，存儲結點Ben上沒有tcpdump,只能從應用結點Ann上單方面抓包）
- 02 在Ann和Ben上手工配置arp記錄，再ping, 可以相互ping通，說明網卡，光模塊和光纖都沒有問題，排除硬件故障；
- 03 檢查Ann和Ben上的萬兆網卡驅動（ixgbe.ko), 發現Ann上的網卡驅動版本比較低，於是升級Ann的操作系統，與Ben保持一致，再ping, 還是ping不通；
- 04 檢查Ann和Ben上有沒有SELinux設置，Ben沒有，Ann有；於是關閉Ann上的SELinux設置，再ping, 還是ping不通；
- 05 檢查Ann和Ben上有沒有防火牆firewalld, Ben沒有，Ann有；於是關閉Ann上的firewall設置並重啟，再ping, 還是ping不通；
- 06 檢查Ann和Ben上有沒有iptables服務，Ben沒有，Ann也沒有；
- 07 在Ann上安裝dropwatch, 啟動一個ping -I 192.168.53.100 192.168.53.110; 然后啟動dropwatch, 發現有丟包，而且是與arp錯誤密切相關，但是丟包原因不清楚；
- 08 坐下來研讀ARP協議（RFC826） （耗時1個周末);
- 09 使用arping從Ben上向Ann發出arping, 成功；再使用arping從Ann上向Ben發出arping, 失敗；好了，於是可以90%確定為是存儲結點Ben的問題；
- 10 在存儲結點Ben上查看arptables服務，發現正在運行，再使用arptables -L查看規則，發現了4條DROP的規則，與Ben上的82599網卡對應的網絡接口正好對應，於是99%確定為存儲結點Ben的問題;
- 11 在存儲結點Ben上搜索源代碼，找到root cause，原來是存儲軟件在啟動的時候，發現82599網卡對應的網絡接口（eth1, eth2）並沒有配置IPv4地址，於是設置ARP規則將eth1, eth2的inbound和outbound的ARP包都通通drop掉，因此，從應用結點Ann上發出arp請求廣播包，沒有收到arp響應包就很好理解了 -- Ann發出去的arp請求包之所以石沉大海，是因為被Ben設置的ARP規則給drop掉了。
說明：
- 01 其實離root cause很近了，但是當時不知道使用arping進行錯誤定位, 所以與成功擦肩而過；
- 02 排除了可能存在的硬件故障問題，為完全轉向查找軟件問題給出了理論依據；
- 03-06 其實是病急亂投醫，屬於神農嘗百草的做法，對最后成功定位幫助不大；
- 07 將注意力重新吸引到定位可能存在的ARP問題，本質上是回歸到01， 功不可沒；
- 08 所謂“磨刀不誤砍柴工”，讓我堅定了在01時候所做的猜測，一定是ARP問題。相對於實踐，理論基礎更重要；
- 09 “差異化”是找出問題所在的關鍵，100次沒有差異的ping操作抵不過1次有差異的arping操作, 成功就在眼前；
- 10 進一步求證，找出ARP包被DROP的證據，到達成功的彼岸只有一步之遙，但很多時候，這一步很難跨越；
- 11 沒有代碼證據，所有的猜測只是猜測而已，“Read The F*cking Source Code”才是王道。
3. 總結陳詞
對於枯燥乏味的bugfix來說，最艱難的部分就是錯誤定位。那些只會搞硬件不會搞軟件擅長於喊口號拉標語的人，永遠也無法體會其中的艱辛和快樂。這就好比踢足球，進球是最讓人振奮的事情，但在進球之前，大多是冗長艱難的奔跑和拼搶。成功定位上面所述問題的root cause，對我來說意義重大(滿滿的成就感)，因為完全是從零開始摸索，在黑暗中前行，沒有任何既有的經驗可用。這需要堅韌不拔，需要百折不撓，非智力因素才是到達成功彼岸的關鍵。 當然，能找到最后的root cause, 也離不開同事和朋友的幫助與點化，在此對Zrf, Lmx, Yyg三位老師和Wjq兄弟表示由衷的感謝！
后記： 找到bug的root cause后，最后的解決方案異常簡單，一行代碼都沒有改，因為不用做任何修改。原因是通過GUI管理界面，給存儲結點Ben上的82599網卡的網絡接口配置上IPv4地址后，存儲軟件系統會自動修改arptables里的ARP規則，而且修改后的ARP規則正是我們所期望的。那么問題就來了，當初這個bug是怎么報出來滴？遺憾的是，bug filer並沒有把具體的重現步驟記錄在案，那就沒有辦法回溯了。因此，對測試工程師來說，不懂具體的技術不要緊，但是把發現bug的具體步驟記錄清楚無疑是最重要的基本功。於此同時，對開發工程師來說，拿到一個bug，搞清楚bug的重現步驟則是最關鍵的，不然很可能是在浪費時間做艱難的長途跋涉。這也給我的職業生涯上了很重要的一課，發人深省，值得好好反思和引以為鑒。