IEEE 標準 802.2 では、802.3、802.5、およびその他のネットワークで使用されるデータリンク制御層として論理リンク制御(LLC)が定義されています。IBM は当初、LLC を IBM Token Ring アーキテクチャのサブレイヤとして設計しました。
次の項目に関する知識があることが推奨されます。
LLC の基本を理解している。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
LLC レイヤでは「コネクションレス型」および「コネクション型」のデータ転送が可能です。
コネクションレス型データ転送は、一般にLLCタイプ1、またはLLC1と呼ばれます。コネクションレス型サービスでは、データリンクやリンクステーションを確立する必要はありません。サービス アクセスポイント(SAP)を有効にすると、コネクションレス型のサービスを使用しているリモート SAP と SAP の間で情報を送受信できるようになります。コネクションレス型サービスにはモード設定コマンド(SABME など)はないため、ステート情報を保持する必要はありません。
コネクション型のデータ転送は、LLCタイプ2またはLLC2と呼ばれます。コネクション型のサービスでは、リンクステーションの確立が必要です。リンク ステーションを確立すると、モード設定コマンドが必要になります。そのため、各リンク ステーションはリンク ステート情報を保持する必要があります。
LLC2 は、LAN または仮想 LAN でシステム ネットワーク アーキテクチャ(SNA)が実行される場合に実装されます。また、LLC2 は直接フレームリレーにカプセル化されます。ルータでは LLC2 フレームを単に渡すだけの場合もありますが、ルータで LLC2 リンクステーションを実装している場合もあります。NetBIOS も LLC を使用します。NetBIOS は LLC1 を使用してリソースを特定します。その後、LLC2 コネクション型セッションが確立されます。
次の機能が有効にされている場合、ルータで LLC2 スタックが実装されます。
データリンク スイッチング(DLSw)(LAN への接続)
ローカル ACK を使用するリモート ソースルート ブリッジング(RSRB)
チャンネル インターフェイス プロセッサ(CIP)
拡張分散ネットワーク機能(SNASwitching(SNASw))
LCC 変換のための Synchronous Data Link Control(SDLC)(SDLLC)
LLC の基本的な知識を有していれば、ほとんどの問題を特定し、解決することができます。これは、保持する必要のあるリンク ステートまたはセッションがないため、LLC1 では問題がほとんど発生しないためです。
一方 LLC2 では、次の 2 種類のカテゴリの問題が発生する可能性があります。
セッションが確立しない
確立されたセッションで断続的に不具合が発生する
これらの問題を解決するには、次の項目について理解している必要があります。
LLC フレームフォーマット
LLC2 モードおよびセッション確立
LLC2 非同期平衡モード操作
LLC2 エラー状態
このセクションでは、LLC のフレーム形式の情報を提供します。
DSAP/SSAP | Control | |||
---|---|---|---|---|
宛先サービス アクセス ポイント(1 バイト) | 制御フィールド:番号なし(1 バイト) | |||
dddd ddxx xxxx xx1x xxxx xxx1 |
Dest. Addr. IEEE Defined Group Address |
CCCC CC11 000F 1111 010P 0011 011F 0011 011P 1111 100F 0111 101z 1111 111z 0011 |
xx-xx 0F-1F 43-53 63-73 6F-7F 87-97 AF-BF E3-F3 |
Unnumbered format Disconnect Mode Disconnect Unnumbered Ack. SABME Frame Reject XID Test |
送信元サービス アクセス ポイント(1 バイト) | 制御フィールド:監視(2 バイト) | |||
ssss ssxx xxxx xx1x xxxx xxx1 |
Source Address IEEE defined Response LPDU |
CCCC CC01 0000 0001 0000 0101 0000 1001 |
xx-xx 01-xx 05-xx 09-xx |
Supervisory Format Receiver Ready Receiver Not Ready Reject |
制御フィールド:情報フレーム(2 バイト) | ||||
ssss sss0 |
xxxx |
Information format |
||
P =「1」に設定されているポール ビット F =「1」に設定されている最終ビット Z =「0」または「1」のいずれかに設定されているポール/最終ビット |
LLC フレームは、LLC プロトコル データ ユニット(LPDU)と呼ばれ、次のようにフォーマットされます。
DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)
宛先サービス アクセス ポイント(DSAP; Destination Service Access Point)では、LPDU が宛先とする SAP が識別されます。DSAP は、次に示すように、6 個のアドレス ビット、ユーザ ビット(U)、個別/グループ(I/G)ビットで構成されています。
D-D-D-D-D-D-D-I/G
U ビットは、アドレスが IEEE で定義されたもの「1」か、ユーザ定義のもの「0」かを示します。 I/G ビットは、SAP がグループ アドレスであるか「1」、個別のアドレスであるか「0」を示します。 シスコでは、これらのビットはどちらもあまり重要視していません。ユーザが実際に知っておく必要があるのは、DSAP が LPDU の宛先になることだけです。このことは、多くの場合に当てはまります。
送信元サービス アクセス ポイント(SSAP; Source Service Access Point)では、LPDU の送信元である SAP が識別されます。SSAP は、次に示すように、6 個のアドレス ビット、ユーザ ビット(U)、コマンド/応答(C/R)ビットで構成されています。
S-S-S-S-S-S-U-C/R
U ビットは、アドレスが IEEE で定義されたもの「1」か、ユーザ定義のもの「0」かを示します。 C/R ビットは、LPDU がコマンドか応答かを示します。LPDU フレームが受信されると、C/R ビットは SSAP の一部とは見なされなくなります。したがって、SSAP は通常は左側の 7 ビットだけであると見なされます。
LPDU 制御フィールドには、コマンド、応答、シーケンス番号情報が含まれます。特定の LLC2 セッションで何が起こるか判断するために、制御フィールドをデコードする方法を理解する必要があります。ただし、デコード情報はすぐに使用できます。
フレームには次の 3 種類があります。
I フレーム
S フレーム(スーパーバイザリ フレーム)
番号なしフレーム
各タイプで制御フィールドの形式が異なる場合がありますが、これは制御フィールドの 2 ビットの検査によって簡単に識別できます。
X-X-X-X-X-X-X-0 = I Frame X-X-X-X-X-X-0-1 = Supervisory Frame X-X-X-X-X-X-1-1 = Unnumbered frame
以降のセクションでは、制御フィールドの各タイプについて説明します。
I フレームは、リンク ステーション間で、情報(コネクション型)を含む連番付きの LPDU を転送することができます。I フレームの形式には、NS カウントと NR カウントが含まれます。NS カウントは、現在転送されている LPDU のシーケンス番号(モジュロ 128)です。NR カウントは送信元が受信を待機している次の LPDU I フレームのシーケンス番号です。後での説明のために、NR は「next receive」を意味すると覚えておいてください。
NS-NS-NS-NS-NS-NS-NS-0-NR-NR-NR-NR-NR-NR-P/F
P/F ビットは、コマンド LPDU では P ビット、応答 LPDU では F ビットと呼ばれます。P/F ビットは、コマンド LPDU に設定され、リモート リンク ステーションに対し、このビットがセットされた応答を送信するよう要求します。P ビットがセットされた送信コマンドに対しては、F ビットがセットされた応答が 1 つだけ受信されます。エラー回復に関連する P/F ビットについては他にも多くの使用方法がありますが、ここでは一般的なルールに言及するにとどめます。
スーパーバイザリ フレームは、監視制御機能を実行します。たとえば、I フレームの確認応答(RR)、I フレームの再送信の要求(REJ)、I フレームの一時停止の要求(RNR)を行います。スーパーバイザリ フレームには情報フィールドは含まれません。そのため、スーパーバイザリ フレームは送信側ステーションの NS に影響を与えず、従って NS フィールドは含まれません。次に、スーパーバイザリ フレームの形式を示します。
0-0-0-0-S-S-0-1-NR-NR-NR-NR-NR-NR-NR-P/F
「S」ビットは S フレームのタイプを示します。
B'00' = Receiver Ready
ステーションは RR を表示してステーションが受信可能であることを示し、受信予定である次の I フレームの NR カウントを含めます。ステーションが RR のフレームを送信する場合、ステーションは、NR - 1 までのリモート ステーションからの番号付き I フレームの受信を確認応答します。
B'01' = Receiver Not Ready
ステーションは RNR を表示してステーションが一時的に受信不可能であることを示します。RNR にも、RR と同じルールに従う NR カウントが含まれます。RNR の一時的な期間は、必ずしもネットワークでの問題を示すものではありません。RNR が続く場合は、端末の輻輳を探します。
B'10' = Reject
ステーションは REJ を表示して、NR カウントで示される数から開始される I フレーム LPDU の再送信を要求します。REJ は重大な問題を示すものではなく、回復可能であることを意味します。 多くの REJ コマンドが表示されたら、反対方向に対して損失した(ドロップされた)I フレームを探します。Frame Reject(FRMR)と REJ を混同しないでください。FRMR は番号なしフレームで、常に重大な問題を示します。
番号なしフレームでは、モードの設定コマンドと応答など、リンクの制御機能が提供されます。場合によっては、番号なし情報フレームも送信できます。番号なしフレームは、長さが 1 バイトしかありません。このフレームには NS カウントまたは NRS カウントに関するフィールドはありません。次に、番号なしフレームの形式を示します。
M-M-M-P/F-M-M-1-1
「M」ビットは番号なしフレームのタイプを示します。
B'00011' = DM 応答(0x1F)
リンク ステーションは、非同期切断モードであることをレポートする DM 応答を送信します。これは、リンクがアクティブでないことを意味します。アクティブなリンク ステーションが、突然 DM の送信を開始したら、そのリンク ステーションはリセットされます。
B'01000' = DISC コマンド(0x53)
リンク ステーションは、DISC を送信して非同期平衡モードを終了します。DISC コマンドは、リモート リンク ステーションに操作が中断されたことを通知します。DISC コマンドに対する正しい応答は、UA(ステーションが ABM の場合)、または DM(ステーションが ADM の場合)です。
B'01100 '= UA 応答(0x73)
リンク ステーションは、SABME および DISC コマンドに応じて UA を送信します。
B'01111' = SABME コマンド(0x7F)
リンク ステーションは、SABME を送信して非同期平衡モードでのデータ転送を開始します。SABME に対する正しい応答は UA です。ステーションで SABME コマンドが受信されると、NR カウンタと NS カウンタがゼロにリセットされます。送信元のステーションは、UA 応答を受信したときに同様に動作します。
B'10001' = FRMR 応答(0x87)
リンク ステーションは、他のリンク ステーションから受信した LPDU のエラーをレポートする Frame Reject 応答を送信します。FRMR が発生したときには、FRMR を送信しているステーションで回復不可能なエラーが検出されています。これは、エラーの原因ではありません。FRMR エラーが発生した後に着信したフレームは、DISC または SABME が受信されるまですべて無視されます。
FRMR 応答には、FRMR の状況の原因についての情報が含まれます。
バイト 0 および 1 には、フレーム拒否を引き起こす LPDU の制御フィールドの内容が含まれます。バイト 2 および 3 には、それぞれ NS および NR カウントが含まれます。バイト 4 には、次に示すように、エラーのタイプを特定する複数のビットが含まれます。
0-0-0-V-Z-Y-W-X
V ビットは、バイト 0 および 1 の制御フィールドで搬送された NS 番号が無効であることを示しています。NS は、最後の NS と最大受信ウィンドウ サイズの合計以上であるとき以外は無効になります。この状態が生じた場合には、リンク ステーションは FRMR 応答ではなく、REJ LPDU を送信します。
Z ビットは、バイト 0 および 1 で示す制御フィールドで搬送された NR では、次の I フレームまたはすでに送信されたものの確認応答されていない I フレームのいずれも参照されてはいないことを意味します。
注:同じNRカウントを複数回受信することは問題ありません。
NR カウントが無効になるのは、すでに確認応答済の I フレームを参照している場合か、まだ送信されていない I フレームにスキップしている場合だけです。このタイプのエラーでは、前者が一般的です。このタイプのエラーが発生した場合は、通常はフレームの順序が誤って受信されたことを意味しており、フレームを誤った順序で搬送しているネットワークを調べる必要があります。これは送信リンク ステーションが順不同で送信した可能性がありますが、発生するのは非常にまれです。
Y ビットは、受信した LPDU 内の I フィールドの長さが、有効なバッファ容量を超過していることを意味します。この状況が発生した場合は、ネットワークではなく端末の問題を調べます。
X ビットは、LPDU に I フィールドが含まれていてはならないときに含まれているか、5 バイトに満たない FRMR 応答が受信されたことを意味しています。これは、ネットワークの問題ではなく、端末の問題であることを示しています。
W ビットは、サポート外の LPDU が受信されたことを示しています。これは端末の問題です。
B'10111' XID コマンドまたは応答
リンク ステーションは、XID コマンドを使用して、送信ノードの特性を伝送し、リモート リンク ステーションに XID 応答で応答させます。リンク ステーションは、SNA 形式などのさまざまな形式で XID を送受信できます。
B'11100' TEST コマンドまたは応答
リンク ステーションは、TEST コマンドを送信して、リモート リンク ステーションが TEST 応答にできるだけ早く応答するようにします。TEST コマンドは、通常はソースルート ブリッジング環境でのパス ディスカバリのために使用されます。
値 | 番号なしフレーム |
---|---|
0x0F または 0x1F | 切断モード(DM)応答 |
0x43 または 0x53 | 切断(DISC)コマンド |
0x63 または 0x73 | 番号なし確認応答(UA) |
0x6F または 0x7F | Set Asynchronous Balanced Mode(SABME)コマンド |
0x87 または 0x97 | Frame Reject(FRMR)応答 |
0xAF または 0xBF | Exchange ID(XID)コマンドまたは応答 |
0xE3 または 0xF3 | テスト(TEST)コマンドまたは応答 |
値 | S フレーム(スーパーバイザリ フレーム) |
---|---|
0x01 | Receiver Ready(RR) |
0x05 | Receiver Not Ready(RNR) |
0x09 | Reject(REJ) |
値 | 情報フレーム |
---|---|
0bnnnnnnn0 | 情報フレーム(INFO) |
LLC2 の動作には次の 2 種類のモードがあります。
拡張非同期平衡モード
非同期切断モード
ABME は、2 つのリンク ステーション間の動作の平衡モードです。平衡モードは、どのステーションも、他のリンク ステーションとは関係なくコマンドをいつでも送信可能であることを示します。これは、非平衡モードで動作する SDLC とは対照的です。非平衡モードでは、セカンダリ ステーションは、データを送信する前に、プライマリによってポーリングされるために待機する必要があります。平衡モードの動作の結果として、従来的な意味での LLC2 回線では、ポーリングは発生しません。ステーションはセッションを維持するためにキープアライブを送信しますが、SDLC のような最適なパフォーマンスの場合はこれらを頻繁に送信する必要はありません。そのため、キープアライブ タイマーの値は通常は 10 秒以上です。端末では、オーバーヘッドを減らすためにこのキープアライブ タイマーの値を増やすことができることに注意してください。キープアライブ タイマーの値を増やしても、スループットまたは応答時間に影響はありません。
ステーションは、SABME コマンドと UA を送受信した後に ABME を開始します。ABME になると、ステーションは番号付き情報フレームを送受信できるようになります。
ステーションが ABME を終了する前および後は、ステーションは非同期切断モードです。ADM では、リンクが論理的に切断されています。そのため、I フレームまたはスーパーバイザリ フレームを送信することはできません。ステーションは次のような状況で ADM を開始します。
DISC コマンドを受信
リンクステーションがアクティブ化されている
DM 応答を受信
リトライの制限を使い果たした
次に、リンク ステーションのアクティベーション シーケンスの例を示します。
To1 4000.0840.0001 8800.5a94.7d94 SABME F0F07F To1 4000.0840.0001 8800.5a94.7d94 UA F0F173 To 1 4000.0840.00018800.5a94.7d94 RR nr=0 F0F001 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=0 ns=0 F0F00000 ... To1 4000.0840.0001 8800.5a94.7d94 RR nr=1 F0F101 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=1 ns=1 F0F00202 ... To1 4000.0840.0001 8800.5a94.7d94 RR nr=2 F0F101 To1 4000.0840.0001 8800.5a94.7d94 INFO nr=2 ns=2 F0F00000 ...
ASBM で動作しているステーションには、プライマリ ステーションやセカンダリ ステーションという厳格な概念はありません。ステーションでは、データ転送のためにポーリングしたり、されたりする必要はありません。ステーションではあらゆるステーションに非同期でデータを転送できます。ステーション同士はピアツーピアの関係にあります。
プライマリとセカンダリの厳密な概念はありませんが、送信側ステーションは、送信される各番号付き情報フレームに対して、呼び出されたリンク レベル応答と、受信側ステーションからの確認応答が必要です。ステーションは、確認応答されなかったフレームの数が制限に達するまで、別のステーションに I フレームを送信し続けることができます。この数値は「ウィンドウサイズ」と呼ばれ、通常は7に設定されます。送信側ステーションが停止して応答を待つ必要を避けるために、遅延の多い回線のウィンドウサイズを増やすことができます。これは通常、特に LLC がローカルで確認応答される状況では、必要ありません。送信側ステーションが自身の送信ウィンドウ サイズに達したときには、ポール ビットを設定して、受信側ステーションに強制的に応答を送信させるようにします。ルータでは、ウィンドウ サイズは llc2 local-window と呼ばれます。
受信側ステーションには、一定数の I フレームが到着するか、タイマーが切れるまで確認応答を保留するオプションがあります。これらのパラメータは、それぞれ N3 および T2 と呼ばれます。これにより、1 つの RR フレームで複数のフレームに確認応答したり、1 つの I フレームの先頭で確認応答を送ることができます。シスコでは、N3 カウンタを llc2 ack-max と呼びます。デフォルト値 3 は、ルータが 3 つの I フレームを受信するか、T2 タイマーまたは llc2 ack-delay-time が切れるまで、ルータが確認応答を保留することを示します。
パートナー ステーションを考慮せずにこれらのステーションのパラメータを変更すると、応答時間およびスループットに影響する可能性があります。たとえば、送信側ステーションの local-window が 5 に設定され、受信側ステーションの ack-max の値が 7 で ack-delay-time の値が 500 ミリ秒の場合、どうなるかについて考えてみます。
この場合、送信側ステーションは 5 フレームを送信し、続行する前に確認応答を待機します。受信側は 7 フレームが受信されるまで確認応答を保留するため、500 ミリ秒の遅延時間が経過するまで確認応答は送信されません。受信側ステーションで ack-max の値を下げると、パフォーマンスが劇的に向上します。
別の共通 LLC2 パラメータは Ti タイマーと呼ばれます。ルータではこれを llc2 idle-time と呼びます。Ti タイマーは、I フレームが送信されない期間中に LLC2 セッションをアクティブ状態に維持するために使用します。この値を下げても、スループットとパフォーマンスが向上することはありません。Ti タイマーが切れると、poll ビットをオンにした状態で RR フレームが送信され、受信側からの応答を促します。ステーションが応答しない場合、ステーションでは llc2 tpf-time の後に llc2 n2 で定義された再試行回数に達するまで再試行が行われます。その時点で、セッションが切断(クリア)されます。
アイドル時間を長くすると、LLC2 回線のオーバーヘッドを減らすことができますが、これをローカル確認応答の代わりとして調整することもできます。200 の DSPU が NCP に接続されている例について考えてみます。各 PU は独立した LLC2 セッションを維持します。それぞれが 10 秒ごとにキープアライブを送信した場合、1 秒ごとに 20 フレームのオーバーヘッドが発生します。アイドル時間を 30 秒に伸ばすと、オーバーヘッド フレームの量は 1 秒ごとに 6.67 フレームに減ります。このアプローチの欠点は、パートナーが到達不能であることをステーションが検出するのに時間がかかることです。ただし、状況によっては、これは大変役に立ちます。
コマンド | デフォルト | 説明 |
---|---|---|
llc2 ack-delay-time>/b> msec | 100 | ack-max の値に到達して確認応答を送信するまで応答を待機する時間。 |
llc2 ack-max カウント | 3 フレーム | 確認応答を送信するまでに受信するフレーム数。 |
llc2 idle-time ミリ秒 | 10,000 | アイドル時間中のポーリング間隔時間。 |
llc2 local-window カウント | 7 フレーム | 応答を待機するまでに送信するフレーム数。 |
llc2 n2 カウント | 8 リトライ | 確認応答のない I フレームまたはポールが送信される回数。この回数だけ応答がない場合は、セッションを終了。 |
llc2 t1-time ミリ秒 | 1,000 | 応答を待機する時間数。この時間内に応答がない場合は I フレームを再送信。この時間は、ラウンドトリップ遅延に見合うように十分に長くする必要があります。 |
llc2 tbuzy-time ミリ秒 | 9600 | RNR を送信したステーションをポーリングするまで待機する時間数。ステータスをクリアする前にビジー状態が異常に長期間続いたステーションの値を増やす場合にのみ、値を変更します。 |
llc2 tpf-time ミリ秒 | 1,000 | 最終的な応答を待機する時間。この時間内に応答がない場合はポール フレームを再送信。 |
llc2 trej-time ミリ秒 | 3200 | REJ を送信した後、正しいフレームを待機する時間数。 |
show llc コマンドを使用して、これらのパラメータの値を確認することができます。
ibu-7206#sh llc LLC2 Connections: total of 1 connections TokenRing3/0 DTE: 4001.68ff.0000 4000.0000.0001 04 04 state NORMAL V(S)=5, V(R)=5, Last N(R)=5, Local window=8, Remote Window=127 akmax=3, n2=8, Next timer in 8076 xid-retry timer 0/60000 ack timer 0/1000 p timer 0/1000 idle timer 8076/10000 rej timer 0/3200 busy timer 0/9600 akdelay timer 0/100 txQ count 0/2000
いずれかの終端にトークン リング LAN がある一般的な DLSw+ ネットワークの場合、LLC2 パラメータの設定は発信トークン リング インターフェイスで行われます。
この例では 2 つの別個の LLC2 セッションがあります。そのため、次に示すように LLC2 パラメータを設定します。
hostname dlsw1 ! source-bridge ring-group 100 ! dlsw local-peer ... dlsw remote-peer ... ! interface token-ring 0 source-bridge 10 1 100 llc2 tpf-timer 2000 llc2 n2 20 hostname dlsw2 ! source-bridge ring-group 100 ! dlsw local-peer ... dlsw remote-peer ... ! interface token-ring 0 source-bridge 20 1 100 llc2 tpf-timer 2000 llc2 n2 20
注:次のスキムされた設定は、関連するLLC2パラメータ設定のみを示しています。
LLC2 パラメータ設定は、LLC2 パラメータを FEP(DLSw1 ルータへ)と PC(DLSw2 ルータへ)に一致させる必要があります。 中央のサイトの DLSw+ ピアが CIP ルータ上にある場合は、設定はやや異なります。
リモートの DLSw+ ルータの設定は変更しないままにしておきます。ただし、中央サイトの LLC2 セッションは、IOS の CIP と LLC2 スタックの間にあります。CIP はメインフレームを表しています。そして、メインフレームから IOS に対する LLC2 パラメータは、LAN トークン リング(CIP)のアダプタで設定されています。 IOS からメインフレームに対する LLC2 パラメータは、発信インターフェイスで設定されています。これはつまり、インターフェイス チャネル x/2(CIP 用)とインターフェイス チャネル x/0(xCPA 用)になります。たとえば、次のようになります。
hostname dlsw1 ! source-bridge ring-group 100 ! dlsw local-peer ... dlsw remote-peer ... ! interface channel 0/2 llc2 tpf-timer 2000 llc2 n2 20 lan tokenring 0 source-bridge 10 1 100 adapter 0 4000.7513.0000 llc2 tpf-timer 2000 llc2 n2 20
注:次のスキムされた設定は、関連するLLC2パラメータ設定のみを示しています。
CIP ルータが LAN を介してローカル ステーションに接続された場合は、CIP アダプタの下の LLC2 パラメータのみが必要です。これらの LLC2 パラメータは、PC のパラメータと照合されます。インターフェイス チャネル 0/2 の下の LLC2 パラメータはどれも非効率的です。
hostname rtr1 ! source-bridge ring-group 100 ! interface channel 0/2 lan tokenring 0 source-bridge 10 1 100 adapter 0 4000.7513.0000 llc2 tpf-timer 2000 llc2 n2 20
注:次のスキムされた設定は、関連するLLC2パラメータ設定のみを示しています。
デバイスがブリッジ グループを介して DLSw+ に接続されると、LLC2 パラメータは次に示すように DLSw+ ブリッジグループ ステートメントで設定されます。
hostname dlsw2 ! dlsw local-peer ... dlsw remote-peer dlsw bridge-group 1 llc2 tpf-timer 2500 n2 20 ! interface ethernet 0 bridge-group 1 bridge 1 protocol ieee
注:次のスキムされた設定は、関連するLLC2パラメータ設定のみを示しています。
注:LLC2はethernet 0インターフェイスで設定できますが、これらのパラメータは無効です。DLSw ブリッジグループ LLC2 は、Cisco IOS ソフトウェア リリース 11.3 の新機能です。
ルータが端末として設定されている場合(たとえば、SNASw および DSPU)、発信インターフェイスで LLC2 パラメータを設定する必要があります。すべての仮想インターフェイスが LLC2 パラメータの設定をサポートしているわけではないことに注意してください。以下に、いくつかの例を示します。
注:次のスキムされた設定は、関連するLLC2パラメータ設定のみを示しています。
hostname snasw1 ! Interface fastethernet 0/0 llc2 tpf-timer 2000 llc2 n2 20 ! snasw cpname neta.snasw1 snasw port FASTETH0 FastEthernet0/0 conntype nohpr
LLC2 セッションでフレームがときどき失われたり、フレームの順序が変わるなどのエラーが発生することは普通であり、回復が可能です。この結果は通常は REJ となり、フレームが再送信されます。再送信が頻繁に行われる場合はエラーの可能性があるため、その原因を特定し、問題を解決する必要があります。再送信が頻繁に行われる原因には、ドロップ、複数のパス、輻輳、過剰な遅延が考えられます。
LLC2 で生じるエラーの中には、回復が不可能で、常にセッションを停止させるものがあります。このようなエラーは、プロトコル違反だけです。これらはステーションが未定義の制御フィールドまたはその他の誤った情報を送信した場合に発生する可能性があります。これらのプロトコル違反が発生すると、ステーションは FRMR 応答を送信する場合があります。FRMR 応答を送信したステーションは、ほとんどの場合は違反者ではなく、単なるメッセンジャです。FRMR には、FRMR が送信された理由を示す情報が含まれています。最も一般的なのは、ステーションが他のステーションに対し、すでに確認応答が行われた I フレームを再送信するよう要求した場合です。ステーションはフレームを再送信できないため(すでに廃棄しているため)、LLC セッションを終了するしかありません。このようなタイプのエラーが発生したときの最も考えられる原因は、フレームの順序が変わったことです。