有人說網絡工程師是整個IT行業中最可能受氣的工種。其實這一點捷個本人也不否認，因爲你管理的網絡，是所有服務器、終端相互通信的基礎。如果有電腦上網不正常，或者是訪問網絡中的某一臺服務器出現異常現象，所以別人肯定首先就會找你網絡的問題。哎！沒辦法，誰讓你管理的是TCP/IP底層的東西呢？
不過，當故障來襲的時候，作爲網絡工程師的你，也要能夠清楚的判斷這個問題到底是不是出現在網絡設備上，並能拿出強有力的證據，有理有節地來反駁那些“氣勢洶洶”的人們。這到底應該怎麼做呢？捷哥來爲大家講一個案例：
趙小志是一名在某壟斷企業駐場工作的網絡工程師，日常的工作是維護數據中心的防火牆和核心、匯聚交換機。因爲DMZ區域的Cisco 6509E交換機投運時間太久，設備老化了，甲方要求將Cisco 6509E更換爲H3C 9512。週四的晚上更換設備的時候一切順利，並且在更換完成匯聚層設備以後測試DMZ區域的所有業務都一切正常，所以趙小志就收工回家了。
時間到了下週一，趙小志上班的時候，就收到了來自甲方負責人的故障工單，內容是：DMZ區域對外的兩臺FTP服務器（內網IP地址是172.18.130.15、172.18.130.16）上傳大量小文件的時候出現了丟文件的現象，請相關網絡工程師負責檢查網絡的問題。
爲什麼是網絡的問題呢？FTP服務器的管理員給出的理由如下：“那兩臺FTP服務器是每個週一接收一次來自營銷部門的文件提交，之前一直都是正常的。在週四的時候DMZ區域更換過不同型號的匯聚交換機，在換了匯聚層設備以後，傳文件就開始丟數據了。”所以那邊管理員就猜測是：“更換過的H3C 9512交換機與之前的Cisco 6509E有兼容問題導致了傳文件丟失。”還把這個事情直接捅到了領導那裏去了。
領導給出的指令是：“今晚再進行一次上傳測試，如果還是丟文件，那就把之間做的割接全部回退！”
“回退？！”把兩臺H3C 9512再換回Cisco 6509E？先不說這兩臺設備有多重，再派人去換設備有多麼費時費力。就怕你再歷經“千辛萬苦”把設備換回來，那邊FTP的訪問還是不正常又怎麼辦？另外，說H3C 9512與Cisco 6509E存在“不兼容”的那位，到底是哪裏不兼容呢？他也說不上個啷哩咯啷，只是說：“憑感覺的！爲什麼換之前沒事換之後有事呢？還肯定是你換這個設備有問題啊？”
得了！既然對方管理員這麼說話，趙小志覺得，是該拿出點證據出來了！一來，不能再到機房裏面去再擡一次這些沉重的設備；二來，對方FTP管理員絲毫沒有查看自己服務器的想法，一口咬定是網絡的問題，必須給他點顏色看看。那麼，如何證明網絡沒問題呢？
首先，趙小志找來了DMZ區域的拓撲圖：
如圖所示：IP地址爲172.18.130.15的FTP Server連接在H3C 9512交換機的Gi 3/0/37號接口上；IP地址爲172.18.130.16的FTP Server連接在H3C 9512交換機的Gi 3/0/43號接口上。另外，從其他區域想要訪問到這兩臺FTP server的話，還必須穿過DMZ區域的防火牆。
首先，趙小志請對方管理員在一臺營銷區域的前置機上使用Telnet命令去測試172.18.130.15和172.18.130.16的TCP-20、TCP-21、TCP-22端口。用Telnet命令去測試端口，如果能夠檢查出前置機訪問這兩臺FTP Server的上述端口是正常現象，那麼就可以排除防火牆上ACL策略的問題。
Telnet測試得出的結果如下，從前置機上Telnet測試TCP-20、TCP-21、TCP-22端口一切正常：
YX-Sys-FrontDev> telnet 172.18.130.15 22 Trying 172.18.130.15... Connected to 172.18.130.15. Escape character is '^]'. SSH-1.99-OpenSSH_4.4 YX-Sys-FrontDev> telnet 172.18.130.15 21 Trying 172.18.130.15... Connected to 172.18.130.15. Escape character is '^]'. YX-Sys-FrontDev> telnet 172.18.130.15 20 Trying 172.18.130.15... Connected to 172.18.130.15. Escape character is '^]'.
另外，趙小志也提供了防火牆上關於這兩臺FTP Server的ACL策略配置，進一步說明了不可能是防火牆導致的丟包現象。
set security policies from-zone untrust to-zone trust policy u-t-65 match source-address 172.18.125.0/24 set security policies from-zone untrust to-zone trust policy u-t-65 match destination-address 172.18.130.15/32 set security policies from-zone untrust to-zone trust policy u-t-65 match destination-address 172.18.130.16/32 set security policies from-zone untrust to-zone trust policy u-t-65 match application tcp-20 set security policies from-zone untrust to-zone trust policy u-t-65 match application tcp-21 set security policies from-zone untrust to-zone trust policy u-t-65 match application tcp-22 set security policies from-zone untrust to-zone trust policy u-t-65 then permit
趙小志認爲：“如果能夠使用Telnet命令去測試目標端口一切正常的話，那就肯定不是防火牆上面ACL策略寫錯的問題了。如果真的是防火牆上面ACL寫錯的問題，那應該一開始就不通，不可能是通一陣子就丟包啊。”所以，防火牆的問題排除。
然後再檢查交換機上的問題。首先，趙小志先登錄到了營銷區域的匯聚層交換機上，對172.18.130.15和172.18.130.16進行了一次長ping測試。所謂長Ping，就是一次性讓它ping 100次以上，這個可以初步判斷網絡狀態是否穩定。
<DC-YX-7503-1>ping -c 100 172.18.130.15 PING 127.0.0.1: 56 data bytes, press CTRL_C to break …… Reply from 172.18.130.15: bytes=56 Sequence=17 ttl=252 time=2 ms Reply from 172.18.130.15: bytes=56 Sequence=18 ttl=252 time=2 ms Reply from 172.18.130.15: bytes=56 Sequence=19 ttl=252 time=1 ms Reply from 172.18.130.15: bytes=56 Sequence=20 ttl=252 time=1 ms Reply from 172.18.130.15: bytes=56 Sequence=21 ttl=252 time=2 ms Reply from 172.18.130.15: bytes=56 Sequence=22 ttl=252 time=1 ms …… --- 172.18.130.15 ping statistics --- 100 packet(s) transmitted 100 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/4/7 ms <DC-YX-7503-1>ping -c 100 172.18.130.16 PING 172.18.130.16: 56 data bytes, press CTRL_C to break …… Reply from 172.18.130.16: bytes=56 Sequence=17 ttl=252 time=2 ms Reply from 172.18.130.16: bytes=56 Sequence=18 ttl=252 time=2 ms Reply from 172.18.130.16: bytes=56 Sequence=19 ttl=252 time=1 ms Reply from 172.18.130.16: bytes=56 Sequence=20 ttl=252 time=1 ms Reply from 172.18.130.16: bytes=56 Sequence=21 ttl=252 time=2 ms Reply from 172.18.130.16: bytes=56 Sequence=22 ttl=252 time=1 ms …… --- 172.18.130.16 ping statistics --- 100 packet(s) transmitted 100 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/3/9 ms
發送了100個ping包的結論是：從營銷區域的交換機上ping位於DMZ區域的兩臺FTP Server，所有的包都沒有丟，而且平均延遲爲4毫秒、3毫秒；最大延遲也不過9毫秒。既然ping都沒問題，那麼上傳不了文件是怎麼個說法呢？
最後，趙小志查看了DMZ區域交換機上Gi 3/0/37和Gi 3/0/43的CRC校驗值，也沒發現有任何CRC校驗失敗的情況。這個時候已經完全能夠說明網絡環境完全沒有丟包的現象發生了。
<DC-DMZ-9512-1>dis int gi 3/0/37 GigabitEthernet3/0/37 current state: UP IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: c4ca-d92e-2f71 …… Last 300 seconds input: 5 packets/sec 907 bytes/sec 0% Last 300 seconds output: 108 packets/sec 10184 bytes/sec 0% Input (total): 44806386 packets, 6003517217 bytes 6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses Input (normal): 44806386 packets, - bytes 6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses Input: 0 input errors, 0 runts, 0 giants, 0 throttles 0 CRC, 0 frame, - overruns, 0 aborts - ignored, - parity errors <DC-DMZ-9512-1>dis int gi 3/0/43 GigabitEthernet3/0/43 current state: UP IP Packet Frame Type: PKTFMT_ETHNT_2, Hardware Address: c4ca-d92e-2f71 …… Last 300 seconds input: 5 packets/sec 907 bytes/sec 0% Last 300 seconds output: 108 packets/sec 10184 bytes/sec 0% Input (total): 44806386 packets, 6003517217 bytes 6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses Input (normal): 44806386 packets, - bytes 6349308 unicasts, 11862178 broadcasts, 26594900 multicasts, 0 pauses Input: 0 input errors, 0 runts, 0 giants, 0 throttles 0 CRC, 0 frame, - overruns, 0 aborts - ignored, - parity errors
此處，CRC校驗值爲0，說明在這兩個接口上沒有一個數據幀損壞，換句話說就是沒有在這兩個接口上丟過一個數據包，網線的傳輸質量也是良好的。
於是，拿着這些證據，趙小志就真的可以理直氣壯的去找FTP服務器的管理員了，請他從服務器自身的故障查起。
最後呢，按照趙小志提供的思路，在172.18.130.15和172.18.130.16兩臺FTP服務器上相互傳送10000個小文件，因爲這兩臺服務器本身就在一個網段內，如果它們之間互傳都有問題，那肯定就是服務器自身的問題了。果然，從172.18.130.16往172.18.130.15上傳文件的時候出現了丟失文件的現象……經過檢查，發現在FTP服務器上，這個FTP服務端軟件不是官方提供的VSFTP，而是某個公司自行編寫的。因爲軟件BUG導致的文件上傳丟失。
那麼我們換一種情況來看，當時領導和對方的管理員氣勢洶洶的，如果趙小志的經驗沒那麼豐富，那是不是就該蒙受“不白之冤”啦？所以，作爲網絡工程師的你，在故障出現的時候，既不能夠大包大攬，把責任全部攬到自己身上，當然也不能夠不管不問。這麼給你說吧，你可以通過以下幾個方式來證明自己管理的網絡設備沒有問題。
1、分區域的使用Telnet命令、ping命令去檢測
你爲某個系統管理員在防火牆上做了允許訪問的ACL，但是他說訪問不通
假設你爲他做的ACL編號爲a，源IP地址爲IP-s，目標地址爲IP-d，目標端口爲Port-p。那麼你首先要檢查你的防火牆上，編號a之前的ACL有沒有關於IP-s、IP-d、Port-p且執行動作爲deny的策略，如果沒有執行動作爲deny的策略，且你寫的ACL也沒犯“低級錯誤”，那就肯定不是這個防火牆的問題。
如何給他證明呢？看圖吧：
這裏需要說明一下。步驟一里面，如果你在防火牆上使用Telnet命令測試通了，說明是同一個安全區域內訪問（不受防火牆ACL控制）是正常的，則肯定是防火牆的問題。如果在防火牆上使用Telnet命令測試不通的話，那進入到第二步操作，因爲你還需要排除Trust區域內交換機的問題啊。
步驟二里面，如果Trust區域內的交換機不支持Telnet測試命令的話，則可以在Trust區域中儘量找一個同網段的服務器去測試。
2、先讓對方證明他沒問題再檢查網絡
如果有系統工程師告訴你說：10.11.12.13服務器的8080端口訪問不了，請你檢查網絡。那麼這個時候你先別急着答應他，你先讓他證明了他的系統沒問題以後你再檢查。你可以按照這個步驟讓他檢查：
（1）如果對方可以遠程登錄到他管理的10.11.12.13的服務器系統，你可以先讓他在服務器上嘗試telnet 127.0.0.1 8080，先從本機上排除問題。如果使用127.0.0.1都訪問不了，除非那臺服務器上有限制使用127.0.0.1作爲目標地址（一般來說大部分系統管理員都不會這麼做），否則就是他那臺服務器的問題。
（2）如果使用telnet 127.0.0.1 8080訪問成功，則你可以讓他找一臺同一個網段的終端（一般不可能沒有）使用telnet 10.11.12.13 8080去測試，如果測試不通那你就別管網絡了，一定是他系統自身的問題。如果他能測試通，或者他能拿出配置文件告訴你說服務器上沒有針對源地址做限制，那你就真的要檢查下網絡了。
3、ping都不通的情況
實際上，不管是從源到目標要不要經過防火牆，“ping不通”這種情況必須得引起足夠的重視。大多數情況下，ping不通多半都是網絡出的問題，但也有特例，比如：
172.18.139.143/24到172.18.164.253/24發現ping不通。你知道了這是兩個不同網段的地址，但你也別先急着去查路由（穿越了骨幹網的情形除外）。首先你得知道172.18.164.253的網關是多少吧，比如說是172.18.164.254/24，那你就ping 172.18.164.254唄。如果能ping通網關，但是ping不通目標地址，也還暫時不能排除掉網絡問題哦！怎麼辦？
那你就在網關所在的設備上查，查什麼呢？當然是ARP信息、MAC地址表、接口CRC校驗這些東西啊！ 如果是ARP表項、MAC表項、接口CRC都沒問題的話，那你的網絡也就沒問題了。
如果是同網段的都ping不通，你就直接檢查ARP表項、MAC表項、接口CRC，都沒問題的話，那也請他別找你了。