例如，如果您的生成樹網絡占據重要位置，或者無法離開nProbe或Wireshark，那么您就應該使用可靠的解決方案，解決以前需要幾個小時才能修復的問題。IEEE 802.1D支持無回路的連接，而Wireshark只需要簡單的操作就可以清理任意數據包。然而，即使有這么多成熟的網絡管理技術和工具，仍然有一些網絡路由問題需要管理通過安全shell進行調試。路由分析就是一個很好的例子。

網絡便利工具

或許我們不會像安滅火器那樣在墻上安裝淺藍色網線，但是每一位管理員都知道從哪里可以馬上找到。解決路由問題需要通過命令行接口重復查看狀態表，而且您總是需要在各個機架上來回走動。您甚至還可能需要連接幾臺設備的控制臺，才能跟蹤路由。但是，這些方法可能還無法解決路由調試的真正挑戰。路由似乎經常會出現問題，而尋找問題根源的最有效方法就是實時獲取錯誤信息。

即使您配置了很好的syslog警報，許多路由變化也只會隔幾天出現一次，因此很難捕捉它們。而且，用戶也不是報告路由錯誤的最佳來源：在頁面加載變慢或聊天應用延遲明顯時，他們只是會向周邊人抱怨(雖然在傳輸路徑出現抖動或丟包問題時，有一些 VoIP客戶會故意給出主觀的低評分)所以，問題就出現了：“您該如何定期查詢路由表，并在網絡路由出現問題時馬上能接受到警報呢?”

路由解析時產生的影響

網絡的實際路由包含許多因素，它們會(但不總是)以各種方式對各自產生影響。路由信息協議、開放最短路徑優先、邊界網關協議、增強內部網關路由協議和靜態配置等都會對最終路由產生影響。本質上，它們一起構成了一種虛擬配置。但是，最終的“物理”路由只能在一個位置驗證：路由表。但是，誰有那么多時間整天盯著所有設備的路由表呢(而且也沒道理這樣做)?

首先，每當路由發生變化時，它會強制路由器重新計算網絡拓撲，因此網絡會充滿更新的數據包。這并不好。其次，路由變化檢測通常在問題出現之后，因此您必須花時間查看各個路由葉節點，才能發現幾小時前發生了什么。有時候，路由變化可能會降低流量傳輸速度，因此路由可能回滾到前一條性能不佳的路由。而有時候，這些變化可能會切斷某條鏈路或中斷關鍵用戶服務。

幸好，許多網絡性能監控解決方案能夠輕松訪問所監控設備的路由表。因為它們能夠感知路由變化，所以您不需要連接控制臺，就可以接收到警報、生成報表或直接查看路由表。將它們與網絡拓撲發現工具相結合，您就可以監控各個終端的完整流量路由，檢查接口連接環境的路由細節。一層網絡是否仍然所有問題的根源，跟蹤一臺服務器到一個連接信號燈熄滅的端口之間的中斷數據包流，不需要管理員離開自己的工位。路由變化歷史報告和變化路由查看視圖通常都是免費的。

肯定，當路由變化時發送syslog消息是很方便，但是您仍然必須監控日志，才能及時捕捉有時很難理解的變化。為了節省您的時間，花一些時間配置路由監控工具，以實時方式發送與變化相關的警報，并且跟蹤它們的變化歷史。這樣，您就能夠更快速地修復問題，并且淘汰控制臺連線的方法。