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

ISDN BRI 故障排除流程图

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


简介

本文帮助您排除故障ISDN基本速率接口(BRI)拨号接入。使用拨号配置文件,在如下所示的流程图和输出示例:中,我们设置ISDN BRI连接到另一个。然而,同样故障排除步骤适用对对其他路由器的连接(例如分支机构)和,当曾经传统按需拨号路由时(DDR)。

注意:您能也使用Cisco支持社区为了帮助您解决您的ISDN问题。

关于ISDN和DDR的简介,参考在思科中查找的音频培训学习连接

流程图

点击下面链路获得关于项目的更多信息。请使用Back按钮您的浏览器的返回到此流程图。


排除故障:如何登陆和获取这些调试

通过使用telnet,您能连接到您的路由器通过控制台电缆附加对您的PC串行端口,或者。

如果需要连接到您的路由器到控制台,请参考应用正确终端仿真程序设置为控制台连接。如果您的路由器为在以太网的连接已经设置使用telnet,并且要连接到您的路由器,请使用一个Telnet客户端连接到路由器的以太网IP地址。

无论如何(控制台或telnet),使用允许您保持在会话期间接收的输出历史记录的客户端最好的,您在您的debug输出中可以必须移动上一步寻找特定消息。

激活在debug输出和日志消息的毫秒。当提示,请输入在您的路由器配置的密码并且输入特权模式:

router>enable
Password: (enter the enable password)
router#
router#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
router(config)#service timestamps debug datetime msec 
router(config)#service timestamps log datetime msec 

使用telnet,如果连接,请键入终端监视器如下:

router#terminal monitor
router# 

在此之后,请输入下面调试指令:

router#debug isdn q931
ISDN Q931 packets debugging is on
router#debug ppp negotiation
PPP protocol negotiation debugging is on
router#debug dialer packet
Dial on demand packets debugging is on
router#debug dialer
Dial on demand events debugging is on
router#debug ppp authentication
PPP authentication debugging is on
router#
然后请启动在呼叫路由器的ping。下面成功的呼叫的debug输出示例。不同的相位,如识别在流程图,突出显示。
router#ping 194.183.201.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 194.183.201.1, timeout is 2 seconds:

*Mar  1 00:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 
100 bytes, outgoing interesting (ip PERMIT)
! -- The ping for 194.183.201.1 is interesting traffic and uses Dialer 1(Di1)
*Mar  1 00:06:36.387: BR0 DDR: rotor dialout [priority]
*Mar  1 00:06:36.391: BR0 DDR: Dialing cause ip (s=10.1.0.1, d=194.183.201.1)
*Mar  1 00:06:36.395: BR0 DDR: Attempting to dial 8134
! -- Number used to dial. 
! -- This is configured using the dialer string or dialer map command ! -- If you do not see this message proceed to section ! -- Symptom: The Router Does Not Attempt to Dial
*Mar 1 00:06:36.411: ISDN BR0: TX -> SETUP pd = 8 callref = 0x02 *Mar 1 00:06:36.415: Bearer Capability i = 0x8890 *Mar 1 00:06:36.423: Channel ID i = 0x83 *Mar 1 00:06:36.427: Called Party Number i = 0x80, '8134', Plan:Unknown, Type:Unknown *Mar 1 00:06:36.519: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x82 *Mar 1 00:06:36.527: Channel ID i = 0x89 *Mar 1 00:06:36.727: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x82 *Mar 1 00:06:36.743: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x02 *Mar 1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up ! -- ISDN Layer 3 CONNECT message and Link Up message ! -- If you do not see this message proceed to section ! -- Symptom: The ISDN Call Does Not Connect Successfully *Mar 1 00:06:36.767: BR0:1: interface must be fifo queue, force fifo *Mar 1 00:06:36.775: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1 *Mar 1 00:06:36.787: BR0:1 PPP: Treating connection as a callout *Mar 1 00:06:36.791: BR0:1 PPP: Phase is ESTABLISHING, Active Open ! -- LCP negotiation begins *Mar 1 00:06:36.791: BR0:1 PPP: No remote authentication for call-out *Mar 1 00:06:36.795: BR0:1 LCP: O CONFREQ [Closed] id 3 len 10 *Mar 1 00:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.859: BR0:1 LCP: I CONFREQ [REQsent] id 59 len 15 *Mar 1 00:06:36.863: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.871: BR0:1 LCP: O CONFACK [REQsent] id 59 len 15 *Mar 1 00:06:36.875: BR0:1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 00:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *Mar 1 00:06:36.879: BR0:1 LCP: I CONFACK [ACKsent] id 3 len 10 *Mar 1 00:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 00:06:36.887: BR0:1 LCP: State is Open ! -- LCP negotiation is complete. Any LCP state other than Open indicates ! -- that LCP negotiation has failed. ! -- If you do not see this message proceed to section ! -- Symptom: PPP LCP Phase Does Not Succeed *Mar 1 00:06:36.903: BR0:1 PPP: Phase is AUTHENTICATING, by the peer *Mar 1 00:06:36.907: BR0:1 CHAP: I CHALLENGE id 38 len 24 from "ISP" ! -- Incoming CHAP challenge *Mar 1 00:06:36.915: BR0:1 CHAP: Using alternate hostname XXXXX ! -- Using alternate hostname configured with ppp chap hostname command *Mar 1 00:06:36.915: BR0:1 CHAP: Username ISP not found *Mar 1 00:06:36.919: BR0:1 CHAP: Using default password ! -- Using password configured with ppp chap password command *Mar 1 00:06:36.923: BR0:1 CHAP: O RESPONSE id 38 len 26 from "XXXXX" ! -- Sending response from "XXXXX" which is the alternate hostname for the router *Mar 1 00:06:36.939: BR0:1 CHAP: I SUCCESS id 38 len 4 ! -- NAS has succesfully authenticated the router *Mar 1 00:06:36.943: BR0:1 PPP: Phase is UP ! -- PPP Authentication is successful ! -- PPP NCP (IPCP) negotiation begins *Mar 1 00:06:36.947: BR0:1 IPCP: O CONFREQ [Not negotiated] id 3 len 10 *Mar 1 00:06:36.951: BR0:1 IPCP: Address 0.0.0.0 (0x030600000000) ! -- This router does not have an address configured, so it sends a ! -- CONFREQ with the address 0.0.0.0. This tells the other peer to assign an address ! -- which is accomplished by the sending of a CONFNAK with the proper address. *Mar 1 00:06:36.955: BR0:1 IPCP: I CONFREQ [REQsent] id 26 len 10 *Mar 1 00:06:36.963: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- Incoming CONFREQ indicating the peer's IP address *Mar 1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10 *Mar 1 00:06:36.971: BR0:1 IPCP: Address 194.183.201.1 (0x0306C2B7C901) ! -- The router accepts the peer's IP address ! -- (since it is not trying to assign one to the peer) ! -- Once the call is connected a route to this address will be installed *Mar 1 00:06:36.975: BR0:1 IPCP: I CONFNAK [ACKsent] id 3 len 10 *Mar 1 00:06:36.979: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- The peer CONFNAKs our initial Address request of 0.0.0.0 ! -- It responds with the address that this router could use ! -- The NAS can assign this using the peer default ip address or dialer map command *Mar 1 00:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] id 4 len 10 *Mar 1 00:06:36.987: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- This router requests the address previously suggested by the NAS *Mar 1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10 *Mar 1 00:06:37.015: BR0:1 IPCP: Address 194.183.201.2 (0x0306C2B7C902) ! -- NAS accepts the address requested by the client *Mar 1 00:06:37.015: BR0:1 IPCP: State is Open ! -- PPP NCP (IPCP) negotiation is complete ! -- If you do not see this message proceed to section ! -- Symptom: PPP NCP (IPCP) negotiation does not succeed *Mar 1 00:06:37.019: Di1 IPCP: Install negotiated IP interface address 194.183.201.2 *Mar 1 00:06:37.031: BR0:1 DDR: dialer protocol up *Mar 1 00:06:37.039: Di1 IPCP: Install route to 194.183.201.1 ! -- Route to peer is installed *Mar 1 00:06:37.943: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state to up *Mar 1 00:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) *Mar 1 00:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 bytes, outgoing interesting (ip PERMIT) router# *Mar 1 00:06:42.783: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8134 unknown router#

回到故障排除流程图


排除故障:路由器是否尝试拨号?

为了欲知路由器是否尝试发出呼叫,请验证您是否有以下线路在呼叫路由器的debug输出中:
*Mar  1 00:06:36.395: BR0 DDR: Attempting to dial 8134
在debug输出中, 8134是路由器尝试拨号的ISDN目录号码。使用dialer string or dialer map命令,此编号指定。

回到故障排除流程图


症状:路由器不尝试拨号

如果您的路由器不尝试拨号,有几种可能性:

没有任何调试输出

如果没有debug输出,这是很可能,因为您发送不均等已路由对拨号接口的IP数据包。此的多数常见原因是:

  • 验证在拨号程序接口上配置了 IP。您应该有在拨号接口的一个IP地址或ip unnumbered接口(其中接口是一个UP/UP接口例如以太网x,环回x等)或协商的IP地址(如果客户端从NAS将获取IP地址)。如果使用传统DDR,则在物理接口(示例, interface bri 0)应该配置IP地址。
  • 验证ip routing命令配置。使用show running-config命令时,当您查看您的配置,您不应该看到no ip routing命令。
  • 验证有指向拨号接口或下一跳的静态路由(如果曾经拨号图)。

    以下示例(拨号配置文件)是172.22.53.0/24的静态路由与下一跳拨号1 :

    maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 dialer 1
    

    以下示例(传统DDR)是172.22.53.0/24的静态路由与下一跳172.16.1.1。下一跳地址应该匹配在使用拨号的拨号映射语句的IP地址:

    maui-soho-01(config)#ip route 172.22.53.0 255.255.255.0 172.16.1.1
  • 验证拨号程序或物理接口不在管理性关闭或备用状态。请使用show interface dialer xshow interface bri x命令保证接口在状态up/up (spoofing)。

    如果接口管理上下降状态,则请使用no shutdown命令在接口配置模式。

    如果接口在备用状态,则拨号程序或BRI接口是备份对是UP的连接。您能删除backup interface命令在主要接口下或从主要接口拔电缆。

"有debug输出但没有""Attempting to Dial"" 消息"

在这种情况下,可能具有路由到该接口的 IP 数据包,但是路由器出于某种原因而将其丢弃且没有启动呼叫。查看debug输出为了发现呼叫尝试为什么没有被做。下面一些debug输出示例和他们可能的来源:

示例 1

*Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1),
  100 bytes, outgoing uninteresting (list 101).

生成的流量不匹配触发数据流定义。对于此示例,请修改access-list 101

一简单关注数据流定义是允许所有IP数据流和在:

maui-soho-01(config)#dialer-list 1 protocol ip permit

警告:特别是如果有一个路由协议或其他日常流量,标记所有IP数据流作为触发的可能导致ISDN链路无限地坚持。调节触发数据流定义配合您的需要。

关于关注数据流的更多信息,参考拨号技术一文:概述和解释

示例 2

*Mar  1 00:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing uninteresting (no dialer-group defined).

没有在拨号接口配置的拨号组。如以下示例所示,添加拨号程序组:

 interface Dialer1
  dialer-group X

注意:X的值应该是同样一个与dialer-list命令一起使用

示例 3

*Mar  1 00:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing uninteresting (dialer-list 1 not defined).

有在拨号接口的一个Dialer-Group语句,但是指的拨号列表不存在。如以下示例所示,配置拨号程序列表:

dialer-list X protocol ip permit

注意:X的值应该是同样一个与dialer-group命令一起使用在拨号接口下。

示例 4

*Mar  1 00:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing interesting (ip PERMIT)
*Mar  1 00:25:32.555: Di1 DDR: No free dialer - starting fast idle timer.

在这种情况下,会将传出数据包视为足够相关以启动该链路,但是没有可用于进行呼叫的物理接口。确保拨号池成员x在物理接口配置,并且dialer pool X在拨号接口配置。示例:

interface BRI0
 dialer pool-member 1
!
interface Dialer1
 dialer pool 1

并且,请验证BRI接口不在关闭状态。

示例5

*Mar  1 00:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1),
100 bytes, outgoing interesting (ip PERMIT)
*Mar  1 00:37:24.239: Di1 DDR: Cannot place call, no dialer string set.

在这种情况下, dialer string在拨号接口没有配置。路由器要发出呼叫,但是不认识ISDN目录号码呼叫。定义拨号程序字符串:

interface Dialer1
 dialer string 8134

欲知更多故障排除信息,参考部分使用debug isdn q931命令, “呼叫路由器不传送一设置信息”在本文故障排除ISDN BRI第3层

回到故障排除流程图


排除故障:ISDN呼叫是否成功连接?

为了识别ISDN呼叫是否连接,请寻找在调试的一个CONNECT_ACK和%LINK-3-UPDOWN消息:
*Mar  1 00:06:36.743: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x02
*Mar  1 00:06:36.751: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
如果看到此消息,您的ISDN呼叫顺利地连接的和您可能进行到下一步。如果看不到象这样的一个消息,为可能的原因下面请读。

回到故障排除流程图


症状:ISDN呼叫不成功连接

  1. 如果看到输出类似于以下,请验证接通ISDN电缆路由器和电信公司接口。
    *Mar  1 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4),
    100 bytes, outgoing interesting (ip PERMIT)
    *Mar  1 21:31:18.190: BR0 DDR: rotor dialout [priority]
    *Mar  1 21:31:18.198: BR0 DDR: Dialing cause ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4)
    *Mar  1 21:31:18.198: BR0 DDR: Attempting to dial 8134.
    *Mar  1 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4),
    100 bytes, outgoing interesting (ip PERMIT).
    
    *Mar  1 21:31:26.226: ISDN BR0: Could not bring up interface
    *Mar  1 21:31:26.226: BRI0: wait for isdn carrier timeout, call id=0x849E
    *Mar  1 21:31:26.246: ISDN BR0: Could not bring up interface.
    Success rate is 0 percent (0/5)
  2. 验证ISDN电路正常运行。请使用show isdn status命令验证第1层是活跃的, Layer2是MULTIPLE_FRAME_ESTABLISHED,并且SPID (若需要)有效。欲知使用show isdn status命令参考的本文更多信息BRI故障排除的

    如果有输出一show isdn status命令从您的Cisco设备,您能使用 显示潜在问题和修正。要使用,您必须是处于登录状态的注册用户,并启用 JavaScript。
  3. 验证已配置的ISDN拨号程序字符串正确。记住您可以必须添加前导零,九个或其他位获得外线,当您通过PBX时连接。

  4. 如果连接使用一长途运营商联系方式您的本地telco和长途提供商验证服务被启动。本地Telco经常错误配置ISDN电路,这样出局ISDN长途呼叫不会通过被切换到适当的长途提供商网络上。您还应验证长途电信运营商网络是否正常工作。

    在Telco或长途提供商无法纠正问题的美国和情况的,您可以希望使用预定的内部交换载体(PIC)。PIC代码是识别美国长途运营商到本地交换运营商的七位前缀(LEC)。这允许客户使用不同的长途运营商单个呼叫。PIC编码配置作为对呼叫号码的前缀。多数PICs是格式1010xxx的。

    请勿请使用dialer stringdialer map删除现有的号码然后配置新号码。

    例如, dialer string 10103215125551111

  5. 寻找一个ISDN断开消息。

    Cisco IOS软件解码在此断开消息的原因代码并且给予您经常包含导致问题的原因的有用的信息的明文正文消息。您可以查找此处包括的可能的字符串:

    • 未分配或未赋值的数字
    • (其中之二表明的目标不兼容呼叫号码也许不正确)
    • 表明的号码繁忙(被呼叫端忙碌)
    • 指示在电信网络的一临时中断)的临时失败(

  6. 为了查找一个特定断开原因的可能的来源,请参考了解debug isdn q931断开原因代码

    例如,断开由于不正确的ISDN号码可能表示用:

    *Mar  3 00:10:38.756: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0xEB
    *Mar  3 00:10:38.764:         Cause i = 0x84D8 - Incompatible destination
    

    参见以前被参考的断开原因代码文档,我们能确定断开代码是由尝试连接造成的到非ISDN设备(例如,模拟线路)。

    可能会显示以下内容来指示由于号码格式不正确而断开连接:

    Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86
    Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format (incomplete number)

    参见“了解debug isdn q931断开原因代码”文件,我们可以确定断开代码是否由远程ISDN号码的无效格式引起。连接发生故障是因为目的地址是用无法识别的格式提交(到交换机)的,或者目的地址不完整。

    以下示例显示被拒的呼叫由于不正确的ISDN号码:

    *Mar 13 11:29:04.758: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x83
    *Mar 13 11:29:04.769:         Cause i = 0x8295 - Call rejected

  7. 如果您的Telco提供您(SPID)将使用的服务配置文件标识符,请确保这些SPID配置在BRI接口。SPID是仅常用的在美国和与倪和DMS交换类型(5ess交换类型不需要SPID)。
    interface BRI0
     isdn spid1 51255511110101 5551111
     isdn spid2 51255511120101 5551112
  8. 如果SPID正确,您能使用show isdn status命令验证。

    欲知更多信息,参考本文故障排除ISDN BRI SPID

    如果有输出一show isdn status命令从您的Cisco设备,您能使用 显示潜在问题和修正。要使用,您必须是处于登录状态的注册用户,并启用 JavaScript。

  9. 如果上述步骤未解决问题,请使用本文故障排除ISDN BRI第3层使用debug isdn q931命令为做进一步的故障排除。

回到故障排除流程图


排除故障:PPP LCP相位是否成功?

在debug输出中,您应该看到消息行到以下:
*Mar  1 00:06:36.887: BR0:1 LCP: State is Open
如果看到此线路,这表明链路控制协议(LCP)顺利地协商。除开放之外的所有状态指示失败的该LCP。

回到故障排除流程图


症状:PPP LCP相位不成功

可能的原因:PPP没有配置

如果有debug输出类似于以下线路,这表明PPP没有开始。

*Mar 2 19:34:21.761: Di1 DDR: dialer protocol up.
*Mar 2 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100
bytes, outgoing interesting (ip PERMIT).
*Mar 2 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100
bytes, outgoing interesting (ip PERMIT).
*Mar 2 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100
bytes, outgoing interesting (ip PERMIT)
*Mar 2 19:34:27.753: %ISDN-6-CONNECT: Interface BRI0:1 is now
connected to 8101.
! -- Call connects but the router does not send any PPP CONFREQ packets *Mar 2 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 bytes, outgoing interesting (ip PERMIT). Success rate is 0 percent (0/5)

从debug输出的注意路由器不传送任何PPP CONFREQ信息。这很可能是,因为接口未为PPP封装配置。

在这种情况下,请验证您配置encapsulation ppp命令在拨号接口和物理接口下。以下是一些示例:

interface Dialer1
 encapsulation ppp


or
interface BRI 0
encapsulation ppp

可能的原因:ISDN速率不匹配

有时您不可以发现仅出站LCP CONFREQ消息,但是入站LCP消息。示例如下所示:

*Mar 14 01:49:10.160: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
! -- Call is connected. PPP negotiation will begin
*Mar 14 01:49:10.168: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1.
*Mar 14 01:49:10.188: BR0:1 PPP: Treating connection as a callout
*Mar 14 01:49:10.188: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] ! -- PPP negotiation begins
*Mar 14 01:49:10.196: BR0:1 LCP: O CONFREQ [Closed] id 24 len 15
*Mar 14 01:49:10.200: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:10.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). ! -- Outgoing Configure-Request (CONFREQ)
*Mar 14 01:49:12.176: BR0:1 LCP: TIMEout: State REQsent ! -- Router has not received a CONFREQ from the peer, hence the timeout
*Mar 14 01:49:12.180: BR0:1 LCP: O CONFREQ [REQsent] id 25 len 15
*Mar 14 01:49:12.184: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:12.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
*Mar 14 01:49:14.160: BR0:1 LCP: TIMEout: State REQsent
*Mar 14 01:49:14.164: BR0:1 LCP: O CONFREQ [REQsent] id 26 len 15
*Mar 14 01:49:14.168: BR0:1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 14 01:49:14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A)
此问题能引起:
  • 为PPP不配置的远程终端。配置在远程终端的encapsulation ppp命令
  • 数据包没获得通过传输介质。此的多数常见原因是ISDN速率不匹配

问题的本质,从ISDN支架,是一端很可能连接在56k,当另一侧连接在64k时。很可能,本地或者远程电路不会支持默认64K连接。配置两端的尝试运行在56k。

拨号配置文件:

maui-soho-01(config)#interface Dialer1
maui-soho-01(config-if)#dialer string 81560 class 56k
! -- Dial 81560 and use the map-class named "56k" (defined below) maui-soho-01(config-if)#exit maui-soho-01(config)#map-class dialer 56k
! -- map-class named "56k" that was used with the dialer string ! -- in int Dialer1
maui-soho-01(config-map-clas)#dialer isdn speed 56
! -- Set the speed of the call to be 56k (default is 64k)

传统DDR (拨号图) :

maui-soho-01(config)#interface bri 0
maui-soho-01(config-if)#dialer map ip 10.1.1.1 name maui-nas-08 speed 56 81560
!-- The keyword speed 56 sets the outgoing call rate at 56k

可能的原因:两路由器不对认证协议达成协议(CHAP或PAP)使用

如果有debug输出类似于以下线路,这表明您的路由器和远端没有对认证协议达成协议使用:

*Mar  1 00:07:24.051: BR0:1 LCP: I CONFREQ [ACKrcvd] id 136 len 14
*Mar  1 00:07:24.055: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:07:24.059: BR0:1 LCP:    MagicNumber 0x1110C3C5 (0x05061110C3C5)
! -- An incoming CONFREQ (Config-Request) indicating the peer is
! -- willing to do PAP
*Mar  1 00:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] id 136 len 9
*Mar  1 00:07:24.063: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
! -- The router send a Configure-Negative-Acknowledge (CONFNAK) rejecting PAP
! -- The router suggests CHAP instead
*Mar  1 00:07:24.087: BR0:1 LCP: I CONFREQ [ACKrcvd] id 137 len 14
*Mar  1 00:07:24.091: BR0:1 LCP:    AuthProto PAP (0x0304C023)
*Mar  1 00:07:24.091: BR0:1 LCP:    MagicNumber 0x1110C3C5 (0x05061110C3C5)
! -- The peer once again requests PAP
! -- This is probably because PAP is the only protocol configured on the peer
! -- The router will once again CONFNAK PAP and suggest CHAP
*Mar  1 00:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] id 137 len 9
*Mar  1 00:07:24.099: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
! -- The router NAKs PAP and suggests CHAP for the 2nd time
*Mar  1 00:07:24.119: BR0:1 LCP: I TERMREQ [ACKrcvd] id 138 len 4
*Mar  1 00:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] id 138 len 4
! -- The two routers cannot agree on LCP parameters so the call is disconnected

在这种情况下,请验证您配置以下:

interface Dialer1
 encapsulation ppp
 ppp authentication chap pap callin
 ! -- This permits both CHAP and PAP and one-way authentication

关于质询握手验证协议(CHAP)的更多信息或密码认证协议,参考以下文档:

您能也使用Cisco支持社区进一步Ppp故障排除。

回到故障排除流程图


排除故障:PPP认证是否成功?

检查debug输出线路类似于此:
*Mar  1 00:06:36.943: BR0:1 PPP: Phase is UP

回到故障排除流程图


症状:PPP认证不成功

确保您配置以下线路:

interface Dialer1
 ppp chap hostname XXXXX
 ppp chap password YYYYY
 ppp pap sent-username XXXXX password YYYYY

在示例中,是您的用户名,并且YYYYY是您的密码。

注意:配置认证方法的仅用户名和密码您,并且您的对等体使用。例如,如果你们俩不会使用PAP,然后您不需要ppp pap sent-username命令。然而,如果是否是不确定的对等体支持PAP或CHAP,然后配置两个。

根据您的Cisco IOS软件版本和配置,密码在您的配置方面可能出现加密。如果这是实际情形,当执行show running-configuration命令,您时看到词“位7然后编号顺序”跟随的密码,例如在以下示例:

interface Dialer1
 ppp chap password 7 140005

在这种情况下,您不能验证是否配置的口令正确通过查看配置。要肯定密码正确,请输入配置模式并且再次删除并且配置密码。要识别调试的一密码失败,比较您的与下列的示例输出的debug输出。

如果此路由器将验证对等体,则请务必配置username username password password命令用户名是验证的对等`路由器供应的名称。

示例 1

一个消息类似那个下面意味着CHAP口令无效。

*Mar  1 00:16:54.403: BR0:1 CHAP: I CHALLENGE id 94 len 24 from "ISP"
! -- Incoming CHAP challenge
*Mar  1 00:16:54.407: BR0:1 CHAP: Using alternate hostname XXXXX
 ! -- Using alternate hostname configured with ppp chap hostname command 
*Mar  1 00:16:54.411: BR0:1 CHAP: Username ISP not found
*Mar  1 00:16:54.415: BR0:1 CHAP: Using default password
! -- Using password configured with ppp chap password command
*Mar  1 00:16:54.415: BR0:1 CHAP: O RESPONSE id 94 len 26 from "XXXXX"
! -- Sending response from "XXXXX" which is the alternate hostname for the router
*Mar  1 00:16:54.439: BR0:1 CHAP: I FAILURE id 94 len 25 msg is
"MD/DES compare failed"
! -- Incoming CHAP failure. The remote router failed to authenticate this router.
! -- Check the username and password configured on both routers
*Mar  1 00:16:54.447: BR0:1 LCP: I TERMREQ [Open] id 165 len 4
*Mar  1 00:16:54.451: BR0:1 LCP: O TERMACK [Open] id 165 len 4

提示:流入的CHAP故障(表示由CHAP :我失败)意味着对等体无法验证路由器。请使用在对等`路由器的debug ppp协商确定失败的确切的原因。

欲知使用ppp chap hostnameppp authentication chap callin参考的本文PPP认证更多信息发出命令

示例 2

一个消息类似那个可能下面含义CHAP用户名无效:

*Mar  1 00:18:34.831: BR0:1 CHAP: I CHALLENGE id 97 len 24 from "ISP"
! -- Incoming CHAP challenge
*Mar  1 00:18:34.835: BR0:1 CHAP: Using alternate hostname Xdwqdqw
 ! -- Using alternate hostname configured with ppp chap hostname command 
*Mar  1 00:18:34.839: BR0:1 CHAP: Username ISP not found
*Mar  1 00:18:34.839: BR0:1 CHAP: Using default password
! -- Using password configured with ppp chap password command
*Mar  1 00:18:34.843: BR0:1 CHAP: O RESPONSE id 97 len 28 from "Xdwqdqw"
! -- Sending response from "Xdwqdqw" which is the alternate hostname
! -- for the router
*Mar  1 00:18:34.867: BR0:1 CHAP: I FAILURE id 97 len 26
msg is "Authentication failure"
! -- Incoming CHAP failure. The remote router failed to authenticate
! -- this router. Check the username and password configured on both routers
*Mar  1 00:18:34.875: BR0:1 LCP: I TERMREQ [Open] id 171 len 4
*Mar  1 00:18:34.879: BR0:1 LCP: O TERMACK [Open] id 171 len 4

提示:流入的CHAP故障(表示由CHAP :我失败)意味着对等体无法验证路由器。请使用在对等`路由器的debug ppp协商确定失败的确切的原因。

使用ppp chap hostnameppp authentication chap callin命令,欲知更多信息,参考本文PPP认证

示例 3

一个消息类似下面意味着PAP口令无效:

*Mar  1 00:21:33.927: BR0:1 PAP: O AUTH-REQ id 3 len 18 from "XXXXX"
! -- Outgoing PAP Authentication Request from XXXXX
! -- XXXXX is the username configured in 
! -- ppp pap sent-username XXXXX password YYYYY
*Mar  1 00:21:33.947: BR0:1 PAP: I AUTH-NAK id 3 len 27 msg is
"Authentication failure"
! -- An incoming PAP failure. The peer could not authenticate this router
! -- Verify that the username and password configured on both routers
! -- are identical
*Mar  1 00:21:33.955: BR0:1 LCP: I TERMREQ [Open] id 182 len 4
*Mar  1 00:21:33.955: BR0:1 LCP: O TERMACK [Open] id 182 len 4
*Mar  1 00:21:33.959: BR0:1 PPP: Phase is TERMINATING
欲知参考配置和排除故障PPP口令验证协议(PAP)的本文的更多信息。

示例 4

一个消息类似下面意味着PAP用户名无效:

*Mar  1 00:20:41.023: BR0:1 PPP: Phase is AUTHENTICATING, by the peer
*Mar  1 00:20:41.031: BR0:1 PAP: O AUTH-REQ id 1 len 17 from "ewddew"
! -- Outgoing PAP Authentication Request from ewddew
! -- ewddew is the username configured in 
! -- ppp pap sent-username ewddew password YYYYY
*Mar  1 00:20:41.047: BR0:1 PAP: I AUTH-NAK id 1 len 27
msg is "Authentication failure"
! -- An incoming PAP failure. The remote router could not authenticate
! -- this router. Check the username and password configured on both routers
! -- Note the PAP authentication failure in example 3 and 4 are identical.
! -- Hence the only way to determine if the username, password or both are
! -- wrong is to run debug ppp negotiation on the authenticating router
*Mar  1 00:20:41.055: BR0:1 LCP: I TERMREQ [Open] id 178 len 4
*Mar  1 00:20:41.059: BR0:1 LCP: O TERMACK [Open] id 178 len 4
*Mar  1 00:20:41.063: BR0:1 PPP: Phase is TERMINATING

欲知参考配置和排除故障PPP口令验证协议(PAP)的本文的更多信息。

您能也使用Cisco支持社区进一步Ppp故障排除。

回到故障排除流程图


排除故障:PPP NCP (IPCP)相位是否完成?

在IPCP协商的关键要素是每个对等体地址。在IPCP协商前,每对等体是在两可能的状态之一中;或者它有一个IP地址或不。如果对等体已经有一个地址,发送在CONFREQ的该地址给另一对等体。如果地址是可接受对另一对等体, CONFACKis返回。如果地址不是可接受,回复是包含对等体的CONFNAK一个地址能使用。

这是不可能通过查看一条线路适当地识别的唯一的相位。为了肯定IP Control Protocol (IPCP)适当地出来,您需要验证IP地址在两个方向协商。查看您的调试为以下线路:

*Mar  1 00:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] id 26 len 10
*Mar  1 00:06:36.971: BR0:1 IPCP:    Address 194.183.201.1(0x0306C2B7C901)
并且
*Mar  1 00:06:37.011: BR0:1 IPCP: I CONFACK [ACKsent] id 4 len 10
*Mar  1 00:06:37.015: BR0:1 IPCP:    Address 194.183.201.2 (0x0306C2B7C902)
并且
*Mar  1 00:06:37.015: BR0:1 IPCP: State is Open

这三套线路可能不立即互相跟随。重要的是有,在其它选项中,在它下的一个地址的您证实是否流出的配置确认(O CONFACK)。

一定也流入配置确认(I CONFACK)用在它下的另一个IP地址。

最后,必须有阐明的线路, IPCP状态是开放的。在此以后,您应该那么顺利是能ping两个IP地址直接地从您的路由器。

回到故障排除流程图


症状:PPP NCP (IPCP)协商不成功

问题:IP地址协商发生故障

一个原因为什么IPCP可能发生故障归结于IP地址协商失败。例如, NAS可能尝试分配对客户端的一个地址,当客户端路由器安排一个不同的IP地址配置时或另一常见问题是,当客户端要求地址时,并且NAS没有任何地址可用为客户端。

在呼叫路由器上:

如果呼叫的路由器动态地分配IP地址到呼叫路由器,请验证您有ip address negotiated命令在拨号接口。

如果NAS Provider/ISP给您静态IP地址,请验证此IP地址(和子网掩码)在与ip address命令地址subnet_mask的拨号接口配置。

在呼叫的Router上:

保证接口控制连接(例如, int拨号程序x)有一个IP地址和分配对使用peer default ip address address命令的对等体的一个地址。

注意:如果客户端路由器有使用peer default ip address命令, IP地址配置您然后不需要分配地址

欲知参考拨号技术一文的更多信息:故障排除技术

问题:呼叫的路由器发生故障Dialer Profile绑定

如果认证的用户名不匹配拨号程序远程名配置在拨号接口下,则呼叫将由呼叫的路由器断开。下列是为这样错误输出的示例debug dialer :

在呼叫路由器上

以下调试显示在呼叫的路由器的一个坏Dialer Profile绑定造成的断开;

*Mar 15 03:19:13.050: BR0:1 CHAP: O CHALLENGE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.094: BR0:1 CHAP: I CHALLENGE id 32 len 33 from "maui-soho-01"
*Mar 15 03:19:13.094: BR0:1 CHAP: O RESPONSE id 32 len 33 from "maui-soho-03"
*Mar 15 03:19:13.134: BR0:1 CHAP: I SUCCESS id 32 len 4 ! -- CHAP authentication is successful
*Mar 15 03:19:13.222: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xA0
*Mar 15 03:19:13.226: Cause i = 0x8090 - Normal call clearing ! -- We have received (RX) a DISCONNECT from the peer ! -- We have to move troubleshooting to the called router
*Mar 15 03:19:13.238: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x20
*Mar 15 03:19:13.242: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:19:13.250: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is TERMINATING
*Mar 15 03:19:13.254: BR0:1 LCP: State is Closed
*Mar 15 03:19:13.254: BR0:1 PPP: Phase is DOWN
*Mar 15 03:19:13.254: BRI0:1 DDR: disconnecting call

注意:从被呼叫端的调试在排除故障不帮助此问题除了表明对等体断开了呼叫。排除故障对呼叫的路由器的移动。

在呼叫的Router上:

以下调试显示呼叫失败由于Dialer Profile绑定问题:

*Mar 15 03:54:09.804: BR0:1 CHAP: O SUCCESS id 33 len 4
*Mar 15 03:54:09.808: BR0:1 CHAP: Processing saved Challenge, id 33
*Mar 15 03:54:09.812: BR0:1 DDR: Authenticated host maui-soho-03 with no matching dialer profile ! -- a binding failure because the dialer remote-name ! -- does not match the authenticated username
*Mar 15 03:54:09.816: BR0:1 DDR: disconnecting call
*Mar 15 03:54:10.086: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
*Mar 15 03:54:10.093: BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]

解决方案:

配置dialer pool number命令在拨号接口。池编号必须匹配在物理接口配置的池编号。

在拨号程序接口上配置 dialer remote-name 命令。指定的名称必须与远程路由器为进行身份验证而提供的用户名精确匹配。在本例中,认证的用户名是maui-soho-03。

欲知关于绑定问题的更多进一步故障检修信息参考设定及故障排除拨号文本

您能也使用Cisco支持社区进一步Ppp故障排除。

回到故障排除流程图


连接后的问题

症状:过早呼叫断开或呼叫不断开

如果呼叫断开或意外呼叫从未断开,请检查拨号空闲超时和关注数据流定义。您能使用debug dialer packet命令发现特定信息包是否是有趣。例如:

Apr 26 01:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5), 64 bytes, 
outgoing uninteresting (list 101)
Apr 26 01:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1), 100 bytes,
outgoing interesting (list 101)
在上面的示例中,OSPF hello 是每个访问列表 101 的非相关流量,而第二个数据包是每个访问列表 101 的相关流量。
  1. 在拨号程序接口配置中调整拨号程序空闲超时。默认是 120 秒,但您可能希望根据自己的需求增大或降低该值。

  2. 更改相关流量定义(已通过 dialer-list 命令配置)。如果呼叫断开您可以过早地希望更加松散定义关注数据流。如果呼叫从未断开更改您的触发数据流定义更加限制式。例如,您可以将路由协议流量定义为不相关。以下是相关流量定义的示例:
    access-list 101 remark Interesting traffic for dialer-list 1
    access-list 101 deny ospf any any
    !--- mark OSPF as uninteresting
    !--- This will prevent OSPF hellos from keeping the link up.

    access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
    ! -- This will prevent periodic ntp traffic from keeping ! -- the link up indefinitely.

    access-list 101 permit ip any any
    ! -- All other IP traffic is interesting.
    ! -- Change this depending on your traffic needs.

    dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer ! -- interface using dialer-group 1

    欲知参考拨号技术一文的更多信息:概述和解释

症状:路由器周期地拨号连接

在某些情况下,您可以注意到路由器周期地拨号连接,即使没有要求链路的明显的用户数据流是UP。这能导致ISDN服务在一个Per-minute基本类型被充电的高长途费用。

多数常见原因是生成日常流量的进程(例如路由协议、ntp, snmp等)可能疏忽地被选定作为触发的。排除故障此是一个两步问题:

  1. 识别导致链路拨号的流量。
  2. 指派该流量如非触发的。

识别导致林克拨号的流量。

要识别导致链路拨号的流量,您需要启用debug dialer packet。监控路由器,当ISDN链路发生故障时并且注意该若干定期的关注数据流尝试启动链路。

提示:除非特别地需要,请选定在路由器配置的所有路由协议如非触发的。

以下示例显示作为有趣的被指示的周期的OSPF Hellos :

*Mar 15 00:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5),
  64 bytes, outgoing interesting (ip PERMIT)

识别的唯一方法上述数据包是OSPF Hello是从为OSPF定义的目的地址(d=224.0.0.5)。下表列出用于一些普通的路由协议的地址:

路由协议
定期的目的地址
更新或Keepalive
RIPv1
255.255.255.255
RIPv2
224.0.0.9
EIGRP
224.0.0.10
OSPF
224.0.0.5

应该标记造成路由器的流量拨号(路由procol或其他日常流量)作为非触发的。

指派日常流量如非触发的

更改相关流量定义(已通过 dialer-list 命令配置)。在本例中,请定义OSPF和NTP流量如非触发的。以下是相关流量定义的示例:

access-list 101 remark Interesting traffic for dialer-list 1
access-list 101 deny ospf any any
!--- mark OSPF as uninteresting
!--- This will prevent OSPF hellos from keeping the link up.

access-list 101 deny udp any any eq ntp ! -- Define ntp traffic as NOT interesting.
! -- This will prevent periodic ntp traffic from keeping ! -- the link up indefinitely.

access-list 101 permit ip any any
! -- All other IP traffic is interesting.
! -- Change this depending on your traffic needs.

dialer-list 1 protocol ip list 101 ! -- this interesting traffic is applied to the dialer interface ! -- using dialer-group 1

欲知参考拨号技术一文的更多信息:概述和解释

注意:OSPF有呼叫能也使用这里的需求电路的一个功能。参考本文OSPF需求电路为什么继续启动林克欲知更多信息

症状:第二B信道不连接

在许多情况下,而其他B信道逗留虚度光阴,路由器在一B信道可能只连接。关于排除故障参考ISDN BRI链路的本文故障排除第二个B-通道呼叫失败的此问题的更多信息。

IP 连通性问题

如果ISDN链路出来,但是您不能通过在链路间的流量然后问题很可能是路由或NAT相关问题。参考Cisco支持社区欲知更多故障排除信息。

如果使用ISDN链路作为备份对WAN连接,则参考配置和故障排除DDR备份文件

相关的思科支持社区讨论

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


相关信息


Document ID: 20602