オプティカル : 同期光ネットワーク(SONET)

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

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2009 年 1 月 14 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

このドキュメントは、Packet over SONET(POS)ルータ インターフェイスの回線プロトコルのステータスが「down」になった場合のトラブルシューティング方法について説明しています。

また、回線プロトコルがダウンしていることを特定する際に役立つ情報のほか、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か。 コマンドレファレンスはまたはそれ」。降ろされたかどうか管理者によって行プロトコルを処理するソフトウェアプロセス行を使用可能と見なすかどうか行 Protocol フィールド ステータスが「示すことを示します(すなわち、キープアライブは正常です)

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

  • Encapsulation(カプセル化):インターフェイスに設定されているカプセル化方式。

  • loopback(ループバック):ループバックが設定されているかどうかを示す。

  • keepalive(キープアライブ):キープアライブが設定されているかどうかを示す。

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

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

/image/gif/paws/16152/gspos_a0.gif

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 コマンドの出力には、多数のインターネットワーキング イベントのプロトコル ステータスとネットワーク アクティビティに関連する診断情報が記載されています。

注意 注意: デバッギングアウトプット 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 をプロトコルとして定義しています。leavingcisco.com RFC 1662 に規定されるとおり、POS インターフェイスはレイヤ 2 でのデータのカプセル化に、HDLC に類似したフレーミングの PPP をサポートしています。leavingcisco.com HDLC に類似したフレーミングの PPP のフレーム形式を次の図に示します。

gspos_a2.gif

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 キープアライブ パケットのフォーマットを示しています。

/image/gif/paws/16152/16152a.gif

これらの 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 時間が経過するまで、受信側から接続を解除することは禁じられています。

/image/gif/paws/16152/16152a.gif

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 プロトコル フィールド値のリスト」を参照するには、ここをクリックしてください。leavingcisco.com

ルータ 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

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

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

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

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

/image/gif/paws/16152/16152b.gif

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 インターフェイスの回線プロトコルはダウンします。 次のトポロジ例について考えてみましょう。

/image/gif/paws/16152/16152c.gif

次のログ出力例は、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登録ユーザ専用)を参照)。

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

  1. aps protect コマンドを設定します。

  2. aps force 1 コマンドを発行します。

  3. 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登録ユーザ専用)で解決されています。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。


関連情報


Document ID: 16152