校园网络测试方案

上个月教学楼三楼机房断网两次，校园每次都是网络上课二十分钟后开始丢包。值班同学查了交换机日志，测试发现是校园某个IP在疯狂发ARP请求。这事说明一个问题：校园网平时看着能用，网络真出故障时，测试没有一套测试方案，校园排查全靠运气。网络

我参与过三次校园网压力测试，测试最深的校园体会是——别一上来就测带宽。先搞清楚拓扑。网络核心交换机型号、测试AP分布、校园VLAN划分、网络出口路由策略，测试这些信息不整理出来，后面测什么都是瞎测。我们学校用的是锐捷的设备和华为的出口路由器，AP密度在图书馆三楼明显不够，一个AP带四十多个终端，不崩才怪。

分层测试，别混在一起做

接入层先测。拿一台笔记本接网线，关掉WiFi，ping网关。延迟超过5ms就不正常。然后换无线，站在AP正下方测一次，走到隔两堵墙的角落再测一次。信号强度掉到-75dBm以下，基本可以判定覆盖有问题。我习惯用iperf3打TCP流，持续六十秒，看吞吐曲线有没有断崖。有次在实验楼四楼，无线速率从300Mbps直接掉到12Mbps，原因是隔壁实验室的微波炉在干扰2.4G频段。

汇聚层和核心层要测的是转发能力和ACL效率。用多台机器同时打流，观察交换机CPU占用。我们那台老华为S5700，在跑满千兆线速时CPU冲到70%，说明它已经到瓶颈了。出口路由器那边重点看NAT会话数，学生一多，并发连接数轻松破万，会话表满了新连接就建不起来。这个数据在设备后台能直接看到，不用猜。

真实场景比理想环境有用

别在空教室测。要测就挑晚自习高峰，或者选课系统开放的那十分钟。我们做过一次对比：凌晨两点测速，下载能跑满签约带宽；晚上八点再测，直接腰斩。原因不复杂，出口带宽被占满了。这时候要做的是QoS策略验证——给教学区流量打高优先级，看视频的流量限速。测试方法也简单，一边开腾讯会议，一边用迅雷下载，看会议会不会卡。会卡，说明QoS没生效或者配错了。

DHCP和DNS也得单独测。有次学生反映“连上WiFi但打不开网页”，查了半天是DHCP地址池耗尽。测试时用脚本批量申请IP，看多久分配完、有没有失败。DNS解析延迟超过50ms就会影响体验，尤其是现在很多网页依赖多个域名。用dig命令测校内DNS和公共DNS的响应时间差异，数据摆在那里，该换就换。

工具和记录

工具不用多，Wireshark抓包、iperf3打流、ping和traceroute做基础连通性，再加一个WiFi分析仪看信道干扰。关键是要记录。每次测试的时间、地点、设备、结果，写成表格。我见过太多人测完就忘，下次故障重新来一遍。把每次的基线数据存好，出问题时一对比就知道哪里变了。

测试方案不是写给别人看的文档。它是你排查故障时的路线图。校园网环境杂、终端多、预算有限，不可能做到完美。但至少要做到——出问题时，你知道从哪一层开始查，用什么工具，看什么指标。这套东西跑通了，比任何理论都管用。