很久没有写博客了，自从四月份以来找了一份开发的工作开始从事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协议的数据包单独映射了一个公网地址。可惜问题还是没有解决。

无奈没有办法，让现场掉线的时候抓包发过来看看有没有收获。于是就发现了下面的情况：

p_w_picpath

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数据包。希望大家留意这个情况。