ソースルート・トランスレーショナル・ブリッジ ングの理解およびトラブルシューティング
目次
概要
このドキュメントでは、ソースルート トランスレーショナル ブリッジング（SR/TLB）、およびそのトラブルシューティング情報について説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
ソースルート・トランスレーショナル・ブリッジング
それは今日のネットワークのトークンリング環境と混合するためにイーサネット環境のためによくあります。 このミックスはいくつかの論理的な問題を持って来ます。 第 1 はイーサネットにソースルート ブリッシングの近くで何もない、トークン リングにルーティング情報フィールド （RIF）がありますことであり。 また、トークン リングはイーサネットに最も頻繁にブロードキャストがあるが、機能アドレスを備えています。
2 つの環境を結合できるために Cisco は SR/TLB を作成しました。
ルータのインターフェイスに（トークン リングおよびイーサネット両方）、透過的にトークン リングおよびイーサネットを繋ぐためにブリッジグループを追加できます。 これは 2 つの環境間の Transparent Bridge ドメインを作成します。 トークンリング側がソースルート ブリッシングを実行する場合、問題があります。 端末がネットワークによってパスを確立する物であることどのように特に与えられる source-routing のトランスペアレント ブリッジングを、結びますか。
このダイアグラムはソリューションを説明します:
pc_1 は pc_3 と通信したいと思うときネットワークにブロードキャスト（FF-FF-FF-FF-FF-FF）パケットの NetBIOS name_query を送信 します。 問題はそれが name_query ではないので pc_3 ステーションが宛先アドレスとの name_queries をの（C0-00-00-00-00-80）受信している、およびそのブロードキャストを受信し、NetBIOS にそれを送信 しませんことです（pc_3 定義によって）。
こういうわけでトークン リングからのイーサネットへの変換は複雑である場合もあります。 詳細のほとんどはルータの中で処理され、混合を作成する問題はビットスワップしています。 トークン リングおよびイーサネットはさまざまな方法のアダプタにビットを読込みました。 ルータはフレームに入らないし、ビット順序を変更します、従ってイーサネットの MAC アドレスはトークン リングの MAC アドレスと異なっています。
イーサネットステーションはソースルート端末として機能できません従って Ciscoルータはそのロールを担います。 前のダイアグラムに基づいて、これらのイベントはルータがイーサネットからパケットを受信した後発生します:
-
cisco1 ルータはイーサネットからパケットを受信します。 これは pc_1 から host_1 にあります。
-
cisco1 は RIF が host_1 に達することを必要とします従って host_1 に達するためにパスを判別するようにエクスプローラを作成します。
-
cisco1 は応答を受け取った後、イーサネットステーションへの応答を（RIF なしで）返します。
-
pc_1 はホスト MAC アドレスに交換識別情報 （XID）を送信 します。
-
cisco1 はイーサネットパケットを取得し、ホストに RIF を接続し、方法のパケットを送信 します。
-
このプロセスは続きます。
複数の条件はこのプロセスを可能にします。 最初にホストに関する限りでは、イーサネットは知られているものがに pseudo-ring として坐っています。 これはルータの 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 です。 |
| pseudo-ring | ソースルートブリッジドメインに透過型ブリッジングドメインを表すのに使用するリング 番号。 この数はソースルートブリッジネットワークで他のどのリングによっても使用しない固有の番号である必要があります。 |
| bridge-number | それが透過型ブリッジングドメインに導くトークン リング ソースルート観点からブリッジのブリッジ番号。 |
| tb-group | ほしいと思う透過型ブリッジグループの数はソースルートブリッジドメインに結びました。 このコマンドの no 形式はこの機能をディセーブルにします。 |
| oui | （オプションの）これらを含む値がある場合がある組織固有識別子 （OUI）、:
|
SR/TLB を設定しているとき、最初にルータのリンググループを持たなければなりません。 pseudo-ring は host_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 はプロセス交換されました。 fast-switching を消すために、このコマンドを発行して下さい:
no source-bridge transparent ring-group fastswitch
show コマンド
SR/TLB と重要の 2 つの show コマンドがあります。
-
show bridge -このコマンドは透過的 な 側面を分析して非常に役立ちます。 ルータがネットワークの特定のデバイスからパケットを受信するかどうか示します。
-
show rif -このコマンドはルータが宛先MAC アドレスのための RIF を構築するかどうか示したものです。
トラブルシューティング
これは論議します MAC アドレス ビットスワッピングおよび SR/TLB ループを解決する方法を区分します。
ビットスワッピング
SR/TLB における問題のもっとも一般的な原因の 1 つは MAC アドレス ビットスワッピングです。 問題はルータがイーサネット トークン リングへのとトークン リングからのイーサネットへの MAC アドレスのビットスワップをするので発生します。 結果は端末がそれらの帯を認識できないことです。 次の図で例を示します。
このダイアグラムでは、フレームに発信元MAC （SMAC）および送信先MAC （DMAC）で正確のが同じビット 構成あります。 しかしこのビット 構成はイーサネットのよりトークン リングで、別様に読まれます。 送信 される前にこのネットワークを渡る誘導帯を送信できるためにそれらをビットスワップして下さい。
するべき最初の事柄はバイナリへのオリジナル MAC アドレスを変換することです。 もっと簡単にするのに 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
ビットスワップをするために、最初のビットをバイトのそれぞれの最後に移動し、最後のビットが第 1 になるまでこれを繰り返して下さい:
00000010 00000000 11101100 10100010 00000000 10000000 02 00 EC A2 00 80
ビットスワッピングが行われた後、0200.ECA2.0080 である新しい MAC アドレスがあります。
多くのシステム ネットワーク アーキテクチャ （SNA） イーサネットステーションのためのソフトウェアはスワップを自動的にします。 確かに知らない場合、それをテストすることが最善両方の方法です。
注: 時々ネットワークはアドレスが交換されるか、または非スワップ同じであるので、広く利用されたデバイスのための「ビットスワップ不可能 な」MAC アドレスが含まれています。 これはリモート FEP アドレスの符号化を取扱う必要はないことを意味します。 これは多くのリモートサイトが付いているフロントエンド プロセッサ （FEP）環境でよくあります。 たとえば、4200.0000.4242 は非ビットスワップ MAC アドレスです。
さらに、ルータ自体はトークン リング 形式としてイーサネットフォーマットとして- Transparent Bridge 部分で- MAC アドレス、およびコードのソースルート一部を扱いますそれらを扱います。 帯が同じ丁度読まれる FDDI のようなシナリオでは、ルータコードは完全に逆になる MAC アドレスを示します。
トークンリングとイーサネット間の DHCP/BOOTP サポート
DHCP/BOOTP は SR/TLB か Transparent Bridging （TB）を使用し、サーバおよびクライアントが異なるメディアタイプ LAN にあるときサポートされません（標準か規範外）。 たとえば、クライアントがイーサネット LAN のトークンリング LAN およびサーバにある場合。 これはクライアントが Bootp要求 パケット（chaddr フィールド）で MAC アドレスが含まれているという理由によります。
たとえば、MAC アドレス 4000.1111.0000 のクライアントが Bootp要求を送信 し、パケットが SR/TLB または TB ブリッジを通過するとき、MACヘッダーの MAC アドレスはビットスワップされますが、Bootp要求で組み込まれる MAC アドレスは変えないでおきます。 その結果、BOOTPパケットはサーバに到達しと、サーバは BOOTP応答と応答します。 この BOOTP応答はブロードキャスト フラグによってブロードキャスト アドレスまたはクライアントの MAC アドレスに、送信 されます。 このブロードキャスト フラグが設定 されなければ、サーバは chaddr フィールドで規定 される MAC アドレスにユニキャスト パケットを送ります。 イーサネット側のサーバは MAC アドレス 4000.1111.0000 への応答を返します。 パケットはブリッジを通過し、ブリッジは MAC アドレスをビットスワップします。 従って、トークンリング側の BOOTP応答は 0200.8888.0000 の宛先MAC アドレスで終ります。 その結果、クライアントはこのフレームを認識しません。
ループ
SR/TLB 問題のもう一つの原因は同じイーサネットに異なるパスを使用する割り当てルータできないことことです。
このダイアグラムは半ループが含まれています:
パケットが同じ pseudo-ring から起き、同じリンググループにあるので、トークンリング環境から来ているパケットはイーサネットに送信されます。 これにより第 2 SR/TLB ルータはある特定の MAC アドレスがローカルイーサネットにあることを信じます。 このように、イーサネットのステーションはそのステーションに再度達することができません。
また、cisco1 はこと同じパケット 奪取 し、（トークンリング環境にあるとき）イーサネットにあるようにステーションは現われること作ることができるネットワークにエクスプローラを差し向けます。
このダイアグラムは一般的 な シナリオを説明します:
この場合、それは巨大なループを作成するために 1 パケットだけ必要とします。 パケットがイーサネット側かトークンリング側によって廃棄されないので、パケットはループしたパターンで際限なく入ります。
デバッグ
SR/TLB のためのデバッグは非常に限られています。 1 つのオプションはパケットがルータを通してそれを作っているかどうか見るためにトークン リングを、フィルターとデバッグすることです。 詳細については知識およびトラブルシューティング Local Source-Route Bridging を参照して下さい。
フィードバック