公告 更多

　　【编者按】技术部维护工程师在工作中积累了丰富的经验，他们以自己实施的各类项目为蓝本，编撰了涉及处理故障、方案设计等方面的案例，以下是在集锦中选摘的四篇文章。

　　案例一：服务器双网卡虚拟单网卡工作不稳定导致stp动荡

　　【基本信息】

　　某校园网使用华为3Com的S8512双核心，服务器群直接接在85上，服务器群采用双归设计，每台服务器配有两块网卡，分别接主备85，双网卡使用自带的小软件，虚拟成一个网卡，共用一个ip地址。

　　网络拓扑如下：

　　【问题描述】

　　客户反映：

　　S8512双机热备，PC ping 85备机地址丢包在5%左右，按常理在Lan中应该无丢包观测发现ping过程出现连续中断，用户反映经常出现此情况

　　Ping statistics for 172.17.50.252:

　　Packets: Sent = 692, Received = 653, Lost = 39 (5% loss),

　　Approximate round trip times in milli-seconds:

　　Minimum = 1ms, Maximum = 62ms, Average = 8ms”

　　【问题解决过程】

　　根据现象分析，可能的原因有三：

　　1、arp 刷新导致

　　2、stp动荡导致

　　3、聚合链路散掉导致

　　如果是arp刷新网络肯能会中断很久，不会是瞬断的现象，所以先考虑其他两种情况。观察设备信息，聚合链路无异常信息，工作正常。于是从stp动荡入手分析。

　　用户十多台服务器，均使用双网卡连接主、备85，网卡采用自带软件，配置一个虚拟网卡ip地址。现怀疑网卡软件不稳定，断时间内出现软环路，导致stp动荡，于是配置服务器与备85连接端口的stp 优先级降低为160，即使出现动荡也中断备用链路。

　　配置完成后，故障现象没有再出现，问题解决

　　(撰文： 赵文瑞)

　　案例二：某省教育厅S6503跨MPLS VPN组播业务

　　【基本情况】

　　省各地市会结点通过MPLS/VPN域与省教育厅连接。组播源在省教育厅，调试时在省教育厅连接机房的7206上挂了一个测试PC A同时在会结点还有一个测试PC B，其目的是可以分段测试各线路。

　　【调试过程】

　　根据客户需求将RP设为省教育厅S6503内网接口地址，沿途各运行组播协议的路由器全部将RP指向这里。

　　调试第一步为省教育厅与测试PC A之间。调试过程中发现Cisco 7206上使用的组播模式为混合模式(pim sparse-dense-mode)。根据200401期案例了解到其与标准的SM模式有区别，7206修改为PIM SM之后组播测试通过。

　　第二步测试与地市之间的组播业务，首先确保单播正常。测试组播时发现在S6503端有相应的igmp group信息存在，在盈通7206上却不能正常收到join信息，导致组播业务不通。

　　【原理分析】

　　分析原因发现地市会结点盈通设备为两台7206构成的HSRP，会结点S6503设置默认网关至HSRP虚地址。敲dis pim nei发现pim邻居为两台7206的实地址。

　　[S6503]dis pim neighbor

　　Neighbor's Address Interface Name Uptime Expires

　　192.168.1.147 Vlan-interface100 00:01:41 00:01:34

　　192.168.1.148 Vlan-interface100 00:01:43 00:01:32

　　在dis pim rout中发现所有的RPF邻居均指向虚地址(192.168.1.145)，导致pim邻居和RPF邻居不一致。

　　RFC2362中有如下说明：A router sends a periodic Join/Prune message to each distinct RPF neighbor associated with each (S,G), (*,G) and (*,*,RP) entry.Join/Prune messages are only sent if the RPF neighbor is a PIM neighbor.

　　因此S6503并没有向7206发送组加入信息，导致组播业务不通。修改默认路由，指向实地址中大的那一个，同时盈通方面调整相应的Active路由器。再次进行组播业务测试，通过。

　　【总结与思考】

　　本次调试由于HSRP虚地址导致组播业务不通，在Cisco设备上有一条命令：ip mroute 0.0.0.0 0.0.0.0 192.168.1.148。如此可以在不修改默认单播路由的情况下直接修改组播路由。在我们的设备上是否也有相应的命令?否则用户就必须修改默认路由，这样HSRP就没有起到相应的备份.

　　(撰文：王智刚)

　　案例三：华为与Cisco设备互连PVST问题

　　【组网拓扑】

　　【问题描述】

　　某政府网中采用华为3Com的一些设备，包括S8505,多台S3526设备，S85上行接入电子政务城域网，下行接Cisco S3550设备，再下行接S3526设备(放在下面街道居委会)。下面再通过盈通的网络(注意：里面有Cisco设备)，连到下面的2层设备。

　　客户放映：在华为3Coms3526设备上Ping 不通19.133.218.168的地址，但能ping通19.133.218.5 地址，如果把华为3Com的S3526换上Cisco 设备都可以Ping 通。

　　【问题分析及解决方案】

　　根据现场了解的基本情况，全网路由采用ospf， 华为3ComS352和cisco 3550 起trunk，让所有vlan通过，其他口是Access口，检查所有的线路发现都应该没有问题，但为什么会出现这种情况了，而且S3526换成Cisco的设备就没有问题， 所以我们做了几种实验尝试来发现问题，但奇怪的是出现了以下几个现象：1.在s3526上能ping通直连pc ：19.133.218.5 ,不能ping通经过了盈通提供的网络接了2层设备下的pc：19.133.218.168地址，换上Cisco 的设备都可以ping通。

　　2.把S3526与cisco 3550连接的口改为access ,都能ping通。

　　3.拔掉S3526的上行口，都能够ping 。

　　经过定位，我们发现肯定是华为与cisco互连时的问题，而且cisco3550设备上起了PVST ， 华为不支持这种协议。华为3526与cisco 3550连接口为Trunk, 但是其他口是access口，pvst报文会通过Trunk口广播，发现华为的设备不支持，会透传，但是到盈通的Cisco设备时，因为是access口，它会以为有环路，所以把cisco设备那个口discarding 掉，所以ping 不通。把S3526换上cisco 设备能够ping通，是因为cisco设备支持pvst ，它不会透穿pvst报文，而会把pvst报文终结掉。

　　所以我们加入一条acl ，把pvst报文在华为交换机上终结掉，并在全局模式下发，问题得到解决，改正后的配置如下：#acl number 4000

　　rule 0 deny ingress any egress 0100-0ccc-cccd 0000-0000-0000

　　# packet-filter link-group 4000 rule 0

　　【总结】

　　我们把握一个原则，如果华为3Com设备放在cisco设备的中间，而且cisco设备一个起了trunk，一个起Access，而且Cisco设备起了PVST ，那条acl 一定要配置，否则会造成不通的情况。

　　(撰文：曾小伟)

　　案例四：报文分片对业务的影响

　　1. 四川某集团组网案例

　　组网：总部和分支通过secpath建立vpn，分支pc通过vpn访问总部server

　　现象：远端pc无法调用server的oracle数据库，其他操作能正常进行

　　问题分析：

　　这种现象一般都是由于mtu造成的，因为链路上的某个设备接口mtu太小，从而导致路径mtu小，而在pc与server进行tcp协商的mss+40(ip头20+tcp头20)>pmtu，如果这时候ip头的DF位置1，报文不分片;而ISP中间的某跳设备又不支持路径MTU发现机制或有防火墙禁止掉了icmp报文，导致无法向pc返回icmp不可达报文，从而导致业务不通。

　　如果是DF没有置 1，那么即使mss+40(ip头20+tcp头20)>pmtu，报文到了设备后将进行分片操作，然后到目的端的I P层将进行重组，业务也能正常开展。

　　处理过程：

　　首先在pc上ping –f 远端server确定路径mtu，根据mss+40≤pmtu，修改secpath的接口mss，一般根据经验修改为1024，或者用二分法，问题解决。

　　2.某公司通过l2tp后无法打开中心服务器网页

　　组网：pc通过BAS(lac)pppoe上来，然后建立l2tp隧道访问网站

　　现象：pc通过l2tp拨号到LNS后，无法打开内部网站网页

　　问题分析：

　　问题给人的第一感觉就是mtu问题。如果报文长度超过了接口mtu，并且报文df没有置位，这个报文将会分片传输，而到达对端后将进行报文的重组。

　　如果报文中df位被置1，那么，用户的报文长度超过mtu后，设备会向报文原地址主机发出icmp type=3 code=4 的保文要求降低分组大小，主机降低到传送路径最低值发送报文，也就是pmtu。如果用户ip报文的 DF置1 ，而链路上某一台设备过滤了icmp type3 code4 的报文，用户报文遇到小mtu的路径后就不会收到响应来降低报文分组长度;而这个时候pc与网站协商出来的mss+40>pmtu，就会产生无法打开网页的现象。

　　处理过程：

　　1，首先在pc上ping内部网站，只能ping通到1434以下，因为隧道ip层20byte+udp 8byte+L2TP 8byte+ppp 2 byte+ 隧道内 ip 20byte+icmp 8byte =66byte，通过此方法确定pmtu。

　　2，抓包发现ip头DF=1，如下图：

　　3，按照上面讲述的原理，根据经验值修改LNS的虚模板和内网接口的tcp mss为1024，问题解决。

　　☆☆☆：在以上两个案例中，我们都是靠修改接口的mss参数解决问题，实际上，在tcp协商的时候，两端会发一个syn报文，报文中携带有mss，我们的修改设备接口的mss目的是：如果检测到pc发送的mss大于我们设置的数据，就修改报文这个值，来达到保证mss+40≤pmtu的目的。