交换机分片报文问题

S6850收到目的IP为自己的分片报文，会正常上送CPU处理，不会直接丢弃。你描述的现象更可能是分片报文在M-LAG组网下被转发或重组异常导致。
排查步骤：
1. 确认分片报文是否到达交换机CPU：
在ping不通时，于S6850上执行：

debug ip packet acl 3000

ACL 3000匹配源服务器IP、目的为网关IP的ICMP分片。
或抓包：

packet-capture local interface RAGGx direction inbound

看是否收到分片。
2. 检查M-LAG三层网关配置：
确认网关IP是否配置在M-LAG虚接口（Vlan-interface）上，且两成员设备配置一致。
执行 display mlag consistency-check 查看三层配置是否一致。
3. 检查分片重组：
执行 display ip statistics 查看分片重组失败计数（ReasmFail）。
若计数增长，说明分片在设备上重组失败，可能因M-LAG哈希导致分片散到不同成员设备。
4. 关键检查——M-LAG下分片转发：
分片报文经M-LAG成员口上行时，若首片和后续片哈希到不同物理成员口，会分别到达两台S6850。目的为网关IP时，只有收到首片的设备能重组，另一台设备上的后续片因无首片无法重组，导致ping不通。
目的为其他网段时，设备仅做三层转发，无需重组，所以能通。
5. 解决方案：
在M-LAG成员口上关闭基于L4端口的分片哈希，使同一IP流的分片走同一成员口：

interface Bridge-Aggregation x
link-aggregation load-sharing mode destination-ip source-ip

或开启M-LAG本地优先转发：

mlag forward-local enable

若服务器侧交换机也支持，可在服务器接入交换机上调整哈希，确保分片同路径。
6. 版本建议：
8307P72较老，分片处理有已知问题。建议升级到8307P75或更高版本，联系H3C确认分片相关补丁。
核心结论：S6850对目的为自己的分片会处理，但M-LAG下分片散列导致重组失败是常见根因。

S6850 收到目的为本机网关 IP 的分片报文，会上送 CPU 做分片重组，不是直接丢弃；M‑LAG 下联服务器做链路聚合，如果服务器侧聚合哈希使用四层端口参与计算，同一个大 ping 报文的不同 IP 分片会被 hash 分散到服务器两个网口，分别进入 M‑LAG 两台成员交换机。 Comware V7 默认ip reassemble local enable关闭，分片报文需要全部送到整机主主控重组；分片分散在两台 M‑LAG 设备，任意一台设备收集不到完整分片，重组失败报文被丢弃，网关不会回应 ICMP 应答。

访问其他网段终端正常的原因：跨网段报文属于转发流量，交换机硬件直接透传分片，交换机不需要做分片重组，分片由对端终端主机重组，因此业务正常。

处理方案（优先方案 2 根治）

【方案 1：交换机开启分片本地重组，两台 M‑LAG 设备均配置】

system‑view ip reassemble local enable

分片在入单板本地重组；但分片如果依旧跨 M‑LAG 两台设备进入，依然重组失败，属于缓解手段，不能彻底根除。

【方案 2：修改服务器网卡聚合哈希策略，根治问题（生产推荐）】 服务器 bond / 网卡聚合哈希不要使用源目 IP + 四层端口（layer3+4），修改为仅基于二层 + 三层哈希，不把四层端口作为 hash 因子。

• Linux bond 配置：xmit_hash_policy=layer2+3；不要 layer3+4
• Windows 网卡组合：哈希策略选择源 IP‑目的 IP，关闭传输层端口参与哈希。

作用：保证同一个 IP 报文的所有分片全部从服务器同一个物理网口发出，进入 M‑LAG 同一台交换机，分片不会被打散跨两台设备。

排查命令

display ip reassemble statistics #查看分片重组失败统计 display current‑configuration | include reassemble

注意：不要配置ip icmp fragment discarding，该命令直接丢弃 ICMP 分片，会加重故障。该现象不是 MTU 问题，MTU 问题会所有场景大包均不通。