维护案例汇编-数据专业.doc

维 护 案 例 汇 编所属专业:【数据】目录：案例一、局域网网络障碍的处理；案例二、电节点下用户频繁掉线；案例三、电节点IAD设备在市电正常情况下供电不良；案例四、POE远程供电设备排障；案例五、光节点交换机未掉电情况下上行端口反复重启；案例六、光节点下测速无法达到正常指标；案例七、三层交换机以太电口下带用户业务障碍；案例八、IP网VPN电路用户业务障碍排障；案例九、华为三层数据交换机与中兴三层数据交换机直联互PING包；案例十、中兴三层数据交换机转发丢包。案例一、局域网网络障碍的处理；现象描述：局域网中部分或全部用户出现网络无法连接的情况。告警信息：设备指示灯正常，但无法远程管理，查看设备CPU占用率高达90%。故障分析：设备未掉过电，曾经可以正常使用，但部分业务端口数据流量异常较大，且广播报文包数量极多。处理过程：1、查看设备告警日志；2、备份设备上全部数据；3、重新启动数据交换机，障碍现象并未消失；但在重新启动之后短暂时间内，业务恢复正常，不久再次出现原有障碍现象。4、将全部已连接的业务端口做好标记；5、拨出全部业务端口连接五类线缆，此时交换机恢复正常，远程可以管理；6、将业务线缆逐一重新连接至交换机，并在连接过程中进行端口逐一观察；7、发现4个异常端口，业务端口五类线缆连接后，再次出现上述障碍情况，拔出某一业务端口后，出现2个端口同时DOWN掉的情况；8、反复测试核实后，确认此交换机上存在2对环线；9、清除环线之后，设备及设备所下带全部业务恢复正常。总结和建议：处理局域网障碍时，应当考虑其均在一个内部网络之中，可能存在着ARP攻击、广播风暴、病毒感染、环线等问题，应当对全部的端口数据进行检查，同时对网络结构进行清晰地分析及了解。案例二、电节点下用户频繁掉线；现象描述：某一电节点下用户出现不规律掉线情况，掉线后不需要重新拨号可以再次连接网络。告警信息：查看光节点二层数据交换机及电节点交换机，确认无重新启动情况，且对应电节点的端口未有UP或DOWN的相关信息。故障分析：用户不需要重新拨号即可连接网络，说明从用户端至电节点交换机之间未曾出现过中断连接的情况，且二层数据交换机未层出现过重启的情况。处理过程：1、查看二层数据交换机及电节点交换机设备告警日志；2、备份设备上全部数据；3、重新启动数据交换机，障碍现象并未消失； 4、对二层数据交换机及电节点交换机取电情况进行现场测试，确认电压稳压；6、核实三层数据交换机数据；8、核实三层数据交换机告警日志；9、发现核实三层数据交换机有重新启动的情况；10、进一步确认三层数据交换机存在问题，更换核实数据交换机后，业务正常使用。总结和建议：处理此类障碍时，应当逐段分项进行核实，明确每一网络层面设备的正常使用情况及告警内容，针对存在异常的设备应当进行数据备份，且明确取电情况，并测试电压。案例三、电节点IAD设备在市电正常情况下供电不良；现象描述：某一电节点IAD208M设备在市电供电稳压的情况下，出现反复重启的情况，并已确认电节点IAD208M设备无问题。告警信息：查看电节点交换机，发现告警记录均为重新启动，并无其他内容。故障分析：考虑到电节点IAD208M属于远程供电而非本地取电供电模式，障碍入手应当从光节点侧入手。处理过程：1、查看二层数据交换机交换机设备告警日志；2、检查光节点POE远程供电设备；3、核实电节点IAD208M下带用户数量及用户所使用业务内容； 4、对二层数据交换机及光节点POE设备的取电情况进行测试；6、对光节点市电取电情况进行测试；8、确认光节点POE设备供电总功率及单一端口供电功率；9、经核实确认障碍原因是由于光节点POE供电设备单端口供电功率小于下带电节点IAD208M输出功率所导致。总结和建议：处理此类障碍时，应当逐段分项进行核实，明确每一网络层面设备的正常使用情况及告警内容，明确取电情况，并测试电压。案例四、POE远程供电设备排障；现象描述：某一光节点下带的IAD208M设备在市电供电稳压的情况下，出现反复重启的情况，并已确认电节点IAD208M设备无问题。告警信息：查看电节点交换机，发现告警记录均为重新启动，并无其他内容。故障分析：考虑到电节点IAD208M属于远程供电而非本地取电供电模式，障碍入手应当从光节点侧入手。处理过程：1、现场核实光节点POE远程供电设备取市电，电压情况；2、在确定市电稳压正常的情况下；3、核实该POE远程供电设备前期运行情况； 4、核对过程中，发现该POE远程供电设备前期可以正常运行，后新增一电节点后，出现整机频繁重启的情况，且新增电节点对应POE远程供电设备端口指示灯出现虚亮情况；6、拨出新增电节点缆，光节点POE远程供电设备恢复正常，其下带业务也恢复正常；7、再次接入新增电节点设备之后，业务再次出现上述障碍现象；8、经过查询资料确认，该障碍由于POE远程供电设备整机超出其自身供电功率所导致其自动保护关闭。总结和建议：处理此类障碍时，应当逐段分项进行核实，考虑到电节点设备属于远程供电模式，在排除电节点设备出现问题及连接线缆出现问题的可能性后，应当从光节点POE远程供电设备入手进行考虑及处理。案例五、光节点交换机未掉电情况下上行端口反复重启；现象描述：某一光节点下带的业务反复中断。告警信息：查看光节点交换机告警信息发现其上行端口出现频繁UP、DOWN信息，查看三层数据交换机发现其对应下行端口与光节点数据交换机同一时频繁出现UP、DOWN信息。故障分析：上下两层数据交换机频繁出现UP、DOWN信息。可能存在的障碍点位于三层数据交换机设备端口侧，二层数据交换机上联端口，中间互联链路存在问题。处理过程：1、首先更换光节点数据交换机上行光口模块，更换后障碍现象并未消失；2、更换三层数据交换机对应端口，更换后障碍现象并未消失；3、测试中间连接光缆衰耗，测试结果为-25DB，确认互联链路之间光缆衰耗正常； 4、三层数据交换机局内打环测试，确认端口及局内尾纤正常无问题；6、经过上述测试，确认为二层光节点数据设备损坏导致；总结和建议：在处理此类障碍时，应当首先对网络结构进行了解，然后逐层进行判断分析及测试，更换不同侧设备端口进行观察，最后进行障碍的定位。案例六、光节点下测速无法达到正常指标；现象描述：某光节点下带电节点IAD208M用户反映其上网速度慢，光节点以太网口现场测速400K。告警信息：查看光节点、电节点交换机均无相关告警信息。故障分析：用户反映其上网速慢，电节电测试无问题之后，应将重点集中在光节点及三层数据交换机一侧。处理过程：1、首先查看光节点数据交换机及三层数据交换机端口配置数据；2、查看光节点数据交换机及三层数据交换机的告警信息；3、光节点现场进行测速度实验； 4、三层数据交换机现场模拟光业区组网模式，加载与三层数据交换机同一厂家的二层数据交换机设备，进行下载速度测试；5、三层数据交换机现场模拟单一端口模式，进行下载速度测试；6、三层数据交换机现场模拟光业区组网模式，加载与三层数据交换机不同一厂家二层数据交换机设备进行下载速度测试；7、进行光路功率测试，测试结果正常；8、查看交换机数据包内容，发现部分攻击二层数据交换机的数据包。总结和建议：在处理此类障碍时，应当全面地进行考虑，将障碍点进行明确，分段排查，同时将整个过程中的全部设备及线路进行通盘考虑。将每个障碍点进行逐点排除。案例七、三层交换机以太电口下带用户业务障碍；现象描述：三层汇聚数据交换机以太电口下带业务出现中断。 告警信息：上端查看端口状态为UP，但无MAC地址，用户侧现场查看光电收发器状态正常，环测用户端线路及设备均正常。故障分析：在排除用户端潜在障碍点之后，应当以机房侧潜在障碍点为切入点。处理过程：1、机房侧进行光路环测，判断局内线缆及局内光电收发器模块是否存在问题；2、查看机房侧光电收发器模块指示灯是否存在问题；3、插拔机房侧光电收发器模块； 4、经插拔机房侧光电收发器模块后，业务恢复；总结和建议：此类障碍产生的原因应该为，由于机房或设备温度过高，导致机房侧光电收发器模块过热，导致设备电气性能下降。案例八、IP网VPN电路用户业务障碍排障现象描述：针对二层VPN业务电路的故障，因ISP不参与城域网内三层路由转发，因此涉及网络中断及网络质量等问题，不易判断。告警信息：无故障分析：VPN电路的具体提供形式分为L3层与L2层，这里仅针对L2层VPN电路进行分析。一般L2层VPN电路的故障表现为业务中断，表现为用户A端无法与用户Z端进行通信。处理过程：1、分别查看A端与Z端的接入电路是否正常，主要查看接入端的MAC地址表项是否正常，有无异常MAC地址冲突；2、检查A端与Z端二层VPN电路是否正常，采用分别在A端与Z端建立三层接口IP的方式，测试A端与Z端的是否路由可达；3、如果A端与Z端路由可达，那么说明城域网内的L2 VPN电路正常，可以排除A-Z之间的链路问题。 4、如果A端与Z端的路由不可达，说明中间链路存在问题，需要逐段排查是否存在问题，具体可以采用逐段建立三层接口的方式进行排查；5、在接入点（A端或Z端）存在用户局域网通过L2 层通道在城域网内MAC地址广播，导致CPU占用率较高，容易造成设备无法正常进行业务转发；6、可以采用在A端或Z端接入点限制MAC地址数目，防止用户非法MAC的广播；7、保证业务正常的情况下，可以由用户提供其合法的MAC方式，建立相应的访问规则。总结和建议：处理此类障碍时，应当逐段分项进行核实，明确L2 VPN电路的路由规划，合理采用建立三层接口的方法进行逐段测试。案例九、华为三层数据交换机与中兴三层数据交换机直联互PING包现象描述：某一机房的中兴3952交换机与华为的3528交换机直连的端口经常出现互ping丢包的现象，3952下带的用户反映上网慢的情况。告警信息：查看交换机告警信息，并无其他内容。故障分析：在故障发生时，在3952上ping华为3528交换机的直连接口有丢包现象，3952下带的用户ping3952上的接口地址没有丢包的现象。另外在3952上ping 下带的2852交换机也没有丢包的现象。端口流量也不大，另外设备的CPU使用率在13%左右属于正常范围。在这两台设备之间增加了一条链路进行测试，发现在新链路上仍然有的时候会发生丢包的现象。处理过程：交换机直连接口互ping丢包的情况主要有如下几种可能：1. 网线质量不好，现场的网线进行过测试，并且已经换过网线，另外在华为交换机和中兴交换机的直连端口上并没有CRC产生，基本上已经可以排除网线质量问题；2. 设备CPU使用率过高，在故障发生时，华为交换机和中兴交换机CPU使用率并不高，基本可以排除设备CPU使用率高导致处理能力不够造成的丢包现象；通过对配置的分析发现在配置中有十多个端口都启用了traffic-shape的配置，这些端口应该是与上行口fei_1/44和fei_1/48之间跑三层转发的流量。这些被限速的端口都需要与上行口进行三层数据包的转发。由于下行口收到的不同数据包会转发到不同的上行口，而这些数据包到达的速度只要超过下行口出口限制的速度就会占用上行口的入口buffer。每个下行口最多可以占用上行口32个入口buffer，100M入口buffer一共有50个。所以可以看出只要上行口接受的数据流同时有2个是超过下行口限制速度的就可能会导致上行口丢包（32*2=6450）。出口做限速可能会存在该问题，实际应用中应该避免这种一个上行口对应多个下行口并且下行口做出口限速的情况；针对上述问题，全部端口都使用acl限速的方式进行限速。经过监测，丢包现象已经消失，设备业务均已处于正常运行状态。总结和建议：1、 如果用1000M口做为上行口则可能可以解决现场的问题，关键看上行口接收到的超过限制速度的出端口的数量。用1000m口应该最多可以满足同时10个下行口的流量超过限速的情况；2、 通过acl对需要限速的端口进行限速。 案例十、中兴三层数据交换机无法实现正常业务转发；现象描述： T40G与S3906互连的GE电路正常，但用户上网业务异常，可以正常PING通网关，不能访问目的网站。告警信息：查看交换机，并无异常告警内容。故障分析：T40G与S3906之间的直连链路正常，没有任何异常，T40G与S3906的OSPF 邻居关系建立正常。处理过程：1、 从S3906设备TRACE城域网内目的网站，路由跳数及节点地址正常，说明S3906的OSPF路由表项正常。2、 从T40G上trace目的网站路由异常，最终目的地址的下一跳指向T40G，初步判断是T40G的设备路由问题。3、