拨号和接入 : 综合业务数字网络 (ISDN),随路信令 (CAS)

拨号技术:故障排除技术

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


从互联网络故障排除指南的此信息在CCO首先被张贴了。作为我们的一项客户服务,使用最新、最准确的信息,所选章节已被更新。"“互联网络故障排除指南""的完全更新,将很快印刷出版并在网上推出。"


目录


简介

拨号是代表终端用户运载数据公共交换电话网(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是在Cisco和调制解调器制造商之间的一家合资企业。通过使用四元组调制解调器卡,将AS5100创建作为增加调制解调器密度的方式。它包含一个双T1卡和一组AS2511卡(插入到有四个调制解调器卡的底板中)。

使用的组件

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

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

规则

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

排除故障呼入呼叫

排除故障呼入呼叫在底部开始并且运转其方式。推理一般流寻找以下:

  1. 是否看到呼叫到达?(A答案提前到下一个问题)

  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。载体功能(经常指bearercap)告诉路由器什么样的呼叫进来。在这种情况下连接是类型0x8890。该值指示“ISDN速度64 Kb/s”。如果bearercap是0x8090A2,将指示“话音/语音呼叫U律”。

如果设定信息没有收到,您应该通过手工呼叫检验编号是否正确(如果设置了语音)。您也应该检查ISDN接口的状态(请参考用于BRI故障排除的show isdn status命令)。如果进行全面检查,确保呼叫始发者发出正确呼叫。这可以由联系电话公司完成。呼叫始发者哪里能跟踪呼叫发现它?发送的s。如果连接是长途,请尝试使用1010长途编码的一个不同的长途运营商。

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

注意: BRI异步调制解调器呼叫是运行12.0(3)T或以上版本的3600路由器功能。它要求BRI接口网络模块的最近硬件版本。WIC模块不支持异步调制解调器呼叫。

如果呼叫已经到达但还没有完成,寻找原因代码(参见表17-10)。成功的完成是由connect-ack表示的。

如果这是异步调制解调器呼叫,请移动向前向呼入调制解调器呼叫的故障排除部分。

这时ISDN呼叫连接,但是数据未被看到遇到链路。使用debug ppp negotiate命令,查看是否有任何PPP数据流流经线路。如果看不到流量,可能有速度不匹配。确定是否是实际情形,使用show running-config特权执行命令,查看路由器配置。检查在本地和远程路由器的dialer map interface configuration命令entries。这些条目应该看起来类似于以下:

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命令。

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

要确保信令是OK,使用概述的show line命令在章节16。

电缆连接问题在旁边,外置调制解调器需要初始化到自动应答。检查远程调制解调器发现是否设置为自动应答。通常, AA指示灯在,当自动应答设置时。设置远程调制解调器为自动应答是否已经没有设置。关于验证和更改调制解调器设置的信息,参考您的调制解调器文档。请使用一反向telnet初始化调制解调器(参考的章节16)。

数字(综合)调制解调器呼叫摘机

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

  1. 确保isdn incoming-voice modem命令存在处理流入的调制解调器连接的所有ISDN接口下。

  2. 在调制解调器的TTY的line configuration下,请确保modem inout命令存在。

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

调制解调器测试

如果接收的调制解调器培养DSR,培训是成功的。连接时故障能指示电路问题或调制解调器不兼容。

要彻底查出个别调制解调器问题的真相,当始发调制解调器与相关的POTS线路连接时, 查看始发调制解调器的AT提示。如果在Cisco接入服务器中呼叫数字调制解调器,请准备记录连接音乐或者数字缺损学习序列(DIL的) 的.wav文件。DIL是一种乐谱(PCM顺序),所产生的V.90模拟调制解调器将告诉接收数字调制解调器播放该乐谱。顺序允许模拟调制解调器辩明在电路的所有数字损伤;例如多D/A转换、law/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会话)从呼叫发起端连接。

注意: 如果接收端显示异步调制解调器专用于异步接口,EXEC拨入只会显示随机ASCII垃圾。要允许终端会话和仍然有PPP功能,请使用交互的async interface configuration命令async mode。在相关的线路配置下,请使用autoselect ppp命令。

调制解调器不能发送或接收数据

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

  • 调制解调器速度设置没有锁定

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

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

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

      语法:

      速度BPS

      语法说明:

      位/秒-在比特/秒(位/秒)的波特率。默认是9600位/秒。

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

      line 1 2
      speed 115200

      注意: 如果,由于某种原因,不能使用流量控制,对9600位/秒请限制线路速度。最高速度可能导致丢失数据。

    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

      欲知更多信息,参考解释在章节输出的Show line 16。

      如果此字段中没有提及硬件流控制,硬件流控制则不会在线路上启用。推荐接入服务器到调制解调器连接的硬件流控制。

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

    2. 使用flowcontrol hardware line configuration命令,配置在线路的硬件流控制。

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

      语法:

      流控制{无|软件[lock] [在|]|硬件[在|]}

      语法说明:

      • -关闭流量控制。

      • 软件-设置软件流控制。可选关键字指定方向:流入导致Cisco IOS软件能接听来自连接设备的流控制,流出导致该软件发送流控制信息到连接的设备上。如果不指定方向,两个假设。

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

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

      示例:

      以下示例设置在线路7的硬件流控制:

      line 7
      flowcontrol hardware

      注意: 由于某种原因如果不能使用流量控制,对9600位/秒请限制线路速度。最高速度可能导致丢失数据。

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

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

  • 误配置的拨号映射命令

    1. 请使用show running-config privileged exec命令查看路由器配置。检查dialer map命令entries发现广播关键字是否指定。

    2. 如果关键字未命中,请添加它到配置。

      语法:

      dialer map protocol next-hop-address [name hostname-] [broadcast] [dial-string]

      语法说明:

      • 协议-受映射支配的协议。选项包括IP、IPX、网桥和快照。

      • 下一条地址-相反的站点的异步接口的协议地址。

      • 主机名-用于PPP认证的要求的参数。它是dialer map创建远程站点的名称。名称区分大小写,并且必须匹配远程路由器的主机名。

      • 广播—— 一个可选关键字,广播发往远程目的地的信息包((例如,IP RIP或IPX RIP/SAP更新信息包)。在静态路由示例配置中,路由更新没有希望,并且广播关键字省略。

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

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

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

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

    关于配置拨号图的详细信息,参考Cisco IOS广域网配置指南Wide-area networking命令reference

  • 问题用拨号调制解调器

    • 确保拨号调制解调器可以操作,可以安全连接到正确端口。确定另一个调制解调器是否运作,当连接对相同端口。

调试流入的EXEC会话通常归入一些个主要类别:

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

  • 自动选择在线路启用

    尝试通过按回车访问EXEC模式。

  • 线路配置用no exec命令

    1. 请使用show line exec命令查看适当的线路的状况。

      检查Capabilities字段发现是否说“抑制的exec”。如果这是实际情形, no exec line configuration命令启用。

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

    以下示例打开在线路7的exec :

    line 7 
    exec
  • 流量控制没有启用。

    流量控制在一个设备仅启用(DTE或DCE)。

    流量控制是不正确的配置的。

    1. 请使用show line aux-line-number exec命令并且寻找以下在Capabilities字段:

      Capabilities: Hardware Flowcontrol In, Hardware Flowcontrol Out
      

      欲知更多信息,参考解释在章节输出的Show line 16。

      如果此字段中没有提及硬件流控制,硬件流控制则不会在线路上启用。推荐接入服务器到调制解调器连接的硬件流控制。

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

    2. 使用flowcontrol hardware line configuration命令,配置在线路的硬件流控制。以下示例设置在线路7的硬件流控制:

      line 7
      flowcontrol hardware

      注意: 由于某种原因如果不能使用流量控制,对9600位/秒请限制线路速度。最高速度可能导致丢失数据。

    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

      语法说明:

      位/秒-在比特/秒(位/秒)的波特率。默认是9600位/秒。

      示例:

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

      line 1 2
      speed 115200

      注意: 由于某种原因如果不能使用流量控制,对9600位/秒请限制线路速度。最高速度可能导致丢失数据。

    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 line configuration命令。此命令设定传输(到终端)和接收(从终端)速度。

      语法:

      速度BPS

      语法说明:

      在比特/秒(位/秒)的位/秒波特率。默认是9600位/秒。

      示例:

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

      线路1 2

      速度115200

      注意: 由于某种原因如果不能使用流量控制,对9600位/秒请限制线路速度。最高速度可能导致丢失数据。

    3. 再请使用show line exec命令并且确认线路速度设定为所需的值。

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

    5. 请使用包括lock dte speed命令您的调制解调器的一个调制解调器命令串。请参阅您的调制解调器文档关于确切的配置命令句法。

    注意: lock DTE speed命令(可能也被称为端口速率调整或缓冲模式)往往与调制解调器处理错误纠正的方式有关。此命令从一个调制解调器较大变化到另一个。

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

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

拨号会话在现有的会话上召开

  • 为DCD配置的调制解调器总是高

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

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

    3. 通过输入断开结束远程登录会话并且重新配置接入服务器线路用exec line configuration命令

  • 调制解调器控制在接入服务器或路由器没有启用

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

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

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

    注意: 考虑调制解调器的连通性时,确定使用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

    输入Hangup dtr modem命令串当DTR信号不再被接收时,此命令将告知调制解调器丢弃载波。

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

  • 调制解调器控制在路由器或接入服务器没有启用

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

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

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

    注意: 考虑调制解调器的连通性时,确定使用modem inout命令代替modem dialin命令。后一个命令允许线路仅响应呼入呼叫。去话将被拒绝,使之不可能建立与调制解调器的Telnet会话,以便进行配置。如果想要启用modem dialin命令,只能在您确定调制解调器正确运行之后方可执行。

排除故障呼出

来电的故障排除方法从底部开始,而排除出站连接故障则从顶部开始。推理一般流寻找以下:

  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. 使用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 (欺骗)。

    • 建立接口在"standby"模式

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

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

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

    • 接口是“管理性关闭”

      拨号接口配置与shutdown命令。Cisco路由器首次被引导时,这也是所有接口的默认状态。请使用interface configuration命令未关闭删除此障碍。

  • 不正确路由

    发出exec命令show ip route [a.b.c.d] a.b.c.d远程路由器的拨号接口isthe地址。如果远程路由器使用的ip unnumberedis,在ip unnumberedcommand使用列出的接口的地址

    输出应该显示路由到远程地址通过拨号接口。如果没有路由,应通过检查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命令,并且在路由器的一拨号接口配置用一匹配的拨号池成员X。如果拨号配置文件没有适当地配置,您可以发现调试消息类似:

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

    确保dialer string配置。

异步呼出电话-验证对话脚本操作

如果呼出是调制解调器呼叫,则必须执行对话脚本,以便进行呼叫。对于基于拨号映射的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

对话脚本问题可以分成三个类别:

  • 配置错误

  • 调制解调器故障

  • 连接失败

对话脚本失败

此列表显示从debug chat的可能的输出显示和建议的行动:

  • 为[number]找到的没有匹配的对话脚本

    对话脚本未配置。加一。

  • 完成的对话脚本拨出,被计时的状态=连接;不响应的远程主机

    调制解调器不响应对对话脚本。验证通信用调制解调器(参考的表16-2在章节16)。

  • 超时预计:连接

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

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

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

    • 第4种可能性:调制解调器测试采取太长或超时值太低。如果本地调制解调器是外置调制解调器,需调大调制解调器的扬声器音量,并监听trainup提示音。如果培训突然被中断,请尝试增加在chat-script命令的超时值。如果超时已经是60秒或更多,请参阅Modem Trainup部分

ISDN呼出电话

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

对于出站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

!--- 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验证故障是典型原因。在假设前,打开debug ppp协商debug ppp authentication连接失败必要是ISDN问题

原因代码字段

表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 (是任一个下列的值的可选)诊断域:2瞬变0未知的1永久性

ISDN 原因值

下表描述了原因信息单元的一些常见原因值——原因代码的第三个和第四个字节。关于ISDN代码和值的更全面的信息,参考了解debug isdn q931断开原因代码

十六进制值 原因 说明
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 modem

  • debug modem csm

  • 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# 
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。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

注意: 您的调试在一个不同的格式可能出现。此示例显示更新的Ppp调试输出格式哪些在IOS版本11.2(8)被修改了。请参阅章节16关于Ppp调试示例与更旧的IOS版本的。

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状态是“打开”。两边确认(CONFACK)另一侧的配置请求(CONFREQ)。
10:57:17.047直到10:57:17.191 PPP认证顺利地完成。在LCP协商后,验证开始。在所有网络协议,例如IP,传送前,验证必须发生。两边验证与在LCP期间协商的方法。Montecito验证使用CHAP的客户端。
10:57:20.551 状态为IP Control Protocol (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消息中看到的承载能力匹配。一种可能的补救措施是,配置在接口层的命令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前收集从两对等体的以下输出:

验证

失败的认证单身PPP失败的多数常见原因。不正确的配置或不匹配的用户名和密码Create错误信息在debug输出中。

以下示例显示用户名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发送包含其IP地址的流出的PPP配置请求信息包给对等体。
21:35:04.282 流入的CONFREQ。对等体请求执行VJ报头压缩。它需要本身的一个主备DNS服务器的IP地址,以及地址。
21:35:04.306 出局配置拒绝(CONFREJ)。VJ报头压缩拒绝。
21:35:04.314直到21:35:04.330 对等体发送请求执行压缩控制协议;整个协议由NAS拒绝通过PROTREJ信息。对等体不应该(和不)尝试重试CCP。
21:35:04.334 对等体确认NAS的IP地址与CONFACK的。
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协商期间的任何问题通常可能追踪到协商对等体的配置。在NCP相位期间,如果PPP协商失效,参考以下步骤:

  1. 验证接口协议配置

    检查privileged exec命令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服务器。必须配置NAS接口与peer default ip address dhcp命令。此外,必须配置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]。

    注意: 当async-bootp subnet-mask命令[mask]可以配置在NAS时,子网掩码则不会在NAS和PPP拨入客户端PC之间进行协商。由于点到点连接的本质,客户端自动地使用NAS的IP地址(在IPCP协商期间获得)作为默认网关。子网掩码在该点对点环境没有必要。PC知道如果目的地地址与本地地址不匹配,应该将数据包转发到默认网关(NAS),该网关总是可以通过PPP链路到达。

在呼叫Cisco系统TAC小组前

呼叫Cisco系统技术支持中心(TAC)之前,保证您通读了本章,并执行完了您的系统问题的建议措施。

另外,执行以下操作,并记录结果,以便我们能够更好地为您提供帮助:

对于所有问题,请收集show running-configshow version输出。保证service timestamps debug datetime msec命令在配置里。

对于DDR问题,请收集以下:

如果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


相关信息


Document ID: 10203