巧用分層模型排障
20世紀80年代中期，各大公司逐漸感受到了盲目地大規模擴展網絡帶來的后果，使用不同標準的網絡之間很難通信，于是他們意識到必須摒棄先前的專用網絡系統，制定一種網絡之間連接的標準。
1984年發布的OSI-RM開放體系模型（Open System Interconnection - Reference Model），它為各個廠商提供了一套標準，確保全世界各公司提出的不同類型網絡技術之間具有良好兼容性和互操作性。
開放系統互連參考模型（Open System Interconnection - Reference Model）中的關鍵字“開放”與“互連”就是為解決這個問題。“開放”表示能使任何兩個遵守參考模型和有關標準的系統進行連接。“互連”是指將不同的系統互相連接起來，以達到相互交換信息、共享資源、分布應用和分布處理的目的。
中鐵集團某分公司進行了一次網絡改造，分公司的網絡用戶報告說其中有一臺客戶端在調整辦公室后無法訪問總部服務器。由于總公司到分公司的路途遙遠，所以采用了電話支持和網絡設備遠程排錯的方法，最終排除了故障。
選擇排查故障的思路
OSI模型并不只是一項“死”知識，而是指導網絡組建和故障排除的一種原則。利用OSI模型排除網絡錯誤工作中有3種方法可以使用。
（1）從下至上的方法：從OSI模型底端開始，順序向上。
（2）從上至下的方法：從OSI模型頂端開始，順序往下。
（3）分而治之的方法：從OSI模型特定層開始，確定問題是在該層、還是上層或下層。
由于分公司的其他客戶端都能訪問到總部的服務器，而只有一個客戶端無法訪問，所以應該確認服務器的應用程序是沒有問題的，所以可以采用“從下至上”的方法排除網絡故障，即從物理層開始。由于是遠程管理，在處理此次網絡故障時總部工程師并沒有到現場，但最終排除了故障。他們并不是通過經驗直接判斷問題的癥結之處，而是根據OSI的7層模型，從“物理層”開始排除問題的，當確保網卡和網絡連接沒有問題的時候，再“上升一層”排除問題，直至找到了最終答案。
下面排除故障中用到了一些命令，現在你可能還不了解它們，在學習完成本書后面的一些網絡設置配置命令之后，你就會發現原來這些工程師的操作也不是很神奇。
故障解決思路與步驟
客戶端無法訪問網絡的情況在企業網絡故障中應該是最常見的一種，但很多管理員在排查故障的時候，不知道從何處入手。并將這臺主機搬回到原信息點后能夠訪問網絡，這就使總部工程師首先懷疑到連接這臺客戶端的物理層鏈路出現了問題。
1．物理層檢查
工程師首先要求用戶檢查網絡客戶端網絡的物理連接是否正常，查看網線是否與墻上端口和設備相連，連接點是否牢靠等。用戶反饋這些連接部件都是正常，所以工程師決定讓用戶查看交換機端口的工作狀態。
由于分公司采用了標準的布線環境，交換機管理良好，有完備的《網絡記錄文檔》。因此，總部查找到這位用戶使用的墻上插座端口號為A201，而且知道A201號口與交換機2號口相連。
如果工程師在現場就可查看交換機端口的指示燈狀態是否正常，但現在是不可能了。所以只能遠程登錄到這臺交換機，利用show ip interface brief 命令查看其端口是否工作正常。
一般持續綠色代表鏈路正常運行，如果閃爍綠色則表明正在發送或者接收數據。
3750-24#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1/0/1 unassigned YES unset up up
GigabitEthernet1/0/2 unassigned YES unset up up
GigabitEthernet1/0/3 unassigned YES unset up up
GigabitEthernet1/0/4 unassigned YES unset up up
GigabitEthernet1/0/5 unassigned YES unset down down
從這條命令的執行結果中看到：GigabitEthernet1/0/2狀態（Status）和協議（Protocol）工作都是up狀態，這證明此終端的線纜連接到交換機是正常的，初步可以排除是物理層的問題。
2．檢查數據鏈路層
既然有連接，說明網絡是通的，發生物理層錯誤的可能性很小，所以可以將故障排查上升一層到數據鏈路層。因此交換機對數據包的轉發是建立在MAC地址（物理地址）基礎之上的，對于IP網絡協議來說，它是透明的，即交換機在轉發數據包時，不知道也無須知道信源機和信宿機的IP地址，只需其物理地址，即MAC地址。
是不是我們過分相信《網絡記錄文檔》中的接口信息了，交換機的這個接口沒有真正連接到這臺客戶端，而是連接到其他的客戶端呢？此時，可以利用第二層信息的排查來確定這個錯誤是否存在。第二層的關鍵是MAC地址，可以對照交換機接口上的MAC地址和客戶端的MAC地址是否相同，這樣也能排除是不是當初施工時《網絡記錄文檔》出現了問題。使用show mac address-table interface gigabitEthernet 1/0/2 命令可以顯示連接此接口計算機的MAC地址信息。
3750-24#show mac address-table interface gigabitEthernet 1/0/2
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
10 0014.2275.57ac DYNAMIC Gi1/0/2
Total Mac Addresses for this criterion: 1
此時在客戶端上查看本機的MAC地址，如果不匹配則說明交換機上的接口并不是真的連接了這臺客戶端。工程師讓用戶在客戶端上執行IPCONFIG /ALL命令，然后將MAC地址和上面的進行對比，發現MAC地址是相同的。可能在數據鏈路層還有其他的錯誤，但至少“網絡記錄文檔”并沒有欺騙我們，交換機端口和客戶端主機是對應的。
3．檢查網絡層
接下來查看第三層。在PC上使用IPCONFIG /ALL命令進行檢查，輸出結果顯示如下：
C:\Documents and Settings\Administrator>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : officetm1
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : gwz.edu
Ethernet adapter 本地連接:
Connection-specific DNS Suffix . : zt2.cuchina.com.cn
Description . . . . . . . . . . . : Realtek RTL8168/8111 PCI-E Gigabit Ethernet NIC
Physical Address. . . . . . . . . : 00-14-22-75-57-AC
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.10.2.41
Subnet Mask . . . . . . . . . . . : 255.255.255.192
Default Gateway . . . . . . . . . : 10.10.2.62
DHCP Server . . . . . . . . . . . : 10.88.56.1
DNS Servers . . . . . . . . . . . : 10.88.56.1
Primary WINS Server . . . . . . . : 10.88.56.1
這里，可以看到PC有IP地址，但是這地址對嗎？這臺PC通過DHCP獲得10.88.x.x范圍內的地址，但是現在地址卻是10.10.x.x。
終于發現了問題，DHCP服務器分發的IP地址不屬于子網。這種問題多出現在PC從某個子網挪到另一個子網時，PC依然請求舊的IP地址就產生了問題，由于這臺主機從另外的辦公室挪過來才出現的問題，因此可以斷定問題出現在網絡層。
管理員嘗試這樣解決問題，讓PC的網絡接口租用的IP地址重新交付給DHCP服務器（即歸還IP地址）。使用IPCONFIG /RELEASE，然后使用IPCONFIG /RENEW命令， PC就會獲得正確的IP地址，所有的網絡應用就都可以使用了。
【編輯推薦】
