拨号技术：故障排除技术

简介

拨号是代表终端用户运载数据公共交换电话网（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的然后8个PRI。最后引入了AS5800，以满足处理数十个流入T1和数百个用户连接所需的运营商级安装。

一些陈旧的技术负担在拨号技术历史讨论中被提及。56Kflex是由罗克韦尔建议的一个更旧的(pre-V.90) 56k调制解调器标准。虽然Cisco支持其内部调制解调器上的56Kflex标准的版本1.1，但建议您尽可能把CPE调制解调器转换成V.90。AS5100是另一种过时的技术。AS5100是思科与调制解调器制造商的合资企业。通过使用四元组调制解调器卡，将AS5100创建作为增加调制解调器密度的方式。它包含一个双T1卡和一组AS2511卡（插入到有四个调制解调器卡的底板中）。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备创建的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您是在真实网络上操作，请确保您在使用任何命令前已经了解其潜在影响。

规则

有关文件规则的更多信息请参见“ Cisco技术提示规则”。

排除来电故障

排除来电故障从底部开始，然后逐渐向上。推理的一般流程包括：

1. 我们看到电话到了吗？(是答案将进入下一个问题)

2. 接收方是否应答呼叫？

3. 购买权是否完成？

4. 数据是否通过链路？

5. 会话建立？（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。承载功能（通常称为bearecap）告知路由器传入的呼叫类型。在本例中，连接类型为0x8890。该值表示“ISDN速度64 Kb/s”。 如果bearcap为0x8090A2，则会显示“语音/语音呼叫u-law”。

如果设定信息没有收到，您应该通过手工呼叫检验编号是否正确（如果设置了语音）。您也应该检查ISDN接口的状态(请参考用于BRI故障排除的show isdn status命令)。 如果进行全面检查，确保呼叫始发者发出正确呼叫。这可以通过联系电话公司来完成。呼叫发起者可以跟踪呼叫，查看其发送位置。如果连接是长距离连接，请尝试使用1010长距离代码的其他长距离载波。

如果入呼叫是异步调制解调器呼叫，则确保线路的配置允许语音呼叫。

注意：BRI异步调制解调器呼叫是运行12.0(3)T或更高版本的3600路由器的一项功能。它需要BRI接口网络模块的最新硬件版本。WIC模块不支持异步调制解调器呼叫。

如果呼叫已经到达但还没有完成，寻找原因代码(参见表17-10)。连接确认表示成功完成。

如果这是异步调制解调器呼叫，请转至“传入调制解调器呼叫故障排除”部分。

此时，ISDN呼叫已连接，但未看到任何数据通过链路。使用debug ppp negotiate命令，查看是否有任何PPP数据流流经线路。如果您没有看到流量，则速度可能不匹配。确定是否是实际情形，使用show running-config特权执行命令，查看路由器配置。检查本地和远程路由器中的dialer map接口配置命令条目。这些条目应类似于以下内容：

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 命令最初出现在AS5200和AS5300的12.0(7)T中。早期版本的IOS使用系统级配置命令service internal和exec命令modem-debug rbs。在AS5800上调试此信息需要连接到中继卡本身。

首先，确定电话公司交换机是否“摘机”以发出来电信号。如果没有，请验证所呼叫的号码。将电话连接到始发端的电话线路，并呼叫号码，可以执行此操作。如果呼叫正确进入，则问题出在始发CPE。如果呼叫仍然没有出现在CAS上，使用debug serial interfaces命令检查此实例中的T1(第15章）。

以下显示使用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

要确保信令正常，请使用第16章中概述的show line命令。

除布线问题外，外部调制解调器需要初始化以自动应答。检查远程调制解调器，查看它是否设置为自动应答。通常，设置自动应答时，AA指示灯亮起。如果尚未设置远程调制解调器，请将其设置为自动应答。有关验证和更改调制解调器设置的信息，请参阅调制解调器文档。使用反向telnet初始化调制解调器（请参阅第16章）。

数字（集成）调制解调器呼叫代答

在外置调制解调器上，需要确定呼叫是否正被应答，但内部调制解调器要求手动呼叫接收编号。听取回音(ABT)。 如果您没有听到ABT，请检查以下两项配置：

1. 确保在处理传入调制解调器连接的任何ISDN接口下都存在isdn incoming-voice modem命令。

2. 在调制解调器的TTY的线路配置下，确保存在命令modem inout。

也有可能呼叫交换模块(CSM)没有分配内部调制解调器，来处理入呼叫。此问题可能由调制解调器或资源池配置的流入连接太少引起。这也可能意味着接入服务器可能已经没有调制解调器。检查调制解调器的可用性并适当调整调制解调器池或资源池管理器设置。如果分配了调制解调器，配置将显示调制解调器输入输出，收集调试，并联系Cisco寻求帮助。

调制解调器培训

如果接收调制解调器引起DSR，则培训成功。培训故障可能表示电路问题或调制解调器不兼容。

要彻底查出个别调制解调器问题的真相，当始发调制解调器与相关的POTS线路连接时, 查看始发调制解调器的AT提示。如果在Cisco接入服务器中呼叫数字调制解调器，请准备记录连接音乐或者数字缺损学习序列(DIL的) 的.wav文件。 DIL是一种乐谱(PCM顺序)，所产生的V.90模拟调制解调器将告诉接收数字调制解调器播放该乐谱。该序列使模拟调制解调器能够识别电路中的任何数字损害；例如多个D/A转换、法律/u-law、强盗位或数字焊盘。如果您听不到DIL，那么调制解调器就没有在V.8/V.8bis中 与V.90进行协商 (即是调制解调器兼容性问题)。 如果您监听到V.34中的DIL和重新连接，那么模拟调制解调器判断(根据DIL回放)该V.90是不可行的。

音乐里有噪音吗？如果是，请清理电路。

客户端是否会迅速放弃，而不运行V.34培训？例如，也许它不知道当它听到V.8bis时该做什么。在这种情况下，您应尝试在服务器上禁用V.8bis（因此是K56Flex）（如果可接受）。 您应该获得新的客户端固件或更换客户端调制解调器。或者，拨号端可以在拨号字符串的末尾插入五个逗号。这将延迟主叫调制解调器的监听，并导致接收服务器的V.8bis语音超时，而不影响客户端调制解调器。拨号字符串中的5个逗号是总指导大纲，并且需要进行调整，以适合本地情况。

会话建立

在序列中的此点，调制解调器已连接并接受培训。现在，是时候了解是否有流量正常通过了。

如果线路接收到的呼叫配有自动选择ppp，而异步接口配置为异步模式交互，则使用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来观察是否有任何配置请求数据包来自远端。调试显示这些为CONFREQ。如果观察入站和出站PPP数据包，请继续“排除PPP故障”。 否则，用字符模式(或"exec")会话(即非PPP会话)从呼叫发起端连接。

注意：如果接收端在异步接口下显示专用的异步调制解调器，则执行拨入仅显示看似随机ASCII垃圾的内容。要允许终端会话并仍具有PPP功能，请使用async接口配置命令async mode interactive。在关联线路的配置下，使用命令autoselect ppp。

调制解调器无法发送或接收数据

如果调制解调器与终端会话连接，而没有数据通过该连接，则检查以下可能原因和建议措施：

• 调制解调器速度设置未锁定

  1. 在访问服务器或路由器时使用show line执行命令。辅助端口的输出应该显示目前配置的Tx和Rx速度。

     欲知 how line命令的输出解释，请参见第15章的“使用调试命令”部分。

  2. 如果线路没有配置正确速度，使用speed line configuration命令，设置接入服务器或路由器线路上的线路速度。将调制解调器和接入服务器或路由器端口之间的共同值设置为最高速度。要设置终端波特率，请使用speed 线路配置命令。此命令设置发送（到终端）和接收（从终端）速度。

     语法:

     速度 bps

     语法说明:

     bps — 波特率(以位/秒(bps)为单位)。 默认值为9600 bps。

     以下示例把Cisco 2509接入服务器上的线路1和线路2设置为115200 bps：

     line 1 2
     speed 115200

     注意：如果由于某种原因，无法使用流量控制，请将线速限制为9600 bps。更快的速度可能导致数据丢失。

  3. 再次使用show line exec命令，确认线路速度已设置为所需值。

  4. 当您确定为接入服务器或路由器线路配置了期望的速度时，那么就通过该线路发起反向TELENT会话，连接到调制解调器。欲知更多信息，参见第16章的“建立到调制解调器的反向Telnet会话”。

  5. 使用调制解调器命令字符串，该字符串包含调制解调器的“lock DTE speed”命令。有关确切的配置命令语法，请参阅调制解调器文档。

  注意：lock DTE speed命令(也称为端口速率调整或缓冲模式)通常与调制解调器处理纠错的方式有关。此命令因调制解调器而异。

  锁定调制解调器速度保证调制解调器总是以Cisco辅助端口配置的速度与Cisco接入服务器或路由器进行通信。如果没有使用此命令，调制解调器将恢复到数据链路(电话线)速度，而不是以接入服务器上配置的速度进行通信。

• 本地或远程调制解调器或路由器上未配置硬件流量控制

  1. 使用show line aux-line-number exec命令，并在Capabilities字段中查找以下内容：

     Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out

     有关详细信息，请参阅第16章中的解释Show Line Output。

     如果此字段中没有提及硬件流控制，硬件流控制则不会在线路上启用。建议对接入服务器到调制解调器连接进行硬件流控制。

     欲知 how line命令的输出解释，请参见第15章的“使用调试命令”部分。

  2. 使用flowcontrol硬件线路配置命令在线路上配置硬件流控制。

     要在终端设备之间或其他串行设备与路由器之间设置数据流控制方法，使用flowcontrol line configuration命令。使用此命令的no形式可禁用流量控制。

     语法:

     flowcontrol {none |软件[锁定] [in |输出] |硬件[in |out]}

     语法说明:

     • none — 关闭流控制。

     • software — 设置软件流控制。可选关键字指定方向：流入导致Cisco IOS软件能接听来自连接设备的流控制，流出导致该软件发送流控制信息到连接的设备上。如果不指定方向，则假定两者都是。

     • lock---连接设备需要软件流控制时，不可能从远端主机关闭流控制。此选项适用于使用Telnet或rlogin协议的连接。

     • hardware — 设置硬件流控制。可选关键字指定方向：流入导致软件能接听来自连接设备的流控制，流出导致该软件发送流控制信息到连接的设备上。如果不指定方向，则假定两者都是。欲知硬件流控制的更多信息，请参见与路由器一起运送的“硬件指南”。

     示例：

     以下示例在7行上设置硬件流控制：

     line 7
     flowcontrol hardware

     注意：如果由于某种原因无法使用流量控制，请将线路速度限制为9600 bps。更快的速度可能导致数据丢失。

  3. 启用接入服务器或路由器线路上的硬件流控制以后，通过该线路，启动到调制解调器的反向Telnet会话。欲知更多信息，参见第16章的“建立到调制解调器的反向Telnet会话”。

  4. 对调制解调器使用包含RTS/CTS Flow命令的调制解调器命令字符串。此命令可以保证调制解调器正在使用与Cisco接入服务器或路由器相同的流控制方法(即硬件流控制)。有关确切的配置命令语法，请参阅调制解调器文档。

• 拨号器映射命令配置错误

  1. 使用show running-config特权执行命令查看路由器配置。检查dialer map命令条目，查看是否指定了broadcast关键字。

  2. 如果缺少关键字，请将其添加到配置。

     语法:

     拨号器映射协议下一跳地址[名称主机名] [广播] [拨号字符串]

     语法说明:

     • protocol — 要映射的协议。选项包括IP、IPX、网桥和快照。

     • next-hop-address — 对方站点异步接口的协议地址。

     • name hostname - PPP身份验证中使用的必需参数。它是为其创建拨号器映射的远程站点的名称。名称区分大小写，并且必须与远程路由器的主机名匹配。

     • 广播—— 一个可选关键字，广播发往远程目的地的信息包（(例如，IP RIP或IPX RIP/SAP更新信息包）。在静态路由示例配置中，不需要路由更新，并省略了broadcast关键字。

     • dial-string — 远程站点的电话号码。必须包括所有接入号(例如，办公室以外拨按9、国际电话代码、区域代码)。

  3. 确保dialer map命令指定正确的下一跳地址。

  4. 如果下一跳地址不正确，请使用dialer map命令更改它。

  5. 确定dialer map命令中的其它所有选项都能正确地使用于您正在使用的协议。

  有关配置拨号器映射的详细信息，请参阅《Cisco IOS广域网配置指南》和《广域网命令参考》。

• 拨号调制解调器问题

  • 确保拨号调制解调器可以操作，可以安全连接到正确端口。确定另一调制解调器在连接到同一端口时是否工作。

调试传入的EXEC会话通常属于以下几个主要类别：

• 拨号客户端收到No exec提示

• 拨号会话看到“垃圾”

• 拨号会话在现有会话中打开

• 拨号接收调制解调器未正确断开

拨号客户端收到No EXEC提示

• 在行上启用自动选择

  按Enter键尝试访问EXEC模式。

• 线路使用no exec命令配置

  1. 使用show line exec命令查看相应线路的状态。

     检查Capabilities字段，查看其是否显示“exec despred”。 如果出现这种情况，则启用no exec线路配置命令。

  2. 在线路上配置exec线路配置命令，以允许启动exec会话。此指令没有自变量或关键字。

  以下示例打开第7行执行：

  line 7 
  exec

• 未启用流控制。

  或

  仅在一台设备（DTE或DCE）上启用流量控制。

  或

  流量控制配置错误。

  1. 使用show line aux-line-number exec命令，并在Capabilities字段中查找以下内容：

     Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
     

     有关详细信息，请参阅第16章中的解释Show Line Output。

     如果此字段中没有提及硬件流控制，硬件流控制则不会在线路上启用。建议对接入服务器到调制解调器连接进行硬件流控制。

     欲知 how line命令的输出解释，请参见第15章的“使用调试命令”部分。

  2. 使用flowcontrol硬件线路配置命令在线路上配置硬件流控制。以下示例在7行上设置硬件流控制：

     line 7
     flowcontrol hardware

     注意：如果由于某种原因无法使用流量控制，请将线路速度限制为9600 bps。更快的速度可能导致数据丢失。

  3. 启用接入服务器或路由器线路上的硬件流控制以后，通过该线路，启动到调制解调器的反向Telnet会话。欲知更多信息，参见第16章的“建立到调制解调器的反向Telnet会话”。

  4. 为调制解调器使用包含RTS/CTS Flow命令的调制解调器命令字符串。此命令可以保证调制解调器正在使用与Cisco接入服务器或路由器相同的流控制方法(即硬件流控制)。有关确切的配置命令语法，请参阅调制解调器文档。

• 调制解调器速度设置未锁定

  1. 在访问服务器或路由器时使用show line执行命令。辅助端口的输出应该显示目前配置的Tx和Rx速度。

     欲知 how line命令的输出解释，请参见第15章的“使用调试命令”部分。

  2. 如果线路没有配置正确速度，使用speed line configuration命令，设置接入服务器或路由器线路上的线路速度。将调制解调器和接入服务器或路由器端口之间的共同值设置为最高速度。要设置终端波特率，请使用speed line configuration命令。此命令设置发送（到终端）和接收（从终端）速度。

     语法:

     速度 bps

     语法说明:

     bps — 波特率(以位/秒(bps)为单位)。 默认值为9600 bps。

     示例：

     以下示例把Cisco 2509接入服务器上的线路1和线路2设置为115200 bps：

     line 1 2
     speed 115200

     注意：如果由于某种原因无法使用流量控制，请将线路速度限制为9600 bps。更快的速度可能导致数据丢失。

  3. 再次使用show line exec命令，确认线路速度已设置为所需值。

  4. 当您确定为接入服务器或路由器线路配置了期望的速度时，那么就通过该线路发起反向TELENT会话，连接到调制解调器。欲知更多信息，参见第16章的“建立到调制解调器的反向Telnet会话”。

  5. 为调制解调器使用包含lock DTE speed命令的调制解调器命令字符串。有关确切的配置命令语法，请参阅调制解调器文档。

  注： lock DTE speed命令（也称为端口速率调整或缓冲模式）通常与调制解调器处理纠错的方式有关。此命令因调制解调器而异。

  锁定调制解调器速度保证调制解调器总是以Cisco辅助端口配置的速度与Cisco接入服务器或路由器进行通信。如果没有使用此命令，调制解调器将恢复到数据链路(电话线)速度，而不是以接入服务器上配置的速度进行通信。

拨号会话看到“垃圾”

• 调制解调器速度设置未锁定

  1. 在访问服务器或路由器时使用show line执行命令。辅助端口的输出应该显示目前配置的Tx和Rx速度。

     欲知 how line命令的输出解释，请参见第15章的“使用调试命令”部分。

  2. 如果线路没有配置正确速度，使用speed line configuration命令，设置接入服务器或路由器线路上的线路速度。将调制解调器和接入服务器或路由器端口之间的共同值设置为最高速度。

     要设置终端波特率，请使用speed 线路配置命令。此命令设置发送（到终端）和接收（从终端）速度。

     语法:

     速度bps

     语法说明:

     bps波特率(以位/秒(bps)为单位)。 默认值为9600 bps。

     示例：

     以下示例把Cisco 2509接入服务器上的线路1和线路2设置为115200 bps：

     线路1 2

     speed 115200

     注意：如果由于某种原因无法使用流量控制，请将线路速度限制为9600 bps。更快的速度可能导致数据丢失。

  3. 再次使用show line exec命令，确认线路速度已设置为所需值。

  4. 当您确定为接入服务器或路由器线路配置了期望的速度时，那么就通过该线路发起反向TELENT会话，连接到调制解调器。欲知更多信息，参见第16章的“建立到调制解调器的反向Telnet会话”。

  5. 为调制解调器使用包含lock DTE speed命令的调制解调器命令字符串。有关确切的配置命令语法，请参阅调制解调器文档。

  注： lock DTE speed命令（也称为端口速率调整或缓冲模式）通常与调制解调器处理纠错的方式有关。此命令因调制解调器而异。

  锁定调制解调器速度保证调制解调器总是以Cisco辅助端口配置的速度与Cisco接入服务器或路由器进行通信。如果没有使用此命令，调制解调器将恢复到数据链路(电话线)速度，而不是以接入服务器上配置的速度进行通信。

症状:远程拨入会话在另一用户启动的已存在会话中打开。也就是，拨入用户没有得到登录提示，而是看到另一个用户建立的会话（可能是unix命令提示、文本编辑器会话，等等)。

拨号会话在现有会话中打开

• 为DCD配置的调制解调器始终高

  1. 调制解调器应重新配置为仅在CD上使DCD高。此操作的完成通常通过使用&C1调制解调器命令串，但需要检查您的调制解调器文档是否具您的调制解调器的确切句法。

  2. 您也许必须使用no exec line configuration命令，配置调制解调器连接的接入服务器线路。用clear line privileged exec命令清除线路，用调制解调器起动反向Telnet会话，并且重新配置调制解调器以使DCD仅在CD上为高水平。

  3. 通过输入disconnect结束Telnet会话，并使用exec线路配置命令重新配置接入服务器线路

• 接入服务器或路由器上未启用调制解调器控制

  1. 在访问服务器或路由器时使用show line执行命令。辅助端口的输出应在“调制解调器”列中显示inout或RIisCD。这表明调制解调器控制在接入服务器或路由器的线路上启用。

     有关show line命令输出的解释，参见第15章的“使用调试命令”部分。

  2. 使用modem inout line配置命令配置用于调制解调器控制的线路。调制解调器控制现在在接入服务器上启用。

  注意：在调制解调器的连接出现问题时，请务必使用modem inout命令而不是modem dialin命令。后一个命令允许线路仅响应呼入呼叫。去话将被拒绝，使之不可能建立与调制解调器的Telnet会话，以便进行配置。如果想要启用modem dialin命令，只能在您确定调制解调器正确运行之后方可执行。

• 布线不正确

  1. 检查调制解调器与接入服务器或路由器之间的电缆连接。确认调制解调器通过一个卷起的RJ-45电缆和MMOD DB-25适配器连接到接入服务器上的辅助端口。此电缆配置由Cisco为RJ-45端口建议使用并且支持。这些连接器通常标有：调制解调器。

     RJ-45电缆有两种类型：直滚。如果您并排地握住RJ-45电缆的两端，您会在每端看到八个颜色的条纹或管脚。如果彩色引脚的顺序在每个末端都相同，则电缆是平直的。如果颜色的顺序在每个末端相反，电缆将卷起。

     反转电缆(CAB-500RJ)是思科2500/CS500的标准电缆。

  2. 使用show line执行命令验证布线是正确的。请参见第15章中的“使用调试命令”部分中的“show line命令解释”

拨号接收调制解调器未正确断开

• 调制解调器未感知DTR

  输入挂机DTR调制解调器命令字符串。当DTR信号不再被接收时，此命令将告知调制解调器丢弃载波。

  在贺氏公司兼容的调制解调器上，&D3字符串通常用于配置调制解调器上的Hangup DTR。有关此命令的确切语法，请参阅调制解调器文档。

• 路由器或接入服务器上未启用调制解调器控制

  1. 在访问服务器或路由器时使用show line执行命令。辅助端口的输出应在“调制解调器”列中显示inout或RIisCD。这表明调制解调器控制在接入服务器或路由器的线路上启用。

     有关show line命令输出的解释，参见第15章的“使用调试命令”部分。

  2. 使用modem inout line configuration命令配置调制解调器控制线路。调制解调器控制现在在接入服务器上启用。

  注意：在调制解调器的连接出现问题时，请务必使用modem inout命令而不是modem dialin命令。后一个命令允许线路仅响应呼入呼叫。去话将被拒绝，使之不可能建立与调制解调器的Telnet会话，以便进行配置。如果想要启用modem dialin命令，只能在您确定调制解调器正确运行之后方可执行。

出站呼叫故障排除

来电的故障排除方法从底部开始，而排除出站连接故障则从顶部开始。推理的一般流程包括：

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. 使用show running-config命令，确保接口配置了dialer-group，而且还配置了一个带有匹配号码的全局dialer-list 。

  2. 保证配置dialer-list命令来允许整个协议，或者允许流量匹配访问控制列表。

  3. 验证access-list是否声明通过链路的数据包为相关数据包。一个有用的测试就是使用特权执行命令 debug ip packet [list number] ，利用相关访问控制列表。然后尝试ping通链路或以其他方式发送流量。如果触发数据流过滤器被正确定义，在调试输出上您将看到信息包。如果在此测试中没有调试输出，那么访问控制列表和信息包就不匹配。

• 接口状态

  使用命令show interfaces [interface name]确保接口处于“up/up(spoofing)”状态。

  • 接口处于“备用”模式

    在路由器配置另一个(主)接口，以便把拨号程序接口用作备份接口。此外，主要接口不在“down/down”状态时，要求建立非备用模式的拨号程序接口。并且，备份延迟必须配在主要接口上，否则backup interface命令绝不会强制执行。

    要检查拨号程序接口是否将从“备用”变成“up/up (spoofing)”，从主要接口拉出电缆通常是必要的。简单关闭带有shutdown配置命令的主要接口，不会把主要接口放入“down/down”状态，而是把它放入与“down/down”状态不同的“administratively down”状态。

    此外，如果主要连接是通过帧中继进行的，则必须在点对点串行子接口上执行帧中继配置，并且电话公司必须通过“活动”位。这种做法也称为“端到端LMI”。

  • 接口为“administratively down”

    拨号器接口已使用命令shutdown进行配置。Cisco路由器首次被引导时，这也是所有接口的默认状态。使用接口配置命令no shutdown消除此障碍。

• 路由不正确

  发出exec命令show ip route [a.b.c.d]，其中a.b.c.d是远程路由器拨号器接口的地址。如果未编号的IP用在远程路由器上，使用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

如果查明了拨号原因，但没有进行拨号，通常原因是误配置了dialer map 或dialer profile。

未拨打呼叫

下面列出了一些可能的问题和建议的操作：

• 拨号器映射配置错误

  用show running-config命令确保拨号接口使用至少一个拨号映射语句进行配置，该语句指向协议地址和远程站点的被叫号码。

• 拨号程序配置文件配置错误

  使用命令show running-config确保拨号程序接口配置了dialer pool X命令，并且路由器上的拨号程序接口配置了匹配的dialer pool-member X。如果拨号程序配置文件未正确配置，您可能会看到如下调试消息：

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

  确保配置了拨号器字符串。

异步出站呼叫 — 验证聊天脚本操作

如果呼出是调制解调器呼叫，则必须执行对话脚本，以便进行呼叫。对于基于拨号器映射的DDR，聊天脚本由dialer map命令中的modem-script参数调用。如果DDR是基于dialer profile的，则使用TTY线路上配置的script dialer命令，完成此操作。这两种方法都依赖于路由器全局配置中现有的聊天脚本，例如：

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

在任一情况下，查看聊天脚本活动的命令都是debug chat。如果用于dialer map或dialer string命令中的拨号串(即电话号码)是5551212 ，dubug输出将是以下这样：

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）。

• 应为超时：连接

  • 可能性1:本地调制解调器实际上没有发出呼叫。检验调制解调器是否能够通过执行反向远程登录到调制解调器和手工拨号，来发出呼叫。

  • 可能性2:远程调制解调器未应答。使用普通POTS电话拨打远程调制解调器来测试此功能。

  • 可能性3:正在拨打的号码不正确。手动拨号以验证号码。如有必要，请更正配置。

  • 可能性4:调制解调器培训过长或TIMEOUT值过低。如果本地调制解调器是外置调制解调器，需调大调制解调器的扬声器音量，并监听trainup提示音。如果突然中断了培训，请尝试在chat-script命令中增加TIMEOUT值。如果TIMEOUT已经超过60秒，请参阅调制解调器培训部分。

ISDN出站呼叫

当一怀疑ISDN出现故障的时候，BRI或PRI就会不断检查show isdn status的输出。需要特别注意的是第一层应该激活，第二层应该处在MULTIPLE_FRAME_ESTABLISHED状态。欲知此输出的阅读和纠正措施的信息，请参见第16章的 “显示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

原因代码字段

表17-9列出了ISDN原因代码字段，该字段将显示为debug命令内部的以下格式：

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断开原因代码。

十六进制值	原因	解释
81	未指定（未分配）号码	ISDN号码以正确的格式发送到交换机；但是，编号未分配给任何目的设备。
90	正常呼叫清除	正常呼叫清除已发生。
91	用户忙	因为所有B信道正在使用，呼叫系统承认连接请求，但无法接受呼叫。
92	无用户应答	因为目的地不回应呼叫，所以连接不可能完成。
93	用户无应答（用户已告警）	目的地回应连接请求，但在规定时间内不能完成连接。问题在于远端连接。
95	呼叫被拒绝	目的地能够接受呼叫，但不知何故拒绝呼叫。
9C	号码格式无效	连接没有建立，可能是因为目的地地址显示为无法识别的格式，或者是因为目的地地址不完整。
9F	正常，不明	报告未应用标准原因时正常事件的发生情况。无所需操作
A2	无可用线路/信道	因为适当信道都不可用于接收呼叫，因此连接不可能建立。
A6	网络无序	目的地不可能到达，是因为网络不正确运行，并且不正确运行这种情况也许持续更长的时间。立即重新连接尝试可能会失败。
交流	没有请求的线路/信道	远程设备由于未知原因无法提供请求的信道。这可能是暂时的问题。
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协商故障之前，了解成功的debug ppp顺序的情况。使用这种方式，比较有故障的PPP调试会话和成功完成的debug 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	传入配置请求(I CONFREQ)。 客户端要协商回叫协议。
10:57:16.919	传出配置拒绝(O CONFREJ)。 NAS拒绝回叫选项。
10:57:17.047	传入配置请求(I 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)的状态为打开。一条路由被协商和安装，为了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

这种情况可能需要致电思科TAC。在呼叫TAC之前，从两个对等体收集以下输出：

• show running-config

• show version

• debug isdn q931

• debug isdn events

• debug ppp negotiation

身份验证

身份验证失败是导致PPP失败的最常见原因。用户名和密码配置错误或不匹配会在调试输出中产生错误消息。

以下示例显示用户名Goleta没有权限拨入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

以下示例显示用户名“Goleta”在NAS上配置。但是，密码比较失败。要解决此问题，使用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向对等体发送一个传出PPP配置请求数据包，其中包含其IP地址。
21:35:04.282	传入CONFREQ。对等体请求执行VJ报头压缩。它需要IP地址，以及主DNS服务器和辅助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阶段失败，请参阅以下步骤：

1. 检验接口协议配置

   检查特权执行命令show running-config的输出。验证接口的配置是否支持您希望在连接上运行的协议。

2. 检验接口地址

   确认相关接口已配置地址。如果使用ip unnumbered [interface-name] 或ipx ppp-client loopback [number]，则要保证参考接口配置有某个地址。

3. 验证客户端地址可用性

   如果假设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接口。此外，必须配置NAS指向带有ip dhcp-server[address]全局配置命令的DHCP服务器。

   • AAA.如果使用TACACS+或RADIUS授权，可以配置AAA服务器，来为每次呼叫连接时的指定呼叫方占用一个特定IP地址。有关详细信息，请参阅第16章。

4. 验证服务器地址配置

   返回域名服务器或Windows NT服务器的配置地址以回应BOOTP请求，保证配置global-level命令、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团队之前

呼叫Cisco系统技术支持中心(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

如果涉及调制解调器，请收集：

• show lines

• show line [x]

• show modem（如果涉及集成调制解调器）

• show modem version(如果涉及集成调制解调器)

• debug modem

• debug modem csm（如果涉及集成调制解调器）

• debug chat（如果是DDR场景）

如果涉及T1或PRI，请收集：

• show controller t1

相关信息

• T1/E1故障排除页
• Cisco IOS拨号解决方案指南
• 监控和维护T1/E1接口
• 排除PPP协商故障
• 调制解调器故障排除
• 调制解调器调试命令
• 排除ISDN故障
• T1 PRI 故障排除
• 技术支持和文档 - Cisco Systems