某某地会控操作延时等问题分析

1.1      现象描述

7月17日下午，一线反馈现场通过终端主叫呼集召开会议，出现会控操作延时问题，同时出现终端注册GK时断时续问题。

1.2      会控操作延时问题分析

现场做了如下测试操作：

1.     北京局点终端Ping MCU IP地址，显示丢包率最高达60%；

2.     与MCU位于同一网段的PC ping MCU，显示丢包率达40%左右；

3.     MCU ping 同一网段PC，无丢包，但是延时较大：

4.     MCU ping自己IP，ping结果正常：

通过现场的Ping操作确认，终端和MCU互通时，存在较大延时和丢包，导致会控操作存在明显延时。

同时，MCU ping自己正常，表明MCU内部业务层处理正常。

1.3      MCU异常延时和丢包原因排查

1.3.1        日志分析

通过查看现场工程师反馈MCU告警灯闪烁，但通过命令行查看无告警。通过获取MCU日志查看，告警日志记录7月17日上午10点钟（MCU系统时间）开始，MCU底层持续检测到网络存在网络风暴冲击：

1.3.2        抓包分析

     现场在MCU侧交换机上进行了端口镜像抓包，从抓包中可以看到，现网网络中存在大量如下ipv6报文：

经统计，不到2分钟的时间，抓包中统计该报文数量为1059015个，平均1S钟该报文数量在10000个左右：

     该报文为DHCPv6组播报文，从抓包中分析，为DHCPv6客户端发向DHCPv6服务器的请求报文。源IP地址为IPv6地址：FE80::5636:9bff:fe00:ec1d，目的IP为组播IP。上一跳MAC地址为：54:36:9b:00:4c:1d。

每秒发送上万个DHCPv6请求，从数量级上分析属于异常。

1.3.3        根因分析

视频会议设备作为专业的多媒体处理设备，使用的会控操作等非媒体报文非常少，主要资源用于音视频媒体报文处理，非媒体报文处理分配资源较少。MCU单板最大支持250M的媒体报文处理，其他非媒体报文上传到业务层进行处理，业务层处理资源有限。

现网存在大量的DHCPv6报文冲击，属于非媒体报文，报文数量持续保持在高数量级，占用大量MCU处理非媒体报文的资源，导致MCU对ping包、GK注册报文、会议控制信令报文等正常非媒体报文的处理能力不足，出现终端注册GK失败、Ping包丢失和会控操作延时等现象。

1.4      问题解决方案

问题原因为现网中存在大量的DHCPv6报文，造成MCU对的非媒体报文处理的影响，导致终端注册GK离线、会控操作响应延时、ping报文丢包现象。

1.4.1        问题解决方案

现网需找到该报文的源头，进行相应处理，停止该报文的异常发送。

关于查处源头设备的思路，建议如下，仅供参考：

1.     在网关设备和出口设备处抓包，确定该报文源头是内部设备还是外部设备。

2.     如果是内部设备，尝试通过源IP和上一跳MAC地址查找：

源IP地址为IPv6地址：FE80::5636:9bff:fe00:ec1d，目的IP为组播IP。上一跳MAC地址为：54:36:9b:00:4c:1d。

如果为病毒触发，有可能为伪装IP和MAC地址。如果通过IP和MAC地址无法确定，内部局域网内在关键节点抓包，分段确认数据包来源。

3.     如果源头是外网引入，则在网关等关键设备屏蔽该报文即可。

  另外，该异常报文从MCU日志记录显示，是从17日上午10点左右开始出现的，可以了解下当时网络中有无做过什么变动。

1.4.2        建议规避措施

尝试在MCU所接交换机上是否可屏蔽该报文（一般3层交换机可操作）：