网络排障少走弯路两案例速解网管疑难,浅淡网络运行的迫切故障管理及对策

导读:为了提高广大初入此行的网管读者们的紧急故障处理水平,故策划了本文,将这几年来的经验撰写出来,与读者分享管理思路和控制管理能力的思维。

导读:为了提高广大初入此行的网管读者们的紧急故障处理水平,故策划了本文,将这几年来的经验撰写出来,与读者分享管理思路和控制管理能力的思维。

在网络的管理运维过程中,可以说故障是不可避免的。如果有管理员企图打造零故障的网络,只能是徒劳。因为网络故障有太多的随机性和偶然性,何况还有人为因素。所以,管理员要做的是掌握网络排错技巧,积累经验培养敏锐的嗅觉,能够少走弯路,快速定位并排除故障。笔者做技术支持时目睹过不少网管的排错过程,也看过一些别人的排错文章,发现有不少人有意或者无意地走了不少弯路。下面很大家共享两例网络排错案例,希望对朋友们有所启发。

随着信息化进程的飞速发展,网络已经成为每个现代企业必须的要素之一。相对于网络维护,网络运维更加侧重于保障网络系统的正常运行,运维有运行和维护两层含义。对于一个系统,有时出错我们无法预知,系统越复杂,其难维护难度更大,为了减少损失,我们尽可能地去预防各种错误,对于突发情况,尽可能地去修复。

随着信息化进程的飞速发展,网络已经成为每个现代企业必须的要素之一。相对于网络维护,网络运维更加侧重于保障网络系统的正常运行,运维有运行和维护两层含义。对于一个系统,有时出错我们无法预知,系统越复杂,其难维护难度更大,为了减少损失,我们尽可能地去预防各种错误,对于突发情况,尽可能地去修复。

  案例一:病毒引发的网络故障

紧急故障解决的通用流程

紧急故障解决的通用流程

  故障现象

在本文开始前,笔者先给出紧急故障解决的流程图,见图一。

在本文开始前,笔者先给出紧急故障解决的流程图,见图一。

  早上刚上班,用户打来电话说某个子网的客户端无法正常上网。并且反馈信息,在Ping
DNS时断时续,远程登录三层交换机,检查连接用户办公楼端口,未发现有异常情况。

图片 1

图片 2

  故障诊断

图一

图一

  笔者建议管理员首先检查网络是否出现风暴或网络回环。打开Sniffer软件监控用户所在网络,看是不是出现流量异常的现象,监控两个小时后发现流量很正常。很奇怪,据用户反映在中午下班时网络正常恢复正常,但是下午用户又打来电话说网络又不正常了,初步判断问题出在用户端。

根据上述流程图,我们可以一目了然明白处理网络运维的紧急故障的处理流程。

根据上述流程图,我们可以一目了然明白处理网络运维的紧急故障的处理流程。

  笔者让管理员到用户办公室逐个排查。根据用户反映,如果把网卡禁用后再启用,网络就正常了,但过10分钟又无法ping通,周而复始。我们知道,网卡禁用再启用的过程,就是一个Arp的学习过程,在此期间,它会发出一个Arp的请求,询问谁是这个网段的网关,然后得到这个网关的MAC地址,然后当它需要去访问不同网段机器的时候,就会把数据包丢给那个网关。那么,是不是用户的某台机器中了病毒,导致它可以模仿真实网关的地址,使得在局域网内的客户端在上网时都把数据包发给了这个模仿真实网关的机器,从而产生故障?马上找了一台机器用arp
-a命令去查看这台机器默认网关的MAC地址,发现当网络正常时显示的默认网关的MAC地址是正确的,当故障出现时默认网关的MAC地址突然变了。

当客户端发生网络中断的故障后,首先判断用户或终端)到三层网关设备之间通道是否存在问题,从用户或终端)上ping网关是否能通,用户或终端)自身是否发生问题。

当客户端发生网络中断的故障后,首先判断用户(或终端)到三层网关设备之间通道是否存在问题,从用户(或终端)上ping网关是否能通,用户(或终端)自身是否发生问题。

  故障解决

二层网络是否正常:如果用户或终端)ping网关不通,则检查下端二层网络、用户网线、三层网关设备以下网线或光纤是否正常,端口是否UP,是否有CRC
error报文统计。检查二层网络中的交换机设备是否能正常学习到用户MAC地址,检查三层网关设备与二层交换设备之间的连通性、二层设备的CPU利用率是否正常,是否有二层环路造成或病毒攻击。首先确保用户或终端)能正常ping通网关设备。

二层网络是否正常:如果用户(或终端)ping网关不通,则检查下端二层网络、用户网线、三层网关设备以下网线或光纤是否正常,端口是否UP,是否有CRC
error报文统计。检查二层网络中的交换机设备是否能正常学习到用户MAC地址,检查三层网关设备与二层交换设备之间的连通性、二层设备的CPU利用率是否正常,是否有二层环路造成或病毒攻击。首先确保用户(或终端)能正常ping通网关设备。

  记下出现故障时显示的那个网关的MAC地址,然后在楼道交换机上根据这个MAC地址查到是哪个机器,拔掉该机器的网线后,网络恢复正常。至于为何中午下班时上网正常,是因为用户下班时将中病毒的机器关了,所以大家都又能够正常上网。中毒机器杀毒后也恢复正常。

三层网络是否正常:可以通过telnet/console口登陆三层设备,如果有问题,通过ping、tracert、show
logging、端口统计、CPU利用率统计、链路状态、路由表状态、MPLS标签表状态等对问题进行分析,在业务忙时,不得擅自重启或倒换三层核心路由器等设备。

三层网络是否正常:可以通过telnet/console口登陆三层设备,如果有问题,通过ping、tracert、show
logging、端口统计、CPU利用率统计、链路状态、路由表状态、MPLS标签表状态等对问题进行分析,在业务忙时,不得擅自重启或倒换三层核心路由器等设备。

排错总结

如果用户上网或承载业务仍然存在故障,可以查看DNS等外界环境是否正常,承载的业务本身是否发生问题,查看相关告警,然后做出相应的处理。

如果用户上网或承载业务仍然存在故障,可以查看DNS等外界环境是否正常,承载的业务本身是否发生问题,查看相关告警,然后做出相应的处理。

  通过对这个网络的故障分析,我们总结出以下几点:首先是当网络出现故障的时候,一定要多到用户端了解情况,最好能通过用户对故障的描述抓住网络故障的实质。其次,当出现奇怪的网络现象时,可以分析是否是用户端的机器中了病毒导致这种现象发生,并不一定是网络设备的问题。

其它问题,如果现场不能解决,就通报关键用户并联系厂商解决。

其它问题,如果现场不能解决,就通报关键用户并联系厂商解决。

  案例二:用户端交换机环路引起故障

在本文中,笔者就以网络不通的故障为例,讲解网络运维的紧急故障处理的比较通用的思路和解决方式。

在本文中,笔者就以网络不通的故障为例,讲解网络运维的紧急故障处理的比较通用的思路和解决方式。

  故障现象

假设有一天,接到通知报告网络不通了。给人的第一感觉是某个服务出现异常而中断,比如打不开OA页面,或者打不开Google页面。让我们看看,一个合格的运维人员是如何循遵怎样的思路来寻找故障的原因并解决的。

假设有一天,接到通知报告网络不通了。给人的第一感觉是某个服务出现异常而中断,比如打不开OA页面,或者打不开Google页面。让我们看看,一个合格的运维人员是如何循遵怎样的思路来寻找故障的原因并解决的。

  维护人员发现7号三层交换机远程无法登录,初步怀疑设备故障,于是迅速赶到机房检查设备运行情况,设备供电及其与S8016核心交换机连接均正常,在交换机控制口Ping网关不通;CPU利用率38%
;检查运行日志未发现有告警。检查端口,发现e
0/3流量不正常,输入流量远大于输出,将e 0/3
Down后,交换机Ping网关正常,业务恢复正常,检查所有端口,只有

确定哪些服务中断

  三口流量不正常,最后确定是三口所带的用户问题,用户端不停地发包,流量过大造成三层交换机上联口拥塞,从而影响其他用户正常上网。

首先要做的就是区分内网服务和外网服务。

  排错过程

在笔者所在公司中,很多自己开发的、只限于公司员工使用的服务都是内网服务,比如OA、邮箱、ERP等等。而像QQ、微博那样的则属于外网服务了。

  到用户端检查,将用户所用的公网IP配置在笔记本电脑上直接上网,上网正常,确定用户端光电转换器和线路无故障。检查用户交换机配置正常,但是只要接上用户交换机,机房内三层交换机就无法正常工作,判断用户交换机故障。由于用户交换机无资料,无法确定每个端口的业务明细,只有采取将交换机上的连接线一个个拔出,同时检查机房三层交换机运行情况的方法来判断故障点的位置。当将用户交换机e
2/8端口线路拔出后,机房内人员报告三层交换机运行恢复正常,立刻检查该线路,发现这条线路的另一端连接在第e
2/29端口,原来是这条线路两端都连接在交换机上造成环路,导致链路拥塞,用户无法上网。详细检查发现造成环路的端口都未配置,并且没有业务使用,交换机没有发出环路告警。

在这样的环境下,内网服务的网络关键节点如下所示:

  排错总结

终端→接入交换机→联网路由器→核心路由器→核心交换机→服务器

  故障处理完毕后,总结分析如下:

依赖的基础服务为:内网DNS服务器。

  (1).用户交换机走线杂乱,线路未作标签,业务走向不明,是造成环路故障的主要原因。

外网服务的网络关键节点如下所示:

  (2).由于造成环路的端口未使用,没有配置业务,导致交换机无法在13志中产生环路告警,也未能报告出哪个VLAN故障。

终端→接入交换机→核心交换机→互联网接入交换机→上网行为管理设备→互联网防火墙→外网服务器

  (3).环路可造成广播风暴,数据流量猛增,造成汇聚设备上联口拥塞,远程无法登录。电脑中ARP病毒后不停发包,也能造成设备死机,远程无法登录,两种情况有相似之处。

依赖的基础服务为:内网DNS服务器,公网DNS服务器。

  总结:两个简单的案例,带给我们不少启发。希望管理员朋友们在日常的维护工作中注意机房内的资料整理,确保线路连接整齐规范。在处理故障时多注意观察三层交换机日志和端口流量,能有效地减少网络故障和处理故障时间。

如果当前访问的服务突然中断,那么首先看看是内网的服务还是外网的服务。然后再在内网和外网分别自选一种服务尝试访问一下。例如ERP突然无法访问了,那就尝试访问一下内网的门户系统和邮件系统,以及外网的一个知名网站。

以下表格(表二)有助于理解故障寻找的过程和思路:

图片 3 
图片 4

表二

确定其他人的症状相同

只是从自己的机器对网络和服务做出判断并不够客观,也不够严谨。前面我们已经大致的推测出故障原因,在这一节我们尝试对这个推测进行证明。

要记住这一点:可重复的结果才是基本可靠的结果。

为了证实测试结果的可重复性,我们需要从不同的网络起点重复相同的测试步骤。

让我们以公司的实际场景来阐述分析故障的思路。目前随着网络技术的成熟,网络架构也趋于稳定,一般的全省级的公司网络拓扑示意图如图三:当然,实际工作中,地市分公司下面,根据业务需要,还会有县级的办公网络、营业网点,实际广域网络会达到三层。

1、要保障全省骨干网络运行安全,在总部核心区域会采用双核心路由器和双核心交换机的冗余架构,做到核心设备和线路的冗余,并保证网络业务调整的弹性;

2、服务器区根据业务运行安全考虑,也将进行分区,不同业务区域的服务器接入不同的服务器交换机,双线上联到核心交换机。

3、地市公司采用路由器和省公司联网,公司在线业务系统重要性较高的情况下,地市分公司到总部会采用租用不同运营商的线路,做双线上联。

4、,公司的办公室电脑通过接入交换机接入局域网。接入交换机上可根据办公业务区域划分VLAN,增加内网安全性。

图片 5

图三

在这种网络环境下,将一般骨干网出故障的情况降到最低,但是实际工作中,还是有不少网络用户会反映这样那样的网络问题:例如我们自己的计算机客户端不能访问ERP系统,并且Ping不通ERP系统的IP地址,那么我们会据此推测ERP系统的服务器失去响应了;如果在自己电脑上还能ping通其它服务器IP地址,或访问其它服务(譬如WEB方式访问OA正常),那ERP系统的服务器失去响应了可能性大大加强;最后,如果在我隔壁办公室的同事也出现了同样的问题,我们就有更大的把握说ERP系统确实出现了问题;如果其它反之,如果其他人一切正常,只有我自己无法访问ERP系统,那么很大的概率是自己的计算机出现了问题。

确定服务中断是软件还是硬件所致

如果某个服务出现中断,大致上的原因一般为网络链路、网络设备、服务器等硬件问题或者服务器操作系统、应用系统等软件问题。我们可以使用ping这个操作系统自带的命令行工具来对这两种原因进行区分。

判断原则:Ping不通服务的IP地址属于硬件故障,能ping通则为软件故障。

Ping不通服务的IP地址属于硬件故障,能ping通则为软件故障。但是如果设置了服务器不对Ping做出响应的话,这时候可以使用nmap来探测目标设备。有关nmap的资料可参阅《浅议广域网中主机发现与管理:

其他人和我一样吗?其它系统和疑似故障系统一样吗?

只是从自己的机器对网络和服务做出判断还是不够客观的,我们还需要更严谨的论证。前面我们已经大致的推测出故障原因,在这一节我们尝试对这个推测进行证明。

判断原则:可重复的结果才是基本可靠的结果。

让我们以几个假设来掩饰解决故障的思路。

假设1:总部A用户Ping不通服务器a而B用户可以。

因为A与B用户访问服务器a走过的是同样的网络路径,都是经过接入交换、核心交换、服务器交换,所以问题出在甲用户的自身。

假设2:总部A用户可以访问服务器a而不能访问服务器b,B用户有同样的故障现象。

因为A与B用户访问服务器a、b走过的是同样的网络路径,所以一般可以证明是服务器b本身问题或者是服务器b接入交换机硬件设备或上下行网络链路问题。

假设3:某个分公司E用户与F用户不能访问任何一台服务器,而总部A、B和分公司C、D四个用户没问题。

因为该分公司E、F用户访问任何一台服务器都要经过分公司接入交换2和联网路由2,所以应该联网路由2是关键节点,联网路由2本身的物理故障、联网路由的协议、或者网路由2和核心路由网络链路故障都是首先排除范围。

假设4:某个分公司C用户发现无法访问服务器a,询问后得知其他用户故障现象相同。

由于每个用户访问服务器a的路径不同,所以越靠近终点的网络路径和网络设备可疑性最大。从图三来看节点是服务器a的接入交换机这节点可能性最大,为较严重故障。

确定断点在何处

根据前面的排查,已经可以基本的确定是不是服务器的问题。如果是网络的问题,那么我们还要确定出断点才行。现在,我们要使用ping和tracert这两条命令完成这项工作。

假如我们事前已经对网络的拓扑很了解,并且知道一些关键节点的IP地址,那么我们只需要参考由近至远的原则逐个ping这些IP地址就可以知道断点的位置了。可是我们日常要访问的服务有很多,怎样才能知道数据怎样从我自己的计算机流向某个服务器的呢?Tracert命令就是为了解决这个问题的。只要Tracert某个域名或者IP地址,它就会把经过的设备的IP地址按照先后顺序显示在屏幕上。如果从某一行开始就不再显示IP地址,那么它的前一行的IP就是你尝试访问的目标所能到达的最后一台设备的IP地址。

建议在平时网络正常的时候就Tracert一些经常访问服务器的IP地址,记录下来正确的步骤是怎样的。等日后服务出现中断时可以用来比较路由有没有发生变化。

确定真正故障原因

故障的原因永远是匪夷所思的,需要专业的技能来做综合的分析、全盘的考虑和一些专业的测试。既然作为一个用户不可能做到这些,那么还是把探索真相这项艰巨的任务交由那些专业人士来完成吧。下面给出一张有可能造成服务中断的故障原因的统计图表,见图四。

图片 6

图四

题外话

现在公司信息中心的岗位划分的比较细,如果你是某个专业应用的项目组,那么假设你现在已经大致知道了发生了什么事,还知道了哪些部门需要对此事负责,那么就致电需要对此事负责的部门,询问当前是不是一次计划内的停机或者检修。如果是的话,弄明白为什么事前没有收到通知。如果不是计划内的,告诉他们你已经掌握的所有事情,这可以帮助他们尽快修复。然后致电所有你在排查期间帮助过你的其他部门或者同事,通报最新的消息给他们。最后致电你的关键用户,向他们解释发生了什么事,告知有望恢复正常的时间,并通过有效手段发布通知所有可能受到影响的终端用户群。

另外,如果问题处在自己负责维护的范围内,请在第一时间修复。

如果你是地区公司的网管,首先要看这次服务中断是不是发生在你自己的职责范围内。如果是的话,修好它。然后通知本公司的关键客户,把问题解释清楚。如果你的反应比较迟缓,那么你的关键用户有可能直接询问总部的相关负责人,最后再找回到你的时候压力会大得多。最后通知可能被涉及的所有终端用户。

结语

网络运维有不同的分工,在大公司和大网络环境中这种分工很明确,比如有设计规划网络的,有管理网络安全的……很系统,也很专业,要达到这样的高度,需要有深入的理论基础和丰富的实际经验作为保证。

然而在相对较小的网络环境中,网络管理员负责的事情是从设计规划网络,建设网络,管理服务器,到购买网络设备等所有与网络有关的事情,经常被作为”万精油”来使用。所以说做这一行的挑战是很大的,是否能有长进取决于自己。如果能够一直坚持做下来,并且抓紧时间不断补充新知识,最终还是可以达到网络管理的顶峰。

如何开始面对那么多的工作内容,我们首先要清理出主次先后。第一步就是要从了解操作系统出发,因为大部分时间我们都是在与各种操作系统打交道,如Windows、Linux、Unix和Mac
OS
X都是需要涉及的。了解了这些操作系统的理论知识和操作方法还不够,我们还必须具备解决问题的能力。这需要很强的操作能力和清晰的思路,你可以去网上看看讨论区的文章,多动手处理实际问题。解决问题时不仅要知道解决之道,而且要学会去发现导致问题的原因。

Post Author: admin

发表评论

电子邮件地址不会被公开。 必填项已用*标注