25-eMDI配置
本章节下载: 25-eMDI配置 (302.82 KB)
目 录
在IPTV等基于组播的视频业务中,丢包、乱序、抖动是影响视频质量的三个重要因素。丢包、乱序和抖动均有可能导致视频花屏和马赛克。如何在故障发生时快速准确地定界呢?eMDI应运而生。
eMDI(Enhanced Media Delivery Index,增强型媒体传输质量指标)是一种专门为视频、音频业务设计的网络质量监控和故障定界方案,它能直接对IP网络中各个网络节点上指定的由TCP或RTP承载的业务报文进行实时监控与分析。网络管理员可以结合多个网络节点的监控与分析结果,对故障位置进行快速定界。
eMDI功能是基于实例实现的。每个eMDI实例由目标数据流、监控周期、监控时间和告警阈值等组成。
在数据流经过的各个节点上配置eMDI,实例启动后会对目标数据流进行实时监控,采集目标数据流报文头中的相关字段,并以周期为基本单位进行分析计算,然后向网管上报分析数据。
如图1-1所示,eMDI的原理机制如下:
(1) 网络管理员收到业务质量变差消息后,获取该业务流的源IP地址、目的IP地址等报文特征信息。
(2) 网络管理员通过网管或CLI在设备上部署eMDI。
(3) 设备周期性地将监控结果上送给网管。
(4) 网管汇总各设备上送的数据进行分析和统计,并将结果进行图形化展示。
(5) 网络管理员根据图形化展示结果对故障位置进行快速定界。
图1-1 eMDI组网图
对于目标TCP数据流,eMDI将自动监控表1-1中的这些指标。
对于目标UDP数据流,eMDI将自动监控表1-2中的这些指标。
eMDI将周期性地将这些指标的值发送给网管。
表1-1 目标TCP数据流监控指标
监控指标 |
指标含义 |
算法 |
说明 |
Rate |
接收报文速率,单位为bps和pps |
· Rate(bps)=周期内收到的所有报文的长度之和÷周期长度 · Rate(pps)=周期内收到的所有报文个数÷周期长度 |
单向流支持监控该指标 |
UPLR |
监控点上游丢包率 |
UPLR=(上游丢包数÷(接收到的总包数+上游丢包数)) |
在无丢包的情况下,当前接收的报文的序列号+报文长度=下一个报文的预期序列号 如果“当前接收的报文的序列号>下一个报文的预期序列号”,则判断为上游发生丢包。丢包个数根据平均报文大小计算 单向流支持监控该指标 |
DPLR |
监控点下游丢包率 |
· 下游丢包数=总丢包数-上游丢包数 · DPLR=(下游丢包数÷接收到的总包数) |
在无丢包的情况下,当前发送的报文的序列号+报文长度=下一个报文的预期序列号 如果“报文序列号<预期的序列号”,则判断其为重传报文,重传报文数=总丢包数 单向流支持监控该指标 |
DRTT |
监控点下游平均双向时延,单位为微秒 |
DRTT=T2–T1 |
记录接收到的非重传报文的当前时间戳为T1 根据序列号和报文长度计算出下一个报文的预期序列号 当收到下游回复的ACK报文的确认号大于或等于预期的序列号时,记录当前时间戳为T2 记录周期内满足上述条件的所有T1、T2值,计算平均值 双向流支持监控该指标 |
URTT |
监控点上游平均双向时延,单位为微秒 |
URTT=T2–T1 |
T1表示发现Client端建立连接请求的SYN报文时的时间戳 T2表示发现Server返回的SYN ACK报文的时间戳 由于本监控指标监控的是TCP控制报文,所以在一个监控周期内该值不一定能计算出来 双向流支持监控该指标 |
表1-2 目标UDP数据流监控指标
监控指标 |
指标含义 |
算法 |
说明 |
RTP-LR |
RTP报文的丢包率 |
RTP-LR=(丢包数÷(收包数+丢包数-乱序数)) |
如果“当前RTP报文的序列号-已接收所有报文中的最大序列号>1”,则为丢包 如果“当前RTP报文的序列号<已接收所有报文中的最大序列号”,则为乱序 单向流支持监控该指标 |
RTP-SER |
RTP报文的乱序率 |
RTP-SER=(乱序数÷(收包数+丢包数-乱序数)) |
单向流支持监控该指标 |
Jitter |
RTP报文的抖动,单位为微秒 |
Jitter=T2–T1 |
T1表示发送端发送第一个报文和最后一个报文的时间差 T2表示接收端接收第一个报文和最后一个报文的时间差。 单向流支持监控该指标 |
RTP-LP |
RTP报文的最大连续丢包数 |
监控周期内RTP报文连续丢失的最大个数 |
网络管理员或者网管应用通过监测RTP-LP的值可以: · 判断网络状态,以便及时响应网络故障,确保关键业务的畅通。例如:当RTP-LP的值增速较快,则说明网络中可能存在突发流量,可以排查突发流量是否为网络攻击,以及对突发流量进行限速;当RTP-LP的值大于经验值或者常规值,则说明网络存在拥塞或者其它故障,网络管理员可以调整丢包重传策略、增大网络带宽或者启用备份链路等,从而缓解网络带宽压力,有效减少丢包 · 快速定位网络故障,业务报文从源端到目的端要经过很多网络设备,分段检测RTP-LP值,可以快速定位丢包发生的区域,从而缩小故障检测范围,提高故障排除的效率 单向流支持监控该指标 |
RTP-ELF |
FEC有效丢包因子 |
RTP-ELF=(周期内丢包窗口总数÷周期内滑动窗口总数) |
RTP-ELF是一个监控周期内丢包窗口占滑动窗口总数的比例。RTP-ELF的计算依赖于窗口大小与预设的丢包阈值 设备周期内采样的业务报文数达到滑动窗口大小时生成首个窗口,滑动窗口数计1。后续每收到一个报文,向后滑动一个报文并生成新的窗口,滑动窗口数加1。每个窗口都会检验报文丢失数量是否超出了预设的阈值。若超出了阈值,则认为该窗口为丢包窗口,丢包窗口的计数加1。这一过程持续进行,直至监控周期结束,窗口停止滑动。此时设备得到监控周期内,滑动窗口的总数和丢包窗口的总数,计算出RTP-ELF的值 如果一个监控周期内的丢包窗口总数大于0,则认为该周期报文传输存在故障 |
仅SF系列接口板支持eMDI功能。
一个eMDI实例只能监控一条目标数据流,不同eMDI实例不能监控相同的目标数据流或者存在冲突的数据流。存在包含关系(clock-rate除外)的流即视为存在冲突。例如:
· 如下两条流,系统将视为存在冲突(存在包含关系,第一条流包含第二条流):
¡ flow ipv4 tcp source 1.1.1.1 destination 2.2.2.2
¡ flow ipv4 tcp source 1.1.1.1 destination 2.2.2.2 destination-port 20
· 如下两条流,系统不会视为冲突(不存在包含关系):
¡ flow ipv4 tcp source 1.1.1.1 destination 2.2.2.2 destination-port 10
¡ flow ipv4 tcp source 1.1.1.1 destination 2.2.2.2 destination-port 20
实例启动后,实例中的所有参数均不支持修改,如需修改请先使用stop命令停止实例;如果设备发生主备倒换或eMDI进程重启,实例会自动停止,如需启动请重新执行start命令。
在如下两种情况中,由于eMDI功能监控到的数据不是完整的,所以监控结果将会存在偏差:
· 被监控的数据流中,有部分流量在网络中传输时未经过本设备;
· 被监控的数据流中,虽然所有流量都经由本设备转发,但并不是经由本设备中的同一个单板转发。
获取目标数据流的特征,才能根据特征为实例配置目标数据流。
(1) 进入系统视图。
system-view
(2) 开启eMDI功能并进入eMDI视图。
emdi
缺省情况下,eMDI功能处于关闭状态。
(3) 创建eMDI实例并进入实例视图。
instance instance-name
(4) (可选)配置eMDI实例的描述信息。
description text
缺省情况下,未配置eMDI实例的描述信息。
(5) 配置目标数据流。请选择其中一项进行配置。
¡ 配置目标TCP数据流
flow ipv4 tcp source source-ip-address destination destination-ip-address [ destination-port destination-port-number | source-port source-port-number | vlan vlan-id | vni vxlan-id ] *
¡ 配置目标UDP数据流
flow ipv4 udp source source-ip-address destination destination-ip-address [ destination-port destination-port-number | source-port source-port-number | vlan vlan-id | vni vxlan-id | pt pt-value | clock-rate clock-rate-value ] *
缺省情况下,未配置eMDI实例的目标数据流。
在进行模糊匹配(即未指定命令中除clock-rate之外的某些可选参数)时,实例仅会以设备收到的首包所属的流为基础进行指标计算。以目的端口号为例,假设配置的目标TCP数据流为flow ipv4 tcp source 10.0.0.1 destination 10.0.1.1,此时设备收到了属于该规则的首包的目的端口号为100,则后续该实例将仅基于源IP地址为10.0.0.1、目的IP地址为10.0.1.1、目的端口号为100这条流进行指标计算,而源IP地址为10.0.0.1、目的IP地址为10.0.1.1、目的端口号为非100的报文,将不会纳入计算范围。
上述模糊匹配的实现机制可能会导致最终的监控结果存在偏差,所以为了保证监控结果的精确性,建议将目标数据流的粒度配置得越精细越好。
(6) (可选)配置eMDI实例的告警阈值。
alarm { dplr | rtp-lr | rtp-ser | uplr } threshold threshold-value
缺省情况下,eMDI实例的告警阈值为100。
对于TCP数据流,仅支持配置dplr和uplr;对于UDP数据流,仅支持配置rtp-lr和rtp-ser。
(7) (可选)配置eMDI实例的告警抑制次数。
alarm suppression times times-value
缺省情况下,eMDI实例的告警抑制次数为3。
(8) (可选)配置目标UDP数据流的视频质量监控的滑动窗口和阈值。
fec { window window-size | threshold threshold-value } *
缺省情况下,UDP数据流的视频质量监控的滑动窗口为100,阈值为5。
(9) (可选)配置eMDI实例的监控时间。
lifetime { seconds seconds | minutes minutes | hours hours | days days }
缺省情况下,eMDI实例的监控时间为1小时。
(10) (可选)配置eMDI实例的监控周期。
monitor-period period-value
缺省情况下,eMDI实例的监控周期为60秒。
(1) 进入系统视图。
system-view
(2) 进入eMDI视图。
emdi
(3) 进入eMDI实例视图。
instance instance-name
(4) 启动eMDI实例。
start
请选择其中一项进行配置。
· 停止eMDI实例。
a. 进入系统视图。
system-view
b. 进入eMDI视图。
emdi
c. 进入eMDI实例视图。
instance instance-name
d. 停止eMDI实例。
stop
· 停止所有eMDI实例。
a. 进入系统视图。
system-view
b. 进入eMDI视图。
emdi
c. 停止所有eMDI实例。
stop all
在完成上述配置后,在任意视图下执行display命令可以显示eMDI配置后的运行情况,通过查看显示信息验证配置的效果。
在用户视图下执行reset命令可以清除eMDI的统计信息。
表1-3 eMDI显示和维护
配置 |
命令 |
显示eMDI实例的信息 |
display emdi instance [ name instance-name | id instance-id ] [ verbose ] |
显示设备的eMDI实例资源信息 |
display emdi resource |
显示eMDI实例的监控统计信息 |
display emdi statistics { instance-name instance-name | instance-id instance-id } [ number number ] [ abnormal | verbose ] |
清除eMDI实例的统计信息 |
reset emdi statistics [ instance-name instance-name | instance-id instance-id-value ] |
如图1-2所示,Camera通过Device A、Device B和Device C将RTP视频数据流回传给Server。现发现Server端收到的画面有花屏,需在Device A、Device B和Device C配置eMDI功能,进行故障定界,以快速发现故障链路或设备。
图1-2 eMDI典型配置组网图
配置各设备的IP地址,并确保它们之间路由可达。
(1) 配置Device A
# 开启eMDI功能。
<DeviceA> system-view
[DeviceA] emdi
# 创建eMDI实例test。
[DeviceA-emdi] instance test
# 配置目标UDP数据流:源IP为192.168.1.2,目的IP为10.1.1.2。
[DeviceA-emdi-instance-test] flow ipv4 udp source 192.168.1.2 destination 10.1.1.2
# 配置eMDI实例的监控周期为10秒。
[DeviceA-emdi-instance-test] monitor-period 10
# 配置eMDI实例的监控时间为30分钟。
[DeviceA-emdi-instance-test] lifetime minutes 30
# 启动eMDI实例。
[DeviceA-emdi-instance-test] start
(2) 配置Device B和Device C
与Device A的配置相同,配置步骤略。
# 实例运行一段时间后,查看Device A、Device B和Device C上实例test的简要监控统计信息,结合三个设备上的数据,判断故障位置。下面以Device A的统计信息为例。
<DeviceA> display emdi statistics instance-name test
Instance name : test
Instance ID : 1
Monitoring period: 10 sec
Protocol : UDP
Unit for RTP-LR, RTP-SER and RTP-ELF is 1/100000
Timestamp Status RTP-LR RTP-SER Jitter(us) RTP-LP RTP-ELF
2019/09/17 16:17:20 Normal 0 0 2560 0 0
2019/09/17 16:17:10 Abnormal 50000 0 2459 1 100000
2019/09/17 16:17:00 Abnormal 12634 33333 5236 3 23356
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!