ソースルート・トランスレーショナル・ブリッジ ングの理解およびトラブルシューティング
内容
概要
このドキュメントでは、ソースルート トランスレーショナル ブリッジング（SR/TLB）、およびそのトラブルシューティング情報について説明します。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
ソースルート・トランスレーショナル・ブリッジング
今日のネットワークでは、イーサネット環境がトークンリング環境と混在するのが一般的です。この組み合わせは、多くの論理的な問題をもたらします。1つ目は、イーサネットにはソースルートブリッジング(SRB)に近いものはなく、トークンリングにはルーティング情報フィールド(RIF)があります。 また、トークンリングには機能アドレスがありますが、イーサネットにはブロードキャストが最も多く存在します。
2つの環境を統合するために、シスコはSR/TLBを作成しました。
ルータのインターフェイス（トークンリングとイーサネットの両方）にブリッジグループを追加して、トランスペアレントにトークンリングとイーサネットをブリッジできます。これにより、2つの環境間にトランスペアレントブリッジドメインが作成されます。トークンリング側でソースルートブリッジングが実行されている場合は、問題が発生します。トランスペアレントブリッジングをソースルーティングと結び付ける方法を教えてください。特に、エンドステーションがネットワークを通過するパスを確立する端末であることを考えると、この方法が重要です。
次の図に、このソリューションを示します。
pc_1がpc_3と通信する場合は、ブロードキャスト(FF-FF-FF-FF-FF-FF-FF)パケットを使用してNetBIOS name_queryをワイヤに送信します。問題は、pc_3ステーションが宛先アドレス(C0-00-00-00-00-80)を使用してname_queriesをリッスンし、そのブロードキャストを受信し、name_query（pc_3の定義による）ではないため、NetBIOSに送信しないことです。
そのため、トークンリングからイーサネットへの変換が複雑になる可能性があります。ほとんどの詳細はルータ内で処理され、混乱を引き起こす問題はビットスワッピングです。トークンリングとイーサネットは、さまざまな方法でアダプタにビットを読み込みます。ルータはフレームに入ってビット順序を変更しないため、イーサネット上のMACアドレスはトークンリング上のMACアドレスと異なります。
イーサネットステーションはソースルーテッドエンドステーションとして機能できないため、Ciscoルータがその役割を担います。上記の図に基づいて、ルータがイーサネットからパケットを受信した後に、次のイベントが発生します。
-
cisco1ルータは、イーサネットからパケットを受信します。これはpc_1からhost_1に対するものです。
-
cisco1はhost_1に到達するためにRIFを必要とするため、host_1に到達するパスを決定するエクスプローラを作成します。
-
cisco1は応答を受信した後、（RIFなしで）応答をイーサネットステーションに送信します。
-
pc_1は、交換識別子(XID)をホストMACアドレスに送信します。
-
cisco1はイーサネットパケットを取得し、RIFをホストに接続し、途中でパケットを送信します。
-
このプロセスは続行されます。
このプロセスは、いくつかの条件によって可能になります。まず、ホストに関する限り、イーサネットは疑似リングと呼ばれる場所に配置されています。これは、ルータでsource-bridge transparentコマンドを使用して設定します。
source-bridge transparent ring-group pseudo-ring bridge-number tb-group [oui]
| パラメータ | 説明 |
|---|---|
| ring-group | source-bridge ring-groupコマンドで作成された仮想リンググループです。これは、トランスペアレントブリッジグループに関連付けるソースブリッジ仮想リングです。このリンググループ番号は、source-bridge ring-groupコマンドで指定された番号と一致する必要があります。指定できる範囲は1～4095です。 |
| 疑似リング | ソースルートブリッジドドメインへのトランスペアレントブリッジングドメインを表すために使用されるリング番号。この番号は、ソースルートブリッジドネットワーク内の他のリングで使用されない一意の番号である必要があります。 |
| bridge-number | トークンリングのソースルーテッドの観点から、トランスペアレントブリッジングドメインに至るブリッジのブリッジ番号。 |
| tb-group | ソースルートブリッジドドメインに関連付けるトランスペアレントブリッジグループの番号。このコマンドのno形式は、この機能を無効にします。 |
| oui | （オプション）組織固有識別子(OUI)。次の値を含めることができます。
|
SR/TLBを設定する場合は、まずルータにリンググループが必要です。疑似リングは、イーサネットがトークンリングであることをホスト_1の観点から示します。
次のようにcisco1を設定します。
| 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コマンドが2つあります。
-
show bridge：このコマンドは、透過側を分析するのに非常に便利です。ルータがネットワーク内の特定のデバイスからパケットを受信しているかどうかを示します。
-
show rif：このコマンドは、ルータが宛先MACアドレスのRIFを構築したかどうかを表示します。
トラブルシューティング
この項では、MACアドレスビットスワッピングおよびSR/TLBループのトラブルシューティング方法について説明します。
ビットスワッピング
SR/TLBに関する問題の最も一般的な原因の1つは、MACアドレスビットスワッピングです。この問題は、ルータがイーサネットからトークンリングおよびトークンリングからイーサネットへのMACアドレスのビットスワップを行うためです。その結果、エンドステーションはこれらのフレームを認識できません。次の図で例を示します。
この図では、フレームは送信元MAC(SMAC)と宛先MAC(DMAC)で完全に同じビットパターンを持っています。 ただし、このビットパターンは、トークンリングではイーサネットとは読み取りが異なります。このネットワークでダイレクトフレームを送信できるようにするには、送信する前にフレームをビットスワップする必要があります。
最初に、元のMACアドレスを2進数に変換します。3つの2バイトのセットを個別に使用して、簡単に使用できます。この例では、4000.3745.0001 を使用しています。
4000.3745.0001には次のバイナリ値があります。
0100 0000 0000 0000 0011 0111 0100 0101 0000 0000 0000 0001
各バイトを反転します。文字列全体を反転しないでください。バイト単位の2進数を次に示します。
01000000 00000000 00110111 01000101 00000000 00000001 40 00 37 45 00 01
ビットスワップを行うには、各バイトの最初のビットを最後のビットに移動し、最後のビットが最初になるまで繰り返します。
00000010 00000000 11101100 10100010 00000000 10000000 02 00 EC A2 00 80
ビットスワッピングが完了すると、0200.ECA2.0080という新しいMACアドレスが割り当てられます。
多くのシステムネットワークアーキテクチャ(SNA)イーサネットステーション用のソフトウェアは、自動的にスワップを行います。もし分からなければ、両方の方法でテストするのが最善です。
注：広く使用されているデバイスには「ビットスワップできない」MACアドレスが含まれることがあります。これは、アドレスがスワップまたはスワップされないためです。つまり、リモートFEPアドレスのコーディングに対処する必要はありません。これは、多くのリモートサイトを持つフロントエンドプロセッサ(FEP)環境で一般的です。たとえば、4200.0000.4242はビットスワップ不可能なMACアドレスです。
さらに、トランスペアレントブリッジ部分のルータ自体はMACアドレスをイーサネット形式として扱い、コードのソースルート部分はトークンリング形式として扱います。FDDIのようなシナリオでは、フレームが完全に同じ読み取りであるにもかかわらず、ルータコードはMACアドレスがすべて反転していることを示します。
トークンリングとイーサネット間の DHCP/BOOTP サポート
SR/TLBまたはトランスペアレントブリッジング(TB)を使用しており、サーバとクライアントが異なるメディアタイプのLAN（標準または非標準）にある場合、DHCP/BOOTPはサポートされません。 たとえば、クライアントがトークンリングLANにあり、サーバがイーサネットLANにある場合です。これは、クライアントのMACアドレスがBOOTP要求パケット(chaddrフィールド)に含まれているためです。
たとえば、MACアドレスが4000.1111.0000のクライアントがBOOTP要求を送信し、パケットがSR/TLBまたはTBブリッジを通過すると、MACヘッダーのMACアドレスはビットスワップされますが、BOOTP要求に埋め込まれたMACアドレスは変更されません。その結果、BOOTPパケットがサーバに到達し、サーバがBOOTP応答で応答します。このBOOTP応答は、ブロードキャストフラグに応じて、ブロードキャストアドレスまたはクライアントのMACアドレスに送信されます。このブロードキャストフラグが設定されていない場合、サーバはchaddrフィールドで指定されたMACアドレスにユニキャストパケットを送信します。イーサネット側のサーバは、MACアドレス4000.1111.0000に応答を送信します。パケットはブリッジを通過し、ブリッジはMACアドレスをビットスワップします。したがって、トークンリング側のBOOTP応答は宛先MACアドレス0200.8888.0000で終わります。したがって、クライアントはこのフレームを認識しません。
ループ
SR/TLBの問題のもう1つの原因は、ルータが同じイーサネットへの異なるパスを使用できないことです。
次の図は、セミループを含んでいます。
パケットは同じ疑似リングから発信され、同じリンググループ内にあるため、トークンリング環境から着信するパケットはイーサネットに送信されます。これにより、2番目のSR/TLBルータは、特定のMACアドレスがローカルイーサネット上に存在すると認識します。そのため、イーサネット上のステーションは、そのステーションに再び到達できません。
また、cisco1は同じパケットを受け取り、探索パケットをネットワークに送信します。これにより、そのステーションがイーサネット上にあるかのように見えます（トークンリング環境の場合）。
次の図は、一般的なシナリオを示しています。
この場合、巨大なループを作成するために必要なパケットは1つだけです。パケットはイーサネット側でもトークンリング側でも廃棄されないため、パケットは無限にループしたパターンになります。
デバッグ
SR/TLBのデバッグは非常に限られています。1つのオプションは、フィルタを使用してトークンリングをデバッグし、パケットがルータを通過しているかどうかを確認することです。詳細は、『ローカルソースルートブリッジングの説明とトラブルシューティング』を参照してください。
フィードバック