2017年四月份校园网络运行波动及处理情况工作记录

1、 校园网运行进入四月份之后，曾出现多次不稳定情况，对正常使用造成了一定程度的困扰。当故障现象出现后，中心技术人员持续跟进，和相关设备厂商、出口带宽运营商协同配合，于 4 月 23 日晚解决了所有故障，校园网络已恢复平稳运行。现将整个故障排查解决过程中的关键节点简要记录如下。3 月 30 日星期四晚间，学校出口防火墙升级替换，由原来的ClavisterAS6000 防火墙，升级为 Clavister Stream防火墙。但本次防火墙升级由于技术原因未能成功，当天晚间重新恢复到原有防火墙设备。防火墙厂商随即将新防火墙返厂，重新做硬件和软件版本的配置。3 月 31 日星期五，当天明显地发现校园网速度

2、异常，访问大多数主流校外门户网站均速度很慢。当天中心技术人员初步推测与月末用户集中用网有关，决定观察一下再做处理。4 月 1 日星期六，学校与北京电信的带宽老合同到期，其将与学校的连接带宽降低 500M 至 1.5Gbps，当日校园网络即出现了一定程度的出口峰值压力。中心技术人员观察到部分访问速度慢的网站出口 trace 路由走的都是北京电信出口，推测可能与 3 月 30 日晚间更换防火墙导致链路虚接有关。22 点左右更换了北京电信出口光纤模块与光纤跳线，但故障现象依旧。4 月 2 最终于 14 点左右定位故障点为有线网核心思科交换机CPU 问题。有线网核心思科交换机间歇性的 CPU 瞬时峰值

3、，每当高峰脉冲出现时，校园网络即出现间歇性假死断网。下图，当瞬时 CPU 为 88%左右的时候，亚马逊 无法显示。定位故障点之后，中心立即与设备厂商联系解决问题。因在清明节假期中，相关厂商无法提供现场技术支持。4 月 5 现场开始采集核心设备的故障现象，并将数据返回美国总部后台工程师处理。4 月 6 日星期四，按照思科厂商工程师的建议，中心技术人员在核心交换机上配置安全策略，以抑制过高 CPU 负载的产生，但当天未见明显效果。4 月 7 日星期五，思科厂商工程师第二次来到学校现场，继续跟进解决问题。本次采集数据采用了更加底层的方法实现，最终于中午 12 点左右确认了核心设备过高 CPU 负载的

4、原因。故障原因为来自校内和校外某两个特定 IP 地址之间的间歇性 SYN Flood 攻击大量消耗了设备的 CPU 资源。当天下午 15 点 40 分左右，中心技术人员完成了对于此网络攻击的安全防护：在核心设备本身完成了过滤攻击包的规则配置，同时在出口防火墙上完成了 DDos 攻击的防护配置。配置完成后，有线网核心设备 CPU 恢复正常。4 月 8 日星期六，据当日的网管软件数据监控，有线网核心交换机的CPU运行平稳，校园网的网络情况得到了一定程度的缓解。当天，中心技术人员发现到某些网站的 trace路由出现中间某一跳路由器的RTT 时间很长，怀疑某条链路的质量有问题。经查，相关中间路由器为北

5、京移动出口对端的边缘路由器，中心第一时间与北京移动联系，要求对方协查相应出口的网络质量。4 月 11 日星期二，中心技术人员针对新浪网主页进行了样本点的抓包分析测试，测试结果显示本地主机与远端服务器的大量 TCP 连接资源消耗出现在 这个专门用于页面图片显示的域名。而该网站据trace 跟踪为北京移动的链路出口。本着“先易后难”的故障处理原则，当天晚间中心技术人员做了北京移动出口的光纤模块和光纤跳线的替换操作，但故障现象依旧，排除了我方机房链路故障的可能性。4 月 14 日星期五，北京移动公司给出对于移动对端 路由器RTT 超长时间的初步技术解释。4 月 18 日星期二，北京移动公司技术人员来

6、到学校现场测试网络质量。当天中心技术人员配置两台测试机，分别强制走北京移动和北京联通的出口做对标测试。当天的测试结果显示“移动线路在响应时间、内容加载层面与联通专响。当天，出口防火墙厂商将重新完成配置的 Clavister Stream防火墙运抵学校，当日晚间按照既定计划完成了出口防火墙的升级替换。4 月 19 日星期三，从新防火墙的在线并发连接数显示，相比老防火墙其处理能力大幅提升，达到了中心依托更强大的硬件设备提升防火墙的处理性能和降低晚间峰值 CPU 负载的升级初衷。当天，按照设备厂商工程师的建议，完成了出口防火墙和出口流控设备的 P2P下载和在线视频的用户流量在流控设备上即全部导向为防

7、火墙设备的北京移动校园网出口。这样的流量导向策略，减轻了防火墙设备的二次处理负载，一定程度上优化了上网用户体验。4 月 20 日星期四，按照设备厂商工程师的建议，中心技术人员在流控设备上完成了对校内用户单 IP 的 TCP 和 UDP 连接的数量优化调整。调整完成之后，据监控结果校园网的访问速度已经恢复到正常水平。但当日晚间 21 点 24 分，新上线的防火墙Clavister Stream设备出现未知，防火墙自动重启再次导致全网中断。从 DNS QPS 统计也可以看到，断网当时由于瞬时负载压力，导致校内 DNS 服务器的瞬时 QPS 冲击到峰值。随后，4 月 21 日星期五和4 月 23 日星期日，出口防火墙又出现两次未知bug 导致的自动重启，防火墙重启期间校园网全部中断。中心在协调防火墙厂商无果的情况下，果断决定重新恢复原有的 Clavister AS6000防火墙。4 月 23 日星期日晚间 22 点左右，老防火墙重