瞭解源路由轉換橋接並排除故障

簡介

本檔案介紹來源路由轉譯橋接(SR/TLB)，並提供疑難排解資訊。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

來源路由轉譯橋接

在當今的網路中，乙太網環境通常與令牌環環境混合使用。這種混合帶來許多邏輯問題。第一個是乙太網路沒有接近來源路由橋接的任何內容，而權杖環有一個路由資訊欄位(RIF)。 此外，權杖環具有有效的地址，而乙太網最常有廣播。

為了能夠將這兩種環境統一起來，思科建立了SR/TLB。

您可以將橋接組新增到路由器的介面（令牌環和乙太網），以透明地橋接令牌環和乙太網。這將在兩個環境之間建立一個透明的橋接域。如果權杖環端正在執行來源路由橋接，將會出現問題。如何將透明橋接與來源路由聯絡起來，尤其是考慮到終端站是建立通過網路的站？

此圖說明解決方案：

當pc_1要與pc_3通訊時，它會向線路傳送帶有廣播(FF-FF-FF-FF-FF-FF)資料包的NetBIOS name_query。問題在於pc_3工作站正在偵聽目標地址為(C0-00-00-00-00-80)的name_queries，並且它接收該廣播並不將其傳送到NetBIOS，因為它不是name_query（根據pc_3的定義）。

因此，從權杖環到乙太網路的轉譯會很複雜。大多數詳細資訊都在路由器內部處理，造成一些混淆的問題是位交換。權杖環和乙太網路以不同方式將位元讀取到配接器中。路由器不會進入幀並更改位順序，因此乙太網上的MAC地址與令牌環上的MAC地址不同。

乙太網路站無法作為來源路由終端站，因此思科路由器會承擔此角色。根據上圖所示，路由器從乙太網路收到封包後，會發生以下事件：

1. Cisco1路由器收到來自乙太網的資料包。這是從pc_1到host_1。

2. cisco1需要一個RIF才能到達host_1，因此它會建立一個資源管理器來確定到達host_1的路徑。

3. Cisco1收到回應後，會將回應（不帶RIF）傳送到乙太網路站。

4. pc_1向主機MAC地址傳送交換標識(XID)。

5. cisco1獲取乙太網資料包，將RIF連線到主機，並在途中傳送資料包。

6. 這一過程仍在繼續。

有幾個條件使這個過程成為可能。首先，就主機而言，乙太網位於所謂的偽環中。在路由器上使用source-bridge transparent命令進行設定：

source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui]

配置SR/TLB時，您必須在路由器中首先具有環組。從host_1的角度來看，偽環使乙太網看起來像是令牌環。

按以下方式配置cisco1:

source-bridge ring-group 10

source-bridge transparent 10 11 1 1
!
interface tokenring 0
 source-bridge 1 1 10
 source-bridge spanning
!
interface Ethernet 0
 bridge-group 1
!
bridge 1 protocol ieee

自Cisco IOS^®軟體版本11.2起，SR/TLB採用快速交換。早於Cisco IOS軟體版本11.2的SR/TLB是程式交換型。若要關閉快速交換，請發出以下命令：

no source-bridge transparent ring-group fastswitch

show命令

有兩個對SR/TLB很重要的show命令。

• show bridge — 此命令在分析透明端時非常有用。它顯示路由器是否從網路中的特定裝置接收資料包。

• show rif — 此命令顯示路由器是否已為目的地MAC位址建立RIF。

疑難排解

本節討論如何對MAC地址位交換和SR/TLB環路進行故障排除。

位交換

SR/TLB問題的最常見原因之一是MAC位址位元交換。之所以會出現此問題，是因為路由器在MAC位址上執行從乙太網路到權杖環以及從權杖環到乙太網路的位元交換。結果是終端站無法識別這些幀。此圖顯示範例：

在此圖中，幀在源MAC(SMAC)和目的MAC(DMAC)中有完全相同的位模式。 但是，在權杖環中讀取此位元模式與在乙太網路中讀取的方式不同。為了能夠通過該網路傳送定向幀，必須在傳送定向幀之前對其進行位元交換。

首先要將原始MAC地址轉換為二進位制。您可以分別使用三個2位元組集來簡化操作。此示例使用4000.3745.0001。

4000.3745.0001具有此二進位制值：

0100 0000 0000 0000 0011 0111 0100 0101 0000 0000 0000 0001

反轉每個位元組。不要反轉整個字串。這是以位元組分隔的二進位制數：

01000000  00000000  00110111  01000101  00000000  00000001
   40        00        37        45        00        01

要執行bitswap，請將每個位元組的第一個位移動到最後一個位，然後重複此操作，直到最後一個位位於第一個位：

00000010  00000000  11101100  10100010  00000000  10000000 
   02        00        EC        A2        00        80

位交換完成後，您會看到新的MAC地址0200.ECA2.0080。

適用於許多系統網路架構(SNA)乙太網路站的軟體會自動執行交換。如果您不能確定，最好雙向測試。

注意：有時，對於廣泛使用的裝置，網路包括「不可位交換」的MAC地址，因為這些地址是相同的交換地址或非交換地址。這意味著您無需處理遠端FEP地址的編碼。這在具有多個遠端站點的前端處理器(FEP)環境中很常見。例如，4200.0000.4242是一個非位可交換MAC地址。

此外，路由器本身（在透明網橋部分）將MAC地址視為乙太網格式，而代碼中的源路由部分將它們視為令牌環格式。在FDDI等場景中，讀取的幀完全相同，路由器代碼顯示MAC地址全部反轉。

權杖環和乙太網路之間的DHCP/BOOTP支援

當您使用SR/TLB或透明橋接(TB)時，且伺服器和客戶端處於不同的媒體型別LAN（規範或非規範）時，不支援DHCP/BOOTP。 例如，如果使用者端位於權杖環LAN中，伺服器位於乙太網路LAN中。這是因為客戶端在BOOTP請求資料包（chaddr欄位）中包含其MAC地址。

例如，當MAC地址為4000.111.0000的客戶端傳送BOOTP請求時，資料包通過SR/TLB或TB網橋，MAC報頭中的MAC地址會進行位交換，但BOOTP請求中嵌入的MAC地址保持不變。因此，BOOTP資料包到達伺服器，伺服器將使用BOOTP回覆進行回覆。此BOOTP應答傳送到廣播地址或客戶端的MAC地址，具體取決於廣播標誌。如果未設定此廣播標誌，伺服器會將單播資料包傳送到chaddr欄位中指定的MAC地址。乙太網端的伺服器將回覆傳送到MAC地址4000.111.0000。資料包通過網橋，網橋位交換MAC地址。因此，令牌環端的BOOTP應答最終會得到目的MAC地址0200.8888.0000。因此，客戶端無法識別此幀。

循環

SR/TLB問題的另一個原因是您不能允許路由器使用前往同一乙太網路的不同路徑。

此圖包含一個半循環：

由於封包來自同一個偽環且位於同一個環群組中，因此來自權杖環環境的封包會傳送到乙太網路。這會導致第二台SR/TLB路由器認為某個MAC位址位於其本機乙太網路上。因此，乙太網路上的站台無法再次到達該站。

此外，Cisco1會取走同一封包並向網路傳送探索器，如此一來，該站台會顯得好像是在乙太網路上（當它位於權杖環環境中時）。

此圖說明了一個常見的情況：

在這種情況下，僅需一個資料包即可建立巨大的環路。因為封包不會被乙太網路端或權杖環端捨棄，所以封包會一直以循環模式執行。

調試

SR/TLB的偵錯非常有限。其中一個選項是使用過濾器對權杖環進行偵錯，以檢查封包是否通過路由器。如需詳細資訊，請參閱瞭解和疑難排解本機來源路由橋接。

相關資訊

• IBM SNA網路技術支援
• 權杖環技術支援
• 技術支援與文件 - Cisco Systems