HCTE第3章广域网故障排除(V2[1].0)

目录
第3章串行链路故障排除 (61)
3.1 PPP、 HDLC和SLIP故障排除综述 (61)
3.1.1 串行链路配置的常见问题 (63)
3.1.2其他相关问题 (63)
3.1.3 串行链路故障排除的一般步骤 (66)
3.2 PPP、 HDLC和SLIP故障相关的display、debugging命令介绍 (68)
3.2.1 debugging ppp (68)
3.2.2 display ppp mp (69)
3.2.3 debugging hdlc (70)
3.2.4 debugging slip (70)
3.3 PPP、 HDLC和SLIP典型案例分析 (71)
3.3.1链路自环导致链路层协议DOWN (71)
3.3.2和某公司路由器互通时验证不通过 (72)
3.3.3 两端封装的链路层协议不同导致链路层不能UP (72)
3.4 帧中继协议故障排除综述 (73)
3.4.1 帧中继配置的常见问题 (73)
3.4.2其他相关问题 (75)
3.4.3 帧中继故障排除的一般步骤 (76)
3.5帧中继故障相关的display、debugging命令 (77)
3.5.1 display fr lmi-info (77)
3.5.2 display fr map-info (77)
3.5.3 display fr statistics (78)
3.5.4 display fr pvc-info (79)
3.5.5 display fr inarp-info (79)
3.5.6 debugging fr (80)
3.5.7 帧中继debugging命令使用建议 (82)
3.6 Frame Relay典型案例分析 (82)
3.6.1 接口物理层UP，但链路层协议DOWN (82)
3.6.2 接口协议UP，但不能PING通 (84)
3.6.3 MAP属性与路由协议问题（如RIP等组播或广播型路由协议） (85)
3.6.4 在帧中继网络运行OSPF协议 (87)
3.6.5 与部分网状网络及子接口完全连接的问题 (89)
3.7 X.25协议故障排除综述 (91)
3.7.1 X.25协议简介 (91)
3.7.2 X.25配置的常见问题 (92)
3.7.3 X.25故障排除的一般步骤 (93)
3.8 X.25故障相关的display、debugging命令 (93)
3.8.1 display x25 map (93)
3.8.2 display x25 switch-table svc (94)
3.8.3 display x25 switch-table pvc (95)
3.8.4 display x25 vc (95)
3.8.5 debugging x25 (97)
3.8.6 x25 debugging命令使用建议 (98)
3.9 X.25典型案例分析 (98)
3.9.1 X.25的参数不一致导致PING大包不通 (98)
3.9.2 两台路由器通过X.25交换机互通问题 (100)
3.9.3 使用X.25网卡的PC不能和中心服务器通信 (100)
第3章串行链路故障排除
3.1 PPP、 HDLC和SLIP故障排除综述
串行链路上支持的链路层协议有PPP、HDLC、Frame Relay、X.25、SLIP
等，本部分主要讲述PPP、 HDLC和SLIP的常见故障和排除方法。

PPP协议是提供在点到点链路上传递、封装网络层数据包的一种数据链路层
协议。

PPP主要由两类协议组成：链路控制协议族(LCP)和网络控制协议族
(NCP)，链路控制协议主要用于建立，拆除和监控PPP数据链路，网络控制
协议族主要用于协商在该数据链路上所传输的数据包的格式与类型。

同时，
PPP还提供了用于网络安全方面的验证协议族(PAP和CHAP)。

PPP支持的
协议有LCP、PAP、CHAP、MP、CBCP、CCP、IPCP、IPXCP、BCP
等。

PPP由于能够提供验证，易扩充，支持同异步而获得较广泛的应用。

PPP在建立链路之前要进行一系列的协商过程。

过程如下：
PPP首先进行LCP协商，协商内容包括：MRU(最大传输单元)、魔术字(magic
number)、验证方式、异步字符映射等选项(详见RFC1661)；LCP协商成功
后，进入Establish(链路建立)阶段。

如配置了CHAP或PAP验证，便进入
CHAP或PAP验证阶段；验证通过后才会进入网络阶段协商(NCP)，如IPCP、
IPXCP、BCP的协商。

任何阶段的协商失败都将导致链路的拆除。

如果PPP
链路上发送的Echo Request 报文产生丢失，则认为线路出现故障，在连续丢
失预定个数之后，将链路复位，以免过多的无效数据传输。

异步字符映射用
于数据的同异步转换，当PPP从异步端口接收到报文时，要将异步报文转换
为同步报文；当向异步端口发送报文时，要将同步报文转换为异步报文。

PPP运行过程可参见下图。

图3-1PPP运行流程图
MP是MultiLink PPP的缩写，是人们出于增加带宽的考虑，将多个PPP链路捆绑使用产生的。

MP允许将报文分片，分片将在多个点对点链路上送到同一个目的地。

MP方式下接口工作进程如下（以虚拟接口模板下的MP为例）：
如果使用虚拟接口模板，MP有两种捆绑形成方式：
(1)根据终端描述符（Endpoint Discriminator）和验证得到的用户名进行捆绑。

●首先和对端进行LCP协商，协商过程中，除了协商一般的LCP参数外，还验
证对端接口是否也工作在MP方式下。

●然后对PPP进行验证，得到对方的用户名。

如果在LCP协商中得知对端不
工作在MP方式下，则在LCP协商成功后，进行一般的NCP协商步骤，不进行MP捆绑。

否则根据用户名找到为该用户指定的虚拟接口模板，并以该虚拟模板的各项NCP参数（如IP地址等）为参数进行NCP协商，物理接口配置的NCP参数不起作用。

NCP协商通过后，即可建立MP链路，用更大的带宽传输数据。

(2)无需终端描述符和验证的捆绑：
●首先和对端进行LCP协商，协商过程中，除了协商一般的LCP参数外，还验
证对端接口是否也工作在MP方式下，如果配置了验证还要进行验证。

●如果在LCP协商中得知对端不工作在MP方式下，则在LCP协商成功后，进
行一般的NCP协商步骤，不进行MP捆绑。

否则根据配置指定的虚拟接口模板的各项NCP参数（如IP地址等）为参数进行NCP协商，物理接口配置的NCP参数不起作用。

NCP协商通过后，即可建立MP链路，用更大的带宽传输数据。

由于在PPP的一系列协商和验证过程中，任何一个阶段的协商或验证不通过，都会导致链路的拆除，所以可能引起PPP链路故障的因素也很多。

HDLC（High Data Link Control，高级数据链路控制），是一种面向比特的链路层协议。

其最大特点是不需要规定数据必须的字符集，对任何一种比特流，均可以实现透明的传输。

HDLC可以承载IP与IPX协议，有简单的链路维护功能。

SLIP（Serial Line Internet Protocol，串行链路因特网协议）定义了一种通过异步串行线路发送包的方法。

SLIP不提供地址协商、错误检测、链路维护与修正及压缩算法，是一种最简单的链路层协议。

3.1.1 串行链路配置的常见问题
1. 物理链路的配置不当导致链路不能互通
由于物理接口的工作模式、时钟选择、波特率设置等不匹配导致物理链路不
能UP或者不能互通报文。

同异步串口上常用的配置有：时钟选择(clock)、时
钟反转(invert receive-clock、invert transmit-clock)、同异步模式选择
(physical-mode)、波特率设置(baudrate)等命令，详见《VRP用户手册配置
指导》接口配置部分。

在物理链路不通的时候，打开PPP的报文调试开关，通常可以看到只有发出
的报文，而没有接收到的报文。

如果用display interface命令查看接口报文统
计信息，也可以发现接收到的报文数没有增长，或者有大量的接收错误（input
errors）。

2. 参数设置不当导致和某些设备互通时协商不通过
有些非标准设备的协商项处理可能与Quidway路由器不兼容，导致协商某些
参数时不能通过协商，这种情况在实际应用中比较少见。

若该协商项不是必
须，也可以通过修改两端设备的相关参数设置来取消该协商项。

3. MP绑定参数设置错误
在使用MP绑定的时候，低端路由器上缺省可以绑定16条链路，当需要绑定
的链路超过16条时，需要在系统视图下使用ppp mp max-bind命令来改变允
许绑定的最大链路数。

系统可以根据接口接收到的用户名或终端标识符来进
行MP捆绑，将拥有相同用户名或终端标识符的接口捆绑到同一个虚模板接口
之上。

用户名是指PPP链路进行PAP或CHAP验证时所接收到的对端用户
名；终端标识符是用来唯一标识一台路由器的标志，是指进行LCP协商时所
接收到的对端终端标识符。

4. HDLC的keepalive设置不匹配
使用HDLC协议时，两端接口的keepalive设置应相等，至少不能相差太多。

如果一端配置了timer hold（缺省为10秒），而另外一端配置了undo timer
hold，则一端接口的链路层协议状态会变为DOWN，而另一端为UP。

3.1.2 其他相关问题
1. 物理链路故障导致PPP链路不能UP
由于传输线路故障造成链路不通、自环、误码率过高等问题，也会表现为PPP
链路故障。

这样的问题可以通过PPP的调试信息和接口收发数据的统计信息
初步定位问题原因，再检查传输线路，排除故障。

这一类问题和前面提到的物理链路配置不当造成故障的现象类似，所以发现接口收发数据有问题时还是应当优先检查接口的物理配置。

如果传输线路发生自环，从调试信息中可以看到接口上收发的报文内容和长度都相同，魔术字也一样。

PPP协商过程中，如果连续多次接收的报文和前面发送的报文都相同，则可以认定线路发生了自环。

从接口收发报文的统计信息来看，收到的报文和发送的报文个数、字节数都相同，这也是接口发生自环的特征。

有时实际的传输线路发生自环故障表现的现象比较特殊，例如既能收到自己发出的报文也可以收到对端发出的报文。

*0.58113771 RTD PPP/8/debug2:
PPP Packet:
Serial1/0 Output LCP(c021) Pkt, Len 18
State reqsent, code ConfReq(01), id 94, len 14
MRU(1), len 4, val 05dc
MagicNumber(5), len 6, val 0376f72f
*0.58113771 RTD PPP/8/debug2:
PPP Packet:
Serial1/0 Input LCP(c021) Pkt, Len 18
State reqsent, code ConfReq(01), id 94, len 14
MRU(1), len 4, val 05dc
MagicNumber(5), len 6, val 0376f72f
<Quidway>display interface s 1/0
Serial1/0 current state :UP
Line protocol current state :DOWN
Description : Serial1/0 Interface
The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
Internet Address is 1.1.1.2/24
Link layer protocol is PPP, loopback is detected
LCP closed
Output queue : (Urgent queue : Size/Length/Discards) 0/50/0
Output queue : (Protocol queue : Size/Length/Discards) 0/500/0
Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0
Physical layer is synchronous, Loopback,Baudrate is 64000 bps
Interface is DCE, Cable type is V35
Last clearing of counters: Never
Last 300 seconds input rate 2.89 bytes/sec, 23 bits/sec, 0.20 packets/sec
Last 300 seconds output rate 2.54 bytes/sec, 20 bits/sec, 0.20 packets/sec
Input: 13745 packets, 256235 bytes
0 broadcasts, 0 multicasts
0 errors, 0 runts, 0 giants
0 CRC, 0 align errors, 0 overruns
0 dribbles, 0 aborts, 0 no buffers
0 frame errors
Output:13745 packets, 256235 bytes
0 errors, 0 underruns, 0 collisions
0 deferred
DCD=UP DTR=UP DSR=UP RTS=UP CTS=UP
2. 和某些非标准设备使用PPP互通时协商不通过
PPP连接建立过程要经过几个协商阶段，至少有LCP、还可能有IPCP、IPXCP、BCP、CBCP、CCP等协商过程，每一个协商过程有多个协商项。

如果对端设备的某个协商项的协商过程处理不妥，可能导致协商无法通过，链路不能建立。

但这种情况比较少见，一般经过几次协商后，PPP会放弃对端不支持的协商项，而让链路成功建立。

一般通过查看ppp调试信息可以看到是哪些项协商不通过。

3. 使用异步口互通时对端设备不支持字符转义
在异步口封装PPP协议时，一般在LCP协商阶段会协商异步字符转义映射表（ACCMP）。

要求对端按协商的结果对指定的字符转义后发送过来。

例如本地协商到的ACCMAP是0X000A0000，表示要求对端对0X11和0X13进行转义。

转义的操作一般由异步串口的硬件电路完成，硬件不支持时也可以使用软件完成。

若对端不能按照PPP协商的结果完成字符转义，可能会导致本地收到的报文内容被改变，不能正常通讯。

SLIP协议中虽然没有协商过程，但也有固定的转义规则，若对端不支持SLIP 转义，也会使本端收到错误的报文。

4. 没有接口路由导致PPP 链路不可用
这种情况下此时LCP已经是OPENED状态，但是Ping报文无法互通，可考虑路由的原因，可以查看是否有对端的路由。

例如，有时在没有配置IP地址的时候PPP已经协商通过，配置IP地址后PPP不会自动重新协商，也不能添加到对端的直连路由，这是需要将端shutdown/undo shutdown，使PPP 重新协商，才能添加直连路由。

3.1.3 串行链路故障排除的一般步骤
从前面的概念所知，PPP作为数据链路层协议，需要由物理层提供数据收发
服务，并为网络层提供数据报文的封装，网络层参数协商等功能。

因此利用
PPP来解决设备问题时，也应该主要从这两方面入手。

1. 物理层问题分析
设备表现为广域网接口无法正常使用时，首先应该从物理层开始检查。

使用
display interface命令查看接口信息，例如执行命令display interface bri
0/0(BRI接口 0/0）或display interface serial 0/0 (串口 0/0)，根据显示信息
中的“硬件设备状态”和“LCP状态”判断物理层是否正常。

如下是一个Quidway AR28-31路由器的例子：
<Quidway>display interface Serial 1/0
Serial1/0 current state :UP
Line protocol current state :DOWN
Description : Serial1/0 Interface
The Maximum Transmit Unit is 1500, Hold timer is 10(sec)
Internet Address is 1.1.1.2/24
Link layer protocol is PPP
LCP reqsent
Output queue : (Urgent queue : Size/Length/Discards) 0/50/0
Output queue : (Protocol queue : Size/Length/Discards) 0/500/0
Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0
Physical layer is synchronous, Loopback,Baudrate is 64000 bps
Interface is DCE, Cable type is V35
Last clearing of counters: Never
Last 300 seconds input rate 11.09 bytes/sec, 88 bits/sec, 0.70
packets/sec
Last 300 seconds output rate 11.09 bytes/sec, 88 bits/sec, 0.70
packets/sec
Input: 14123 packets, 262139 bytes
0 broadcasts, 0 multicasts
0 errors, 0 runts, 0 giants
0 CRC, 0 align errors, 0 overruns
0 dribbles, 0 aborts, 0 no buffers
0 frame errors
Output:14118 packets, 257681 bytes
0 errors, 0 underruns, 0 collisions
0 deferred
DCD=UP DTR=UP DSR=UP RTS=UP CTS=UP
Serial1/0 is up,表明物理层状态UP，,此外Serial1/0可能为down, administratively down,standby，其中down说明物理层工作异常，应检查物理层配置及设备问题。

administratively down，说明物理层被人为关闭。

此时可以执行undo shutdown命令手工打开此端口。

standby是在使用接口备份功能，备份口的一种状态，也表示接口物理层不可用。

LCP状态也表明了物理层是否向链路层上报lowerup消息，从图3-1PPP运行流程图可知。

物理层未发送lowerup，PPP未发送open消息，LCP应处于initial状态；如物理层发送了lowerup，PPP已发送 open消息，发出CONFREQ报文LCP 应处于req-send状态；如物理层发送了lowerup，PPP已发送open消息，发出CONFREQ报文和CONFACK报文， LCP应处于ACKSENT状态，如物理层发送了lowerup，PPP未发送 open消息，LCP应处于starting状态。

如物理层未通，应先查找物理层未通的原因。

2. LCP问题分析
执行命令display interface bri 0/0 (BRI接口 0/0）或display interface serial 0/0 (串口 0/0)，如显示LCP协议未进入OPENED状态，可考虑为LCP的问题。

此方面的问题一般较少出现，如出现应该打开debugging ppp packet all，首先检查物理接口的报文收发是否正常，如果确认接口的报文收发正常，并且有大量的CONFNAK、CONFREJ报文出现，或者出现TERMACK、CODEREJ、PROTREJ之类的报文，可以说明是协商的问题，再根据报文协商项内容分析无法协商成功的原因。

3. 验证问题分析
使用display interface命令查看接口信息，如显示LCP协议进入OPENED状态，而IPCP依然为Initial状态，或者LCP变为OPENED状态后又很快重新开始协商，可考虑为验证的问题，由于此状态为临时状态，不易观察，也可通过debugging ppp all来观察。

如果成功协商了验证，PPP会打印出PAP 或CHAP验证的报文，如果验证失败，会打印出“PPP authentication failed”信息，可以根据报文的具体内容分析验证失败的原因。

有时配置了验证，但是LCP协商过程中该协商项被拒掉，LCP进入OPENED状态会立即重新协
商，此时若通过debug ppp all观察，可以看到对端未通过验证的提示信息，
例如“The opposite terminal haven't pass the chap authentication!”。

4. IPCP问题分析
使用display interface命令查看接口信息，如显示LCP协议进入OPENED状
态，而IPCP处于REQ_SEND或ACK_RCVD，并观察PPP报文有大量的
IPCP报文收发，可说明路由器IPCP协商有问题。

若IPCP处于STOPPED
状态，也可能是收到IPCP的TERMREQ或CODEREJ导致状态迁移。

阅读
IPCP报文，可分析出问题原因。

由于IPCP必须协商的参数为IP地址，其他
为可选择参数，一般来说是IP地址配置有问题，无法进行IPCP协商。

此时
应给两端接口配置IP地址，此外如果是访问Internet网，可不配置IP地址，
但应该配置ip address ppp-negotiate。

5. 其他问题分析
如LCP、IPCP均已经进入OPENED状态，但是Ping报文无法互通，可考虑
路由的原因，可采用直接ping此接口对端的IP地址，如能够互通，证明PPP
对IP报文的封装情况正常。

如依然有问题，但LCP和IPCP始终处于OPENED
状态，可考虑是否链路误码率较高，此情况比较少见。

以上只是一些常见问题的分析，但实际应用中问题复杂得多，但如果能够阅
读PPP报文，了解PPP协商所处的阶段，和PPP报文的协商过程，问题一
般可得到满意的解决。

3.2 PPP、 HDLC和SLIP故障相关的display、debugging命令介绍
3.2.1 debugging ppp
本命令用于打开PPP调试信息开关。

debugging ppp { debugging-option } [ interface type number ]
【参数】
debugging-option：PPP调试信息开关类型，详见下表。

interface type number：封装PPP协议的接口及编号。

表3-1PPP调试信息开关类型及含义
PPP的协商报文包含LCP、IPCP、IPXCP等协商过程中交互的报文，以及
echoReqst、echoReply报文。

PPP事件调试信息中包含一些异常信息和关键
的状态迁移，MP捆绑提示信息等。

【视图】
系统视图
3.2.2 display ppp mp
本命令用于显示MP绑定的接口及绑定关系，还可以显示出MP链路建立的时
间，验证的用户名和协商的终端标示符等信息。

display ppp mp [ interface interface-type interface-num ]
【参数】
interface-type interface-num：用于指定查看的接口。

【视图】
所有视图
【举例】
# 显示MP接口的信息。

<Quidway> display ppp mp
Template is Virtual-Template1
Bundle Multilink, 2 member, slot 0, Master link is Virtual-Template1:0
0 lost fragments, 0 reordered, 0 unassigned, 0 interleaved,
sequence 0/0 rcvd/sent
The bundled member channels are:
Serial1/0
Serial1/1
表3-2 MP的显示信息描述表
3.2.3 debugging hdlc
本命令用于打开HDLC调试信息开关。

debugging hdlc { debugging-option }
【参数】
debugging-option：HDLC调试信息开关类型，详见下表。

表3-3 HDLC调试信息开关类型及含义
【视图】
系统视图
3.2.4 debugging slip
本命令用于打开帧中继报文调试信息开关。

debugging slip { event | error | packet | all }
【参数】
packet：打开信息包调试信息输出开关。

event：打开事件调试信息输出开关。

error：打开错误调试信息输出开关。

【视图】
系统视图
3.3 PPP、 HDLC和SLIP典型案例分析
3.3.1 链路自环导致链路层协议DOWN
1. 现象描述
某次工程中，两台Quidway AR28-30设备使用using E1方式互联，中间封装
PPP协议。

工程结束时，通信正常，但是有一天突然不通了。

现场工程师通
过Console口察看路由器，发现AR28-30共有两个口使用这种方式与外界通
信，一个是s1/0:0，另一个是s2/0:0，出问题的口是s2/0:0，但是这两个口的
配置方法都是一样的，而且对s2/0:0口进行shutdown和undo shutdown操
作，也没有变化。

2. 调试信息
工程师在现场进行reset counters interface serial 2/0:0的操作，然后用
display interface serial 2/0:0命令观察端口的包流量，发现端口的input 和
output包文周期性的每次20个增加，但这期间路由器没有进行任何可能导致
向外发包的的操作，所以猜测路由器有自环，周期性增加的20个报文应该是
ppp协商的正常报文。

打开PPP报文的调试信息，发现PPP在不停地重新协
商，并且发送和接受报文的CONFREQ报文的魔术字相同。

3. 原因分析
首先排除配置导致故障的可能性，由于物理端口也是up的，所以电缆联接没
有问题。

再联系到网络曾经运行正常，那么很有可能是网络在运行中由于某
种非路由器可控因素导致故障，最有可能是链路上发生自环。

4. 处理过程
联系局方人员，得知前几天进行过网络改造，使中间的传输设备产生了自环。

经过调整，问题解决。

3.3.2 和某公司路由器互通时验证不通过
1. 现象描述
Quidway路由器与某公司路由器互通PPP，使用pap方式进行验证，PPP协
商不通。

Quidway路由器做被验证方，配置ppp pap local-user xxx password
simple xxx。

该公司路由器做验证方，配置user xxx password 0 xxx 。

2. 调试信息
打开PPP报文调试信息，发现是由于用户名口令错误，验证失败导致PPP
协商不过。

但是使用display current-configuration查看配置信息，发现两端
的用户名和口令是一致的。

3. 原因分析
配置路由器时，操作员对于不熟悉的命令习惯敲？查询帮助信息，在该公司
设备上配置user xxx password 0 xxx至最后的密码后，操作员敲了一个空格
键，再敲？，发现再没有参数了，此时再敲回车，导致配置的密码就不是xxx
了，而是xxx加上一个空格符号。

所以导致验证不通过。

4. 处理过程
在该公司路由器上重新配置用户名和密码，敲完密码后直接回车。

5. 请注意，两台Quidway路由器进行验证时同样需要注意此类问题。

3.3.3 两端封装的链路层协议不同导致链路层不能UP
1. 现象描述
Quidway路由器RouterA与某公司路由器RouterB使用同步串口互通，两端
都使用缺省的最简配置。

Quidway路由器RouterA的链路层协议不能UP，
RouterB的链路层虽然可以UP，但过一分钟左右又会DOWN掉。

2. 调试信息
在Quidway路由器RouterA上打开PPP报文调试信息，发现有不可识别的报
文输入，发出的CONFREQ报文没有收到回应。

3. 原因分析
Quidway路由器广域网口缺省的链路层协议是PPP，但该公司路由器RouterB
的同步串口上缺省的链路层协议是HDLC，所以不能互通。

RouterB的HDLC
协议发出的KEEPALVE报文，得不到回应，导致协议DOWN。

4. 处理过程
在RouterB的同步串口上封装PPP协议后问题解决。

3.4 帧中继协议故障排除综述
帧中继（Frame-Relay）是在X.25技术基础之上发展起来的一种快速分组交
换技术。

帧中继网提供了用户设备（如路由器和主机等）之间进行数据通信
的能力，帧中继在单一物理传输线路上能够提供多条虚电路，目前在帧中继
中使用最多的方式是永久虚电路方式，即手工配置产生的虚电路方式，
Quidway路由器只支持永久虚电路方式。

用户进行故障诊断时，显示和调试
的信息都是基于永久虚电路方式的。

帧中继在数据链路层不提供差错恢复机制，也不需要响应，所有的差错检查
将留给使用帧中继服务的网络层和传输层协议进行。

帧中继作为链路层的基
本协议，技术已经比较成熟，其中出现的一些故障主要是基于传输介质和对
于帧中继的配置。

帧中继的一个问题是拥塞控制，因为标准中取消了流量控制，交换机和目标
站点可能塞满了数据。

拥塞不仅能够造成通信延迟，在非常严重的情况下，
可以造成一个站点完全失效。

帧中继协议并没有解决这些问题，而是提供了
一个减少这种可能性的方法。

每当永久虚电路上的交换机遇到拥塞时，它将
通过开启FECN位(前向显式拥塞指示位，设置为“1”)，警告它下游的交换
机和目标站点。

这一位告诉下游的设备拥塞已经开始了，他们可能会遇到一
些帧被丢弃。

同样也可以通过开启BECN位(后向显式拥塞指示位)，来警告上
游的交换机和发送者链路上出现了拥塞，希望它们以更慢的速度发送帧。

可
以通过display fr pvc-info命令来查看FECN和BECN的设置情况。

3.4.1 帧中继配置的常见问题
在帧中继链路上的连接失败，通过display interface命令输出显示接口和链
路协议均down，或是接口up而链路协议down。

这种情况下可能故障原因有
以下几种。

1. 电缆、端口等硬件问题
排错步骤：
●使用display interface命令查看端口和链路协议是否up；
●如果接口和链路协议均down，检查电缆，确定是否为DTE串口电缆并
确认电缆安全连接；
●如果线缆连接正确，尝试着将其连到另一接口。

如果该接口工作正常，
则说明第一个接口有问题，更换接口卡或路由器；
●如果电缆在第二个接口上也不能工作，更换电缆。

如果更换后仍不能正
常工作，则可能是DCE的问题。

2. LMI（本地管理接口）类型不匹配
排错步骤：
●使用display interface或者display current-configuration 来观察接口
状态。

●如果输出显示接口up但链路协议down，使用display interface命令查
看是否在帧中继接口上配置了LMI类型。

●确认路由器与本端帧中继交换机上的LMI类型相同，如果不同，使用fr lmi
type {ansi | nonstandard | q933a }接口命令来配置该路由器的LMI类型值。

3. 没有发送keepalive报文。

排错步骤：
●使用display interface查看是否配置了发送keepalive报文。

如果你看
到一行“keepalives not set”，则说明keepalives报文没有配置。

●使用timer hold seconds命令配置keepalives，该命令的缺省值为10
秒。

4. 封装类型不匹配
排错步骤：
●当用Quidway设备与非Quidway设备互联时，必须在两端设备上使用
IETF封装方式。

使用display interface或者display current-configuration来检查Quidway设备的封装方式。

●如果Quidway设备没有使用IETF封装，用link-protocol fr ietf 接口配
置命令在Quidway设备的帧中继接口上配置IETF封装方式。

5. DLCI没有激活或已被删除
排错步骤：
●使用display fr pvc-info来观察接口PVC的状态。

●如果输出显示PVC没有激活或已被删除，可能是到对端路由器的路径问
题，检查到对端路由器的路径。

6. DLCI被指派给错误的子接口
排错步骤：
●使用display fr pvc-info来检查分配的DLCI，确信DLCI分配正确。

●如果DLCI分配无误，依次使用shutdown和undo shutdown命令重置
主接口。

3.4.2 其他相关问题
1. 通过帧中继连接，ping对端路由器失败
可能原因有：封装类型不匹配；DLCI没有激活或已被删除；DLCI被指派给
错误的子接口；访问控制列表设置不当；缺少fr map命令配置；在fr map命
令中缺少broadcast关键字等。

如果访问列表配置有误，采用以下排错步骤：
●使用display acl命令查看路由器是否配置了访问控制列表。

●如果存在控制列表，使用undo firewall packet-filter命令去掉列表并测
试此时的连通性，看是否链路已通。

●如果连接恢复，重新加上访问限制，但注意一次仅加上一条限制，再观
察加上限制后的连通性。

●如果发现某条ACL语句所加的限制阻碍了连接，审查该语句有没有拒绝
合法的流量，同时要显式地为允许通过的流量加上permit说明。

●继续上述过程，直至所有的访问控制列表均恢复且连接正常。

如果缺少fr map命令配置，采用如下排错步骤：
●使用display fr map命令查看路由器是否为DLCI配置了地址映射。

●如果DLCI缺少地址映射配置，依次键入reset fr inarp-info和display fr
map-info命令查看是否存在对DLCI的地址映射。

●如果没有对DLCI的映射，使用fr map为其添加静态的地址映射。

●确认fr map命令中DLCIs和下一跳地址正确，定义的协议地址应与本地
帧中继接口处于同一子网内。

如果在fr map命令中缺少broadcast关键字，采用如下排错步骤：。