このドキュメントは、Cisco ルータでの Binary Synchronous Communication(BSC; 2 進同期通信)データ リンク プロトコルおよび Block Serial Tunneling(BSTUN; ブロック シリアル トンネリング)の設定と使用を支援するために作成されています。また、作業中に発生する問題のトラブルシューティングにも役立ちます。
このドキュメントの読者は次のトピックについての専門知識を有している必要があります。
Binary Synchronous Communications(BSC; 2 進同期通信)の概念
基本的なデータ処理の原則に関する基礎知識
このドキュメントの情報は、Cisco IOS??IBMフィーチャセットを含むソフトウェアです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
図 1 および 2 では、2 つのデバイス間の既存の BSC リンクを再設定することにより、Cisco ルータを使用できるようにする方法について説明しています。この方法では、既存の BSC デバイスを変更することなく、同じ論理リンクを提供できます。
図1:既存のBSC設定図2:CiscoルータによるBSCの設定
Cisco ルータは、2 つのデバイス間で BSC ブロックを転送するのに、Block Serial Tunneling(BSTUN; ブロック シリアル トンネリング)カプセル化を使用します。ラインから受信される各 BSC ブロックにアドレス、および制御データを追加することによって、BSTUN フレームを作成します。BSTUN を使用して、ブロックが正しい宛先ルータに配信されます。
クリーンなルータでは、次のコマンドをリストされている順序で発行します。
[no] bstun peer-name IP アドレス
IP アドレスには、TCP トランスポートを使用する他の BSTUN ピアが、この BSTUN ピアを認識するのに使用するアドレスを指定します。
注: このコマンドは、リリース 11.3 よりも前の Cisco IOS ソフトウェアを使用する場合には、設定する必要があります。または、route 文で TCP/IP アドレスが使用されている場合にも、設定する必要があります。
[no] bstun protocol-group グループ番号 {bsc | bsc-local-ack | adplex | adt-poll | adt-poll-select | adt-vari-poll | diebold | async-generic | mdi}
このグローバル コマンドは、グループ番号とプロトコル名を関連付けます。group-numberは、1から255までの10進数です | bsc-local-ack | adplexは、事前に定義されたBSTUNプロトコルキーワードです。詳細は、『シリアル トンネルおよびブロック シリアル トンネルの設定』の「プロトコル グループの定義」を参照してください。
パススルーまたはローカル確認応答(Local-Ack)のどちらのモードを使用するかを決定する際に、グループ タイプの選択が重要になります。
注:このコマンドは常に設定する必要があります。
encapsulation bstun
特定のシリアル インターフェイスに BSTUN の機能を設定します。インターフェイスに他の BSTUN または BSC コマンドを設定する前に、まずこのコマンドを設定する必要があります。
[no] bstun group グループ番号
そのインターフェイスが属する BSTUN グループを指定します。ルータ上の BSTUN 対応インターフェイスは、それぞれ定義済みの BSTUN グループに所属している必要があります。同じグループに属する BSTUN 対応インターフェイス間でだけ、パケットが交換されます。グループ番号には、1 ~ 255 の 10 進数を指定します。
グループ番号によって、このインターフェイスでローカル確認応答とパススルーのどちらが実行されるかが決まります。
[no] bsc モード
ここでは、主要なオプションの一部について説明します。すべてのオプションの一覧は、『シリアル トンネルおよびブロック シリアル トンネルの設定』の「シリアル インターフェイスでの Bisync オプションの設定」を参照してください。
次のモードのいずれか 1 つが設定されるまでは、フレームは受信も送信もされません。
contention:シリアル インターフェイスとポイント ツー ポイントの BSC ステーションを接続する BSC リンクを設定します。3780 の パススルー モードにのみ使用できます。
contention virtual-address:Cisco IOSソフトウェアリリース11.3で最初に使用可能です。ダイヤルコンテンションとともに使用して、複数のリモートデバイスがホストエンドルータで同じインターフェイスを使用できるようにします。
dial-contention timeout:Cisco IOSソフトウェアリリース11.3で最初に使用可能です。コンテンションのためにホストエンドルータで使用されます。同じ物理インターフェイスが複数のリモート デバイスによって多重化されるようにします。
primary:ルータを BSC リンクのプライマリ エンドとして機能するように定義します。また、接続されたデバイスが BSC トリビュタリ ステーションとなることを指定します。
secondary:ルータを BSC リンクのセカンダリ エンドとして機能するように定義します。また、接続されたリモート デバイスが(フロントエンド プロセッサ [FEP] またはその他のホスト デバイスなどの)BSC コントロール ステーションとなることを指定します。
このコマンドが設定されない場合は、インターフェイスのライン プロトコルがダウンしてしまうため、インターフェイスは動作しません。
この設定では、トランスポート システムは TCP/IP です。TCP/IP が動作するのであれば、どのような物理メディアでも実行できます。
[no] bstun route all tcp IP アドレス
[no] bstun route address アドレス番号 tcp IP アドレス
IP アドレスは、パートナーのルータのピア名に指定されているのと同じ IP アドレスを指定します。
この設定では、トンネルでシスコ独自のトランスポートが使用されます。動作速度は TCP/IP より高速ですが、シリアル インターフェイスにのみ使用できます。
[no] bstun route all interface serial インターフェイス番号
[no] bstun route address アドレス番号 interface serial インターフェイス番号
この設定では、トンネルにおいて独自技術に基づいたシリアル カプセル化を使用して、フレーム リレー上で通常のシリアル ルーティングと同等の速度を実現します。
[no] bstun route address アドレス番号 interface serial インターフェイス番号 dlci DLCI 番号
フレーム リレーのインターフェイスで、このコマンドを実行します。
[no] frame-relay map DLCI 番号 bstun
この設定では、フレーム リレーのカプセル化に Logical Link Control, type 2(LLC2; 論理リンク制御タイプ 2)を使用して、ローカルな確認応答(Local-Ack)とエンドツーエンドのセッション制御を提供します。キーワード lsap を指定する必要があります。指定しない場合には、パススルー モードでカプセル化されます。
[no] bstun route address アドレス番号 interface serial インターフェイス番号 dlci DLCI 番号 lsap lsap
フレーム リレーのインターフェイスで、このコマンドを実行します。
[no] frame-relay map DLCI 番号 llc2
注:詳細は、『シリアルトンネルおよびブロック・シリアルトンネルの設定』の「フレームの転送方法の指定」を参照してください。
パススルーは、基本的なトンネリング モードです。BSTUN トンネルを通過するときでも、デバイス間を転送されるすべてのフレームは、変更されることはありません。ネットワークの遅延によって、プロトコルの動作が影響されないように、シーケンス番号およびデバイスのアドレスが追加されます。ポールや EOT の信号が遅れて到着すると、既存のセッションを大幅に中断させてしまう可能性があります。
次の状況では、パススルーを使用する必要があります。
データの整合性を確認するために送信される確認応答フレームが、転送されるデータに明示されていない。
プロトコルがピュア 3270 でない。
エンドツーエンドでデバイスを接続する必要があり、ネットワークの遅延が少ない。
ローカル確認応答によって、トンネルにすべての制御フレームを送信することによって生じるオーバーヘッドを排除します。ホストが最初のポーリングを制御ユニットに送信すると、デバイスのアドレスのリモート ポーリングを開始するために、特別な制御フレームがトンネルを通して送信されます。リモート デバイスの稼動が確認されると、ポールに対する応答を指示するための制御フレームがホスト ルータに送信されます。リモート デバイスがダウンしたときには、ホスト ルータがポールに応答しないように、トンネルを通して指示が送信されます。
次の 3 つの状況では、ローカル確認応答を使用できます。
3270 Bisync が使用されている。
ネットワークの遅延により、Bisync セッションがタイムアウトしてしまう。
WAN の超過トラフィックの問題に直面している。
[no] bsc pause 時間
このコマンドは、あるポール サイクルから、次回のポール サイクルまでの間隔を指定します。デフォルト値は 30(10 分の 1 秒が 30 単位の意味。3 秒に相当)です。
Bysinc インターフェイスのコントローラが 1 つまたは 2 つだけの場合には、このコマンドの設定をお勧めします。ポーリングの頻度を効率的に下げることができるため、接続されたデバイスに CPU サイクルを割り当てられるようになります。
[no] bsc poll-timeout 時間
ポールまたはシーケンス選択のタイムアウトを設定します。10 分の 1 秒単位で指定し、デフォルト値は 30(10 分の 1 秒が 30 単位の意味。3 秒に相当)です。
時間の最小値は、接続されたデバイスの速度によって決定されるため、多くの場合ホスト側に左右されます。ホスト側でルータのタイムアウト値が最小になるように設定されている場合には、デバイスの一部に障害が生じても、パフォーマンスが改善されます。
[no] bsc retries 再試行回数
このコマンドは、デバイスに障害が発生したと断定されるまでに実行される再試行の回数を設定します。指定できる値の範囲は、1 ~ 100 です。デフォルトは、5 回です。
[no] bsc servlim 値
servlim(アクティブなエンドステーション ポーリングと非アクティブなエンドステーション ポーリングの比率)の値を指定します。指定できる値の範囲は、1 ~ 50 です。デフォルトは 3 です。
[no] bsc spec-poll
固有仕様のポールを一般的なポールとして処理するようにホストに通知します。タンデム ホストを使用する際には、このコマンドを使用します。
すべてのオプションの一覧は、『シリアル トンネルおよびブロック シリアル トンネルの設定』の「シリアル インターフェイスでの Bisync オプションの設定」を参照してください。
コンテンションは、Bisync の一形態で、3780 で使用されます。コンテンションには制御ユニット アドレスがありません。デバイスはポイントツーポイント接続されます。一般に、リモート デバイスはセントラル ロケーションにダイヤルインし、他にデバイスが存在しないと想定されています。
リモート ジョブ入力(RJE)、3780、および 2780 を使用している場合にのみ、コンテンションを使用します。コンテンションを確認したら、両方のエンドでコンテンションが使用されるように設定されているかをチェックします。
確認するには、次の手順に従います。
bsc primary を設定します。
debug bsc packet をオンにします。
接続したデバイスでポーリングを開始します。
「1 bytes 2D」というメッセージは、コンテンションが設定されていることを表します。「2D」の前に複数バイトの表示が見られる場合は、3780 ではありません。
WAN バックボーンを越える他のすべてのトラフィックと比較した場合、Bisync トラフィックは非常にサイズが小さいので、他のトラフィックに簡単に圧倒されてしまいます。Bisync でフレームが失われると、回復までに長時間が必要になり、エンドポイントに明白な影響が現れます。この問題を最小にするために、Bisync トラフィックのプライオリティを設定する必要があります。BSTUN の優先順位またはカスタム キューイングのどちらかを使用して、トラフィックのプライオリティを設定します。
プライオリティ キューイングは、ルーティング機能の 1 つで、パケット サイズやインターフェイス タイプなどのさまざまな特性に基づいて、インターフェイスの出力キューのフレームのプライオリティを設定します。
プライオリティ出力キューイングを使用すると、ネットワーク管理者は、特定のインターフェイス上のトラフィックの4つのプライオリティ(高、通常、中、低???)を定義できます。トラフィックがルータに入ると、4 つの出力キューのいずれか 1 つに割り当てられます。最も優先順位の高いキューのパケットが最初に転送されます。そのキューが空になると、次に優先順位が高いキューが順次転送されます。このメカニズムにより、輻輳状態にあっても、優先順位の低いトラフィックによって最も優先順位の高いデータが遅延させられることがなくなります。ただし、指定のインターフェイスに送信されたトラフィックが、そのインターフェイスの帯域幅を超過した場合には、優先順位の低いトラフィックに著しい遅延が発生する可能性があります。
たとえば、WAN のシリアル リンクで、IPX より IP の優先順位を高くした場合には、IP が高い優先順位で送信される設定が有利に働くため、TCP/IP の BSC トラフィックの方が高速になります。
カスタム キューイングを利用することにより、特定のプロトコルに使用できる帯域幅を予約できます。通常のデータ用に最大 10 個の出力キューを定義できるほか、LAN のキープアライブ メッセージなど、システム メッセージ用のキューも定義できます。ルーティング パケットは、システム キューには割り当てられません。 Cisco ルータでは、それぞれのキューは順番に処理されます。あるキューに設定された割合のトラフィックの送信が完了すると、次のキューの処理に移行します。カスタム キューイングを使用すると、他のトラフィックのスループットを著しく低下させることなく、ミッションクリティカルなデータに、常に一定の割合の帯域幅が割り当てられるようにできます。
この機能を提供するために、Cisco ルータでは、インターフェイスの速度と設定された割合に基づいて、各キューから転送されるバイト数が決定されます。所定のキューに設定された数のバイトが送信されると、ルータは現在のパケットの送信を完了し、次のキューに処理を移行します。つまり、各キューはラウンドロビン方式で処理されます。
詳細は、『シリアル トンネルおよびブロック シリアル トンネルの設定』、および『輻輳管理の概要』の「使用するキューイング ポリシーの決定」を参照してください。
[no] priority-list リスト番号 protocol bstun キュー [gt | lt packetsize] [address bstun-group bsc-addr]
BSTUN ヘッダーに基づいて BSTUN キューイング プライオリティを確立するには、priority-list protocol bstun global 設定コマンドを実行します。通常の優先順位に復帰するには、no を指定する形式のコマンドを実行します。
[no] custom-queue-list [リスト]
リストには、カスタム キュー リストの番号を表す整数値(1 ~ 16)を指定します。
[no] bstun remote-peer-keepalive 間隔
BSTUN ピア キープアライブをイネーブルにします。間隔に指定した時間が経過しても、ピアとの通信がなかった場合に、ピアに対して要求が送信されます。フレームが送信されるとクロックはリセットされ、キープアライブは送信されません。デフォルトは、30 秒です。
[no] bstun keepalive-count 回数
キープアライブが指定した回数連続して失われた場合には、BSTUN 接続が切断されます。デフォルト値は 3 です。
キープアライブは、ローカル確認応答および TCP/IP を使用しているときに、トンネルの停止を防止するのに役立ちます。信号をリモートから受信したときにのみ、トンネルはインターフェイスをダウンします。トンネルがダウンすると、信号が受信されることはありません。
パススルー モードでは、エンドツーエンドの接続が求められるので、このコマンドは必要ではありません。
[no] debug bstun event グループ
BSTUN の接続およびステータスをデバッグできます。イネーブルにすると、接続の確立や全体的なステータスを示すメッセージが表示されます。
[no] debug bstun packet group グループ buffer-size 表示バイト数
BSTON リンクを通過するパケットをデバッグできます。
[no] debug bsc packet group グループ buffer-size 表示バイト数
BSC 機能を通過するフレームをデバッグできます。
[no] debug bsc packet
BSC 機能を通過するフレームをデバッグできます。BSTUN グループ番号を使用して設定されたすべてのインターフェイスをトレースします。
[no] debug bsc event グループ
BSC 機能で生成されるイベントをデバッグできます。グループ番号を省略した場合は、BSTUN グループ番号を使用して設定されたすべてのインターフェイスをトレースします。
BSTUN の現在のステータスを表示します。
This peer: 10.10.20.108 *Serial5 -- interface for ATM: R1710V421 (group 3 [bsc]) route transport address state rx_pkts tx_pkts drops C2 TCP 10.10.10.107 open 655630 651332 0 Serial6 -- interface for SEC: MST012 (group 2 [bsc]) route transport address state rx_pkts tx_pkts drops C2 TCP 10.10.10.107 open 649385 644001 0
次のような問題がないかチェックします。
「state」が「closed」になっている
「drops」に数字がカウントされている
パケット カウントが低下している
注:パケットカウントが低い場合は、必ずしも問題を示しているとは限りません。ローカル確認応答を実行しているときには、データ フレームの数のみがカウントに含まれます。それは、実際にホストから送信されたフレームの数よりかなり少ない数値を示します。
このコマンドは、BSC の現在のステータスを表示します。
BSC pass-through on Serial5: Output queue depth: 0. HDX enforcement state: IDLE. Frame sequencing state: SEC. Tx-Active: Idle. Rx-Active: False. Tx Counts: 670239 frames(total). 670239 frames(data). 9288816 bytes. Rx Counts: 651332 frames(total). 651332 frames(data). 651332 bytes.
次のような問題がないかチェックします。
「HDX enforcement state」が「IDLE」以外のステートにとどまる場合は、接続されたデバイス、またはこのルータに問題が生じている可能性があります。これは通常、そのデバイスが応答していないことを示しています。bsc event debug をオンにします。「no response from remote」というメッセージが多数出力される場合は、最初にデバイスがアクティブであることを確認し、その次にデュプレックスをチェックします。メッセージが表示されず、結果的に復旧もされないという場合には、送信完了イベントはすでに失われています。これは、壊滅的な影響をもたらす可能性のあるバグであることを示します。
「Frame sequence state」は、チェックすべき Finite State Machine(FSM; 有限状態マシン)を示しています。
「Rx-Active」が「True」にとどまる場合は、ハードウェアに何らかの問題があることを示しています。shut を実行した後で、no shut を実行してインターフェイスをリセットします。これで改善されない場合は、ルータをリロードします。
BSC local-ack on Serial0: Secondary state is CU_Idle. Control units on this interface: Poll address: 40. Select address: 60 *CURRENT-CU* Current active device address is: 40. State is Active. Tx Counts: 87228 frames(total). 11 frames(data). 87353 bytes. Rx Counts: 87271 frames(total). 5 frames(data). 436312 bytes. Total Tx Counts: 87228 frames(total). 11 frames(data). 87353 bytes. Total Rx Counts: 174516 frames(total). 5 frames(data). 523557 bytes.
「state」が「TCU_Down」にとどまる場合は、インターフェイスをダウンさせている要因が依然残っていることを示しています。クロッキングと BSC モードをチェックし、管理上ダウンしていないことを確認します。随時、shut コマンドに続けて no shut コマンドを実行することによって、再びインターフェイスを開始します。
output queue depth が 1 より大きい場合は、インターフェイスにバックログが存在することを示しています。半二重が適切に設定されているかどうかをチェックします。
Out of SYN-hunt mode は、インターフェイスがダウンしているか、または受信側がディセーブルにされていることを示します。Rx-Active の場合と同じ説明が当てはまります。
このコマンドは、そのシリアル インターフェイスに関連付けられたカウンタを調べるのに役立ちます。
Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
注意:エラーは問題を意味します。
次のような問題がないかチェックします。
aborts:不正な伝送があることを示します。
ignored:Bisync プロトコルに違反するフレームであることを示します。
giants:MTU が小さすぎるか、または Bisync シーケンスが不正であることを示します。
overrun:CPU リソースの枯渇を示します。
CRC:回線に(ノイズまたは他の要因による)データの破損が見られることを示します。
DTE ケーブルを使用していて、回線が頻繁にダウンしているように見える場合、または送信でエラーが発生しても受信には問題がない場合には、ignore-dcd コマンドを実行する必要があります。この問題は、プロトコル アナライザを使用して検証することができます。DCE で送信するときには、Data Carried Detect(DCD; データ キャリア検出)が起動します。送信が完了すると DCD がダウンするため、ルータは応答できなくなります。
Hardware is CD2430:Cirrus のチップセットであることを示します。
Hardware is HD64570:Hitachi のチップセットであることを示します。
Hitachi では、文字単位の割り込みが使用されており、フレーミングはソフトウェアにより行われます。そのため、DCD の処理が十分ではありません。Cirrus では、フレーム割り込みが使用されます。フレームは ucode で構築されます。Cirrus では、DCD を処理するオプションを利用できます。デバッグの際には、使用するインターフェイスの種類を把握し、種類による違いについて十分に理解しておくことが重要です。
「line protocol」のステータスは「up」である必要があります。「up」でない場合は、BSC モードが設定されているかどうかをチェックします。
Serial5 is up, line protocol is up Hardware is CD2430 in sync mode MTU 265 bytes, BW 4 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation BSTUN, loopback not set Half-duplex enabled. cts-delay 0 millisec dcd-txstart-delay 100 millisec dcd-drop-delay 100 millisec transmit-delay 0 millisec Errors - 0 half duplex violation Last input 10:27:12, output 1:07:12, output hang never Last clearing of "show interface" counters 4d11 Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 3223346 packets input, 3223356 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 3242346 packets output, 45259079 bytes, 0 underruns 0 output errors, 0 collisions, 8 interface resets, 0 restarts 0 output buffer failures, 0 output buffers swapped out 4 carrier transitions DCD=up DSR=up DTR=up RTS=down CTS=down
パススルー モードで実行していることを確認します。チェックすべき Finite State Machine(FSM; 有限状態マシン)を特定する必要があります。
イベント デバッグ メッセージに注目します。チェックすべき FSM が 2 つあります。HDX-FSM は、強制的に半二重に設定される FSM です。ラインが全二重または半二重のどちらに設定されているかに関わらず、強制的に設定されます。ルータの送信キューに古いデータのバックログが存在しないことを確認しようと試みます。FS-FSM では、ネットワーク全域のフレームの遅延によって、確立されているセッションが破壊されないようにします。
どちらをチェックすべきかを判断するには、コンテンションが設定されている場合は、直接コンテンション FSM を調べます。コンテンションが設定されていない場合は、「IDLE」からどのステートに移行するかをチェックします。「SEC」に移行した場合は、セカンダリ フレーム シーケンスの FSM を調べます。「PRI」に移行した場合は、プライマリ フレーム シーケンスの FSM を調べます。
BSC: Serial6: HDX-FSM event: RXV old_state: PND_RCV. new_state: IDLE. BSC: Serial6: FS-FSM event: SDI EOT old_state: SEC. new_state: IDLE. BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC. BSC: Serial6: New Address(C2) New NS(01) BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP. BSC: Serial6: HDX-FSM event: CmpOTH old_state: PND_COMP. new_state: PND_RCV. BSC: Serial6: SDI: Data (1 bytes): 37 BSC: Serial6: HDX-FSM event: RXV old_state: PND_RCV. new_state: IDLE.
表の左側に入力、上部にステートがそれぞれ表示されていることを確認してください。行のそれぞれのエントリは、{次のステート,アクション} という形式で表示されています。まず、アクションが実行された後に、移行が行われます。
ローカル確認応答モードで実行していることを確認します。show bsc コマンドは、インターフェイスがポーリング側か被ポーリング側のどちらであるかを示します。結果に基づいて、適切な LACK FSM を使用します。
注意: この操作は実行しないでください。確実な動作は期待できません。
問題なく設定が完了しても、何も起こりません。リモート ルータで debug bsc packet をオンにしても、何も表示されません。次に、debug bstun packet をオンにしても、やはり何も表示されません。さらに、debug bstun event をオンにしますが、何も表示されません。ホストエンド ルータに戻って、debug bstun event をオンにします。ここでは、不正な接続を示すいくつかのメッセージが表示されます。
これは、トンネルのどちらかのエンドが、異なるグループ番号で設定されているときに発生します。この場合、データは間違ったインターフェイスから送信されてしまうか、または BSTUN レベルで廃棄されてしまいます。
ローカル確認応答とパススルーのグループ番号を混在させないようにします。ネットワーク全体で、一貫性のあるプロトコルグループの定義が使用されていることを確認します。また、コンテンションを実行するデバイス(3780)には、3270 とは異なるグループ番号が定義されている必要があります。
21:55:18: BSC: Serial4: SDI-rx: Data (5 bytes): C7C740402D 21:55:19: BSC: Serial5: SDI-tx: Data (1 bytes): 37 21:55:19: BSC: Serial5: SDI-tx: Data (5 bytes): C2C240402D 21:55:21: BSC: Serial4: SDI-rx: Data (1 bytes): 37 21:55:21: BSC: Serial4: SDI-rx: Data (5 bytes): C7C740402D 21:55:22: BSC: Serial5: SDI-tx: Data (1 bytes): 37 21:55:22: BSC: Serial5: SDI-tx: Data (5 bytes): 404040402D 21:55:24: BSC: Serial4: SDI-rx: Data (1 bytes): 37
タンデムの場合、厳密に 3270 の用法に従っているわけではありません。タンデムでは、ポーリングの実行には、すべて固有のポールが使用されるため、デフォルトの LACK FSM では問題が発生します。タンデムが適切に動作できるようにするには、BSC のセカンダリ インターフェイスに bsc spec-poll を設定します。
全二重と半二重は常に混同されがちです。
全二重では、送信側ステーションと受信側ステーションの間で、同期的にデータが送信されます。
半二重では、送信側ステーションと受信側ステーションの間で、一度に 1 方向にのみデータが送信されます。
詳細は、show bsc コマンドのセクションを参照してください。
プロトコル アナライザまたはブレークアウト ボックスを利用できる場合は、アナライザをルータを外したシステムに接続します。
RTS または CTS によって信号が変化する場合は、半二重であり、そうでない場合は全二重です。
DCD の変化が激しく、回線がアップとダウンを繰り返すか、またはダウンしたままという場合は、スイッチング DCD を使用している可能性があります。
注:プライマリルータは全二重であるのに対し、リモートルータは半二重である可能性があります。その逆もあります。これらは別々の物理回線であり、インターフェイスからの制御信号がトンネルを越えて転送されることはありません。
これは、セカンダリ ルータ上に、2 種類のインターフェイスを作成した例です。それは、ローカル確認応答とパススルーです。どちらのインターフェイスもリモートからの応答を受信していません。セカンダリ ルータにポーリングが到着しているのを確認したら、すぐにリモート エンドの状態を調べる必要があります。
21:55:18: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D 21:55:19: BSC: Serial5: SDI-tx: Data (1 bytes): 37 21:55:19: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D 21:55:21: BSC: Serial4: SDI-rx: Data (1 bytes): 37 21:55:21: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D 21:55:22: BSC: Serial5: SDI-tx: Data (1 bytes): 37 21:55:22: BSC: Serial5: SDI-tx: Data (5 bytes): 40407F7F2D 21:55:24: BSC: Serial4: SDI-rx: Data (1 bytes): 37 21:55:24: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D 21:55:25: BSC: Serial5: SDI-tx: Data (1 bytes): 37 21:55:25: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D 21:55:27: BSC: Serial4: SDI-rx: Data (1 bytes): 37 21:55:27: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D 21:55:28: BSC: Serial5: SDI-tx: Data (1 bytes): 37 21:55:28: BSC: Serial5: SDI-tx: Data (5 bytes): C2C27F7F2D 21:55:30: BSC: Serial4: SDI-rx: Data (1 bytes): 37 21:55:30: BSC: Serial4: SDI-rx: Data (5 bytes): C7C77F7F2D
これはパススルーの例ですが、リモート エンドを調べてみると、トンネルを通してフレームが到達しているにも関わらず、接続したデバイスは反応していません。
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: NDI: Data (4 bytes): C2C00037 BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: NDI: Data (4 bytes): C2C00037 BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: NDI: Data (4 bytes): C2C00037 BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: NDI: Data (4 bytes): C2C00037 BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: NDI: Data (4 bytes): C2C00037
次に、障害のあるデバイス、または不良なトランスミッタが接続されたルータを判断するために、イベント デバッギングをオンにします。
BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC. BSC: Serial6: New Address(C2) New NS(01) BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP. BSC: Serial6: HDX-FSM event: CmpOTH old_state: PND_COMP. new_state: PND_RCV. BSC: Serial6: Response not received from remote BSC: Serial6: HDX-FSM event: T/O old_state: PND_RCV. new_state: IDLE. BSC: Serial6: NDI: Data (4 bytes): C2C00037 BSC: Serial6: FS-FSM event: NDI EOT old_state: SEC. new_state: IDLE. BSC: Serial6: HDX-FSM event: TX old_state: IDLE. new_state: PND_COMP. BSC: Serial6: HDX-FSM event: CmpEOT old_state: PND_COMP. new_state: IDLE. BSC: Serial6: NDI: Data (8 bytes): C24100C2C27F7F2D BSC: Serial6: FS-FSM event: NDI BID old_state: IDLE. new_state: SEC. BSC: Serial6: New Address(C2) New NS(01)
トレースの結果から、「HDX-FSM」をチェックします。この値が「PND_COMP」ステートにとどまる場合は、トランスミッタで障害が発生しています。これは、多くの場合、クロックが提供されていないために起こります。前の例に見られるように、「PND_RCV」ステートに達していて、「Response not received from remote」というメッセージが表示される場合には、受信側に問題があるか、またはデバイスがアクティブではありません。
これは、仮想マルチドロップ環境におけるネットワークの遅延の例です。
BSC: Serial0: NDI: Data (5 bytes): C703001061 BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: Discard SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (5 bytes): 404040402D BSC: Serial0: NDI: Data (4 bytes): 40C00037 BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: Discard SDI: Data (1 bytes): 37 !--- Output suppressed. BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: Discard SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (5 bytes): C4C4C4C42D
次の表示では、C4 が時間内に応答していません。
BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: Discard SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (5 bytes): C5C5C5C52D BSC: Serial0: NDI: Data (4 bytes): C5C00037 BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: Discard SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (5 bytes): C7C7C7C72D
やはり、フレームは失われています。さらに詳細に調べれば、この問題がやや困難な状況にあることがわかります。
BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: Discard SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (5 bytes): 404040402D BSC: Serial0: NDI: Data (4 bytes): 40C00037 BSC: Serial0: SDI: Data (1 bytes): 37 BSC: Serial0: Discard SDI: Data (1 bytes): 37 BSC: Serial0: SDI: Data (5 bytes): C1C1C1C12D
再び、C7 の EOT が突然出現しています。この状態を回復するために EOT を破棄します。次のフレームは、C1 の EOT です。
この例では、ネットワークから送信されたフレームに遅延が見られ、さらに順序も乱れています。これは、ホスト上に大量の未応答のポールが発生する原因になります。この場合、ローカル確認応答を設定することが解決策となります。
この図では、3270 と 3780 の Bisync ターミナルを両方実行しているサイトの構成例を示します。
この図では、次の設定が使用されています。
Central |
---|
hostname central ! bstun peer-name 10.10.10.107 bstun protocol-group 1 bsc bstun protocol-group 2 bsc bstun protocol-group 44 bsc-local-ack ! interface Serial0 description EFTPOS host no ip address encapsulation bstun no keepalive full-duplex clockrate 19200 bstun group 1 bsc contention 1 bstun route all tcp 10.10.10.108 ! interface Serial2 description WAN-ppp backbone ip address 10.10.10.107 255.255.255.0 encapsulation ppp clockrate 2000000 ! interface Serial3 description WAN-hdlc ip address 10.10.20.107 255.255.255.0 bandwidth 2000 no keepalive clockrate 2000000 ! interface Serial4 description ATM Host no ip address encapsulation bstun no keepalive full-duplex bstun group 44 bsc secondary bstun route all tcp 10.10.20.108 ! interface Serial5 description ATM host no ip address encapsulation bstun no keepalive bstun group 2 bsc secondary bstun route address C2 tcp 10.10.20.108 ! end |
Remote 1 |
---|
hostname remote1 ! bstun peer-name 10.10.10.108 bstun protocol-group 1 bsc bstun protocol-group 44 bsc-local-ack ! interface Serial0 description EFTPOS 1 no ip address encapsulation bstun no keepalive full-duplex clockrate 19200 bstun group 1 bsc char-set ebcdic bsc contention bstun route all tcp 10.10.10.107 ! interface Serial1 description ATM 3 no ip address encapsulation bstun no keepalive bstun group 44 bsc char-set ebcdic bsc primary bstun route address 40 tcp 10.10.10.107 ! interface Serial3 description WAN -ppp ip address 10.10.10.108 255.255.255.0 encapsulation ppp ! end |
Remote 2 |
---|
hostname remote2 ! ! bstun peer-name 10.10.20.108 bstun protocol-group 2 bsc bstun protocol-group 44 bsc-local-ack bstun protocol-group 10 bsc-local-ack ! interface Serial0 description WAN-hdlc ip address 10.10.20.108 255.255.255.0 bandwidth 2000 no keepalive ! interface Serial5 description ATM 1 mtu 265 encapsulation bstun clockrate 19200 bstun group 44 bsc char-set ebcdic bsc primary bstun route address C2 tcp 10.10.10.107 ! interface Serial6 description interface for ATM 2 mtu 265 encapsulation bstun clockrate 19200 bstun group 2 bsc char-set ebcdic bsc primary bstun route address C2 tcp 10.10.10.107 ! ip route 10.10.10.0 255.255.255.0 10.10.20.107 ! end |
一般情報:『Binary Synchronous Communication』(IBM Systems Reference Library、GA27-3004-2)
IBM 3274:第 4 章「Remote Operations BSC」
IBM 3275:第 9 章
Cisco のドキュメント CD-ROM に収録された BSTUN コマンドの解説(オンラインの『シリアル トンネルおよびブロック シリアル トンネル』で参照可能)