TECS资源池上报网络流程异常告警的问题处理
某资源池TECS上报网络流程异常告警，告警单次持续15秒-4分钟之间。
涉及UDM/PCF网元OMU虚机和ISBG网元的OMP虚机，不间断出现“网络流量异常”告警。
问题分析如下：
1.告警发生在多个网元环境，涉及不通的主机以及主机集合，以及多个业务TOR，按照问题发生的规律性排除单台的硬件故障。
2.在线TECS版本和硬件组合已在多个站点使用，未发生相关情况，排除软件版本和硬件的兼容性问题。
3.结合具体现场情况，上层业务多为测试版本，需要重点定位在上层业务和TECS的配合。
4.按照问题发生的严重度，优先选择告警最频繁的网元虚拟机做抓包定位分析，同时结合历史数据做规律性排查。
本次网络流量异常告警涉及网络虚机多，但问题原因类似，以下涉及的TECS以排查一个网元虚机为例。
1.通过告警详情，TECS检查虚机对应端口性能统计，如下图所示。
2.从告警详情中得知虚机NFV-R-xxx-56OMP_L的vhu599f535d-1f端口在接收的21859个包中，丢了380个包，丢包率为1.7%。随即统计了该虚机端口指标，发现虚机端口流入有丢包，端口流出没有丢包。
3.TECS网络流量异常告警产生机制，如图5所示。
a.虚拟机的每一个虚口，对应DVS虚交换都有两个队列缓存，用于DVS和该虚口收发包的处理。一个收队列（VM--->DVS方向，默认队列长度1024），一个发队列（DVS--->VM方向，默认队列长度1024）。该告警是对应DVS的发队列，即DVS发送报文给虚拟机的方向（图中红线示例部分）。
b.DVS收到物理口进来的报文后，根据相应的转发规则，将对应的报文向不同的虚拟机的虚口转发，发送的报文会进入发送队列。
c.DVS根据队列的标志位状态决定是否产生中断信号，通知虚拟机接收发送队列的包（队列标志位状态由虚拟机内部收包进程维护：当虚拟机内正在处理收包时，置标志位状态标记DVS为不需要发送中断信号通知虚拟机处理收包；当虚拟机内没有处理收包时，置标志位标记DVS为需要立即发送中断信号通知虚拟机处理收包）。
d.当虚拟机没能及时取走队列的数据，DVS发向虚拟机虚口的报文填满队列时，则会出现队列消息积压，超过了队列的长度，后续多余的报文就会因为无法入队列而被丢弃，丢弃的报文数统计在overrun中。
e.DVS每隔5秒检测一次overrun的统计和本周期内收包总数的比值，如果连续3次检测，overrun的报文占比达到告警门限（丢包超过千分之一），就会上报告警。
f.计算节点上可以使用统计命令dvs show-dpifstats，采集所有虚拟机虚口和物理网口的收发包历史统计信息，命令需要通过多次采集后，根据采集的结果，观察虚口是否存在tx_overrun的统计增加。如果存在虚口在采集的周期内增加现象，说明虚拟机处理DVS发送队列的报文不及时（或者处理能力不足），无法及时消费队列的报文导致报文overrun。 g.DVS处理能力如下，本次问题的核心不是DVS的处理能力，而是在于业务虚拟机的处理能力。
25G网卡带宽分配比例为0.24（DVS最大处理能力为12Gbps）。
10G网卡带宽分配比例为0.35（DVS最大处理能力为 7Gbps）。
4.由于网络流量异常告警不止一个种类的虚机，统计了4个月非凌晨操作时间的“网络流量异常”的历史告警，结果如下图所示。
5.采集观察每一类虚机指标发现，丢包均为DVS 发送报文给虚拟机的方向。且同类型虚机都是入向到端口有丢包，可以判定是上层网元虚机原因，需要上层业务虚机侧协助排查。
6.UDM/PCF网元OMU虚机：
a.现场停止OMU虚机的端到端信令跟踪任务后，告警不再出现。
b.现网OMU创建大量端到端信令跟踪任务，未及时进行清理，会出现该现象，原因为：现场OMU 有N个SC。
c.当前信令跟踪任务同步机制为：每条信令跟踪任务数据约4K记录，需要全表同步，即每次信令跟踪任务激活，都会把所有信令跟踪任务数据全量同步至前台。
d.此外，MP向SC同步数据时，要乘以SC个数，即每次要同步N*4K*300的数据。大包需要进行分包，造成一次往前台同步的数据量很大，造成虚机流量过大，出现告警。
e.TIPI是立刻重传，只要接收方发现接收的消息不连续，会给发送消息方请求重传，请求方接收到重传请求，会立刻重传。
7.ISBG网元的OMP虚机：
针对资源池DVS进行抓包分析，发现存在瞬间大量包集中收发情况，5秒内瞬时冲高收发27000个包，之后立即恢复正常，如下图所示。
a.收发包峰值时刻深入分析确定，峰值收发包均由网元性能统计采集数据产生。
b.以日志采集为例，该时刻约产生27000个包，其中“SCSCF 用户数按模块统计”性能统计任务瞬间产生12596个包；“内存库占用按模块统计”性能统计任务瞬间产生13617个包。
c.两个性能统计任务瞬间合计产生26213个包（12596+13617=26213），说明资源池产生流量峰值与“SCSCF 用户数按模块统计”、“内存库占用按模块统计”两个性能统计任务有关联。
8.S-CSCF用户数按模块统计，如下图所示。
9.内存库占用按模块统计，如下图所示。
10.查看“SCSCF 用户数按模块统计”、“内存库占用按模块统计”性能统计任务发现：
a.两性能统计任务勾选全量模块对象，实际应用中只需勾选真实激活的SMP模块即可（CDB、OMP以及未激活SMP模块无需勾选），按真实应用只需勾选47个SMP测量对象。
b.其余勾选的测量对象（CDB、OMP以及未激活SMP模块）为无效对象，导致处理性能统计上报的网卡上流量突增，流量突增时会影响底层资源池产生瞬时流量告警。
c.性能统计与外部信令交互区分通道执行，此性能统计流量瞬时突增不会波及VoLTE业务流程，对业务无影响。
d.此性能统计流量突增产生少量丢包情况。由于性能统计数据上报有重传机制保障，不会影响性能统计数据整粒度采集，所以对性能统计数据呈现无影响。此外，由于流量冲高是瞬时行为，因此对网元自身CPU影响不大。
11.“SCSCF 用户数按模块统计”、“内存库占用按模块统计”两个统计任务勾选了大量的无效性能统计测量对象，导致性能统计数据采集异常，单个网卡流量短暂冲高，偶发性造成短时间少量丢包，导致底层资源池产生端口流量异常告警，但不会影响网元业务及性能统计。
1.通过如下方式暂时规避该问题：
a.UDM / PCF：现场测试阶段，尽量控制信令跟踪任务在30个以下，完成测试后删除测试号码的跟踪任务。
b.ISBG：“SCSCF 用户数按模块统计”、“内存库占用按模块统计”两个统计任务去除测量对象勾选。
2.网络流量异常告警是监控上层网元运行正常的重要告警之一，例如当上层网元虚机有下电或者重启都会产生网络流量异常告警，可通过告警信息判断涉及网元、对应虚机及端口。
3.本次网络流量异常告警主要是因为上层网元有抓包或信令跟踪导致，告警本身无业务影响。
审核编辑：刘清
-
PCF
+关注
关注
0文章
32浏览量
20893 -
DVS
+关注
关注
0文章
18浏览量
9620 -
虚拟机
+关注
关注
1文章
914浏览量
28158 -
ToR
+关注
关注
0文章
8浏览量
10407 -
NFV
+关注
关注
3文章
118浏览量
33710
原文标题：TECS资源池上报网络流程异常告警的问题处理
文章出处：【微信号：ztedoc，微信公众号：中兴文档】欢迎添加关注！文章转载请注明出处。
发布评论请先 登录
相关推荐
TAS5630B使用的PHD封装，OTW1输出低电平，100°C过温告警是为什么？
异常重启怎么破？多方排查后，原因竟然是。。。
自动化生产车间异常告警运维管理系统解决方案
EM储能网关 ZWS智慧储能云应用(4) — 告警介绍（下）
EM储能网关 ZWS智慧储能云应用(4) — 告警介绍（上）
一站式统一返回值封装、异常处理、异常错误码解决方案—最强的Sping Boot接口优雅响应处理器
如何处理STM32的HAL库函数返回异常问题？
熔纤机放电异常怎么处理
AWTK 开源串口屏开发(10) - 告警信息的高级用法
Service层的异常处理
SNMP配置及网络管理系统无法接收告警（Trap）的解决方法
AWTK 串口屏开发(3) - 告警信息
工商网监
评论