拨号和接入 : 按需拨号路由 (DDR)

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

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 22 日) | 反馈


目录


简介

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

先决条件

要求

本文包括三个主要方案;在您开始排除故障前,请确定什么类型的呼叫尝试并且去该部分:

使用的组件

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

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

历史记录

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

运营商市场显著增长,并且市场当前需求更高的调制解调器密度。满足此需求的答案是更高的互操作程度,以及电话公司设备和数字调制解调器的发展。这是有能力对PSTN的直接数字访问上的调制解调器。结果是,利用数字调制解调器享受的信号清晰度,现在已经开发更快速的CPE调制解调器。事实使用V.90通信标准,数字调制解调器连接到PSTN的通过PRI或基本速率接口(BRI)能传送数据在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是在Cisco和调制解调器制造商之间的一家合资企业。通过使用四元组调制解调器卡,将AS5100创建作为增加调制解调器密度的方式。它包含一个双T1卡和一组AS2511卡(插入到有四个调制解调器卡的底板中)。

规则

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

Cisco IOS DDR 发起呼叫

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

推理一般流类似于以下:

  1. 按需拨号路由(DDR)是否发起呼叫?(A是答案提前到下一个问题。)

  2. 如果这是异步调制解调器,对话脚本是否发出预计命令?

  3. 呼叫是否使它到PSTN ?

  4. 远程终端是否应答呼叫?

  5. 购买权是否完成?

  6. 数据通过在链路?

  7. 会话建立?(PPP或终端)

要看到拨号程序是否尝试做呼叫到其远程目的地,请使用debug dialer events命令。详细信息可以从debug dialer packet得,但是debug dialer packet命令资源加强,并且不应该使用在有多个拨号接口操作的繁忙的系统。

以下为IP信息包的debug dialer events的输出,它列出了DDR接口的名称和信息包的起源和目的地址:

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

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

表 1:流量不启动拨号尝试

可能的原因 建议的行动
缺失或不正确的“关注数据流”定义
  1. 使用show running-config命令,确保接口配置了dialer-group,而且还配置了一个带有匹配号码的全局dialer-list 。
  2. 保证配置dialer-list命令来允许整个协议,或者允许流量匹配访问控制列表。
  3. 验证access-list宣称去在链路间的数据包是触发的。一个有用的测试就是使用特权执行命令 debug ip packet [list number] ,利用相关访问控制列表。然后尝试ping或者发送流量,在链路间。如果触发数据流过滤器被正确定义,在调试输出上您将看到信息包。如果没有从此测验的debug输出, access-list不匹配数据包。
接口状态 请使用show interfaces命令<interface name>保证接口在状态“up/up (spoofing)”。
  • 建立接口在"standby"模式
在路由器配置另一个(主)接口,以便把拨号程序接口用作备份接口。此外,主要接口不在“down/down”状态时,要求建立非备用模式的拨号程序接口。并且,备份延迟必须配在主要接口上,否则backup interface命令绝不会强制执行。要检查拨号接口从“待机”将变成“up/up (spoofing)”,拔从主要接口的电缆通常是必要的。关闭与配置命令shutdown的主要接口不会放主要接口到“down/down”,反而放它到“管理性关闭” ?不是同一件事。此外,如果主要连接是通过帧中继进行的,则必须在点对点串行子接口上执行帧中继配置,并且电话公司必须通过“活动”位。亦称此实践是“端到端本地管理接口(LMI)”。
  • 接口是“管理性关闭”
拨号接口配置与shutdown命令。Cisco路由器首次被引导时,这也是所有接口的默认状态。请使用interface configuration命令未关闭删除此障碍。
不正确路由 发出exec命令show ip route [a.b.c.d] a.b.c.d远程路由器的拨号接口地址。如果远程路由器使用的ip unnumberedis,在ip unnumberedcommand使用列出的接口的地址输出应该显示路由到远程地址通过拨号接口。如果没有路由,应通过检查show running-config的输出确认静态或浮动静态路由已配置。如果有路由通过除拨号接口之外的其他接口,则暗示DDR作为备份。检查路由器配置确保,静态或浮动静态路由配置。可靠方法测试路由,在这种情况下,将禁用主要连接,并且执行show ip route [a.b.c.d] commandto请验证适当的路由在路由表里安装。

注意: 在真实网络操作期间,如果尝试此,拨号事件可能被触发。在计划维护周期期间,此类测试是最好实现的。

发出呼叫

如果路由和触发数据流过滤器正确,应该发起呼叫。通过使用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
确保dialer string配置。

其次,请识别使用媒体的种类:

外部异步调制解调器 DDR

  1. 要识别外部异步调制解调器DDR,请使用以下命令,然后设法做呼叫:

    router# debug modem
    router# debug chat line <n>
    
    
  2. 对于调制解调器呼叫,对话脚本必须执行为了呼叫能继续。对于基于拨号映射的DDR,对话脚本由在dialer map命令的调制解调器脚本参数调用。如果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
    
  3. 保证对话脚本尝试根据“发送字符串(即正确的编号)的期望的呼叫”。如果对话脚本不尝试做期望的呼叫,请验证对话脚本的配置。请使用启动对话命令在EXEC提示手工启动对话脚本。

  4. 看到“超时预计:连接”能描述几种不同的可能性:

    • 第1种可能性:本地调制解调器实际上不发出呼叫。验证调制解调器能发出呼叫由执行一反向telnet对调制解调器和手工启动拨号。如果远程终端不似乎回答,请验证呼叫由始发调制解调器发出通过手工呼叫本地号码与ATDT <number>命令和细听环。

    • 第2种可能性:远程调制解调器不回答。通过拨号远程调制解调器测试此用一个普通的POTS电话。尝试此:

      1. 保证被叫电话编号正确。请使用一话筒呼叫接收的编号。请务必使用同一个电缆到墙壁调制解调器使用。如果手动呼叫能到达接收的异步调制解调器,始发调制解调器可能不正确地工作。验证调制解调器并且替换当必要时。

      2. 如果手动呼叫不能到达回答的异步调制解调器,请更换在接收的调制解调器的电话线并且尝试在接收的调制解调器线路的一个一般电话。如果呼叫可以由一般电话接收,有可能的一问题用接收的调制解调器。

      3. 如果手动呼叫仍然不能到达在有问题的线路的一般电话,请尝试在接收设备的另一条(已知好)线路。如果那连接好,请有telco检查去接收的调制解调器的电话线路。

      4. 如果这是长途呼叫,请安排始发端尝试另一个(已知好)长途号码。如果那工作,接收设备或线路不可以设置收到长途呼叫。如果始发线路不能到达任何其他长途号码,可能不安排长距离启用。不同的长途电话公司的尝试1010代码。

      5. 最后,请尝试从始发线路的另一(已知好)本地号码。如果连接仍然发生故障,请有telco检查始发线路。

    • 第3种可能性:拨号的编号不正确。通过手工拨号它验证编号。更正配置,如果需要。

    • 第4种可能性:调制解调器测试采取太长或超时值太低。增加在chat-script命令的尝试超时值。如果超时已经是60秒或更多,可能有在附加的调制解调器和DTE之间的一个电缆问题。连接时故障能也指示电路问题或调制解调器不兼容。

      要查出个别调制解调器问题的真相,请努力去做AT提示符在有反向telnet的始发调制解调器。若可能,请达到接收的调制解调器的AT提示符。多数调制解调器将指示一环给终端会话附加对他们的DTE连接。请使用ATM1有调制解调器发送声音到其扬声器,以便每个末端的人们能听到什么在线路发生。

      音乐是否有在它的噪声?如果那样,请整理电路。如果异步调制解调器不培训,请呼叫编号并且细听静态。可能有其他因素干涉训练。对异步调制解调器和调试的反向telnet

  5. 如果一切优良工作,并且在您的CAS异步调制解调器DDR不能仍然连接,请尝试Ppp调试。请使用命令:

    router# debug ppp negotiation
         router# debug ppp authentication
    

    如果对话脚本成功地完成,调制解调器连接。参见在互联网络故障排除指南的章节17下一步的在排除故障连接。

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

  1. 要识别CAS T1/E1异步调制解调器DDR,请使用以下命令,然后设法做呼叫:

    警告 警告: 运行在繁忙的系统的调试能通过超载CPU或超出控制台缓冲区失败路由器!

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

    注意: debug cas命令是可用的在运行Cisco IOS软件版本12.0(7)T及以上版本的Cisco AS5200及AS5300平台。在IOS中以前的版本, service internal命令将必须被输入到路由器配置的主要级别,并且modem-mgmt csm debug-rbs将需要被输入在EXEC提示。在Cisco AS5800的调试要求连接对中继卡。(使用modem-mgmt csm no-debug-rbs关闭调试。)

  2. 对于调制解调器呼叫,对话脚本必须执行为了呼叫能继续。对于基于拨号映射的DDR,对话脚本由在dialer map命令的调制解调器脚本参数调用。如果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
    
  3. 保证对话脚本尝试根据“发送字符串” (即正确的编号)的期望的呼叫。如果对话脚本不尝试做期望的呼叫,请验证对话脚本的配置。请使用启动对话命令在EXEC提示手工启动对话脚本。

  4. 看到“超时预计:连接”能描述几种不同的可能性:

    • 第1种可能性:本地调制解调器实际上不发出呼叫。验证调制解调器能发出呼叫由执行一反向telnet对调制解调器和手工启动拨号。如果远程终端不似乎回答,请验证呼叫由调制解调器放置通过手工呼叫本地号码与ATDT <number>命令和细听环。

      对于通过CAS T1或E1和集成的数字调制解调器进行的呼出呼叫,许多故障排除与其他DDR故障排除类似。同样为在PRI线路的出站集成调制解调器呼叫适用。以这种方式发送呼叫需要的唯一功能是要求在呼叫失败情形下进行特殊调试。

      关于其他DDR情况,您必须保证呼叫尝试被需求。为此请使用debug dialer events。参考IOS DDR,前在此条款。

      发出呼叫之前,调制解调器必须分配给呼叫。要查看此进程和后续呼叫,请使用以下调试指令:

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

      注意: 在AS5200和AS5300的IOS版本首先出现的debug cas命令12.0(7)T。IOS更早版本与exec命令modem-mgmt debug rbs一起使用system-level configuration命令service internal :

      打开调试:

      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的与其他信令类型的调试和E1s是类似的。

      达到在调试的此点表明呼叫和应答调制解调器培训了并且连接,并且更高层协议能开始协商。如果调制解调器适当分配用于呼出,但连接不能接通,则必须检查T1。使用show controller t1/e1指令验证T1/E1运作。请参阅故障排除串行线路关于show controller输出的说明。如果T1/E1是工作不正常, T1/e1故障排除是必要的。

    • 第2种可能性:远程调制解调器不回答。通过拨号远程调制解调器测试此用普通电话。尝试此:

      1. 保证被叫电话编号正确。请使用一话筒呼叫接收的编号。

      2. 保证手动呼叫能到达回答的异步调制解调器。如果手动呼叫能到达回答的异步调制解调器, CAS线路不可以设置允许出局语音呼叫。

      3. 如果手动呼叫不能到达回答的异步调制解调器,请更换在接收的调制解调器的电话线并且尝试在接收的调制解调器线路的一个一般电话。如果呼叫可以由一般电话接收,有可能的一问题用接收的调制解调器。

      4. 如果手动呼叫仍然不能到达在有问题的线路的一般电话,请尝试在接收设备的另一条(已知好)线路。如果那连接,请有telco检查去接收的调制解调器的电话线路。

      5. 如果这是长途呼叫,请安排始发端尝试另一个(已知好)长途号码。如果那工作接收设备或线路不可以设置收到长途呼叫。如果产生的(CAS)线路不能到达任何其他长途号码,可能不安排长距离启用。不同的长途电话公司的尝试10-10代码。

      6. 最后,请尝试从产生的CAS线路的另一(已知好)本地号码。如果连接仍然发生故障,请有telco检查CAS。

    • 第3种可能性:拨号的编号不正确。通过手工拨号它验证编号。更正配置,如果需要。

    • 第4种可能性:调制解调器测试采取太长,或者超时值太低。增加在chat-script命令的尝试超时值。如果超时已经是60秒或更多,可能有在附加的调制解调器和DTE之间的一个电缆问题。连接时故障能也指示电路问题或调制解调器不兼容。

      要查出个别调制解调器问题的真相,请努力去做AT提示符在有反向telnet的始发调制解调器。若可能,请使用反向telnet达到接收的调制解调器的AT提示符。请使用ATM1有调制解调器发送声音到其扬声器,以便每个末端的人们能听到什么在线路发生。

      音乐是否有在它的噪声?如果那样,请整理电路。如果异步调制解调器不培训,请呼叫编号并且细听静态。可能有其他因素干涉训练。对异步调制解调器和调试的反向telnet

  5. 如果一切优良工作,并且在您的CAS异步调制解调器DDR不能仍然连接,请尝试Ppp调试。如果对话脚本成功地完成,并且PPP调试指示一失败,请参见在互联网络故障排除指南的章节17的"故障排除ppp "部分

PRI 异步调制解调器 DDR

  1. 要识别PRI异步调制解调器DDR,请使用以下命令,然后设法做呼叫:

    警告 警告: 运行在繁忙的系统的调试能通过超载CPU或超出控制台缓冲区失败路由器!

    router# debug modem
    router# debug chat
    router# debug modem csm
    router# debug isdn q931
    router# debug isdn
    router# debug ppp negotiate
    router# debug ppp authenticate
    
  2. 对于调制解调器呼叫,对话脚本必须执行为了呼叫能继续。对于基于拨号映射的DDR,对话脚本由在dialer map命令的调制解调器脚本参数调用。如果DDR是基于dialer profile的,则使用TTY线路上配置的script dialer命令,完成此操作。两个方法依靠存在路由器的全局配置里的对话脚本,例如:

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

    无论如何,命令查看对话脚本活动是debug chat。如果用于dialer map or dialer string命令(电话号码)的拨号字符串是5551212, debug输出将看似类似以下:

    CHAT1: Attempting async line dialer script
    
    
    CHAT1: Dialing using Modem script: callout & System script: none
    CHAT1: process started
    CHAT1: Asserting DTR
    CHAT1: Chat script callout started
    CHAT1: Sending string: AT
    CHAT1: Expecting string: OK
    CHAT1: Completed match for expect: OK
    CHAT1: Sending string: atdt5551212
    CHAT1: Expecting string: CONNECT
    CHAT1: Completed match for expect: CONNECT
    CHAT1: Chat script callout finished, status = Success
    
  3. 保证对话脚本尝试根据“发送字符串(正确的编号)的期望的呼叫”。如果对话脚本不尝试做期望的呼叫,请验证对话脚本的配置。请使用启动对话命令在EXEC提示手工启动对话脚本。

  4. 看到“超时预计:连接”能描述几种不同的可能性:

    • 第1种可能性:本地调制解调器实际上不发出呼叫。验证调制解调器能发出呼叫由执行一反向telnet对调制解调器和手工启动拨号。如果远程终端不似乎回答,请验证呼叫由调制解调器发出通过手工呼叫本地号码与ATDT <number>命令和细听环。如果呼叫不出去,请打开ISDN调试。当一怀疑BRI的一个ISDN故障的时候,总是请检查从show isdn status的输出。需要特别注意的是第一层应该激活,第二层应该处在MULTIPLE_FRAME_ESTABLISHED状态。关于阅读此输出的信息,请参阅互联网络故障排除指南章节16" Interpreting Show ISDN Status ",以及关于纠正措施。

      对于出站ISDN呼叫, debug isdn q931debug 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信息是成功关键指标。如果连接没有接收,您可以发现原因代码或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比特的值的第二个字节在断开或RELEASE_COMP接收的端到端呼叫路径指示点。这可能帮助您定位问题。

      • 第三个和第四个字节指示故障的实际原因。参见表9关于不同的值的含义。

    • 第2种可能性:远程调制解调器不回答。通过拨号远程调制解调器测试此用普通电话。尝试此:

      1. 保证被叫电话编号正确。请使用一话筒呼叫接收的编号。

      2. 保证手动呼叫能到达回答的异步调制解调器。如果手动呼叫能到达回答的异步调制解调器, BRI线路不可以设置允许出局语音呼叫。

      3. 如果手动呼叫不能到达回答的异步调制解调器,请更换在接收的调制解调器的电话线并且尝试在接收的调制解调器线路的一个一般电话。如果呼叫可以由一般电话接收,有可能的一问题用接收的调制解调器。

      4. 如果手动呼叫仍然不能到达在有问题的线路的一般电话,请尝试在接收设备的另一条(已知好)线路。如果那连接,请有telco检查去接收的调制解调器的电话线路。

      5. 如果这是长途呼叫,请安排始发端尝试另一个(已知好)长途号码。如果那工作,接收设备或线路不可以设置收到长途呼叫。如果产生的(BRI)线路不能到达任何其他长途号码,可能不安排长距离启用。不同的长途电话公司的尝试1010代码。

      6. 最后,请尝试从产生的BRI线路的另一(已知好)本地号码。如果连接仍然发生故障,请有telco检查BRI。

    • 第3种可能性:拨号的编号不正确。通过手工拨号它验证编号。更正配置,如果需要。

    • 第4种可能性:调制解调器测试采取太长或超时值太低。增加在chat-script命令的尝试超时值。如果超时已经是60秒或更多,可能有在调制解调器和DTE之间的一个电缆问题附加。连接时故障能也指示电路问题或调制解调器不兼容。

      要查出个别调制解调器问题的真相,请努力去做AT提示符在有反向telnet的始发调制解调器。若可能,请使用反向telnet达到接收的调制解调器的AT提示符。请使用ATM1有调制解调器发送声音到其扬声器,以便每个末端的人们能听到什么在线路发生。

      音乐是否有在它的噪声?如果那样,请整理电路。如果异步调制解调器不培训,请呼叫编号并且细听静态。可能有其他因素干涉训练。对异步调制解调器和调试的反向telnet

  5. 如果一切优良工作,并且在您的BRI异步调制解调器DDR不能仍然连接,请尝试Ppp调试。如果对话脚本成功地完成,并且PPP调试指示一失败,请参见在互联网络故障排除指南的章节17的"故障排除ppp "部分

BRI 异步调制解调器 DDR

此功能只用于在Cisco 3640平台上的Cisco IOS软件版本12.0(3)T及以后版本。它要求BRI网络模块的最新硬件修订版。这不会与广域网接口卡一起使用。

  1. 保证国家代码用show modem命令是正确。请使用以下命令,然后设法做呼叫:

    警告 警告: 运行在繁忙的系统的调试能通过超载CPU或超出控制台缓冲区失败路由器!

    router# debug modem
    router# debug chat
    router# debug modem csm
    router# debug isdn q931
    router# debug bri
    router# debug ppp negotiate
    router# debug ppp authenticate
    
  2. 对于调制解调器呼叫,对话脚本必须执行为了呼叫能继续。对于基于拨号映射的DDR,对话脚本由在dialer map命令的调制解调器脚本参数调用。如果DDR是基于dialer profile的,则使用TTY线路上配置的script dialer命令,完成此操作。两用途依靠存在路由器的全局配置里的对话脚本,例如:

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

    无论如何,命令查看对话脚本活动是debug chat。如果用于dialer map or dialer string命令(电话号码)的拨号字符串是5551212, debug输出将看似类似以下:

    CHAT1: Attempting async line dialer script
    
    CHAT1: Dialing using Modem script: callout & System script: none
    CHAT1: process started
    CHAT1: Asserting DTR
    CHAT1: Chat script callout started
    CHAT1: Sending string: AT
    CHAT1: Expecting string: OK
    CHAT1: Completed match for expect: OK
    CHAT1: Sending string: atdt5551212
    CHAT1: Expecting string: CONNECT
    CHAT1: Completed match for expect: CONNECT
    CHAT1: Chat script callout finished, status = Success
    
  3. 保证对话脚本尝试根据“发送字符串(正确的编号)的期望的呼叫”。如果对话脚本不尝试做期望的呼叫,请验证对话脚本的配置。请使用启动对话命令在EXEC提示手工启动对话脚本。

  4. 看到“超时预计:连接”能描述几种不同的可能性:

    • 第1种可能性:本地调制解调器实际上不发出呼叫。验证调制解调器能发出呼叫由执行一反向telnet对调制解调器和手工启动拨号。如果远程终端不似乎回答,请验证呼叫由调制解调器发出通过手工呼叫本地号码与ATDT <number>命令和细听环。如果呼叫不出去,请打开ISDN调试。当一怀疑BRI的一个ISDN故障的时候,总是请检查从show isdn status的输出。需要特别注意的是第一层应该激活,第二层应该处在MULTIPLE_FRAME_ESTABLISHED状态。关于读此输出和纠正措施的信息,请参阅互联网络故障排除指南章节16" Interpreting Show ISDN Status "

      对于出站ISDN呼叫, debug isdn q931debug 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信息是成功关键指标。如果连接没有接收,您可以发现原因代码或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比特的值的第二个字节在断开或RELEASE_COMP接收的端到端呼叫路径指示点。这可能帮助您定位问题。

      • 第三个和第四个字节指示故障的实际原因。参见表9关于不同的值的含义。

    • 第2种可能性:远程调制解调器不回答。通过拨号远程调制解调器测试此用普通电话。尝试此:

      1. 保证被叫电话编号正确。请使用一话筒呼叫接收的编号。

      2. 保证手动呼叫能到达回答的异步调制解调器。如果手动呼叫能到达回答的异步调制解调器, BRI线路不可以设置允许出局语音呼叫。

      3. 如果手动呼叫不能到达回答的异步调制解调器,请更换在接收的调制解调器的电话线并且尝试在接收的调制解调器线路的一个一般电话。如果呼叫可以由一般电话接收,有可能的一问题用接收的调制解调器。

      4. 如果手动呼叫仍然不能到达在有问题的线路的一般电话,请尝试在接收设备的另一条(已知好)线路。如果那连接,请有telco检查去接收的调制解调器的电话线路。

      5. 如果这是长途呼叫,请安排始发端尝试另一个(已知好)长途号码。如果那工作,接收设备或线路不可以设置收到长途呼叫。如果产生的(BRI)线路不能到达任何其他长途号码,可能不安排长距离启用。不同的长途电话公司的尝试10-10代码。

      6. 最后,请尝试从产生的BRI线路的另一(已知好)本地号码。如果连接仍然发生故障,请有telco检查BRI。

    • 第3种可能性:拨号的编号不正确。通过手工拨号它验证编号。更正配置,如果需要。

    • 第4种可能性:调制解调器测试采取太长,或者超时值太低。增加在chat-script命令的尝试超时值。如果超时已经是60秒或更多,可能有在调制解调器和DTE之间的一个电缆问题附加。连接时故障能也指示电路问题或调制解调器不兼容。

      要查出个别调制解调器问题的真相,请努力去做AT提示符在有反向telnet的始发调制解调器。若可能,请使用反向telnet达到接收的调制解调器的AT提示符。请使用ATM1有调制解调器发送声音到其扬声器,以便每个末端的人们能听到什么在线路发生。

      音乐是否有在它的噪声?如果那样,请整理电路。如果异步调制解调器不培训,请呼叫编号并且细听静态。可能有其他因素干涉训练。对异步调制解调器和调试的反向telnet

  5. 如果一切优良工作,并且在您的BRI异步调制解调器DDR不能仍然连接,请尝试Ppp调试。如果对话脚本成功地完成,并且PPP调试指示一失败,请参见在互联网络故障排除指南的章节17的"故障排除ppp "部分

PRI ISDN DDR

  1. 当一怀疑PRI的一个ISDN故障的时候,总是请检查从show isdn status的输出。需要特别注意的是第一层应该激活,第二层应该处在MULTIPLE_FRAME_ESTABLISHED状态。关于读此输出和纠正措施的信息,请参阅互联网络故障排除指南章节16" Interpreting Show ISDN Status "

    对于出站ISDN呼叫, debug isdn q931debug 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信息是成功关键指标。如果连接没有接收,您可以发现原因代码或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比特的值的第二个字节在断开或RELEASE_COMP接收的端到端呼叫路径指示点。这可能帮助您定位问题。

    • 第三个和第四个字节指示故障的实际原因。参见表9关于不同的值的含义。

    注意: 以下打印输出指示一个高协议故障:

    Cause i = 0x8090 - Normal call clearing

    PPP验证故障是典型原因。在假设前,打开debug ppp协商debug ppp authentication连接失败必要是ISDN问题。

  2. 如果CONNECT信息的ISDN被看到,并且PPP调试指示一失败,请参见在互联网络故障排除指南的章节17的"故障排除ppp "部分

BRI ISDN DDR

  1. 当一怀疑BRI的一个ISDN故障的时候,总是请检查从show isdn status的输出。需要特别注意的是第一层应该激活,第二层应该处在MULTIPLE_FRAME_ESTABLISHED状态。关于读此输出和纠正措施的信息,请参阅互联网络故障排除指南章节16, " Interpreting Show ISDN Status "。

    对于出站ISDN呼叫, debug isdn q931debug 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信息是成功关键指标。如果连接没有接收,您可以发现原因代码或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比特的值的第二个字节在断开或RELEASE_COMP接收的端到端呼叫路径指示点。这可能帮助您定位问题。

    • 第三个和第四个字节指示故障的实际原因。参见表9关于不同的值的含义。

      注意: 以下打印输出指示一个高协议故障:

      Cause i = 0x8090 - Normal call clearing

      PPP验证故障是典型原因。在假设前,打开debug ppp协商debug ppp authentication连接失败必要是ISDN问题。

  2. 如果CONNECT信息的ISDN被看到,并且PPP调试指示一失败,请参见在互联网络故障排除指南的章节17的"故障排除ppp "部分

相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


相关信息


Document ID: 14954