交換機的五種故障診斷技術
在一個交換網絡里，您如何確定從哪里開始動手查找問題？想深入“透視”一個交換網絡是非常困難的。首先，在2層交換的時候還是橋接轉發方式，但到了3層交換卻有了更高級的特性和轉發規則，例如VLAN。到了4層交換，就更加復雜了，出現了更高級的轉發和負載均衡技術，故障診斷故障診斷和解決就需要更多的交換機配置知識。
在安裝完一臺交換機后，每個交換機的半雙工端口就構成了一個沖突域。如果該端口連接了一個集線器，集線器下面連接若干站點，那么沖突域會擴大。但隨著交換產品的價格下跌，現在大多數新建的網絡每個交換端口都只連接一個站點。因此，在半雙工連接情況下，沖突域僅針對一個單獨的電纜鏈路。
交換機通常是一個獨立廣播域的一部分，包括串連或者并連的任意數目的其他交換機。如果使用了OSI模型3層的功能，就可以創建多廣播域，廣播域的數目與VLAN數目相等。最極限的情況，如果交換機功能允許，每個端口可以配置為一個獨立的廣播域。可以把這種情況描述為路由到桌面。為每個端口創建一個獨立的廣播域后，故障診斷就會嚴格受限。但是如果我們把每個端口設置為一個單獨的廣播域，交換機在轉發流量的時候，每個端口都需要路由服務，這會占用交換機 CPU的有限資源。在網絡環境中，對每個單獨的端口進行路由請求和應答是非常困難的，我們應該避免這樣的配置。不幸的是，這種情況在實際情況中非常常見，網絡中經常發現服務器全部在一個子網或者廣播域中，所有的客戶在另外的子網或者廣播域中。在這種情況下，所有的請求都必須路由。如果維護行為限制在一個單獨的服務器群里，那么考慮把服務器放進單獨的VLAN里。然后把使用這臺服務器的用戶放到同一個VLAN。這樣就可以使用2層交換的橋接方式來交換流量，只有很少的請求需要路由。如果服務器支撐多于一個用戶區，可以在服務器上多裝一塊網卡來實現到用戶的2層交換連接。
對交換機進行故障診斷的5種技術
可以采取5種基本方式來透視交換機。每一種方法都不同，都有積極或者消極的一面。類似在網絡中遇到的其他問題一樣，沒有一個最好的答案。最合適的方案往往取決于您手中可以利用到的資源(什么工具可以使用或者以前安裝過什么工具)，而且使用這些技術有可能造成服務中斷。
即使把這些方式組合起來，也不能監測到所連接的網絡，在交換的環境里面，也不像集線器那樣方便監測。我們幾乎不可能看到通過一個交換機的全部流量。大多數的故障診斷會假設流量會在站點和所連接的服務器之間或經過故障診斷交換機uplink口通過。而實際上如果2臺主機直接傳輸信息的話，就不會使用交換機的uplink口或者任何其他的端口來交換流量。除非你知道具體用到哪個端口，否則是監測不到的。
舉個例子，一臺服務器接入一臺交換機。在反映有問題的用戶中，一部分是直接與這臺交換機相連，另外的一部分用戶是由這臺交換機的uplink口從其他路由器或者交換機連接上來的。故障報告是訪問服務器“慢”，這樣的故障報告對技術支持工程師來說基本上沒有任何價值。
方法1：通過TELNET或者串行口接入服務器
高級的網絡技術支持工程師或其他知道交換機密碼的人在進行故障診斷時可以選擇通過TELENET或者交換機的串口登陸，來檢查交換機的配置。
交換機配置可以通過上面提到的2種方法查看，雖然問題不一定是配置引起的。不管問題是操作系統有BUG還是配置不完善，都不能從配置列表中輕易的查看出。配置信息在定位交換機是否像預期的那樣運行上比較有用，但針對故障診斷就不是了。為了驗證交換機的配置，往往需要使用多種的交換機故障診斷方法配合。
很多交換機都帶有實時的故障診斷工具，因為交換機生產廠家和型號的不同，這些故障解決工具的特征也各不相同。但是要使用好這些工具，必須依靠一定的理論知識和實際經驗。#p#
方法2：連接到一個空閑端口
最簡單的故障診斷方法是在交換機的空閑端口接入一個監測工具，例如協議分析儀。
把監測工具接入交換機的一個空閑端口，不用中斷服務就可以查看所屬廣播域。該監測工具與廣播域里的其他站點一樣有相同的權限。
不幸的是，交換機(做為一個多端口的橋接設備)幾乎不轉發流量到監測端口。因為橋接設備就是這樣設計的，流量直轉發到所屬的目的端口，不會去其他的端口。協議分析儀因此幾乎監測不到流量。
非常少的流量會轉到其他端口。站點和服務器之間可能每秒鐘會轉發幾千個幀，但是監測端口每分鐘只能看到幾個幀。
轉發到監測端口的流量幾乎全部都是廣播，包含一些零星的目的地址不明的幀。這些零星的幀是由于路由轉發表老化的結果，經常是目的端口不明的幀。一些經驗不夠的技術人員看到這么高的廣播(接近100%)，卻沒有注意到端口利用率很低，就誤判網絡出現了廣播風暴，其實不是。
這樣查看交換網絡幾乎沒有用，因為監測工具必須獲取流量。獲得的流量或者對廣播域的查詢對網絡搜索和發現其他類型問題是有很有幫助的，但對解決用戶連接慢的問題并沒有多大的幫助。
對大多數交換機來說，都有一個更好的選擇，可以把需要監測的端口流量備份到一個專門的空閑口。這種技術通常稱為端口鏡像。
大多數交換機廠家都提供備份或鏡像流量的功能，可以把監測工具接入交換機一個專門配置過的端口。老的交換機必須指定一個專門的監測口做為鏡像口，但現在大多數新的交換機可以指定任何一個端口做為鏡像口。
雖然交換機廠家實現鏡像的方式各不相同，但是有一些基本相同的監測選項。值得注意的是，幾乎在所有的情況下，交換機在轉發流量到鏡像口的時候，同時把錯誤都過濾掉了。對于故障診斷來說，這意味著同時過濾掉了有用的信息。
此外，實際操作當中需要我們通過控制口(交換機的RS232端口)，或者Telnet進程來配置鏡像。這意味著除了監測工具之外，我們通常還需要帶一臺電腦或者終端來對交換機進行配置。
鏡像端口經常只是一個“監聽”端口，不過很多交換機廠家允許把該端口配置成全雙工的。配置了鏡像口，監測工具就可以查看報告連接慢的主機和服務器之間的實際流量的備份。鏡像口可以只監測交換機的任意一個端口，甚至可以是Uplink口，也可以同時監測交換機的多個端口。但是同時監測的端口很多的話，過高的流量就有可能會超過鏡像口的接收能力。
監測端口的輸出能力是一個很重要的問題。鏡像口可以收，也可以發。在配置的時候，經常關掉了鏡像口發的功能。但不管有沒有關掉鏡像口發的功能(不管鏡像口是全雙工或者不是)，鏡像口的接收能力都是有限制的。如果被監測的全雙工端口的速率和鏡像口是一樣的話，交換機在轉發流量的時候很容易就會丟包，但是交換機不會通知您。
假設您在監測一個以100MB全雙工速率連接到交換機的服務器的話，那么服務器在全雙工工作的時候，服務器的收發速率都是100MB，那么總共就有了200MB。然而交換機的100MB鏡像口最多只能接收100MB的流量。所以任何交換機的端口(全雙工的)利用率超過50%的時候，鏡像口接收到的包就會有丟失。
如果把多個端口鏡像到一個端口，丟包的問題就會更加的嚴重。因為大多數交換機都工作在低容量，這個問題并不會被立刻注意到。大多數用戶連接的平均利用率都很低。只是偶爾會有流量的突發。
如果選擇一個高速的鏡像口，就可以減少丟包的問題。例如把圖6中的100MB鏡像口換成1000MB，那么就可以很容易的接收200MB的監測流量。#p#
方法3：在鏈路上接入集線器
使用集線器很具有戰略意義。對很多網絡來說，大多數發送和接收的流量都來源于文件服務器之類的共享設備。在交換機端口和文件服務器中間接入一個集線器，再把分析儀接入集線器，實際上就把分析儀和文件服務器接入了同一個廣播域。使用這種方法，技術支持人員就可以看到文件服務器所有進出的流量，幫助技術支持人員解決一系列的問題，包括用戶登陸失敗、性能低效、連接丟失等。
接入集線器的方法很多時候都不實用，特別是在需要監測多個服務器的時候。在哪里接入集線器合適？所有的服務器都要連接嗎？如果是用一個集線器，換來換去連接的話，您一定不希望您的網絡這樣頻繁地被干擾。連接集線器所帶來的時延，經常會帶來連接的丟失。另外，很多時候監測工具并不支持服務器所采用的技術或者連接速率。
使用共享集線器監測一條鏈路上的所有流量和錯誤仍然是一個有效的方法。這幾乎是唯一一種可以在交換網絡環境中實際查看和分析MAC層錯誤的方法。使用SNMP來發現這些錯誤也可以。但是，為了更好地進行錯誤分析，還是用監測工具直接查看最直接。
接入集線器的方法有2種主要缺陷。服務器鏈路有可能不是全雙工的，或者和集線器的端口雙工狀態不匹配，這會給監測帶來更多的不愿意看到的錯誤結果。而且使用這種方法時，手頭必須要有一個共享集線器。現在很多新型的集線器都類似于交換機，而不是共享的轉發設備。接入這種新型的集線器，相當于接入了一個新的交換機，您會看不到想要查看的流量，對監測起不到什么作用。安恒公司如果接入的是雙速率的集線器，例如10MB/100MB雙速率的，可能每個速率都提供了一個廣播域，兩個速率之間再進行轉發。在這種情況下，需要確認被監測鏈路和監測工具運行在相同速率，才能夠使用這種雙速率集線器。還有一些集線器提供在所有端口之間轉發的功能，更因此把自己標榜為價格便宜的交換機，給人造成誤解。他們都不能用在這種監測方法上。#p#
方法4：使用一個TAP（監測接口盒）或者分流器
這種方法類似于加了一個共享集線器，不同點是TAP鏈路只是接收流量，不允許監測工具發出流量。
個詞有時候可以互換，雖然分流器通常應用于光纖鏈路。在光纖鏈路上，分流器會把光在初始路徑和監測路徑上進行分光。典型的分光比率包括80：20、 70：30以及50：50。以80：20為例，80%的光通過分光器繼續傳送到原始路徑，20%的光轉發到監測路徑。如果光纖本來就有問題，或者傳輸的距離很長的話，光分流器帶來的20%光丟失，很容易造成鏈路出現問題。分流器在光纖鏈路上很容易就會帶來3 dB的衰減。有些分流器要耐用一些，因此即使在鏈路的一端安裝分流器造成鏈路中斷，還可以將其換到另一端去安裝，讓鏈路正常工作。光分流器不需要電源就可以工作。需要注意的是，分流器是帶內（Inbound）監測設備，所以分流器的線纜正確連接就非常重要。
電口的TAP也會帶來信號丟失的問題，因為TAP需要信號來識別通過的流量。對電纜來說，這相當于增加了衰減，如果鏈路本身已經有一定問題或者鏈路很長的話，TAP的引入有可能會造成連接中斷。電口的TAP工作需要電源，信號被恢復并重傳到監測端口。如果設計的好，在TAP掉電的時候，鏈路應該也不會中斷。
對鏈路使用TAP進行監測的方式是一個很好的查看鏈路流量的方法。一旦安裝成功，TAP對被監測的設備來說就是透明的，可以隨時使用，而且不會帶來更多干擾。不幸的是，在接入TAP的時候，鏈路必須暫時中斷。此外，TAP或者分流器會按照2個獨立的方向提供流量。也就是說，發送和接收是分開的。
為了同時監測通過TAP鏈路的請求及響應，需要一個帶兩個輸入口的監測工具。雙端口的監測工具可以分別監測每個方向，也可以把兩個方向的鏈路集中在一起分析。您也可以選擇每次只監測一個方向的流量，但這樣分析起來會比較困難。對TAP來說，監測全雙工鏈路和半雙工鏈路，操作上沒有什么區別，都可以監測。您可以選擇一個單端口的監測工具，監測單一的方向，或者選擇一個雙端口的監測工具，同時的監測兩個方向。#p#
方法5：用SNMP查詢交換機
對一個交換網絡進行故障診斷的最有效辦法，應該是通過直接詢問交換機來查看網絡的狀況。這可以通過SNMP或者連接到交換機的控制口實現。顯然，直接連接到交換機的控制口不是理想的辦法，因為這就需要對網絡中的每臺交換機都有物理上的連接。稍微理想一點的替代方法是搭建連接到交換機控制口的終端服務器。安恒公司SNMP是一個更好的選擇，它可以在交換網絡帶內的任何地方進行查詢，不需要附加的硬件。如果您部署了網管系統，還可以配置當利用率、錯誤、或者其他參數超過門限的時候，交換機主動發出SNMP陷阱。然后利用網管或者監測工具，研究是什么原因造成了門限超出。
事實上幾乎所有的交換機都提供SNMP功能，哪怕是最便宜的交換機。它們之間主要的區別就是提供的信息多少。一些價格便宜的交換機只提供簡單的SNMP信息，且是針對整個交換機的;而那些價格貴一些的交換機，還可以提供交換機每個端口的詳細信息。
SNMP可能是監測交換網絡最常用和干擾最少的辦法。SNMP控制臺不需要非常靠近被監測的設備，只要求有路由可達就可以了，同時交換機的安全配置允許控制臺與交換機的代理進行通信。
雖然交換機可以識別到錯誤，但交換機本身并不定時地報告錯誤，所以使用SNMP查詢或許是最好的辦法。
支持SNMP的交換機有不同的MIB庫(管理信息庫)。每一種MIB都不同。除了某些對自己的交換機提供支持的私有MIB庫，標準的MIB庫對交換網絡的監測也非常有用。下面是對故障診斷非常有用的一些MIB庫。
RFC 1213 – MIB II
RFC 1643 – Ethernet-Like Interface MIB
RFC 2819 – RMON Ethernet
RFC 2021 – RMON 2
RFC 2613 – SMON
很多RFC生成之后就不斷地在更新和增強。因此我們要檢查最近更新的RFC。例如RFC1213，至少更新和增強了五次，生成了5個新的 RFC(2011，2012，2013，2358和2665)。除了定義利用率和錯誤的RFC之外，有關橋接的MIB(RFC1493)也是非常有用的。
使用SNMP監測網絡的時候，必須注意安全性。如果SNMP代理沒有限制，那么潛在的任何地方的任何人都可以監測到您的網絡動態或修改交換機配置。交換機售出的時候默認打開了SNMP，并且使用的是一個非常通用的密碼。SNMP密碼叫做通信字符串，使用明文傳播，這帶來了潛在的危險。SNMP V3提供對通信字符串的加密，減少了這種危險，但是SNMP V3還沒有廣泛使用。最常用的通信字符串是public。現在，使用public，很多Internet上的SNMP代理都可以被接入。
我們應該立即修改通信字符串。SNMP代理應該為不同的字符串配置不同的接入級別，不同的IP地址、不同的子網也有不同的接入級別。或者根據其它的配置來限制接入的級別。通過路由器接入SNMP代理可能會對SNMP的限制帶來一些影響。防火墻也有可能完全阻止SNMP。即使您能夠通過SNMP接入代理，也要求代理支持您所要查詢的MIB庫。大部分廠家完全支持標準的MIB庫。然而，也有一些廠家不支持。有時候為了支持期望的MIB，還需要先對交換機的操作系統進行升級。這種方法還有一個問題，如果SNMP代理執行的MIB不正確的話，那么響應就完全是錯誤的了。雖然這并不是經常發生的，但有時候程序設計的錯誤，會帶來錯誤的響應。
交換機不響應SNMP的查詢有很多原因。一旦這些問題都解決了，SNMP就能夠提供非常有效的監測和趨勢分析。
結論
故障診斷的一個普遍方法是等待用戶的投訴。這個方法雖然簡單，但是非常有效。用戶能夠感知到網絡正常的性能是怎樣的。一旦有性能下降，網絡支持中心就會很快收到客戶的投訴。有了用戶投訴，您就應該從他的接入點開始做故障診斷了。這種方法的缺點是完全是被動的，不具有前瞻性的。
理想的方法是使用前瞻性地監測。包括定期地查詢每個交換機、監測每個交換端口的流量、流量的趨勢，同時檢測其他的相關網段。把問題解決從故障診斷方式變成故障預防方式。
【編輯推薦】
