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

2017 年四月份校园网络运行波动及处理情况工作记录 校园网运行进入四月份之后，曾出现多次不稳定情况，对正常使用造成了 一定程度的困扰。当故障现象出现后，中心技术人员持续跟进，和相关设备厂 商、出口带宽运营商协同配合，于4 月23 日晚解决了所有故障，校园网络已恢 复平稳运行。现将整个故障排查解决过程中的关键节点简要记录如下。 3 月30 日星期四晚间，学校出口防火墙升级替换，由原来的Clavister AS6000 防火墙，升级为Clavister Stream 防火墙。但本次防火墙升级由于技术原 因未能成功，当天晚间重新恢复到原有防火墙设备。防火墙厂商随即将新防火 墙返厂，重新做硬件和软件版本的配置。 3 月31 日星期五，当天明显地发现校园网速度异常，访问大多数主流校外 门户网站均速度很慢。当天中心技术人员初步推测与月末用户集中用网有关， 决定观察一下再做处理。 4 月1 日星期六，学校与北京电信的带宽老合同到期，其将与学校的连接带 宽降低500M 至1.5Gbps，当日校园网络即出现了一定程度的出口峰值压力。中 心技术人员观察到部分访问速度慢的网站出口trace 路由走的都是北京电信出 口，推测可能与3 月30 日晚间更换防火墙导致链路虚接有关。22 点左右更换 了北京电信出口光纤模块与光纤跳线，但故障现象依旧。 4 月2 日星期日 （清明节假期第一天），中心技术人员继续加班处理问题， 最终于14 点左右定位故障点为有线网核心思科交换机CPU 问题。有线网核心 思科交换机间歇性的CPU 瞬时峰值，每当高峰脉冲出现时，校园网络即出现间 歇性假死断网。下图，当瞬时CPU 为88%左右的时候，亚马逊 无法显示。 定位故障点之后，中心立即与设备厂商联系解决问题。因在清明节假期 中，相关厂商无法提供现场技术支持。 4 月5 日星期三 （清明节假期后的第一个工作日），思科厂商工程师到学校 现场开始采集核心设备的故障现象，并将数据返回美国总部后台工程师处理。 4 月6 日星期四，按照思科厂商工程师的建议，中心技术人员在核心交换机 上配置安全策略，以抑制过高CPU 负载的产生，但当天未见明显效果。 4 月7 日星期五，思科厂商工程师第二次来到学校现场，继续跟进解决问 题。本次采集数据采用了更加底层的方法实现，最终于中午12 点左右确认了核 心设备过高CPU 负载的原因。故障原因为来自校内和校外某两个特定IP 地址之 间的间歇性SYN Flood 攻击大量消耗了设备的CPU 资源。当天下午15 点40 分 左右，中心技术人员完成了对于此网络攻击的安全防护：在核心设备本身完成 了过滤攻击包的规则配置，同时在出口防火墙上完成了DDos 攻击的防护配 置。配置完成后，有线网核心设备CPU 恢复正常。 4 月8 日星期六，据当日的网管软件数据监控，有线网核心交换机的CPU 运行平稳，校园网的网络情况得到了一定程度的缓解。 当天，中心技术人员发现到某些网站的trace 路由出现中间某一跳路由器的 RTT 时间很长，怀疑某条链路的质量有问题。经查，相关中间路由器为北京移 动出口对端的边缘路由器，中心第一时间与北京移动联系，要求对方协查相应 出口的网络质量。 4 月11 日星期二，中心技术人员针对新浪网主页 进行了 样本点的抓包分析测试，测试结果显示本地主机与远端服务器的大量TCP 连接 资源消耗出现在 这个专门用于页面图片显示的域名。而该网站据 trace 跟踪为北京移动的链路出口。本着“先易后难”的故障处理原则，当天晚 间中心技术人员做了北京移动出口的光纤模块和光纤跳线的替换操作，但故障 现象依旧，排除了我方机房链路故障的可能性。 4 月14 日星期五，北京移动公司给出对于移动对端 路由器 RTT 超长时间的初步技术解释。 4 月18 日星期二，北京移动公司技术人员来到学校现场测试网络质量。当 天中心技术人员配置两台测试机，分别强制走北京移动和北京联通的出口做对 标测试。当天的测试结果显示“移动线路在响应时间、内容加载层面与联通专 线体验效果相当”，至此排除了北京移动出口链路质量对于校园网访问速度的影 响。 当天，出口防火墙厂商将重新完成配置的Clavister Stream 防火墙运抵学 校，当日晚间按照既定计划完成了出口防火墙的升级替换。 4 月19 日星期三，从新防火墙的在线并发连接数显示，相比老防火墙其处 理能力大幅提升，达到了中心依托更强大的硬件设备提升防火墙