S125CR设备MOD标准配置

一、MOD 基础概念
MOD = Mirror On Drop，内部转发丢包镜像，属于 Telemetry 子功能；当报文在芯片转发过程丢弃时，设备复制丢弃报文头部 + 丢包原因，主动上送到采集器，用于定位 Spine/Leaf 内部转发丢包。
S125CR（Comware V7 R51xx）完整支持该特性，依赖 Telemetry 框架。
二、两种上送传输方式
UDP（默认，主流落地方案）
四层自定义 UDP 报文，可跨三层路由；
适合传统采集平台，抓包即可解析；
缺点：无重传，极端场景报文丢失。
gRPC（TCP 长连接）
基于 Telemetry 标准 gRPC 协议；
面向标准化云原生采集平台；
要求采集服务部署 gRPC 监听端。
行业现网 DCN 场景绝大多数使用 UDP 方式。
三、S125CR 标准完整配置模板（UDP 推荐方案）
plaintext
system-view
# 1、创建采样器（MOD必须绑定采样，防止报文风暴）
sampler MOD_SAMPLER mode random packet-interval n-power 16

# 2、进入MOD视图
telemetry mod
device-id 10.255.0.1 //设备标识，填写交换机三层可达IP
sampler MOD_SAMPLER //引用采样器
transport-protocol udp //选择UDP上送
# transport-protocol grpc //如需gRPC启用这条，注释UDP
# 配置采集器目的地址、端口
collector source-ip 10.255.0.1 destination-ip 10.255.0.100 source-port 60000 destination-port 6345
reason-list all //监控全部丢包原因；也可以自定义筛选少量丢包类型
quit

# 3、配套依赖：Telemetry流表老化（可选优化）
telemetry flow-group aging-time 10
telemetry apply flow-group 1
关键配置说明
reason-list 可以精细化筛选，示例：
plaintext
telemetry mod
reason-list ipv4-dip-miss unknown-vlan queue-length-exceed
采样参数n-power 16 = 2^16 随机采样，根据业务压力调整；不要设置过小避免 CPU 冲击。
四、数据报文格式说明
1）UDP 模式（现网最常用）
外层：标准 IP + UDP 封装（自定义端口）
内部报文结构：
MOD 头部：设备 Device-ID、时间戳、丢包原因码、入接口索引、出接口索引
原始丢弃报文 二层 + 三层头部（截断，不含完整载荷）
报文为私有二进制格式！无公开标准 JSON 文本格式，需要采集平台适配 H3C MOD 私有解析插件；单纯 wireshark 只能看到二层头，无法直接识别丢包含义。
2）gRPC 模式
采用 Telemetry 标准 GPB (Protobuf) 序列化格式，字段标准化：
包含：timestamp、source device id、drop reason、ingress/egress ifindex、原始报文头、VLAN、五元组信息。
五、常用查看验证命令
plaintext
display telemetry mod //查看MOD全局运行状态
display sampler //采样器状态
display telemetry mod statistics //统计：发送报文数量、丢弃数量
六、重要约束与踩坑提醒
MOD 依赖业务单板 K 系列芯片，老款 S 型业务板不支持；S125CR 务必确认接口板型号。
MOD 只检测芯片内部转发丢包；接口物理层 CRC、对端设备丢包不会产生 MOD 报文。
采样不能关闭！如果不配置 sampler，突发大量丢包场景会造成主控 CPU 飙升。
采集服务器和交换机三层互通，防火墙放行目的 UDP 端口。

H3C S125CR 系列交换机的 MOD（Mirror On Drop，丢包镜像） 功能，是 Telemetry 技术的一部分。它可以监控设备内部转发过程中发生的丢包，并将丢包原因和报文特征上报给采集器。

以下是关于其标准配置、上送方式及数据格式的详细说明。

📝 标准配置模板（UDP方式）

以下是官方推荐的一套完整、标准化的 MOD 配置模板，主要用于通过 UDP 协议上送数据。

关键配置项说明：

• 采样器 (sampler)：必须配置，否则大量丢包时可能耗尽CPU资源。n-power 16 表示采样率为 1/2^16，可根据业务压力调整，但不建议设置过小。

• 设备ID (device-id)：用于在采集器侧唯一标识设备，通常配置为设备的管理IP地址。

• 采集器地址 (collector)：指定MOD报文要发送到的目的采集器的IP和端口。

• 丢包原因 (reason-list)：all 表示监控所有丢包类型。也可以精细化筛选，例如只监控特定原因：

  bash

  telemetry mod reason-list ipv4-dip-miss unknown-vlan queue-length-exceed

📤 上送方式

MOD支持两种上送协议：

• UDP（默认，推荐）：

  • 使用自定义的UDP报文进行上送。

  • 优势是配置简单，可跨三层路由，适合传统采集平台。

  • 缺点是无重传机制，极端网络情况下可能丢包。

• gRPC：

  • 基于Telemetry标准的gRPC协议，使用TCP长连接。

  • 优势是数据格式标准化（Protobuf），适合云原生采集平台。

  • 需要在采集器侧部署gRPC服务端。

📊 数据报文格式

根据上送方式的不同，数据格式也不同。

1. UDP模式（现网最常用）：

   • 外层封装：标准的IP + UDP报文头。

   • 内部报文结构：为私有二进制格式，无公开的JSON标准。其结构大致包含：

     • MOD头部：设备ID、时间戳、丢包原因码、入接口索引、出接口索引等。

     • 原始丢弃报文：截断的原始报文二、三层头部。

   • 解析要求：由于是私有格式，需要采集平台适配H3C专用的MOD解析插件才能读懂。仅用Wireshark无法识别具体丢包含义。

2. gRPC模式：

   • 采用Telemetry标准的 GPB (Protobuf) 序列化格式。

   • 字段是标准化的，包含时间戳、设备ID、丢包原因、入/出接口索引、原始报文头、VLAN、五元组信息等。

🛠️ 常用验证命令

配置完成后，可以使用以下命令进行验证和排错：

⚠️ 重要注意事项

在部署MOD功能前，请务必了解以下限制：

• 硬件依赖：MOD功能依赖业务单板的K系列芯片。在S125CR上使用前，请务必确认接口板的型号是否支持。

• 丢包范围：MOD仅监控设备芯片内部的转发丢包。接口物理层CRC错误、对端设备丢包等不会触发MOD报文。

• 功能互斥：MOD与NetStream及IPv6 NetStream功能互斥，不能同时开启。

• ACL依赖：MOD仅对命中Flow Group所引用ACL的流量生效。

• 网络连通性：确保交换机与采集服务器三层路由可达，且防火墙已放通相应的UDP端口