- 产品与解决方案
- 行业解决方案
- 服务
- 支持
- 合作伙伴
- 关于我们
27-eMDI配置
本章节下载： 27-eMDI配置 (306.48 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，则认为该周期报文传输存在故障 |
一个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
开启eMDI模块的告警功能后，该模块会生成告警信息，用于报告该模块的重要事件。生成的告警信息将发送到设备的SNMP模块，通过设置SNMP中告警信息的发送参数，来决定告警信息输出的相关属性。
有关告警信息的详细介绍，请参见“网络管理和监控配置指导”中的“SNMP”。
(1) 进入系统视图。
system-view
(2) 开启eMDI模块的告警功能。
snmp-agent trap enable emdi
缺省情况下，eMDI的告警功能处于开启状态。
在完成上述配置后，在任意视图下执行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保留在没有任何通知或提示的情况下对资料内容进行修改的权利!
支持
