很久沒有寫博客了，自從四月份以來找了一份開發的工作開始從事PHP，symfony 網站開發，突然發現好像也沒有什麼東西可以分享了，所以博客也寫的少了。
言歸正傳，最近學校常常有人抱怨QQ掉線，而且據說有嚴重的趨勢，據說之前也有類似的問題不過一直沒有引起足夠的重視，最近反應說掉線非常嚴重，決心解決一下。
首先想到的都是ARP工具，在園區網絡裏局域網工具十分普遍而且也比較嚴重，在覈心交換和接入層交換機上都啓用了了ARP流量控制。幾天下來也抓出來了不少的ARP***的機器，可是掉線的情況還是存在。
後來想QQ是基於UDP協議的，本身就是不保證絕對送達的，極有可能是從內網到騰訊機房的過程中某臺設備CPU或者內存偏高。於是逐一檢查鏈路上的每個設備，對每個設備內存和CPU進行監控和記錄，發現接入層CPU基本爲20%左右，內存40%左右，核心層CPU才5%，內存也就30%，防火牆的CPU在4%左右徘徊，久久不知道到底是那臺設備在丟包。
之後使用jperf_gr對網絡UDP包到達情況進行監視，發現局域網內部發送基本沒有掉包，但是發往公網基本都有20%左右的掉包。不過這個也不能說明什麼。畢竟從電信到聯通服務器，而且從內網發到公網掉一些也比較正常。
之後的一段時間，防火牆廠家，接入層設備廠家陸續到學校進行排查，甚至還將接入層設備卸下進行檢測，也沒有解決問題。
後來觀察防火牆規則發現，所有的內網IP經過NAT轉換後都是使用一個公網地址，懷疑是不是公網地址不足的原因，因爲內網有5個機房500多臺機房電腦，100多教室電腦，加上辦公電腦，服務器，一共可能有800多臺電腦左右，百度之後發現說一個公網地址最少可以帶2K多臺內網，但是我還是在防火牆上對QQ協議的數據包單獨映射了一個公網地址。可惜問題還是沒有解決。
無奈沒有辦法，讓現場掉線的時候抓包發過來看看有沒有收穫。於是就發現了下面的情況：
SSDP在抓包中出現的平率目測就比較高，統計一下發現SSDP包占全部的10%左右，而且後面部分有其他程序在傳文件，產生了大量的數據包，剔除這些影響SSDP的佔比就非常高了。
而且172.16.10.74這個IP地址應該和抓包的的計算機在不同vlan中作爲廣播包時如何跨越Vlan過來的呢？
馬上檢查覈心交換機，發現核心交換機上居然啓用了組播路由。。。。之前局域網中有應用是做局域網視頻錄播的，需要啓用組播路由，當時的技術人員居然不顧一切對所有的vlan都啓用了組播路由。
但是2兩年前基本上還是xp的時代，局域網內使用win7的用戶還是比較少的，因此只是有掉包現象，並不是很嚴重。但是隨着win7系統的普及（現在基本700臺win7）問題越來越嚴重。
難以想象700多臺win7每臺都在向其他機器發送組播包，並且還是跨vlan的傳播，導致局域網內UDP包數量不計其數。因此客戶計算機就會拋棄一部分UDP包，於是QQ就遭殃了。
SSDP是win7的局域網發現協議，同時是UPnP技術的重要支持，迅雷p2p下載等應用需要用到SSDP。對於網段裏的SSDP應該控制在一個vlan內，本身就不應該發現路由器背後的設備，因此在接入層設備上添加ACL直接過濾了UDP到239.255.255.250的所有數據包。在覈心路由器上應該也可以設置不轉發SSDP的，不過我覺得在接入層上直接幹掉SSDP比較好。
目前這個問題仍然在觀察中，不過基本可以確定是這個問題了，不過對於win7的這個局域網發現，還是抱有一定的擔心，如果一個vlan中有100臺win7開啓這個發現還是會產生大量的UDP數據包。希望大家留意這個情況。