HCTE第3章广域网故障排除V210Word文档下载推荐.docx

上传人:b****2 文档编号:5131356 上传时间:2023-05-04 格式:DOCX 页数:54 大小:317.68KB
下载 相关 举报
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第1页
第1页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第2页
第2页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第3页
第3页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第4页
第4页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第5页
第5页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第6页
第6页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第7页
第7页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第8页
第8页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第9页
第9页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第10页
第10页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第11页
第11页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第12页
第12页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第13页
第13页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第14页
第14页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第15页
第15页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第16页
第16页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第17页
第17页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第18页
第18页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第19页
第19页 / 共54页
HCTE第3章广域网故障排除V210Word文档下载推荐.docx_第20页
第20页 / 共54页
亲,该文档总共54页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

HCTE第3章广域网故障排除V210Word文档下载推荐.docx

《HCTE第3章广域网故障排除V210Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《HCTE第3章广域网故障排除V210Word文档下载推荐.docx(54页珍藏版)》请在冰点文库上搜索。

HCTE第3章广域网故障排除V210Word文档下载推荐.docx

3.5.5displayfrinarp-info79

3.5.6debuggingfr80

3.5.7帧中继debugging命令使用建议82

3.6FrameRelay典型案例分析82

3.6.1接口物理层UP,但链路层协议DOWN82

3.6.2接口协议UP,但不能PING通84

3.6.3MAP属性与路由协议问题(如RIP等组播或广播型路由协议)85

3.6.4在帧中继网络运行OSPF协议87

3.6.5与部分网状网络及子接口完全连接的问题89

3.7X.25协议故障排除综述91

3.7.1X.25协议简介91

3.7.2X.25配置的常见问题92

3.7.3X.25故障排除的一般步骤93

3.8X.25故障相关的display、debugging命令93

3.8.1displayx25map93

3.8.2displayx25switch-tablesvc94

3.8.3displayx25switch-tablepvc95

3.8.4displayx25vc95

3.8.5debuggingx2597

3.8.6x25debugging命令使用建议98

3.9X.25典型案例分析98

3.9.1X.25的参数不一致导致PING大包不通98

3.9.2两台路由器通过X.25交换机互通问题100

3.9.3使用X.25网卡的PC不能和中心服务器通信100

串行链路故障排除

PPP、HDLC和SLIP故障排除综述

串行链路上支持的链路层协议有PPP、HDLC、FrameRelay、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(最大传输单元)、魔术字(magicnumber)、验证方式、异步字符映射等选项(详见RFC1661);

LCP协商成功后,进入Establish(链路建立)阶段。

如配置了CHAP或PAP验证,便进入CHAP或PAP验证阶段;

验证通过后才会进入网络阶段协商(NCP),如IPCP、IPXCP、BCP的协商。

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

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

异步字符映射用于数据的同异步转换,当PPP从异步端口接收到报文时,要将异步报文转换为同步报文;

当向异步端口发送报文时,要将同步报文转换为异步报文。

PPP运行过程可参见下图。

PPP运行流程图

MP是MultiLinkPPP的缩写,是人们出于增加带宽的考虑,将多个PPP链路捆绑使用产生的。

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

MP方式下接口工作进程如下(以虚拟接口模板下的MP为例):

如果使用虚拟接口模板,MP有两种捆绑形成方式:

(1) 

 

根据终端描述符(EndpointDiscriminator)和验证得到的用户名进行捆绑。

● 

首先和对端进行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参数不起作用。

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

HDLC(HighDataLinkControl,高级数据链路控制),是一种面向比特的链路层协议。

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

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

SLIP(SerialLineInternetProtocol,串行链路因特网协议)定义了一种通过异步串行线路发送包的方法。

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

3.1.1串行链路配置的常见问题

1.物理链路的配置不当导致链路不能互通

由于物理接口的工作模式、时钟选择、波特率设置等不匹配导致物理链路不能UP或者不能互通报文。

同异步串口上常用的配置有:

时钟选择(clock)、时钟反转(invertreceive-clock、inverttransmit-clock)、同异步模式选择(physical-mode)、波特率设置(baudrate)等命令,详见《VRP用户手册配置指导》接口配置部分。

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

如果用displayinterface命令查看接口报文统计信息,也可以发现接收到的报文数没有增长,或者有大量的接收错误(inputerrors)。

参数设置不当导致和某些设备互通时协商不通过

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

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

MP绑定参数设置错误

在使用MP绑定的时候,低端路由器上缺省可以绑定16条链路,当需要绑定的链路超过16条时,需要在系统视图下使用pppmpmax-bind命令来改变允许绑定的最大链路数。

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

用户名是指PPP链路进行PAP或CHAP验证时所接收到的对端用户名;

终端标识符是用来唯一标识一台路由器的标志,是指进行LCP协商时所接收到的对端终端标识符。

HDLC的keepalive设置不匹配

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

如果一端配置了timerhold(缺省为10秒),而另外一端配置了undotimerhold,则一端接口的链路层协议状态会变为DOWN,而另一端为UP。

其他相关问题

物理链路故障导致PPP链路不能UP

由于传输线路故障造成链路不通、自环、误码率过高等问题,也会表现为PPP链路故障。

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

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

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

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

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

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

*0.58113771RTDPPP/8/debug2:

PPPPacket:

Serial1/0OutputLCP(c021)Pkt,Len18

Statereqsent,codeConfReq(01),id94,len14

MRU

(1),len4,val05dc

MagicNumber(5),len6,val0376f72f

Serial1/0InputLCP(c021)Pkt,Len18

MagicNumber(5),len6,val0376f72f

<

Quidway>

displayinterfaces1/0

Serial1/0currentstate:

UP

Lineprotocolcurrentstate:

DOWN

Description:

Serial1/0Interface

TheMaximumTransmitUnitis1500,Holdtimeris10(sec)

InternetAddressis1.1.1.2/24

LinklayerprotocolisPPP,loopbackisdetected

LCPclosed

Outputqueue:

(Urgentqueue:

Size/Length/Discards)0/50/0

(Protocolqueue:

Size/Length/Discards)0/500/0

(FIFOqueuing:

Size/Length/Discards)0/75/0

Physicallayerissynchronous,Loopback,Baudrateis64000bps

InterfaceisDCE,CabletypeisV35

Lastclearingofcounters:

Never

Last300secondsinputrate2.89bytes/sec,23bits/sec,0.20packets/sec

Last300secondsoutputrate2.54bytes/sec,20bits/sec,0.20packets/sec

Input:

13745packets,256235bytes

0broadcasts,0multicasts

0errors,0runts,0giants

0CRC,0alignerrors,0overruns

0dribbles,0aborts,0nobuffers

0frameerrors

Output:

13745packets,256235bytes

0errors,0underruns,0collisions

0deferred

DCD=UPDTR=UPDSR=UPRTS=UPCTS=UP

和某些非标准设备使用PPP互通时协商不通过

PPP连接建立过程要经过几个协商阶段,至少有LCP、还可能有IPCP、IPXCP、BCP、CBCP、CCP等协商过程,每一个协商过程有多个协商项。

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

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

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

使用异步口互通时对端设备不支持字符转义

在异步口封装PPP协议时,一般在LCP协商阶段会协商异步字符转义映射表(ACCMP)。

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

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

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

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

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

没有接口路由导致PPP链路不可用

这种情况下此时LCP已经是OPENED状态,但是Ping报文无法互通,可考虑路由的原因,可以查看是否有对端的路由。

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

串行链路故障排除的一般步骤

从前面的概念所知,PPP作为数据链路层协议,需要由物理层提供数据收发服务,并为网络层提供数据报文的封装,网络层参数协商等功能。

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

物理层问题分析

设备表现为广域网接口无法正常使用时,首先应该从物理层开始检查。

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

如下是一个QuidwayAR28-31路由器的例子:

displayinterfaceSerial1/0

LinklayerprotocolisPPP

LCPreqsent

Last300secondsinputrate11.09bytes/sec,88bits/sec,0.70packets/sec

Last300secondsoutputrate11.09bytes/sec,88bits/sec,0.70packets/sec

14123packets,262139bytes

14118packets,257681bytes

DCD=UPDTR=UPDSR=UPRTS=UPCTS=UP

Serial1/0isup,表明物理层状态UP,,此外Serial1/0可能为down,administrativelydown,standby,其中down说明物理层工作异常,应检查物理层配置及设备问题。

administrativelydown,说明物理层被人为关闭。

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

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状态。

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

LCP问题分析

执行命令displayinterfacebri0/0(BRI接口0/0)或displayinterfaceserial0/0(串口0/0),如显示LCP协议未进入OPENED状态,可考虑为LCP的问题。

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

验证问题分析

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

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

有时配置了验证,但是LCP协商过程中该协商项被拒掉,LCP进入OPENED状态会立即重新协商,此时若通过debugpppall观察,可以看到对端未通过验证的提示信息,例如“Theoppositeterminalhaven'

tpassthechapauthentication!

”。

IPCP问题分析

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

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

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

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

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

其他问题分析

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

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

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

PPP、HDLC和SLIP故障相关的display、debugging命令介绍

debuggingppp

本命令用于打开PPP调试信息开关。

debuggingppp{debugging-option}[interfacetypenumber]

【参数】

debugging-option:

PPP调试信息开关类型,详见下表。

interfacetypenumber:

封装PPP协议的接口及编号。

PPP调试信息开关类型及含义

调试开关类型

含义

all

打开PPP所有调试信息开关

lcp

打开PPP的LCP调试信息

ipcp

打开PPP的IPCP调试信息

pap

打开PPP的PAP调试信息

chap

打开PPP的CHAP调试信息

Ip

打开PPP的IP调试信息

mp

打开PPP的mp调试信息

PPP的协商报文包含L

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 高中教育 > 小学教育

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2