城域网未知组播分析和优化

1 引言
电信城域网目前综合承载宽带，IPTV，语音业务。随着网络规模的增大，网络内未知组播报文的数量随之增多，达到一定程度后，就会对网络带宽，设备负载产生压力，进而影响业务质量。研究未知组播的成因，实施对应的网络优化势在必行。
2未知组播及其危害
城域网设备，例如交换机在处理单播报文时，每转发一个数据帧，就会进行相应的源MAC地址学习，从而学习到一个单播转发表项。而组播转发表项则不同，它是通过一些三层或二层的组播协议获得的。城域网常用的二层组播协议有IGMP（Internet Group Management Protocol，因特网组管理协议）。
在组播转发流程中，设备使用CPU分析IGMP报文，形成组播转发表下发给ASIC （Application Specific Integrated Circuits，专用集成电路）芯片，芯片根据转发表转发组播报文。命中组播转发表的报文，称为已知组播，没有命中的报文，称为未知组播。
对于未知组播，设备根据自身设计，在物理端口层面将报文丢弃或者泛洪。同时报文被抄送至CPU，交给上层协议处理。当未知组播报文到达一定速率，就会超过CPU处理能力或触发CPU保护机制，导致部分正常业务的IGMP报文被丢弃。
IGMP报文被部分丢弃后，正常组播表项有几率得不到刷新被老化，对应流量成为未知组播。此时，若设备在物理端口层面的转发策略为丢弃，则IPTV业务表现为流量中断；若策略为泛洪，则报文会被转发至该网络广播域下除源端口以外其他所有端口，可能导致用户侧端口拥塞，甚至触发相邻网络设备的CPU丢包，影响范围进一步扩大。
3 城域网未知组播的来源
3.1  非法组播
当设备开启可控组播功能，配置了组播节目列表之后，所收到报文中的组播目的地址不在列表范围内，该组播即为非法组播。设备不会为非法组播建立组播转发表项，而是根据自身设计，丢弃，泛洪或者限速泛洪。
非法组播一般有两个来源：
（1）终端内置协议：
例如，开启了IPv6协议栈的电信家庭网关，会向IPv6组播目的地址FF02::16发送MLDv2（Multicast Listener Discover，组播侦听发现协议）报文。
TP-LINK，华为，NETGEAR，小米，REALTEK等厂家的路由器或智能终端，会向IPv4组播目的地址239.X.X.X，224.X.X.X等发送IGMPv2，IGMPv3报文。在城域网汇聚交换机（下挂约2.5万终端）CPU侧抓包，1分钟内可以收到此类终端发出的729个IPv4组播报文，包含322个IPv4组播组。
（2）恶意组播攻击：
终端没有组播业务需求，却向外发送过量组播报文的行为，称为恶意组播攻击。终端可以利用某些设备对未知组播的“泛洪”处理动作，在不具备合法接入IP的情况下，向网络发送大量恶意组播报文，恶意报文又被设备沿广播树泛洪至整个网络，进而造成网络中CPU性能瓶颈节点下的组播转发出现异常。恶意组播源不仅可以存在于IPTV业务VLAN（Virtual Local Area Network，虚拟局域网）中，也可存在于专线、宽带，语音等任意业务的任意VLAN内。
以W市某次攻击事件为例，恶意终端原有专线业务已拆机，网关IP等三层业务数据已删除，但接入光路和端口VLAN仍然保留。攻击者利用城域网的IGMP报文处理机制，直接构造大量虚假IGMP请求报文发送给上联，速率约0.35kpps。经过专线交换机泛洪后，造成汇聚交换机CPU处理IGMP报文时大量丢包，进而影响了该汇聚交换机下所有组播业务。攻击时，汇聚交换机CPU报文统计如图1所示，IGMP报文转发比例被降低到了9.8%。
 
图1 汇聚交换机IGMP报文丢包
3.2 组播转发表规格过小
交换机和路由器的组播转发表通常由组播组、源端口、目的端口、VLAN组成[1]。当组播转发表规格过小，设备实际承载的组播数量超过了组播转发表最大条目数量，超出的组播组流量就会成为未知组播。
在目前城域网汇聚层和接入层中的交换机通常工作在IGMP snooping模式，往往不配置组播节目列表或不具备可控组播能力，此时组播转发表规格过小成为未知组播的潜在来源因素。 
3.3 CPU报文处理丢包
CPU若存在丢包，IGMP报文得不到及时处理，会使得组播转发表项得不到正确刷新[2]。根据IGMP协议机制，若两个周期的IGMP通用组查询被丢弃，再过一个IGMP最大查询响应时间，设备上所有组播表项都将老化，原先合法的组播将成为未知组播。若两个周期的特定组响应报文被丢弃，再过一个最大查询响应时间，设备上特定组播组表项都将老化，流量成为未知组播。
CPU丢包和未知组播的形成之间互为因果：CPU丢包几率导致未知组播产生，另一方面未知组播会被抄送CPU处理，加剧CPU丢包。
城域网内设备和终端CPU丢包的原因主要有：
（1） 未知组播：
以之前提到的MLDv2协议报文为例：网络未优化前，在W市某局家庭网关 PON口抓包，终端从上联口收到了同一汇聚交换机下其他家庭网关的大量MLDv2报文，速率约1.5kpps。该速率触发了家庭网关的CPU保护机制，造成IPTV业务的IGMP报文随机性丢包，最终导致组播类视频断流。
（2） 针对设备CPU的恶意攻击：
有些协议需要设备CPU处理，例如ICMP，IGMP，TELNET，广播等。攻击者利用此机制，向设备发送过量协议报文，从而影响CPU正常工作。
W市某次网管服务器中毒，网管向接入网OLT（Optical Line Terminal，光线路终端）发送ICMP报文，报文速率0.5kpps。导致该OLT主控板CPU异常，峰值利用率达到73%，远高于相同负载的同类型OLT，峰值时间与该OLT下IPTV业务卡顿时间相近。在OLT上临时配置ACL（Access Control List，访问控制列表）禁止网管服务器访问，后期重装服务器操作系统后，IPTV业务恢复正常。
（3）网络环路：
通常为用户将网线接在了同一台ONU（Optical Network Unit，光网络单元）的两个口上导致。上联设备发送的广播包进入环路后形成广播风暴，耗尽二层设备CPU资源。
4 网络优化措施
提高设备硬件规格，网络优化是应对未知组播的两个主要措施。而网络优化可以在不增加硬件成本，不影响现有业务的前提下，促进网络的平稳发展，是运营商的较优选择。
网络优化中，保留并处理业务相关的协议报文，隔离或丢弃不相关协议报文，做好网络安全防护工作，是方案的基本原则。
W市城域网优化方案如下：
（1）配置合法组播前缀列表：
针对组播转发表规格大小问题，业务控制层设备可以配置合法组播前缀列表，接入层设备开启IGMP proxy功能[3]并使能合法组播前缀列表。配置后，设备只学习包含在前缀列表范围内的IGMP报文并形成组播转发表项。 
（2）汇聚层和接入层开启二层隔离：
传统的二层网络，VLAN和VLAN之间相互隔离，但同一个VLAN内的终端仍然属于同一个广播域，存在广播/组播风暴隐患。汇聚层和接入层配置二层隔离后，同一个VLAN内广播以及未知组播仅向二层设备上联口转发，下联设备和终端之间二层隔离，不再收到其他终端发出的的广播和组播报文。
例：针对跨OLT泛洪，汇聚交换机开启下联口隔离。注意上联端口不能配置隔离，避免路由器接收不到用户侧正常的广播和组播报文；针对跨PON口和VLAN内泛洪，OLT开启PON口隔离和vlan内隔离。
隔离效果如图2所示：

图2  二层隔离效果
（3）接入层开启未知组播丢弃：
未知组播处理方式为“泛洪”的二层接入设备，可以开启未知组播丢弃。配置后，设备将丢弃未知组播报文，不再上送CPU，也不向其他端口转发。
（4）统筹规划CPU报文分类限速和出口报文分类限速：
针对仅本地处理的报文：设备开启CPU保护功能，对ASIC芯片上送CPU的报文分类并限速，优先保证网络管理和重要业务报文的处理。
针对除本地处理外继续向网络泛洪的报文：首先，可信ONU或者交换机利用QOS为报文着色分类；其次，各层次设备依据QOS标记，部署出口报文分类限速；底层设备限速适当严格，把攻击流量隔离在靠近用户侧。
（5）周期巡检，积极应对：
采集统计CPU报文处理信息，形成维护基准，开展针对设备CPU的周期性检测和异常处理。设备主控板和业务板的CPU都需要巡检。
5结束语
网络优化是一项长期性，周期性的系统工作。随着城域网终端规模的增长和业务融合的发展，需要维护人员不断调整网络结构，优化网络流量，解决网络质量瓶颈，使得用户体验得到较大提升，为运营商业务战略和国家通信事业提供有力支撑。