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

下載選項

  • PDF     (397.5 KB)
    在多種裝置上使用 Adobe Reader 檢視
  • ePub     (89.1 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
  • Mobi (Kindle)     (97.6 KB)
    在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視
已更新: 2007 年 7 月 9 日
文件 ID:14954

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

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

必要條件

需求

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

採用元件

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

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

歷史記錄

撥號就是代表終端使用者傳送資料的公共交換電話網路(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)

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

表 1：流量無法發起撥號嘗試

可能的原因 建議的操作
缺少或不正確的「相關流量」定義
  1. 使用命令show running-config，確保介面配置有dialer-group，並且有一個配置有匹配號碼的全域性級別dialer-list。
  2. 確保dialer-list命令配置為允許整個協定或允許與訪問清單匹配的流量
  3. 驗證access-list是否宣告通過鏈路的資料包有意義。一個有用的測試是使用特權執行命令debug ip packet [list number] 使用相關訪問清單的編號。然後嘗試通過鏈路ping或以其他方式傳送流量。如果相關流量過濾器定義正確，您將在調試輸出中看到資料包。如果此測試沒有調試輸出，則access-list與資料包不匹配。
介面狀態 使用命令show interfaces <interface name>確保介面處於「up/up(spoofing)」狀態。
  • 處於「備用」模式的介面
路由器上的另一個（主要）介面已配置為使用撥號器介面作為備份介面。此外，主介面未處於「down/down」狀態，這是使撥號器介面退出備用模式所必需的。此外，必須在主介面上配置備份延遲，否則永遠不執行backup interface 命令。要檢查撥號器介面是否將從「standby」變為「up/up(spoofing)」，通常需要從主介面拔下電纜。僅使用配置命令shutdown關閉主介面不會使主介面進入「down/down」狀態，而是將其置於「管理性關閉」狀態？不是一回事。此外，如果主要連線是通過幀中繼，則幀中繼配置必須在點對點串列子介面上完成，並且電話公司必須傳遞「活動」位。這種做法也稱為「端到端本地管理介面(LMI)」。
  • 介面處於「管理性關閉」狀態
已使用shutdown指令設定撥號器介面。這也是首次啟動Cisco路由器時任何介面的預設狀態。使用介面配置命令no shutdown消除此障礙。
路由不正確 發出exec命令show ip route [a.b.c.d]，其中a.b.c.d是遠端路由器撥號器介面的地址。如果在遠端路由器上使用ip unnumbered，請使用ip unnumbered命令中列出的介面地址。輸出應顯示通過撥號器介面到達遠端地址的路由。如果沒有路由，通過檢查show running-config的輸出確保已配置靜態或浮動靜態路由。如果存在通過除撥號器介面之外的介面的路由，則意味著使用DDR作為備份。檢查路由器配置，確保已配置靜態或浮動靜態路由。在這種情況下，測試路由的最可靠方法是禁用主連線，並執行show ip route [a.b.c.d]命令以驗證路由表中是否安裝了正確的路由。

注意：如果您在即時網路操作期間嘗試此操作，撥號事件可能會被觸發。這種測試最好在計畫的維護週期內完成。

發出呼叫

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

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



Async1 DDR: Attempting to dial 5551212

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

表 2：未撥打電話

可能的問題 建議的操作
撥號器對映配置錯誤 使用命令show running-config確保撥號介面至少配置一條指向遠端站點的協定地址和被叫號碼的dialer map語句。
撥號器設定不正確 使用命令show running-config確保使用dialer pool X命令配置Dialer介面，並且路由器上的撥號器介面配置有匹配的dialer pool-member X。如果沒有正確配置撥號程式設定檔，您可能會看到以下偵錯訊息： 
Dialer1: Can't place call, no dialer pool set
確保配置了撥號器字串。

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

外部非同步數據機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，請使用以下命令，然後嘗試進行呼叫：

    warning 警告：  在繁忙的系統上運行調試可能會使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，請使用以下命令，然後嘗試進行呼叫：

    warning 警告：  在繁忙的系統上運行調試可能會使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命令確保國家/地區代碼正確。使用以下命令，然後嘗試進行呼叫：

    warning 警告：  在繁忙的系統上運行調試可能會使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」一節。

相關資訊

修訂記錄

修訂 發佈日期 意見
1.0
09-Jul-2007
初始版本

這份文件是否有所幫助？

Feedback意見

讓思科協助您

本文件適用於這些產品