首页“星球娱乐”首页明确地定义什么是网络的“故障”和“排错”不是一件容易的事情。网络的“故障”往往是用户在某种应用不能正常实现时感知到的，有的业务场合，迅速地找到故障并加以排除的要求是相当严格的。

　　除了设备在正常运行中出现故障的情况外，还有另外一种情形，当我们在实施某种应用，已经完成了配置，但却得不到预期的效果。

　　对于上述恼人问题的处理，把它们总结出来，叫做排错技术。显然，这与完全不知道如何配置网络设备是两回事。因此要求阅读本篇文档的工程师有一定的网络基础，并具备了基本的锐捷网络设备配置能力。

　　在目前的网络应用中，故障产生的原因是多样化，复杂化的。涉及到网络设备，服务器提供的应用服务，客户端PC操作系统，物理线缆等等因素。

　　在本文档中，我们主要以和网络设备相关的网络故障类型着手，选取了几篇锐捷网络工程师的内部故障处理报告，加以批注。通过这几篇处理报告，您可以了解到工程师是如何把排错思路应用到实际工作中。

　　本章节中对三个故障处理报告进行了分析点评。这三个故障本身的技术难度并不艰深，但在处理过程中，故障处理思路清晰，值得大家参考。

　　某客户使用windows 2000 server自带的vpn拨号程序远程拨入到远端的vpn服务器（RG-R3662路由器构建的pptp server）后，发现ping超过1432字节大小的包时，就出现不通的现象，而ping 1432字节及其以下的包都很正常。断开vpn拨号，直接拨外网地址可以ping通5000字节大小的包。

　　应用说明：WINDOWS 2000主机通过一台ADSL路由器接入到internet,当WINDOWS 2000主机需要访问总部数据时，便先在本机上运行VPN拨号程序，连接总部广域网路由器R3662，总部广域网路由器R3662作为VPN服务器。VPN建立后，WINDOWS 2000主机得到一私有IP,然后WINDOWS 2000主机便能访问总部数据服务器。

　　拨号主机在没有建立vpn连接前上网正常。并能够ping通R3662外网接口地址，包的大小可以超过2000BYTE。测试中ping –l 8000 的包也可以正常通讯。

　　通过windows 2000 server的vpn拨号程序与远端vpn服务器建立vpn连接。Vpn能够通过pptp隧道协议进行建立。并且在拨号主机上ping –l 1500 的大小的包不通。经过测试ping –l 1432的大小的包是可以通讯的。凡是超过1432的包都不通。

　　故障初次发生时间及发生频率：该WIN2000主机开始VPN使用便产生该故障；只要报文大小超过1432，必定故障现象重现。

　　→ vpn没有建立前。拨号主机与vpn 路由器的外网口之间能够正常通讯。而且ping –l 8000的大小包没有问题。说明电信线路的连通性是没有问题的。

　　批注：首先在未建立VPN前，使用PING命令验证了线路质量的稳定性，基于分层排查的思路，排除了物理层线路质量原因。

　　→ vpn拨号主机能够与远端的vpn服务器之间建立起VPN连接。而且在未建立隧道前ping 1432大小以上的包没有问题。说明电信线路之间的设备没有对vpn隧道进行限制。Vpn两端的配置检查也没有问题。

　　批注：基于分块排查的思路，排除了路由器VPN功能可能存在的故障因素。通过这种方式，也初步验证了配置的正确性。

　　→ 通过自带笔记本（安装xp系统）,使用cdma无线上网卡。远程拨入到vpn服务器上。能够建立连接。而且ping –l 3000的大小的包可以正常通讯。说明vpn内部服务器和vpn设备本身是没有问题的。

　　批注：利用另一台PC访问测试，基于替换排查的思路，进一步确定了配置的正确性，及VPN服务的正常。到此我们已经可以确定，该故障的产生与用户的VPN 客户端环境有关。

　　注意：一些工程师对该故障处理可能就到此结束了，只是简单的告诉用户故障与系统有关，需要重装系统或者更换其它操作系统。这种对问题浅尝辄止的处理方式是不可取的，我们要尽可能的去分析原因背后更深的原因。

　　→ 使用自带的笔记本连接到电信的adsl线路上。与远端的vpn服务器建立连接。发现ping –l 3000大小的包是没有问题。看样子问题出现在windows 2000 server的vpn拨号程序上。因现场不具备抓报文环境。所以通过后来的分析初步可以确定是由于windows 2000 server 的vpn拨号程序在建立vpn连接后。其虚拟的vpn网卡没有将超大包进行分片所致。具体分析如下：

　　通过pptp隧道协议建立vpn连接中，VPN拨号客户端和vpn服务器之间其实是建立了一条GRE隧道，VPN拨号客户端和vpn服务器通过该GRE隧道互访。

　　但是为什么windows 2000server的vpn拨号客户端只能ping通大小为1432的包呢？我们下面来分析一下：

　　VPN拨号客户端出来的IP报文长度为1432，，到达电信的PPP0E拨号接入设备的拨号接口时。IP报文的长度已经变为：1432＋8（ICMP报头长）＋20（IP报头长）+8（pptp利用ppp协议头）+4（封装GRE头）+20（再加上外层IP头）＝1492字节，刚好等于电信ADSL拨号接口的的MTU，于是被顺利传送。而ping 超过1432大小的包时，到达电信局端ADSL拨号接口的包大小就相应的超出了1492的MTU，又因为报文DF位未置1，即不能分片，电信ADSL拨号接口于是将该超大的报文丢掉。这就是我们所看到的现象。如果此时使用的应用程序发出的就是超大包。此时就会导致应用程序不能通讯了。

　　而xp操作系统自带的vpn拨号程序却可以将超大包允许分片发出。这样就出现了使用xp系统能够正常通讯了。试图在windows 2000 server系统的注册表中。找出修改该功能的键值。从而实现分片功能。但是很遗憾没有找到。

　　批注：这一部分的分析过程，要求工程师对故障涉及的技术理论有较深入的理解。

　　向用户解释故障原因后，将windows 2000 server操作系统的主机更换成xp操作系统。

　　建议在网点处使用专用vpn设备直接与市中心的vpn设备之间建立SITE-TO-SITE模式的vpn连接，减少vpn拨号的复杂性和局限性。

　　在涉及到广域网通讯时，如果正常报文大小的PING测试能通过，而大报文PING测试失败，要考虑MTU方面的问题。

　　某客户反馈. 该处使用我司R2690路由器为出口设备,线M SDH线路.近一个月反复出现内网访问外网掉线故障,每天少则掉线三四次,多则七八多次.同时访问内网服务器还存在掉包情况。

　　应用说明：用户网络中心是一台S2150G交换机，通过下挂一些非网管交换机连接本单位所有PC，本地数据服务器直接连接在S2150G上。用户出口部署了一台R2690路由器，路由器连接G/V转换器－》光猫，通过一条2M SDH线路访问省中心数据服务器。

　　用户访问接入在S2150G交换机的本地数据服务器时，发现服务器响应缓慢。用户在客户端PC 上PING 本地数据服务器，发现有丢包情况。

　　用户访问省中心数据服务器时发现有时无法连接，此时用户在客户端PC PING 省中心数据服务器，发现无响应，用户不做任何操作，过一段时间后访问外网自动回复正常。

　　故障初次发生时间及频率：内网访问掉包与外网访问无法连接的故障初次发生大约在一周前。内网访问掉包故障现象一直存在；外网访问无法连接的故障最初时一天发生2－3次，到向我工程师报故障时，一天出现7，8次。

　　→ 首先排查内网掉包问题。与用户交流得知,该公司网线已经使用了五六年,许多信息点PC虽然是百兆网卡，但都无法使用100M,只能在交换机上将端口降为10M后,线路才能使用。由此判定用户线路一定存在老化现象,建议用户更换掉则部份线路。

　　批注：首先，将故障分段。优先处理内网故障，防止内网故障干扰外网故障排查。对网络掉包故障，根据分层法，先处理物理层存在的问题。

　　→ 用户重新部署线路后,反馈信息点可以使用 100M 访问网络了,但内网访问还是有掉包情况,检查用户 S2150G 配置，只有 VLAN 与管理 IP 配置，确认配置无误。

　　批注：和网络设备相关的故障，排除线路问题后，通常先确定设备配置是否正确。

　　→ 建议用户在 S2150G 上直接连接两台用户PC 相互 PING 测试，发现还是存在掉包的情况，因此使用一台备件交换机，导入故障交换机软件配置后替换掉故障交换机，故障消失，经过长时间 PING 大数据包测试，无掉包情况 。

　　批注：先根据分段排查原则，将测试 PC 直连中心交换机，避免中间设备与线缆干扰同时根据替换法，怀疑设备问题时，使用另一台设备替换排查是最简单，也是最有效的方式。

　　→ 将交换机替换后,内网访问掉包问题解决,但外网口掉线情况依然频繁。检查路由器配置，未发现配置错误；检查 CPU 利用率，为 2％。于是检查设备版本信息：

　　→ 设备软件版本已是最新，对该版本 TAC 中心没有通告过类似故障情况。

　　批注：根据分段排查原则，在确认内网正常后，对出口问题排查路由器工作状态。对于掉线类型的故障，确定路由器设备配置正确的同时，也要确定 CPU 利用率是否过高。此外我们建议确保设备软件版本是我司发布的最新相应版本，软件版本可以登陆锐捷网站下载。

　　从倾斜部分我们可用看出,物理线路正常,问题出在 LCP 协商上，接口状态提示有环路。

　　批注：根据分段排查的原则，我们可以通过 SH INTERFACE 命令，确认故障发生时，路由器外网端口是否正常转发数据。

　　→ 电信工程师配合将光猫到局端打环测试,发现光猫设备存在问题,电信将两端光猫更换,但测试发现故障依然存在。

　　在sh interface serial 4/1 输出中LCP 协商一直为Acksent 的原因找到,继续分析，网络使用一段时间后，会 rcvd id 与 sentid 号出现不一致现象。向 TAC 中心反馈该情况后，初步判定问题可能是因为 G/V 转换器处理异常造成（此部分只能根据获取的 DEBUG 信息估计，协议转换器的内部具体情况，我们不了解）。

　　批注：根据分层排查的原则，通过 DEBUG 方式排查 PPP 协商故障原因。

　　→ 将本地 G/V 更换为与对端相同品牌,相同型号的 G/V,测试一天,网络稳定。

　　对于 PPP 协商导致的故障，利用相关的 DEBUG 命令，能比较迅速的找到问题所在，前提是需要工程师对 PPP 协商过程熟悉。3. 访问 internet 丢包和网速慢故障

　　用户访问 internet 很慢，网页打开速度不能忍受；ping internet 上服务器丢包严重；故障发生在每天的中午 12 点以后，持续到下午 17 点左右的下班时间。故障连续 3 天发生。

　　应用说明：用户网络通过 S6806E 汇聚后，出口部署一台 CISCO6509。ISP对用户出口线M 限速。

　　某用户反映访问 internet 很慢，网页打开速度不能忍受，需多次刷新才能打开；ping internet 上服务器丢包严重；故障发生在每天的中午 12 点以后，持续到下午 17 点左右的下班时间。故障连续 2 天发生。

　　由于前二天故障发生时，恰逢中午，工程师已经安排任务，只能通过远程电话支持，通过简单的网络性能参数查看，判断网络故障与设备无关，故障与环境有关，根据故障发生的频，故障很可能在第三天重现。第三天，工程师安排现场观察，以便故障重现进行故障定位和分析。

　　→ 根据前两天的故障现象：故障发生在中午 12 点多，持续到下班时间，故障即可恢复。首先查看配置，确认配置没有问题。

　　→ 根据故障发生时，引导用户查看核心设备和出口设备的 cpu、内存利用率， 发现都在正常范围之内。判断故障与设备性能关系不大。

　　→ 根据故障时引导用户的ping 测试，发现到对方 ISP 的地址 ping 无丢包，到 ISP 的下一跳出现丢包率很高的情况。判断故障很可能与运营商的设备有关。

　　→ 第三天抵达现场，将前两天的测试和以上分析与用户交流。用户开始与运营商交涉，并将以上第三点严重化，质问运营商。运营商不敢怠慢，协调工程师与用户一起解决问题。很快 ISP 反馈回来，近两天用户在某个时间流量异常，持续流量达 40~100M，而 ISP 提供给用户的是 20M 的流量，此时 ISP 的工程师提供近 5 天来的用户流量图：

　　说明：从上图可以看到异常流量在每天都持续 2-4 个小时，流量在 50-100M之间。

　　→ 根据 ISP 的反馈和提供的流量图，可以看到平均流量在 10M 左右，近 2 天的流量中，有持续达到 100M 的情况。根据 ISP 提供的流量图，结合 ISP 对用户带宽控制机制的了解，初步结论如下：ISP 的网络设备针对用户的流量做20M 限速，在流量异常时，超过 20M 的流量都被丢弃掉，大约有 2~3 倍于正常流量的流量被丢弃掉了。可以想象大部分用户的业务、办公和 internet 访问流量被丢弃，以至于用户反映网络访问速度不可忍受。

　　批注：根据基准线排查原则，以 ISP 限速 20M 的设定，可以明确的判断出用户发出流量异常，现在问题便是如何找到异常流量的来源。

　　→ 由于流量引起故障，故障处理从流量监控着手，查找故障源。到达用户现场， 开始部署流量监控软件，对核心 cisco6509 的上联出口接口，下联汇聚交换机接口、RSR-04E 下联接口、上联接口、RG-WALL1200 上联口和下联口进行流量监控。采用软件 SolarWinds，软件对设备通过 snmp 对接口的流量进行读取。并描绘流量图。

　　→ 通过观测，在中午 12 点左右，网络流量异常。此时从 cisco6509 的接口流量图可以看到，下联汇聚交换机 S6806-1 的接口流量异常。

　　→ 此时将异常流量的故障源定位在第一台 S6806E-1 上，在该设备上打开 snmp， 对其所有 up 的接口进行流量监控。发现该交换机的 g2/14 流量异常，定位故障源位于该接口下，如图：

　　→ telnet 到该 RG-S2150G 上，使用 show counter 查看所有接口的计数信息，发现 F0/5 接口数据发送流量大，高于接受的 500 倍，将其隔离出网络，出口的流量即恢复正常。异常流量如下图:

　　→ 通过使用 show mac-address-table interface f0/5，发现从该接口学习到的 mac 地址数为 1，判断 f0/5 接一 pc；pc 瞬间发出大量的数据报文实数异常，将其隔离网络，网络流量恢复正常，用户对网络访问正常。

　　→ 在大型园区网，如果存在网络不稳定的情况，如持续一天的某个时段用户访问 internet 出现严重丢包或者网络应用不能使用的问题，一般都是由于流量过大，超出部分被 ISP 丢弃导致的。一般大型园区网的出口带宽在 10-100M 之间，而出口设备一般为 1000M 设备，设备性能一般不是问题。

　　→ 在大型园区网的网络管理中，部署流量管理工具，对关键设备接口的流量进行监控，为网络管理和故障处理提供基准线. 小结

　　以上三个排错案例，每一个案例在排查过程中都融合了几类排错方法。在实际工作中应用时，需要你根据实际情况与个人经验灵活应用。还有很重要的一点， 通过一次排错，你要能有所学习与总结。如何引导客户详细描述故障现象和信息

　　在多数情况下，你会听到客户这样的求助，他说出了一个常见问题，但又没有该问题产生原因的任何信息。例如，客户说：“我的机器不能够访问 FTP 服务器了”。此时，你就必须以系统的、渐近的、有序的一系列问题引导客户，以得到所有的相关信息。

　　你定位网络问题的过程，实质上是一个不断提出问题的过程（问客户或问自己），提问通常应当以这样一个顺序进行：谁出了问题；是什么问题；何时产生的；何处出现的…….并且这些问题是可以循环提出的，当你提出一个问题的时候，必须能够根据用户对该问题的回答继续提问，直到对整个问题有了一个准确的了解并满意为止。

　　是连通性问题，还是性能差的问题？如果是连通性问题，是完全连通性问题？还是部分连通性问题？

　　故障发生在核心区域、边缘区域还是接入区域？核心区域的故障，你的提问可能应关注下列方面：

　　对找出问题最有帮助的线索，往往就是问题发生前的一系列操作，因此，你的说明应该包含操作步骤，以及网络的反应，直到问题产生。

　　如果你的说明很长，在开头简述问题会有所帮助，接下来按时间顺序详述。这样其它支持工程师们就知道该在你的说明中找什么。

　　本篇文档开篇以三个真实的网络故障处理情况为例，说明我们是如何将排错理论应用到实际工作中的；并在此基础上提炼了一些问题，当故障发生时，你可以参考这些问题向用户了解网络故障信息。