排除DLSw配置故障
簡介
本文探討如何對資料連結交換(DLSw)組態進行疑難排解。
必要條件
需求
本文件沒有特定需求。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
背景資訊
如果對等點沒有連線，請確認兩台路由器之間是否存在IP連線。如果是，請檢驗本地和遠端路由器上是否有適當的DLSw peer語句。有關詳細資訊，請參閱基本DLSw+配置和故障排除DLSw IP連線問題。如果不存在遠端語句，請在一端對本地對等語句使用關鍵字promiscuous。有關詳細資訊，請參閱DLSw+配置命令。
網路拓撲
本節將解決一些常見問題，並提供如何進行疑難排解的提示。
循環
請記住，路由資訊欄位(RIF)終止是DLSw的一個重要方面。RIF通過在網路中容易建立環路而導致重大問題。
網路拓撲
以下是跟蹤環路建立的示例拓撲。
DLSw終止RIF，資料包無休止地傳輸。每次從對等體傳送CANUREACH(CUR)幀時，接收方對等體都會建立一個新的資源管理器（無RIF）並傳送它。
環路建立：案例 1
這是探險家的路線：
-
第11環中的3174傳送探查器以到達主機。
-
舊金山1(SF1)和網橋都會複製幀。
-
SF1建立到Los Angeles 1(LA1)的CUR訊框（對等路由器），通知LA13174想要到達主機。
-
San Francisco 2(SF2)收到資料包並重複操作。
-
LA1和Los Angeles 2(LA2)建立探險者，並把它送到戒指。
-
LA1和LA2各自接收一個探險者（另一個建立的探險者）。
現在出現了一個問題。每一端都確定3174是本地連線的，並且每台路由器都以本地和遠端方式檢視3174。
-
每一端向SF1和SF2傳送一個CUR幀，並從3174為主機建立一個資源管理器。
-
兩台路由器（SF1和SF2）都會再次複製該幀，並檢視主機既是本地主機又是遠端主機。DLSw現在中斷並進入循環。
在這種情況下，您能做的最好的事情就是確保路由器的虛擬環在雲的每一端都完全相同：
環路建立：案例 2
為雲端各端的路由器配置了相同的虛擬環號。此配置可確保傳送探查器的路由器已通過環路，因此路由器將丟棄探查器。當LA1為SF1收到的CUR幀生成一個資源管理器時，LA2將丟棄該資源管理器，因為該資源管理器已經通過環1。如果路由器要向同一個環進發，則它們必須配置不同的網橋號。此網路的LA端的情況就是這樣。使用乙太網路時，必須停用對等點：
乙太網上的資料包本身沒有RIF。因此，當LAN上的另一台路由器建立廣播時，路由器無法確定廣播是來自另一台路由器還是來自始發站。在系統網路架構(SNA)的情況下，路由器無法確定封包是源自本地還是遠端。令牌環中的探查器同時具有源MAC地址和目標MAC地址。因此，此類探險者實際上並不是乙太網上的廣播。相反，它們將作為定向幀從一個站點傳送到另一個站點。
請考慮以下順序：
-
3174向主機傳送一個探查器。
-
SF1和SF2都接受瀏覽器。
-
SF1和SF2各自產生到另一端LA1和LA2的CUR。
-
這些CUR都會生成一個探查器，主機會對它做出響應。由於這是單個路由瀏覽器，因此所有路由瀏覽器都會響應。
-
LA1和LA2都建立到SF1和SF2的CUR幀，為3174建立此資料包。
問題在於SF1從乙太網偵聽主機的MAC地址，並確定主機位於自己的本地LAN上。但是，在SF1快取中，主機似乎從遠端對等體響應。因此，路由器的主機被定義為本地和遠端。
DLSw現在中斷並進入循環。
要修復DLSw，必須禁用一個對等體或使用乙太網冗餘功能。有關詳細資訊，請參閱DLSw乙太網冗餘配置示例。
意見