撥號技術連線故障排除 — IOS DDR發起呼叫

簡介

本文提供排除不同型別撥號連線故障的方法，並不打算從頭到尾進行閱讀。此結構設計為允許讀者向前跳至感興趣的部分，每個部分都是針對特定案例的整體故障排除主題的變體。

必要條件

需求

本檔案介紹三種主要案例；開始故障排除之前，請確定正在嘗試的呼叫型別，然後轉至該部分：

• 卡林

• Cisco IOS按需撥號路由(DDR)

• 非DDR標註

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。

歷史記錄

撥號就是代表終端使用者傳送資料的公共交換電話網路(PSTN)的應用。它涉及使用者駐地裝置(CPE)裝置，該裝置向電話交換機傳送一個電話號碼，以便將其連線到該電話號碼。AS3600、AS5200、AS5300和AS5800都是路由器示例，這些路由器能夠運行主速率介面(PRI)以及數字數據機銀行。而AS2511則是與外部數據機進行通訊的路由器示例。

運營商市場已顯著增長，現在市場需要更高的數據機密度。解決這一需求的辦法是與電話公司的裝置以及數字數據機的開發進行更高程度的互操作。這是一個能夠直接數字訪問PSTN的數據機。因此，現在開發了速度更快的CPE數據機，以利用數字數據機所具有的訊號清晰度。通過PRI或基本速率介面(BRI)連線到PSTN的數字數據機可以使用V.90通訊標準以53k以上的速度傳輸資料，這證明了此想法的成功。

第一台接入伺服器是AS2509和AS2511。 AS2509可以使用外部數據機支援8個傳入連線，AS2511可以支援16個。 AS5200引入了2個PRI，可以使用數字數據機支援48個使用者，這是技術的一大飛躍。隨著AS5300支援4個PRI，然後支援8個PRI，數據機密度穩步增加。最後，引入了AS5800以滿足運營商級安裝的需要，需要處理數十個傳入的T1和數百個使用者連線。

在撥號器技術的歷史討論中，有幾個過時技術值得一提。56Kflex是Rockwell提出的較舊（V.90之前）的56k數據機標準。思科在其內部數據機上支援56Kflex標準的1.1版，但建議儘快將CPE數據機遷移到V.90。另一種過時技術是AS5100。AS5100是思科與數據機製造商的合資企業。建立AS5100是為了通過使用四數據機卡來提高數據機密度。它涉及一組AS2511卡，這些卡插入由四數據機卡共用的背板，以及一個雙T1卡。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

Cisco IOS DDR發起呼叫

來電故障排除方法從底部開始，出站連線故障排除方法則從頂部開始。

推理的一般流程如下：

1. 按需撥號路由(DDR)是否會發起呼叫？（下一個問題的答案是「是」。）

2. 如果這是非同步數據機，聊天指令碼是否發出預期的命令？

3. 電話打給PSTN了嗎？

4. 遠端是否應答呼叫？

5. 呼叫是否完成？

6. 資料是否通過鏈路傳輸？

7. 是否已建立會話？（PPP或終端）

要檢視撥號器是否嘗試呼叫其遠端目標，請使用命令debug dialer events。您可以從debug dialer packet獲取更詳細的資訊，但是debug dialer packet命令是資源密集型命令，不應在具有多個撥號器介面運行的繁忙系統上使用。

以下IP資料包的debug dialer events輸出行列出了DDR介面的名稱以及資料包的源地址和目的地址：

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

如果流量不發起撥號嘗試，最常見的原因是配置不正確（相關流量定義、撥號器介面的狀態或路由）。

發出呼叫

如果路由和相關流量過濾器正確，則應發起呼叫。這可以通過使用debug dialer events看到：

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

如果出現撥號原因，但未嘗試撥號，則通常原因是撥號對映或撥號程式配置檔案配置錯誤。

Dialer1: Can't place call, no dialer pool set

接下來，確定所使用的介質型別：

• 外部非同步數據機DDR

• 通道關聯訊號(CAS)T1/E1非同步資料機DDR

• PRI非同步數據機DDR

• BRI非同步數據機DDR

• PRI ISDN DDR

• BRI ISDN DDR

外部非同步數據機DDR

1. 要識別外部非同步數據機DDR，請使用以下命令，然後嘗試進行呼叫：

   router# debug modem
   router# debug chat line  
            
   
   

2. 對於數據機呼叫，必須執行聊天指令碼才能繼續呼叫。對於基於撥號對映的DDR，聊天指令碼由dialer map命令中的modem-script引數呼叫。如果DDR是基於撥號程式配置檔案的，這可以通過在TTY線路上配置的指令碼dialer來實現。這兩種方法都依賴於路由器的全域性配置中存在的聊天指令碼，例如：

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   在任一事件中，檢視聊天指令碼活動的命令都是debug chat。如果dialer map或dialer string命令中使用的撥號字串（即電話號碼）為5551212，則debug輸出將如下所示：

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 確保聊天指令碼根據「傳送字串」嘗試預期的呼叫（即正確的號碼）。 如果聊天指令碼沒有嘗試進行預期的呼叫，請驗證聊天指令碼的配置。在執行提示符下使用start-chat命令手動啟動聊天指令碼。

4. 正在檢視「等待超時：CONNECT」可以描述幾種不同的可能性：

   • 可能性1:本地數據機實際上沒有發出呼叫。驗證數據機是否可以通過執行對數據機的反向telnet和手動發起撥號來發出呼叫。如果遠端似乎沒有應答，請通過使用ATDT <number>指令手動呼叫本地號碼並監聽鈴聲，驗證呼叫是否由始發數據機發出。

   • 可能性2:遠端數據機未響應。使用普通POTS電話撥打遠端數據機測試此功能。嘗試以下操作：

     1. 確保被叫電話號碼正確。使用聽筒呼叫接收號碼。請務必使用數據機正在使用的同一電纜連線到牆上。如果手動呼叫能夠到達接收非同步數據機，則始發數據機可能無法正常工作。驗證數據機並根據需要進行更換。

     2. 如果手動呼叫無法接通應答非同步數據機，請更改接收數據機上的電話線並在接收數據機線路上嘗試普通電話。如果普通電話可以接收呼叫，則可能是接收數據機有問題。

     3. 如果手動呼叫仍無法接通相關線路上的常規電話，請在接收設施中嘗試另一條（已知良好）線路。如果連線正常，讓電信檢查通向接收數據機的電話線。

     4. 如果是長途呼叫，讓始發方再試一個長途號碼（確認工作正常）。如果正常工作，則接收設施或線路可能不會被設定為接收長途呼叫。如果始發線路無法到達任何其他長距離號碼，則可能未啟用長距離。嘗試為不同的長途公司使用1010代碼。

     5. 最後，嘗試來源線路中的另一個（已知正常）本地號碼。如果連線仍失敗，請電信公司檢查始發線路。

   • 可能性3:正在撥打的號碼不正確。通過手動撥號驗證號碼。如有必要，請更正配置。

   • 可能性4:數據機培訓時間過長或TIMEOUT值過低。嘗試增加chat-script命令中的TIMEOUT值。如果TIMEOUT已經是60秒或更長，則數據機與所連線的DTE之間可能存在電纜問題。培訓故障也可能表示電路問題或數據機不相容。

     要瞭解單個數據機問題的底部，請使用反向telnet轉到始發數據機的AT提示。如果可能，也轉到接收數據機的AT提示。大多數數據機將指示連線到其DTE連線的終端會話的振鈴。使用ATM1讓數據機向其揚聲器傳送聲音，以便兩端的人可以聽到線路上發生的情況。

     音樂裡有聲音嗎？如果是，請清理電路。如果非同步數據機未進行培訓，請撥打該號碼並偵聽靜態。或許還有其他因素干擾著訓練反向telnet至非同步數據機和調試。

5. 如果一切正常，並且仍無法連線CAS非同步數據機DDR，請嘗試PPP調試。使用命令：

   router# debug ppp negotiation
        router# debug ppp authentication
   

   如果聊天指令碼成功完成，則連線數據機。請參閱Internetwork Troubleshooting Guide第17章的「Troubleshooting PPP」一節，瞭解連線故障排除的下一步。

CAS T1/E1非同步數據機DDR

1. 要識別CAS T1/E1非同步數據機DDR，請使用以下命令，然後嘗試進行呼叫：

   警告：  在繁忙的系統上運行調試可能會使CPU過載或控制檯緩衝區過度運行而使路由器崩潰！

   router# debug modem
   router# debug chat or debug chat line n
   
   router# debug modem csm
   router# debug cas
   

   注意：debug cas命令可在運行Cisco IOS的Cisco AS5200和AS5300平台上使用??軟體版本12.0(7)T及更高版本。在先前的IOS版本中，命令service internal必須輸入到路由器配置的主要層級，並且需要在exec提示符下輸入modem-mgmt csm debug-rbs。在Cisco AS5800上進行調試需要連線到中繼卡。(使用modem-mgmt csm no-debug-rbs關閉調試。)

2. 對於數據機呼叫，必須執行聊天指令碼才能繼續呼叫。對於基於撥號對映的DDR，聊天指令碼由dialer map命令中的modem-script引數呼叫。如果DDR是基於撥號程式配置檔案的，這可以通過在TTY線路上配置的指令碼dialer來實現。兩種使用都依賴於路由器的全域性配置中存在的聊天指令碼，例如：

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   在任一事件中，檢視聊天指令碼活動的命令都是debug chat。如果dialer map或dialer string命令中使用的撥號字串（即電話號碼）為5551212，則debug輸出將如下所示：

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 確保聊天指令碼根據「傳送字串」嘗試預期的呼叫（即正確的號碼）。 如果聊天指令碼沒有嘗試進行預期的呼叫，請驗證聊天指令碼的配置。在執行提示符下使用start-chat命令手動啟動聊天指令碼。

4. 正在檢視「等待超時：CONNECT」可以描述幾種不同的可能性：

   • 可能性1:本地數據機實際上沒有發出呼叫。驗證數據機是否可以通過反向telnet到數據機並手動發起撥號來發出呼叫。如果遠端似乎沒有應答，請透過使用命令ATDT<number>手動呼叫本地號碼並監聽鈴聲，驗證數據機正在發出呼叫。

     對於通過CAS T1或E1和整合數字數據機的出站呼叫，大部分故障排除類似於其他DDR故障排除。對於通過PRI線路的出站整合數據機呼叫也是如此。以這種方式進行呼叫所涉及的獨特功能需要在呼叫失敗時進行特殊調試。

     對於其他DDR情況，必須確保要求呼叫嘗試。為此，請使用debug dialer events。請參閱本文前面的IOS DDR。

     在發出呼叫之前，必須為呼叫分配數據機。要檢視此過程和隨後的呼叫，請使用以下debug命令：

     router# debug modem
     router# debug modem csm
     router# debug cas 
     

     注意：debug cas命令最初出現在AS5200和AS5300的IOS版本12.0(7)T中。早期版本的IOS使用系統級配置命令service internal以及exec命令modem-mgmt debug rbs:

     開啟Debug:

     router#conf t 
     Enter configuration commands, one per line.  End with CNTL/Z. 
     router(config)#service internal 
     router(config)#^Z 
     router#modem-mgmt csm ? 
       debug-rbs     enable rbs debugging 
       no-debug-rbs  disable rbs debugging 
     router#modem-mgmt csm debug-rbs 
     router# 
     neat msg at slot 0: debug-rbs is on 
     neat msg at slot 0: special debug-rbs is on 
     

     關閉Debug:

     router#modem-mgmt csm no-debug-rbs 
     neat msg at slot 0: debug-rbs is off 

     在AS5800上調試此資訊需要連線到中繼卡。以下是針對FXS-Ground-Start調配和配置的CAS T1上的正常出站呼叫示例：

     Mica Modem(1/0): Rcvd Dial String(5551111) 
     [Modem receives digits from chat script]
     
     CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_LOCK at slot 1 and port 0 
     
     CSM_PROC_OC4_DIALING: 
     CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 
     
     Mica Modem(1/0): Configure(0x1) 
     
     Mica Modem(1/0): Configure(0x2) 
     
     Mica Modem(1/0): Configure(0x5) 
     
     Mica Modem(1/0): Call Setup 
     
     neat msg at slot 0: (0/2): Tx RING_GROUND 
     
     Mica Modem(1/0): State Transition to Call Setup 
     
     neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
     [Telco switch goes OFFHOOK]
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_START_TX_TONE at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 
     
     neat msg at slot 0: (0/2): 
     Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
     
     Mica Modem(1/0): Rcvd Tone detected(2) 
     
     Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 
     
     Mica Modem(1/0): Rcvd Digits Generated 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 
     
     CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
     EVENT_CHANNEL_CONNECTED at slot 1 and port 0 
     
     CSM_PROC_OC5_WAIT_FOR_CARRIER: 
     CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 
     
     Mica Modem(1/0): Link Initiate 
     
     Mica Modem(1/0): State Transition to Connect 
     
     Mica Modem(1/0): State Transition to Link 
     
     Mica Modem(1/0): State Transition to Trainup 
     
     Mica Modem(1/0): State Transition to EC Negotiating 
     
     Mica Modem(1/0): State Transition to Steady State 
     
     Mica Modem(1/0): State Transition to Steady State Speedshifting 
     
     Mica Modem(1/0): State Transition to Steady State
     

     T1和E1與其他信令型別的調試類似。

     如果在調試中談到這一點，則表明呼叫數據機和應答數據機已經過培訓和連線，並且高層協定可以開始協商。如果數據機為出站呼叫正確分配，但連線未能到達此點，則必須檢查T1。使用show controller t1/e1命令驗證T1/E1是否正常工作。有關show controller 輸出的說明，請參閱序列線路故障排除。如果T1/E1不能正常工作，則T1/E1故障排除是必要的。

   • 可能性2:遠端數據機未響應。使用普通電話撥打遠端數據機測試此功能。嘗試以下操作：

     1. 確保被叫電話號碼正確。使用聽筒呼叫接收號碼。

     2. 確保手動呼叫能夠到達應答非同步數據機。如果手動呼叫能夠到達應答非同步數據機，則可能不會將CAS線路設定為允許出站語音呼叫。

     3. 如果手動呼叫無法接通應答非同步數據機，請更改接收數據機上的電話線並在接收數據機線路上嘗試普通電話。如果普通電話可以接收呼叫，則可能是接收數據機有問題。

     4. 如果手動呼叫仍無法接通相關線路上的常規電話，請在接收設施中嘗試另一條（已知良好）線路。如果連線，讓電信公司檢查通向接收數據機的電話線。

     5. 如果是長途呼叫，讓始發方再試一個長途號碼（確認工作正常）。如果正常工作，則接收設施或線路可能不會被設定為接收長途呼叫。如果始發(CAS)線路無法到達任何其他長距離號碼，則可能未啟用長距離。嘗試使用適用於不同長途公司的10-10個代碼。

     6. 最後，從始發CAS線路中嘗試另一個本地號碼（確認工作正常）。如果連線仍失敗，請讓電信公司檢查CAS。

   • 可能性3:正在撥打的號碼不正確。通過手動撥號驗證號碼。如有必要，請更正配置。

   • 可能性4:數據機培訓時間過長，或TIMEOUT值過低。嘗試增加chat-script命令中的TIMEOUT值。如果TIMEOUT已經是60秒或更長，則數據機與所連線的DTE之間可能存在電纜問題。培訓故障也可能表示電路問題或數據機不相容。

     要瞭解單個數據機問題的底部，請使用反向telnet轉到始發數據機的AT提示。如果可能，請使用反向telnet來獲得接收數據機的AT提示。使用ATM1讓數據機向其揚聲器傳送聲音，以便兩端的人可以聽到線路上發生的情況。

     音樂裡有聲音嗎？如果是，請清理電路。如果非同步數據機未進行培訓，請撥打該號碼並偵聽靜態。或許還有其他因素干擾著訓練反向telnet至非同步數據機和調試。

5. 如果一切正常，並且仍無法連線CAS非同步數據機DDR，請嘗試PPP調試。如果聊天指令碼成功完成，並且PPP調試指示出現故障，請參閱《Internetwork Troubleshooting Guide》第17章中的「Troubleshooting PPP」一節。

PRI非同步資料機DDR

1. 要標識PRI非同步數據機DDR，請使用以下命令，然後嘗試進行呼叫：

   警告：  在繁忙的系統上運行調試可能會使CPU過載或控制檯緩衝區過度運行而使路由器崩潰！

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug isdn
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. 對於數據機呼叫，必須執行聊天指令碼才能繼續呼叫。對於基於撥號對映的DDR，聊天指令碼由dialer map命令中的modem-script引數呼叫。如果DDR是基於撥號程式配置檔案的，這可以通過在TTY線路上配置的指令碼dialer來實現。這兩種方法都依賴於路由器的全域性配置中存在的聊天指令碼，例如：

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

   在任一事件中，檢視聊天指令碼活動的命令都是debug chat。如果dialer map或dialer string命令中使用的撥號字串（電話號碼）為5551212，則調試輸出將如下所示：

   CHAT1: Attempting async line dialer script
   
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 確保聊天指令碼根據「傳送字串」嘗試預期的呼叫（正確號碼）。 如果聊天指令碼沒有嘗試進行預期的呼叫，請驗證聊天指令碼的配置。在執行提示符下使用start-chat命令手動啟動聊天指令碼。

4. 正在檢視「等待超時：CONNECT」可以描述幾種不同的可能性：

   • 可能性1:本地數據機實際上沒有發出呼叫。驗證數據機是否可以通過執行對數據機的反向telnet和手動發起撥號來發出呼叫。如果遠端似乎沒有應答，請透過使用命令ATDT<number>手動呼叫本地號碼並監聽鈴聲，驗證數據機正在發出呼叫。如果沒有發出呼叫，請開啟ISDN調試。首次懷疑在BRI上發生ISDN故障時，請始終檢查show isdn status的輸出。需要注意的關鍵是，第1層應處於活動狀態，第2層應處於MULTIPLE_FRAME_ESTABLISHED。有關讀取此輸出的資訊以及糾正措施的資訊，請參閱Internetwork Troubleshooting Guide Chapter 16, Interpreting Show ISDN Status。

     對於出站ISDN呼叫，debug isdn q931和debug isdn events是最好的使用工具。幸運的是，調試出站呼叫與調試傳入呼叫非常相似。正常成功的呼叫可能如下所示：

     *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
     

     請注意，CONNECT消息是成功的關鍵標誌。如果未收到CONNECT，您可能會看到DISCONNECT或RELEASE_COMP（發行完成）消息後跟原因代碼：

     *Mar 20 22:11:03.212: ISDN SE0:23: 
     RX <-RELEASE_COMP pd = 8 callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     原因值指示兩件事：

     • 4或6位元組值的第二個位元組表示從端到端呼叫路徑接收DISCONNECT或RELEASE_COMP的點。這有助於您對問題進行本地化。

     • 第三個和第四個位元組表示故障的實際原因。有關不同值的含義，請參閱表9。

   • 可能性2:遠端數據機未響應。使用普通電話撥打遠端數據機測試此功能。嘗試以下操作：

     1. 確保被叫電話號碼正確。使用聽筒呼叫接收號碼。

     2. 確保手動呼叫能夠到達應答非同步數據機。如果手動呼叫能夠到達應答非同步數據機，則BRI線路可能不能設定為允許出站語音呼叫。

     3. 如果手動呼叫無法接通應答非同步數據機，請更改接收數據機上的電話線並在接收數據機線路上嘗試普通電話。如果普通電話可以接收呼叫，則可能是接收數據機有問題。

     4. 如果手動呼叫仍無法接通相關線路上的常規電話，請在接收設施中嘗試另一條（已知良好）線路。如果連線，讓電信公司檢查通向接收數據機的電話線。

     5. 如果是長途呼叫，讓始發方再試一個長途號碼（確認工作正常）。如果正常工作，接收設施或線路可能不會被設定為接收長途呼叫。如果始發(BRI)線路無法到達任何其他長途號碼，則可能未啟用長途號碼。為不同的長途公司嘗試1010編碼。

     6. 最後，從始發BRI線路嘗試另一個（已知正常）本地號碼。如果連線仍失敗，請讓電信公司檢查BRI。

   • 可能性3:正在撥打的號碼不正確。通過手動撥號驗證號碼。如有必要，請更正配置。

   • 可能性4:數據機培訓時間過長或TIMEOUT值過低。嘗試在chat-script命令中增加TIMEOUT值。如果TIMEOUT已經是60秒或更長，則數據機與其連線的DTE之間可能存在電纜問題。培訓故障也可能表示電路問題或數據機不相容。

     要瞭解單個數據機問題的底部，請使用反向telnet轉到始發數據機的AT提示。如果可能，請使用反向telnet來獲得接收數據機的AT提示。使用ATM1讓數據機向其揚聲器傳送聲音，以便兩端的人可以聽到線路上發生的情況。

     音樂裡有聲音嗎？如果是，請清理電路。如果非同步數據機未進行培訓，請撥打該號碼並偵聽靜態。或許還有其他因素干擾著訓練反向telnet至非同步數據機和調試。

5. 如果一切正常，並且仍無法連線BRI非同步數據機DDR，請嘗試PPP調試。如果聊天指令碼成功完成，並且PPP調試指示出現故障，請參閱《Internetwork Troubleshooting Guide》第17章中的「Troubleshooting PPP」一節。

BRI非同步數據機DDR

此功能僅適用於使用Cisco IOS軟體版本12.0(3)T或更新版本的Cisco 3640平台。它需要BRI網路模組的更高硬體版本。這對WAN介面卡(WIC)不起作用。

1. 使用show modem命令確保國家/地區代碼正確。使用以下命令，然後嘗試進行呼叫：

   警告：  在繁忙的系統上運行調試可能會使CPU過載或控制檯緩衝區過度運行而使路由器崩潰！

   router# debug modem
   router# debug chat
   router# debug modem csm
   router# debug isdn q931
   router# debug bri
   router# debug ppp negotiate
   router# debug ppp authenticate
   

2. 對於數據機呼叫，必須執行聊天指令碼才能繼續呼叫。對於基於撥號對映的DDR，聊天指令碼由dialer map命令中的modem-script引數呼叫。如果DDR是基於撥號程式配置檔案的，這可以通過在TTY線路上配置的指令碼dialer來實現。兩種使用都依賴於路由器的全域性配置中存在的聊天指令碼，例如：

   chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
   

   在任一事件中，檢視聊天指令碼活動的命令都是debug chat。如果dialer map或dialer string命令中使用的撥號字串（電話號碼）為5551212，則調試輸出將如下所示：

   CHAT1: Attempting async line dialer script
   
   CHAT1: Dialing using Modem script: callout & System script: none
   CHAT1: process started
   CHAT1: Asserting DTR
   CHAT1: Chat script callout started
   CHAT1: Sending string: AT
   CHAT1: Expecting string: OK
   CHAT1: Completed match for expect: OK
   CHAT1: Sending string: atdt5551212
   CHAT1: Expecting string: CONNECT
   CHAT1: Completed match for expect: CONNECT
   CHAT1: Chat script callout finished, status = Success
   

3. 確保聊天指令碼根據「傳送字串」嘗試預期的呼叫（正確號碼）。 如果聊天指令碼沒有嘗試進行預期的呼叫，請驗證聊天指令碼的配置。在執行提示符下使用start-chat命令手動啟動聊天指令碼。

4. 正在檢視「等待超時：CONNECT」可以描述幾種不同的可能性：

   • 可能性1:本地數據機實際上沒有發出呼叫。驗證數據機是否可以通過執行對數據機的反向telnet和手動發起撥號來發出呼叫。如果遠端似乎沒有應答，請透過使用命令ATDT<number>手動呼叫本地號碼並監聽鈴聲，驗證數據機正在發出呼叫。如果沒有發出呼叫，請開啟ISDN調試。首次懷疑在BRI上發生ISDN故障時，請始終檢查show isdn status的輸出。需要注意的關鍵是，第1層應處於活動狀態，第2層應處於MULTIPLE_FRAME_ESTABLISHED狀態。有關讀取此輸出和糾正措施的資訊，請參閱Internetwork Troubleshooting Guide第16章「Interpreting Show ISDN Status」。

     對於出站ISDN呼叫，debug isdn q931和debug isdn events是最好的使用工具。幸運的是，調試出站呼叫與調試傳入呼叫非常相似。正常成功的呼叫可能如下所示：

     *Mar 20 21:07:45.025: ISDN BR0: Event: 
     Call to 5553759 at 64 Kb/s
     
     *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
     callref = 0x2C
     *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
     *Mar 20 21:07:45.041:         Channel ID i = 0x83
     *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
     *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.145:         Channel ID i = 0x89
     *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
             Channel ID i = 0x0101
     *Mar 20 21:07:45.161:   -------------------
             Channel ID i = 0x89
     *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
     callref = 0xAC
     *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
     

     請注意，CONNECT消息是成功的關鍵標誌。如果未收到CONNECT，您可能會看到DISCONNECT或RELEASE_COMP（發行完成）消息後跟原因代碼：

     *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
     callref = 0x8F
     *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
     

     原因值表示兩件事。

     • 4或6位元組值的第二個位元組表示從端到端呼叫路徑接收DISCONNECT或RELEASE_COMP的點。這有助於您對問題進行本地化。

     • 第三個和第四個位元組表示故障的實際原因。有關不同值的含義，請參見表9。

   • 可能性2:遠端數據機未響應。使用普通電話撥打遠端數據機測試此功能。嘗試以下操作：

     1. 確保被叫電話號碼正確。使用聽筒呼叫接收號碼。

     2. 確保手動呼叫能夠到達應答非同步數據機。如果手動呼叫能夠到達應答非同步數據機，則BRI線路可能不能設定為允許出站語音呼叫。

     3. 如果手動呼叫無法接通應答非同步數據機，請更改接收數據機上的電話線並在接收數據機線路上嘗試普通電話。如果普通電話可以接收呼叫，則可能是接收數據機有問題。

     4. 如果手動呼叫仍無法接通相關線路上的常規電話，請在接收設施中嘗試另一條（已知良好）線路。如果連線，讓電信公司檢查通向接收數據機的電話線。

     5. 如果是長途呼叫，讓始發方再試一個長途號碼（確認工作正常）。如果正常工作，接收設施或線路可能不會被設定為接收長途呼叫。如果始發(BRI)線路無法到達任何其他長途號碼，則可能未啟用長途號碼。嘗試為不同的長途公司提供10-10個代碼。

     6. 最後，從始發BRI線路嘗試另一個（已知正常）本地號碼。如果連線仍失敗，請讓電信公司檢查BRI。

   • 可能性3:正在撥打的號碼不正確。通過手動撥號驗證號碼。如有必要，請更正配置。

   • 可能性4:數據機培訓時間過長，或TIMEOUT值過低。嘗試在chat-script命令中增加TIMEOUT值。如果TIMEOUT已經是60秒或更長，則數據機與其連線的DTE之間可能存在電纜問題。培訓故障也可能表示電路問題或數據機不相容。

     要瞭解單個數據機問題的底部，請使用反向telnet轉到始發數據機的AT提示。如果可能，請使用反向telnet來獲得接收數據機的AT提示。使用ATM1讓數據機向其揚聲器傳送聲音，以便兩端的人可以聽到線路上發生的情況。

     音樂裡有聲音嗎？如果是，請清理電路。如果非同步數據機未進行培訓，請撥打該號碼並偵聽靜態。或許還有其他因素干擾著訓練反向telnet至非同步數據機和調試。

5. 如果一切正常，並且仍無法連線BRI非同步數據機DDR，請嘗試PPP調試。如果聊天指令碼成功完成，並且PPP調試指示出現故障，請參閱《Internetwork Troubleshooting Guide》第17章中的「Troubleshooting PPP」一節。

PRI ISDN DDR

1. 在首次懷疑某個PRI上存在ISDN故障時，請始終檢查show isdn status的輸出。需要注意的關鍵是，第1層應處於活動狀態，第2層應處於MULTIPLE_FRAME_ESTABLISHED狀態。有關讀取此輸出和糾正措施的資訊，請參閱Internetwork Troubleshooting Guide第16章「Interpreting Show ISDN Status」。

   對於出站ISDN呼叫，debug isdn q931和debug isdn events是最好的使用工具。幸運的是，調試出站呼叫與調試傳入呼叫非常相似。正常成功的呼叫可能如下所示：

   *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
   Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
   callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
   callref = 0xAC
   *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
   

   請注意，CONNECT消息是成功的關鍵標誌。如果未收到CONNECT，您可能會看到DISCONNECT或RELEASE_COMP（發行完成）消息後跟原因代碼：

   *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   原因值表示兩件事。

   • 4或6位元組值的第二個位元組表示從端到端呼叫路徑接收DISCONNECT或RELEASE_COMP的點。這有助於您對問題進行本地化。

   • 第三個和第四個位元組表示故障的實際原因。有關不同值的含義，請參見表9。

   註：以下列印輸出指示較高協定故障：

   Cause i = 0x8090 - Normal call clearing

   PPP身份驗證失敗是一個典型原因。在假設連線失敗必然是ISDN問題之前，啟用debug ppp negotiation和debug ppp authentication。

2. 如果看到ISDN CONNECT消息並且PPP調試指示出現故障，請參閱《Internetwork Troubleshooting Guide》第17章中的「Troubleshooting PPP」一節。

BRI ISDN DDR

1. 首次懷疑在BRI上發生ISDN故障時，請始終檢查show isdn status的輸出。需要注意的關鍵是，第1層應處於活動狀態，第2層應處於MULTIPLE_FRAME_ESTABLISHED狀態。有關讀取此輸出和糾正措施的資訊，請參閱Internetwork Troubleshooting Guide第16章「Internetwork Discounting Show ISDN Status」。

   對於出站ISDN呼叫，debug isdn q931和debug isdn events是最好的使用工具。幸運的是，調試出站呼叫與調試傳入呼叫非常相似。正常成功的呼叫可能如下所示：

   *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s
   
   *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
   *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
   *Mar 20 21:07:45.041:         Channel ID i = 0x83
   *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
   *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
   *Mar 20 21:07:45.145:         Channel ID i = 0x89
   *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
           Channel ID i = 0x0101
   *Mar 20 21:07:45.161:   -------------------
           Channel ID i = 0x89
   *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
   *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
   

   請注意，CONNECT消息是成功的關鍵標誌。如果未收到CONNECT，您可能會看到DISCONNECT或RELEASE_COMP（發行完成）消息後跟原因代碼：

   *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
   callref = 0x8F
   *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
   

   原因值表示兩件事。

   • 4或6位元組值的第二個位元組表示從端到端呼叫路徑接收DISCONNECT或RELEASE_COMP的點。這有助於您對問題進行本地化。

   • 第三個和第四個位元組表示故障的實際原因。有關不同值的含義，請參見表9。

     註：以下列印輸出指示較高協定故障：

     Cause i = 0x8090 - Normal call clearing

     PPP身份驗證失敗是一個典型原因。在假設連線失敗必然是ISDN問題之前，啟用debug ppp negotiation和debug ppp authentication。

2. 如果看到ISDN CONNECT消息並且PPP調試指示出現故障，請參閱《Internetwork Troubleshooting Guide》第17章中的「Troubleshooting PPP」一節。

相關資訊

• Cisco IOS撥號服務快速配置指南
• Cisco IOS撥號服務配置指南：網路服務
• Cisco IOS撥號服務配置指南：終端服務
• Cisco IOS撥號服務命令參考
• 撥號案例研究概述
• 存取技術頁面
• 技術支援與文件 - Cisco Systems