簡單排除VLAN無線上網交換器故障

 　　在無線網路組成中，很多裝置的使用都值得大家詳細瞭解一下。那麼今天我們主要談論一下VLAN無線上網交換器故障的問題。如下是一位網友的經驗分享：單位一個辦公區所在的兩個部門VLAN出現了一個很奇怪的問題，網際網路上部分網站可以正常訪問，而部分網站又無法訪問;通過Outlook或者Foxmail內送郵件正常，發送不帶附件的小郵件也正常，但是發送大郵件或者含有附件的郵件時就不能正常發送了。單位其他辦公區上網正常。

　　VLAN無線上網交換器故障分析

　　使用者PC所在的辦公區距離核心交換器大約有2～3公裡，該辦公區有兩個部門，分屬不同的VLAN，因此我們在該辦公區放置了安奈特網管交換器AT-8024，中間通過光纖和一對光收發器串連在我們的核心交換器Cisco 6509上面(Cisco 6509配置為：超級引擎SUP720，一個16口的千兆位光模組WS-X6816-GBIC，一個48口的快速交換電模組WS-X6548-RJ-45)。在串連光收發器的6509和安奈特交換器的相應連接埠上起了Trunk，安奈特交換器上面劃分了兩個VLAN，分別是172.25.6.0/24(以下簡稱VLAN6)和172.25.7.0/24(以下簡稱VLAN7)，兩個部門的機器分別接在各自的VLAN裡面。而其他辦公區的匯聚層交換器(Cisco 3550)直接通過光模組串連在6509的WS-X6816-GBIC光模組上。

　　整個網路用了一台IBM X235伺服器作為NAT和DHCP伺服器，所有VLAN的資料先到NAT做地址轉換以後再通過邊緣路由器訪問網際網路。

　　遇到上述奇怪問題，我們一開始懷疑是NAT和6509的設定出了問題，但是經檢查，VLAN6和VLAN7的配置和其他辦公區的路由配置是完全一樣的。因為除這兩個VLAN外的其他VLAN上網完全正常，於是我們採用了以下解決步驟。

　　(1)將VLAN6和VLAN7的VLAN資訊在安奈特網管交換器上全部刪除，將所有連接埠都劃在上網正常的VLAN1裡面，這下它們完全和VLAN1一樣了。但是問題依然如故，而其他辦公地區VLAN1裡面的使用者上網仍然正常。

　　(2)從步驟(1)推斷問題不在VLAN的劃分上，我們開始懷疑是光收發器或者安奈特交換器有問題，於是將其他辦公區使用正常的光收發器或者安奈特交換器換上去，問題依舊。

　　(3)難道是鏈路品質的問題?趕緊找來兩台PC，一台接在安奈特交換器上，將光收發器接6509的網線拔下來，直接接在另外一台機器上，配置同一網段的IP，發最大的資料包65500b互ping，但是結果讓我們失望，延時只有幾個毫秒，這說明鏈路沒有問題。

　　(4)就在我們“黔驢技窮”的時候，我們再次把光收發器和6509串連好，仍然用接在安奈特上的PC機ping設在6509上的該VLAN的網關172.25.6.210，問題出現了，用小包ping時，基本上沒有延時，但是用大包(接近18024b，Cisco所支援的最大資料包)ping時出現了丟包，問題肯定出在這裡了。

　　(5)重新檢查安奈特和6509及NAT伺服器的配置，我們發現這樣一個問題：在安奈特上配置VLAN6和VLAN7，並將相應連接埠添加到VLAN的命令為：add VLAN 6 ports=23 frame=untagged(將23號連接埠添加到VLAN6裡面，注意這裡的frame=untagged表示此時不對資料包封幀)，而我們在安奈特交換器與6509的級聯口(第一號連接埠)上起了Trunk，同時對資料進行了強制封幀，命令如下：add VLAN 1 ports=1-24 frame=tagged(即我們將所有經過級聯口轉寄出去的資料包進行了強制封幀，我們知道安奈特交換器封框架類型為IEEE 802.1Q VLAN標記)。然後我們繼續檢查6509的配置，進入串連VLAN6和VLAN7的介面，進行該連接埠的Trunk配置，如下：

　　6509#conf t

　　Enter configuration commands, one per line. End with CNTL/Z.

　　6509(config)#interface gigabitEthernet 3/48 —進入級聯結口

　　6509(config-if)#switchport trunk ? —查看起Trunk後的情況

　　allowed Set allowed VLAN characteristicswhen interface is in trunking modenative Set trunking

　　native characteristics when interface is in trunking modepruning Set

　　pruning VLAN characteristics when interface is in trunking mode

　　VLAN無線上網交換器故障排除

　　從上面可以看出：該連接埠不能強制進行IEEE 802.1Q的Trunk設定，其他介面情況都一樣。此時想到超級引擎SUP720模組上還有一個介面沒有用，看它能不能進行強制封幀。進入該連接埠的Trunk配置，看到如下資訊。

　　6509#conf t

　　Enter configuration commands, one per line. End with CNTL/Z.

　　6509(config)#interface gigabitEthernet 5/2

　　6509(config-if)#switchport trunk ?

　　allowed Set allowed VLAN characteristics when interface is in trunking mode

　　encapsulation Set trunking encapsulation when interface is in trunking mode

　　native Set trunking native characteristics when interface is in t runking mode

　　pruning Set pruning VLAN characteristics when interface is in trunking mode

　　下畫線標示出的比在gigabitEthernet 3/48介面上看到的多了一個encapsulation選項，由此可見，在超級引擎模組的介面上可以強制進行IEEE 802.1Q的Trunk設定。

　　輸入如下命令：

　　6509(config-if)#switchport trunk encapsulation ?得到：

　　dot1q Interface uses only 802.1q trunking encapsulation when trunking

　　isl Interface uses only ISL trunking encapsulation when trunking

　　negotiate Device will negotiate trunking encapsulation with peer on interface

　　繼續：

　　6509(config-if)#switchport trunk encapsulation dot1q 斷行符號;

　　6509(config-if)#end

　　6509#write

　　Building configuration...

　　[OK]

　　*註：該6509所用的IOS版本是Version 12.2(17a)SX。

　　我們將跳線接到該介面上，再來測試網路，原來的問題已不複存在。這兩個VLAN內的使用者訪問網頁恢複正常，帶有附件的郵件又可以輕鬆發送了。

　　VLAN無線上網交換器故障經驗總結

　　由於Cisco的6509 核心交換器上48口的快速交換電模組是預設對幹線進行IEEE 802.1Q封幀的，而我們的安奈特網管交換器強制對幹線進行IEEE 802.1Q封幀，這是兩個廠家的產品，因此可能會導致資料包傳輸進行協議的協商時不能很好匹配的情況。

　　此時我們又想到，在出現這個問題之前很長一段時間，我們的網路都是正常的，而當時我們的做法是：一開始只有收發器接在6509 超級引擎SUP720模組gigabitEthernet 5/2口上，我們在此介面上進行了強制IEEE 802.1Q封幀，後來由於48口的快速交換電模組有空餘介面，我們就將其改在了gigabitEthernet 3/48口上，使用了預設IEEE 802.1Q封幀，但網路使用一直正常。這次我們對網路進行了一些調整，重新啟動了一次我們的核心交換器，結果就出現了這個問題。這說明如果先將超級引擎強制進行IEEE 802.1Q的Trunk設定，待網路穩定後，再將跳線接回gigabitEthernet 3/48介面，此時Cisco 6509 將使用預設的IEEE 802.1Q封幀，同安奈特進行幹線協議的協商，這樣資料包在傳輸時進行協議的協商就不會出現問題，VLAN6和VLAN7就可以正常上網。我們後來又這樣實驗了一下，事實證明確實如此。