S6800-54QF 流量统计

qos apply policy xxx global outbound 统计到报文 ≠ 100% 证明报文已经发送到对端防火墙！
一、原理拆解（Comware7 S6800 2612P02）
全局 outbound QoS 策略匹配时机
全局 outbound 是三层转发完成之后、进入接口队列之前做报文匹配统计。
报文走到这一步，代表：路由查找成功、确定出接口（你的三层聚合子接口）。
但是！不代表报文成功送出物理端口。
存在这些后续丢包场景：
聚合组成员端口负载分担异常、链路协商异常；
出接口队列拥塞，队列尾部丢弃；
聚合接口 LACP 异常、成员端口故障；
报文二层封装失败（ARP 解析失败！重点！）；
硬件转发芯片内部异常丢弃。
最典型场景：路由可达，但是目标网关 ARP 无法解析；全局 outbound 统计计数上涨，报文最终无法发出设备。
为什么你无法把子接口应用 outbound 策略（官方约束）
S6800 Comware7：三层聚合子接口不支持 outbound 方向 qos apply policy、packet-filter outbound，硬件限制，你遇到的报错属于产品固有特性。
三层 BAGG 子接口仅支持 inbound 流策略，outbound 不支持。
二、现有方案缺陷
全局 outbound 只能证明：交换机完成三层路由转发，报文准备从目标子接口发出，无法确认「物理端口真正发出报文」。
你当前拓扑：虚拟机→S6800→FW，ping 不通。
全局流统计数上涨，只能锁定：故障点不在 S6800 三层路由阶段，丢包大概率发生：S6800 出队列 / 二层封装 / 聚合链路 / 防火墙侧，不能断定报文已经抵达防火墙。
三、推荐可行替代方案（按优先级排序，解决你无法子接口 outbound 统计痛点）
方案 1：端口镜像（最精准，首选，能直接确认报文是否发到防火墙）
对接防火墙的三层聚合【物理成员口】配置本地端口镜像
plaintext
# 创建镜像组
mirroring-group 1 local
# 聚合的成员口作为源（所有BAGG成员物理口）
mirroring-group 1 mirroring-port Ten-GigabitEthernet1/0/1 Ten-GigabitEthernet1/0/2 outbound
# 空闲物理口作为观察口，接电脑抓包
mirroring-group 1 monitor-port Ten-GigabitEthernet1/0/20
✅ 优势：直接抓物理端口发出的报文，抓到 = 报文成功送出交换机到防火墙，铁证。
缺点：需要一台电脑接观察口；远程机房没有空闲端口可以选择远程镜像。
方案 2：在聚合【物理成员接口】应用 QoS 策略 outbound 统计（强烈推荐，无需额外设备）
限制只是三层聚合子接口不能 outbound 应用策略，BAGG 物理成员口支持 outbound qos policy！
流量从子接口转发，最终会从 BAGG 对应的物理成员口发出。
流分类 ACL 和你现有保持一致（匹配虚拟机 ping 客户的流量）
在所有 BAGG 成员物理接口应用 policy outbound
plaintext
interface Ten-GigabitEthernet1/0/1
qos apply policy COUNT outbound
interface Ten-GigabitEthernet1/0/2
qos apply policy COUNT outbound
查看统计：
plaintext
display qos policy interface Ten-GigabitEthernet 1/0/1 outbound
display qos policy interface Ten-GigabitEthernet 1/0/2 outbound
统计计数上涨 = 报文已经送入物理端口发送队列，可信度远高于全局 outbound。
注意：聚合负载分担，流量可能分布在多个成员口，所有成员都要部署。
方案 3：接口队列统计（无额外配置，辅助验证）
先开启队列统计模式
plaintext
system-view
statistic mode queue
查看聚合物理口出方向队列报文计数
plaintext
display qos queue-statistics interface Ten-GigabitEthernet 1/0/1 outbound
可以观察报文调度到队列的数量，只能做辅助，无法区分业务流。
方案 4：入方向双向统计，区间比对（定位丢包区间）
虚拟机接入侧接口 inbound 部署流统计（进入交换机的 ICMP 请求包数量）
BAGG 成员物理口 outbound 部署流统计（离开交换机的 ICMP 请求包数量）
两边数据包数量对比：
入＞出：交换机内部丢包（队列、ARP 失败等）
入≈出：交换机正常发出，问题 100% 在防火墙（策略、路由、回包、ARP）
四、针对你当前 ping 不通场景快速排查补充
确认 S6800 上防火墙互联网段 ARP 正常：display arp 防火墙互联地址
❌ 如果 ARP 学习不到，全局 outbound 计数上涨，但是报文根本发不出去！这是最常见坑。
在防火墙侧抓包，终极验证：是否收到 ICMP 请求。
区分单向 / 双向问题：
ICMP 请求交换机成功发出，防火墙收到但是不回包：防火墙策略 / 回程路由问题
ICMP 请求防火墙收不到：链路 / 二层封装 / 聚合负载分担问题
五、最简总结
全局 outbound qos policy 统计命中 ≠ 报文发送到防火墙，仅代表路由转发完成；ARP 失败、队列拥塞依然会丢包。
最优落地手段：在 BAGG 聚合的物理成员口部署相同统计策略 outbound，规避子接口硬件限制；
终极证据：端口镜像抓物理出端口流量，或者防火墙侧抓包。