撥號技術：疑難排解技巧
目錄
簡介
撥號就是代表終端使用者傳送資料的公共交換電話網路(PSTN)的應用。它涉及使用者駐地裝置(CPE)裝置，該裝置向電話交換機傳送一個電話號碼，以便將其連線到該電話號碼。Cisco3600、AS5200、AS5300和AS5800都是能夠與數字數據機組一起運行PRI的路由器的示例。而AS2511則是與外部數據機進行通訊的路由器示例。
必要條件
需求
本文檔的讀者應瞭解以下內容：
運營商市場已顯著增長，現在市場需要更高的數據機密度。解決這一需求的辦法是與電話公司的裝置以及數字數據機的開發進行更高程度的互操作。這是一個能夠直接數字訪問PSTN的數據機。因此，現在開發了速度更快的CPE數據機，以利用數字數據機所具有的訊號清晰度。通過PRI或BRI連線到PSTN的數字數據機可以使用V.90通訊標準以53k以上的速度傳輸資料，這證明了此想法的成功。
第一台接入伺服器是Cisco2509和Cisco2511。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卡。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
來電故障排除
來電的故障排除從底部開始，然後向上進行。推理的一般流程如下：
-
我們看到電話到了嗎？(下一個問題的答案是「是」)
-
接收方是否應答呼叫？
-
呼叫是否完成？
-
資料是否通過鏈路？
-
是否已建立會話？（PPP或終端）
對於數據機連線，資料呼叫看起來與進入的終端會話相同，直到資料呼叫到達最後協商PPP。
對於涉及數字數據機的來電，首先確保底層ISDN或CAS正在接收呼叫。如果使用外部數據機，則可以跳過ISDN和CAS組部分。
傳入ISDN呼叫故障排除
使用命令debug isdn q931。以下是成功連線的示例輸出：
Router# debug isdn q931 RX <- SETUP pd = 8 callref = 0x06 Bearer Capability i = 0x8890 Channel ID i = 0x89 Calling Party Number i = 0x0083, `5551234' TX -> CONNECT pd = 8 callref = 0x86 RX <- CONNECT_ACK pd = 8 callref = 0x06
設定消息指示遠端終端正在啟動連線。呼叫參考號碼被保持為一對。在這種情況下，連線的傳入端的呼叫參考編號為0x06，連線的傳出端的呼叫參考編號為0x86。承載能力（通常稱為bearercap）告知路由器將傳入何種呼叫。在這種情況下，連線型別為0x8890。該值表示「ISDN Speed 64 Kb/s」。 如果基準是0x8090A2，則表示「語音/語音呼叫u-law」。
如果沒有收到設定消息，如果語音已調配，您應該通過手動呼叫來驗證正確的號碼。您還應檢查ISDN介面的狀態(請參閱使用show isdn status命令進行BRI故障排除)。 如果所有結果都正確無誤，請確定呼叫發起者正在進行正確呼叫。這可以通過聯絡電話公司來實現。呼叫發起者可以跟蹤該呼叫，以檢視其傳送位置。如果連線是長距離的，請嘗試使用1010長距離代碼的其他長距離載波。
如果來電是非同步數據機呼叫，請確保線路已設定為允許語音呼叫。
註：BRI非同步數據機呼叫是運行12.0(3)T或更高版本的3600路由器的功能。它需要BRI介面網路模組的最新硬體版本。WIC模組不支援非同步數據機呼叫。
如果呼叫到達但仍未完成，請查詢原因代碼（請參見Table 17-10）。connect-ack表示成功完成。
如果是非同步數據機呼叫，請前轉到「傳入數據機呼叫故障排除」部分。
此時，已連線ISDN呼叫，但是未發現資料通過鏈路。使用命令debug ppp negotiate檢視是否有任何PPP流量通過線路。如果您沒有看到流量，可能是速度不相符。若要判斷是否發生這種情況，請使用show running-config許可權exec命令檢視路由器配置。檢查本地和遠端路由器中的dialer map interface configuration命令條目。這些條目應類似於以下內容：
dialer map ip 131.108.2.5 speed 56 name C4000
對於撥號程式配置檔案，需要定義對映類以設定速度。請注意，預設情況下，ISDN介面嘗試在每個通道上使用64K通訊速度。
有關配置撥號程式對映和配置檔案的詳細資訊，請參閱Cisco IOS撥號解決方案配置指南、撥號解決方案命令參考和撥號解決方案快速配置指南。
如果您收到有效的PPP資料包，鏈路將啟動並工作。此時，應進入「PPP故障排除」一節。
傳入CAS呼叫故障排除
要排除CAS組服務到數據機的連線故障，請使用debug modem、debug modem csm和debug cas命令。
注意：debug cas命令首次出現在12.0(7)T中，用於AS5200和AS5300。早期版本的IOS使用系統級配置命令service internal以及exec命令modem-mgmt debug rbs。在AS5800上調試此資訊需要連線到中繼卡本身。
首先，確定電話公司交換機是否進入「摘機」狀態，發出來電訊號。如果沒有，請檢驗要呼叫的號碼。為此，請將電話附加到發起方的電話線路並呼叫號碼。如果來電正確，問題出在始發CPE上。如果CAS上仍未顯示該呼叫，請檢查T1（第15章）。在此例項中，使用debug serial interfaces命令。
以下顯示使用debug modem CSM的良好連線：
Router# debug modem csm CSM_MODEM_ALLOCATE: slot 1 and port 0 is allocated. MODEM_REPORT(0001): DEV_INCALL at slot 1 and port 0 CSM_PROC_IDLE: CSM_EVENT_ISDN_CALL at slot 1, port 0 CSM_RING_INDICATION_PROC: RI is on CSM_RING_INDICATION_PROC: RI is off CSM_PROC_IC1_RING: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 MODEM_REPORT(0001): DEV_CONNECTED at slot 1 and port 0 CSM_PROC_IC2_WAIT_FOR_CARRIER: CSM_EVENT_ISDN_CONNECTED at slot 1, port 0
在本示例中，呼叫被定向到數據機。如果您的呼叫定向至數據機，請繼續下面的「傳入數據機呼叫故障排除」部分。
傳入數據機呼叫故障排除
排除傳入數據機呼叫故障時，請使用以下debug命令：
-
debug modem
-
debug modem csm（適用於整合式數位資料機）
同時使用以下debug命令來指示新呼叫的進入：
-
debug isdn q931
-
debug cas
假設呼叫到達數據機，數據機需要接聽呼叫。
外部資料機的調試提示
為了便於在連線到TTY線路的外部數據機上進行調試，請增加揚聲器音量。這有助於使一些問題更顯而易見。
當始發數據機呼叫時，接收數據機是否振鈴？如果不是，請驗證該號碼，並嘗試從遠端站點進行手動呼叫。嘗試在接收端使用普通電話。根據需要更換電纜和硬體。
非同步數據機呼叫代答
如果外部數據機沒有應答，請檢查數據機和接入伺服器或路由器之間的電纜。確認數據機已使用反轉的RJ-45電纜和MMOD DB-25介面卡連線到路由器上的TTY或輔助埠。思科建議並支援此用於RJ-45埠的電纜配置。請注意，這些聯結器通常標有：資料機。
RJ-45電纜有以下幾種型別：直通、捲動和交叉。可通過並排按住RJ-45電纜的兩端來確定電纜型別。你會看到八條彩色條紋或別針。
-
如果彩色引腳的順序在兩端相同，則電纜為直線。
-
如果兩端的顏色順序相反，電纜就會捲起。
-
如果顏色指示以下內容，則電纜為交叉電纜：
RJ45到RJ45交叉電纜：
RJ45 RJ45
5 ------------------ 2
2 ------------------ 5
4 ------------------ 1
1 ------------------ 4
要確保訊號正常，請使用show line命令，如第16章所述。
除了佈線問題，外部數據機需要初始化為自動應答。檢查遠端數據機是否設定為自動應答。通常，設定自動應答時，AA指示燈亮起。將遠端數據機設定為自動應答（如果尚未設定）。有關驗證和更改數據機設定的資訊，請參閱數據機文檔。使用反向telnet初始化數據機（請參閱第16章）。
數位（整合）資料機呼叫代答
在外部數據機上，呼叫是否得到應答是清楚的，但內部數據機要求手動呼叫接收號碼。收聽迴音(ABT)。 如果您沒有聽到ABT，請檢查配置中是否有以下兩項：
-
確保isdn incoming-voice modem命令存在於處理傳入數據機連線的任何ISDN介面下。
-
在數據機的TTY線路配置下，確保命令數據機inout存在。
也有可能呼叫交換模組(CSM)沒有分配內部數據機來處理傳入呼叫。此問題可能是由於為過少的傳入連線配置數據機或資源池造成的。這也可能意味著訪問伺服器可能只是數據機不足。檢查數據機的可用性，並相應地調整數據機池或資源池管理器設定。如果數據機已分配且配置顯示數據機輸入，請收集調試資訊並聯絡思科以獲得幫助。
資料機培訓
如果接收數據機啟動DSR，則培訓成功。培訓故障可能表示電路問題或數據機不相容。
要瞭解單個數據機問題的底部，請在將始發數據機連線到所關注的POTS線路時，轉到始發數據機的AT提示。如果呼叫思科接入伺服器中的數字數據機，請準備好錄製培訓音樂的.wav檔案，或錄製數字缺陷學習序列(DIL)。 DIL是發起V.90模擬數據機告訴接收數字數據機回放的樂譜（PCM序列）。該序列允許模擬數據機識別電路中的任何數字損壞；例如多個D/A轉換、法律/u法律、搶位或數字墊。如果您沒有聽到DIL，數據機沒有在V.8/V.8bis中協商V.90（即數據機相容性問題）。 如果您確實在V.34中聽到DIL和重新訓練，模擬數據機認為（根據DIL回放）V.90不可行。
音樂裡有聲音嗎？如果是，則清理電路。
客戶端是否在不運行V.34培訓的情況下快速放棄？例如，當它聽到V.8bis時，它可能不知道該怎麼做。在這種情況下，您應嘗試在伺服器上禁用V.8bis（因此K56Flex）（如果可接受）。 您應該獲得新的客戶端韌體或更換客戶端數據機。或者，撥號端可以在撥號字串的末尾插入五個逗號。這會延遲呼叫數據機的偵聽，並且會導致接收伺服器的V.8bis音調超時，而不會影響客戶端數據機。撥號字串中的五個逗號是一般准則，可能需要調整以適應本地條件。
會話建立
在序列中的這個階段，數據機連線並經過訓練。現在該查明是否有任何流量正確通過。
如果接收呼叫的線路配置了autoselect ppp，非同步介面配置了async mode interactive，請使用命令debug modem驗證自動選擇過程。當流量通過非同步鏈路傳入時，接入伺服器將檢查流量，以確定流量是基於字元還是基於資料包。根據確定情況，接入伺服器隨後將啟動PPP會話，或進行線上上的exec會話。
帶入站PPP LCP資料包的常規自動選擇序列：
*Mar 1 21:34:56.958: TTY1: DSR came up *Mar 1 21:34:56.962: tty1: Modem: IDLE->READY *Mar 1 21:34:56.970: TTY1: EXEC creation *Mar 1 21:34:56.978: TTY1: set timer type 10, 30 seconds *Mar 1 21:34:59.722: TTY1: Autoselect(2) sample 7E !--- The inbound traffic is displayed in hexadecimal format. This is based on the !--- bits coming in over the line, regardless of whether the bits are ASCII !--- characters or elements of a packet. The bits represented in this example are !--- correct for a LCP packet. Anything different would be either a malformed packet !--- or character traffic. *Mar 1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D *Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23 *Mar 1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate !--- Having determined that the inbound traffic is actually an LCP packet, the access !--- server triggers the PPP negotiation process. *Mar 1 21:34:59.746: TTY1: EXEC creation *Mar 1 21:34:59.746: TTY1: create timer type 1, 600 seconds *Mar 1 21:34:59.794: TTY1: destroy timer type 1 (OK) *Mar 1 21:34:59.794: TTY1: destroy timer type 0 *Mar 1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up !--- The async interface changes state to up, and the PPP negotiation (not shown) !--- commences.
如果呼叫是PPP會話，並且非同步介面上配置了async mode dedicated，則使用命令debug ppp negotiation檢視是否有任何配置請求資料包來自遠端端。debug顯示為CONFREQ。如果您同時觀察入站和出站PPP資料包，請繼續「排除PPP故障」。 否則，請從呼叫發起端使用字元模式（或「exec」）會話（即非PPP會話）進行連線。
註：如果接收端在非同步介面下顯示專用的非同步調制解調器，則exec撥入僅顯示似乎是隨機ASCII垃圾的資訊。要允許終端會話但仍具有PPP功能，請使用非同步介面配置命令async mode interactive。在關聯行的配置下，使用命令autoselect ppp。
數據機無法傳送或接收資料
如果數據機與終端會話連線，並且沒有遇到任何資料，請檢查以下可能的原因和建議的操作過程：
-
數據機速度設定未鎖定
-
在接入伺服器或路由器上使用show line exec命令。輔助埠的輸出應指示當前配置的Tx和Rx速度。
有關show line命令輸出的說明，請參閱第15章中的「使用Debug命令」一節。
-
如果線路未配置為正確的速度，請使用speed線路配置命令設定接入伺服器或路由器線路上的線路速度。將該值設定為數據機與接入伺服器或路由器埠之間共有的最高速度。要設定終端波特率，請使用speed線路配置命令。此命令可設定傳送（到終端）和接收（從終端）的速度。
語法：
速度 bps
語法說明：
bps — 波特率，以位/秒(bps)為單位。 預設值為9600 bps。
以下示例將Cisco 2509接入伺服器上的線路1和2設定為115200 bps:
line 1 2 speed 115200
注意：如果由於某種原因，您無法使用流量控制，請將線路速度限製為9600 bps。速度越快，可能會導致資料丟失。
-
再次使用show line exec命令，並確認線路速度已設定為所需值。
-
當您確定接入伺服器或路由器線路已配置為所需速度時，請通過該線路啟動到數據機的反向Telnet會話。有關詳細資訊，請參閱第16章的「建立到數據機的反向Telnet會話」一節。
-
使用包含數據機的「鎖定DTE速度」命令的數據機命令字串。有關確切的配置命令語法，請參閱數據機文檔。
註：lock DTE speed命令(也稱為埠速率調整或緩沖模式)通常與數據機處理錯誤糾正的方式有關。此命令因數據機不同而大不相同。
鎖定數據機速度可確保數據機始終以在Cisco輔助埠上配置的速度與Cisco接入伺服器或路由器通訊。如果沒有使用此命令，數據機將恢復為資料鏈路（電話線）的速度，而不是以接入伺服器上配置的速度通訊。
-
-
未在本地或遠端數據機或路由器上配置硬體流控制
-
使用show line aux-line-number exec命令，然後在Capabilities欄位中查詢以下內容：
Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
有關詳細資訊，請參閱解釋第16章中的Show Line Output。
如果此欄位中未提及硬體流控制，則線路上未啟用硬體流控制。建議對接入伺服器到數據機的連線進行硬體流控制。
有關show line命令輸出的說明，參見第15章的「使用Debug命令」部分。
-
使用flowcontrol hardware line configuration命令配置線路上的硬體流控制。
要設定終端或其它串列裝置與路由器之間的資料流控制方法，請使用flowcontrol line configuration命令。使用此命令的no形式可禁用流控制。
語法：
flowcontrol {none |軟體[lock] [in | out] |硬體[在 |退出]}
語法說明：
-
none — 關閉流量控制。
-
software — 設定軟體流控制。可選關鍵字指定方向：in導致Cisco IOS軟體偵聽來自連線裝置的流量控制，out導致軟體將流量控制資訊傳送到連線的裝置。如果不指定方向，則假設兩個方向都相同。
-
lock — 當連線的裝置需要軟體流量控制時，無法關閉遠端主機的流量控制。此選項適用於使用Telnet或rlogin協定的連線。
-
hardware — 設定硬體流控制。可選關鍵字指定方向：in使軟體偵聽來自所連線裝置的流量控制，而out使軟體將流量控制資訊傳送到所連線的裝置。如果不指定方向，則假設兩個方向都相同。有關硬體流控制的詳細資訊，請參閱路由器附帶的硬體手冊。
範例：
以下示例在第7行上設定硬體流控制：
line 7 flowcontrol hardware
注意：如果由於某種原因而無法使用流量控制，請將線路速度限製為9600 bps。速度越快，可能會導致資料丟失。
-
-
在接入伺服器或路由器線路上啟用硬體流控制後，啟動通過線路到數據機的反向Telnet會話。有關詳細資訊，請參閱第16章的「建立到數據機的反向Telnet會話」一節。
-
使用包含數據機的RTS/CTS Flow命令的數據機命令字串。此命令可確保數據機使用與Cisco接入伺服器或路由器相同的流量控制方法（即硬體流量控制）。有關確切的配置命令語法，請參閱數據機文檔。
-
-
撥號器映射命令配置錯誤
-
使用show running-config特權exec命令檢視路由器配置。檢查dialer map命令條目，檢視是否指定了broadcast關鍵字。
-
如果缺少關鍵字，請將其新增到配置中。
語法：
dialer map protocol next-hop-address [name hostname] [broadcast] [dial-string]
語法說明：
-
protocol — 要對映的協定。選項包括IP、IPX、網橋和快照。
-
next-hop-address — 對端站點的非同步介面的協定地址。
-
name hostname - PPP身份驗證中使用的必需引數。它是為其建立撥號器對映的遠端站點的名稱。名稱區分大小寫，必須與遠端路由器的主機名相匹配。
-
broadcast — 一個可選關鍵字，用於廣播轉發到遠端目的地的資料包（例如IP RIP或IPX RIP/SAP更新）。在靜態路由示例配置中，不需要路由更新，並且省略broadcast關鍵字。
-
dial-string — 遠端站點的電話號碼。必須包括任何接入碼（例如，9個才能離開辦公室、國際撥號碼、區號）。
-
-
確保dialer map命令指定正確的下一跳地址。
-
如果下一跳地址不正確，請使用dialer map命令更改。
-
確保dialer map命令中的所有其他選項都已為您使用的協定正確指定。
有關配置撥號器對映的詳細資訊，請參閱Cisco IOS廣域網配置指南和廣域網命令參考。
-
-
撥號數據機問題
-
確保撥號數據機工作正常，並且已安全連線到正確的埠。確定連線到同一埠時另一個數據機是否工作。
-
調試傳入的exec會話通常分為幾個主要類別：
撥號客戶端未收到執行提示
-
線路上啟用了自動選擇
按Enter鍵嘗試訪問exec模式。
-
使用no exec命令配置線路
-
使用show line exec命令檢視相應線路的狀態。
檢查Capabilities欄位以檢視其是否顯示「exec suppressed」。 如果是這種情況，則會啟用no exec線路配置命令。
-
線上路上配置exec線路配置命令，以允許啟動exec會話。此命令沒有引數或關鍵字。
以下示例在第7行開啟exec:
line 7 exec
-
-
未啟用流控制。
或
僅在一個裝置（DTE或DCE）上啟用流量控制。
或
流量控制配置錯誤。
-
使用show line aux-line-number exec命令，然後在Capabilities欄位中查詢以下內容：
Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
有關詳細資訊，請參閱解釋第16章中的Show Line Output。
如果此欄位中未提及硬體流控制，則線路上未啟用硬體流控制。建議對接入伺服器到數據機的連線進行硬體流控制。
有關show line命令輸出的解釋，參見第15章的「使用調試命令」部分。
-
使用flowcontrol hardware line configuration命令線上上配置硬體流控制。以下示例在第7行上設定硬體流控制：
line 7 flowcontrol hardware
注意：如果由於某種原因而無法使用流量控制，請將線路速度限製為9600 bps。速度越快，可能會導致資料丟失。
-
在接入伺服器或路由器線路上啟用硬體流控制後，啟動通過線路到數據機的反向Telnet會話。有關詳細資訊，請參閱第16章的「建立到數據機的反向Telnet會話」一節。
-
使用包含數據機的RTS/CTS Flow命令的數據機命令字串。此命令可確保數據機使用與Cisco接入伺服器或路由器相同的流量控制方法（即硬體流量控制）。有關確切的配置命令語法，請參閱數據機文檔。
-
-
數據機速度設定未鎖定
-
在接入伺服器或路由器上使用show line exec命令。輔助埠的輸出應指示當前配置的Tx和Rx速度。
有關show line命令輸出的解釋，參見第15章的「使用Debug命令」部分。
-
如果線路未配置為正確的速度，請使用speed line configuration命令設定接入伺服器或路由器線路上的線路速度。將該值設定為數據機與接入伺服器或路由器埠之間共有的最高速度。要設定終端波特率，請使用速度行配置命令。此命令可設定傳送（到終端）和接收（從終端）的速度。
語法：
速度 bps
語法說明：
bps — 波特率，以位/秒(bps)為單位。 預設值為9600 bps。
範例：
以下示例將Cisco 2509接入伺服器上的線路1和2設定為115200 bps:
line 1 2 speed 115200
注意：如果由於某種原因而無法使用流量控制，請將線路速度限製為9600 bps。速度越快，可能會導致資料丟失。
-
再次使用show line exec命令，並確認線路速度已設定為所需值。
-
當您確定接入伺服器或路由器線路已配置為所需速度時，請通過該線路啟動到數據機的反向Telnet會話。有關詳細資訊，請參閱第16章的「建立到數據機的反向Telnet會話」一節。
-
使用包含數據機的lock DTE speed命令的數據機命令字串。有關確切的配置命令語法，請參閱數據機文檔。
註：lock DTE speed命令（也稱為埠速率調整或緩沖模式）通常與數據機處理錯誤糾正的方式有關。此命令因數據機不同而大不相同。
鎖定數據機速度可確保數據機始終以在Cisco輔助埠上配置的速度與Cisco接入伺服器或路由器通訊。如果沒有使用此命令，數據機將恢復為資料鏈路（電話線）的速度，而不是以接入伺服器上配置的速度通訊。
-
撥號會話看到「垃圾」
-
數據機速度設定未鎖定
-
在接入伺服器或路由器上使用show line exec命令。輔助埠的輸出應指示當前配置的Tx和Rx速度。
有關show line命令輸出的說明，請參閱第15章中的「使用Debug命令」一節。
-
如果線路未配置為正確的速度，請使用speed線路配置命令設定接入伺服器或路由器線路上的線路速度。將該值設定為數據機與接入伺服器或路由器埠之間共有的最高速度。
要設定終端波特率，請使用speed線路配置命令。此命令可設定傳送（到終端）和接收（從終端）的速度。
語法：
speed bps
語法說明：
bps波特率，以位/秒(bps)為單位。 預設值為9600 bps。
範例：
以下示例將Cisco 2509接入伺服器上的線路1和2設定為115200 bps:
線路1 2
速度115200
注意：如果由於某種原因而無法使用流量控制，請將線路速度限製為9600 bps。速度越快，可能會導致資料丟失。
-
再次使用show line exec命令，並確認線路速度已設定為所需值。
-
當您確定接入伺服器或路由器線路已配置為所需速度時，請通過該線路啟動到數據機的反向Telnet會話。有關詳細資訊，請參閱第16章的「建立到數據機的反向Telnet會話」一節。
-
使用包含數據機的lock DTE speed命令的數據機命令字串。有關確切的配置命令語法，請參閱數據機文檔。
註：lock DTE speed命令(也稱為port rate adjust或buffered mode)通常與數據機處理錯誤糾正的方式有關。此命令因數據機不同而大不相同。
鎖定數據機速度可確保數據機始終以在Cisco輔助埠上配置的速度與Cisco接入伺服器或路由器通訊。如果沒有使用此命令，數據機將恢復為資料鏈路（電話線）的速度，而不是以接入伺服器上配置的速度通訊。
-
症狀：遠端撥入會話在另一個使用者啟動的已存在會話中開啟。也就是說，撥入使用者看到的不是登入提示，而是另一個使用者建立的會話（可能是UNIX命令提示、文本編輯器會話等）。
在現有會話中開啟撥號會話
-
為DCD配置的數據機始終高
-
數據機應重新配置，使其僅在光碟上保持DCD高位。這通常通過使用&C1 modem命令字串來完成，但請查閱數據機文檔，瞭解數據機的確切語法。
-
您可能必須使用no exec線路配置命令配置數據機所連線的接入伺服器線路。使用clear line特權exec命令清除線路，啟動與數據機的反向Telnet會話，並重新配置數據機，以便僅CD上的DCD高。
-
輸入disconnect結束Telnet會話並使用exec線路配置命令重新配置接入伺服器線路
-
-
訪問伺服器或路由器上未啟用數據機控制
-
在接入伺服器或路由器上使用show line exec命令。輔助埠的輸出應該在「數據機」列中顯示inout或RIisCD。這表示在接入伺服器或路由器的線路上啟用了數據機控制。
有關show line輸出的說明，請參閱第15章中的「使用Debug命令」部分。
-
使用modem inout line configuration命令配置用於數據機控制的線路。訪問伺服器上現在啟用了數據機控制。
註：當數據機連線存在問題時，請一定使用modem inout命令而不是modem dialin命令。後一個命令允許線路僅接受來電。傳出呼叫將被拒絕，使得無法與數據機建立Telnet會話進行配置。如果要啟用modem dialin命令，請僅在您確定數據機工作正常後才啟用。
-
-
纜線不正確
-
檢查數據機和接入伺服器或路由器之間的電纜。確認數據機已使用反轉的RJ-45電纜和MMOD DB-25介面卡連線到接入伺服器或路由器上的輔助埠。思科推薦並支援此佈線配置，用於RJ-45埠。這些聯結器通常標有：數據機。
RJ-45電纜有兩種型別：筆直滾動。如果並排拿起RJ-45電纜的兩端，您會看到每端有8條彩色線或引腳。如果彩色引腳的順序在兩端相同，則電纜為直線。如果兩端的顏色順序相反，則電纜將捲起。
卷電纜(CAB-500RJ)是思科2500/CS500的標準配置。
-
使用show line exec命令驗證佈線是否正確。請參閱本章15中「使用Debug命令」一節中show line命令輸出的說明。
-
撥號接收數據機未正確斷開連線
-
數據機未感知DTR
輸入Hangup DTR數據機命令字串。此命令指示數據機在不再接收DTR訊號時丟棄載波。
在與Hayes相容的數據機上，通常使用&D3字串在調制解調器上配置Hangup DTR。有關此指令的確切語法，請參閱您資料機的說明檔案。
-
路由器或訪問伺服器上未啟用數據機控制
-
在接入伺服器或路由器上使用show line exec命令。輔助埠的輸出應該在「數據機」列中顯示inout或RIisCD。這表示在接入伺服器或路由器的線路上啟用了數據機控制。
有關show line命令輸出的解釋，參見第15章的「使用Debug命令」部分。
-
使用modem inout line configuration命令配置用於數據機控制的線路。訪問伺服器上現在啟用了數據機控制。
註：當數據機連線存在問題時，請一定使用modem inout命令而不是modem dialin命令。後一個命令允許線路僅接受來電。傳出呼叫將被拒絕，使得無法與數據機建立Telnet會話進行配置。如果要啟用modem dialin命令，請僅在您確定數據機工作正常後才啟用。
-
出站呼叫故障排除
來電故障排除方法從底部開始，出站連線故障排除方法則從頂部開始。推理的一般流程如下：
-
按需撥號路由(DDR)是否會發起呼叫？（下一個問題的答案是「是」）
-
如果這是非同步數據機，聊天指令碼是否發出預期的命令？
-
電話打給PSTN了嗎？
-
遠端是否應答呼叫？
-
呼叫是否完成？
-
資料是否通過鏈路傳輸？
-
是否已建立會話？（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)
如果流量不發起撥號嘗試，最常見的原因是配置不正確（相關流量定義、撥號器介面的狀態或路由）。
流量無法發起撥號嘗試
-
缺少或不正確的「相關流量」定義
-
使用命令show running-config，確保介面配置有dialer-group，並且有一個配置有匹配號碼的全域性級別dialer-list。
-
確保dialer-list命令配置為允許整個協定或允許與訪問清單匹配的流量
-
驗證存取清單是否宣告通過連結的封包有意義。一個有用的測試是使用特權exec命令debug ip packet [list number] 使用相關訪問清單的編號。然後嘗試通過鏈路ping或以其他方式傳送流量。如果相關流量過濾器定義正確，您將在調試輸出中看到資料包。如果此測試沒有調試輸出，則訪問清單與資料包不匹配。
-
-
介面狀態
使用命令show interfaces [interface name]確保介面處於「up/up（欺騙）」狀態。
-
處於「備用」模式的介面
路由器上的另一個（主要）介面已配置為使用撥號器介面作為備份介面。此外，主介面未處於「down/down」狀態，這是使撥號器介面退出備用模式所必需的。此外，還必須在主介面上配置備份延遲，否則永遠不會執行backup interface命令。
要檢查撥號器介面是否將從「standby」變為「up/up(spoofing)」，通常需要從主介面拔下電纜。僅使用配置命令shutdown關閉主介面不會使主介面進入「down/down」狀態，而是使其進入「administratively 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
如果出現撥號原因，但未嘗試撥號，則通常原因是撥號對映或撥號程式配置檔案配置錯誤。
未撥打電話
下面列出了一些可能的問題和建議的操作：
-
撥號器對映配置錯誤
使用命令show running-config確保為撥號介面配置至少一條指向遠端站點的協定地址和被叫號碼的dialer map語句。
-
撥號器設定不正確
使用命令show running-config確保使用dialer pool X命令配置Dialer介面，並且路由器上的撥號程式介面配置有匹配的dialer pool-member X。如果沒有正確配置Dialer配置檔案，您可能會看到調試消息：
Dialer1: Can't place call, no dialer pool set
確保配置了撥號器字串。
非同步出站呼叫 — 驗證聊天指令碼操作
如果出站呼叫是數據機呼叫，則必須執行聊天指令碼才能繼續該呼叫。對於基於撥號對映的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
聊天指令碼問題可分為三類：
-
配置錯誤
-
數據機故障
-
連線失敗
聊天指令碼失敗
此清單顯示偵錯聊天顯示的可能輸出和建議動作：
-
找不到[number]的匹配聊天指令碼
尚未配置聊天指令碼。加一個。
-
聊天指令碼撥出完成，狀態=連線超時；遠端主機沒有響應
數據機沒有響應聊天指令碼。驗證與數據機的通訊（請參閱第16章中的表16-2）。
-
預計超時：CONNECT
-
可能性1:本地數據機實際上沒有發出呼叫。驗證數據機是否可以通過反向Telnet到數據機並手動發起撥號來發出呼叫。
-
可能性2:遠端數據機未響應。使用普通POTS電話撥打遠端數據機測試此功能。
-
可能性3:正在撥打的號碼不正確。通過手動撥號驗證號碼。如有必要，請更正配置。
-
可能性4:數據機培訓時間過長或TIMEOUT值過低。如果本地數據機是外部數據機，請開啟數據機揚聲器音量並收聽培訓音。如果突然中斷培訓，請嘗試增加chat-script命令中的TIMEOUT值。如果TIMEOUT已經是60秒或更長，請參閱數據機培訓部分。
-
ISDN出站呼叫
在BRI或PRI上首次懷疑發生ISDN故障時，總是檢查show isdn status的輸出。需要注意的關鍵是，第1層應處於活動狀態，第2層應處於MULTIPLE_FRAME_ESTABLISHED狀態。有關讀取此輸出的資訊以及糾正措施，請參閱第16章的「解釋Show ISDN狀態輸出」一節。
對於出站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
!--- The CONNECT message is the key indicator of success. If a CONNECT is not received, !--- you may see a DISCONNECT or a RELEASE_COMP (release complete) message followed by !--- a cause code (see below)
*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的位置。這有助於您對問題進行本地化。
-
第三個和第四個位元組表示故障的實際原因。請參見後續表以瞭解不同值的意義。
註：以下列印輸出通常表示較高的協定故障：
Cause i = 0x8090 - Normal call clearing
PPP身份驗證失敗是一個典型原因。在假設連線失敗必然是ISDN問題之前，啟用debug ppp negotiation和debug ppp authentication
原因代碼欄位
Table 17-9列出了debug命令中以以下格式顯示的ISDN原因代碼欄位：
i=0x y1 y2 z1 z2 [a1 a2]
ISDN原因代碼欄位
| 欄位 | 值說明 |
|---|---|
| 0x | 後面的值以十六進位制表示。 |
| y1 | 8 - ITU-T標準編碼。 |
| y2 | 0 — 使用者1 — 專用網路服務本地使用者2 — 公共網路服務本地使用者3 — 傳輸網路4 — 公共網路服務遠端使用者5 — 專用網路服務遠端使用者7 — 國際網路A — 超出網間點的網路 |
| z1 | 原因值的類（更重要的十六進位制數）。有關可能值的詳細資訊，請參閱下表。 |
| z2 | 原因值的值（不太重要的十六進位制數）。有關可能值的詳細資訊，請參閱下表。 |
| a1 | （可選）始終為8的診斷欄位。 |
| a2 | （可選）診斷欄位，該欄位是以下值之一：0 — 未知1 — 永久2 — 瞬變 |
ISDN原因值
下表列出原因資訊元素的一些最常見原因值的說明 — 原因代碼的第三個和第四個位元組。有關ISDN代碼和值的更完整資訊，請參閱瞭解debug isdn q931 Disconnect Cause Codes。
| 十六進位制值 | 原因 | 說明 |
|---|---|---|
| 81 | 未分配（未分配）號碼 | ISDN號碼已以正確格式傳送到交換器；但是，該號碼不會分配給任何目的裝置。 |
| 90 | 正常呼叫清除 | 發生了正常的呼叫清除。 |
| 91 | 使用者忙 | 被叫系統確認連線請求，但無法接受該呼叫，因為所有B通道都在使用中。 |
| 92 | 無使用者響應 | 無法完成連線，因為目標未響應呼叫。 |
| 93 | 使用者無應答（使用者收到警報） | 目的地會響應連線請求，但無法在規定時間內完成連線。問題出在連線的遠端端。 |
| 95 | 呼叫被拒絕 | 目標可以接受呼叫，但因未知原因拒絕了該呼叫。 |
| 9C | 無效的數字格式 | 無法建立連線，因為目標地址以無法識別的格式顯示，或者因為目標地址不完整。 |
| 9F | 正常，未指定 | 報告正常事件在沒有標準原因適用時的發生情況。無需任何操作。 |
| A2 | 沒有可用電路/通道 | 無法建立連線，因為沒有合適的管道可以接聽呼叫。 |
| A6 | 網路故障 | 無法到達目的地，因為網路無法正常運作，且條件可能會持續較長時間。立即重新連線可能失敗。 |
| AC | 請求的電路/通道不可用 | 由於未知原因，遠端裝置無法提供請求的通道。這可能是暫時的問題。 |
| B2 | 請求的合作室未訂閱 | 遠端裝置僅通過預訂支援請求的補充服務。這通常是指長途服務。 |
| B9 | 未授權承載能力 | 使用者請求網路提供的承載能力，但使用者無權使用它。這可能是訂閱問題。 |
| D8 | 目標不相容 | 表示嘗試連線到非ISDN裝置。例如，連線到模擬線路。 |
| E0 | 缺少必需的資訊元素 | 接收裝置接收到不包含強制資訊元素之一的消息。這通常是由於D通道錯誤造成的。如果此錯誤會系統地發生，請向ISDN服務提供商報告。 |
| E4 | 資訊元素內容無效 | 遠端裝置接收到在資訊元素中包含無效資訊的消息。這通常是由於D通道錯誤造成的。 |
CAS出站呼叫
對於通過CAS T1或E1和整合數字數據機的出站呼叫，大部分故障排除類似於其他DDR故障排除。對於通過PRI線路的出站整合數據機呼叫也是如此。以這種方式進行呼叫所涉及的獨特功能需要在呼叫失敗時進行特殊調試。
對於其他DDR情況，必須確保要求呼叫嘗試。使用debug dialer events實現此目的。請參閱驗證撥號器操作。
在發出呼叫之前，必須為呼叫分配數據機。要檢視此過程和後續呼叫，請使用以下debug命令：
-
debug modem
-
debug modem csm
-
debug cas
注意：debug cas命令最初出現在AS5200和AS5300的IOS版本12.0(7)T中。早期版本的IOS使用系統級配置命令service internal以及exec命令modem-mgmt debug rbs:
開啟調試
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
關閉調試
router# 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。有關T1故障排除資訊，請參閱第15章。
PPP故障排除
當知道撥號連線（ISDN或非同步）已成功建立時，開始排除連線的PPP部分的故障。
在排除PPP協商故障之前，必須瞭解成功的調試PPP序列的外觀。這樣，將故障的PPP調試會話與成功完成的調試PPP序列進行比較可節省時間和精力。
以下是成功的PPP序列示例。有關輸出欄位的詳細說明，請參閱PPP LCP協商詳細資訊。
Montecito# Mar 13 10:57:13.415: %LINK-3-UPDOWN: Interface Async1, changed state to up Mar 13 10:57:15.415: As1 LCP: O CONFREQ [ACKrcvd] id 2 len 25 Mar 13 10:57:15.415: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:15.415: As1 LCP: AuthProto CHAP (0x0305C22305) Mar 13 10:57:15.415: As1 LCP: MagicNumber 0x1084F0A2 (0x05061084F0A2) Mar 13 10:57:15.415: As1 LCP: PFC (0x0702) Mar 13 10:57:15.415: As1 LCP: ACFC (0x0802) Mar 13 10:57:15.543: As1 LCP: I CONFACK [REQsent] id 2 len 25 Mar 13 10:57:15.543: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:15.543: As1 LCP: AuthProto CHAP (0x0305C22305) Mar 13 10:57:15.543: As1 LCP: MagicNumber 0x1084F0A2 (0x05061084F0A2) Mar 13 10:57:15.543: As1 LCP: PFC (0x0702) Mar 13 10:57:15.547: As1 LCP: ACFC (0x0802) Mar 13 10:57:16.919: As1 LCP: I CONFREQ [ACKrcvd] id 4 len 23 Mar 13 10:57:16.919: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:16.919: As1 LCP: MagicNumber 0x001327B0 (0x0506001327B0) Mar 13 10:57:16.919: As1 LCP: PFC (0x0702) Mar 13 10:57:16.919: As1 LCP: ACFC (0x0802) Mar 13 10:57:16.919: As1 LCP: Callback 6 (0x0D0306) Mar 13 10:57:16.919: As1 LCP: O CONFREJ [ACKrcvd] id 4 len 7 Mar 13 10:57:16.919: As1 LCP: Callback 6 (0x0D0306) Mar 13 10:57:17.047: As1 LCP: I CONFREQ [ACKrcvd] id 5 len 20 Mar 13 10:57:17.047: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:17.047: As1 LCP: MagicNumber 0x001327B0 (0x0506001327B0) Mar 13 10:57:17.047: As1 LCP: PFC (0x0702) Mar 13 10:57:17.047: As1 LCP: ACFC (0x0802) Mar 13 10:57:17.047: As1 LCP: O CONFACK [ACKrcvd] id 5 len 20 Mar 13 10:57:17.047: As1 LCP: ACCM 0x000A0000 (0x0206000A0000) Mar 13 10:57:17.047: As1 LCP: MagicNumber 0x001327B0 (0x0506001327B0) Mar 13 10:57:17.047: As1 LCP: PFC (0x0702) Mar 13 10:57:17.047: As1 LCP: ACFC (0x0802) Mar 13 10:57:17.047: As1 LCP: State is Open Mar 13 10:57:17.047: As1 PPP: Phase is AUTHENTICATING, by this end Mar 13 10:57:17.047: As1 CHAP: O CHALLENGE id 1 len 28 from "Montecito" Mar 13 10:57:17.191: As1 CHAP: I RESPONSE id 1 len 30 from "Goleta" Mar 13 10:57:17.191: As1 CHAP: O SUCCESS id 1 len 4 Mar 13 10:57:17.191: As1 PPP: Phase is UP Mar 13 10:57:17.191: As1 IPCP: O CONFREQ [Closed] id 1 len 10 Mar 13 10:57:17.191: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:17.303: As1 IPCP: I CONFREQ [REQsent] id 1 len 40 Mar 13 10:57:17.303: As1 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) Mar 13 10:57:17.303: As1 IPCP: Address 0.0.0.0 (0x030600000000) Mar 13 10:57:17.303: As1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Mar 13 10:57:17.303: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:17.303: As1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Mar 13 10:57:17.303: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:17.303: As1 IPCP: O CONFREJ [REQsent] id 1 len 22 Mar 13 10:57:17.303: As1 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) Mar 13 10:57:17.303: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:17.303: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:17.319: As1 CCP: I CONFREQ [Not negotiated] id 1 len 15 Mar 13 10:57:17.319: As1 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) Mar 13 10:57:17.319: As1 CCP: Stacker history 1 check mode EXTENDED (0x1105000104) Mar 13 10:57:17.319: As1 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP Mar 13 10:57:17.319: As1 LCP: (0x80FD0101000F12060000000111050001) Mar 13 10:57:17.319: As1 LCP: (0x04) Mar 13 10:57:17.319: As1 IPCP: I CONFACK [REQsent] id 1 len 10 Mar 13 10:57:17.319: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:18.191: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async1, changed state to up Mar 13 10:57:19.191: As1 IPCP: TIMEout: State ACKrcvd Mar 13 10:57:19.191: As1 IPCP: O CONFREQ [ACKrcvd] id 2 len 10 Mar 13 10:57:19.191: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:19.315: As1 IPCP: I CONFACK [REQsent] id 2 len 10 Mar 13 10:57:19.315: As1 IPCP: Address 172.22.66.23 (0x0306AC164217) Mar 13 10:57:20.307: As1 IPCP: I CONFREQ [ACKrcvd] id 2 len 34 Mar 13 10:57:20.307: As1 IPCP: Address 0.0.0.0 (0x030600000000) Mar 13 10:57:20.307: As1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Mar 13 10:57:20.307: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:20.307: As1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Mar 13 10:57:20.307: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:20.307: As1 IPCP: O CONFREJ [ACKrcvd] id 2 len 16 Mar 13 10:57:20.307: As1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Mar 13 10:57:20.307: As1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Mar 13 10:57:20.419: As1 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 Mar 13 10:57:20.419: As1 IPCP: Address 0.0.0.0 (0x030600000000) Mar 13 10:57:20.419: As1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Mar 13 10:57:20.419: As1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Mar 13 10:57:20.419: As1 IPCP: O CONFNAK [ACKrcvd] id 3 len 22 Mar 13 10:57:20.419: As1 IPCP: Address 10.1.1.1 (0x03060A010101) Mar 13 10:57:20.419: As1 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) Mar 13 10:57:20.419: As1 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) Mar 13 10:57:20.543: As1 IPCP: I CONFREQ [ACKrcvd] id 4 len 22 Mar 13 10:57:20.543: As1 IPCP: Address 10.1.1.1 (0x03060A010101) Mar 13 10:57:20.547: As1 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) Mar 13 10:57:20.547: As1 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) Mar 13 10:57:20.547: As1 IPCP: O CONFACK [ACKrcvd] id 4 len 22 Mar 13 10:57:20.547: As1 IPCP: Address 10.1.1.1 (0x03060A010101) Mar 13 10:57:20.547: As1 IPCP: PrimaryDNS 171.68.10.70 (0x8106AB440A46) Mar 13 10:57:20.547: As1 IPCP: SecondaryDNS 171.68.10.140 (0x8306AB440A8C) Mar 13 10:57:20.547: As1 IPCP: State is Open Mar 13 10:57:20.551: As1 IPCP: Install route to 10.1.1.1
注意：調試可能以不同的格式顯示。此示例顯示在IOS版本11.2(8)中修改過的較新PPP調試輸出格式。 有關使用舊版IOS進行PPP調試的示例，請參閱第16章。
PPP LCP協商詳細資訊
| 時間戳 | 說明 |
|---|---|
| 10:57:15.415 | 傳出配置請求(O CONFREQ)。 NAS向客戶端傳送傳出PPP配置請求資料包。 |
| 10:57:15.543 | 傳入配置確認(I CONFACK)。 客戶端確認Montecito的PPP請求。 |
| 10:57:16.919 | 傳入配置請求(CONFREQ)。 客戶端希望協商回撥協定。 |
| 10:57:16.919 | 傳出配置拒絕(O CONFREJ)。 NAS拒絕回撥選項。 |
| 10:57:17.047 | 傳入配置請求(CONFREQ)。 客戶端請求一組新選項。請注意，這次未請求Microsoft回撥。 |
| 10:57:17.047 | 傳出配置確認(O CONFACK)。 NAS接受一組新的選項。 |
| 10:57:17.047 | PPP LCP協商已成功完成。LCP狀態為「Open」。 兩端均已確認(CONFACK)另一端的配置請求(CONFREQ)。 |
| 10:57:17.047至10:57:17.191 | PPP身份驗證已成功完成。LCP協商後，身份驗證開始。在傳送任何網路協定（例如IP）之前，必須進行身份驗證。兩端都使用在LCP期間協商的方法進行身份驗證。Montecito正在使用CHAP對客戶端進行身份驗證。 |
| 10:57:20.551 | IP控制通訊協定(IPCP)的狀態為open。為IPCP對等體協商並安裝路由，該對等體分配了IP地址1.1.1.1。 |
連結控制通訊協定
在LCP協商過程中通常遇到兩種問題。
當一個對等體發出另一個對等體無法或不願確認的配置請求時，會發生第一個事件。雖然這種情況經常發生，但如果請求者堅持使用該引數，就可能會出現問題。典型的示例是協商AUTHTYPE（也稱為「AuthProto」）時。 例如，許多訪問伺服器配置為僅接受CHAP進行身份驗證。如果呼叫方配置為僅執行PAP身份驗證，則將會交換CONFREQ和CONFNAK，直到一個對等體或另一個對等體斷開連線。
BR0:1 LCP: I CONFREQ [ACKrcvd] id 66 len 14 BR0:1 LCP: AuthProto PAP (0x0304C023) BR0:1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) BR0:1 LCP: O CONFNAK [ACKrcvd] id 66 len 9 BR0:1 LCP: AuthProto CHAP (0x0305C22305) BR0:1 LCP: I CONFREQ [ACKrcvd] id 67 len 14 BR0:1 LCP: AuthProto PAP (0x0304C023) BR0:1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) BR0:1 LCP: O CONFNAK [ACKrcvd] id 67 len 9 BR0:1 LCP: AuthProto CHAP (0x0305C22305) BR0:1 LCP: I CONFREQ [ACKrcvd] id 68 len 14 BR0:1 LCP: AuthProto PAP (0x0304C023) BR0:1 LCP: MagicNumber 0xBC6B9F91 (0x0506BC6B9F91) BR0:1 LCP: O CONFNAK [ACKrcvd] id 68 len 9 BR0:1 LCP: AuthProto CHAP (0x0305C22305) ... ...
LCP中的第二類問題是當只有一個或兩個對等點上只看到出站CONFREQ，如下例所示。這通常是下層速度不匹配所導致的結果。這種情況可能會發生在非同步或ISDN DDR中。
Jun 10 19:57:59.768: As5 PPP: Phase is ESTABLISHING, Active Open Jun 10 19:57:59.768: As5 LCP: O CONFREQ [Closed] id 64 len 25 Jun 10 19:57:59.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:57:59.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:57:59.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:57:59.768: As5 LCP: PFC (0x0702) Jun 10 19:57:59.768: As5 LCP: ACFC (0x0802) Jun 10 19:58:01.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:01.768: As5 LCP: O CONFREQ [REQsent] id 65 len 25 Jun 10 19:58:01.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:58:01.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:58:01.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:58:01.768: As5 LCP: PFC (0x0702) Jun 10 19:58:01.768: As5 LCP: ACFC (0x0802). Jun 10 19:58:03.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:03.768: As5 LCP: O CONFREQ [REQsent] id 66 len 25 Jun 10 19:58:03.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:58:03.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:58:03.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:58:03.768: As5 LCP: PFC (0x0702) Jun 10 19:58:03.768: As5 LCP: ACF.C (0x0802) Jun 10 19:58:05.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:05.768: As5 LCP: O CONFREQ [REQsent] id 67 len 25 !--- This repeats every two seconds until: Jun 10 19:58:19.768: As5 LCP: O CONFREQ [REQsent] id 74 len 25 Jun 10 19:58:19.768: As5 LCP: ACCM 0x000A0000 (0x0206000A0000) Jun 10 19:58:19.768: As5 LCP: AuthProto CHAP (0x0305C22305) Jun 10 19:58:19.768: As5 LCP: MagicNumber 0x5779D9D2 (0x05065779D9D2) Jun 10 19:58:19.768: As5 LCP: PFC (0x0702) Jun 10 19:58:19.768: As5 LCP: ACFC (0x0802) Jun 10 19:58:21.768: As5 LCP: TIMEout: State REQsent Jun 10 19:58:21.768: TTY5: Async Int reset: Dropping DTR
如果連線是非同步的，可能的原因是路由器與其數據機之間的速度不匹配。這通常是因為無法將數據機的DTE速度鎖定為TTY線路的配置速度。在對等體中的任一個或兩個上可能會出現問題，請檢查兩者。請參閱本章前面的數據機無法傳送或接收資料。
如果通過ISDN連線時出現症狀，則問題可能是一個對等體在56K連線，而另一個在64K。雖然這種情況很少發生，但它確實發生了。問題可能是一個或兩個同行，也可能是一個電話公司。使用debug isdn q931並檢查每個對等體上的SETUP消息。從一個對等體傳送的承載能力應與在另一個對等體上接收的SETUP消息中看到的承載能力相匹配。作為可能的補救措施，在介面級別命令dialer map中或在對映類下配置的命令dialer isdn speed中配置撥號速度56K或64K。
*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
這種情形可保證致電Cisco TAC。在呼叫TAC之前，從兩個對等點收集以下輸出：
-
show running-config
-
顯示版本
-
debug isdn q931
-
debug isdn events
-
debug ppp negotiation
驗證
身份驗證失敗是PPP失敗最常見的原因。錯誤配置或錯誤匹配的使用者名稱和密碼在調試輸出中會產生錯誤消息。
以下示例顯示使用者名稱Goleta沒有撥入NAS的許可權，NAS沒有為此使用者配置的本地使用者名稱。要解決此問題，請使用username name password password 命令將使用者名稱「Goleta」新增到NAS的本地AAA資料庫：
Mar 13 11:01:42.399: As2 LCP: State is Open Mar 13 11:01:42.399: As2 PPP: Phase is AUTHENTICATING, by this end Mar 13 11:01:42.399: As2 CHAP: O CHALLENGE id 1 len 28 from "Montecito" Mar 13 11:01:42.539: As2 CHAP: I RESPONSE id 1 len 30 from "Goleta" Mar 13 11:01:42.539: As2 CHAP: Unable to validate Response. Username Goleta not found Mar 13 11:01:42.539: As2 CHAP: O FAILURE id 1 len 26 msg is "Authentication failure" Mar 13 11:01:42.539: As2 PPP: Phase is TERMINATING
以下示例顯示在NAS上配置了使用者名稱「Goleta」。但是密碼比較失敗。要解決此問題，請使用username name password password 命令為Goleta指定正確的登入密碼：
Mar 13 11:04:06.843: As3 LCP: State is Open Mar 13 11:04:06.843: As3 PPP: Phase is AUTHENTICATING, by this end Mar 13 11:04:06.843: As3 CHAP: O CHALLENGE id 1 len 28 from "Montecito" Mar 13 11:04:06.987: As3 CHAP: I RESPONSE id 1 len 30 from "Goleta" Mar 13 11:04:06.987: As3 CHAP: O FAILURE id 1 len 25 msg is "MD/DES compare failed" Mar 13 11:04:06.987: As3 PPP: Phase is TERMINATING
有關PAP身份驗證的詳細資訊，請參閱PPP口令身份驗證協定(PAP)的配置與故障排除。
網路控制通訊協定
對等體成功執行所需的身份驗證後，協商將進入NCP階段。如果兩個對等體都配置正確，則NCP協商可能與以下示例類似，該示例顯示客戶端PC正在撥入和協商NAS:
solvang# show debug Generic IP: IP peer address activity debugging is on PPP: PPP protocol negotiation debugging is on *Mar 1 21:35:04.186: As4 PPP: Phase is UP *Mar 1 21:35:04.190: As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10 *Mar 1 21:35:04.194: As4 IPCP: Address 10.1.2.1 (0x03060A010201) *Mar 1 21:35:04.282: As4 IPCP: I CONFREQ [REQsent] id 1 len 28 *Mar 1 21:35:04.282: As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) *Mar 1 21:35:04.286: As4 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 1 21:35:04.290: As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Mar 1 21:35:04.298: As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Mar 1 21:35:04.306: As4 IPCP: O CONFREJ [REQsent] id 1 len 10 *Mar 1 21:35:04.310: As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) *Mar 1 21:35:04.314: As4 CCP: I CONFREQ [Not negotiated] id 1 len 15 *Mar 1 21:35:04.318: As4 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) *Mar 1 21:35:04.318: As4 CCP: Stacker history 1 check mode EXTENDED (0x1105000104) *Mar 1 21:35:04.322: As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP *Mar 1 21:35:04.326: As4 LCP: (0x80FD0101000F12060000000111050001) *Mar 1 21:35:04.330: As4 LCP: (0x04) *Mar 1 21:35:04.334: As4 IPCP: I CONFACK [REQsent] id 1 len 10 *Mar 1 21:35:04.338: As4 IPCP: Address 10.1.2.1 (0x03060A010201) *Mar 1 21:35:05.186: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed state to up *Mar 1 21:35:07.274: As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22 *Mar 1 21:35:07.278: As4 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 1 21:35:07.282: As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) *Mar 1 21:35:07.286: As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) *Mar 1 21:35:07.294: As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22 *Mar 1 21:35:07.298: As4 IPCP: Address 10.1.2.2 (0x03060A010202) *Mar 1 21:35:07.302: As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) *Mar 1 21:35:07.310: As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) *Mar 1 21:35:07.426: As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 *Mar 1 21:35:07.430: As4 IPCP: Address 10.1.2.2 (0x03060A010202) *Mar 1 21:35:07.434: As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) *Mar 1 21:35:07.442: As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) *Mar 1 21:35:07.446: ip_get_pool: As4: validate address = 10.1.2.2 *Mar 1 21:35:07.450: ip_get_pool: As4: using pool default *Mar 1 21:35:07.450: ip_get_pool: As4: returning address = 10.1.2.2 *Mar 1 21:35:07.454: set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant *Mar 1 21:35:07.458: As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22 *Mar 1 21:35:07.462: As4 IPCP: Address 10.1.2.2 (0x03060A010202) *Mar 1 21:35:07.466: As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) *Mar 1 21:35:07.474: As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) *Mar 1 21:35:07.478: As4 IPCP: State is Open *Mar 1 21:35:07.490: As4 IPCP: Install route to 10.1.2.2
PPP NCP協商詳細資訊
| 時間戳 | 說明 |
|---|---|
| 21:35:04.190 | 傳出配置請求(O CONFREQ)。 NAS向對等裝置傳送包含其IP地址的傳出PPP配置請求資料包。 |
| 21:35:04.282 | 傳入CONFREQ。對等體請求執行VJ標頭壓縮。它自身需要IP地址，以及主和輔助DNS伺服器的地址。 |
| 21:35:04.306 | 出站配置拒絕(CONFREJ)。VJ標頭壓縮被拒絕。 |
| 21:35:04.314至21:35:04.330 | 對等體傳送請求以進行壓縮控制協定；NAS通過PROTREJ消息拒絕整個協定。對等體不應嘗試（且不會）重試CCP。 |
| 21:35:04.334 | 對等體使用CONFACK確認NAS的IP地址。 |
| 21:35:07.274 | 傳入CONFREQ。對等體不再請求執行VJ標頭壓縮，但仍需要自身的IP地址，以及主和輔助DNS伺服器的地址。 |
| 21:35:07.294 | NAS傳送一個CONFNAK，其中包含它希望對等體使用的地址以及主和輔助DNS伺服器的地址。 |
| 21:35:07.426 | 對等體將地址傳送回NAS;試圖確認地址是否正確接收。 |
| 21:35:07.458 | NAS使用CONFACK確認地址。 |
| 21:35:07.478 | 已發出CONFACK的連線兩端，協商完成。NAS上的show interfaces Async4命令顯示「IPCP:開啟」。 |
| 21:35:07.490 | NAS的路由表中安裝了到遠端對等體的主機路由。 |
對等體可以同時協商多個第3層協定。例如，看到正在協商的IP和IPX並不罕見。一個協定也可能成功協商，而另一個協定則無法成功協商。
NCP故障排除
NCP協商期間發生的任何問題通常都可以追溯到協商對等體的配置。如果PPP協商在NCP階段失敗，請參閱以下步驟：
-
驗證介面協定配置
檢查特權exec命令show running-config的輸出。驗證介面是否配置為支援您希望通過連線運行的協定。
-
驗證介面位址
確認有問題的介面已配置地址。如果使用ip unnumbered [interface-name]或ipx ppp-client loopback [number]，請確保為引用的介面配置地址。
-
驗證客戶端地址可用性
如果NAS應該向呼叫者發出IP地址，請確保此地址可用。通過下列方法之一可以獲得要分配給呼叫者的IP地址：
-
在介面上本地配置。檢查命令peer default ip address a.b.c.d的介面配置。在實踐中，此方法只應用於接受來自單個呼叫方的連線的介面，例如非同步(非組非同步)介面。
-
在NAS上本地配置地址池。介面應使用peer default ip address pool [pool-name]命令。此外，必須在系統級別使用ip local pool [pool-name] [first-address] [last-address]命令定義池。池中定義的地址範圍應足夠大，以容納與NAS相同數量的同時連線的呼叫者。
-
DHCP伺服器。必須使用peer default ip address dhcp命令配置NAS介面。此外，必須使用ip dhcp-server [address]全域性配置命令將NAS配置為指向DHCP伺服器。
-
AAA。如果使用TACACS+或RADIUS進行授權，則可以將AAA伺服器配置為在每次呼叫者連線時向給定呼叫者傳遞特定IP地址。有關詳細資訊，請參閱第16章。
-
-
驗證伺服器地址配置
要返回域名伺服器或Windows NT伺服器的已配置地址以響應BOOTP請求，請確保配置了async-bootp dns-server [address]和async-bootp nbns-server [address]全域性級命令。
注意：雖然可以在NAS上配置async-bootp subnet-mask [mask]命令，但不會在NAS和PPP撥入客戶端PC之間協商子網掩碼。由於點對點連線的性質，客戶端自動使用NAS的IP地址（在IPCP協商期間獲知）作為預設網關。該點對點環境中不需要子網掩碼。PC知道，如果目的地址與本地地址不匹配，則應將資料包轉發到預設網關(NAS)，後者始終通過PPP鏈路到達。
致電思科系統TAC團隊之前
在致電思科系統技術支援中心(TAC)之前，請確保您已閱讀本章節，並完成針對系統問題所建議的動作。
此外，請執行以下操作並記錄結果，以便我們更好地為您提供幫助：
對於所有問題，收集show running-config和show version的輸出。確保配置中包含service timestamps debug datetime msec命令。
對於DDR問題，請收集以下資訊：
-
show dialer map
-
debug dialer
-
debug ppp negotiation
-
debug ppp authentication
如果涉及ISDN，請收集：
-
show isdn status
-
debug isdn q931
-
debug isdn events
如果涉及數據機，請收集：
-
顯示行
-
顯示行[x]
-
show modem（如果涉及整合數據機）
-
show modem version(如果涉及整合數據機)
-
debug modem
-
debug modem csm（如果涉及整合數據機）
-
調試聊天（如果是DDR場景）
如果涉及T1或PRI，請收集：
-
show controller t1
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
14-Sep-2005 |
初始版本 |
意見