ダイヤルとアクセス : 総合デジタル通信網(ISDN)、個別線信号方式(CAS)

BRI 回線をテストするループバック コールの実行

2010 年 11 月 29 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 9 月 9 日) | フィードバック


目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
背景説明
ISDN レイヤ 3 ループバック コールの実行
データ ループバック コールの実行
      ルータの設定
      データ ループバック コールの開始
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

このドキュメントでは、Basic Rate Interface(BRI; 基本速度インターフェイス)回線をテストするためのループバックを実行する手順を説明しています。



前提条件

要件

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

この手順を実行する前に、電話会社から次の情報を入手してください。

  • 設定するスイッチのタイプ。

  • Service Profile Identifier(SPID; サービス プロファイル識別子)と Local Directory Number(LDN; 市内電話番号)。SPID と LDN は、アメリカ合衆国内で必要です。

  • 両方の B チャネルが 1 つのハント グループ内にあるかどうか。両方とも同じハント グループ内にある場合、1 つの番号をダイヤルするだけでどちらの B チャネルにも到達できます。

  • BRI 回線上のコールが 56k と 64k のどちらで行われるのか。



使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco IOS® ソフトウェア リリース 12.0(3)T 以降。これは、isdn call コマンドが導入されたのが Cisco IOS ソフトウェア リリース 12.0(3)T であるためです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。



表記法

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



背景説明

ループバック コールでは、ルータはそれ自体の Basic Rate Interface(BRI; 基本速度インターフェイス)の ISDN 番号をダイヤルします。コールは電話会社のクラウドに進み、そこで電話会社によって第 2 B チャネルに切り替えられます。これにより、このコールは第 2 チャネルへの着信コールとしてルータに到達します。したがって、ルータは ISDN コールの送信と受信を両方とも行います。

ループバック コールは、ルータが ISDN コールを開始できるか、および終端できるかをテストします。ループバック コールが成功すれば、電話会社のクラウドまでの ISDN 回線は機能していると考えられます。

BRI 回線のテストを実行できるループバック コールには、次の 2 つのタイプがあります。

  • ISDN レイヤ 3 ループバック コール:isdn call interface コマンドを使用できる対象。このループバック コールでは、ルータとローカル ISDN スイッチの間で ISDN レイヤ 1、2、3 が機能しているかどうかを確認できます。このテストは D チャネルを使用しており、B チャネル経由でのデータのテストは行いません。これには、ルータのコンフィギュレーションへの変更は含まれません。このテストを最初に実行します。成功した場合、データ ループバック コール テストを実行してください。

  • データ ループバック コール:B チャネルが実際にデータを通すことができるかどうかをテストします。これには、ルータのコンフィギュレーションの変更が含まれます。

これらの手順は、ローカル スイッチへの BRI 回線が機能しているかどうかをテストできるだけです。これはエンドツーエンドの ISDN 接続のテストや、Dial-on-Demand Routing(DDR; ダイヤルオンデマンド ルーティング)に関連する問題のテストは行いません。BRI のトラブルシューティングの詳細は、次のドキュメントを参照してください。



ISDN レイヤ 3 ループバック コールの実行

このセクションでは、正常な ISDN レイヤ 3 ループバック コールの例を示します。isdn call コマンドは、対象のトラフィックとルートなど、DDR 要件なしで発信 ISDN コールをイネーブルにします。このコマンドはレイヤ 3 までの ISDN 回線をテストする目的にだけ使用できます。トラフィックを通す目的や、通常の DDR 設定の代用としては使用できません。このコマンドは、ISDN 回線、特にレイヤ 3 が機能しているかどうかを確認します。

図 1 では、コール フローといくつかの debug isdn q931 メッセージを示します。

図 1:コール フローと、いくつかの debug isdn q931 メッセージ

bri_loopback_call1.GIF

maui-soho-04#isdn call interface bri 0 5551111

!--- ルータは 5551111(ルータ自体の BRI の ISDN 番号)をダイヤルします。
!--- BRI 回線に各 B チャネル用の 2 つの異なる電話番号がある場合、
!--- 2 番目の B チャネルに属する番号を使用します。
!--- このコマンドを使用して、速度 56 オプションの 56k でコールを行うことができます。
.
maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup メッセージが電話会社スイッチに送信(TX)されました。

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding メッセージが電話会社スイッチから受信(RX)されました。
!--- スイッチは現在コールを処理しています。

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- Setup メッセージがスイッチから受信(RX)されました。このメッセージは 
!--- 着信コールに対するものです。ルータはすでに(発信コールの)Setup メッセージを送信しており、
!--- ここで同じコールの SETUP メッセージを受信します。

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- 着信コールの Call Proceeding メッセージを送信(TX)しました。

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

!  --- 着信コールの Connect メッセージを送信(TX)しました。

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

!  --- 着信コールの Connect Acknowledgment を受信(RX)しました。

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

!  --- 発信コールの Connect メッセージを受信(RX)しました。

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5551111 

!  ---  これでコールが接続され、ループバック コールは成功しました。

  • ループバック コール中、ルータは異なる B チャネル上で着信側ルータと発信側ルータの両方の役割を果たします。debug isdn q931 の出力を解釈する際は、これらの「デュアルロール」の経過をたどることが重要です。たとえば、ルータは SETUP メッセージを送信し(TX -> SETUP)、また SETUP メッセージの受信もします(RX <- SETUP)。送信された SETUP メッセージは発信コールに対応していて、受信された SETUP メッセージは着信コールに対応している必要があります。

  • 上記の例では、第 1 B チャネルの番号がダイヤルされています。電話会社では第 1 B チャネルが話中であると認識し(コールを発信しているため)、コールを第 2 B チャネルに切り替えるため、接続が正常に完了します。しかし、電話会社のスイッチ設定が誤っていると、ループバック コールが失敗することがあります。これは、スイッチが第 1 チャネル(コールを発信しているために話中である)にコールを割り当てようとするために発生する可能性があります。ハント グループに両方の B チャネルを追加するように電話会社に依頼してください。ただし、このテストの目的として、isdn call interface コマンドに第 2 B チャネル番号を指定してこの問題を回避することができます。

  • 別のルータでループバック コールを実行します。

  • ループバック コールが成功しているのに、リモート エンドへのコールが引き続き失敗する場合、次のセクションで説明するように、データ ループバック コールを行って B チャネル データ整合性をテストできます。

問題のトラブルシューティング方法についての詳細は、次のドキュメントを参照してください。



データ ループバック コールの実行

データ ループバック コールは、B チャネルが適切にデータを転送できるかどうかをテストするときに役立ちます。多くの状況で、debug ppp negotiation が何度も失敗することがあります。このテストは、B チャネルのデータ整合性をチェックするときに使用できます。

注:このテストは、前述のテストとは異なり、ルータへの設定の変更が含まれます。

データ ループバック コールでは、ルータに 2 つのダイヤラ インターフェイスを設定します。ダイヤラ インターフェイスは、BRI 回線で正常にダイヤルし、着信コールを受信し、他のダイヤラ インターフェイスをバインドして、正常に接続するように、必要なアドレッシング、認証、および DDR コマンドで設定されています。

同一のルータ上の別のダイヤラ プロファイルにダイヤルするために、ダイヤラ プロファイルを作成します。



ルータの設定

ループバック コール用にルータを設定するには、次のステップを実行します。

  1. copy running-config startup-config コマンドを利用して実行コンフィギュレーションを保存します。これを行うと、テストの完了後、リブートして実行コンフィギュレーションをテスト前のバージョンに復元できます。

  2. 物理インターフェイスを設定します。

    注:このセクションでは、スイッチ タイプや SPID など、ISDN 関係の必要な情報を理解していることを前提としています。

    interface BRI0
     no ip address
     
    !--- 物理インターフェイスには IP アドレスを設定しないでください。
    !--- IP アドレスはダイヤラに設定されます。
    
     encapsulation ppp
     !--- physical interface uses PPP encapsulation
     dialer pool-member 1
     
    !--- dialer pool 1 のメンバとして BRI0 を割り当てます。
    !--- dialer pool 1 は、インターフェイス Dialer 1 と、 
    !--- インターフェイス  Dialer 2 に指定されます。
    
     isdn switch-type basic-ni
     isdn spid1 71355511110101 5551111
     isdn spid2 71355511120101 5551112
     
    !--- switch-type と SPID の設定です。
    !--- この情報については、電話会社に問い合せてください。
    
     ppp authentication chap callin   
     
    !--- 物理インターフェイスは CHAP 認証を使用します。
    !--- 認証は、着信コールを正しいダイヤラ プロファイルにバインドするために 
    !--- 物理インターフェイスで必要です。
    
    
  3. 最初のダイヤラ インターフェイスを設定します。

    interface Dialer1
     ip address 1.1.1.1 255.255.255.0
     
    !--- ダイヤラ インターフェイスに IP アドレスを割り当てます。
    !--- この例では、両方のダイヤラ用の IP アドレスは
    !---  同じサブネット内にあります。
    
     encapsulation ppp
     
    !--- ダイヤラ インターフェイスは PPP を使用しています(物理 BRI インターフェイスと同様)。
    
     dialer pool 1
    
     !--- これは Dialer pool 1 を定義します。BRI 0 はこのプールのメンバです。
    
     dialer remote-name dialer2
     
    !--- この名前は、それ自体を認証するために他のダイヤラ インターフェイスによって使用される名前と
    !--- 一致する必要があります。ダイヤラの文字列は 7135551112 です。
    !--- もう 1 つの B チャネルの電話番号です。
    !--- 接続が両方の B チャネル用に 1 つの番号だけを必要とする
    !--- (つまり、ハント グループである)場合、その番号をここで使用します。
    
     dialer-group 1
     
    !--- dialer-list 1 から対象トラフィックの定義を適用します。
    
     ppp authentication chap callin
    
     !--- 単方向の CHAP 認証を使用します。これは、このテストでは十分です。
    
     ppp chap hostname dialer1
    
     !--- 認証のために送出される CHAP ホスト名です。
    
     ppp chap password dialer1
    
     !--- 認証のために送出される CHAP パスワードです。
    
    
  4. 2 番目のダイヤラ インターフェイスを設定します。

    interface Dialer2
     ip address 1.1.1.2 255.255.255.0
    
     !--- ダイヤラ インターフェイスに IP アドレスを割り当てます。
    !--- この例では、両方のダイヤラ用の IP アドレスは同じサブネット内にあります。
    
     encapsulation ppp
     dialer pool 1
    
     !--- これは Dialer pool 1 を定義します。
    !--- BRI 0 はこのプールのメンバです。
    
     dialer remote-name dialer1
    
     !--- この名前は、それ自体を認証するために他のダイヤラ インターフェイス(dialer1)によって使用される名前と 
    !--- 一致する必要があります。ダイヤラの文字列は 7135551111 です。
    !--- もう 1 つの B チャネルの電話番号です。
    !--- 接続が両方の B チャネル用に 1 つの番号だけがある 
    !--- (つまり、ハント グループである)場合、その番号をここで使用します。
    
     dialer-group 1
    
     !--- dialer-list 1 から対象トラフィックの定義を適用します。
    
     ppp authentication chap callin
     ppp chap hostname dialer2
    
     !--- 認証のために送出される CHAP ホスト名です。
    
     ppp chap password dialer2
    
     !--- 認証のために送出される CHAP パスワードです。
    
    
  5. 認証のためにユーザ名とパスワードを設定します。

    username dialer1 password 0 dialer1
    username dialer2 password 0 dialer2
    

    ユーザ名とパスワードは、各ダイヤラ インターフェイスで ppp chap hostname コマンドと ppp chap password コマンドによって設定したものと同じです。

  6. わかりやすくするため、スタティック ルートを設定します。

    ip route 1.1.1.1 255.255.255.255 Dialer1
    
    !--- 1.1.1.1 のルートが dialer1 をポイントしていることに注目します。
    
    ip route 1.1.1.2 255.255.255.255 Dialer2
    
    !--- 1.1.1.2 のルートが dialer2 をポイントしていることに注目します。
    !--- ルートはどのダイヤラ インターフェイスがダイヤルアウトに使用されるのかを判断するために 
    !--- 使用されます。
    
    

    ヒント:独立したサブネットでインターフェイス Dialer 1(ステップ 3)とインターフェイス Dialer 2(ステップ 4)用の IP アドレスを設定する場合、スタティック ルートは必要ありません。

  7. 対象のトラフィック定義を設定します。

    dialer-list 1 protocol ip permit

    注:dialer-list の番号は、ダイヤラ インターフェイスの下で dialer-group に設定されたものと同じにする必要があります。この例では、dialer-list 1 を設定します。

  8. テストが完了したら、テストの前に使用していた元の設定に戻すためにルータをリロードします(設定は保存しないでください)。



データ ループバック コールの開始

ここで、データ ループバック コールを開始し、PPP ネゴシエーションの正常な完了を確認します。正常な PPP ネゴシエーションは、B チャネルが適切にデータを通せることを示します。

図 2:データ ループバック コールの開始

bri_loopback_call2.GIF

次のデバッグをアクティブ化します。

  • debug dialer

  • debug isdn q931

  • debug ppp negotiation

  • debug ppp authentication(オプション)

注:ループバック コールが実行中のときに、ルータは異なる B チャネル上で着信側ルータと発信側ルータの両方の役割を果たします。debug isdn q931 コマンドと debug ppp negotiation コマンドの出力を解釈する際は、これらの「デュアルロール」の経過をたどることが重要です。たとえば、ルータは SETUP メッセージを送信し(TX -> SETUP)、また SETUP メッセージの受信もします(RX <- SETUP)。送信された SETUP メッセージは発信コールに対応していて、受信された SETUP メッセージは着信コールに対応している必要があります。

次に示すのは、連続した ISDN コールのデバッグです。

router#show debug
Dial on demand:
  Dial on demand events debugging is on
PPP:
  PPP protocol negotiation debugging is on
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 1
  1 -

router#ping 1.1.1.1

!--- 前述のステップ 6 に示されているスタティック ルート エントリのため、
!--- コールは dialer 1 から行われます。


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

03:40:41: BR0 DDR: rotor dialout [priority]
03:40:41: BR0 DDR: Dialing cause ip (s=1.1.1.1, d=1.1.1.1)
03:40:41: BR0 DDR: Attempting to dial 7135551112
03:40:41: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x08

!--- 発信 SETUP メッセージ。

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x83
03:40:41:         Keypad Facility i = '7135551112'
03:40:41: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x88
03:40:41:         Channel ID i = 0x89
03:40:41: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x2A

!--- もう 1 つの B チャネルの着信 SETUP メッセージ。

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x8A
03:40:41:         Signal i = 0x40 - Alerting on - pattern 0
03:40:41:         Called Party Number i = 0xC1, '5551112', Plan:ISDN,
  Type:Subscriber(local)
03:40:41:         Locking Shift to Codeset 5
03:40:41:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
03:40:42: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s

!--- コールが 2 番目の B チャネル(BRI0:2)に着信することに注目します。
!--- そのため、発信コールは BRI0:1 で行われている必要があります。

03:40:42: ISDN BR0: Event: Accepting the call id 0xB
03:40:42: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up.
03:40:42: BR0:2 PPP: Treating connection as a callin
03:40:42: BR0:2 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load]
03:40:42: BR0:2 LCP: State is Listen

!--- PPP LCP ネゴシエーションが始まります。

03:40:42: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x2A
03:40:42:         Channel ID i = 0x8A
03:40:42:         Signal i = 0x4F - Alerting off
03:40:42: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x88
03:40:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:40:42: BR0:1: interface must be fifo queue, force fifo
03:40:42: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
03:40:42: BR0:1 PPP: Treating connection as a callout
03:40:42: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:40:42: BR0:1 PPP: No remote authentication for call-out

!--- 単方向の認証(PPP 認証 CHAP callin で設定)。

03:40:42: BR0:1 LCP: O CONFREQ [Closed] id 11 len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x08
03:40:42: BR0:2 LCP: I CONFREQ [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:2 LCP: O CONFREQ [Listen] id 11 Len 15
03:40:42: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:2 LCP: O CONFACK [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: I CONFREQ [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: O CONFACK [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: I CONFACK [ACKsent] id 11 Len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: State is Open
03:40:42: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
03:40:43: BR0:2 LCP: I CONFACK [ACKsent] id 11 Len 15
03:40:43: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:43: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:43: BR0:2 LCP: State is Open
03:40:43: BR0:2 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]

!--- 認証の開始。

03:40:43: BR0:2 CHAP: O CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: I CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: Using alternate hostname dialer1

!--- Dialer 1 の下で  PPP CHAP hostname で指定された代替ホスト名 
!--- を使用します。

03:40:43: BR0:1 CHAP: Username router not found
03:40:43: BR0:1 CHAP: Using default password
03:40:43: BR0:1 CHAP: O RESPONSE id 7 Len 28 from "dialer1"

!--- B チャネル 1 に送出された発信 CHAP 応答。

03:40:43: BR0:2 CHAP: I RESPONSE id 7 Len 28 from "dialer1"

!--- B チャネル 2 で確認される着信 CHAP 応答。

03:40:43: BR0:2 CHAP: O SUCCESS id 7 Len 4

!--- 認証が成功しました。

03:40:43: BR0:2: interface must be fifo queue, force FIFO
03:40:43: %DIALER-6-BIND: Interface BR0:2 bound to profile Di2

!--- (Dialer 1 からの)コールはインターフェイス Dialer 2 にバインドされます。 
!--- これは、dialer remote-name dialer1 コマンドがインターフェイス dialer 2 
!--- の下に設定されているためです。dialer remote-name コマンドが省略される、または 
!--- 正しくない場合は、バインディングは失敗します。

03:40:43: BR0:2 PPP: Phase is UP [0 sess, 0 load]

!--- IPCP ネゴシエーションが開始されます。

03:40:43: BR0:2 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 CHAP: I SUCCESS id 7 Len 4
03:40:43: BR0:1 PPP: Phase is UP [0 sess, 1 load]
03:40:43: BR0:1 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:1 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:2 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 IPCP: State is Open

!--- B チャネル 2 の IPCP はオープンになっています。

03:40:43: BR0:1 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 IPCP: State is Open

!--- B チャネル 1 の IPCP はオープンになっています。

03:40:43: BR0:2 DDR: dialer protocol up
03:40:43: BR0:1 DDR: dialer protocol up
03:40:43: Di2 IPCP: Install route to 1.1.1.1
03:40:43: Di1 IPCP: Install route to 1.1.1.2
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, 
changed state to up
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, 
changed state to up

! -- 両方の B チャネルが動作しています。

...
Success rate is 0 percent (0/5)
router#

注:ping は、ルーティングに関連する問題のために失敗する可能性があります。このことは予想できます。正常な PPP ネゴシエーションは、B チャネルがリンク上でデータを適切に通すことができるかどうかの本当のテストです。コールが失敗した場合、回線のトラブルシューティング方法の詳細について、電話会社に問い合わせてください。




関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 22802