シリアル回線の問題に関するトラブルシューティング

概要

この章では、一般的なトラブルシューティングの情報を記載しており、シリアル接続のトラブルシューティングのツールとテクニックについて説明します。この章の内容は、次のとおりです。

• show interfaces serial コマンドを使用するトラブルシューティング

• show controllers コマンドの使用

• debug コマンドの使用

• 拡張 ping テストの使用

• クロッキング問題のトラブルシューティング

• バッファの調整

• 特殊なシリアル回線のテスト

• show interfaces serial コマンドに関する詳細情報

• T1 問題のトラブルシューティング

• E1 問題のトラブルシューティング

前提条件

要件

このドキュメントの読者は次の定義に関する知識が必要です。

• DTE = data terminal equipment（データ端末装置）

• CD = Carrier Detect（キャリア検知）

• CSU = channel service unit（チャネル サービス ユニット）

• DSU = digital service unit（デジタル サービス ユニット）

• SCTE = serial clock transmit external（シリアル クロック送信外部）

• DCE = data circuit-terminating equipment（データ回線終端装置）

• CTS = clear-to-send（クリア ツー センド）

• DSR = data-set ready（データセット レディ）

• SAP = Service Advertising Protocol（サービス アドバタイジング プロトコル）

• IPX = Internetwork Packet Exchange

• FDDI = Fiber Distributed Data Interface（ファイバ分散データ インターフェイス）

• ESF = Extended Superframe Format（拡張スーパーフレーム フォーマット）

• B8ZS = binary eight-zero substitution

• LBO = Line Build Out（回線整合）

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

show interfaces serial コマンドを使用するトラブルシューティング

show interfaces serial EXEC コマンドの出力には、シリアル インターフェイスに特化した情報が表示されます。図 15-1 には、ハイレベル データリンク コントロール（HDLC）のシリアル インターフェイスでの show interfaces serial EXEC コマンドの出力が示されています。

このセクションでは、show interfaces serial コマンドを使用してワイドエリア ネットワーク（WAN）環境でのシリアル回線の接続問題を診断する方法を説明しています。後続のセクションでは、コマンド出力の重要なフィールドをいくつか取り上げて説明しています。

この表示に示されている他のフィールドは、この章の後のセクション「show interfaces serial コマンドに関する詳細情報」で詳細に説明されています。

シリアル回線：show interfaces serial のステータス行の状態

show interfaces serial で表示されるインターフェイス ステータス行（図 15-1 参照）では、下記の 5 つの問題ステートが識別される可能性があります。

• Serial x is down, line protocol is down

• Serial x is up, line protocol is down

• Serial x is up, line protocol is up (looped)

• Serial x is up, line protocol is down (disabled)

• Serial x is administratively down, line protocol is down

図 15-1：HDLC show interface serial コマンドの出力

表 15-1：シリアル回線：show interfaces serial のステータス行の状態：この表には、インターフェイスのステータス状態、その状態に関連する可能性のある問題、それらの問題に対するソリューションが示されています。

ステータス行の状態	考えられる問題	解決方法
Serial x is up, line protocol is up		これは正常なステータス行の状態です。操作は不要です。
Serial x is down, line protocol is down (DTE mode)	通常、ルータで CD シグナルが検出されていない（つまり、CD がアクティブではない）ことを示す。 電話会社の問題：回線がダウンになっているか、回線が CSU/DSU に接続されていない。 ケーブル接続に障害があるか、ケーブル接続が正しくない。 ハードウェア障害（CSU/DSU）。	CSU/DSU で LED をチェックして、CD がアクティブかどうかを確認する。あるいは、回線にブレークアウト ボックスを挿入して CD シグナルをチェックする。 適切なケーブルとインターフェイスが使用されていることを確認する（ハードウェア インストールのドキュメントを参照）。 ブレークアウト ボックスを挿入して、制御線をすべてチェックする。 使用している専用回線その他のキャリア サービスに問い合せて、問題がないかどうかを確認する。 障害のある部品を交換する。 ルータのハードウェアの障害が疑われる場合は、シリアル回線を他のポートに切り替える。これで接続が回復した場合は、前に接続されていたインターフェイスに問題があります。
Serial x is up, line protocol is down (DTE mode)	ローカルかリモートのルータの設定が誤っている。 リモートのルータからキープアライブが送信されていない。 専用回線その他のキャリア サービスの問題：ノイズの多い回線、あるいは、誤設定されているか障害が発生しているスイッチ。 ケーブル上のタイミングの問題（CSU/DSU で SCTE が設定されていない）。ローカルかリモートの CSU/DSU の障害 ローカルかリモートの CSU/DSU の障害。 ルータのハードウェア障害（ローカルあるいはリモート）。	モデム、CSU、あるいは DSU をローカル ループバック モードに設定し、show interfaces serial コマンドを使用して、回線プロトコルがアップするかどうかを確認する。これで回線プロトコルがアップになったら、問題はおそらく電話会社の問題かリモート ルータの障害です。 リモート エンドに問題がありそうな場合は、リモートのモデム、CSU、あるいは DSU でステップ 1 を繰り返す。 ケーブル接続をすべて確認する。正しいインターフェイス、正しい CSU/DSU、正しい電話会社のネットワーク終端ポイントにケーブルが接続されていることを確認します。どのケーブルがどのインターフェイスに接続されているかを確認するには、show controllers EXEC コマンドを使用します。 debug serial interface EXEC コマンドをイネーブルにする。 注意：デバッグ出力にはCPUプロセスで高い優先順位が割り当てられているため、システムが使用できなくなる可能性があります。このため、debug コマンドは、絞り込まれた問題のトラブルシューティングか、Cisco のテクニカルサポート スタッフとのトラブルシューティング セッション中に限定して使用してください。さらに、ネットワークのトラフィック量が低い時間帯やユーザが少ない時間帯に debug コマンドを使用するのがベストです。デバッギングをこのような時間帯に行うと、debug コマンド処理のオーバーヘッドの増加によりシステムの使用に影響が及ぶ可能性が少なくなります。 回線プロトコルがローカル ループバック モードでアップにならず、debug serial interface EXEC コマンドの出力でキープアライブ カウンタが増加していない場合、ルータのハードウェアの問題が疑われます。ルータのインターフェイス ハードウェアを交換してください。 これで回線プロトコルがアップになって、キープアライブ カウントが増加したら、ローカル ルータには問題はありません。この章で後述されている「クロッキング問題のトラブルシューティング」セクションと「CSU と DSU のループバック テスト」セクションでの説明に従って、シリアル回線のトラブルシューティングを行ってください。 ルータのハードウェアの障害が疑われる場合は、シリアル回線を他のポートに切り替える。これで接続が回復した場合は、前に接続されていたインターフェイスに問題があります。
Serial x is up, line protocol is down (DCE mode)	clockrate インターフェイス設定コマンドがない。 DTE デバイスで SCTE モードがサポートされていないか、SCTE モード用には設定されていない。 リモートの CSU や DSU の障害。 ケーブル接続に障害があるか、ケーブル接続が正しくない。 ルータのハードウェア障害。	シリアル インターフェイスに clockrate インターフェイス設定コマンドを追加する。構文：clock rate bps構文の説明： bps：ビット/秒での要求クロック レート。1200、2400、4800、9600、19200、38400、56000、64000、72000、125000、148000、250000、500000、800000、1000000、1300000、2000000、4000000、あるいは 8000000。 可能な場合は、DTE デバイスを SCTE モードに設定する。使用している CSU/DSU で SCTE がサポートされていない場合は、Cisco ルータのインターフェイスで SCTE をディセーブルにする必要がある可能性があります。この章で後述されているセクション「送信クロックの反転」を参照してください。 正しいケーブルが使用されていることを確認する。 それでも回線プロトコルがダウンしている場合、ハードウェア障害かケーブル接続の問題である可能性があります。ブレークアウト ボックスを挿入して、配線を確認します。 必要に応じて障害のある部品を交換する。
Serial x is up, line protocol is up (looped)	回線にループが発生している。ループが最初に検出されると、キープアライブ パケット内のシーケンス番号がランダムな数字に変わります。リンク経由で同じランダム番号が返されてくる場合は、ループが存在します。	show running-config 特権 EXEC コマンドを使用して、何らかのループバック インターフェイス設定コマンドエントリを検索する。 loopback インターフェイス設定コマンド エントリが見つかった場合は、no loopback インターフェイス設定コマンドを発行してループを排除する。 loopback インターフェイス設定コマンドが見つからない場合は、CSU/DSU を調べて、マニュアル ループバック モードに設定されているかどうかを確認する。そのように設定されている場合は、マニュアル ループバックをディセーブルにする。 CSU か DSU をリセットして、回線ステータスを確認する。回線プロトコルがアップする場合は、他の操作は不要です。 CSU か DSU がマニュアル ループバック モードに設定されていない場合、専用回線その他のキャリア サービスに問い合せて、回線のトラブルシューティングのサポートを求めてください。
Serial x is up, line protocol is down (disabled)	電話会社のサービスの問題によりエラー率が高い。 CSU か DSU のハードウェアの問題。 不良ルータ ハードウェア（インターフェイス）。	シリアル アナライザとブレークアウト ボックスで回線をトラブルシューティングする。トグルしている CTS シグナルと DSR シグナルを検索する。 CSU/DSU をループさせる（DTE ループ）。 問題が続く場合は、ハードウェアに問題がある可能性があります。問題がなくなった場合は、電話会社に問題がある可能性があります。 必要に応じて不良ハードウェアを交換する（CSU、DSU、スイッチ、ローカルまたはリモートのルータ）。
Serial x is administratively down, line protocol is down	ルータのコンフィギュレーションに shutdown インターフェイス設定コマンドがある。 IP アドレスの重複。	ルータのコンフィギュレーションで shutdown コマンドをチェックする。 no shutdown インターフェイス設定コマンドを使用して、shutdown コマンドを無効にする。 show running-config 特権 EXEC コマンドか show interfaces EXEC コマンドを使用して、同一の IP アドレスがないことを確認する。 重複アドレスがある場合は、その IP アドレスの一方を変更して競合を解消する。

シリアル回線：シリアル リンクでの出力廃棄の増加

show interfaces serial コマンドの出力（図 15-1 参照）には、システムから転送バッファにパケットが渡されようとした際に使用できるバッファがない場合の出力廃棄が示されています。

症状：シリアル リンクでの出力廃棄が増加している。

表15-2シリアルライン：シリアル リンクでの出力廃棄の増加：この表では、この症状を引き起こす可能性のある問題の概要と推奨のソリューションが概説されています。

考えられる問題

解決方法

シリアル インターフェイスへの入力レートが、シリアル リンクで利用可能な帯域幅を超過している。

アクセス リストの使用やその他の手段で、ルーティング アップデートや SAP アップデートなどの定期的なブロードキャスト トラフィックを最小化する。たとえば、ipx sap-interval インターフェイス設定コマンドを使用して、SAP アップデート間の遅延を大きくします。 hold-queue out インターフェイス設定コマンドを使用して、出力保留キューのサイズを小刻み（たとえば、25 %）に増加させる。 該当のインターフェイスで、頻繁に使用されるプロトコルとしてファースト スイッチングをオフにする。たとえば、no ip route-cache インターフェイス設定コマンドを入力して、IP ファースト スイッチングをオフにします。他のプロトコルのコマンド構文については、Cisco IOS のコンフィギュレーション ガイドとコマンド リファレンスを参照してください。 プライオリティ リストを作成して、低速のシリアル リンクにプライオリティ キューイングを実装する。プライオリティ リストの設定についての情報は、Cisco IOS のコンフィギュレーション ガイドとコマンド リファレンスを参照してください。 注：特定の条件下では、出力廃棄は許容されます。たとえば、リンクが過剰に使用されていることがわかっていて、その状況を緩和する方法がない場合、パケットを保留するよりも廃棄した方が望ましい場合があります。TCP/IP や Novell IPX などの、フロー制御がサポートされていてデータの再送が可能なプロトコルがこれに該当します。 一方、DECnet やローカルエリア トランスポートなどの一部のプロトコルはパケットの廃棄の影響を受け易く、再送機能は、たとえ有ったとしても、不十分なものです。

シリアル回線：シリアル リンクでの入力廃棄の増加

show interfaces serial EXEC コマンドの出力（図 15-1 参照）には、インターフェイスからの過剰なパケットが引き続きシステムで処理中であることが示されています。

症状：シリアル リンクでの入力廃棄が増加している。

表 15-3：シリアル回線：シリアル リンクでの入力廃棄の増加：この表では、この症状を引き起こす可能性のある問題の概要と推奨のソリューションが概説されています。

考えられる問題

解決方法

入力レートがルータのキャパシティを超過しているか、入力キューが出力キューのサイズを超過している。

注：入力ドロップの問題は、通常、より高速なインターフェイス（イーサネット、トークンリング、FDDIなど）とシリアルインターフェイス間でトラフィックがルーティングされている場合に発生します。トラフィックが軽い場合は、問題はありません。トラフィック レートが増加するに従って、パケット ドロップの発生が始まります。このような輻輳の時間帯に、ルータではパケットが廃棄されます。 パケットを廃棄しているインターフェイスに対して、共通の宛先インターフェイスでの出力キューを増加させる。hold-queue out インターフェイス設定コマンドを使用します。show interfaces の出力に廃棄が表示されなくなるまで、これらのキューを小刻み（たとえば、25 %）に増加させます。デフォルトの出力保留キューの制限は 100 パケットです。 hold-queue in インターフェイス設定コマンドを使用して入力キューのサイズを縮小し、入力廃棄を強制的に出力廃棄にさせる。出力廃棄の方が入力廃棄よりもルータのパフォーマンスへの影響が小さくなります。デフォルトの入力保留キューは 75 パケットです。

シリアル回線：総インターフェイス トラフィックの 1 % を超える入力エラーの増加

show interfaces serial の出力（図 15-1 参照）に入力エラーが示されている場合、これらのエラーには発生源が何通りか考えられます。可能性の高い発生源を「表 15-4」にまとめてあります。

注：巡回冗長検査(CRC)エラー、フレーミングエラー、またはインターフェイストラフィック全体の1 %を超える中断に関する入力エラー値は、何らかの切り分けと修復が必要なリンクの問題を示唆しています。

症状：総インターフェイス トラフィックの 1 % を超える入力エラーの増加。

表 15-4：シリアル回線：総インターフェイス トラフィックの 1 % を超える入力エラーの増加

考えられる問題	解決方法
この症状には、次の原因が考えられます。 電話会社の機器の障害 ノイズの多いシリアル回線 不適切なクロッキング設定（SCTE 未設定） 不適切なケーブルあるいは長すぎるケーブル 不良ケーブルあるいは不良接続 不良 CSU あるいは不良 DSU 不良ルータ ハードウェア ルータと DSU の間で使用されているデータ コンバータやその他のデバイス	注：ルータをWANまたはシリアルネットワークに接続する場合は、データコンバータを使用しないことを強く推奨します。 シリアル アナライザを使用して、入力エラーの発生源を割り出す。エラーを検出した場合、ルータの外部のデバイスにハードウェアの問題やクロックのミスマッチがあることが考えられます。 ループバックと ping テストを使用して、具体的な問題の発生源を割り出す。詳細は、この章で後述されているセクション「trace コマンドの使用」とセクション「CSU と DSU のループバック テスト」を参照してください。 パターンを見つける。たとえば、エラーが一定の間隔で発生する場合、ルーティング アップデートの送信のような定期的な機能に関連するものである可能性があります。

シリアル回線：シリアル回線での入力エラーのトラブルシューティング

表 15-5：この表では、show interfaces serial コマンドで表示される（図 15-1 参照）さまざまなタイプの入力エラー、それらのエラーを引き起こしている可能性のある問題、それらの問題に対するソリューションが説明されています。

入力エラーのタイプ（カッコ内はフィールド名）	考えられる問題	解決方法
CRC エラー（CRC）	CRC エラーが発生するのは、CRC の計算が検査に通らず、データが破損していることが示されている場合で、これには下記の理由があります。 ノイズの多いシリアル回線 シリアル ケーブルが長すぎるか、CSU/DSU からルータへのケーブルがシールドされていない。 DSU で SCTE モードがイネーブルになっていない。 CSU 回線クロックが不適切に設定されている。 T1 リンクでの ones density の問題（不適切なフレーミングやコーディングの仕様）。	回線が転送要件に対して十分にクリーンであることを確認する。必要な場合は、ケーブルにシールドを施します。 ケーブルが推奨の長さである 15.24 m（50 フィート）あるいは T1 リンクでは 7.62 m（25 フィート）に収まっていることを確認する。 すべてのデバイスが共通の回線クロックに対して適切に設定されていることを確認する。ローカルとリモートの DSU で SCTE を設定します。使用している CSU/DSU で SCTE がサポートされていない場合は、この章で後述されているセクション「送信クロックの反転」を参照してください。 ローカルとリモートの CSU/DSU が、専用回線その他のキャリア サービス（たとえば、ESF/B8ZS）で使用されているのと同じフレーミングとコーディングのスキームに設定されていることを確認する。 使用している専用回線その他のキャリア サービスに問い合せて、回線での整合性テストを実施させる。
フレーミング エラー（frame）	フレーミング エラーが発生するのは、パケットが 8 ビット境界で終わっていない場合で、これには下記の理由があります。 ノイズの多いシリアル回線 不適切に設計されたケーブル。シリアルケーブルが長すぎます。CSUまたはDSUからルータへのケーブルがシールドされていない DSUでSCTEモードが有効になっていない。CSU回線クロックが正しく設定されていない。クロックの1つがローカルクロッキング用に設定されている T1 リンクでの ones density の問題（不適切なフレーミングやコーディングの仕様）。	回線が転送要件に対して十分にクリーンであることを確認する。必要な場合は、ケーブルにシールドを施します。適切なケーブルを使用していることを確認します。 ケーブルが推奨の長さである 15.24 m（50 フィート）あるいは T1 リンクでは 7.62 m（25 フィート）に収まっていることを確認する。 すべてのデバイスが共通の回線クロックを使用するように適切に設定されていることを確認する。ローカルとリモートの DSU で SCTE を設定します。使用している CSU/DSU で SCTE がサポートされていない場合は、この章で後述されているセクション「送信クロックの反転」を参照してください。 ローカルとリモートの CSU/DSU が、専用回線その他のキャリア サービス（たとえば、ESF/B8ZS）で使用されているのと同じフレーミングとコーディングのスキームに設定されていることを確認する。 使用している専用回線その他のキャリア サービスに問い合せて、回線での整合性テストを実施させる。
打ち切られた転送（abort）	Aborts は、ビット列の不正なシーケンスを示します（データの中に連続する 7 個以上の "1" のビット）。 これには次の理由が考えられます。 DSU で SCTE モードがイネーブルになっていない。 CSU 回線クロックが不適切に設定されている。 シリアル ケーブルが長すぎるか、CSU や DSU からルータへのケーブルがシールドされていない。 T1 リンクでの ones density の問題（不適切なフレーミングやコーディングの仕様）。 転送途中で終了されたパケット：通常、原因はインターフェイスのリセットやフフレーミング エラー。 ハードウェアの問題：不良回線、不良 CSU/DSU、あるいはリモート ルータでの不良送信インターフェイス。	すべてのデバイスが共通の回線クロックを使用するように適切に設定されていることを確認する。ローカルとリモートの DSU で SCTE を設定します。使用している CSU/DSU で SCTE がサポートされていない場合は、この章で後述されているセクション「送信クロックの反転」を参照してください。 必要な場合は、ケーブルにシールドを施します。ケーブルが推奨の長さである 15.24 m（50 フィート）あるいは T1 リンクでは 7.62 m（25 フィート）に収まっていることを確認する。すべての接続が良好であることを確認します。 リンクの両端でハードウェアをチェックする。必要に応じて、障害のある機器を交換します。 データ レートを低下させて、打ち切り（abort）の頻度が下がるかどうか確認する。 ローカルとリモートのループバック テストを使用して、打ち切り（abort）が発生している箇所を判別する。この章で後述されているセクション「特殊なシリアル回線のテスト」を参照してください。 使用している専用回線その他のキャリア サービスに問い合せて、回線での整合性テストを実施させる。

シリアル回線：シリアル リンクでのインターフェイス リセットの増加

show interfaces serial EXEC コマンドの出力（図 15-1 参照）に示されているインターフェイス リセットは、キープアライブ パケットの欠落によるものです。

症状：シリアル リンクでのインターフェイス リセットが増加している。

表 15-6：この表では、この症状を引き起こす可能性のある問題の概要と推奨のソリューションが概説されています。

考えられる問題

解決方法

この症状には、次の原因が考えられます。 リンクでの輻輳（通常は出力廃棄に関連）。 CD 遷移を引き起こす不良回線。 CSU、DSU、あるいはスイッチで考えられるハードウェアの問題。

インターフェイスのリセットが発生した場合、show interfaces serial コマンドの出力の他のフィールドを調べて、問題の発生源を判別します。インターフェイスのリセットでの増加が記録されているとの前提で、下記のフィールドを検査します。 show interfaces serialの出力に大量の出力ドロップがある場合は、「Serial Lines:シリアルリンクでの出力ドロップの増加」を参照してください。 show interfaces serial で示されている carrier transitions フィールドをチェックする。インターフェイスのリセットが登録されていてキャリア遷移が高頻度な場合、不良リンクや不良な CSU や DSU が問題である可能性が高くなります。専用回線やキャリア サービスに問い合せて、必要に応じて障害機器を交換してください。 show interfaces serial で示されている input errors フィールドを検査する。インターフェイスのリセットが増加していて入力エラーが高頻度な場合、不良リンクや不良 CSU/DSU が問題である可能性が高くなります。専用回線その他のキャリア サービスに問い合せて、必要に応じて障害機器を交換してください。

シリアル回線：シリアル リンクでのキャリア遷移カウントの増加

キャリア シグナルに中断がある（リンクのリモート エンドでのインターフェイスのリセットなど）と常に、show interfaces serial EXEC コマンドの出力にはキャリア遷移が表示されます。

症状：シリアル リンクでのキャリア遷移カウントが増加している。

表 15-7 では、この症状を引き起こす可能性のある問題の概要と推奨のソリューションが概説されています。

表 15-7：シリアル回線：シリアル リンクでのキャリア遷移カウントの増加

考えられる問題	解決方法
この症状には、次の原因が考えられます。 ケーブルの物理的分離、赤や黄色の T1 アラーム、ネットワークのどこかへの落雷などの外部発生源による回線の中断。 障害のあるスイッチ、DSU、あるいはルータのハードウェア。	リンクの両端でハードウェアをチェックする。ブレークアウト ボックスやシリアル アナライザを接続してテストし、問題の発生源を判別します。 アナライザやブレークアウト ボックスで外部の問題が何も判別できない場合は、ルータのハードウェアをチェックする。 必要に応じて、障害のある機器を交換します。

show controllers コマンドの使用

シリアル回線をトラブルシューティングする際の重要な診断ツールには show controllers EXEC コマンドもあります。このコマンド構文はプラットフォームにより異なります。

• Cisco 7000 シリーズ ルータのシリアル インターフェイスの場合は、show controllers cbus EXEC コマンドを使用する。

• Cisco アクセス製品の場合は、show controllers EXEC コマンドを使用する。

• AGS、CGS、および MGS の場合は、show controllers mci EXEC コマンドを使用する。

図 15-2 には、show controllers EXEC コマンドによる出力が示されています。このコマンドは、ファスト シリアル インターフェイス プロセッサ（FSIP）カードを装備した Cisco 7000 シリーズ ルータで使用されています。このコマンド出力をチェックして、チャネル サービス ユニット/デジタル サービス ユニット（CSU/DSU）が適切なインターフェイスに接続されていることを確認します。マイクロコードのバージョンをチェックして、それが最新であるかどうかを確認することもできます。

図 15-2：show controllers cbus コマンドの出力

Cisco 2000、Cisco 2500、Cisco 3000、および Cisco 4000 シリーズのアクセス サーバとルータでは、show controllers EXEC コマンドを使用します。図15-3は、Cisco 2503アクセスサーバの基本速度インターフェイス(BRI)およびシリアルインターフェイスからのshow controllersコマンドの出力を示しています。（一部の出力は表示されないことに注意してください）。

show controllers の出力には、インターフェイス チャネルのステート、および、そのインターフェイスにケーブルが接続されているかどうかが示されます。図 15-3 では、serial interface 0 に RS-232 DTE ケーブルが接続されています。serial interface 1 にはケーブルが接続されていません。

図 15-4 には、show controllers mci コマンドによる出力が示されています。このコマンドが使用されるのは、AGS、CGS、および MGS の各ルータでだけです。電気インターフェイスが、V.35、EIA/TIA-449、あるいはそれ以外の電気インターフェイス タイプではなく、UNKNOWN と表示されている場合、不適切に接続されたケーブルが問題であると考えられます。不良アップリケやカードの内部配線の可能性もあります。電気インターフェイスが UNKNOWN になっている場合、show interfaces serial EXEC コマンドでの対応表示には、そのインターフェイスと回線プロトコルがダウンであると表示されます。

図 15-3：show controllers コマンドの出力

図 15-4：show controllers mci コマンドの出力

debug コマンドの使用

さまざまな debug 特権 EXEC コマンドにより、多くのインターネットワーキング イベントについてのプロトコル ステータスとネットワーク アクティビティに関連する診断情報がもたらされます。

注意：  デバッギングの出力には、CPU プロセスでの高い優先度が割り当てられているので、システムが使用できなくなる可能性があります。このため、debug コマンドは、絞り込まれた問題のトラブルシューティングか、Cisco のテクニカルサポート スタッフとのトラブルシューティング セッション中に限定して使用してください。さらに、ネットワークのトラフィック量が低い時間帯やユーザが少ない時間帯に debug コマンドを使用するのがベストです。デバッギングをこのような時間帯に行うと、debug コマンド処理のオーバーヘッドの増加によりシステムの使用に影響が及ぶ可能性が少なくなります。debug コマンドの使用が終わったら、no debug コマンドを個別に使用するか、または no debug all コマンドを使用して、必ず debug コマンドを無効にしてください。

シリアルの問題と WAN の問題をトラブルシューティングする際には、下記の debug コマンドが便利です。これらのコマンドそれぞれの情報と出力についての詳細は、debug コマンド リファレンスの公開情報を参照してください。

• debug serial interface：HDLC キープアライブ パケットが増加しているかどうかを確認します。HDLC キープアライブ パケットが増加していない場合は、インターフェイス カードまたはネットワークに、タイミングに関する問題があります。

• debug x25 events：相手先選択接続（SVC）のオープンとクローズのような X.25 のイベントを検出します。 この結果の「cause and diagnostic」情報はイベント レポートにあります。

• debug lapb：平衡型リンク アクセス手順（LAPB）あるいはレベル 2 の X.25 情報を出力します。

• debug arp：ルータが ARP パケットで、WAN クラウドの相手側にあるルータに関する情報を送信しているか、あるいは相手側にあるルータについて学習しているかどうかが表示されます。TCP/IP ネットワークの一部のノードが応答していて、それ以外のノードが応答していない場合に、このコマンドを使用します。

• debug frame-relay lmi：フレーム リレー スイッチとルータで LMI パケットの送受信が行われているかどうかを判別するのに有効なローカル管理インターフェイス（LMI）情報を取得します。

• debug frame-relay events：ルータとフレーム リレー スイッチ間で通信が行われているかどうかを判別します。

• debug ppp negotiation：ポイントツーポイント プロトコル（PPP）オプションがネゴシエートされている PPP スタートアップ時に転送されている PPP パケットが表示されます。

• debug ppp packet：送受信されている PPP パケットを表示します。このコマンドは低レベルのパケット ダンプを表示します。

• debug ppp errors：PPP 接続のネゴシエーションと操作に関連する PPP エラー（不正フレームや誤形式フレームなど）が表示されます。

• debug ppp chap：PPP チャレンジ ハンドシェーク認証プロトコル（CHAP）とパスワード認証プロトコル（PAP）のパケット交換が表示されます。

• debug serial packet：送受信されているスイッチド マルチメガビット データ サービス（SMDS）パケットが表示されます。この表示には、パケットが送信されなかった理由や受信でエラーが発生した理由を示すエラー メッセージも含まれています。SMDS に関して、このコマンドでは、SMDS パケットが送受信される際の SMDS ヘッダー全体とペイロード データの一部がダンプされます。

拡張 ping テストの使用

ping コマンドはシスコのインターネットワーキング デバイスをはじめ多くのホスト システムで利用できる便利なテストです。TCP/IP においては、この診断ツールは Internet Control Message Protocol（ICMP; インターネット制御メッセージ プロトコル）のエコー要求としても知られています。

注：pingコマンドは、show interfaces serialディスプレイに高レベルの入力エラーが登録されている場合に特に役立ちます。図 15-1 を参照してください。

シスコのインターネットワーキング デバイスでは、多数の ping パケットを次々と送出することを自動化するメカニズムを備えています。図 15-5 には、拡張 ping オプションを指定するのに使用されるメニューが示されています。この例では、20 件の連続 ping が指定されています。一方、使用しているシリアル回線でコンポーネントをテストする際には、1000 件の ping のように、はるかに大きい値を指定する必要があります。

図 15-5：拡張 ping 指定メニュー

ping テストの実行

通常、シリアル回線の ping テストは次のように行います。

1. CSU や DSU をローカル ループバック モードにする。

2. さまざまなデータ パターンとパケット サイズを送信するように拡張 ping コマンドを設定する。図 15-6 と図 15-7 には、それぞれ、すべて 0（1500 バイト）の ping とすべて 1（1500 バイト）の ping の 2 つの有効な ping テストが示されています。

3. show interfaces serial コマンドの出力（図 15-1 を参照）を検査して、入力エラーが増加したかどうかを判別する。入力エラーが増加していない場合、ローカル ハードウェア（DSU、ケーブル、ルータのインターフェイス カード）はおそらく良好な状態です。

   テスト シーケンスで CRC エラーとフレーミング エラーが大量に報告されているものと仮定すると、クロッキングの問題である確率が高くなります。CSU と DSU でタイミングの問題をチェックします。この章で後述されているセクション「クロッキング問題のトラブルシューティング」を参照してください。

4. クロッキングの設定が正しく、適切に動作していると判断される場合は、CSU あるいは DSU をリモート ループバック モードにする。

5. ping テストを繰り返し、入力エラーの統計情報の変化を探す。

6. 入力エラーが増加している場合は、シリアル回線か CSU/DSU のどちらかに問題があります。WAN のサービス プロバイダーに問い合せて、CSU か DSU を交換します。問題が解決しない場合は、テクニカルサポートの担当者にお問い合せください。

図 15-6：ALl-Zeros 1500-Byte ping Test

図 15-7：All-Ones 1500-Byte ping Test

クロッキング問題のトラブルシューティング

シリアル接続でクロッキングの競合が発生すると、長期に渡り接続サービスが途絶えたり、パフォーマンスが低下したりする場合があります。この項では、クロッキング問題の重要な側面について説明します。クロッキング問題の原因、クロッキング問題の検出、クロッキング問題の切り分け、クロッキング問題の解決策

クロッキング概要

CSU/DSU では、通過するデータからデータ クロックを導出しています。クロックを回復するために、CSU/DSUハードウェアは、通過する8ビットのデータごとに少なくとも1ビットの値を受信する必要があります。これはones densityと呼ばれます。ones density が維持されると、ハードウェアではデータ クロックの信頼性を回復できます。

最近の T1 実装では、一般的に、B8ZS（binary eight-zero substitution）コーディングによる拡張スーパーフレーム フォーマット(ESF）フレーミングが使用されます。B8ZS では、シリアル リンクで 0 が連続して 8 つ送信されると、特殊なコードに置き換えられるスキームが提供されます。このコードは後で接続のリモート エンドで解釈されます。この手法により、ones density のデータ ストリームからの独立性が保証されます。

古い T1 実装では、スーパーフレーム フォーマット（SF）フレーミングとも呼ばれる D4 と交互マーク反転（AMI）コーディングが使用されます。AMI では、B8ZS のようなコーディング スキームは使用されません。この場合、データ ストリームから独立して ones density が維持されないため、転送できるデータのタイプは制限を受けます。

シリアル通信での他の重要な要素に、シリアル クロック送信外部（SCTE）ターミナル タイミングがあります。SCTE は、ルータなどのデータ端末装置（DTE）デバイスから、CSU/DSU などのデータ通信装置（DCE）デバイスにエコーバックされるクロックです。

DCE デバイスで内部クロックの代わりに SCTE を使用して DTE からのデータをサンプリングする場合、CSU/DSU とルータ間のケーブルに位相偏移があったとしても、エラーなしでデータをサンプリングできる方がよいでしょう。64 Kbps よりも高速なシリアル転送には、SCTE の使用が推奨されます。使用している CSU/DSU で SCTE がサポートされていない場合は、この章で後述されているセクション「送信クロックの反転」を参照してください。

クロッキング問題の原因

一般的には、次のいずれかが、シリアル WAN の相互接続でのクロッキング問題の原因として考えられます。

• 不適切な DSU の設定

• 不適切な CSU の設定

• 15.24 m（50 フィート）よりも長いか、あるいはシールドされていない仕様外のケーブル

• ノイズが多いか、あるいは脆弱なパッチ パネルの接続

• 1 列にまとめて接続された複数のケーブル

クロッキング問題の検出

シリアル インターフェイスでのクロッキングの競合を検出するには、次のように入力エラーを探します。

1. リンクの両端のルータで show interfaces serial EXEC コマンドを使用する。

2. コマンド出力を検査して、CRC、フレーミング エラー、打ち切り（abort）を探す。

3. これらの手順のいずれかで、インターフェイスでのトラフィックのエラーが約 0.5 ～ 2.0 % の範囲を超えていることが示されている場合、WAN のどこかにクロッキング問題があるものと考えられます。

4. 次のセクション「クロッキング問題の切り分け」での概説に従って、クロッキングの競合の発生源を割り出す。

5. 障害のあるパッチ パネルを迂回するか、修理する。

クロッキング問題の切り分け

クロッキングの競合が入力エラーの原因であると考えられる場合、エラーの発生源を割り出すのには、次の手順が有効です。

1. この章で前述されているセクション「CSU と DSU のループバック テスト」での説明に従って、一連の ping テストとループバック テスト（ローカルとリモートの両方）を実行する。

2. 問題の発生源である接続の端末、あるいは、回線に問題があるかどうかを判別する。ローカル ループバック モードで、ping テストでのさまざまなパターンとサイズ（たとえば、1500 バイトのデータグラム）を実行する。 特にルータへのシリアル ケーブルや CSU/DSU が問題である場合、単一のパターンとパケット サイズでのテストでは、エラーから役立つ情報は引き出せません。

3. show interfaces serial EXEC コマンドを使用して、入力エラー カウントが増加しているかどうか、および、どこで頻繁に発生しているかを判別する。

入力エラーが接続の両端で頻繁に発生している場合は、ほとんどが CSU のクロッキングに問題があります。

入力エラーが一端で発生している場合は、おそらく DSU のクロッキングかケーブル接続の問題です。

一端での打ち切り（abort）は、他端が不良情報を送信しているか、回線の問題があることを示しています。

注：常にshow interfaces serialコマンドの出力を参照して（図15-1を参照）、エラーカウントの変更をログに記録するか、エラーカウントが変更されない場合は記録します。

クロッキング問題のソリューション

表15-8シリアル回線:クロッキングの問題と解決策：次の表に、問題の原因に基づいて、クロッキング問題に対する推奨される解決策の概要を示します。

考えられる問題	解決方法
不適切な CSU の設定	両端の CSU でのクロック ソース（ローカルあるいは回線）の設定が一致しているかどうかを判別する。 CSUが同意しない場合は、一致するように設定します。通常、回線は送信元です。 CSUのLBO設定をチェックして、インピーダンスが物理回線のインピーダンスと一致していることを確認します。CSU を設定する上での情報は、使用している CSU のハードウェアのドキュメントを参照してください。
不適切な DSU の設定	両端の DSU で SCTE モードがイネーブルになっているかどうかを判別する。 接続の両端で SCTE がイネーブルになっていない場合は、これをイネーブルにする。 ones density が維持されていることを確認する。これには、専用回線その他のキャリア サービスで使用されているものと同じフレーミングとコーディングのスキーム（たとえば、ESF と B8ZS）が DSU で使用されている必要があります。フレーミングとコーディングのスキームについての情報は、専用回線のプロバイダーに確認してください。 使用しているキャリア サービスで AMI コーディングが使用されている場合は、リンクの両端で送信クロックを反転させるか、DSU をビットスタッフ モードで稼働させる。DSU を設定する上での情報は、使用している DSU のハードウェアのドキュメントを参照してください。
ルータに接続されたケーブルが仕様外	ケーブルが 15.24 m（50 フィート）よりも長い場合は、もっと短いケーブルを使用する。ケーブルがシールドされていない場合は、シールド ケーブルに交換する。

送信クロックの反転

SCTE がサポートされていない CSU/DSU で 64 Kbps よりも高速でシリアル接続しようとしている場合、ルータで送信クロックを反転させる必要がある可能性があります。送信クロックを反転させると、データ シグナルとクロック シグナル間のフェーズのずれが補正されます。

送信クロックを反転させるのに使用される具体的なコマンドはフラットフォームにより異なります。Cisco 7000 シリーズのルータでは、invert-transmit-clock インターフェイス設定コマンドを入力します。Cisco 4000 シリーズのルータでは、dte-invert-txc インターフェイス設定コマンドを使用します。

使用しているルータに対して確実に適切なコマンド構文を使用するために、使用しているルータやアクセス サーバのユーザ ガイド、および Cisco IOS のコンフィギュレーション ガイドとコマンド リファレンスを参照してください。

注：古いプラットフォームでは、送信クロックを反転するために物理ジャンパを移動する必要がある場合があります。

バッファの調整

帯域幅の使用率が過剰（70 % 超）になると、全体的なパフォーマンスが低下し、散発的に障害が発生する可能性があります。たとえば、DECnet のファイル転送では、ネットワークのいずれかの箇所で廃棄されているパケットにより、障害が発生する可能性があります。

状況が非常に悪い場合は、リンクの帯域幅を増加させる必要があります。ところが、帯域幅を増加させることが必要ではない場合もあれば、即座には現実的ではない場合もあります。シリアル回線の境界域付近での過剰使用の問題を解決する 1 つの方法は、ルータでのデータ バッファの使用具合を制御することです。

注意：一般には、シスコのテクニカルサポート担当者と緊密に連携している場合を除き、システムバッファを調整しないでください。ルータでシステム バッファを不適切に調整すると、使用しているハードウェアとネットワークのパフォーマンスに大きな悪影響が及ぶ可能性があります。

バッファの使用具合を制御するには、次の 3 つの選択肢のいずれかを使用します。

• システム バッファに関連するパラメータを調整する。

• 入力と出力のキュー（保留キュー）で保留されるパケットの数を指定する。

• トラフィックが転送用にどのようにキューイングされるかを優先付けをする（出力キューイングの優先度）。

これらの選択肢に関連する設定コマンドは、Cisco IOS のコンフィギュレーション ガイドとコマンド リファレンスを参照してください。

次のセクションでは、シリアル/WAN の相互接続で接続性とパフォーマンスの問題の解決に有効な、これらの選択肢の適用がふさわしい状況を識別する方法、および、これらの選択肢を使用する方法に焦点を当てています。

システム バッファの調整

Ciscoルータには、一般的なバッファタイプが2つあります。ハードウェアバッファとシステムバッファシステム管理者が直接に設定できるのは、システム バッファだけです。ハードウェア バッファは各インターフェイスに関連付けられた受信バッファと転送バッファとして個別に使用され、（特に設定されていない場合は、）システム ソフトウェア自体によりダイナミックに管理されます。

システム バッファはメイン システム メモリに関連付けられており、さまざまなサイズのメモリ ブロックに割り当てられています。使用しているシステム バッファのステータスを判別するのに便利なコマンドは、show buffers EXEC コマンドです。図 15-8 には、show buffers コマンドによる出力が示されています。

図 15-8：show buffers コマンドの出力

show buffers の出力には、次の項目があります。

• total：プール内のバッファの総数。これには使用済みバッファと未使用バッファが含まれています。

• permanent：プール内の割り当て済みバッファの固定数。これらのバッファは常にプール内にあり、切り離すことはできません。

• in free list：現在プール内にあって利用可能なバッファの数。

• min：ルート プロセッサ（RP; Route Processor）でフリー リスト内に確保を試みる必要のあるバッファの最小数。

  • min パラメータは、任意の時点でプールからバッファへの要求を予測するときに使用します。

  • フリー リスト内のバッファの数が min の値よりも低い場合、RP ではプールのためのバッファをさらに多く作成しようとします。

• max allowed：フリー リスト内に許可されるバッファの最大数。

  • max allowed パラメータでは、不要になったバッファがプール内で占有されるのが防止され、そのメモリは後の使用に備えてシステムに明け渡されます。

  • フリー リスト内のバッファの数が最大の allowed の値よりも大きい場合、RP ではプールからバッファを切り離す必要があります。

• hits：要求されているプールからのバッファの数。hits カウンタにより、どのプールがバッファの上限のデマンドに適合する必要があるのかを判別する機構が提供されます。

• misses：バッファが要求され、RPが追加バッファが必要なことを検出した回数。（つまり、フリーリスト内のバッファの数がminを下回っています）。 misses カウンタは、RP が追加バッファの作成を強いられた回数を表します。

• trims：フリー リスト内のバッファの数が上限のバッファ数を上回った際に、RP によりプールから切り離されたバッファの数。

• created：プール内で作成されたバッファの数。フリー リスト内のバッファの数がバッファの下限を下回るか、フリー リスト内のバッファがゼロであることにより廃棄が発生するまで、バッファのデマンドが増加していると、RP ではバッファを作成します。

• failures：追加のバッファの作成が試行された後にもかかわらず、リクエスタに対してバッファを許可するのに失敗した数。failures の数は、バッファの不足により廃棄されたパケットの数を示しています。

• no memory：追加のバッファを作成するのにメモリが不足したために発生した障害の数。

図 15-8 にある show buffers コマンドの出力では、大きいバッファに対する trims フィールドと created フィールドの値が高くなっています。これらのフィールドに大きな数が表示される場合は、システムバッファに設定されているmax free値を増やすことで、シリアルリンクのパフォーマンスを向上できます。trims:in free listのバッファ数が最大許容バッファ数を超えた場合に、RPがプールから削除したバッファの数を示します。

buffers max free 数値グローバル設定コマンドを使用して、フリー システム バッファの数を増加させます。設定する値は、show buffers コマンドの出力の total フィールドに示された合計値の約 150 % である必要があります。show buffers の出力に切り離されたバッファと作成されたバッファが表示されなくなるまで、この手順を繰り返します。

show buffers コマンドの出力で、no memory フィールド（図 15-8 の出力の最終行を参照）に大量の障害が示されている場合、ルータでシステムバッファの使用を削減するか、共有またはメイン メモリ（物理 RAM）の総量を増加させる必要があります。お客様のテクニカルサポート担当者に連絡して、サポートを求めてください。

保留キュー制限の実装

保留キューは、ルータの各インターフェイスで発信パケットと着信パレットの保存に使用されるバッファです。ルータでパケットが廃棄されるよりも先にキューイングされたデータ パケットの数を増加させるには、hold-queue インターフェイス設定コマンドを使用します。show interfacesの出力に廃棄が表示されなくなるまで、これらのキューを少し増やします（たとえば、25 %など）。デフォルトの出力保留キューの制限は 100 パケットです。

注：hold-queueコマンドは、プロセス交換パケットとルータによって生成される定期的なアップデートに使用されます。

hold-queue コマンドを使用して、次のような条件でパケットが廃棄されないようにし、シリアル リンクのパフォーマンスを向上させます。

• 使用しているアプリケーションでは廃棄が許容されず、プロトコルでは比較的長い遅延を許容できる。DECnet はこの両方の基準に適合するプロトコルの例です。ローカルエリア トランスポート（LAT）では遅延が許容されないので、これにはあてはまりません。

• インターフェイスが非常に低速である。帯域幅が低いか、使用率が利用可能な帯域幅を散発的に超過することが予想されます。

注：出力保留キューに指定した数を増やすと、システムバッファの数を増やす必要がある場合があります。使用する値は、ネットワークで予想されるトラフィックに関係付けられたパケットのサイズに依存します。

プライオリティ キューイングを使用したボトルネックの緩和

プライオリティ キューイングはリストベースの制御機構で、トラフィックをインターフェイスごとにプライオリティ付けできます。プライオリティ キューイングには、次の 2 つのステップがあります。

1. プロトコル タイプとプライオリティ レベルごとにプライオリティ リストを作成する。

2. 特定のインターフェイスにプライオリティ リストを割り当てる。

これらのステップの両方とも、priority-list グローバル設定コマンドのバージョンを使用します。さらに、priority-list の指定項目から access-list グローバル設定コマンドを参照することにより、さらに高度なトラフィック制御を適用できます。プライオリティ リストを定義する例とプライオリティ キューイングに関連するコマンド構文についての詳細は、Cisco IOS のコンフィギュレーション ガイドとコマンド リファレンスを参照してください。

注：プライオリティキューは、サイズの異なる4つの保留キューを自動的に作成します。これにより、使用しているコンフィギュレーションにある保留キューの設定がすべて上書きされます。

プライオリティ キューイングを使用して、次のような条件でパケットが廃棄されないようにし、シリアル リンクのパフォーマンスを向上させます。

• インターフェイスが低速な場合、転送されるトラフィック タイプは多様で、ターミナル トラフィックのパフォーマンスを向上させる必要があります。

• 散発的に非常に負荷が重くなる（特定の回数で発生するファイル転送など）ようなシリアル リンクがある場合、トラフィックが重い期間中にどのタイプのトラフィックを廃棄するかを選択するのに、プライオリティ キューイングが有効です。

一般的には、プライオリティ キューを実装する際には、デフォルトのキューの数で開始します。プライオリティキューイングをイネーブルにしたら、show interfaces serial EXEC コマンドで出力の廃棄を監視します。高プライオリティに設定したトラフィック キューで出力の廃棄が発生していることが報告された場合は、（priority-list グローバル設定コマンドの queue-limit キーワード オプションを使用して）キューイングできるパケットの数を増加させます。 高プライオリティ キューでのデフォルトの queue-limit 因数は 20 パケットで、中プライオリティ キューでは 40、通常プライオリティ キューでは 60、低プライオリティ キューでは 80 です。

注：Digital Equipment Corporation(DEC)のLATトラフィックをブリッジングする場合、ルータで廃棄するパケットが非常に少なくなるか、LATセッションが予期せず終了する可能性があります。ルータで出力パケットが廃棄されていて、シリアル回線の帯域幅使用率を 50 % 程度にする場合、queue-limit キーワードで指定される高優先度キュー深度は約 100 が通常の運用値です。ルータでパケットが廃棄されていて、使用率が 100 % の場合は、他の回線が必要です。

DEC LAT をブリッジングしている場合、LAT 圧縮で輻輳を緩和するという方法もあります。interface configuration コマンドの bridge-group グループ名 lat-compression で LAT 圧縮を実装できます。

特殊なシリアル回線のテスト

ルータで使用できる基本診断機能以外にも、さまざまな補助ツールやテクニックを使用して、ケーブル、スイッチング機器、モデム、ホスト、およびリモート インターネットワーキング ハードウェアの状態を判別できます。詳細は、使用している CSU、DSU、シリアル アナライザ、あるいはその他の機器のドキュメントを参照してください。

CSU と DSU のループバック テスト

show interfaces serial EXEC コマンドの出力に、シリアル回線がアップしていながら、回線プロトコルがダウンしていることが示されている場合は、CSU/DSU ループバック テストを使用して、問題の発生源を判別します。ローカル ループバック テストを最初に行い、次にリモート テストを行います。図 15-9 には CSU/DSU のローカルとリモートのループバック テストの基本的なトポロジが示されています。

図 15-9：CSU/DSU のローカルとリモートのループバック テスト

注：これらのテストは本質的に一般的であり、インターネットワーキングシステムがCSUまたはDSUに接続されていることを前提としています。一方、このテストは組み込み CSU/DSU 機能によるマルチプレクサへの接続でも本質的に同じです。X.25 やフレームリレー パケット スイッチド ネットワーク（PSN）環境ではループバックという概念はないため、X.25 やフレームリレー ネットワークにはループバック テストは適用されません。

HDLC リンクや PPP リンク用の CSU と DSU のローカル ループバック テスト

次のリストには、組み込みシステム診断機能とともにループバック テストを実行する一般的な手順が示されています。

1. CSU/DSU をローカル ループ モードに設定する（使用しているベンダーのドキュメントを参照）。 ローカル ループ モードで、T1 回線クロックの使用を止めて、DSU でローカル クロックを使用するように設定します。

2. show interfaces serial EXEC コマンドを使用して、「line protocol is down」から「line protocol is up (looped)」にステータスが変化するかどうか、あるいは、ダウンしたままの状態かどうかを判別する。

3. CSU や DSU がローカル ループバック モードにある場合に回線プロトコルがアップする場合、問題はシリアル回線のリモート エンドで発生していることが示唆されます。ステータス回線が変化しない場合、問題はルータ、接続ケーブル、あるいは CSU/DSU にある可能性があります。

4. 問題がローカルであると示される場合は、debug serial interface 特権 EXEC コマンドを使用する。

5. CSU/DSU をローカル ループ モード以外にする。回線プロトコルがダウンしている場合、debug serial interface コマンドの出力には、キープアライブ カウンタが増加していないことが示されます。

6. CSU/DSU をローカル ループ モードに戻す。これにより、キープアライブ パケットの増加が始まります。具体的には、mineseen と yourseen のキープアライブが 10 秒ごとに増加します。この情報は、debug serial interface の出力に示されます。

   キープアライブが増加しない場合、インターフェイス カードかネットワークにタイミング上の問題があると考えられます。タイミング問題の修正に関する情報は、この章で前述されているセクション「クロッキング問題のトラブルシューティング」を参照してください。

   キープアライブが増加しない場合、インターフェイス カードかネットワークにタイミング上の問題があると考えられます。タイミング問題の修正に関する情報は、この章で前述されているセクション「クロッキング問題のトラブルシューティング」を参照してください。

7. ローカルのルータ、CSU/DSU のハードウェア、および接続されているケーブルをチェックする。ケーブルが推奨の長さである 15.24 m（50 フィート）あるいは T1 リンクでは 7.62 m（25 フィート）に収まっていることを確認します。ケーブルが適切なポートに接続されていることを確認します。必要に応じて、障害のある機器を交換します。

図 15-10 には HDLC シリアル接続での debug serial interface コマンドによる出力が示されており、キープアライブの消失により回線がダウンしてインターフェイスがリセットされています。

図 15-10：debug serial interface コマンドの出力

HDLC リンクや PPP リンク用の CSU と DSU のリモート ループバック テスト

ローカルのハードウェアは正常に動作しているものの、シリアル リンクを経由する接続を確立しようとすると依然として問題が発生する場合は、リモート ループバック テストを実行して問題の原因を切り分けます。

注：このリモートループバックテストでは、HDLCカプセル化が使用されており、このテストの直前に前のローカルループテストが実行されたことを前提としています。

ループバック テストを実行するには、次の手順が必要です。

1. リモートの CSU/DSU をリモート ループ モードに設定する（使用しているベンダーのドキュメントを参照）。

2. show interfaces serial EXEC コマンドを使用して、ステータス行が「Serial x is up, line protocol is up (looped).」と表示されていて回線プロトコルがアップ状態のままか、ステータス行が「line protocol is down.」と表示されていてダウン状態になったか判断する。

3. 回線プロトコルがアップ状態のまま（looped）の場合、問題は（リモート CSU/DSU とリモート ルータ間の）シリアル接続のリモート エンド側にある可能性が高くなります。 リモート側でローカルとリモートのテストを実行し、問題の原因を切り分けます。

4. リモート ループバック モードがアクティブな際に回線ステータスが「line protocol is down」に変わる場合は、ones density が適切に維持されていることを確認する。専用回線その他のキャリア サービスで使用されているものと同じフレーミングとコーディングのスキーム（たとえば、ESF と B8ZS）を使用するように、CSU/DSU が設定されている必要があります。

5. 問題が解決されない場合は、WAN のネットワーク管理者かサービス組織にお問い合せください。

show interfaces serial コマンドに関する詳細情報

これに続くサブセクションでは、show interfaces serial コマンドのパラメータ、構文説明、サンプル出力表示、およびフィールドの説明が紹介されています。

show interfaces serial のパラメータ

シリアル インターフェイスに関する情報を表示するには、show interfaces serial 特権 EXEC コマンドを使用します。

show interfaces serial [number] [accounting]
show interfaces serial [number [:channel-group] [accounting] (Cisco 4000 series)
show interfaces serial [slot | port [:channel-group]] [accounting] (Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [serial] 
(ports on VIP cards in the Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [:t1-channel] [accounting | crb]
(CT3IP in Cisco 7500 series)

シンタックスの説明

• number：オプション。リッスンするようにします。

• accounting：オプション。インターフェイスを介して送信された各プロトコルタイプのパケット数を表示します。

• :channel-group：オプション。NPMを搭載したCisco 4000シリーズまたはMIPを搭載したCisco 7500シリーズでは、channel-group controllerコンフィギュレーションコマンドで定義される0 ～ 23の範囲のT1チャネルグループ番号を指定します。

• slot：スロット情報は該当するハードウェア マニュアルに記載されています。

• port：ポート情報は該当するハードウェア マニュアルに記載されています。

• port-adapter：ポート アダプタの互換性に関する情報は該当するハードウェア マニュアルに記載されています。

• :t1-channel – オプション。CT3IPでは、T1チャネルは1 ～ 28の数値です。

• CT3IP 上の T1 チャネルには 1 から 28 までの番号が付けられています。これは他の Cisco 製品で使用されている、従来のゼロから始める方式（0 ～ 27）とは異なります。これは、チャネライズド T3 機器内部の T1 チャネルに対する電話会社での番号付け方式と一貫性を持たせるようにしたためです。

• crb：オプション。インターフェイスのルーティングおよびブリッジング情報を表示します。

コマンド モード

特権 EXEC

使用上のガイドライン

Cisco 4000 シリーズでこのコマンドが最初に使用されたのは、Cisco IOS リリース 10.0 です。Cisco 7000 シリーズでこのコマンドが最初に使用されたのは、Cisco IOS リリース 11.0 で、Cisco IOS リリース 11.3 で CT3IP を含むように修正されています。

表示例

次に、同期シリアル インターフェイスでの show interfaces コマンドの出力例を示します。

Router# show interfaces serial
Serial 0 is up, line protocol is up
   Hardware is MCI Serial
   Internet address is 150.136.190.203, subnet mask is 255.255.255.0
   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
   Encapsulation HDLC, loopback not set, keepalive set (10 sec)
   Last input 0:00:07, output 0:00:00, output hang never
   Output queue 0/40, 0 drops; input queue 0/75, 0 drops
   Five minute input rate 0 bits/sec, 0 packets/sec
   Five minute output rate 0 bits/sec, 0 packets/sec
       16263 packets input, 1347238 bytes, 0 no buffer
       Received 13983 broadcasts, 0 runts, 0 giants
       2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
1 carrier transitions 
     22146 packets output, 2383680 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts

フィールドの説明

表 15-9：show interfaces serial のフィールドの説明：この表では、出力中の重要なフィールドが説明されています。

フィールド	説明
シリアル...が{up |ダウン}...管理上ダウン	インターフェイスのハードウェアが現在アクティブになっている（キャリアが検出されている）かどうか、あるいは、管理者によってダウンにされているかどうかが示される。
line protocol is {up |ダウン}	プロトコルを処理するソフトウェア プロセスで回線が使用可能（キープアライブが成功している）と認識されているかどうか、あるいは、管理者によってダウンにされているかどうかが示される。
line protocol is {up |ダウン}	プロトコルを処理するソフトウェア プロセスで回線が使用可能（キープアライブが成功している）と認識されているかどうか、あるいは、管理者によってダウンにされているかどうかが示される。
Hardware is	ハードウェアのタイプが指定される。
Internet address is	インターネット アドレスとサブネット マスクが指定される。
MTU	インターフェイスの Maximum Transmission Unit（MTU; 最大伝送ユニット）。
BW	インターフェイスに設定されている帯域幅パラメータの値（Kbps）が表示される。 この帯域幅パラメータが使用されるのは、IGRP メトリックを算出するためだけです。デフォルト（T1 では 1536 か 1544、標準同期シリアル回線では 56）に一致しない回線速度でシリアル回線にインターフェイスが接続されている場合、bandwidth コマンドを使用して、そのシリアル回線に適切な回線速度を指定します。
DLY	マイクロ秒単位でのインターフェイスの遅延。
rely	255 に対する比率で表されたインターフェイスの信頼性（255/255 が 100 % の信頼性）で、5 分間の幾何平均で算出される。
負荷	255 に対する比率で表されたインターフェイスの信頼性（255/255 が 100 % の信頼性）で、5 分間の幾何平均で算出される。
カプセル化	インターフェイスに割り当てられているカプセル化メソッド。
ループバック	ループバックが設定されているかどうかが示される。
keepalive	キープアライブが設定されているかどうかが示される。
Last input	インターフェイスで最後にパケットが正常に受信されてから現在までの時間数、分数、秒数。インターフェイスの障害がいつ発生したかを知る場合に役立ちます。
Last output	インターフェイスで最後にパケットが正常に送信されてから現在までの時間数、分数、秒数。
output hang	転送にかかった時間が長すぎたためにインターフェイスが最後にリセットされてから現在までの時間数、分数、秒数（あるいは、なし）。最後のフィールドのいずれかの時間数が 24 を超過すると、日数と時間数が表示されます。フィールドがオーバーフローすると、アスタリスク（*）が表示されます。
Output queue, drops input queue, drops	出力キューと入力キュー内のパケット数。各数値の後にスラッシュ（/）とキューの最大サイズ、およびキューがフルになったために廃棄されたパケット数が続きます。
5 minute input rate 5 minute output rate	過去 5 分間に転送された 1 秒間あたりの平均ビット数とパケット数。この 5 分間の入出力レートを使用できるのは、任意の 5 分間での 1 秒あたりのトラフィックの概算値としてのみです。これらのレートは 5 分間の時間定数による指数加重平均です。この平均がその期間中のトラフィックの均一なストリームの瞬間的なレートの 2 % に収まる前には、時間定数 4 つ分の期間が経過する必要があります。
packets input	システムでエラーなしで受信されたパケットの総数。
バイト	システムで受信されたエラーのないパケット内のデータと MAC のカプセル化が含まれる総バイト数。
no buffer	メイン システム内のバッファ スペースがないために廃棄された受信パケット数。無視された数と比較します。イーサネット ネットワークでのブロードキャスト ストームとシリアル回線でのノイズのバーストが、no input buffer イベントの原因となることがよくあります。
Received... broadcasts	インターフェイスで受信されたブロードキャスト パケットとマルチキャスト パケットの総数。
runts	メディアの最小パケット サイズよりも小さいために廃棄されたパケット数。
giants	メディアの最大パケット サイズよりも大きいために廃棄されたパケット数。
入力エラー	no buffer、runts、giants、CRCs、frame、overrun、ignored、および abort の総数。これ以外の入力関連エラーでもこのカウントは増加する場合があるため、この総数は他のカウントの合計と等しくならない可能性があります。
CRC	発信元のステーションまたは遠端のデバイスによって生成された CRC が、受信データから計算したチェックサムと一致しない。シリアル リンクの場合、通常、CRC フィールドで示されるものは、ノイズ、ゲイン ヒット、あるいはデータ リンクでのその他の転送上の問題です。
フレーム	CRC エラーおよび非整数のオクテットを持つため、正しく受信されなかったパケットの数。シリアル回線の場合、通常、これはノイズやその他の転送上の問題による結果です。
overrun	入力レートがレシーバのデータ処理能力を超えたために、シリアル レシーバ ハードウェアが受信データをハードウェア バッファに渡すことができなかった回数。
無視	インターフェイスのハードウェアの内部バッファでの動作が低速なため、インターフェイスで無視された受信パケットの数。ブロードキャスト ストームおよびノイズのバーストによって、ignored のカウントが増加する場合があります。
中断	シリアル インターフェイスでのビット列の不正なシーケンス。通常、これはシリアル インターフェイスとデータ リンク機器間のクロッキングの問題を示しています。
carrier transitions	シリアル インターフェイスのキャリア検出シグナルでステートが変わった回数。たとえば、データ キャリア検出（DCD）がダウンになってからアップに戻る場合、carrier transitions カウンタは 2 回増加します。キャリア検出回線でステートが頻繁に変わっている場合、モデムか回線の問題が示されています。
packets output	システムで転送されたメッセージの総数。
bytes output	データと MAC のカプセル化を含む、システムで転送された総バイト数。
Underruns	ルータの処理能力を超えた速度でトランスミッタが動作した回数。一部のインターフェイスでは、これは報告されない可能性があります。
出力エラー	検査中のインターフェイスからのデータグラムの最終的な送信を妨害したすべてのエラーの総数。この数は列挙された出力エラー数の合計値と等しくならないことがあります。これは、データグラムによっては、複数のエラーや、個別に集計されるどのカテゴリにも属さないエラーがあるためです。
コリジョン	イーサネットのコリジョンのために再送されたメッセージ数。通常、過剰に拡張された LAN（イーサネットやトランシーバのケーブルが長すぎるか、ステーション間に設置されたリピータが 2 基よりも多いか、カスケード接続されたマルチポート トランシーバが多すぎる）がこの原因です。 一部のコリジョンは通常のものです。ところが、コリジョン率が 4 ～ 5 % 前後に上昇する場合は、セグメント上に問題のある機器がないことを確認することや、既存のステーションの一部を新しいセグメントに移動すること、あるいはその両方を検討する必要があります。出力パケットでは、コリジョンを起こしたパケットは一度だけカウントされます。
interface resets	インターフェイスが完全にリセットされた回数。インターフェイス リセットは、送信のためにキューイングされたパケットが数秒以内に送られなかった場合に発生する可能性があります。シリアル回線では、転送クロック シグナルを供給していない誤動作モデム、あるいは、ケーブル接続の問題でこれが発生する場合があります。シリアル インターフェイスのキャリア検出ラインがアップになっていながら、回線プロトコルがダウンしていることがシステムで検出された場合、システムではインターフェイスを再起動するための対応として間歇的にリセットをかけます。また、インターフェイスがループバックまたはシャットダウンされたときにも、インターフェイスのリセットが発生することがあります。
再起動	コントローラがエラーにより再起動された回数。
alarm indications, remote alarms, rx LOF, rx LOS	CSU/DSU アラーム数、フレームの受信消失とシグナルの受信消失の発生数。
BER inactive, NELR inactive, FELR inactive	ビット エラー レート（BER）アラーム、近端ループ リモート（NELR）、および遠端ループ リモート（FELR）に関する G.703-E1 カウンタのステータス。 NELR や FELR は設定できないことに注意してください。

T1 のトラブルシューティング

このセクションでは、ダイヤルイン カスタマーのための T1 回線のトラブルシューティングの方法と手順について説明しています。

show controller t1 コマンドを使用するトラブルシューティング

このコマンドでは、そのコントローラのハードウェアに特有のコントローラのステータスが表示されます。ここで表示される情報は、通常、テクニカル サポートのスタッフが診断タスクを行う際にのみ役立ちます。

NMP（ネットワーク管理プロセッサ）や MIP（マルチチャネル インターフェイス プロセッサ）では、ポート アダプタに照会して現在のステータスを確認できます。T1 リンクに関する統計情報を表示するには、show controller t1 コマンドを発行します。

スロットおよびポート番号を指定すると、15 分ごとの統計が表示されます。show controller t1 EXEC コマンドでは、物理層とデータリンク層の問題を論理的にトラブルシューティングするための情報が提供されます。このセクションでは、show controller t1 コマンドを使用して論理的にトラブルシューティングを行う方法を説明しています。

T1 エラーのほとんどは、誤設定された回線が原因で発生します。回線コーディング、フレーミング、およびクロック ソースは、お客様のサービス プロバイダーの提案に従って設定されていることを確認してください。

show controller t1 の状態

T1 コントローラは、次の 3 つ状態のいずれかになっている可能性があります。

• 管理上ダウン

• 停止

• 稼働

T1 コントローラが管理上ダウンになっているか。

コントローラは手動でシャットダウンされた場合、管理上ダウンしています。このエラーを修復するには、コントローラを再起動する必要があります。

1. イネーブル モードに入ります。

   maui-nas-03>en
   Password: 
   maui-nas-03#

2. グローバル コンフィギュレーション モードに入ります。

   maui-nas-03#configure terminal
   Enter configuration commands, one per line. End with CNTL/Z.
   maui-nas-03(config)#

3. コントローラ設定モードに入ります。

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#

4. コントローラを再起動する。

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

回線がアップしているか。

T1 コントローラと回線がアップしていない場合、show controller t1 EXEC コマンド出力に次のメッセージのいずれかが表示されているか確認してください。

• Receiver has loss of frame

• Receiver has loss of signal

T1 レシーバでフレーム消失があるか。

T1 レシーバでフレーム消失がある場合、次の手順に従ってください。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。コントローラのフレーミング フォーマットは、実行コンフィギュレーションまたは show controller t1 コマンドの出力で確認できます。

   フレーミングフォーマットを変更するには、framing {SF | ESF}コマンドを使用します。

   maui-nas-03#configure terminal
   

   Enter configuration commands, one per line.CNTL/Z で終了します。

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#framing esf
   

2. もう一方のフレーミング フォーマットを試用して、アラームが消えるか確認します。

3. cablelength {long | short}コマンド。

ライン ビルドアウト（LBO）では、デバイスから回線内の最初のリピータまでの距離に基づいて、デシベルの損失が補正されます。デバイスからリピータまでの距離が長いと、その距離に要した損失を補正するために、回線上の信号強度を高める必要があります。

ビルドアウト設定についての詳細は、お客様のサービス プロバイダーに問い合せて、さらに Cisco IOS(R) コマンド リファレンスを参照してください。

それでも問題が解決しない場合は、次の「T1 レシーバでシグナル消失があるか。」セクションを参照してください。

T1 レシーバでシグナル消失があるか。

T1 レシーバでシグナル消失がある場合、次の手順に従ってください。

1. インターフェイス ポートと、T1 サービス プロバイダーの機器（または T1 端末機器）をつなぐケーブルが正しく接続されていることを確認する。ケーブルが正しいポートに接続されているか確認します。必要な場合は、ケーブルを接続し直してください。

2. ケーブルの整合性を確認する。ケーブルに破損またはその他の物理的異常がないか調べます。ピン配置の設定が正しいことを確認します。必要な場合は、ケーブルを交換します。

3. ケーブル コネクタを確認します。送信および受信ペア、またはオープン受信ペアが反転していると、エラーの原因となります。受信ペアを回線1と2に設定し、送信ペアを回線4と5に設定します。

   RJ-45ジャックのピンには1 ～ 8の番号が付いています。ピン1は、金属ピンが向いているジャックを見るときに一番左のピンです。次の図を参照してください。

   図 15-10：RJ-45 ケーブル

   

4. ロールオーバー ケーブルを使用してみる。

各ステップが終了した後で show controller t1 EXEC コマンドを発行して、コントローラにエラーが発生していないか確認します。

回線がループバック モードになっているかを、show controller t1 コマンドの出力で確認します。回線をループバック モードにするのはテスト目的の場合に限ります。

ループバックをオフにするには、次のように、コントローラ コンフィギュレーション モードで no loopback コマンドを使用します。

maui-nas-03(config-controlle)#no loopback

コントローラで何らかのエラーが表示されているか。

show controller コマンドの出力をチェックして、コントローラにアラームが表示されているか確認します。

以降、さまざまなアラームとその修復に必要な手順を説明します。

受信（RX）アラーム表示信号（AIS）（青）：

アラーム表示信号（AIS）を受信した場合、そのポートに接続された機器のアップストリームの回線にアラームが発生していることが示されています。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。一致していない場合は、コントローラのフレーミング フォーマットを回線に一致させるように変更します。

2. お客様のサービス プロバイダーに問い合せて、電話会社部分での誤設定をチェックする。

受信（RX）リモート アラーム表示（RAI）（黄）：

RAI を受信した場合、遠端の機器でアップストリームの機器から受信しているシグナルに関して問題があることが示されています。

1. 外部ループバック ケーブルをポートに挿入します。ループバック プラグを製作するには、この章のセクション「ループバック プラグの製作」を参照してください。

2. 何らかのアラームがあるかどうかをチェックする。アラームが何も表示されていない場合、ローカルのハードウェアはおそらく良好な状態です。その場合、次の手順を実行します。

   1. ケーブル配線を調べます。詳細は、セクション「T1 レシーバでシグナル消失があるか。」を参照してください。

   2. リモート エンドで設定を確認し、これがポート設定と一致するか確認します。

   3. 問題が続くようであれば、サービス プロバイダーに問い合わせてください。

3. ループバック プラグを取りはずして、T1 回線に再接続します。

4. ケーブル配線を調べます。詳細は、セクション「T1 レシーバでシグナル消失があるか。」を参照してください。

5. ルータの電源をオフ/オンします。

6. T1 回線を別のポートに接続します。そのポートを回線の設定に合せて設定します。これで問題が解消した場合は、一方のポートに問題があります。

   1. T1 回線を元のポートに再接続します。

   2. 「T1 エラー イベントのトラブルシューティング」セクションに進む。

      問題が解決しない場合は、次の手順を実行します。

7. セクション「ハードウェア ループバック プラグ テストの実行」での説明に従って、ハードウェア ループ テストを実行する。

8. T1 コントローラ カードを交換します。

9. 「T1 エラー イベントのトラブルシューティング」セクションに進む。

トランスミッタがリモート アラームを送信（赤）：

赤アラームが表示されるのは、CSU で T1 回線でのフレーミング パターンの同期ができない場合です。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。一致していない場合は、コントローラのフレーミング フォーマットを回線に一致させるように変更します。

2. リモート エンドで設定を確認し、これがポート設定と一致するか確認します。

3. お客様のサービス プロバイダーにお問い合せください。

送信（TX）リモート アラーム表示（RAI）（黄）：

インターフェイスで送信された RAI は、インターフェイスで遠端の機器から受信しているシグナルに関して問題があることを示しています。

1. リモート エンドで設定を確認し、これがポート設定と一致するか確認します。

2. 送信 RAI には、遠端の機器からのシグナルに関して T1 ポート/カードに発生している問題の性質を示すその他のアラームが付随しているはずです。

その状態をトラブルシューティングして、送信 RAI を解決します。

送信（TX）AIS（青）：

次の手順に従って、送信（TX）AIS（青）を解決します。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。一致していない場合は、不一致を修正します。

2. ルータの電源をオフ/オンします。

3. T1 回線を別のポートに接続します。そのポートを回線の設定に合せて設定します。

4. セクション「ハードウェア ループバック プラグ テストの実行」での説明に従って、ハードウェア ループ テストを実行する。

5. T1 コントローラ カードを交換します。

6. 「T1 エラー イベントのトラブルシューティング」セクションに進む。

T1 エラー イベントのトラブルシューティング

show controller t1 EXEC コマンドでは、問題のトラブルシューティングに利用できるエラー メッセージが表示されます。以降、いくつかのエラー メッセージとそのエラーの修復方法を説明します。

エラー カウンタが増加しているかどうかを確認するには、繰り返し show controller t1 コマンドを実行します。現在の間隔でのカウンタの値を記録します。

フレーミングと回線コーディングの設定については、お客様のサービス プロバイダーにお問い合せください。経験的には、B8ZS 回線コーディングと ESF フレーミングの組み合わせ、および、AMI 回線コーディングと SF フレーミングの組み合わせが適切な方法です。

Slip Secs カウンタが増加中：

T1 回線でスリップがある場合、クロッキングの問題が示されています。T1 プロバイダー（電話会社）から、宅内装置（CPE）を同期させるクロッキングが供給されます。

1. クロック ソースがネットワークから導出されていることを確認する。これは、「Clock Source is Line Primary」を探すことにより確認できます。

   注：アクセスサーバに複数のT1が存在する場合は、プライマリになれるのは1つだけですが、他のT1はプライマリからクロックを取得します。これに該当する場合は、プライマリ クロックに指定された T1 回線が適切に設定されていることを確認してください。

2. コントローラ コンフィギュレーション モードで T1 クロック ソースを適切に設定する。

   maui-nas-03(config-controlle)#clock source line primary
   

Framing Loss Seconds カウンタが増加中：

Framing Loss Seconds カウンタが増加している場合は、次の手順に従ってください。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。これは、show controller t1 の出力で Framing is {ESF|SF} を探すことによりチェックできます。

2. フレーミングフォーマットを変更するには、framing {SF | ESF}コマンドを使用します。

   maui-nas-03(config-controlle)#framing esf
   

3. cablelength {long | short}コマンド。

ビルドアウト設定についての詳細は、お客様のサービス プロバイダーに問い合せて、さらに Cisco IOS(R) コマンド リファレンスを参照してください。

Line Code Violations が増加中：

Line Code Violations が増加している場合は、次の手順に従ってください。

1. ポートに設定された回線コーディングが、回線のフレーミング フォーマットと一致していることを確認する。これは、show controller t1 の出力で Line Code is {B8ZS|AMI} を探すことによりチェックできます。

2. 回線コーディングを変更するには、linecode {ami | b8zs}コマンドを使用します。

   maui-nas-03(config-controlle)#linecode b8zs
   

3. cablelength {long | short}コマンド。

ビルドアウト設定についての詳細は、お客様のサービス プロバイダーに問い合せて、さらに Cisco IOS(R) コマンド リファレンスを参照してください。

ISDN スイッチ タイプと PRI グループが正しく設定されていることの検証

show running-config コマンドを使用して、ISDN スイッチ タイプと PRI グループのタイムスロットが適切に設定されていることを確認します。適切な値については、お客様のサービス プロバイダーにお問い合せください。

ISDN スイッチ タイプと PRI グループの変更方法

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-5ess
maui-nas-03(config)#controller t1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-24

シグナリング チャネルの検証

エラー カウンタ類が増加していないのに問題が残っている場合は、シグナリング チャネルがアップになっていて、適切に設定されていることを確認します。

1. show interface serial x:23 コマンドを実行する。この x にはインターフェイス番号を指定します。

2. インターフェイスがアップになっているかどうかを確認する。インターフェイスがアップしていない場合は、no shutdown コマンドを使用してインターフェイスをアップします。

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

3. カプセル化が PPP であることを確認する。インターフェイスで PPP が使用されていない場合は、インターフェイス コンフィギュレーション モードで encapsulation ppp コマンドを使用して、これを修正します。

   maui-nas-03(config-if)#encapsulation ppp
   

4. ループバックが設定されているかどうかを確認する。ループバックはテストの目的にだけ設定します。no loopback コマンドを使用してループバックを削除します。

   maui-nas-03(config-if)#no loopback
   

5. ルータの電源をオフ/オンします。

6. 問題が解消されない場合は、お客様のサービス プロバイダーあるいは Cisco の TAC にお問い合せください。

PRI のトラブルシューティング

PRI のトラブルシューティングを行う際には常に、両端で T1 が問題なく稼働しているかどうかをチェックする必要があります。上記のように、レイヤ 1 の問題が解決されたら、レイヤ 2 とレイヤ 3 の問題を検討します。

show isdn status コマンドを使用するトラブルシューティング

すべての ISDN インターフェイスのスナップショットを表示するには、show isdn status コマンドを使用します。これにより、レイヤ 1、2、3 のステータスが表示されます。

1. レイヤ 1 がアクティブであることを確認する。

   レイヤ 1 のステータスは、T1 がダウンしていない限り、常に ACTIVE と表示されているはずです。show isdn status でレイヤ 1 が DEACTIVATED と表示される場合、T1 回線の物理的な接続に問題があります。セクション「T1 コントローラが管理上ダウンになっているか。」を参照してください。

   T1 が管理上ダウンにはなっていないことも確認してください。T1 コントローラをアップにするには、no shutdown コマンドを使用します。

2. レイヤ 2 の状態が MULTIPLE_FRAME_ESTABLISHED であることをチェックする。

望ましいレイヤ 2 の状態は Multiple_Frame_Established で、これはレイヤ 2 フレームの交換が行われており、レイヤ 2 の初期化が完了していることを示しています。

レイヤ 2 が Multiple_Frame_Established ではない場合、show controller t1 EXEC コマンドを使用して、問題を診断します。この章の「show controller t1 コマンドを使用するトラブルシューティング」セクションを参照してください。

show isdn status は現在のステータスのスナップショットなので、Mulitple_Frame_Established が表示されているにもかかわらず、レイヤ 2 の状態がアップとダウンに頻繁に切り替わる場合があります。レイヤ 2 が安定した状態であることを確認するには、debug isdn q921 コマンドを使用します。

debug isdn q921 コマンドでは、D チャネル上のルータで行われているデータ リンク レイヤ（レイヤ 2）のアクセス手順が表示されます。

必要に応じて、logging console コマンドか terminal monitor コマンドを使用して、debug メッセージが表示されるように設定されていることを確認します。

注：実稼働環境では、コンソールロギングが無効になっていることを確認してください。show logging コマンドを入力します。ロギングがイネーブルになっている場合、コンソール ポートがログ メッセージで過負荷状態になるとアクセス サーバが断続的にフリーズする可能性があります。no logging console コマンドを入力します。

注：debug isdn q921がオンで、デバッグ出力を受信しない場合は、コールを発信するか、コントローラをリセットしてデバッグ出力を取得します。

1. レイヤ 2 が安定していることを確認する。

   debug 出力で、サービスの状態がアップとダウンに頻繁に切り替わっていないことを示すメッセージを探す必要があります。次のタイプの debug 出力が表示されている場合、回線は安定していません。

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed 
   to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller T1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
   
   

   レイヤ 2 が安定しているようには見えない場合、この章で前述されている「T1 エラー イベントのトラブルシューティング」を参照してください。

2. 送信（TX）側と受信（RX）側の両方で SAPI メッセージだけが表示されていることを確認する。

   Mar 20 10:06:52.505: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:23: TX ->  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. レイヤ 2 で初期化が再試行されていることを示す SABME メッセージが表示されていないことを確認する。通常、これが表示されるのは、ポール要求（RRp）を転送していて、スイッチからの応答（RRf）を受信していないか、あるいはその逆である場合です。次に SABME メッセージの例を示します。

   Mar 20 10:06:21.702: ISDN Se0:23: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:23: TX ->  SABMEp sapi = 0  tei = 0

   SABME メッセージが表示されている場合は、show running-config コマンドを使用して、ISDN スイッチ タイプと PRI グループのタイムスロットが適切に設定されていることを確認します。適切な値については、お客様のサービス プロバイダーにお問い合せください。

   ISDN スイッチ タイプと PRI グループの変更方法

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-5ess
   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-24
   

4. show interfaces serial x:23 コマンドを使用して、D チャネルがアップになっていることを確認する。

   D チャネルがアップになっていない場合は、no shutdown コマンドを使用してアップにします。

   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

5. カプセル化が PPP であるかどうかを確認する。そうでない場合は、encapsulation ppp コマンドを使用してカプセル化を設定します。

   maui-nas-03(config-if)#encapsulation ppp
   

6. インターフェイスがループバック モードになっているかどうかを確認する。通常の運用では、インターフェイスはループバック モードではない必要があります。

   maui-nas-03(config-if)#no loopback
   

7. ルータの電源をオフ/オンします。

8. 問題が解消されない場合は、お客様のサービス プロバイダーあるいは Cisco の TAC にお問い合せください。

ハードウェア ループバック プラグ テストの実行

ハードウェア ループバック プラグ テストを使用して、ルータに何らかの問題があるかどうかをテストできます。ルータがハードウェア ループバック プラグ テストをパスした場合は、問題は回線上のルータ以外の場所で発生しています。

ループバック プラグの製作

次の手順でループバック プラグを製作します。

1. 機能している RJ-45 か RJ-48 のケーブルをカッターで切断して、一端にコネクタが付いた 5 インチのケーブルを製作する。

2. ワイヤーの被覆をはがします。

3. ピン 1 につながるワイヤとピン 4 につながるワイヤを撚り合せる。

4. ピン 2 につながるワイヤとピン 5 につながるワイヤを撚り合せる。

RJ-45/48ジャックのピンには1 ～ 8の番号が付けられています。ピン1は、金属ピンが向いているジャックを見る際の左端のピンです。

ループバック プラグ テストの実行

次の手順でループバック プラグテストを実行します。

1. 対象の T1 ポートにプラグを挿入する。

2. write memory コマンドを使用して、ルータの設定を保存する。

   maui-nas-03#write memory
   Building configuration...
   [OK]

3. カプセル化を HDLC に設定する。

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0
   maui-nas-03(config-if)#enc
   maui-nas-03(config-if)#encapsulation HDLC 
   maui-nas-03(config-if)#^Z
   

4. show running-config コマンドを使用して、インターフェイスに IP アドレスが設定されているがどうかを確認する。

   インターフェイスに IP アドレスが設定されていない場合は、一意なアドレスを取得して、そのアドレスをサブネット マスク 255.255.255.0 でインターフェイスに割り当てます。

   maui-nas-03(config)#ip address 172.22.53.1 255.255.255.0
   

5. clear counters コマンドを使用して、インターフェイスのカウンタをクリアします。

   maui-nas-03#clear counters
   Clear "show interfaces" counters on all interfaces [confirm]
   maui-nas-03#

6. この章で前述されている「拡張 ping テストの使用」セクションで説明されているように、拡張 ping テストを実行する。

E1 のトラブルシューティング

このセクションでは、ダイヤルイン カスタマーのための E1 回線のトラブルシューティングの方法と手順について説明しています。

show controller e1 コマンドを使用するトラブルシューティング

このコマンドでは、そのコントローラのハードウェアに特有のコントローラのステータスが表示されます。ここで表示される情報は、通常、テクニカル サポートのスタッフが診断タスクを行う際にのみ役立ちます。

NMP（ネットワーク管理プロセッサ）や MIP（マルチチャネル インターフェイス プロセッサ）では、ポート アダプタに照会して現在のステータスを確認できます。E1 リンクに関する統計情報を表示するには、show controller e1 コマンドを発行します。スロットおよびポート番号を指定すると、15 分ごとの統計が表示されます。

show controller e1 EXECコマンドは、物理層とデータリンク層の問題を論理的にトラブルシュートするための情報を提供します。このセクションでは、show controller e1 コマンドを使用して論理的にトラブルシューティングを行う方法を説明しています。

E1 エラーのほとんどは、誤設定された回線が原因で発生します。回線コーディング、フレーミング、クロック ソース、および回線終端（平衡型あるいは不平衡型）は、お客様のサービス プロバイダーの提案に従って設定されていることを確認ください。

show controller e1 の状態

E1 コントローラは、次の 3 つ状態のいずれかになっている可能性があります。

• 管理上ダウン

• 停止

• 稼働

E1 コントローラが管理上ダウンになっているか。

コントローラは手動でシャットダウンされた場合、管理上ダウンしています。このエラーを修復するには、コントローラを再起動する必要があります。

1. イネーブル モードに入ります。

   maui-nas-03>enable
   Password: 
   maui-nas-03#

2. グローバル コンフィギュレーション モードに入ります。

   maui-nas-03#configure terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#

3. コントローラ設定モードに入ります。

   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#

4. コントローラを再起動する。

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

回線がアップしているか。

E1 回線がアップしていない場合、回線コンフィギュレーションが適切でリモート エンドの設定に一致していることを確認します。

1. 回線とリモート エンドのフレーミングをチェックする。E1 回線では、フレーミングは CRC4 か noCRC4 のいずれかです。

2. 回線とリモート エンドの回線コーディングをチェックする。回線コーディングは AMI か HDB3 のいずれかです。

3. 回線の終端が平衡型か不平衡型（75 Ωか 120 Ω）に設定されているかどうかをチェックする。

適切な設定についての詳細は、お客様のサービス プロバイダーにお問い合せください。ローカルとリモート エンドのデバイスの両方に対して、必要に応じた変更を加えます。

E1 コントローラと回線がアップしていない場合、show controller e1 EXEC コマンド出力に次のメッセージのいずれかが表示されているか確認してください。

• Receiver has loss of frame

• Receiver has loss of signal

E1 レシーバでフレーム消失があるか。

E1 レシーバでフレーム消失がある場合は、次の手順を実行してください。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。コントローラのフレーミング フォーマットは、実行コンフィギュレーションまたは show controller e1 コマンドの出力で確認できます。

   フレーミングフォーマットを変更するには、framing {CRC4 | no CRC4}コマンドを使用します。

   maui-nas-03#configure terminal 
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#controller E1 0
   maui-nas-03(config-controlle)#framing CRC4
   

2. もう一方のフレーミング フォーマットを試用して、アラームが消えるか確認します。

   それでも問題が解決しない場合は、次の「E1 レシーバでシグナル消失があるか。」セクションを参照してください。

3. リモート エンドのフレーミング フォーマットをチェックする。

4. リモート エンドの回線コーディングをチェックする。

E1 レシーバでシグナル消失があるか。

E1 レシーバでシグナル消失がある場合は、次の手順を実行してください。

1. インターフェイス ポートと、E1 サービス プロバイダーの機器（または E1 端末機器）をつなぐケーブルが正しく接続されていることを確認する。ケーブルが正しいポートに接続されているか確認します。必要な場合は、ケーブルを接続し直してください。

2. ケーブルの整合性を確認する。ケーブルに破損またはその他の物理的異常がないか調べます。ピン配置の設定が正しいことを確認します。必要な場合は、ケーブルを交換します。

3. ケーブル コネクタを確認します。送信および受信ペア、またはオープン受信ペアが反転していると、エラーの原因となります。受信ペアを回線1と2に設定し、送信ペアを回線4と5に設定します。

   RJ-48ジャックのピンには1 ～ 8の番号が付いています。ピン1は、金属ピンが向いているジャックを見るときに一番左のピンです。詳細については、次の図を参照してください。

   図 15-11：RJ-45 ケーブル

   

4. ロールオーバー ケーブルを使用してみる。

5. 遠端ブロック エラーがあるかどうかをチェックする。このエラーがある場合は、ローカル エンドでのレシーバのリード線に問題があります。TAC に問い合せて、サポートを依頼してください。

各ステップが終了した後で show controller e1 EXEC コマンドを発行して、コントローラにエラーが発生していないか確認します。

回線がループバック モードか。

回線がループバック モードになっているかを、show controller e1 コマンドの出力で確認します。回線をループバック モードにするのはテスト目的の場合に限ります。

ループバックをオフにするには、次のように、コントローラ コンフィギュレーション モードで no loopback コマンドを使用します。

maui-nas-03(config-controlle)#no loopback

コントローラで何らかのエラーが表示されているか。

show controller コマンドの出力をチェックして、コントローラにアラームが表示されているか確認します。

以降、さまざまなアラームとその修復に必要な手順を説明します。

レシーバ（RX）でのリモート アラーム：

リモート アラームを受信した場合、そのポートに接続された機器のアップストリームの回線にアラームが発生していることが示されています。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。一致していない場合は、コントローラのフレーミング フォーマットを回線に一致させるように変更します。

2. リモート エンド機器の回線コーディングをチェックする。正しい設定については、サービス プロバイダーにお問い合わせください。必要に応じて、誤設定をすべて修正します。

3. 外部ループバック ケーブルをポートに挿入します。ループバック プラグを製作するには、この章で前述されているセクション「ループバック プラグの製作」を参照してください。

4. 何らかのアラームがあるかどうかをチェックする。アラームが何も表示されていない場合、ローカルのハードウェアはおそらく良好な状態です。その場合、次の手順を実行します。

   1. ケーブル配線を調べます。詳細は、セクション「E1 レシーバでシグナル消失があるか。」を参照してください。

   2. リモート エンドで設定を確認し、これがポート設定と一致するか確認します。

   3. 問題が続くようであれば、サービス プロバイダーに問い合わせてください。

5. ループバック プラグを取り外して、E1 回線を再接続する。

6. ケーブル配線を調べます。詳細は、セクション「E1 レシーバでシグナル消失があるか。」を参照してください。

7. ルータの電源をオフ/オンします。

8. E1 回線を別のポートに接続します。そのポートを回線の設定に合せて設定します。これで問題が解消した場合は、一方のポートに問題があります。

   1. 元のポートに E1 回線を再接続します。

   2. 「E1 エラー イベントのトラブルシューティング」セクションに進む。

      問題が解決しない場合は、次の手順を実行します。

9. セクション「ハードウェア ループバック プラグ テストの実行」での説明に従って、ハードウェア ループ テストを実行する。

10. E1 コントローラ カードを交換する。

11. 「E1 エラー イベントのトラブルシューティング」セクションに進む。

トランスミッタがリモート アラームを送信（赤）：

赤アラームが表示されるのは、CSU で E1 回線でのフレーミング パターンの同期ができない場合です。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。一致していない場合は、コントローラのフレーミング フォーマットを回線に一致させるように変更します。

2. リモート エンドで設定を確認し、これがポート設定と一致するか確認します。

3. 外部ループバック ケーブルをポートに挿入します。ループバック プラグを製作するには、この章で前述されているセクション「ループバック プラグの製作」を参照してください。

4. 何らかのアラームがあるかどうかをチェックする。アラームが何も表示されていない場合、ローカルのハードウェアはおそらく良好な状態です。その場合、次の手順を実行します。

   1. ケーブル配線を調べます。詳細は、セクション「E1 レシーバでシグナル消失があるか。」を参照してください。

   2. 問題が続くようであれば、サービス プロバイダーに問い合わせてください。

5. E1 回線を別のポートに接続します。そのポートを回線の設定に合せて設定します。これで問題が解消した場合は、一方のポートに問題があります。

   1. 元のポートに E1 回線を再接続します。

   2. 「E1 エラー イベントのトラブルシューティング」セクションに進む。

      問題が解決しない場合は、次の手順を実行します。

6. セクション「ハードウェア ループバック プラグ テストの実行」での説明に従って、ハードウェア ループ テストを実行する。

7. E1 コントローラ カードを交換する。

8. 「E1 エラー イベントのトラブルシューティング」セクションに進む。

9. お客様のサービス プロバイダーにお問い合せください。

E1 エラー イベントのトラブルシューティング

show controller e1 EXEC コマンドでは、問題のトラブルシューティングに利用できるエラー メッセージが表示されます。以降、いくつかのエラー メッセージとそのエラーの修復方法を説明します。

エラー カウンタが増加しているかどうかを確認するには、繰り返し show controller e1 コマンドを実行します。現在の間隔でのカウンタの値を記録します。フレーミングと回線コーディングの設定については、お客様のサービス プロバイダーにお問い合せください。

Slip Secs カウンタが増加中：

E1 回線でスリップがある場合、クロッキングの問題が示されています。E1 プロバイダー（電話会社）から、宅内装置（CPE）を同期させるクロッキングが供給されます。

1. クロック ソースがネットワークから導出されていることを確認する。これは、「Clock Source is Line Primary」を探すことにより確認できます。

   注：アクセスサーバに複数のE1が存在する場合、プライマリになれるのは1つだけで、他のE1はプライマリからクロックを取得します。これに該当する場合は、プライマリ クロックに指定された E1 回線が適切に設定されていることを確認してください。

2. コントローラ コンフィギュレーション モードで E1 クロック ソースを適切に設定する。

   maui-nas-03(config-controlle)#clock source line primary
   

Framing Loss Seconds カウンタが増加中：

Framing Loss Seconds カウンタが増加している場合は、次の手順に従ってください。

1. ポートに設定されたフレーミング フォーマットが、回線のフレーミング フォーマットと一致していることを確認する。これは、show controller e1 の出力で Framing is {CRC4|no CRC4} を探すことによりチェックできます。

2. フレーミングフォーマットを変更するには、framing {CRC4 | no CRC4}}コマンドを発行します。

   maui-nas-03(config-controlle)#framing crc4
   

Line Code Violations が増加中：

Line Code Violations が増加している場合は、次の手順に従ってください。

1. ポートに設定された回線コーディングが、回線のフレーミング フォーマットと一致していることを確認する。これは、show controller e1 の出力で Line Code is {AMI/HDB3} を探すことによりチェックできます。

2. 回線コーディングを変更するには、linecode {ami | hdb3}コマンドを発行します。

   maui-nas-03(config-controlle)#linecode ami
   

ISDN スイッチ タイプと PRI グループが正しく設定されていることの検証

show running-config コマンドを使用して、ISDN スイッチ タイプと PRI グループのタイムスロットが適切に設定されていることを確認します。適切な値については、お客様のサービス プロバイダーにお問い合せください。

ISDN スイッチ タイプと PRI グループの変更方法

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-net5
maui-nas-03(config)#controller e1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-31

シグナリング チャネルの検証

エラー カウンタ類が増加していないのに問題が残っている場合は、シグナリング チャネルがアップになっていて、適切に設定されていることを確認します。

1. show interface serial x:15 コマンドを実行する。この x にはインターフェイス番号を指定します。

2. インターフェイスがアップになっているかどうかを確認する。インターフェイスがアップしていない場合は、no shutdown コマンドを使用してインターフェイスをアップします。

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

3. カプセル化が PPP であることを確認する。インターフェイスで PPP が使用されていない場合は、インターフェイス コンフィギュレーション モードで encapsulation ppp コマンドを使用して、これを修正します。

   maui-nas-03(config-if)#encapsulation ppp
   

4. ループバックが設定されているかどうかを確認する。ループバックはテストの目的にだけ設定します。no loopback コマンドを使用してループバックを削除します。

   maui-nas-03(config-if)#no loopback
   

5. ルータの電源をオフ/オンします。

6. 問題が解消されない場合は、お客様のサービス プロバイダーあるいは Cisco の TAC にお問い合せください。

PRI のトラブルシューティング

PRI のトラブルシューティングを行う際には、両端で E1 が問題なく稼働しているかどうかをチェックする必要があります。上記のように、レイヤ 1 の問題が解決されたら、レイヤ 2 とレイヤ 3 の問題を検討します。

show isdn status コマンドを使用するトラブルシューティング

すべての ISDN インターフェイスのスナップショットを表示するには、show isdn status コマンドを使用します。これにより、レイヤ 1、2、3 のステータスが表示されます。

1. レイヤ 1 がアクティブであることを確認する。

   レイヤ 1 のステータスは、E1 がダウンしていない限り、常に ACTIVE と表示されているはずです。

   show isdn status でレイヤ 1 が DEACTIVATED と表示される場合、E1 回線の物理的な接続に問題があります。セクション「E1 コントローラが管理上ダウンになっているか。」を参照してください。

   E1 が管理上ダウンにはなっていないことも確認してください。E1 コントローラをアップにするには、no shutdown コマンドを使用します。

2. レイヤ 2 の状態が MULTIPLE_FRAME_ESTABLISHED であることをチェックする。

望ましいレイヤ 2 の状態は Multiple_Frame_Established で、これは ISDN スイッチとエンド デバイス間のスタートアップ プロトコルが確率されており、レイヤ 2 フレームの交換が行われていることを示しています。

レイヤ 2 が Multiple_Frame_Established ではない場合、show controller e1 EXEC コマンドを使用して、問題を診断します。この章の「show controller e1 コマンドを使用するトラブルシューティング」セクションと「E1 エラー イベントのトラブルシューティング」セクションを参照してください。

show isdn status は現在のステータスのスナップショットなので、Mulitple_Frame_Established が表示されているにもかかわらず、レイヤ 2 の状態がアップとダウンに頻繁に切り替わる場合があります。レイヤ 2 が安定した状態であることを確認するには、debug isdn q921 コマンドを使用します。

debug q921 コマンドの使用

debug isdn q921コマンドは、Dチャネル上のルータで行われているデータリンク層（レイヤ2）アクセス手順を表示します。

必要に応じて、logging console コマンドか terminal monitor コマンドを使用して、debug メッセージが表示されるように設定されていることを確認します。

注：実稼働環境では、コンソールロギングが無効になっていることを確認してください。show logging コマンドを入力します。ロギングがイネーブルになっている場合、コンソール ポートがログ メッセージで過負荷状態になるとアクセス サーバが断続的にフリーズする可能性があります。no logging console コマンドを入力します。

注：debug isdn q921がオンで、デバッグ出力を受信しない場合は、コールを発信するか、コントローラをリセットしてデバッグ出力を取得します。

1. レイヤ 2 が安定していることを確認する。debug 出力で、サービスの状態がアップとダウンに頻繁に切り替わっていないことを示すメッセージを探す必要があります。次のタイプの debug 出力が表示されている場合、回線は安定していません。

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:15, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:15, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:15, TEI 0 
   changed to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller E1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:15, changed state to up
   
   

   レイヤ 2 が安定しているようには見えない場合、この章で前述されている「E1 エラー イベントのトラブルシューティング」を参照してください。

2. 送信（TX）側と受信（RX）側の両方で SAPI メッセージだけが表示されていることを確認する。

   Mar 20 10:06:52.505: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:15: TX ->  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. レイヤ 2 で初期化が再試行されていることを示す SABME メッセージが表示されていないことを確認する。通常、これが表示されるのは、ポール要求（RRp）を転送していて、スイッチからの応答（RRf）を受信していないか、あるいはその逆である場合です。次に SABME メッセージの例を示します。SABME メッセージに対して ISDN スイッチからの応答があるはずです（UA フレームの受信）。

   Mar 20 10:06:21.702: ISDN Se0:15: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:15: TX ->  SABMEp sapi = 0  tei = 0

   SABME メッセージが表示されている場合は、show running-config コマンドを使用して、ISDN スイッチ タイプと PRI グループのタイムスロットが適切に設定されていることを確認します。適切な値については、お客様のサービス プロバイダーにお問い合せください。

   ISDN スイッチ タイプと PRI グループの変更方法

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-net5
   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-31
   

4. show interfaces serial x:15 コマンドを使用して、D チャネルがアップになっていることを確認する。

   D チャネルがアップになっていない場合は、no shutdown コマンドを使用してアップにします。

   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

5. カプセル化が PPP であるかどうかを確認する。そうでない場合は、encapsulation ppp コマンドを使用してカプセル化を設定します。

   maui-nas-03(config-if)#encapsulation ppp
   

6. インターフェイスがループバック モードになっているかどうかを確認する。通常の運用では、インターフェイスはループバック モードではない必要があります。

   maui-nas-03(config-if)#no loopback
   

7. ルータの電源をオフ/オンします。

8. 問題が解消されない場合は、お客様のサービス プロバイダーあるいは Cisco の TAC にお問い合せください。

関連情報

• テクニカルサポート - Cisco Systems

更新履歴