ISDN BRI故障排除流程圖
目錄
簡介
本檔案將幫助您排除ISDN基本速率介面(BRI)撥號存取的故障。在如下所示的流程圖和輸出示例中，我們已使用撥號程式配置檔案建立到另一個的ISDN BRI連線。但是，當使用傳統按需撥號路由(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
在調試輸出中，8134是路由器嘗試撥號的ISDN目錄號碼。此數字是使用dialer string或dialer map命令指定的。
症狀：路由器不會嘗試撥號
如果您的路由器沒有嘗試撥號，則存在幾種可能性：
完全沒有調試輸出
如果完全沒有調試輸出，這很可能是因為您傳送的IP資料包甚至沒有路由到撥號器介面。最常見的原因包括：
- 驗證撥號器介面上是否配置了IP。您應該在撥號器介面或ip unnumbered interface(其中interface是開啟/開啟介面，例如ethernet x、loopback x等)上擁有ip位址，或協商ip位址（如果使用者端將從NAS取得IP位址）。 如果使用傳統DDR，則應在物理介面（例如，介面BRI 0）上配置IP地址。
- 驗證是否已設定ip routing指令。使用show running-config命令檢視組態時，不應看到命令no ip routing。
- 驗證是否有指向撥號器介面或下一躍點的靜態路由（如果使用撥號器對映）。
以下示例（對於撥號程式配置檔案）是下一跳撥號程式1的172.22.53.0/24靜態路由：
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
以下示例（適用於傳統DDR）是下一跳為172.22.53.0/24的靜態路由172.16.1.1。下一跳地址應匹配撥號對映語句中用於撥號的ip地址：
maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
- 驗證撥號器或物理介面是否處於管理性關閉或待機狀態。使用show interface dialer X或show interface bri X命令以確保介面處於up/up狀態（欺騙）。
如果介面處於管理性關閉狀態，請在介面組態模式下使用no shutdown指令。
如果介面處於待命狀態，則撥號器或BRI介面是到開啟連線的備份。您可以在主介面下刪除backup interface命令，或從主介面拉出電纜。
存在調試輸出，但是沒有「嘗試撥號」消息
在這種情況下，可能有路由到介面的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).
撥號器介面上沒有配置任何撥號器組。新增撥號器組，如下例所示：
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 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目錄號碼。定義撥號器字串：
interface Dialer1 dialer string 8134
如需更多疑難排解資訊，請參閱使用debug isdn q931指令對ISDN BRI第3層進行疑難排解的檔案「呼叫路由器不傳送設定訊息」一節。
疑難排解: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故障排除的檔案。
如果您的Cisco裝置輸出了show isdn status命令，則可以使用Cisco CLI Analyzer顯示潛在問題和修復程式。要使用Cisco CLI Analyzer，您必須是註冊使用者，必須登入並啟用JavaScript。 - 驗證配置的ISDN撥號程式字串是否正確。請記住，當您通過PBX連線時，可能需要新增前導零、九位或其它數字才能獲得外線。
- 如果連線使用長途運營商，請聯絡您當地的電信公司和長途提供商，確認服務已啟用。通常，本地Telco的ISDN電路配置錯誤，因此出站ISDN長途呼叫不會切換到相應的長途提供商網路。您還應該驗證長途提供商網路是否正常工作。
在美國以及電信或長途提供商無法糾正問題的情況下，您可能希望使用預訂購的網際網路交換運營商(PIC)。PIC碼是七個數字的字首，用於識別美國到本地交換載波(LEC)的長途載波。 這樣，客戶就可以使用不同的長途電話進行單獨呼叫。PIC代碼被配置為被叫號碼的字首。大多數PIC的格式為1010xxx。
使用no dialer string xxxxx或no dialer map刪除現有號碼，然後配置新號碼。
例如，dialer string 1010321512555111。
- 查詢ISDN斷開連線消息。
Cisco IOS®軟體會對此結束通話訊息中的原因代碼進行解碼，並為您提供一個清晰的文字訊息，其中包含有助於判斷問題原因的資訊。您可能會在此處找到的字串包括：
- 未分配或未分配號碼
- 目的地不相容（兩者都表示所撥號碼可能不正確）
- Number busy（表示被叫方正忙）
- 臨時故障（表示Telco網路出現臨時故障）
要查詢特定斷開原因的可能原因，請參閱了解調試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
參照前面提到的結束通話原因代碼文檔，我們可以確定結束通話代碼是由試圖連線到非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)參考Understanding debug isdn q931 Disconnect Cause Codes文檔，我們可以確定斷開連線代碼是由遠端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
- 如果您的電信公司向您提供了要使用的服務配置檔案識別符號(SPID)，請確保在BRI介面上配置了這些SPID。SPID通常僅在美國使用，並與NI和DMS交換機型別一起使用（5ess交換機型別不需要SPID）。
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
您可以使用show isdn status命令驗證SPID是否正確。
如需詳細資訊，請參閱疑難排解ISDN BRI SPIDs檔案。
如果您的Cisco裝置輸出了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
如果您看到此行，表示連結控制通訊協定(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
可能的原因：兩台路由器不同意使用驗證通訊協定（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
有關質詢握手身份驗證協定(CHAP)或密碼身份驗證協定(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 ，其中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地址，要麼沒有。如果對等體已有地址，則會將CONFREQ中的該地址傳送到另一個對等體。如果該地址對於另一個對等體是可接受的，則返回CONFACK。如果地址不可接受，則回覆是包含供對等體使用的地址的CONFNAK。
這是僅看一行無法正確識別的唯一階段。若要確認IP控制通訊協定(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
這三組線可能不會立即相互跟隨。請務必檢查是否存在其下有地址的傳出Configure Acknowledge(O CONFACK)。
還必須有一個傳入的Configure Acknowledge(I CONFACK)，其下有另一個IP地址。
最後，必須有一行指出IPCP狀態為開啟。之後，您應該能夠直接從路由器成功對兩個IP地址執行ping。
症狀：PPP NCP(IPCP)交涉未成功
問題：IP地址協商失敗
IPCP可能失敗的原因之一是IP地址協商失敗。例如，NAS可能正在嘗試為客戶端分配地址，而客戶端路由器配置了不同的IP地址，或者另一個常見問題是客戶端請求地址，而NAS沒有可用於客戶端的任何地址。
在呼叫路由器上：
如果被呼叫的路由器向呼叫路由器動態分配IP地址，請確認您在撥號器介面中協商了命令ip address。
如果NAS提供商/ISP為您提供了靜態IP地址，請使用命令ip address subnet_mask驗證此IP地址（和子網掩碼）是否已在撥號器介面中配置。
在被叫路由器上：
確保控制連線的介面（例如int Dialer x）具有IP地址，並且正在使用peer default ip address 命令向對等體分配地址。
附註：如果客戶端路由器配置了IP地址，則無需使用peer default ip address 命令分配地址
問題：被叫路由器未通過撥號器配置檔案繫結
如果經過身份驗證的使用者名稱與撥號器介面下配置的dialer remote-name不匹配，則呼叫將被被叫路由器斷開。以下是此類錯誤的調試撥號器輸出示例：
在呼叫路由器上:
以下調試顯示由被叫路由器上的撥號程式配置檔案繫結錯誤引起的斷開連線；
*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)
在上方範例中，每個存取清單101的OSPF hello都不感興趣，而第二個封包每個存取清單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等）的過程可能無意中被指定為關注進程。故障排除這是一個兩步問題：
- 識別導致鏈路撥號的流量。
- 將該流量指定為無用流量。
確定導致鏈路撥號的流量。
要識別導致鏈路撥號的流量，需要啟用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的唯一方法是從為OSPF定義的目標地址(d=224.0.0.5)中獲取。下表列出了用於某些常見路由協定的地址：
|
路由協定
|
定期的目標地址 更新或Keepalive |
|
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需求電路不斷開啟鏈路文檔
症狀：第二個B通道無法連線
在許多情況下，路由器可能只連線一個B通道，而另一個B通道保持空閒。有關對此問題進行故障排除的詳細資訊，請參閱排除ISDN BRI鏈路上的第二個B通道呼叫故障文檔。
IP連線問題
如果ISDN鏈路啟動，但無法通過鏈路傳遞流量，則問題可能是路由或NAT相關問題。如需更多疑難排解資訊，請參閱思科支援社群。
如果使用ISDN鏈路作為WAN連線的備份，請參閱配置和故障排除DDR備份文檔。
意見