無需探究有關(guān)該模型的歷史和使用的太多細(xì)節(jié)，讓我們來看一下你可以如何將OSI模型擴展成一個可用于問題隔離的框架。圖4.1顯示了OSI模型的七層結(jié)構(gòu)以及與每一層相關(guān)的一些典型問題。讓我們按照從下到上的順序來討論每一層：
物理層 典型問題包括構(gòu)成網(wǎng)絡(luò)的物理連接的斷裂。斷開的網(wǎng)絡(luò)連接，電纜和連接器問題和由硬件引起的禁止電流在設(shè)備之間的傳送問題都是物理層的一些典型問題。
數(shù)據(jù)鏈路層 我們暫不討論純粹的電學(xué)問題，而將注意力轉(zhuǎn)移到接口本身的配置。數(shù)據(jù)鏈路問題常常和地址解析協(xié)議(ARP)問題有關(guān)，該協(xié)議負(fù)責(zé)將IP地址轉(zhuǎn)換成MAC地址。網(wǎng)絡(luò)設(shè)備之間速率和工作模式的不匹配或者過多的硬件接口錯誤都會引發(fā)這些問題。而設(shè)備操作系統(tǒng)(OS)接口的錯誤配置或者無線連接的干擾同樣會導(dǎo)致數(shù)據(jù)鏈路層出現(xiàn)問題。
網(wǎng)絡(luò)層 我們從網(wǎng)絡(luò)遍歷問題開始說起。網(wǎng)絡(luò)分組無法在從源地址到目的地址的過程中進行正確選路往往會造成網(wǎng)絡(luò)層問題。這可能和不正確的IP尋址或者網(wǎng)絡(luò)中的IP地址復(fù)制有關(guān)。網(wǎng)絡(luò)中的數(shù)據(jù)或者ICMP分組路由問題以及協(xié)議錯誤也有可能導(dǎo)致問題的發(fā)生。在極端情況下，外部攻擊同樣有可能造成網(wǎng)絡(luò)設(shè)備的錯誤從而導(dǎo)致網(wǎng)絡(luò)層出現(xiàn)問題。
傳輸層 傳輸層問題一般出現(xiàn)在以太網(wǎng)中的TCP或者UDP分組上。這些問題可能和過量重傳錯誤或者分組分裂有關(guān)。沒有單獨的一種問題能夠?qū)е戮W(wǎng)絡(luò)性能完全下降。該層上的問題比較難于追蹤，因為不像底層出現(xiàn)的問題，傳輸層問題通常不會導(dǎo)致連接的完全丟失。此外，傳輸層問題還經(jīng)常與IP端口的流量擁塞有關(guān)。如果你能夠ping通服務(wù)器，但是不能通過已知端口進行連接，這有可能就是一個傳輸層問題。
會話層、表示層和應(yīng)用層 這三層經(jīng)常被放到一起討論，因為最近有關(guān)OSI的解釋趨向于淡化這三層之間的分隔。這三層的故障檢修過程包括與應(yīng)用有關(guān)的各種問題。
這些應(yīng)用問題可能包括DNS、NetBIOS問題或者其它一些存在于OS中的解析、應(yīng)用問題，又或者是高層協(xié)議失效或者錯誤配置問題。一些典型的高層協(xié)議有HTTP協(xié)議、SMTP協(xié)議、FTP協(xié)議和其它一些典型的“使用網(wǎng)絡(luò)”而不是“運行網(wǎng)絡(luò)”的協(xié)議。另外，一些專門的外部攻擊(如中間人攻擊)也會造成這些層次上的問題。
網(wǎng)絡(luò)問題可能而且確實發(fā)生在模型的任意一層上。因為網(wǎng)絡(luò)管理員對該模型非常了解，所以它自然就成了各種網(wǎng)絡(luò)管理員用來解決問題的一種有效的工具。如果你曾經(jīng)和使用如此語言-“這好像是第四層的問題”-的網(wǎng)絡(luò)管理員一起工作，你馬上就可以知道問題可能發(fā)生的大體區(qū)域(傳輸層)。
你會聽到一些有經(jīng)驗的網(wǎng)絡(luò)管理員經(jīng)常使用層次號來指代問題的位置。例如，當(dāng)你聽到“那在第三層”，就表示IP連接問題。第四層揭示的是網(wǎng)絡(luò)端口關(guān)閉引起的問題。有趣的是，網(wǎng)絡(luò)管理員喜歡把系統(tǒng)而不是網(wǎng)絡(luò)出現(xiàn)的問題稱為“第七層”問題。
讓我們探討一下在使用OSI模型對問題進行隔離的過程中可以使用的三種不同的方法。
三種不同的方法
使用OSI模型作為故障檢修框架的網(wǎng)絡(luò)管理員一般使用下列三種方法中的一種：自下而上(Bottom-Up)、自上而下(Top-Down)和自中間而兩端(Divide-and-Conquer)。對某一個特定問題，他們會依據(jù)問題的明顯程度和他們的經(jīng)驗來選擇其中一種方法�；趩栴}的類型，每一種方法都有它的用武之地。讓我們一個個來討論。
自下而上(Bottom-Up)
簡單來說，自下而上的方法就是，網(wǎng)絡(luò)管理員從OSI模型的底部開始，逐步穿過各個層次，直到找到問題的根源所在。使用自下而上方法的網(wǎng)絡(luò)管理員一般從檢查物理層問題開始，首先，確定網(wǎng)絡(luò)連接是否斷裂，其次，查看網(wǎng)絡(luò)接口配置和誤差率，再次，檢查路由、分段和端口阻塞等IP和TCP/UDP錯誤，最后，查看各個應(yīng)用錯誤。
這種方法最適合于網(wǎng)絡(luò)完全崩潰或者具有大量底層錯誤的情形。當(dāng)問題特別復(fù)雜時，這種方法也是最佳選擇。在復(fù)雜的問題中，故障檢測程序往往無法給網(wǎng)絡(luò)管理員提供足夠的調(diào)試數(shù)據(jù)以便對問題進行分析。因此，聚焦于網(wǎng)絡(luò)的方法是最佳的。
自上而下(Top-Down)
自上而下的方法于自下而上的方法正好相反，網(wǎng)絡(luò)管理員首先從OSI模型的頂端開始，查看出現(xiàn)故障的程序并設(shè)法跟蹤程序出現(xiàn)故障的原因。這種方法最適合于網(wǎng)絡(luò)狀態(tài)良好，網(wǎng)絡(luò)中新的應(yīng)用或者應(yīng)用配置正在完成的時候。網(wǎng)絡(luò)管理員可以首先確保應(yīng)用的正確配置，然后往下保證全IP連接和適當(dāng)?shù)亩丝谔幱陂_放狀態(tài)以確保程序的正常運行。一旦所有的上層問題被解決，就可以回頭檢查網(wǎng)絡(luò)功能是否正常。正如先前所述，這種方法一般用于網(wǎng)絡(luò)功能正常，但是正在引入新的網(wǎng)絡(luò)應(yīng)用或者正在對現(xiàn)存應(yīng)用進行重新配置的情況。
自中間而兩端(Divide-and-Conquer)
自中間而兩端的方法是對“內(nèi)臟感覺”方法的一種富有想象力的命名。這種方法一般被對網(wǎng)絡(luò)和可能出現(xiàn)的問題有較深理解的有經(jīng)驗的網(wǎng)絡(luò)管理員所使用。自中間而兩端的方法需要網(wǎng)絡(luò)管理員具對問題出現(xiàn)的地方有一種直觀的感覺，首先從你認(rèn)為問題可能出現(xiàn)的那一層開始，然后從該位置逐步擴展到模型的兩端。這種方法還可以用于解決以前遇到過的一些小問題。
然而，這種方法經(jīng)常會因為沒有足夠的科學(xué)依據(jù)而無法正確地診斷比較困難的問題而失敗。如果問題在本質(zhì)上非常復(fù)雜，那么自中間而兩端的方法可能就無法有效地追蹤問題所在。
圖 據(jù)問題的類型，選擇自下而上、自上而下或者自中間而兩端方法中最有效的一種來隔離問題的根源 不管你使用的是那種方法，只有當(dāng)你充分了解了你的網(wǎng)絡(luò)和它的特質(zhì)，你才能考慮選擇使用一種結(jié)構(gòu)化的方法作為故障檢修技術(shù)。盡管使用結(jié)構(gòu)化的方法可能會增加解決問題的時間，但是它將徹底追查問題根源所在，而不會由于遺漏一些關(guān)鍵問題而日后對網(wǎng)絡(luò)“修修補補”。
只有當(dāng)你對網(wǎng)絡(luò)以及故障檢修技術(shù)有了堅實的基礎(chǔ)，才建議你使用自中間而兩端的方法。這種方法常常只能應(yīng)付一些表面的網(wǎng)絡(luò)問題而不能解決實際的根源問題。
讓我們暫時放下故障檢修的一般概念，開始談一下我們可以使用的進行故障檢修的一些工具。
