網絡測試必不可少，但有時候頗具挑戰性;遇到軟件缺陷和破損的設備是測試環境的一個再平常不過的方面。但要是沒有軟件缺陷，設備又沒有破損，可是測試依然通不過，那又出現了什么情況呢?是測試本身有缺陷嗎?應該怪罪于測試工程師?還是說問題出在其他別的方面，可能是較為隱蔽的方面?

奇怪和預料不到的測試問題一直會出現;而運行使用IPv6的測試網絡的人士對這些問題絕不陌生。本文將逐一分析與IPv6測試有關的若干最常見問題，另外給出了可能適合的解決辦法。

1. 硬件：它有沒有鏈路?

當然，這是很明顯的出發點，并不是IPv6所特有的，但它可能是追查起來最令人沮喪的問題之一，常常是由于你根本沒有想到問題會出在線纜上。事實上，線纜會脫落，交換機會重啟，有時候硬件會出現故障。所有這些問題都會導致硬件系統的最基礎層面出現通信中斷，因而給你的測試帶來棘手的問題。說到交換，由于無線網絡、虛擬化、甚至簡單的虛擬局域網(VLAN)很普遍，硬件故障會變成看不見的問題，要識別起來甚至更加麻煩。

解決這個問題的最好辦法就是使用一個穩定的、標記清楚、備份起來的測試網絡。很少變化、了解得一清二楚的測試網絡也許無法防止故障，但是問題果真出現時，可以大大簡化辯明真相。

2. 防火墻：它們存在!

防火墻就像IPv6協議一樣在不斷完善，說到保護用戶和軟件遠離危險，防火墻是絕對必不可少的部件。這意味著，認識到防火墻是如何部署的，以及它經配置后可以監控或阻止什么對象，這一點很重要。防火墻常常阻止盡管對協議測試驗證而言很重要，但可能似乎是拒絕服務(DoS)攻擊或另一種危險攻擊的流量。過于謹慎的防火墻會讓你想自己是不是果真接入了你認為應該接入的系統，害得你捕風捉影。

這里的解決辦法很棘手。就測試而言，一臺被禁用的防火墻有助于迅速縮小原因范圍。說到部署，這無助于事;然后你得確保你的設備在互聯網上會正常運行，可保護其用戶。這方面可沒有什么高招;需要做的最好辦法就是，調查防火墻為什么阻止協議流量，尋求專家的幫助，確定這是異常阻止還是真正的安全漏洞。

[[127624]]

3. 多宿主：這道門后面是……

多宿主(Multihoming)并不是IPv6的一個新概念，但說到測試和部署IPv6，這個概念會引起一大堆問題。這一方面歸因于IPv6的自動配置越來越對用戶友好――具體來說，是默認路由的自動配置。格式正確的ICMPv6路由器公告(RA)會引起設備安裝通過傳送路由器的默認路由(或“最后采取的路由”)。

[[127625]]

不止一個路由器發送這樣的數據包時，問題就會出現。你可能認為，兩個路由器發送這種格式正確的數據包的可能性微乎其微，可是在測試網絡中，路由器公告很容易溜出去、跑到生產環境上，或者是跑到不同的測試網絡上，從而造成嚴重破壞。當然，只有你的設備擁有不止一個接口時――可是事實證明這種情況很常見，才會出現這個問題。手機(無疑和蜂窩)和筆記本電腦(無線和以太網)就是兩種很常見的設備，它們通常至少有兩個潛在的出站接口。

與硬件和防火墻問題一樣，多宿主問題會導致流量似乎丟失或從來沒有被發送。區別在于，它時而行，時而不行，似乎是間歇性的。這歸因于計時器或生命周期的不同，讓設備有一個“恢復”期間：它在這段期間似乎會正常運行。這個問題很容易識別，因為兩個默認路由會清楚地顯示在系統上。當然，解決這個問題可能有難度，因為現在你得查明誰是未授權路由器公告的發送者。或者，你可能要試一下防火墻。

4.地址：地址很大

地址有許許多多，而且地址很難輸入。與IPv6地址這么簡單的東西有關的測試問題比比皆是。這個問題會體現在把E誤輸成D或把3誤輸成6這么簡單的事情。由于有那么多的數字需要輸入，這個問題一直在發生。下面是一個典型的IPv6地址：

FC00:41FF:3880:1FE0:5851:75f2:8867:de1b

這里的最佳解決辦法就是，總是拷貝粘貼。不要在任何情況下過于相信自己而輸入IPv6地址!

其他地址問題比較復雜，實際上旨在幫助網絡而不是破壞網絡。但是就像其他許多情況下一樣，測試網絡與生產網絡大不一樣。不妨考慮重復地址檢測，內置到IPv6中的這個策略用于識別網絡上重復的地址。

地址重復不太可能出現在完全自動配置的網絡上，即便在生產環境下。但在測試環境中，工具和設備都配置成同樣或相似的地址，以便簡化測試和配置工作，所以兩個設備很容易最后使用同一個地址。這里的解決辦法與識別未授權路由器公告很相似：只要關注一下接口，應該就能弄清楚該地址是不是重復。難就難在追查竊賊的蹤跡!

5. 內存：設備不會忘記

IPv6包括許多部分：設備接入時間越長，發現的關于網絡和環境的信息就越多。這包括路徑最大傳輸單元(MTU)、地址、鄰居狀態及更多信息。同樣，雖然熟悉和調整設備以符合網絡特點對生產網絡而言再理想不過，可是在測試環境下，這可能會帶來好多的誤報測試結果。

[[127626]]

這方面的一個典例就是ICMPv6數據包太大這個消息。某個設備想做到一致性，就必須在一段時間內記住該消息的內容。問題在于，這段時間可能比它進入到下一個測試所花的時間更長!所以，如果你看到預料之外的碎片數據包，可能就有必要重啟。

這同樣適用于鄰居發現操作。這個復雜的狀態機存在好多變數，要是任由它處于“不干凈”的測試狀態，就會給即將進行的測試帶來諸多問題。在許多情況下，發送各種清理數據包的例程會清空鄰居緩存。不過，IPv6的新標準讓這成為一項更艱巨的任務，所以重啟日益成為是清空緩存的最佳方法。