拨号技术连接 - IOS DDR 发起呼叫故障排除

下载选项

PDF (369.7 KB)
在各种设备上使用 Adobe Reader 查看
ePub (89.3 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (97.5 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2007 年 7 月 9 日

文档 ID:14954

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

本文提供拨号连接的不同类型故障排除方法因此没有必要自始至终阅读。文章的结构被设计为允许读者直接跳到感兴趣的部分阅读，其中每一个都是是整体故障排除主题的一个特定的案件。

先决条件

要求

本文包括三个主要方案;在开始排除故障之前，请确定尝试的呼叫类型并转至该部分：

卡林
思科IOS按需拨号路由(DDR)
非 DDR 呼出

使用的组件

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

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

历史记录

拨号是代表终端用户运载数据公共交换电话网（PSTN）的应用。它包括客户终端设备(CPE)，该设备将向电话交换机发送电话号码，进行连接。AS3600、AS5200、AS5300和AS5800都是能够运行主速率接口(PRI)和数字调制解调器组的路由器的示例。AS2511，另一方面，是与外部调制解调器联络路由器的示例。

运营商市场显著增长，并且市场当前需求更高的调制解调器密度。满足此需求的答案是更高的互操作程度，以及电话公司设备和数字调制解调器的发展。这是有能力对PSTN的直接数字访问上的调制解调器。结果是，利用数字调制解调器享受的信号清晰度，现在已经开发更快速的CPE调制解调器。通过PRI或基本速率接口(BRI)连接到PSTN的数字调制解调器可以使用V.90通信标准以53k以上的速率传输数据，这一事实证明了该思想的成功。

第一个接入服务器是AS2509和AS2511。AS2509可支持8个使用外部调制解调器的传入连接，AS2511可支持16个。AS5200引入了2个PRI，可支持48个用户使用数字调制解调器，这代表着技术的重大飞跃。调制解调器密度稳步增加了与AS5300支持4的然后8个PRI。最后引入了AS5800，以满足处理数十个流入T1和数百个用户连接所需的运营商级安装。

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

规则

有关文档规则的详细信息，请参阅 Cisco 技术提示规则。

Cisco IOS DDR 发起呼叫

来电的故障排除方法从底部开始，而排除出站连接故障则从顶部开始。

一般推理流程如下：

按需拨号路由(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)

如果数据流不能触发拨号，那么最常见的原因就是配置不正确(或者是触发数据流定义、或者拨号程序接口状态或者路由配置不对)。

表 1：流量不会发起拨号尝试

可能的原因	建议的行动
缺少或不正确的“相关流量”定义	使用show running-config命令，确保接口配置了dialer-group，而且还配置了一个带有匹配号码的全局dialer-list 。保证配置dialer-list命令来允许整个协议，或者允许流量匹配访问控制列表。验证访问列表是否声明通过链路的数据包是相关的。一个有用的测试就是使用特权执行命令 debug ip packet [list number] ，利用相关访问控制列表。然后尝试ping通链路或以其他方式发送流量。如果触发数据流过滤器被正确定义，在调试输出上您将看到信息包。如果此测试没有调试输出，则访问列表与数据包不匹配。
接口状态	使用命令show interfaces <interface name>确保接口处于“up/up(spoofing)”状态。
接口处于“备用”模式	在路由器配置另一个(主)接口，以便把拨号程序接口用作备份接口。此外，主要接口不在“down/down”状态时，要求建立非备用模式的拨号程序接口。并且，备份延迟必须配在主要接口上，否则backup interface命令绝不会强制执行。要检查拨号器接口是否将从“standby”更改为“up/up(spoofing)”，通常需要从主接口拉出电缆。仅使用配置命令shutdown关闭主接口不会将主接口置于“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。

表 2：未拨打呼叫

可能的问题	建议的操作
拨号器映射配置错误	使用命令show running-config确保拨号接口配置了至少一条指向远程站点的协议地址和被叫号码的拨号程序映射语句。
拨号程序配置文件配置错误	使用命令show running-config确保拨号程序接口配置了dialer pool X命令，并且路由器上的拨号程序接口配置了匹配的拨号程序池成员X。如果拨号程序配置文件未正确配置，您可能会看到调试消息，如： Dialer1: Can't place call, no dialer pool set 确保配置了拨号器字符串。

接下来，确定所使用的介质类型：

外部异步调制解调器 DDR
信道关联信令(CAS)T1/E1异步调制解调器DDR
PRI 异步调制解调器 DDR
BRI 异步调制解调器 DDR
PRI ISDN DDR
BRI ISDN DDR

外部异步调制解调器 DDR

要识别外部异步调制解调器DDR，请使用以下命令，然后尝试进行呼叫：
```
router# debug modem
router# debug chat line  
         
```
对于调制解调器呼叫，必须执行聊天脚本才能继续呼叫。对于基于拨号器映射的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
```
确保聊天脚本根据“发送字符串”尝试预期呼叫（即正确的号码）。如果聊天脚本未尝试进行预期呼叫，请验证聊天脚本的配置。在执行提示符下使用start-chat命令手动启动聊天脚本。
看到“超时预期：CONNECT”可以描述几种不同的可能性：
- 可能性1:本地调制解调器实际上没有发出呼叫。检验调制解调器是否能够通过执行反向远程登录到调制解调器和手工拨号，来发出呼叫。如果远程终端似乎没有应答，请使用命令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至异步调制解调器并调试。
如果一切正常，但您仍无法连接CAS异步调制解调器DDR，请尝试PPP调试。使用以下命令：
```
router# debug ppp negotiation
     router# debug ppp authentication
```
如果聊天脚本成功完成，则调制解调器已连接。有关连接故障排除的下一步，请参阅《网际网络故障排除指南》第17章中的“PPP故障排除”部分。

CAS T1/E1 异步调制解调器 DDR

要识别CAS T1/E1异步调制解调器DDR，请使用以下命令，然后尝试进行呼叫：

警告： 在繁忙系统上运行调试可能会通过使CPU过载或控制台缓冲区超载导致路由器崩溃！
```
router# debug modem
router# debug chat or debug chat line n

router# debug modem csm
router# debug cas
```
注意：在运行Cisco IOS的Cisco AS5200和AS5300平台上，debug cas命令可用？软件版本12.0(7)T及更高版本。在以前的IOS版本中，internal命令必须输入到路由器配置的主级，并且modem-mgmt csm debug-rbs需要在执行提示符下输入。在Cisco AS5800上进行调试需要连接到中继卡。(使用modem-mgmt csm no-debug-rbs关闭调试。)
对于调制解调器呼叫，必须执行聊天脚本才能继续呼叫。对于基于拨号器映射的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
```
确保聊天脚本根据“发送字符串”尝试预期呼叫（即正确的号码）。如果聊天脚本未尝试进行预期呼叫，请验证聊天脚本的配置。在执行提示符下使用start-chat命令手动启动聊天脚本。
看到“超时预期：CONNECT”可以描述几种不同的可能性：
- 可能性1:本地调制解调器实际上没有发出呼叫。检验调制解调器是否能够通过执行反向远程登录到调制解调器和手工拨号，来发出呼叫。如果远程终端似乎没有应答，请使用命令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:
  
  打开调试：
```
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#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提示符。如果可能，使用reverse telnet也可以进入接收调制解调器的AT提示符。使用ATM1让调制解调器向扬声器发送声音，以便两端的人都能听到线路上发生的情况。
  
  音乐里有噪音吗？如果是，请清理电路。如果异步调制解调器未进行培训，请呼叫该号码并侦听静态。可能有其他因素干涉训练。反向telnet到异步调制解调器并调试。
如果一切正常，但您仍无法连接CAS异步调制解调器DDR，请尝试PPP调试。如果聊天脚本成功完成，且PPP调试指示出现故障，请参阅《网际网络故障排除指南》第17章的“PPP故障排除”部分。

PRI 异步调制解调器 DDR

要识别PRI异步调制解调器DDR，请使用以下命令，然后尝试进行呼叫：

警告： 在繁忙系统上运行调试可能会通过使CPU过载或控制台缓冲区超载导致路由器崩溃！
```
router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug isdn
router# debug ppp negotiate
router# debug ppp authenticate
```
对于调制解调器呼叫，必须执行聊天脚本才能继续呼叫。对于基于拨号器映射的DDR，聊天脚本由dialer map命令中的modem-script参数调用。如果DDR是基于dialer profile的，则使用TTY线路上配置的script dialer命令，完成此操作。这两种方法都依赖于路由器全局配置中现有的聊天脚本，例如：
```
chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
```
在任一情况下，查看聊天脚本活动的命令都是debug chat。如果拨号器映射或拨号器字符串命令中使用的拨号字符串(电话号码)是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
```
确保聊天脚本根据“发送字符串”尝试预期呼叫（正确的号码）。如果聊天脚本未尝试进行预期呼叫，请验证聊天脚本的配置。在执行提示符下使用start-chat命令手动启动聊天脚本。
看到“超时预期：CONNECT”可以描述几种不同的可能性：
- 可能性1:本地调制解调器实际上没有发出呼叫。检验调制解调器是否能够通过执行反向远程登录到调制解调器和手工拨号，来发出呼叫。如果远程终端似乎没有应答，请使用命令ATDT<number>手动呼叫本地号码并侦听振铃，以验证调制解调器是否正在进行呼叫。如果没有呼出，请打开ISDN调试。在BRI上首次怀疑ISDN故障时，请始终检查show isdn status的输出。需要特别注意的是第一层应该激活，第二层应该处在MULTIPLE_FRAME_ESTABLISHED状态。有关读取此输出的信息，请参阅网际网络故障排除指南第16章“解释 Show ISDN状态”，以及纠正措施。
  
  对于出站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提示符。如果可能，使用reverse telnet也可以进入接收调制解调器的AT提示符。使用ATM1让调制解调器向扬声器发送声音，以便两端的人都能听到线路上发生的情况。
  
  音乐里有噪音吗？如果是，请清理电路。如果异步调制解调器未进行培训，请呼叫该号码并侦听静态。可能有其他因素干涉训练。反向telnet到异步调制解调器并调试。
如果一切正常，但您仍无法连接BRI异步调制解调器DDR，请尝试PPP调试。如果聊天脚本成功完成，且PPP调试指示出现故障，请参阅《网际网络故障排除指南》第17章的“PPP故障排除”部分。

BRI 异步调制解调器 DDR

此功能只用于在Cisco 3640平台上的Cisco IOS软件版本12.0(3)T及以后版本。它需要BRI网络模块的更新硬件版本。这不适用于广域网接口卡(WIC)。

使用show modem命令确保国家/地区代码正确。使用以下命令，然后尝试进行呼叫：

警告： 在繁忙系统上运行调试可能会通过使CPU过载或控制台缓冲区超载导致路由器崩溃！
```
router# debug modem
router# debug chat
router# debug modem csm
router# debug isdn q931
router# debug bri
router# debug ppp negotiate
router# debug ppp authenticate
```
对于调制解调器呼叫，必须执行聊天脚本才能继续呼叫。对于基于拨号器映射的DDR，聊天脚本由dialer map命令中的modem-script参数调用。如果DDR是基于dialer profile的，则使用TTY线路上配置的script dialer命令，完成此操作。这两种方法都依赖于路由器全局配置中现有的聊天脚本，例如：
```
chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
```
在任一情况下，查看聊天脚本活动的命令都是debug chat。如果拨号器映射或拨号器字符串命令中使用的拨号字符串(电话号码)是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
```
确保聊天脚本根据“发送字符串”尝试预期呼叫（正确的号码）。如果聊天脚本未尝试进行预期呼叫，请验证聊天脚本的配置。在执行提示符下使用start-chat命令手动启动聊天脚本。
看到“超时预期：CONNECT”可以描述几种不同的可能性：
- 可能性1:本地调制解调器实际上没有发出呼叫。检验调制解调器是否能够通过执行反向远程登录到调制解调器和手工拨号，来发出呼叫。如果远程终端似乎没有应答，请使用命令ATDT<number>手动呼叫本地号码并侦听振铃，以验证调制解调器是否正在进行呼叫。如果没有呼出，请打开ISDN调试。在BRI上首次怀疑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
```
  请注意，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提示符。如果可能，使用reverse telnet也可以进入接收调制解调器的AT提示符。使用ATM1让调制解调器向扬声器发送声音，以便两端的人都能听到线路上发生的情况。
  
  音乐里有噪音吗？如果是，请清理电路。如果异步调制解调器未进行培训，请呼叫该号码并侦听静态。可能有其他因素干涉训练。反向telnet到异步调制解调器并调试。
如果一切正常，但您仍无法连接BRI异步调制解调器DDR，请尝试PPP调试。如果聊天脚本成功完成，且PPP调试指示出现故障，请参阅《网际网络故障排除指南》第17章的“PPP故障排除”部分。

PRI ISDN DDR

在PRI上首次怀疑ISDN故障时，请始终检查show isdn status的输出。需要特别注意的是第一层应该激活，第二层应该处在MULTIPLE_FRAME_ESTABLISHED状态。有关阅读此输出和纠正措施的信息，请参阅网际网络故障排除指南第16章“解释Show ISDN状态”。

对于出站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。
如果看到ISDN CONNECT消息，并且PPP调试指示出故障，请参阅《网际网络故障排除指南》第17章的“PPP故障排除”部分。

BRI ISDN DDR

在BRI上首次怀疑ISDN故障时，请始终检查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
```
请注意，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。
如果看到ISDN CONNECT消息，并且PPP调试指示出故障，请参阅《网际网络故障排除指南》第17章的“PPP故障排除”部分。