ISDN BRI 故障排除流程图
目录
简介
本文档帮助您排除ISDN基本速率接口(BRI)拨号访问故障。在如下所示的流程图和示例输出中，我们已使用拨号程序配置文件建立到另一个的ISDN BRI连接。但是，与其他路由器（如分支机构）的连接以及使用传统按需拨号路由(DDR)时，也采用相同的故障排除步骤。
注意：您还可以使用思科支持社区来帮助您解决ISDN问题。
有关ISDN和DDR的介绍信息，请参阅Cisco Learning Connection中的音频培训。
流程图
单击下面的链接可获取有关项目的详细信息。使用浏览器的后退按钮返回此流程图。
故障排除：如何登录和捕获这些调试
您可以通过连接到PC串行端口的控制台电缆或通过telnet连接到路由器。
如果需要通过控制台连接到路由器，请参阅为控制台连接应用正确的终端仿真器设置。如果您的路由器已经设置为在以太网上连接，并且您希望使用telnet连接到您的路由器，只需使用telnet客户端连接到路由器的以太网IP地址。
无论如何（控制台或telnet），最好使用允许您保留会话期间收到的输出历史记录的客户端，因为您可能需要在调试输出中回滚以查找特定消息。
在调试输出和日志消息上激活毫秒。出现提示时，输入在路由器上配置的密码并进入启用模式：
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连接，请键入terminal monitor，如下所示：
router#terminal monitor router#
在此之后，在下面输入debug命令：
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。以下是成功调用的调试输出示例。流程图中确定的不同阶段将突出显示。
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#
故障排除：路由器是否尝试拨号？
为了确定路由器是否尝试发出呼叫，请验证主叫路由器的调试输出中是否有以下线路：
*Mar 1 00:06:36.395: BR0 DDR: Attempting to dial 8134
在调试输出中，8134是路由器尝试拨号的ISDN目录号码。此编号是使用dialer string或dialer map命令指定的。
症状：路由器不尝试拨号
如果您的路由器没有尝试拨号，则有多种可能：
没有任何调试输出
如果根本没有调试输出，这很可能是因为您发送的IP数据包甚至没有路由到拨号器接口。造成这种情况的最常见原因是：
- 验证在拨号程序接口上配置了 IP。您应该在拨号器接口上或ip未编号接口(其中接口是up/up接口，如ethernet x 、loopback x等)或ip地址协商（如果客户端将从NAS获取IP地址）。 如果使用传统DDR，则应在物理接口（例如，接口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 X或show interface bri X命令确保接口处于up/up状态（欺骗）。
如果接口管理性关闭，则在接口配置模式下使用no shutdown命令。
如果接口处于备用状态，则拨号器或BRI接口是连接启用的备份。您可以删除主接口下的backup interface命令，或从主接口拉出电缆。
"有debug输出但没有""Attempting to Dial"" 消息"
在这种情况下，可能具有路由到该接口的 IP 数据包，但是路由器出于某种原因而将其丢弃且没有启动呼叫。查看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-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，在拨号程序接口中配置了拨号程序池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.
在这种情况下，拨号器接口上未配置拨号器字符串。路由器想发出呼叫，但不知道要呼叫的ISDN目录号码。定义拨号程序字符串：
interface Dialer1 dialer string 8134
有关更多故障排除信息，请参阅使用debug isdn q931命令排除ISDN BRI第3层故障文档中的“呼叫路由器不发送SETUP消息”部分。
故障排除：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呼叫未成功连接
- 如果您看到类似以下的输出，请验证ISDN电缆是否已同时插入路由器和Telco插孔。
*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)
- 检验ISDN电路是否正常运行。使用show isdn status命令验证第1层是活动的，第2层是MULTIPLE_FRAME_ESTABLISHED，并且SPID（如果需要）有效。有关详细信息，请参阅文档使用show isdn status命令进行BRI故障排除。
如果您从Cisco设备获得show isdn status命令的输出，则可以使用Cisco CLI Analyzer显示潜在问题和修复。要使用Cisco CLI Analyzer，您必须是注册用户、已登录并启用JavaScript。 - 验证配置的ISDN拨号程序字符串是否正确。请记住，当您通过PBX连接时，可能必须添加前导零、九或其他数字才能获得外线。
- 如果连接使用长途运营商，请联系您当地的电信公司和长途运营商以验证服务是否已激活。本地Telco经常错误配置ISDN电路，这样出局ISDN长途呼叫不会通过被切换到适当的长途提供商网络上。您还应验证长途电信运营商网络是否正常工作。
在美国，如果电信公司或长途运营商无法纠正问题，您可能希望使用预订长途交换运营商(PIC)。PIC代码是七位前缀，用于标识美国到本地交换运营商(LEC)的长途运营商。 这允许客户使用不同的长途运营商进行单独呼叫。PIC编码配置作为对呼叫号码的前缀。多数PICs是格式1010xxx的。
使用no dialer string xxxxx或no dialer map来删除现有号码，然后配置新号码。
例如，拨号程序字符串10103215125551111。
- 查找ISDN断开消息。
Cisco IOS®软件对此断开消息中的原因代码进行解码，并提供明文消息，其中通常包含导致问题原因的有用信息。您可能在此处找到的字符串包括：
- 未分配或未赋值的数字
- 目的地不兼容（这两个都表示拨号号码可能不正确）
- 忙号（表示被叫方忙）
- 临时故障（表示Telco网络出现临时故障）
要查找特定断开原因的可能原因，请参阅了解debug isdn q931 Disconnect Cause Codes。
例如，由于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
- 如果您的电信公司已向您提供要使用的服务配置文件标识符(SPID)，请确保在BRI接口上配置了这些SPID。SPID通常仅在美国使用，与NI和DMS交换机类型（5ess交换机类型不需要SPID）一起使用。
interface BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112
您可以使用show isdn status命令验证SPID是否正确。
有关详细信息，请参阅文档ISDN BRI SPID故障排除。
如果您从Cisco设备获得show isdn status命令的输出，则可以使用Cisco CLI Analyzer显示潜在问题和修复。要使用Cisco CLI Analyzer，您必须是注册用户、已登录并启用JavaScript。 - 如果上述步骤未解决问题，请使用文档“使用debug isdn q931命令排除ISDN BRI第3层故障”进一步故障排除。
故障排除：PPP LCP阶段是否成功？
在调试输出中，您应看到一条消息行显示如下：
*Mar 1 00:06:36.887: BR0:1 LCP: State is Open
如果您看到此行，则表明链路控制协议(LCP)已成功协商。除打开以外的任何状态都表示LCP失败。
症状：PPP LCP阶段不成功
可能的原因：未配置PPP
如果调试输出类似于以下行，则表明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)
从调试输出中注意，路由器不发送任何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）
如果您的调试输出类似于以下行，则表明您的路由器和远程端未同意使用身份验证协议：
*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)或密码身份验证协议(PAP)的详细信息，请参阅以下文档：
- 了解和配置 PPP CHAP 认证
- 使用 ppp chap hostname 和 ppp authentication chap callin 命令的 PPP 认证
- PPP 口令认证协议 (PAP) 的配置与故障排除
您还可以使用思科支持社区进一步排除PPP故障。
故障排除：PPP身份验证是否成功？
检查类似以下行的调试输出：
*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
在示例中，XXXXX是您的用户名，YYYYY是您的密码。
注意：仅配置您和您的对等设备所使用的身份验证方法的用户名和密码。例如，如果您两个都不使用PAP，则不需要ppp pap sent-username命令。但是，如果您不确定对等体是支持PAP还是CHAP，请同时配置两者。
根据您的Cisco IOS软件版本和配置，您的配置中可能会显示加密的密码。如果是这种情况，在执行show running-configuration命令时，您会看到“password”一词，后跟数字7，然后是数字序列，如以下示例所示：
interface Dialer1 ppp chap password 7 140005
在这种情况下，您无法通过查看配置来验证配置的密码是否正确。要确保密码正确，只需进入配置模式，然后再次删除并配置密码。要确定调试中的密码故障，请将调试输出与下面的示例输出进行比较。
如果此路由器将对对等体进行身份验证，则请务必配置命令username username password password，其中username是对等路由器提供的用于身份验证的名称。
示例 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指示：I FAILURE)表示对等体无法对路由器进行身份验证。在对等路由器上使用debug ppp negotiation确定故障的确切原因。
有关详细信息，请参阅使用ppp chap hostname和ppp 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指示：I FAILURE)表示对等体无法对路由器进行身份验证。在对等路由器上使用debug ppp negotiation确定故障的确切原因。
有关详细信息，请参阅使用 ppp chap hostname 和 ppp 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)故障。
您还可以使用思科支持社区进一步排除PPP故障。
故障排除：PPP NCP(IPCP)阶段是否完成？
IPCP中协商的关键元素是每个对等体的地址。在IPCP协商之前，每个对等体处于两种可能的状态之一；要么它有IP地址，要么它没有。如果对等体已经有地址，它会在CONFREQ中将该地址发送给另一对等体。如果地址对其他对等体可接受，则返回CONFACK。如果地址不可接受，则回复是包含供对等体使用的地址的CONFNAK。
这是仅仅查看一行无法正确识别的唯一阶段。为了确保IP控制协议(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地址协商失败。例如，当客户端路由器配置了不同的IP地址时，NAS可能会尝试为客户端分配地址，或者另一个常见问题是当客户端请求地址而NAS没有任何可用于客户端的地址时。
在主叫路由器上：
如果被叫路由器动态地为主叫路由器分配IP地址，请验证您在拨号器接口中协商了ip address命令。
如果NAS Provider/ISP已为您提供静态IP地址，请使用命令ip address address subnet_mask验证拨号器接口中是否配置了此IP地址（和子网掩码）。
在被叫路由器上：
确保控制连接的接口（例如，int Dialer x）具有IP地址，并且使用peer default ip address address命令为对等体分配地址。
注意：如果客户端路由器配置了IP地址，则您无需使用peer default ip address命令分配地址
问题：被叫路由器无法绑定拨号程序配置文件
如果经过身份验证的用户名与拨号器接口下配置的拨号器远程名称不匹配，则呼叫将被被叫路由器断开。以下是此类错误的debug dialer输出示例：
在主叫路由器上:
以下调试显示由于被叫路由器上的拨号程序配置文件绑定错误而导致的断开连接；
*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
注意：来自被叫方的调试在排除此问题方面没有帮助，只是表明对等体已断开呼叫。将故障排除移至被叫路由器。
在被叫路由器上：
以下调试显示由于拨号程序配置文件绑定问题导致呼叫失败：
*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。
有关绑定问题的更多故障排除信息，请参阅文档配置和故障排除拨号程序配置文件。
您还可以使用思科支持社区进一步排除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 的相关流量。
- 在拨号器接口配置中调整拨号器空闲超时。默认是 120 秒，但您可能希望根据自己的需求增大或降低该值。
- 更改相关流量定义（已通过 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
症状：路由器定期拨打连接
在某些情况下，您可能会发现路由器会定期拨打连接，即使没有明显的用户流量需要链路接通。这会导致ISDN服务每分钟收费的高收费。
最常见的原因是，生成定期流量的流程（如路由协议、ntp、snmp等）可能会被无意指定为有趣的。故障排除分为两步：
- 确定导致链路拨号的流量。
- 将该流量指定为不相关。
确定导致链路拨号的流量。
要确定导致链路拨号的流量，您需要启用debug dialer packet。在ISDN链路关闭时监控路由器，并观察尝试打开链路的一些定期相关流量。
提示：除非特别需要，否则将路由器上配置的所有路由协议指定为不相关协议。
以下示例显示定期OSPF问询被标记为相关：
*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
|
导致路由器拨号的流量（路由协议或其他定期流量）应标记为不相关。
将定期流量指定为非关注流量
更改相关流量定义（已通过 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相关问题。有关故障排除的详细信息，请参阅思科支持社区。
如果将ISDN链路用作WAN连接的备份，请参阅文档DDR备份配置和故障排除。
反馈