路由器排障手册.docx

路由器故障排除手册v1第1章 以太口故障排除本章介绍了分析以太口故障的基本思路，以及分析以太口故障的常用方法和使用命令等。本章内容： 以太口故障排除基本思路 以太常见故障处理 错误信息实例 以太口故障的其它检测手段1.1 以太口故障排除基本思路故障分析的基本思路：由底层到上层 首先分析物理原因，包括设备是否工作正常，连线是否正常； 检测方法： ping包测试与以太口工作状态指示灯。检测方法：通过路由器以太口ping局域网内的已知ip地址；查看arp表是否有该ip地址的arp表项，同时看ping是否成功。 1.2 以太口常见故障处理故障一：接口不断updown 可能的原因判断方法和解决方案若此故障发生在路由器刚开机时，一般是由于以太口与交换机或是其它相连设备协商不成功。检查以太口工作状态，即通过show以太口接口查看以太工作方式（单工、双工或自动协商）以及工作速率（10m、100m还是自动协商）。检查以太口相连设备的工作方式。看双方是否能工作在同一种方式下。若配置自动协商不能协商成功可换用指定方式。若此是发生在正常工作一段时间之后，则往往是由于以太口连线未接好造成。检测连接线与接口是否正常连接。检测连线是否有破裂情况。检测连线是否穿过强电场的情况。故障二：以太接口始终不up可能的原因判断方法和解决方案路由器与相连设备支持协议不同两个设备是否是支持相同的协议，迈普公司路由器支持协议如下。802.3协议，ethernetii协议以及snap协议。使用连接线错误与不同的设备相连将需要不同的以太口连接线，一般使用直连线、交叉线。也有使用全反线与全发交叉线。查看硬件安装手册以太接口引脚定义，选用正常的连线。故障三：接口up但无法ping通lan内地址可能的原因判断方法和解决方案以太口mac地址错误ip add 是否在同一网段。两个设备是否是支持相同的协议，迈普公司路由器支持协议如下：802.3协议、ethernet 协议、snmp协议以太口模块硬件受损或错误ping包后查看接口发送是否有正确的统计。ping被ping设备有使用访问列表等安全措施，不允许lan内设备ping通。查看被ping设备的配置等是否有关于icmp表的禁止配置。局网内划分了vlan，且两设备在不同的vlan中以太接口是否封装802.1q，两设备是否属于同一vlan中。同时ping广播是否能学习到vlan内的其它的arp表项。故障四：局网内某个设备能ping通该路由器以太口但以太口不能ping同该设备。或是以太口能ping通该设备，该设备无法ping通路由器以太口。可能的原因判断方法和解决方案使用了访问列表等访问控制的配置查看路由器配置以及设备配置。以太口mac地址错误show int查看以太口mac地址，确定不是全f或是全0；若是请在接口模式下使用macaddress更改mac地址（限mp3600以上路由器）1.3 错误信息实例1.3.1 接口信息fastethernet0: flags: (0x8063) up broadcast multicast arp running type: ethernet_csmacd（以太类型） internet address: 129.255.8.11 （局网ip 地址） netmask 0xffff0000 subnetmask 0xffff0000 broadcast address: 129.255.255.255 queue strategy: fifo , output queue: 0/40 (current/max packets) metric: 0, mtu: 1500, bw: 100000 kbps, dly: 100 usec, vrf: kernel ethernet address is 0001.7a010.34c5 5 minute input rate 7000 bits/sec ,7 packets/sec 5 minute output rate 0 bits/sec ,0 packets/sec 193834 packets received; 161 packets sent 193715 multicast packets received 77 multicast packets sent 10 input errors; 0 output errors 0 collisions; 131 dropped 0 no buffer for receive,speed 100mbit/s,mode full-duplex （100m全双工） receive 212283 broadcasts, 0 runts, 0 giants, 0 throttles 0 input error , 0 crc, 0 frame, 0 overrun, 0 ignored 0 output error ,0 collisions, 0 interface resets, 0 underrun 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier , 0 excessive collison 0 buffer failure,0 buffer swap out1.3.2 arp表项信息mp3600#sho arp alllink level arp tabledestination gateway flagsrefcntuse interface-129.255.0.60 0001.7a01.70b5 204050 0 fastethernet0129.255.0.80 0001.7a01.7daa 20405 0 0 fastethernet0129.255.8.6 0005.5da4.be6f 20405 0 34 fastethernet0129.255.8.7 0000.0001.0012 c05 0 0 fastethernet0129.255.19.10 0001.7a30.eb6c 405 0 1 fastethernet0flag 表示arp表现的状态：c05 表示为静态arp表项405 表示还未进入老化期的表项20405 表示进入老化期的表项use 该arp表现使用次数第2章 广域网故障排除本章采用串行线路技术来分析、排除广域网故障，主要分析串口、hdlc、ppp、frame-relay、x.25的常见故障。本章内容： 串口故障排除 hdlc故障排除 ppp故障排除 frame-relay故障排除 x.25故障排除2.1 串口故障排除2.1.1 串口故障排除基本思路1分析本端物理原因检测方法：使用show interface命令查看物理信号是否全部up，检测本端连线、接口类型（v24/v35）、设备是否正常。2.2分析远端物理原因检测方法：在线路上一段一段的打环测试各段线路是否正常。2.3检查接口参数配置检测方法：查看通信两端配置是否正常，并使用相关广域网协议的debug命令进一步确定问题所在。2.1.2 串口常见故障处理故障一：物理信号没有全部up可能的原因判断方法和解决方案1路由器与dce设备接口类型（v24/v35）不一致show interface发现物理信号没有全部up，检查路由器与dce设备的接口类型是否一致。2路由器工作为dce方式，但没有配置时钟（缺省工作为dte方式，不用配置时钟；但例如：路由器与路由器背靠背连接时，需要其中的一台工作为dce方式）show interface发现物理信号txc为down，其它信号up，如果路由器需要工作为dce方式，此时要在接口上配置时钟：clock rate（请参看配置手册）。3路由器与dce设备之间的连接线有问题show interface发现物理信号没有全部up，换另一条连接线试试。4路由器或dce设备有问题在确保接口类型一致、连接线正常后，show interface查看具体物理信号状态；如果dce、dsr、cts、txc中的某些信号状态为down，说明问题在dce设备，可能本端dce设备本身有问题，也可能远端dce设备有问题或本端dce设备与远端dce设备连接有问题，此时可以打环进一步确定问题所在；如果dtr、rts信号状态为down，说明问题在路由器，检查接口配置是否做了shutdown的操作，没有的话可能问题在串口模块本身或路由器插槽，先换插槽、再换串口模块来进一步确定问题。故障二：物理信号全部up、但广域网协议不能up可能的原因判断方法和解决方案1路由器与dce设备接口类型（v24/v35）不一致或设备兼容性有问题有时路由器与dce设备接口类型不一致，物理信号也会全部up，此时show interface一般会有一些错误信息（rxnooctet、rxabterrs、rxcrcerrs、rxoverrun、rxlenerrs、txunderrun）；在确定接口类型一致后，错误统计信息依然在增加，可能dce设备本身有问题或路由器与此dce设备兼容性有问题，此时可以尝试在广域口上配置：idle-character flags（在帧与帧之间插入0x7e字符。默认为idle-character marks方式：在帧与帧之间插入0xff字符）；另外还可以尝试在路由器广域口上配置时钟翻转或时钟复用或同时使用：clock invert（把dte端的发送时钟翻转，消除线路上半个时钟周期的时延）、clock multiplex（将dce设备的发送时钟复用为路由器的收/发时钟）；如果还是没有效果，可以换路由器和dce设备调试来进一步确定问题。2广域网两端接口协议或相关协议参数配置不一致show interface发现接口下rxframes、txframes两项数值都有增加、且没有错误信息增加，此时一般dce上的收发灯都正常闪动，先检查广域网两端协议配置是否一致，再打开相关协议的debug信息进一步确定问题（具体请参照下面几节协议故障排除）。3广域网两端之间线路或设备有问题show interface发现接口下txframes在增加、但rxframes没有增加或错误统计信息在增加。此时可以通过打环来检测；检测本端问题：在路由器接口上配置hdlc协议，并在本端的dce设备上打数字环，如果本端发送、接收的数据都在增加且show interface看到环（显示line looped），说明本端没有问题；如果没有增加，则检查本端路由器、dce设备、连接线的问题；检测线路问题（本端已经确定没有问题）：看两端dce设备的收发灯是否都在闪烁，在本端dce打网络环检测对端路由器是否有收有发，或在对端dce打网络环检测本端路由器是否有收有发且有环，如果两端都没有收发且看不到环，可能是中间线路上的问题，查中间线路。检测对端问题：在对端路由器接口上配置hdlc协议，并在对端的dce设备上打数字环，如果对端发送、接收的数据都在增加且show interface看到环，说明对端没有问题；如果没有增加且看不到环，则检查对端路由器、dce设备、连接线的问题；故障三：物理信号全部up、协议up，但丢包严重可能的原因判断方法和解决方案1路由器工作在dte方式，但错误的配置了时钟clock rate查看接口下配置，在dte方式下，路由器不能配置clock rate，时钟应该由dce设备提供2路由器与dce设备接口兼容性不好从本端路由器ping对端路由器广域口地址，时通时断，丢包严重，但没有规律（有规律的丢包可能是路由原因，如通一个、丢一个），此时show interface一般会有一些错误信息（rxnooctet、rxabterrs、rxcrcerrs、rxoverrun、rxlenerrs、txunderrun）；ping包的过程中，错误信息在不断增加，可能dce设备本身有问题或路由器与此dce设备兼容性有问题，此时可以尝试在广域口上配置：idle-character flags（在帧与帧之间插入0x7e字符。默认为idle-character marks方式：在帧与帧之间插入0xff字符）；另外还可以尝试在路由器广域口上配置时钟翻转或时钟复用或同时使用：clock invert（把dte端的发送时钟翻转，消除线路上半个时钟周期的时延）、clock multiplex（将dce设备的发送时钟复用为路由器的收/发时钟）；如果还是没有效果，可以换路由器和dce设备调试来进一步确定问题。3广域网两端之间线路或设备有问题show interface发现接口下txframes、rxframes在增加，错误统计信息也在增加。此时可以通过打环来检测；检测本端问题：在路由器接口上配置hdlc协议，并在本端的dce设备上打数字环，本端接口正常情况能up，ping 本端接口的地址，如果没有丢包，说明本端没有问题；如果丢包严重，则检查本端路由器、dce设备、连接线的问题；检测线路问题（本端已经确定没有问题）：在路由器接口上配置hdlc协议，并在对端dce打网络环，本端接口正常情况能up，ping 本端接口的地址，如果没有丢包，说明线路没有问题；如果丢包严重，则检查线路；检测对端问题：如果做过以上操作后，都正常，可能问题在对端，此时需要根据对端设备情况打环测试，进一步确定问题。4数据流量超过线路带宽当跑业务时丢包严重，但停止业务时ping包正常，此时就应该考虑业务流量是否超过线路带宽。当跑业务丢包时，show inferface，查看接口下是否有较多的input errors、output errors，还可以看5分钟接收、发送流量统计是否接近线路带宽，如果是，基本可以说明线路负载过重，此时应该查本端以及对端局域网是否有较多的非业务数据流经过广域网，可以在以太口或广域口通过一些手段（如访问列表）来过滤这些非业务数据流，如果都是业务数据的话就应该提高线路带宽了。2.1.3 串口显示信息说明在迈普系列路由器的接口类型越来越多的情况下，我们将常用接口的显示信息具体做说明，以便对此种接口和上层协议运行情况进行分析。下面就以串口跑同步方式ppp协议为例来介绍接口统计信息。当我们在路由器的特权模式下，键入show interface serial0/0后，显示如下信息：router#show interface serial0/0serial0/0:1 flags: (0x80f1) up point-to-point multicast running 2 type: ppp3 internet address: 3.3.3.94 netmask 0xff000000 subnetmask 0xff0000005 destination internet address: 3.3.3.16 queue strategy: fifo , output queue: 0/40 (current/max packets)7 metric: 0, mtu: 1500, bw: 128 kbps, dly: 20000 usec, vrf: kernel8 5 minute input rate 3000 bits/sec ,288 packets/sec9 5 minute output rate 3000 bits/sec ,288 packets/sec10 1447 packets received; 1983 packets sent11 0 multicast packets received12 0 multicast packets sent13 1 input errors; 0 output errors14 0 collisions; 0 dropped15 lcp:opened16 ipcp:opened ndspcp:opened17 rxframes: 1981, rxchars 12220318 txframes: 1983, txchars 12426619 rxnooctet 0, rxabterrs 0, rxcrcerrs 020 rxoverrun 0, rxlenerrs 0, txunderrun 021 dcd=updsr=updtr=uprts=upcts=uptxc=up接口属性和ip层属性：1flags标志表示当前接口的状态（即：up/down）；2type表示当前接口的封装类型。s0/1接口为ppp3显示接口的本地地址为3.3.3.94显示接口本地地址对应的网络掩码为255.0.0.0和子网掩码为255.0.0.05显示接口的对端地址为3.3.3.16显示接口上的队列策略为fifo（first in first out）7显示接口上的metric（度量值）为0, mtu（最大传输单元）为1500, bw（网络带宽）为128 kbps, dly（网络延迟）为20000 usec,vrf（vpn路由转发）为kernel（核心）接口ip层统计：8-9 显示接口的5分钟流量统计信息。即：5分钟内平均每秒接收和发送的比特数及数据包10 显示到目前为止，接口上接收和发送的数据包数目11-12显示到目前为止，接口上发送和接收的多播报文的数目13 因为数据报文格式错误等出现的输入输出错误统计（如果output error较多，可能是线路流量太大，超过带宽）14 因为数据冲突和不能入ip队列而丢掉的错误统计接口链路层统计及物理层属性：15-16 显示当前接口上ppp协议运行状态。lcp（链路控制协议）、ipcp（ip控制协议）、ndspcp（ndsp控制协议）均处于open状态。17-18 显示物理上接收和发送帧的数目以及接收和发送的字节数。19 接收8位不对齐, 接收到abort（终止帧）错误, 接收crc错误。20 接收overrun（接收cpu处理不及）错误, 接收长度错误, 发送underrun（接口发送不及）错误。21 显示接口物理信号连接情况（即：up/down）2.2 hdlc故障排除2.2.1 hdlc故障排除基本思路故障排除的基本思路：检查物理线路、查看debug hdlc信息 首先分析物理原因，包括连线是否正确、物理接口是否正常（关于串口故障分析请参见第一节）； 其次检查接口keepalive参数配置是否匹配，并通过debug hdlc命令查找问题。2.2.2 hdlc常见故障处理故障一：接口不断up/down可能的原因判断方法和解决方案1物理线路故障、接口报文收发故障检测物理线路是否良好检测接口报文收发是否正常确保物理接口所有物理信号dcd、dsr、dtr、rts、cts、txc状态up，且数据收发正常（关于串口故障排除请参见第一节）2接口keepalive参数小于对端设备接口keepalive参数的1/3打开debug hdlc 命令观察接口keepalive帧收发是否正常，hdlc的链路维持靠keepalive帧，如果在3倍于本地keepalive时间间隔仍没有收到对端的keepalive报文则链路层协议down，认为此条链路不可靠。解决办法：确保配置双方接口keepalive时间间隔一致（默认配置为10秒，show run看不到此配置信息），如果配置一致后现象仍然存在，则此条链路不可信，请检测物理线路。 故障二：接口down可能的原因判断方法和解决方案1物理线路故障、接口报文收发故障物理线路是否良好检测接口报文收发是否正常确保物理接口所有物理信号dcd、dsr、dtr、rts、cts、txc状态up，且数据收发正常（关于串口故障排除请参见第一节）2对端没有配置ip地址打开debug hdlc 命令观察接口是否一直在交互地址请求报文，如果对端没有配置ip地址则对端发回来的应答报文中没有携带有效ip地址，而是0.0.0.0；或者查看接口信息，查看接口信息中是否有对端地址；解决办法：为对端接口配置ip地址。2.2.3 hdlc错误信息实例2.2.3.1 hdlc错误信息（debug hdlc信息的关键语句）及原因 信息故障原因信息1：thdlctimhdlc(bm0/0)_t: m addr_request 192.168.8.2tqmcinthdlc(bm0/0)_r: m addr_reply 0.0.0.0对端没有配置ip地址信息2：tqmcinthdlc(bm0/0)_r: m keepalive rno=123 lno=123 time=19153000thdlctimhdlc(bm0/0)_t: m keepalive rno=124 lno=123 time=19160000thdlctimhdlc(bm0/0)_t: m keepalive rno=124 lno=123 time=19164000thdlctimhdlc(bm0/0)_t: m keepalive rno=124 lno=123 time=19168000 thdlctim%lineproto-5-updown: line protocol on interface bm0/0, changed state to down3倍于本地keeplive时间间隔内，没有收到对端keeplive报文1解决：为对端配置正确ip地址2解决：配置双方keeplive时间间隔一致& 注：以上信息均由debug hdlc命令打出，具体请参照配置手册相关章节。2.3 ppp故障排除2.3.1 ppp故障排除基本思路1分析物理原因检测方法：使用show interface命令查看物理信号是否全部up，检测连线是否正常、设备是否正常、环境(各种干扰因素)是否对ppp工作有不良影响。（关于串口故障分析请参见第一节）2检查配置及参数设置检测方法：查看通信两端配置是否正常，并使用相关ppp协议的debug命令进一步确定问题所在。2.3.2 ppp常见故障处理故障一：物理信号全部up，但只发不收lcp帧，协议down可能的原因判断方法和解决方案1物理上的问题show interface发现接口下txframes在增加、但rxframes没有增加或错误统计信息在增加。此时应该查物理上的原因。 （关于串口故障排除请参见第一节）2对端未封装ppp协议show interface发现接口下txframes、rxframes在增加，且错误统计信息没有增加，但打开debug ppp negotiation，发现本端发lcp帧，但接收到不能识别的帧。如对端封装hdlc协议的debug信息：09:02:43: tpppexeppps1/0: sent lcp confreq id=0x88 09:02:44: tpppexeppps1/0: rcvd00 80 35 00 00 00 02 00 00 00 00 00 00 00 00 ff ff 06 d6 ee 48（不能识别的包）09:02:45: tpppexeppps1/0: sent lcp confreq id=0x89 09:02:45: tpppexeppps1/0: rcvd00 80 35 00 00 00 00 17 00 00 5c ff 00 00 00 ff ff 06 d6 f2 30（不能识别的包）09:02:46: tpppexeppps1/0: rcvd00 80 35 00 00 00 00 17 00 00 5c ff 00 00 00 ff ff 06 d6 f6 18（不能识别的包）09:02:47: tpppexeppps1/0: sent lcp confreq id=0x89 故障二：物理信号全部up，但pap认证不通过，协议down可能的原因判断方法和解决方案1用户名、密码不匹配物理信号up，打开debug ppp negotiation，发现提示login failed，没有进入ipcp协商阶段。被认证方debug信息如下：1d8h: tpppexeppps0/3: sent lcp confreq id=0x91 1d8h: tpppexeppps0/3: rcvd lcp confack id=0x91 1d8h: tpppexeppps0/3: rcvd lcp confreq id=0xd3 1d8h: tpppexeppps0/3: sent lcp confack id=0xd3 1d8h: tpppexeppps0/3: sent pap authreq id=0xf user=aaa password=aaa1d8h: tpppexeppps0/3: rcvd pap authnak id=0xf msg=login failed1d8h: tpppexeppps0/3: remotemsg: login failed1d8h: tpppexeppps0/3: sent lcp termreq id=0x911d8h: tpppexeppps0/3: rcvd lcp termreq id=0xd3此时应该查认证端配置的用户名、密码，保证下端发送的用户名、密码正确。 故障三：物理信号全部up，但chap认证不通过，协议down可能的原因判断方法和解决方案1认证发起方没有为被认证方建立一个用户，或两端建立的用户密码不一致（chap认证要求两端都为对方建立一个用户user，且此两个user的密码必须保持一致）物理信号up，打开debug ppp negotiation，发现提示chap authentication failure，没有进入ipcp协商阶段。被认证方debug信息如下：1d8h: tpppexeppps0/3: sent lcp confreq id=0x99 1d8h: tpppexeppps0/3: rcvd lcp confreq id=0xda 1d8h: tpppexeppps0/3: sent lcp confack id=0xda 1d8h: tpppexeppps0/3: rcvd lcp confack id=0x99 1d8h: tpppexeppps0/3: rcvd chap challenge id=0x5 , name = r21d8h: tpppexeppps0/3: sent chap response id=0x5 , name = abc1d8h: tpppexeppps0/3: rcvd chap failure id=0x5 chap authentication failure, serial1/01d8h: tpppexeppps0/3: remotemsg: chap authentication failure, serial1/01d8h: tpppexeppps0/3: chap chap authentication failed1d8h: tpppexeppps0/3: sent lcp termreq id=0x991d8h: tpppexeppps0/3: rcvd lcp termreq id=0xda此时应该查认证发起方是否为被认证方建立了用户，且两端建立的用户密码一致。2被认证方没有为认证发起方建立一个用户物理信号up，打开debug ppp negotiation，被认证方连续接收chap challenge帧，没有进入ipcp协商阶段。被认证方debug信息如下：09:49:14: tpppexeppps1/0: sent lcp confreq id=0xdc 09:49:14: tpppexeppps1/0: rcvd lcp confack id=0xdc 09:49:15: tpppexeppps1/0: rcvd lcp confreq id=0x9b 09:49:15: tpppexeppps1/0: sent lcp confack id=0x9b 09:49:15: tpppexeppps1/0: sent chap challenge id=0x7, name = aaa09:49:18: tpppexeppps1/0: sent chap challenge id=0x7, name = aaa09:49:21: tpppexeppps1/0: sent chap challenge id=0x7, name = aaa09:49:24: tpppexeppps1/0: sent chap challenge id=0x7, name = aaa此时应该在被认证方为认证发起方建立一个用户，且两端建立的用户密码一致。故障四：物理信号全部up，ipcp协商不成功，协议down可能的原因判断方法和解决方案1本端没有ip地址或使用ip unnumber时对应的接口没有ip地址物理信号up，打开debug ppp negotiation，本端打印：our address is 0, not do ipcp negotiation! debug信息如下：11:03:29: tpppexeppps1/0: sent lcp confreq id=0xee 11:03:29: tpppexeppps1/0: rcvd lcp confreq id=0xad 11:03:29: tpppexeppps1/0: sent lcp confack id=0xad 11:03:29: tpppexeppps1/0: rcvd lcp confack id=0xee 11:03:29: tpppexeppps1/0: serial1/0: our address is 0, not do ipcp negotiation!11:03:29: tpppexeppps1/0: sent lcp termreq id=0xee2对端没有ip地址或使用ip unnumber时对应的接口没有ip地址物理信号up，打开debug ppp negotiation，ipcp协商不成功，debug信息如下：1d9h: tpppexeppps0/3: sent lcp confreq id=0xaf 1d9h: tpppexeppps0/3: rcvd lcp confreq id=0xf0 1d9h: tpppexeppps0/3: sent lcp confack id=0xf0 1d9h: tpppexeppps0/3: sent lcp confreq id=0xaf 1d9h: tpppexeppps0/3: rcvd lcp confack id=0xaf 1d9h: tpppexeppps0/3: ipcp open1d9h: tpppexeppps0/3: sent ipcp confreq id=0x77 1d9h: tpppexeppps0/3: rcvd lcp termreq id=0xf01d9h: tpppexeppps0/3: sent lcp termack id=0xf0 故障五：物理信号up，协议up，但ping 包不通可能的原因判断方法和解决方案1本端配置地址协商，但对端没有分配地址或地址池中的地址已分配完。 show interface显示：internet address: 0.0.0.0，说明对端没有给本端分配地址或地址池中的地址已分配完，此时应该检查对端的配置，作相应修改。2对端没有ip地址show interface显示：destination internet address: 0.0.0.0，此时应该检查对端的配置，配置ip地址。3两端ip地址不在同一网段（有些厂家的路由器不支持广域口两端ip地址不在同一网段的情况、mp路由器支持，不存在此问题）当分配的广域口地址不在同一网段时（如在接口上使用ip unnumber一般就不在同一网段），有些厂家的的路由器就不支持。通过查看广域网两端的路由表是否有对端地址的路由项可以看出（mp路由器上使用show ip route命令），如果没有就需要分别手动配置到对端地址的接口静态路由。2.3.3ppp错误信息实例2.3.3.1 ppp错误信息（debug ppp negotiation信息的关键语句）及原因 信息故障原因信息1：ppps0/3: remotemsg: login failedpap认证失败信息2：ppps0/3: remotemsg: chap authentication failurechap认证失败信息3：ppps0/3: serial0/3: our address is 0, not do ipcp negotiation!本端没有配置ip地址1解决：配置正确的用户名、密码2解决：在两端配置正确的用户名、密码3解决：在本端配上ip地址 & 注：以上信息均由debug ppp negotiation命令打出，具体请参照配置手册相关章节。2.4 frame-relay故障排除2.4.1 frame-relay故障排除基本思路故障分析的基本思路：检查物理线路、检查frame-relay协议报文交互是否正常，分析lmi报文交互 首先分析物理原因，包括连线是否正确、物理接口是否正常（关于串口故障分析请参见第一节）； 其次检查frame-relay lmi报文交互是否正常，检查pvc配置是否正确，检查协议地址映射是否正确建立。2.4.2 frame-relay常见故障处理故障一：用做dte设备时接口down可能的原因判断方法和解决方案1物理线路故障、接口报文收发故障检测物理线路是否良好检测接口报文收发是否正常确保物理接口所有物理信号dcd、dsr、dtr、rts、cts、txc状态up，且数据收发正常（关于串口故障分析请参见第一节）2lmi报文交互失败，只发不收打开debug frame-relay lmi 命令观察接口lmi报文收发是否正常，frame-relay是否对物理链路信任是依据lmi报文的交互情况来定的。 正常情况下lmi报文是有发有收的，即dte发出链路状态请求报文，收到对端dce的链路状态应答报文；接口lmi报文只有发送没有接收，在排除接口物理故障的前提下，可能是dte设备和dce设备lmi类型不匹配造成的，如果lmi类型不匹配则dce设备是不会对此链路状态请求报文做应答的。解决办法：可以向局端设备核实lmi类型，或者可以通过调整本地lmi类型的方法来解决问题；lmi类型有3种：ansi、lmi(兼容cisco)、q933a，确保lmi类型匹配； 在lmi报文连续3次成功交互后接口会up；3特殊情况：frame-relay接口类型设置错误在某些特定的网络环境中可能需要我们的设备完成dcenni的功能，由此通过debug frame-relay lmi可以看到不断报错的情况：unexpected message type：说明本地设备应该设置为dce或者nni故障二：用做dce设备时接口down可能的原因判断方法和解决方案1物理线路故障、接口报文收发故障检测物理线路是否良好检测接口报文收发是否正常确保物理接口所有物理信号dcd、dsr、dtr、rts、cts、txc状态up，且数据收发正常（关于串口故障分析请参见第一节）2lmi报文交互失败，只收不发开debug frame-relay lmi 命令观察接口lmi报文收发是否正常，frame-relay是否对物理链路信任是依据lmi报文的交互情况来定的。 正常情况下lmi报文是有发有收的，dce在收到链路状态请求报文后必须发送应答报文，如果在t392dce（默认15秒）的时间内没有收到正确的链路状态请求报文，则dce会提示“dce lmi timeout”，如果在n392dte事件计数内有n392dce次错误，则该dce接口会down掉；如果接口lmi报文只有接收没有发送，并且lmi协议报错，在排除接口物理故障的前提下，可能是dte设备和dce设备lmi类型不匹配造成的，如果lmi类型不匹配则dce设备是不会对此链路状态请求报文做应答的，并且报错：“lmi: locking shift seen。”解决办法： lmi类型有3种：ansi、lmi(兼容cisco)、q933a，确保dce和dte接口lmi类型匹配；在lmi报文连续3次成功交互后接口会up；故障三：frame-relay协议up，但pvc状态非active可能的原因判断方法和解决方案1对端dte设备没有准备好或者fr网络故障pvc状态inactive，通过show frame-relay命令查看到