随着 IT 技术的蓬勃发展, 大数据, 云计算及 SDN 等新兴技术的使用已成为未来数据中心建设新趋势, 这些技术在为业务带来快速投产, 高冗余度及高灵活性的同时, 也在其部署的网络环境中引入了多种新型封装格式的数据包和大量的 BUM 类泛洪流量. 而无论上层的应用架构如何变化, 底层网络基础设施架构终究无法脱出经典网络的二, 三层转发模式, 在经典网络的二, 三层转发模式中, 网络环境中就有会存在广播, 组播和未知单播泛洪等 BUM 流量.
一些必要的 BUM 流量如 ARP 解析, 交换机 Mac 地址学习和防火墙, 冗余网关热备份协议的组播心跳是网络转发所必需的行为, 而超过规划可控范围外的异常 BUM 流量会对网络的整体转发性能造成严重影响, 今天我们就结合日常网络运维工作实践, 来聊一聊基础网络运维中的网络异常泛洪流量的发现, 分析及优化.
BUM 类流量 (指三类流量的简称, 包括 Broadcast 广播流量; Unknown Unicast 未知单播流量; Multicast 组播流量) 是一把双刃剑, 数据中心级别网络的正常运行及各系统冗余架构的部署搭建离不开 BUM 类流量的支持. 而由于数据中心接入环境的复杂性和服务器接入带宽的差异性, 过多的 BUM 类流量又可能会导致小带宽接入服务器的网络带宽资源被占满而引起传输性能下降. 因此我们需要详细了解和区分哪些 BUM 流量是必需的, 哪些 BUM 流量是异常的, 要能够区分正常与异常的 BUM 类流量, 才能够及时的控制和剔除异常 BUM 流量, 保障数据中心网络运行性能正常. 下面我们就来看一下, 哪些流量属于正常的 BUM 类流量.
1.Broadcast 广播流量
1 在数据中心网络中, ARP 是一类正常范畴的 Broadcast 广播类流量, 在网络中, 同一广播域内的服务器, 网关之间的通讯依靠 Mac 地址完成, 而 Mac 地址一般情况下是唯一的, 这样不利于服务器的灵活利用. 所以通常在赋予一个服务器功能角色的同时赋予其一个 IP 地址. ARP 信息在网络中主要负责进行 ARP 解析工作, 即完成服务器到网关, 服务器到服务器之间 IP 地址与 Mac 地址对应关系的解析, 这样在已知目标服务器 IP 地址的情况下, 就可以通过 ARP 获取目标服务器对应的 Mac 地址, 再进一步完成通讯. 因此, ARP 流量在网络中必不可少, 也是保证网络基础通讯的重要流量信息.
2 数据中心内部, 启用 DHCP 服务的网络环境中, DHCP 请求报文, 也属于一类正常范畴的 Broadcast 广播类流量. 启用 DHCP 的终端将通过 DHCP 请求报文来获取自己接入数据中心所需要的 IP 地址, 并后续通过此 IP 地址进行互联通讯;
2.UnknownUnicast 未知单播流量
二层网络环境中, 未知单播流量是时刻存在的, 这是一种单纯的受网络运行机制影响产生的泛洪类流量. 在网络交换机进行 Mac 地址学习的过程中, 一旦收到目标 Mac 地址未在交换机本地 CAM 表中缓存的数据包, 就会将此类数据包进行复制, 继而从本地交换机处于转发状态的接口转发出去(收到数据包的接口不转发), 以完成未知目标 Mac 地址首次通讯. 这里我们根据未知单播类报文的特点就可以总结出一条规律: 所有未知单播泛洪流量在产生时, 始发泛洪的交换机的 CAM 表一定没有被泛洪流量目标 Mac 地址的缓存.
3.Multicast 组播流量
在目前的数据中心环境中, 组播流量的应用场景不多, 且大部分应用在网络, 系统, 数据库等环境的冗余架构心跳, 多活架构信息同步及网络路由协议状态监控等场景中. 较为常见的应用有冗余网关热备份协议心跳信息, 防火墙心跳信息, F5 多活心跳信息及 OSPF 等路由协议的心跳信息等. 而这些心跳信息的目标组播地址均较为固定, 例如 HSRP 的目标组播地址为 224.0.0.2,OSPF 的心跳信息目标组播地址为 224.0.0.5 等;
上面了解到, 数据中心网络中应该存在的 BUM 类流量的类型和特点, 作为一名网络运维工程师, 下一步就需要针对网络环境中的 BUM 类流量采取实时的监控手段, 避免突发 BUM 流量对网络类其它设备运行造成影响, 需要建立实时监控系统, 以便及时发现和处理网络中的异常 BUM 类流量.
为实时监控网络同一广播域内的异常 BUM 类流量, 及时发现网络中运行的异常 BUM 类流量. 可针对 BUM 类流量的转发特点, 建立合理有效的监控手段, 能够有效的发现异常 BUM 流量, 并对异常 BUM 流量进行及时的处置, 避免大量的异常 BUM 流量对网络整体的传输效率造成影响.
1. 建立异常泛洪流量监测手段
为及时发现网络中可能存在的异常 BUM 流量, 网络团队建立部署针对总行同城双活数据中心的网络异常流量监控系统, 具备支撑整个网络安全区域 BUM 流量的运营监控能力. 其设计思路为, 利用 BUM 流量在全广播域内泛洪的特点, 在各个安全域中选取核心交换机 Trunk Edge 接口, 将该区域中所有 VLAN 内的 BUM 流量全部通过该接口引流至流量采集网(不具备条件的单位可以直接引入到探针), 由流量采集网内的探针服务器进行基线动态学习调整, 结合上线后一段时间内不同区域网络规模及业务流量分类和模型, 考虑一些特殊的跨数据中心防火墙 HA 心跳同步数据, 针对性的得到监控阀值, 一般普通 30 个左右网段的区域正常泛洪流量在 500Kbps 以内, 如果有区域内防火墙等 HA 心跳 vlan, 可能会在几兆以内.
2. 精细化网络运维及持续优化
通过网络异常流量监控系统, 我们可以在第一时间掌握网络异常情况, 实时的对网络中的异常 BUM 流量进行发现, 并根据异常流量产生的基本原理做出流量来源初步判断, 其判断依据和优化手段如下;
1 实时发现超出 BUM 流量基线的异常 BUM 类流量, 并可初步判断异常 BUM 类流量是否会对其当前所在安全域的业务产生实时影响;
2 通过流量采集网可获取异常 BUM 类报文的详细信息, 包括报文中的源目 Mac 地址, 源目 IP 地址, 并可以此为依据来进一步分析异常 BUM 报文的来源及产生原因;
3 异常广播及组播类流量: 根据捕获数据包内的详细信息追溯至异常广播流量发起源位置, 并最终确认异常广播流量产生原因;
4 异常未知单播类流量: 网络中存在异常未知单播类流量通常均由网络原因导致, 上面已经介绍过, 未知单播类流量产生的原因是因为本地交换机没有数据包目标 Mac 地址信息. 那么, 具体未缓存数据包目标 Mac 地址的原因就需要进一步分析确认.
结合多年网络运维实践, 出现未知单播泛洪的原因一般有以下 6 种:
交换机 Mac 地址老化时间早于交换机 ARP 老化时间;
交换机上的 Mac 地址被生成树 TC BPDU 等异常删除;
服务器配置静态 ARP 绑定问题, 导致数据包目的 Mac 交换机没法正常学习, 特别是当服务器网卡 Mac 地址发生变化时候更容易出现大流量泛洪;
区域内服务器不主动发送数据包, 一般为单向接收数据包, 例如监控 syslog 日志服务器等 UDP 单向数据设备;
服务器或者交换机异常封装不存在的 Mac 地址, 例如个别服务器在极端情况下会出现封装全 0mac 地址的情况造成泛洪;
不对称路由导致 Mac 地址学习异常, 产生异常的未知单播泛洪流量;
5 对于网络中存在的可优化的 BUM 类报文发现异常及时进行网络优化, 以降低正常 BUM 类流量对网络造成的性能影响; 针对数据中心系列交换机, 由于该系列交换机中 ARP 的老化时间为 25 分钟, 其 ARP 单播更新时间为 18 分钟, 而 Mac 地址老化时间为 5 分钟, 这样就可能因 Mac 地址的快速老化而产生大量未知单播泛洪. 为避免此情况, 我们调整交换机的 Mac 地址老化时间为 30 分钟(大于 ARP 老化时间 25 分钟), 这样就可以在 ARP 单播更新的同时, 同步完成 Mac 地址的更新, 极大的减少了未知单播泛洪流量, 提升了网络转发性能.
3. 完善告警机制
未来我们将逐步完善网络异常流量监控系统的告警机制, 通过灵活的告警方法和监控点设置, 达到更快捷, 更准确的告警通告. 将未知 BUM 报文监控接口的流量, 计数器等内容全部纳入统一监控, 结合动态基线, 实时分析进行异常预警, 发送给网络管理员, 提升故障处置效率.
随着业务的发展, 数据中心网络规模在持续扩大, 给网络运维管理带来挑战, 运维场景日趋复杂; 面对挑战, 网络运维人员应该夯实技术基础, 充分掌握网络技术经典理论, 及时总结日常工作中碰到的疑难杂症, 认真剖析, 明确网络优化和故障处置思路, 进一步做好网络运维工作. 以上是我们针对网络中异常 BUM 流量的初步分析和总结, 请大家批评指正.
来源: http://server.51cto.com/Datacenter-591275.htm