トラブルシューティング：POS インターフェイスでの「Line Protocol is Down」問題

ダウンロードオプション

PDF (331.9 KB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (106.1 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (156.4 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2006 年 5 月 19 日

Document ID:16152

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

show interface pos コマンドの解釈

POS プロトコルスタックの概要

debug コマンドの使用

HDLC での回線プロトコルのダウン

PPP での回線プロトコルのダウン

リンク設定

キープアライブによるリンク保守

リンク終了

トラブルシューティング手順の例

トラブルシューティングに関する注意

ループバックテスト

APS での回線プロトコルのステータス

既知の問題

概要

このドキュメントでは、回線プロトコルのステータスが「down」である Packet over SONET（POS）ルータインターフェイスをトラブルシューティングする方法について説明します。

また、回線プロトコルがダウンしていることを特定する際に役立つ情報のほか、show コマンドと debug コマンドを使用して、ポイントツーポイントプロトコル（PPP）および High-level Data Link Control（HDLC; 高レベルデータリンク制御）のカプセル化の問題をトラブルシューティングする方法についても説明します。さらに、ドキュメント化されたラボセットアップに基づく、一般的なトラブルシューティングシナリオの概要を示しています。

show interface pos コマンドの解釈

このドキュメントの目的に従い、show interface pos の出力を次に示します。出力とコメントの強調表示された部分に注意してください。

RTR12410-2#show interface pos 6/0 
   POS6/0 is up, line protocol is down 

!--- The line protocol is down
.
     Hardware is Packet over SONET 
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 1/255 
     Encapsulation HDLC, crc 32, loopback not set 

!--- The loopback has not been set.

     Keepalive set (10 sec) 

!--- The keepalive is set as every ten seconds.

     Scramble disabled 
  Last input never, output 00:00:05, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  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 
     0 packets input, 0 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
              0 parity 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     3 packets output, 1074 bytes, 0 underruns 
     0 output errors, 0 applique, 1 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     2 carrier transitions

Cisco IOS(R) コマンドリファレンスには、line protocol（回線プロトコル）フィールドのステータスについて次のように記載されています。「（line protocol フィールドは）回線プロトコルを処理するソフトウェアプロセスによって回線が使用可能（つまり、キープアライブが正常）と見なされているかどうか、または回線が管理者によってダウン状態にされているかどうかを示します。」

show interface pos の出力中には、その他にも次の重要なフィールドがあります。

Encapsulation（カプセル化）：インターフェイスに設定されているカプセル化方式。
loopback（ループバック）：ループバックが設定されているかどうかを示す。
keepalive（キープアライブ）：キープアライブが設定されているかどうかを示す。

POS プロトコルスタックの概要

次の図に、POS インターフェイスで使用されるプロトコルスタックを示します。

POS インターフェイスは、HDLC、PPP、およびフレームリレーという複数のカプセル化をサポートします。したがって Packet over SONET は、より正確には PPP over SONET または HDLC over SONET です。このドキュメントでは、フレームリレーカプセル化については説明していません。

PPP と HDLC には密接な関係があり、次のような特性を共有しています。

ヘッダーとトレーラを含むフレーミング構造を備えています。トレーラーはエラーチェックに使用されます。
受信装置のためにパケットとフレームの始まりと終わりの場所を正確に定義する、フレーム識別を備えています。HDLC および PPP では、フレーム識別は特殊なフレーム間フィルパターンまたはアイドルパターンによって表されます。そのパターンは 0x7E、つまり 0111 1110 です。
最小パケット長と最大パケット長を定義します。
IP パケットを転送します。受信装置がパケットの正確なタイプを判別できるように、到達したフレーム内部の情報からパケットのタイプを判別する方法が定められています。

ただし、密接な関係があるとはいっても PPP と HDLC は同じものではなく、回線プロトコル問題のトラブルシューティングには異なる debug コマンドを使用します。

debug コマンドの使用

各種の debug 特権 EXEC コマンドの出力には、多数のインターネットワーキングイベントのプロトコルステータスとネットワークアクティビティに関連する診断情報が記載されています。

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

POS インターフェイスに関する問題のトラブルシューティングには、次の debug コマンドが役立ちます。各コマンドの機能と出力の詳細は、Cisco デバッグコマンドリファレンスマニュアルに記載されています。

debug serial interface：HDLC キープアライブパケットが増加しているかどうかを確認します。HDLC キープアライブパケットが増加していない場合は、インターフェイスカードまたはネットワークに、タイミングに関する問題があります。
debug ppp negotiation：PPP の開始時に送信される PPP パケットを表示します。PPP の開始時には PPP オプションがネゴシエートされます。
debug ppp packet：送受信されている PPP パケットを表示します。このコマンドは低レベルのパケットダンプを表示します。
debug ppp errors：PPP 接続のネゴシエーションと操作に関連する PPP エラー（不正フレームや誤形式フレームなど）が表示されます。

詳細は、『シリアル回線問題のトラブルシューティング』を参照してください。

HDLC での回線プロトコルのダウン

HDLC は、POS ルータインターフェイスのデフォルトのカプセル化タイプです。HDLC は国際標準ですが、ベンダー実装によって、フィールド、ヘッダー、トレーラのサイズや形式は異なります。SONET を定義している Telecordia GR-253 仕様に、HDLC-over-SONET マッピングに関する説明があります（3-59 ページ、3.4.2.3 項、Issue 3 を参照）。ここでは HDLC フレームが SONET フレームとバイト整合されるように規定されているほか、自己同期スクランブラ、Cyclic Redundancy Check（CRC; 巡回冗長検査）が定義され、到着する HDLC フレームの可変性に対応するために HDLC フラグパターンを使用してフレーム間を埋める方法が規定されています。

show interface pos コマンドを使用して、HDLC カプセル化によって回線とプロトコルがダウンしていることが示された場合は、debug serial interface コマンドを使用して、回線障害を接続障害の原因として切り離すことができます。HDLC はキープアライブを使用しており、デバッグ出力にある 3 つのカウンタの値を報告します。

myseq：ローカルルータがリモートルータにキープアライブパケットを送信するたびに値が 1 ずつ増えます。
mineseen：mineseen カウンタの値は、リモートルータがローカルルータから受信したことを確認応答した最後の myseq シーケンス番号を示します。リモートルータはこの値を自身の yourseen カウンタに格納し、キープアライブパケットに含めてローカルルータに送信します。
yourseen：ローカルルータがリモートルータからのキープアライブパケットによって受信した myseq シーケンス番号の値を示します。

デバッグ出力の後続の各行で mineseq、yourseen、および myseen フィールドのキープアライブ値が増えていない場合は、接続の一方の端に問題があります。myseq フィールドと mineseen フィールドの値の差が 3 よりも大きい場合は、回線がダウンし、インターフェイスがリセットされています。

次の debug serial interface コマンドの出力例は、HDLC 接続の両端でキープアライブが正しく受信されていることを示しています。

hswan-12008-2a#debug serial interface 
Serial network interface debugging is on 
hswan-12008-2a# 
Oct 31 11:47:16: POS4/0: HDLC myseq 180, mineseen 0*, yourseen 1, line up 
Oct 31 11:47:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- Local router sees a remote keepalive with a sequence number of 1. 

Oct 31 11:47:26: POS4/0: HDLC myseq 181, mineseen 181*, yourseen 2, line up 
Oct 31 11:47:36: POS4/0: HDLC myseq 182, mineseen 182*, yourseen 3, line up 
Oct 31 11:47:46: POS4/0: HDLC myseq 183, mineseen 183*, yourseen 4, line up 
Oct 31 11:47:56: POS4/0: HDLC myseq 184, mineseen 184*, yourseen 5, line up 
Oct 31 11:48:06: POS4/0: HDLC myseq 185, mineseen 185*, yourseen 6, line up 

!--- Keepalives are sent every 10 seconds by default. !--- Both sides report incrementing sequence numbers.

次の debug serial interface コマンドの出力例は、HDLC 接続でリモートインターフェイスが停止しており、ローカルインターフェイスで 3 つ以上のキープアライブの受信に失敗したことを示しています。

hswan-12008-2a# 
Oct 31 11:49:46: POS4/0: HDLC myseq 195, mineseen 192, yourseen 13, line down 
Oct 31 11:49:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to down 

!--- The local router has failed to receive three keepalives and !--- brings down the line protocol. Note the difference between !--- "myseq 195" and "mineseen 192". 

Oct 31 11:49:56: POS4/0: HDLC myseq 196, mineseen 192, yourseen 13, line down 
Oct 31 11:50:06: POS4/0: HDLC myseq 197, mineseen 192, yourseen 13, line down 
Oct 31 11:50:16: POS4/0: HDLC myseq 198, mineseen 192, yourseen 13, line down 
Oct 31 11:50:26: POS4/0: HDLC myseq 199, mineseen 192, yourseen 13, line down 
Oct 31 11:50:36: POS4/0: HDLC myseq 200, mineseen 0*, yourseen 1, line up 
Oct 31 11:50:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- After you execute the no shut command on the remote router, !--- the local router receives a keepalive again and brings up !--- the line protocol. 

Oct 31 11:50:46: POS4/0: HDLC myseq 201, mineseen 201*, yourseen 2, line up 
Oct 31 11:50:56: POS4/0: HDLC myseq 202, mineseen 202*, yourseen 3, line up 
Oct 31 11:51:06: POS4/0: HDLC myseq 203, mineseen 203*, yourseen 4, line up 
Oct 31 11:51:16: POS4/0: HDLC myseq 204, mineseen 204*, yourseen 5, line up 
Oct 31 11:51:26: POS4/0: HDLC myseq 205, mineseen 205*, yourseen 6, line up 
Oct 31 11:51:36: POS4/0: HDLC myseq 206, mineseen 206*, yourseen 7, line up 

!--- After the shut/no shut, the remote router re-initialized its !--- sequence number.

PPP での回線プロトコルのダウン

RFC 1661 では、PPP をプロトコルとして定義しています。 POSインターフェイスは、RFC 1662で規定されているハイレベルデータリンク制御(HDLC)に類似したフレーミングでのPPPをサポートして、レイヤ2でのデータカプセル化を実現します。HDLCに類似したフレーミングでのPPPののフレーム形式は、次です。

RFC 2615 では、SONET または SDH リンク上での PPP カプセル化の使用が規定されています。PPP はポイントツーポイントリンクでの使用を目的に設計されたもので、SONET または SDH リンクに適しています。SONET または SDH リンクはリングトポロジであってもポイントツーポイント回線として提供されます。

ポイントツーポイントリンクを起動すると、PPP は状態遷移図に表されるような、いくつかの異なるフェーズを通過します。Carrier Detection（CD; キャリア検出）やネットワーク管理者設定などの外部イベントによって物理層が使用可能な状態であることが示されると、PPP はリンク確立フェーズに進みます。このフェーズに移行すると、Link Control Protocol（LCP; リンクコントロールプロトコル）に対して UP イベントが生成され、これによっていくつかの機能が提供されます。そのうちの 1 つが、リンクが正常に機能しているか、またはダウンしているかを判断する機能です。ポイントツーポイントリンクで通信を確立するためには、まず PPP リンクの両端がそれぞれ個別に LCP パケットを送信し、データリンクを設定およびテストする必要があります。

次に、PPP は Network Control Protocol（NCP; ネットワークコントロールプロトコル）パケットを送信し、1 つ以上のネットワーク層プロトコルを選択して設定します。選択されたネットワーク層プロトコルが個別に設定された後、各ネットワーク層プロトコルのデータグラムをリンク上に送信することが可能になります。

次の表に、LCP パケットの 3 つのクラスの一覧を示します。

LCP パケットクラス	LCP パケットタイプ	目的
リンク設定	Configure-Request、Configure-Ack、Configure-Nak、Configure-Reject	リンクの確立と設定に使用します。
リンク終了	Terminate-Request、Terminate-Ack	リンクの終了に使用します。
リンク保守	Code-Reject、Protocol-Reject、Echo-Request、Echo-Reply、Discard-Request	リンクの管理とデバッグに使用します。

リンク設定

LCP は、Configure パケットの交換によって接続を確立するときに使用します。Configure-Ack パケットが送信および受信されると、この交換は完了し、LCP Opened 状態になります。

次の出力例は POS インターフェイスの LCP リンク設定段階をキャプチャしたものです。

4d01h: PO3/1 LCP: State is Open 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 LCP_UP 
(0x639FCAD8) id 0 (0s.) queued 1/1/2 
4d01h: PO3/1 PPP: Phase is UP 
4d01h: PO3/1 IPCP: O CONFREQ [Closed] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 
4d01h: PO3/1 IPCP: I CONFREQ [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: O CONFACK [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: I CONFACK [ACKsent] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 IPCP: State is Open 
4d01h: PO3/1 IPCP: Install route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to up

注：PPP カプセル化が設定された POS インターフェイスは絶えず PPP セッションを確立しようとします。そのため、問題がまだ解決されていないときや、ファイバが取りはずされていても回線プロトコルが周期的に短時間アップする状況が起こります。

キープアライブによるリンク保守

LCP Echo-Request および Echo-Reply パケットは、リンクの両方向のレイヤ 2 ループバックメカニズムを提供します。LCP Opened 状態で Echo-Request が受信されると、必ず Echo-Reply が送信されます。

次の図は RFC 1661 に掲載されているもので、PPP キープアライブパケットのフォーマットを示しています。

これらの LCP パケットには次の主要フィールドがあります。

Code：Echo-Request の場合は 9、Echo-Reply の場合は 10。
Identifier：送信時は、Data フィールドの内容が変わった場合、および前の要求に対して有効な応答が受信された場合に必ず Identifier フィールドが変更されます。再送の場合は Identifier が変わらないことがあります。受信時は、Echo-Request の Identifier フィールドが Echo-Reply パケットの Identifier フィールドにコピーされます。
Magic-Number：Magic-Number フィールドは長さが 4 オクテットで、ループバック状態にあるリンクを検出する際に役立ちます。Magic-Number 設定オプションが正常にネゴシエートされるまで、Magic-Number は常にゼロとして伝送されます。詳細は、RFC 1661 の Magic-Number 設定オプションを参照してください。
Data：Data フィールドは長さがゼロ以上のオクテットで、送信側が使用する未解釈のデータが含まれます。データにはバイナリ値を含めることができます。フィールドの終わりは Length によって示されます。

次に、キープアライブが有効な場合の debug ppp negotiation の例を示します。

4d01h: PO3/1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x1A45933B 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 16 
4d01h: PO3/1 LCP: I ECHOREP [Open] id 1 len 12 magic 0x00000002 
4d01h: PO3/1 LCP: Received id 1, sent id 1, line up

リンク終了

PPP はいかなる時点でもリンクを終了できます。リンクを終了するトリガには、キャリアの消失、認証の失敗、リンクの品質障害、アイドルタイマーのタイムアウト、管理上の理由によるリンクのクローズなどがあります。

LCP は Terminate パケットを使用してリンクをクローズします。Terminate-Request の送信側は、Terminate-Ack の受信後、または Restart カウンタのタイムアウト後に接続を解除します。Terminate-Request の受信側はピアが接続解除するのを待ちます。Terminate-Ack の送信後少なくとも 1 回の Restart 時間が経過するまで、受信側から接続を解除することは禁じられています。

Terminate LCP パケットには次の主要フィールドがあります。

Code：Terminate-Request の場合は 5、Terminate-Ack の場合は 6。
Identifier：送信時は、Data フィールドの内容が変わった場合、および前の要求に対して有効な応答が受信された場合に必ず Identifier フィールドが変更されます。再送の場合は Identifier が変わらないことがあります。受信時は、Terminate-Request の Identifier フィールドが Terminate-Ack パケットの Identifier フィールドにコピーされます。

Data フィールドは長さがゼロ以上のオクテットで、送信側が使用する未解釈のデータが含まれます。データにはバイナリ値を含めることができます。フィールドの終わりは Length によって示されます。

次に、TERMREQ パケットを受信したときの debug ppp negotiation の出力例を示します。

4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 8 
4d01h: PO3/1 LCP: I TERMREQ [Open] id 4 len 4 
4d01h: PO3/1 LCP: O TERMACK [Open] id 4 len 4 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 18 
4d01h: PO3/1 IPCP: State is Closed 
4d01h: PO3/1 PPP: Phase is TERMINATING 
4d01h: PO3/1 LCP: I CONFREQ [TERMsent] id 1 len 14 
4d01h: PO3/1 LCP:    MRU 1500 (0x010405DC) 
4d01h: PO3/1 LCP:    MagicNumber 0x00000002 (0x050600000002) 
4d01h: PO3/1 LCP: Dropping packet, state is TERMsent 

!--- While in the TERMsent state, PPP should drop all other packets. 

4d01h: PO3/1 IPCP: Remove route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to down

トラブルシューティング手順の例

このセクションでは、PPP カプセル化を使用した POS リンクにおけるサンプルのトラブルシューティングシナリオについて説明しています。このシナリオでは、次の設定を使用しています。

ルータ A の設定
interface POS1/0 ip address 1.1.1.6 255.255.255.0 no ip directed-broadcast encapsulation ppp crc 16 clock source internal

ルータ B の設定
interface POS2/0 ip address 1.1.1.5 255.255.255.0 no ip directed-broadcast encapsulation ppp crc 16

注：これらのデバッグは、バックツーバックのラボセットアップで2台のルータでキャプチャされたものです。そのため、一方のルータではクロッキングを internal に設定し、もう一方のルータではデフォルトのクロッキング設定（回線）を使用しています。

debug ppp negotiation

次の出力は、LCPのリンク確立フェーズでdebug ppp negotiationを使用してキャプチャされたパケット交換を示しています。

ルータAのデバッグ出力
Router A Debug Output (1) !--- The router sends an outgoing confreq. hswan-12008-2a# Nov 7 08:27:00: %LINK-3-UPDOWN: Interface POS1/0, changed state to up Nov 7 08:27:00: PO1/0 PPP: Treating connection as a dedicated line Nov 7 08:27:00: PO1/0 PPP: Phase is ESTABLISHING, Active Open Nov 7 08:27:00: PO1/0 LCP: O CONFREQ [Closed] id 7 len 14 Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D)
(4) !--- Router A receives an incoming confreq from router B. Nov 7 08:27:00: PO1/0 LCP: I CONFREQ [REQsent] id 45 len 14 Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2)
(5) !--- Router A responds with a confack and receives a !--- confack from Router B. The LCP state is open. Nov 7 08:27:00: PO1/0 LCP: O CONFACK [REQsent] id 45 len 14 Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2) Nov 7 08:27:00: PO1/0 LCP: I CONFACK [ACKsent] id 7 len 14 Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) Nov 7 08:27:00: PO1/0 LCP: State is Open *Nov 7 08:27:00: PO1/0 PPP: Phase is UP
(7) !--- Router A begins the IPCP stage and negotiates an IP address. !--- In this setup, the peer router already has an address and !--- sends it in a confreq. If the peer router accepts the address, !--- it responds with a confack. Nov 7 08:27:00: PO1/0 IPCP: O CONFREQ [Closed] id 7 len 10 Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 08:27:00: PO1/0 CDPCP: O CONFREQ [Closed] id 7 len 4 Nov 7 08:27:00: PO1/0 IPCP: I CONFREQ [REQsent] id 9 len 10 Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 08:27:00: PO1/0 IPCP: O CONFACK [REQsent] id 9 len 10 Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 08:27:00: PO1/0 CDPCP: I CONFREQ [REQsent] id 9 len 4 Nov 7 08:27:00: PO1/0 CDPCP: O CONFACK [REQsent] id 9 len 4 Nov 7 08:27:00: PO1/0 IPCP: I CONFACK [ACKsent] id 7 len 10 Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 08:27:00: PO1/0 IPCP: State is Open Nov 7 08:27:00: PO1/0 CDPCP: I CONFACK [ACKsent] id 7 len 4 Nov 7 08:27:00: PO1/0 CDPCP: State is Open Nov 7 08:27:00: PO1/0 IPCP: Install route to 1.1.1.5 Nov 7 08:27:01: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, changed state to up

ルータ B のデバッグ出力
(2) !--- Router B receives an incoming confrq from Router A. hswan-12008-2b# Nov 7 10:29:19.043: PO2/0 LCP: I CONFREQ [Open] id 7 len 14 Nov 7 10:29:19.043: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.043: PO2/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) Nov 7 10:29:19.043: PO2/0 IPCP: State is Closed Nov 7 10:29:19.043: PO2/0 CDPCP: State is Closed Nov 7 10:29:19.043: PO2/0 PPP: Phase is TERMINATING Nov 7 10:29:19.043: PO2/0 PPP: Phase is ESTABLISHING
(3) !--- Router B sends its own LCP confreq. Nov 7 10:29:19.043: PO2/0 LCP: O CONFREQ [Open] id 45 len 14 Nov 7 10:29:19.043: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.043: PO2/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2)
(6) !--- Router B responds with a confack and receives a confack from Router A. The LCP state is open. Nov 7 10:29:19.043: PO2/0 LCP: O CONFACK [Open] id 7 len 14 Nov 7 10:29:19.043: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.043: PO2/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) Nov 7 10:29:19.043: PO2/0 IPCP: Remove route to 1.1.1.6 Nov 7 10:29:19.047: PO2/0 LCP: I CONFACK [ACKsent] id 45 len 14 Nov 7 10:29:19.047: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.047: PO2/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2) Nov 7 10:29:19.047: PO2/0 LCP: State is Open Nov 7 10:29:19.047: PO2/0 PPP: Phase is UP
(8) !--- Router B also begins the IPCP stage and negotiates an IP address. Nov 7 10:29:19.047: PO2/0 IPCP: O CONFREQ [Closed] id 9 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 10:29:19.047: PO2/0 CDPCP: O CONFREQ [Closed] id 9 len 4 Nov 7 10:29:19.047: PO2/0 IPCP: I CONFREQ [REQsent] id 7 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 10:29:19.047: PO2/0 IPCP: O CONFACK [REQsent] id 7 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 10:29:19.047: PO2/0 CDPCP: I CONFREQ [REQsent] id 7 len 4 Nov 7 10:29:19.047: PO2/0 CDPCP: O CONFACK [REQsent] id 7 len 4 Nov 7 10:29:19.047: PO2/0 IPCP: I CONFACK [ACKsent] id 9 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 10:29:19.047: PO2/0 IPCP: State is Open Nov 7 10:29:19.047: PO2/0 CDPCP: I CONFACK [ACKsent] id 9 len 4 Nov 7 10:29:19.047: PO2/0 CDPCP: State is Open Nov 7 10:29:19.047: PO2/0 IPCP: Install route to 1.1.1.6 *Nov 7 10:29:19.048: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, changed state to up

debug ppp packet

次の出力は、リンクの確立中に debug ppp packet でキャプチャされたパケット交換を示したものです。このデバッグは、PPP パケットにあるプロトコルフィールドの値をキャプチャします。RFC 1661 は、Protocol フィールドを 1 または 2 オクテットに定義しています。このフィールドの値によって、パケットの Information フィールドでカプセル化されたデータグラムが識別されます。

「0***」から「3***」までの Protocol フィールドの値は特定のパケットのネットワークレイヤプロトコルを識別し、「8***」から「b***」までの範囲は、関連する Network Control Protocol（NCP）に属するパケット（存在する場合）を識別します。「c***」から「f***」までの Protocol フィールドの値は、パケットをリンク層の制御プロトコル（LCP など）として識別します。他にも、さまざまなベンダー固有の値があります。完全な「PPP プロトコルフィールド値のリスト」を参照するには、ここをクリックしてください。

ルータAのデバッグ出力
(1) Nov 7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 !--- 0xC021 identifies LCP.* Nov 7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x269933F4 (0x0506269933F4) Nov 7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) Nov 7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x269933F4 (0x0506269933F4) Nov 7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up Nov 7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 Nov 7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 !--- 0x8021 identifies IPCP, PPP internet protcol control protocol.* Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 !--- 0x8207 identifies Cisco discovery protocol control. Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) Nov 7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 Nov 7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 Nov 7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 Nov 7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 Nov 7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 Nov 7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 !--- 0x0207 identifies Cisco Discovery Protocol (CDP). Nov 7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 Nov 7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 *Nov 7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, changed state to up
(3) !--- ECHOREQand ECHOREP packets for PPP keepalives use packet type values !--- of 0xC021. Nov 7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 Nov 7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 Nov 7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C Nov 7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C Nov 7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 Nov 7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 Nov 7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 Nov 7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up

ルータAのデバッグ出力

(1) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 

!--- 0xC021 identifies LCP. 

*Nov  7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 
*Nov  7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 

!--- 0x8021 identifies IPCP, PPP internet protcol control protocol. 
 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 

!--- 0x8207 identifies Cisco discovery protocol control.
  
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 

!--- 0x0207 identifies Cisco Discovery Protocol (CDP). 
 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
POS1/0, changed state to up

(3) 

!--- ECHOREQand ECHOREP packets for PPP keepalives use packet type values !--- of 0xC021.
 
*Nov  7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 
*Nov  7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up

ルータ B のデバッグ出力
(2) Nov 7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 Nov 7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 Nov 7 12:22:16.947: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 Nov 7 12:22:16.947: PO2/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) Nov 7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 Nov 7 12:22:16.947: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 12:22:16.947: PO2/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) Nov 7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 Nov 7 12:22:16.947: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 12:22:16.947: PO2/0 LCP: MagicNumber 0x269933F4 (0x0506269933F4) Nov 7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 Nov 7 12:22:16.947: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 Nov 7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 Nov 7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 Nov 7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 Nov 7 12:22:16.951: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 Nov 7 12:22:16.951: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 Nov 7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 Nov 7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 Nov 7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 Nov 7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 Nov 7 12:22:16.951: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 Nov 7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, changed state to up
(4) !--- ECHOREQ and ECHOREP packets for PPP keepalives use packet type !--- values of 0xC021. Nov 7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 Nov 7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 Nov 7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 Nov 7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 Nov 7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 Nov 7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C Nov 7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up Nov 7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16

ルータ B のデバッグ出力

(2) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
Nov  7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 
Nov  7 12:22:16.947: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 
Nov  7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up

(4) 

!--- ECHOREQ and ECHOREP packets for PPP keepalives use packet type !--- values of 0xC021. 

Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
Nov  7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 
Nov  7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
Nov  7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up
Nov  7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16

トラブルシューティングに関する注意

PPPまたはHDLCカプセル化を使用するPOSインターフェイスは、リンク障害を警告する2つのメカニズムをサポートしています。レイヤ2キープアライブとSONETレイヤのアラームキープアライブは、固有の SONET アラーム構造よりも、問題の報告に時間がかかります。ただし、レイヤ2キープアライブは、SONETレベルのアラームのように、フレーマからフレーマへのパスではなく、ラインカードのCPUからラインカードのCPUへのパスをチェックするため、便利です。LCP は即時にダウンするため、PPP はリンク状態の変化により速く対応します。これに対し、HDLC はキープアライブをタイムアウトする必要があります。

2 台のルータによるバックツーバックセットアップでは、ファイバの一方を引き抜くとレイヤ 1 の接続性が失われ、両方の POS インターフェイスの状態が down/down に変わります。ただし、2 つのルータ POS インターフェイスが SONET/SDH 機器で電話会社のクラウドを超えて接続されている場合、レイヤ 1 の損失情報はリモートエンドには伝搬されません。この設定では、キープアライブはリンクをダウンさせるためのメカニズムです。

次の構成について考えてみましょう。

SDHb から SDHa へのリンク上で送信ファイバを引き抜くと、次のことが起こります。

ルータ 7507a でキープアライブが受信されなくなります。
受信ファイバがまだ動作しているので、ルータ 7507b は 7507a からのキープアライブを認識します。これを確認するには、debug serial interface を使用します。

または、このテストの実行時に show controller pos コマンドを実行して、SONET アラームを表示します。ルータ 7507a にはパスアラーム表示信号（P-AIS）、7507b にはパスリモート障害表示（P-RDI）が表示されます。

ループバックテスト

show interfaces pos コマンドの出力から、シリアル回線はアップしているものの回線プロトコルがダウンしていることが判明した場合は、問題の原因を突き止めるためにループバックテストを使用します。最初にローカルループテスト、次にリモートテストを行ってください。手順については、『Cisco ルータのループバックモードについて』を参照してください。

注：ループバックを使用する場合は、カプセル化をPPPからHDLCに変更します。すべての LCP セッションと NCP セッションのネゴシエートが成功しなければ、PPP を設定したインターフェイス上の回線プロトコルはアップ状態になりません。

APS での回線プロトコルのステータス

Automatic Protection Switching（APS; 自動保護スイッチング）用に設定されている POS インターフェイスが現用チャネルではなく保護チャネルである場合、その POS インターフェイスの回線プロトコルはダウンします。次のトポロジ例について考えてみましょう。

次のログ出力例は、GSRb の POS 1/0 インターフェイス上のファイバ配線を取りはずした後でキャプチャされたものです。APS 切り替えの発生時に、両方のインターフェイス上の回線プロトコルステータスの変化に注意してください。また、Open Shortest Path First（OSPF）の隣接状態の変化にも注意してください（詳細は『APS テクノロジーに関するサポートページ』を参照してください）。

*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: SLOS 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS2/0: APS enabling channel 
*Sep  5 17:41:46: %SONET-6-APSREMSWI: POS2/0: Remote APS status now Protect 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: APS disabling channel 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, 
changed state to down 
*Sep  5 17:41:48: %LINK-3-UPDOWN: Interface POS1/0, changed state to down 
*Sep  5 17:41:48: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS1/0 
from FULL to DOWN, Neighbor Down: Interface down or detached 
*Sep  5 17:41:56: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS2/0 
from LOADING to FULL, Loading Done

PPP カプセル化が設定されている POS インターフェイスで APS を設定するのは避けてください。PPP は APS の存在を認識していません。APS の選択解除が原因でインターフェイスがアップまたはダウンした場合、PPP はインターフェイスをリセットしようとし、引き続き PPP ネゴシエーションパケットを送信します。

また、回線プロトコルの不必要なフラップを避けるために、キープアライブを無効にしてください。ほとんどの POS ルータハードウェアでは、キープアライブは自動的に無効になります。

APS 現用モードまたは保護モードにある Cisco 12000 シリーズの POS インターフェイスは、APS を無効にすると、アップ状態またはダウン状態に固定される場合があります（これはループバックを使用していても同様です）。同じスロットに別のカードを挿入したときも、この問題が起こります。この場合は、カードを新しいスロットに移すと、正しい回線プロトコルステータスに戻ります。この問題は Cisco IOS ソフトウェアリリース 12.0(19)S で解決されています（Cisco Bug ID CSCdt43759（登録ユーザ専用）を参照）。

この問題を回避するには、次の手順を実行します。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

aps protect コマンドを設定します。
aps force 1 コマンドを発行します。
no aps protect コマンドを設定します。

既知の問題

POS インターフェイスに関する回線プロトコル問題のトラブルシューティングを行う際は、次の注意点を考慮してください。

カプセル化方式を PPP から HDLC に変更すると、PA-POS インターフェイスのリセットが継続的に繰り返される場合があります。この問題は Cisco Bug ID CSCdk30893（登録ユーザ専用）で PA-POS に関して報告されており、Cisco Bug ID CSCdk18777（登録ユーザ専用）および Cisco Bug ID CSCdk13757（登録ユーザ専用）で、PPP および HDLC カプセル化をサポートする各種インターフェイスに関して解決されています。この問題は、カプセル化方式が変更されたときに PPP が完全にシャットダウンされなかった場合に発生します。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。
HDLC カプセル化とキープアライブが設定された POS インターフェイスでは、リモートエンドからのキープアライブが受信されないときに、回線プロトコルがダウンするのではなく、インターフェイスのフラップが繰り返し発生します。この問題は、Cisco Bug ID CSCdp86387（登録ユーザ専用）で解決されています。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

トラブルシューティング：POS インターフェイスでの「Line Protocol is Down」問題

ダウンロードオプション

偏向のない言語

翻訳について

内容

概要

show interface pos コマンドの解釈

POS プロトコルスタックの概要

debug コマンドの使用

HDLC での回線プロトコルのダウン

PPP での回線プロトコルのダウン

リンク設定

キープアライブによるリンク保守

リンク終了

トラブルシューティング手順の例

debug ppp negotiation

debug ppp packet

トラブルシューティングに関する注意

ループバックテスト

APS での回線プロトコルのステータス

既知の問題

関連情報

更新履歴

提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

トラブルシューティング：POS インターフェイスでの「Line Protocol is Down」問題

ダウンロード オプション

偏向のない言語

翻訳について

内容

debug ppp negotiation

debug ppp packet

更新履歴

提供

このドキュメントは役に立ちましたか?

シスコに問い合わせ

このドキュメントは次の製品に対応しています

ダウンロードオプション