IBM テクノロジー : IBM ネットワーキング

論理リンク制御について

2005 年 9 月 9 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 9 月 9 日) | フィードバック

目次


概要

論理リンク制御(LLC; Logical Link Control)は、IEEE 標準 802.2 で定義されています。 これは、802.3、802.5、および他のネットワークで使用されるデータ リンク制御層です。 元々は IBM によって IBM トークン リング アーキテクチャのサブレイヤとして設計されたものです。 LLC レイヤでは「コネクションレス型」および「コネクション型」のデータ転送が可能です。

コネクションレス型のデータ転送は、一般的には LLC タイプ 1 または LLC1 と呼ばれます。 コネクションレス型のサービスでは、データ リンクやリンク ステーションを確立する必要がありません。 サービス アクセスポイント(SAP; Service Access Point)を有効にすると、コネクションレス型のサービスを使用しているリモート SAP と SAP との間で情報を送受信できるようになります。 コネクションレス型のサービスには、SABME などのモードを設定するコマンドはなく、状態の情報を維持する必要もありません。

コネクション型のデータ転送は、LLC タイプ 2 または LLC2 と呼ばれます。 コネクション型ではリンク ステーションを確立する必要があります。 リンク ステーションを確立すると、モード設定コマンドが必要になります。 したがって、各リンク ステーションではリンクの状態情報を保持する必要があります。

LLC を使用する場所

LAN 上または仮想 LAN 上で Systems Network Architecture(SNA; システム ネットワーク アーキテクチャ)が実行されている場合には、常に LLC2 が実装されています。 また、フレーム リレーに直接カプセル化されます。 ルータでは LLC2 フレームを単に渡すだけの場合もありますが、ルータで LLC2 リンクステーションを実装している場合もあります。 NetBIOS でも LLC を使用します。 NetBIOS ではリソースの場所の確認に LLC1 を使用します。 LLC2 のコネクション型セッションは、その後で確立されます。

ルータで LLC2 スタックが実装されるのは、次の機能がイネーブルにされている場合です。

  • データリンク スイッチング(DLSw)(LAN 接続)

  • ローカル ACK を使用するリモート ソースルート ブリッジング(RSRB)

  • チャネル インターフェイス プロセッサ(CIP)

  • 拡張分散ネットワーク機能(SNASw; SNASwitching)

  • LCC 変換のための Synchronous Data Link Control(SDLC)(SDLLC)

トラブルシューティングのために必要な LLC に関する知識について

LLC の基本を理解していれば、ほとんどの問題を切り分けて、解決できます。 LLC1 では維持するリンク状態やセッションがないため、問題が起きることはまれです。

LLC2 では、問題は基本的に、確立できないセッションと、確立はしたものの断続的に途切れるセッションの 2 つのカテゴリに分けられます。 これらの問題を解決するには、次の項目について理解している必要があります。

LLC のフレーム形式

DSAP/SSAP
制御
宛先サービス アクセス ポイント(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 情報フォーマット
P = ポール ビットを「1」にセット
F = 最終ビットを「1」にセット
Z = ポール/最終ビットを「0」または「1」にセット

LLC フレームは LLC Protocol Data Unit(LPDU; LLC プロトコル データ ユニット)と呼ばれます。 これは、次のような形式です。

DSAP (1 byte)-SSAP (1 byte)-Control Field (1 or 2 bytes)-Information Field (0 or more bytes)

DSAP フィールド

宛先サービス アクセス ポイント(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 フィールド

送信元サービス アクセス ポイント(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

制御フィールドの 3 つのタイプの詳細は次のとおりです。

I フレーム

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 ビットと呼ばれます。 リモート側のリンク ステーションでこのビットをセットして応答を送信するように要求するために、コマンド LPDU ではこのビットが設定されます。 P ビットがセットされた送信コマンドに対しては、F ビットがセットされた受信応答が 1 つだけ存在します。 エラー回復に関連して、この使用に関するその他の詳細事項がありますが、これは一般的な規則です。

S フレーム(スーパーバイザリ フレーム)

S フレームにより、I フレームの確認応答(RR)、I フレームの再伝送の要求(REJ)、I フレームの一時的な中断の要求(RNR)など、管理的な制御機能が実行されます。 S フレームには情報フィールドがないため、送信側ステーションの NS には影響を与えません。 したがって、NS フィールドは含まれません。 S フレームの形式は次のとおりです。

    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 を使用して、ステーションで一時的に受信準備ができていないことを表示します。 これには、上記と同じルールに従った NR カウントが入っています。 RNR の一時的な期間は、必ずしもネットワークでの問題を示すものではありません。 RNR の状態が続く場合は、端末での輻輳を調べてください。

  • B'10'=Reject
  • ステーションでは REJ を使用して、NR カウントで示される番号から始まる I フレーム LPDU の再伝送を要求します。 REJ は重大な問題を示すものではありません(回復可能であることを意味します)。 多数の REJ コマンドが見られる場合は、反対方向での I フレームの欠落(ドロップ)を確認してください。 REJ を Frame Reject(FRMR)と混同しないでください。 FRMR は番号なしフレームで、常に重大な問題を示すものです。

番号なしフレーム

番号なしフレームでは、モードの設定コマンドと応答など、リンクの制御機能が提供されます。 一部のケースでは、番号なしの情報フレームが送信されることもあります。 番号なしフレームは、長さが 1 バイトだけしかありません。 このフレームには NS カウントまたは NR カウントに関するフィールドはありません。 番号なしフレームの形式は次のとおりです。

    M-M-M-P/F-M-M-1-1

「M」ビットは番号なしフレームのタイプを示します。

  • B'00011'=DM Response (0x1F)
  • リンク ステーションは DM 応答を送信し、非同期切断モードであることを報告します。 これは、リンクがアクティブでないことを意味します。 リンク ステーションがアクティブであったのに、突然 DM を送信し始めた場合は、リンク ステーションがリセットされたと考えられます。

  • B'01000'=DISC Command (0x53)
  • リンク ステーションでは DISC を送信して、非同期平衡モードを終了します。 DISC コマンドは、リモート リンク ステーションに動作を停止していることを通知します。 DISC コマンドに対する正しい応答は、UA(ステーションが ABM の場合)、または DM(ステーションが ADM の場合)です。

  • B'01100'=UA Response(0x73)
  • リンク ステーションは、UA を使用して、SABME コマンドおよび DISC コマンドに応答します。

  • B'01111'=SABME Command(0x7F)
  • リンク ステーションでは SABME を送信して、非同期平衡モードでのデータ転送を開始します。 SABME に対する正しい応答は UA です。 ステーションで SABME コマンドが受信されると、NR カウンタと NS カウンタがゼロにリセットされます。 送信元のステーションは、UA 応答を受信したときに同様に動作します。

  • B'10001'=FRMR Response(0x87)
  • リンク ステーションは Frame Reject 応答を送信して、他のリンク ステーションから着信した LPDU にエラーがあることを報告します。 FRMR が発生したときには、FRMR を送信しているステーションで回復不可能なエラーが検出されています。 これはエラーの原因ではありません。FRMR エラーが発生した後に着信したフレームは、DISC または SABME が受信されるまではすべて無視されます。

    FRMR 応答には、FRMR の状態の原因に関する情報が含まれています。

    バイト 0 と 1 には、Frame Reject を引き起こした LPDU の制御フィールドの内容が含まれています。 バイト 2 と 3 には、それぞれ NS カウントと NR カウントが含まれています。 バイト 4 には、次のように、エラーのタイプを示すいくつかのビットが含まれます。

      0-0-0-V-Z-Y-W-X

    V ビットは、バイト 0 および 1 の制御フィールドで搬送された NS 番号が無効であることを示しています。 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 コマンドは、通常はソースルート ブリッジング環境でのパス ディスカバリのために使用されます。

LLC 制御フィールドの概要

番号なしフレーム
0x0F または 0x1F 切断モード(DM)応答
0x43 または 0x53 Disconnect(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 モードとセッションの確立

LLC2 の動作には、拡張非同期平衡モードと非同期切断モードの 2 つのモードがあります。

拡張非同期平衡モード(ABME)

ABME は、2 つのリンク ステーション間での動作の平衡モードです。 平衡モードは、いずれのステーションでも、他のリンク ステーションの状態に関係なく、常にコマンドを送信できることを意味します。 これを非平衡モードで動作する SDLC と比較してみましょう。 非平衡モードでは、セカンダリ ステーションがデータを送信できるようになるには、プライマリ ステーションからポールされるのを待機する必要があります。 平衡モードでの動作の結果、LLC2 回線では従来の意味でのポーリングは発生しません。 ステーションではセッションを維持するためのキープアライブを送信しますが、SDLC のように最適なパフォーマンスのために頻繁にキープアライブを送信する必要はありません。 この理由により、キープアライブ タイマーは通常は 10 秒以上です。 このキープアライブ タイマー値を端末側で増やして、オーバーヘッドを削減できる点に注意することが重要です。 キープアライブ タイマーの値を上げることで、スループットやレスポンス タイムに悪影響が及ぶことはありません。

ステーションでは SABME コマンドに対する UA を送受信した後、ABME に入ります。 ABME になると、ステーションは番号付き情報フレームを送受信できるようになります。

非同期切断モード(ADM)

ABME の終了の前後に、ステーションは非同期切断モードになります。 ADM では、リンクが論理的に切断されるため、I フレームや S フレームはいっさい送信できなくなります。 ステーションでは、次の状態の場合に 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 ...

LLC2 非同期平衡モードでの動作

ASBM で動作しているステーションには、プライマリ ステーションやセカンダリ ステーションという厳格な概念はありません。 ステーションでは、データ転送のためにポーリングしたり、されたりする必要はありません。 ステーションではあらゆるステーションに非同期でデータを転送できます。 ステーションは、ピアツーピアの関係にあると見なされます。

プライマリおよびセカンダリという厳格な概念はないものの、送信元のステーションは受信側のステーションからの確認応答と呼ばれるリンク レベル応答を、送信した番号付き情報フレームごとに必要とします。 ステーションでは、確認応答のないフレームの数が限界になるまで、I フレームを他のステーションに送信し続けることができます。 この数値は「ウィンドウ サイズ」と呼ばれ、通常はデフォルトで 7 になっています。遅延の多い回線では、この数を増やすことにより、送信元のステーションが動作を停止して応答を待機するのを避けることができます。 通常はこの操作は必要ありません。特に LLC がローカルで確認応答されている場合は不要です。 送信元のステーションが自身の送信ウィンドウ サイズに達したときには、ポール ビットを設定して、受信側ステーションに強制的に応答を送信させるようにします。 ルータでは、ウィンドウ サイズは llc2 local-window と呼ばれます。

受信側のステーションには、一定数の I フレームを受信するか、タイマーが切れるまで、確認応答を保留するというオプションがあります。 これらのパラメータは、それぞれ N3 および T2 と呼ばれます。 これにより、1 つの RR フレームで複数のフレームに確認応答したり、1 つの I フレームの先頭で確認応答を送ることができます。 シスコでは、N3 カウンタを llc2 ack-max と呼んでいます。 デフォルト値の 3 は、ルータが I フレームを 3 つ受信するか、llc2 ack-delay-time と呼ばれる T2 タイマーが切れるまで確認応答を保留することを示しています。

これらのパラメータをあるステーションで相手側のステーションを考慮することなく変更すると、レスポンス タイムとスループットが影響を受けることがあります。 たとえば、送信側のステーションで local-window を 5 に設定し、受信側のステーションで ack-max に 7 を、ack-delay-time に 500 ミリ秒を設定したとします。

この場合、送信側のステーションでは 5 個のフレームを送信し、継続する前に確認応答が到達するのを待機します。 受信側では 7 個のフレームを受信するまで確認応答を保留しているため、500 ミリ秒の遅延時間が切れるまで、確認応答を送信しません。 受信側のステーションで ack-max の値を小さくすると、パフォーマンスは劇的に向上します。

もう 1 つの一般的な LLC2 パラメータは Ti タイマーと呼ばれます。 ルータではこれを llc2 idle-time と呼びます。 この目的は、I フレームが送信されていない間も LLC2 セッションをアクティブに維持することです。 この値を下げても、スループットとパフォーマンスは向上しません。 Ti タイマーが切れると、poll ビットをオンにした状態で RR フレームが送信され、受信側からの応答を促します。 ステーションから応答がない場合、llc2 tpf-time 後にリトライを行い、llc2 n2 で定義されているリトライ回数に達するまで、これを続けます。 この時点で、セッションは切断されます。

アイドル タイムを長くすると、LLC2 回線でのオーバーヘッドの量を減らすことができ、ローカルでの確認応答の代用として調整できます。 NCP に DSPU が 200 接続されている例について考えます。 各 PU では個別の LLC2 セッションが維持されています。 各 PU が 10 秒ごとにキープアライブを送信する場合、毎秒 20 フレームのオーバーヘッドがかかっています。 アイドル タイムを 30 秒に長くすると、オーバーヘッドは毎秒 6.67 フレームに下がります。 アイドル タイムを長くすることの欠点は、ステーションで相手先に到達できないことが検出されるまでの時間が長くなることです。 しかし、状況によっては、これが利点になることもあります。

LLC2 の調整可能なパラメータ

コマンド デフォルト 説明
llc2 ack-delay-time>/b> msec 100 ack-max の値に到達して確認応答を送信するまで応答を待機する時間。
llc2 ack-max カウント 3 フレーム 確認応答を送信するまでに受信するフレーム数。
llc2 idle-time ミリ秒 10000 アイドル時間中のポーリング間隔時間。
llc2 local-window カウント 7 フレーム 応答を待機するまでに送信するフレーム数。
llc2 n2 カウント 8 リトライ 確認応答のない I フレームまたはポールが送信される回数。この回数だけ応答がない場合は、セッションを終了。
llc2 t1-time ミリ秒 1000 応答を待機する時間数。この時間内に応答がない場合は I フレームを再送信。 この時間は、ラウンドトリップ遅延に見合うように十分に長くする必要があります。
llc2 tbuzy-time ミリ秒 9600 RNR を送信したステーションをポーリングするまで待機する時間数。 現在の状態をクリアするのに通常以上に長いビジー時間があるステーションに対しては、この値を長くすることだけが可能です。
llc2 tpf-time ミリ秒 1000 最終的な応答を待機する時間。この時間内に応答がない場合はポール フレームを再送信。
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

LLC2 のパラメータ設定の例

両端がトークン リング LAN である一般的な DLSw+ ネットワークでは、発信側のトークン リング インターフェイスで LLC2 パラメータの設定を行います。

この例では 2 つの別個の LLC2 セッションがあります。 したがって、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 パラメータ設定は、FEP(DLSw1 ルータに接続)と PC(DLSw2 ルータに接続)に対する LLC2 パラメータと一致する必要があります。 中央のサイトの DLSw+ ピアが CIP ルータ上にある場合は、設定はやや異なります。

リモートの DLSw+ ルータの設定は変更しないままにしておきます。 しかし、中央サイトでの LLC2 セッションは、CIP と IOS での LLC2 スタックとの間で行われます。 CIP はメインフレームを表しています。そして、メインフレームから IOS に対する LLC2 パラメータは、LAN トークン リング(CIP)のアダプタで設定されています。 IOS からメインフレームに対する LLC2 パラメータは、発信インターフェイスで設定されています。 これはつまり、インターフェイス チャネル x/2(CIP 用)とインターフェイス チャネル x/0(xCPA 用)になります。たとえば、次のようになります。

注:次の一部を抜粋した設定では、関連のある LLC2 パラメータ設定だけを示しています。

 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
 

CIP ルータがローカル LAN を経由してローカル ステーションに接続している場合は、CIP アダプタでの LLC2 パラメータだけが必要です。 これらの LLC2 パラメータは、PC のパラメータと照合されます。 インターフェイス チャネル 0/2 の LLC2 パラメータは効力がありません。つまり、次のようになります。

注:次の一部を抜粋した設定では、関連のある 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
 

デバイスがブリッジグループを経由して DLSw+ に接続している場合は、LLC2 パラメータは DLSW+ の bridge-group 文で次のように設定します。

注:次の一部を抜粋した設定では、関連のある LLC2 パラメータ設定だけを示しています。

 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
 

イーサネット 0 インターフェイスで LLC2 を設定することもできますが、これらのパラメータは効力がないことに注意してください。 DLSw bridge-group LLC2 は 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 のエラー状態

LLC2 セッションでフレームがときどき失われたり、フレームの順序が変わるなどのエラーが発生することは普通であり、回復が可能です。 この結果は通常は REJ となり、フレームが再送信されます。 過剰な再送信が起きるのは異常であり、その原因を明らかにして解決する必要があります。 過剰な再送信を引き起こしている事象には、ドロップ、複数パス、輻輳、過剰な遅延があります。

LLC2 で生じるエラーの中には、回復が不可能で、常にセッションを停止させるものがあります。 このようなエラーは、プロトコル違反だけです。 これは、ステーションから未定義の制御フィールドや他の誤った情報が送信された場合に発生します。 このプロトコル違反が生じた結果、ステーションは FRMR 応答を送信します。 FRMR 応答を送信したステーションは、ほとんどの場合は違反者ではなく、単なるメッセンジャです。 FRMR には、FRMR が送信された理由を示す情報が含まれています。最も一般的なのは、ステーションが他のステーションに対し、すでに確認応答が行われた I フレームを再送信するよう要求した場合です。 フレームはすでに廃棄されているため、ステーションがフレームを再送信することは不可能であり、LLC セッションを終了するしか選択肢はありません。 このようなタイプのエラーが発生したときの最も考えられる原因は、フレームの順序が変わったことです。


関連情報


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 12247