ISDN BRI トラブルシューティング フローチャート』を参照してください。
内容
概要
この文書は、ISDN Basic Rate Interface（BRI; 基本速度インターフェイス）によるダイヤルアップ アクセスに関するトラブルシューティングの手引きです。以下に示すフローチャートと出力例では、ダイヤラ プロファイルを使用して相手側との ISDN BRI 接続をセットアップしています。ただし、レガシー Dial-on-Demand Routing（DDR;ダイヤルオンデマンド ルーティング）を使用して他のルータ（ブランチ オフィスなど）に接続している場合でも、同じトラブルシューティングの手順を利用できます。
注：ISDN に関する問題を解決するために、シスコ サポート コミュニティも使用できます。
ISDN と DDR の入門的な情報は、Cisco Learning Connection の音声トレーニングを参照してください。
フローチャート
リンクをクリックすると、各項目の詳細にジャンプします。このフローチャートに戻るには、ブラウザの ｛戻る｝ ボタンを使用してください。
トラブルシューティング：トラブルシューティング：ログイン方法とデバッグのキャプチャ方法
ルータには、PC のシリアル ポートに接続されたコンソール ケーブルを使用して接続するか、または Telnet を使用して接続します。
コンソールを通じてルータに接続する場合は、『コンソール接続用ターミナル エミュレータの正しい設定』を参照してください。ルータがすでにイーサネットで Telnet を使用してルータに接続する場合は、単に Telnet クライアントを使用してルータのイーサネット IP アドレスに接続するだけです。
コンソール接続と Telnet 接続のいずれの場合でも、セッション中に受信された出力の履歴を保持できるクライアントを使用することをお勧めします。これは、特定のメッセージを探すために、デバッグ出力を戻って確認することがあるからです。
デバッグ出力とログ メッセージをミリ秒単位で表示させるように設定します。プロンプトが表示されたら、ルータに設定されているパスワードを入力してイネーブル モードに入ります。
router>enable Password: (enter the enable password) router# router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Telnet を使用してログインしている場合は、次のように terminal monitor と入力します。
router#terminal monitor router#
続いて debug コマンドを入力します。
router#debug isdn q931 ISDN Q931 packets debugging is on router#debug ppp negotiation PPP protocol negotiation debugging is on router#debug dialer packet Dial on demand packets debugging is on router#debug dialer Dial on demand events debugging is on router#debug ppp authentication PPP authentication debugging is on router#
次に、発信側ルータで ping を発行します。コールが成功した場合のデバッグ出力の例を次に示します。フローチャートで異なるフェーズとして示されている箇所は強調表示されています。
router#ping 194.183.201.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds: *Mar 1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) ! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1) *Mar 1 00:06:36.387: BR0 DDR: rotor dialout [priority] *Mar 1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1) *Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134 ! -- Number used to dial.
! -- This is configured using the dialer string or dialer map command
! -- If you do not see this message proceed to section
! -- Symptom: The Router Does Not Attempt to Dial *Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates
! -- that LCP negotiation has failed.
! -- If you do not see this message proceed to section
! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a
! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address
! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address
! -- (since it is not trying to assign one to the peer)
! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0
! -- It responds with the address that this router could use
! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section
! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#
トラブルシューティング：ルータはダイヤルを試行しますか?
ルータがコールを発信しようとしているかどうかを確かめるには、発信側ルータのデバッグ出力に次の行があるかどうかを探します。
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
このデバッグ出力では、ルータがダイヤルを試行している ISDN ディレクトリ番号は 8134 です。この番号は dialer string または dialer map コマンドを使用して指定されています。
症状：ルータがダイヤルを試行しない。
ルータがダイヤルを試行しない場合は、次のような可能性があります。
デバッグに何も出力されない
デバッグに何も出力されない場合、最も可能性の高い原因は、送信しようとしている IP パケットがダイヤラ インターフェイスにルーティングされていないことです。この状況が発生する一般的な原因は、次のとおりです。
- ダイヤラ インターフェイスに IP が設定されていることを確認します。これには、ダイヤラ インターフェイスに IP アドレスが設定されているか、ip unnumbered interface（この場合、interface は、ethernet x や loopback x などの up/up インターフェイス）または ip address negotiated（クライアントが NAS から IP アドレスを取得する場合）が設定されていることが必要です。 レガシー DDR を使用する場合は、物理インターフェイス（インターフェイス BRI 0 など）に IP アドレスを設定する必要があります。
- コマンド ip routing が設定されていることを確認します。show running-config コマンドを使用して設定を表示した場合に、コマンド no ip routing が表示されていてはいけません。
- ダイヤラ インターフェイスまたはネクストホップ（ダイヤラ マップを使用している場合）を指し示すスタティック ルートがあることを確認します。
次の例（ダイヤラ プロファイルの場合）は、ネクストホップとして dialer 1 を持つ 172.22.53.0/24 へのスタティック ルートです。
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
次の例（レガシーDDRの場合）は、ネクストホップが172.16.1.1の172.22.53.0/24のスタティックルートです。ネクストホップアドレスは、ダイヤルに使用されるdialer mapステートメントのIPアドレスと一致する必要があります。
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- ダイヤラ インターフェイスまたは物理インターフェイスが administratively down またはスタンバイの状態にないことを確認します。インターフェイスが up/up（spoofing）の状態にあることを確認するには、show interface dialer X または show interface bri X コマンドを使用します。
インターフェイスが administratively down の場合は、インターフェイス設定モードで no shutdown コマンドを使用します。
インターフェイスがスタンバイ状態にある場合は、ダイヤラ インターフェイスまたは BRI インターフェイスが、アップしている接続へのバックアップであることを意味します。プライマリ インターフェイスの下にある backup interface コマンドを削除するか、またはプライマリ インターフェイスのケーブルを取りはずします。
デバッグは出力されても、「Attempting to Dial」メッセージがない
このケースでは、おそらく IP パケットはインターフェイスにルーティングされていますが、なんらかの理由でルータがそのパケットを廃棄するため、コールが開始されません。コールが試行されない原因を突き止めるために、debug 出力を確認します。次に debug 出力の例と考えられる原因をいくつか示します。
例 1
*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 bytes, outgoing uninteresting (list 101).
生成されたトラフィックが対象トラフィック定義と一致していません。この例では、access-list 101 を変更します。
単純な対象トラフィック定義であれば、次のようにすべての IP トラフィックを入力として許可します。
maui-soho-01(config)#dialer-list 1 protocol ip permit
警告：すべての IP トラフィックを対象としてマークすると、特にルーティング プロトコルを使用している場合や周期的なトラフィックがある場合に、ISDN リンクが無期限にアップし続ける可能性があります。ニーズに合わせて対象トラフィック定義を調整してください。
対象トラフィックについての詳細は、ドキュメント『ダイヤルアップ テクノロジー：概要と説明』を参照してください。
例 2
*Mar 1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (no dialer-group defined).
ダイヤラ インターフェイスに dialer-group が設定されていません。次の例のように dialer-group を追加します。
interface Dialer1 dialer-group X
注：X の値は dialer-list コマンドで使用されている値と同じであることが必要です。
例 3
*Mar 1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing uninteresting (dialer-list 1 not defined).
ダイヤラ インターフェイスに dialer-group 文がありますが、参照している dialer-list が存在しません。次の例のように dialer-list を設定します。
dialer-list X protocol ip permit
注：X の値は、ダイヤラ インターフェイスの下にある dialer-group コマンドで使用されている値と同じであることが必要です。
例 4
*Mar 1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.
このケースでは、発信パケットはリンクをアップする対象トラフィックと見なされていますが、コールの発信に利用できる物理インターフェイスがありません。物理インターフェイスで dialer pool-member X が設定されていて、さらにダイヤラ インターフェイスで dialer pool X が設定されていることを確認します。例：
interface BRI0 dialer pool-member 1 ! interface Dialer1 dialer pool 1
また、BRI インターフェイスがシャットダウン状態にないことも確認します。
例 5
*Mar 1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.
このケースでは、ダイヤラ インターフェイスにダイヤラ ストリングが設定されていません。ルータはコールを発信しようとしますが、発信する ISDN ディレクトリ番号がわかりません。次のように dialer-string を定義します。
interface Dialer1 dialer string 8134
その他のトラブルシューティング情報についての詳細は、ドキュメント『debug isdn q931 コマンドを使用した ISDN BRI レイヤ 3 のトラブルシューティング』の「発信側ルータが SETUP メッセージを送信しない」セクションを参照してください。
トラブルシューティング：ISDN コールは正常に接続しますか。
ISDN コールが接続するかどうかを確認するには、デバッグ中に CONNECT_ACK および %LINK-3-UPDOWN メッセージがあるかを調べます。
*Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
このメッセージがある場合、ISDN コールは正常に接続しているため、次のステップに進むことができます。このようなメッセージがない場合は、次に示す考えられる原因を参照してください。
症状：ISDN コールが正常に接続しない。
- 次のような出力が見られる場合は、ルータと電話会社のジャックの両方で ISDN ケーブルが差し込まれていることを確認します。
*Mar 1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 21:31:18.190: BR0 DDR: rotor dialout [priority] *Mar 1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *Mar 1 21:31:18.198: BR0 DDR: Attempting to dial 8134. *Mar 1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 bytes, outgoing interesting (ip PERMIT). *Mar 1 21:31:26.226: ISDN BR0: Could not bring up interface *Mar 1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E *Mar 1 21:31:26.246: ISDN BR0: Could not bring up interface. Success rate is 0 percent (0/5)
- ISDN 回線が正常に機能していることを確認します。show isdn status コマンドを使用して、レイヤ 1 が ACTIVE、レイヤ 2 が MULTIPLE_FRAME_ESTABLISHED、および SPID（必要な場合）が有効であることをそれぞれ確認します。詳細は、ドキュメント『show isdn status コマンドを使用した BRI のトラブルシューティング』を参照してください。
ご使用のシスコデバイスのshow isdn statusコマンドの出力がある場合は、Cisco CLI Analyzerを使用して潜在的な問題と修正を表示できます。Cisco CLI Analyzerを使用するには、登録ユーザとしてログインし、JavaScriptを有効にしている必要があります。 - 設定されている ISDN ダイヤラ ストリングが正しいことを確認します。PBX 経由で接続される場合は、外線に発信する際に先頭に 0、9、またはその他のディジットを追加する必要があることがあります。
- 接続が長距離キャリアを使用する場合は、各地域の電話会社と長距離プロバイダーに問い合せて、サービスがアクティブであることを確認します。各地域の通信事業者の ISDN 回線に設定ミスがあり、ISDN の長距離発信コールが適切な長距離プロバイダー ネットワークに変換されないケースがよく見られます。また、長距離プロバイダー ネットワークが機能していることも確認します。
米国では、電話会社または長距離プロバイダーが問題を解決できない場合は、Presubscribed Interexchange Carrier（PIC）を利用できます。Local Exchange Carrier（LEC; 地域の電話会社）に対して米国の長距離キャリアを明示する 7 桁のプレフィクスを PIC コードと呼びます。 お客様はPIC コードを使用することで、コールごとに異なる長距離キャリアを利用できます。PIC コードは、ダイヤル番号の接頭番号として構成されています。ほとんどの PIC は 1010xxx の形式です。
no dialer string xxxxx または no dialer map を使用して既存の番号を削除し、続いて新しい番号を設定します。
たとえば、dialer string 10103215125551111 と設定します。
- ISDN 接続解除メッセージを探します。
Cisco IOS(R) ソフトウェアはこの接続解除メッセージ中の原因コードを解読し、明確なテキスト メッセージとして示します。このテキスト メッセージに、問題の原因につながる有用な情報が含まれている場合があります。ここで見られる可能性があるテキスト メッセージを次に示します。
- 未割り当て番号
- Incompatible destination（互換性のない宛先）- これらのメッセージはどちらも、ダイヤル番号が誤っている可能性があることを示します。
- Number busy（番号が話中）- 着信側が話中であることを示します。
- Temporary failure（一時的な障害）- 電話会社のネットワークが一時的に停止していることを示します。
特定の接続解除原因について考えられる理由を調べるには、『debug isdn q931 の接続解除原因コードの理解』を参照してください。
たとえば、次のメッセージは ISDN 番号が誤っているために接続が解除されたことを示しています。
*Mar 3 00:10:38.756: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xEB *Mar 3 00:10:38.764: Cause i = 0x84D8 - Incompatible destination
前述の『debug isdn q931 の接続解除原因コードの理解』ドキュメントを参照すれば、ISDN 以外の機器（アナログ回線など）に接続しようとしたことが原因で接続解除コードが発生したことがわかります。
次のメッセージは番号の形式が適切でないために接続が解除されたことを示しています。
Aug 13 18:23:14.734: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x86
Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)ドキュメント『debug isdn q931 の接続解除原因コードの理解』を参照すれば、リモート ISDN 番号の形式が無効であることが原因で接続解除コードが発生したことがわかります。つまり、接続が失敗したのは、（スイッチに対して）宛先アドレスが認識不可能な形式で提示されたか、または宛先アドレスが不完全だったからです。
次の例は、ISDN 番号が誤っているためにコールが拒否されたことを示しています。
*Mar 13 11:29:04.758: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0x83 *Mar 13 11:29:04.769: Cause i = 0x8295 - Call rejected
- 電話会社から Service Profile Identifier（SPID; サービス プロファイル識別子）を提供されている場合は、これらの SPID が BRI インターフェイスに設定されていることを確認します。SPID は通常、米国で NI および DMS スイッチタイプを使用している場合にだけ必要です（5ess スイッチタイプでは SPID は不要です）。
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
SPID が正しいかどうかを確認するには、show isdn status コマンドを使用します。
詳細については、ドキュメント『トラブルシューティング：ISDN BRI SPID』を参照してください。
ご使用のシスコデバイスのshow isdn statusコマンドの出力がある場合は、Cisco CLI Analyzerを使用して潜在的な問題と修正を表示できます。Cisco CLI Analyzerを使用するには、登録ユーザとしてログインし、JavaScriptを有効にしている必要があります。 - 上記の手順を実行しても問題が解決しない場合は、ドキュメント『debug isdn q931 コマンドを使用した ISDN BRI レイヤ 3 のトラブルシューティング』に従ってトラブルシューティングを進めてください。
トラブルシューティング：PPP LCP フェーズは成功しますか?
デバッグ出力に、次のようなメッセージ行があるはずです。
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
この行がある場合は、Link Control Protocol（LCP; リンク制御プロトコル）が正常にネゴシエートされたことを示します。Open 以外の状態であれば、LCP が失敗したことを示します。
症状：PPP LCP フェーズが成功しない。
考えられる原因：PPP が設定されていない。
デバッグ出力に次のような行がある場合は、PPP が開始されなかったことを示します。
*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up. *Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). *Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT) *Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)
デバッグ出力から、ルータが PPP CONFREQ メッセージをまったく送信していないことがわかります。これはおそらく、インターフェイスで PPP カプセル化が設定されていないためです。
このケースでは、ダイヤラ インターフェイスと物理インターフェイスの下に encapsulation ppp コマンドが設定されていることを確認します。次に例を示します。
interface Dialer1 encapsulation ppp or
interface BRI 0
encapsulation ppp
考えられる原因：ISDN 速度のミスマッチ。
ときどき、発信 LCP CONFREQ メッセージだけが見られ、着信 LCP メッセージが見られないことがあります。次に例を示します。
*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
この問題の考えられる原因は次のとおりです。
- リモート エンドで PPP が設定されていない。リモート エンドでコマンド encapsulation ppp を設定します。
- パケットが伝送メディアを通過していない。この状況が発生する最も一般的な原因は ISDN 速度のミスマッチです。
ISDN の観点から見ると、一方の側がおそらく 56k で接続しているのに対して、もう一方の側が 64k で接続している点に問題の本質があります。ローカルまたはリモートの回線がデフォルトの 64K 接続をサポートしない場合があります。両端を 56k で動作するように設定してみます。
ダイヤラ プロファイルの場合：
maui-soho-01(config)#interface Dialer1 maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below) maui-soho-01(config-if)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string
! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)
レガシー DDR の場合（ダイヤラ マップ）：
maui-soho-01(config)#interface bri 0 maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k
考えられる原因：2 台のルータが、使用する認証プロトコル（CHAP または PAP）について合意しない
デバッグ出力に次のような行がある場合は、ローカル ルータとリモート側が、使用する認証プロトコルについて合意しなかったことを示します。
*Mar 1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14 *Mar 1 00:07:24.055: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP *Mar 1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9 *Mar 1 00:07:24.063: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead *Mar 1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14 *Mar 1 00:07:24.091: BR0:1 LCP: AuthProto PAP (0x0304C023) *Mar 1 00:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) ! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP *Mar 1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9 *Mar 1 00:07:24.099: BR0:1 LCP: AuthProto CHAP (0x0305C22305) ! -- The router NAKs PAP and suggests CHAP for the 2nd time *Mar 1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4 *Mar 1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4 ! -- The two routers cannot agree on LCP parameters so the call is disconnected
このケースでは、次のように設定されていることを確認します。
interface Dialer1 encapsulation ppp ppp authentication chap pap callin ! -- This permits both CHAP and PAP and one-way authentication
Challenge Handshake Authentication Protocol（CHAP）または Password Authentication Protocol（PAP）の詳細については、次のドキュメントを参照してください。
- PPP CHAP 認証の理解および設定
- ppp chap hostname および ppp authentication chap callin コマンドを使用した PPP 認証
- PPP パスワード認証プロトコル（PAP）の設定とトラブルシューティング
さらに PPP トラブルシューティングを行う場合は、シスコ サポート コミュニティも使用できます。
トラブルシューティング：PPP 認証は成功しますか?
デバッグ出力に次のような行があるかどうかを確認します。
*Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP
症状：PPP 認証が失敗する
次の行が設定されていることを確認します。
interface Dialer1 ppp chap hostname XXXXX ppp chap password YYYYY ppp pap sent-username XXXXX password YYYYY
この例では、XXXXX がユーザ名、YYYYY がパスワードです。
注：ユーザ名とパスワードは、ローカル ルータとピアが使用する認証方式に対してだけ設定します。たとえば、どちらの側も PAP を使用しない場合、ppp pap sent-username コマンドは必要ありません。ただし、ピアが PAP と CHAP のどちらをサポートしているかがわからない場合は、両方とも設定します。
Cisco IOS ソフトウェア バージョンと設定によっては、パスワードは暗号化された状態で設定に表示されます。その場合、show running-configuration コマンドを実行すると、「password」の語の後に数字の 7 が続き、その後に一連の数字が続きます（次の例を参照）。
interface Dialer1 ppp chap password 7 140005
このケースでは、設定を見ても、設定されているパスワードが正しいかどうかを確認できません。パスワードが正しいことを確実にするには、設定モードに入り、パスワードをいったん削除してからもう一度設定します。パスワード障害が起こっているかどうかをデバッグによって判断するには、取得したデバッグ出力を次の出力例と比較します。
このルータがピアを認証する場合は、必ずコマンド username username password password, を設定してください。ここでの username は認証のためにピア ルータから提示される名前です。
例 1
次のようなメッセージがあれば、CHAP パスワードが無効であることを意味します。
*Mar 1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:16:54.411: BR0:1 CHAP: Username ISP not found *Mar 1 00:16:54.415: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is "MD/DES compare failed" ! -- Incoming CHAP failure. The remote router failed to authenticate this router. ! -- Check the username and password configured on both routers *Mar 1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4 *Mar 1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4
ヒント：着信 CHAP 障害（CHAP:I FAILURE で示される）は、ピアがルータを認証できなかったことを意味します。障害の正確な原因を特定するには、ピア ルータで debug ppp negotiation を使用します。
詳細は、ドキュメント『ppp chap hostname および ppp authentication chap callin コマンドを使用した PPP 認証』を参照してください。
例 2
次のようなメッセージがあれば、CHAP ユーザ名が無効であることを意味します。
*Mar 1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:18:34.839: BR0:1 CHAP: Username ISP not found *Mar 1 00:18:34.839: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw" ! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router *Mar 1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26 msg is "Authentication failure" ! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers *Mar 1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4 *Mar 1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4
ヒント：着信 CHAP 障害（CHAP:I FAILURE で示される）は、ピアがルータを認証できなかったことを意味します。障害の正確な原因を特定するには、ピア ルータで debug ppp negotiation を使用します。
詳細は、ドキュメント『ppp chap hostname および ppp authentication chap callin コマンドを使用した PPP 認証』を参照してください。
例 3
次のようなメッセージがあれば、PAP パスワードが無効であることを意味します。
*Mar 1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX" ! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in
! -- ppp pap sent-username XXXXX password YYYYY *Mar 1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical *Mar 1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4 *Mar 1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4 *Mar 1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
詳細は、ドキュメント『PPP パスワード認証プロトコル（PAP）の設定とトラブルシューティング』を参照してください。
例 4
次のようなメッセージがあれば、PAP ユーザ名が無効であることを意味します。
*Mar 1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew" ! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in
! -- ppp pap sent-username ewddew password YYYYY *Mar 1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27 msg is "Authentication failure" ! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router *Mar 1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4 *Mar 1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4 *Mar 1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING
詳細は、ドキュメント『PPP パスワード認証プロトコル（PAP）の設定とトラブルシューティング』を参照してください。
さらに PPP トラブルシューティングを行う場合は、シスコ サポート コミュニティも使用できます。
トラブルシューティング：PPP NCP（IPCP）フェーズは完了しますか?
IPCP でネゴシエートされる主な要素は、それぞれのピアのアドレスです。IPCP ネゴシエーションが始まる前にそれぞれのピアが取り得る状態は、「IPアドレスが付けられている」または「IP アドレスが付けられていない」のいずれかになります。ピアにアドレスがすでに付いている場合は、そのアドレスを CONFREQ に含めて他方のピアに送ります。他方のピアがそのアドレスを受け入れることができる場合は、CONFACK が返されます。アドレスを受け入れることができない場合は、ピアが使用すべきアドレスを含む CONFNAK が応答として返されます。
このフェーズだけは、デバッグ出力の 1 行だけを見ても正しく判断できません。IP Control Protocol（IPCP）を必ず正常にアップするには、IP アドレスが両方向でネゴシエートされていることを確認する必要があります。デバッグ出力の次の行を見てください。
*Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1(0x0306C2B7C901)
と
*Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902)
と
*Mar 1 00:06:37.015: BR0:1 IPCP: State is Open
これら 3 つの行のセットは連続していない場合があります。重要な点は、数あるオプションの中で特にアドレスがその下に表示されている発信 Configure Acknowledge（O CONFACK）があるかどうかをチェックすることです。
また、別の IP アドレスがその下に表示されている着信 Configure Acknowledge（I CONFACK）があることも必要です。
最後に、IPCP 状態がオープンしていることを示す行が必要です。この後、ルータから直接両方の IP アドレスに対して正常に ping が通ります。
症状：PPP NCP（IPCP）ネゴシエーションが成功しない。
問題：IP アドレスのネゴシエーションが失敗する
IPCP が失敗する理由の 1 つに、IP アドレスのネゴシエーションの失敗が挙げられます。たとえば、クライアント ルータにすでに別の IP アドレスが設定されているにもかかわらず、NAS がクライアントにアドレスを割り当てようとする場合があります。また、クライアントがアドレスを要求したときに、クライアント用に使用できるアドレスが NAS に 1 つもない問題もよく見られます。
発信側ルータ：
着信側ルータが発信側ルータにダイナミック IP アドレスを割り当てる場合は、ダイヤラ インターフェイスにコマンド ip address negotiated が設定されていることを確認します。
NAS プロバイダーまたは ISP から固定 IP アドレスを供給されている場合は、この IP アドレス（およびサブネット マスク）が、コマンド ip address address subnet_mask によってダイヤラ インターフェイスに設定されていることを確認します。
着信側ルータ：
接続を制御するインターフェイス（インターフェイス Dialer x など）に IP アドレスが付いており、peer default ip address address コマンドを使用してピアにアドレスを割り当てていることを確認します。
注：クライアント ルータに IP アドレスが設定されている場合は、peer default ip address コマンドを使用してアドレスを割り当てる必要はありません。
詳細については、『 ダイヤルアップ テクノロジー：Troubleshooting Techniques」
問題：着信側ルータでダイヤラ プロファイルのバインディングが失敗する
認証されるユーザ名が、ダイヤラ インターフェイスの下に設定されている dialer remote-name と一致しない場合は、着信側ルータによってコールの接続が解除されます。次に、この種のエラーに関する debug dialer の出力例を示します。
発信側ルータ：
次のデバッグは、着信側ルータでダイヤラ プロファイルがバインディングできなかったことが原因でコールの接続が解除されたことを示しています。
*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer
! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call
注：着信側でのデバッグは、ピアがコールの接続を解除したことを示している点を除き、この問題のトラブルシューティングにはあまり役立ちません。次に着信側ルータでのトラブルシューティングに移ります。
着信側ルータ：
次のデバッグは、ダイヤラ プロファイルのバインディングの問題が原因でコールが失敗したことを示しています。
*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name
! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]
ソリューション：
ダイヤラ インターフェイスで dialer pool number コマンドを設定します。プール番号は、物理インターフェイスで設定されているプール番号と一致している必要があります。
ダイヤラ インターフェイスで dialer remote-name コマンドを設定します。指定された名前は、リモート ルータから認証のために提示されるユーザ名と正確に一致する必要があります。この例では、認証されるユーザ名は maui-soho-03 です。
バインディングの問題に関するトラブルシューティングについての詳細は、ドキュメント『ダイヤラ プロファイルの設定とトラブルシューティング』を参照してください。
さらに PPP トラブルシューティングを行う場合は、シスコ サポート コミュニティも使用できます。
接続後の問題
症状：コールの接続解除が早すぎるか、またはコールの接続がまったく解除されない
コールの接続が途中で解除される場合、またはコールの接続がまったく解除されない場合は、ダイヤラのアイドル タイムアウトと対象トラフィック定義をチェックします。特定のパケットが対象かどうかを確認するには、debug dialer packet コマンドを使用します。以下に、いくつかの例を示します。
Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, outgoing uninteresting (list 101) Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes, outgoing interesting (list 101)
前述の例では、OSPF hello は access-list 101 によると非対象となりますが、2 番目のパケットは access-list 101 によると対象となります。
- ダイヤラ インターフェイス設定の dialer idle-timeout を調整します。デフォルトは 120 秒ですが、必要に応じてこの値を大きくしたり小さくしたりできます。
- （dialer-list コマンドで設定される）対象トラフィック定義を変更します。 コールの接続解除が早すぎる場合は、対象トラフィックの定義を緩和します。コールの接続がまったく解除されない場合は、対象トラフィックの定義をより限定的なものに変更します。たとえば、ルーティング プロトコル トラフィックを非対象として定義できます。次に対象トラフィック定義の例を示します。
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer
! -- interface using dialer-group 1詳細については、『 ダイヤルアップ テクノロジー：概要と説明』を参照してください。
症状：ルータが周期的に接続をダイヤルする。
状況によっては、リンクのアップを必要とする明確なユーザ トラフィックがないにもかかわらず、ルータが周期的に接続をダイヤルする症状が見られます。ISDN サービスが分単位で課金されている場合は、この症状によって請求額が高額になるおそれがあります。
この問題の最も一般的な原因は、周期的トラフィックを生成するプロセス（ルーティング プロトコル、NTP、SNMP など）が誤って対象として指定されていることです。このトラブルシューティングには、次の 2 つのステップがあります。
- リンクのダイヤルを引き起こすトラフィックを特定する。
- そのトラフィックを非対象として指定する。
リンクのダイヤルを引き起こすトラフィックを特定する。
リンクのダイヤルを引き起こすトラフィックを特定するには、debug dialer packet を有効にする必要があります。ISDN リンクがダウンしている間、ルータを監視し、周期的な対象トラフィックによってリンクのアップが試行されるのを待ちます。
ヒント：特に必要ない限り、ルータで設定されているルーティング プロトコルはすべて非対象として指定してください。
次の例は、周期的な OSPF hello が対象としてマークされていることを示しています。
*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5), 64 bytes, outgoing interesting (ip PERMIT)
上記のパケットが OSPF hello であることを見極める唯一の方法は、宛先アドレス（d=224.0.0.5）が OSPF 用に定義されているかどうかを確認することです。次の表は一般的なルーティング プロトコルで使用されるアドレスを示しています。
|
ルーティング プロトコル
|
周期的なアップデートまたは キープアライブ用の宛先アドレス |
|
RIPv1
|
255.255.255.255
|
|
RIPv2
|
224.0.0.9
|
|
EIGRP
|
224.0.0.10
|
|
OSPF
|
224.0.0.5
|
ルータによるダイヤルを引き起こすトラフィック（ルーティング プロトコルまたはその他の周期的なトラフィック）は非対象としてマークする必要があります。
周期的トラフィックを非対象として指定
（dialer-list コマンドで設定される）対象トラフィック定義を変更します。 この例では、OSPF および NTP トラフィックを非対象として定義します。次に対象トラフィック定義の例を示します。
access-list 101 remark Interesting traffic for dialer-list 1 access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.
access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping
! -- the link up indefinitely.
access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.
dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer interface
! -- using dialer-group 1
詳細については、『 ダイヤルアップ テクノロジー：概要と説明』を参照してください。
注：OSPF には、ここでも使用可能な「デマンド回線」機能があります。詳細は、ドキュメント『OSPF デマンド回線によってリンクがアップ状態になり続ける理由』を参照してください。
症状：第 2 B チャネルが接続しない。
多くの場合、ルータは 1 つの B チャネル上でだけ接続し、その間、もう 1 つの B チャネルはアイドル状態にあります。この問題のトラブルシューティングの詳細については、ドキュメント『トラブルシューティング：ISDN BRI リンクで第 2 B チャネルのコールが接続できない』を参照してください。
IP 接続性の問題
ISDN リンクはアップするのに、そのリンクをトラフィックが通過できない場合、問題はおそらくルーティングまたは NAT に関連しています。さらに詳しいトラブルシューティング情報については、シスコ サポート コミュニティを参照してください。
ISDN リンクを WAN 接続のバックアップとして使用している場合は、ドキュメント『DDR バックアップの設定とトラブルシューティング』を参照してください。
フィードバック