公告 更多

　　【編者按】技術部維護工程師在工作中積累了豐富的經驗，他們以自己實施的各類項目為藍本，編撰了涉及處理故障、方案設計等方面的案例，以下是在集錦中選摘的四篇文章。

　　案例一：服務器雙網卡虛擬單網卡工作不穩定導致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的目的。