核心问题答复
1、报文在接口硬件阶段直接丢弃（PHY / 芯片超长帧丢弃）
- 不会生成会话表
报文在接口芯片层面就被丢弃，报文还没有送入防火墙业务模块（域间策略 / ASPF），根本不会走到会话创建流程，
display session table看不到任何该流量会话（放行会话 / 丢包会话都不会生成）H3C。
注意：丢包会话（deny‑session）仅针对 ASPF、连接数限制模块丢弃报文才会生成；接口芯片、二层超长帧丢弃不属于该场景，不会产生丢包会话H3C。
- QoS 流统（accounting）也统计不到 QoS 策略流统计是报文上送到业务芯片之后才做统计；接口芯片直接丢弃的报文，还没有进入 QoS 处理点，流统计计数不会增长H3C。
这正好与你现场现象吻合：大包完全看不到会话，QoS 统计 0。
区分两种丢包场景： | 丢包场景 | 是否生成会话 | QoS 流统能否统计 | |---|---|---| | 接口芯片 / PHY 丢弃（超长帧、CRC 错、缓冲区满）|❌ 不生成任何会话 |❌ 统计不到 | | 域间策略 / ASPF / 连接数限制软件丢包 |✅ 可生成 deny‑session（需开启）|✅ QoS 可以统计到 |
2、报文处理简要顺序（M9K V7）
接口 PHY 芯片接收报文 → 二层帧校验（超长帧、CRC）→ QoS 策略（业务芯片）→ 查找 / 创建会话表 → 域间安全策略检查 → 转发 / 丢弃H3C。
如果在最前面的 PHY / 二层阶段丢弃，后面 QoS、会话全部不会触发。
二、排查接口、进程丢包常用命令（M9K）
1）查看接口硬件丢包、错包、超长帧
#看接口统计，重点观察 input drops、CRC、errors、long frames计数
display interface Ten‑GigabitEthernet 1/0/x
#专门查看接口各类原因丢包明细（芯片丢包、FFP、速率限制等）
display packet‑drop interface Ten‑GigabitEthernet 1/0/x
display packet‑drop summary
⚠️提示：
display packet‑drop不统计 QoS policing、filter deny 丢弃，这类软件丢弃要看display qos policy interface统计计数H3C。
2）查看 QoS 策略流统计
display qos policy interface Ten‑GigabitEthernet 1/0/x inbound
display qos policy interface Ten‑GigabitEthernet 1/0/x outbound
###3）查看会话表（确认大包完全无会话）
display session table source‑ip x.x.x.x destination‑ip x.x.x.x verbose
###4）查看 CPU / 进程丢包（上送 CPU 报文、控制平面丢包）
display cpu‑usage slot x
display system‑internal drop statistics
三、针对你现场 “>1500 不通，<1500 正常” 故障分析建议
现象特征：大包无会话、无流统计，说明报文根本没有进到防火墙业务处理模块，大概率在接口二层帧层面被丢弃，问题点不一定在防火墙业务配置。
- 检查两端接口的 MTU、最大帧长 (jumbo)
M9K 接口
max‑frame‑length，确认是否允许接收大于 1518 字节帧；锐捷交换机侧检查MTU、Jumbo 帧开关。
带 VLAN 标签的报文，二层帧会多出 4 字节 tag，IP MTU=1500 时，二层帧实际 1518 字节；如果对端设备 max‑frame 限制为 1518，带标签报文会被判定超长帧直接丢弃。
- 测试：把 ping 包 DF 位关闭，
ping ‑l 1600 ‑f改成ping ‑l 1600，允许分片，看能否通；
如果允许分片后可以通，说明是端到端 MTU / 最大帧长不匹配。
- 定位在哪一侧丢弃：
- 在 M9K 接口抓包，看能不能收到大于 1518 字节的帧；
- 如果 M9K 接口根本收不到大包（
display interface无大包计数），说明锐捷交换机就已经把大包丢弃，没有发给防火墙。
- 已开启虚拟分片重组（ip virtual‑reassembly），该功能是三层 IP 分片重组，不能解决二层超长帧丢弃；二层帧超长在芯片就丢了，报文到不了三层分片处理模块。
四、变更排查操作步骤建议
- 先清统计：
reset counters interface、reset packet‑drop interface，再复现故障，看哪个计数器上涨。 - 确认 M9K 接口 max‑frame‑length，建议配置为 9216；同时确认锐捷侧开启巨帧。
interface Ten‑GigabitEthernet 1/0/x
max‑frame‑length 9216
- 双向分别 ping，对比两端接口的
long frame、input drops 计数器是否增长。 - 如果 M9K 接口完全收不到大包，重点排查锐捷交换机配置。
总结
你现场大包无会话 + QoS 流统计为 0，非常典型：报文在接口硬件二层阶段被丢弃，没有送到防火墙会话、QoS 业务模块，不是防火墙域间策略、虚拟分片重组这类业务配置问题，优先排查二层最大帧、MTU，重点排查对接的锐捷交换机侧。
针对你描述的1500以上大包不通、小包正常、双向现象一致，且无会话、无流统计，这更像是MTU或分片相关丢包，可能发生在防火墙接口或中间链路设备。虽然你已开启虚拟分片重组，但仍需确认以下几点：
排查步骤与命令
1. 检查接口MTU配置
确认防火墙与锐捷交换机互联接口的MTU是否一致，尤其是允许巨型帧或至少大于1500。
命令：
display interface GigabitEthernet x/x/x
查看Maximum transmission unit字段，默认1500，若需支持1500以上大包（含IP头），需调整为更大值（如9000）。
修改MTU（接口视图）：
mtu 9000
2. 检查接口丢包统计
查看接口错误计数，判断是否物理层或链路层丢包：
display interface GigabitEthernet x/x/x verbose
关注Input errors、Output errors、CRC errors、Overruns、Giants等字段。若Giants计数增长，说明收到超过MTU的帧被丢弃。
3. 检查防火墙安全策略与会话
虽然你说无会话，但可确认是否因分片报文首片未通过导致后续分片被丢弃：
display session table verbose | include <源/目的IP>
检查是否开启ip virtual-reassembly（虚拟分片重组）：
display ip virtual-reassembly
确保在入接口和出接口都启用。
4. QoS流统计验证
配置流策略统计大包流量，确认是否真的无统计：
acl advanced 3000
rule 0 permit ip source <源IP> 0 destination <目的IP> 0
traffic classifier test
if-match acl 3000
traffic behavior test
accounting
qos policy test
classifier test behavior test
应用到接口后，用大包ping测试，查看：
display qos policy interface GigabitEthernet x/x/x
若计数为0，说明报文未进入QoS处理，即接口入口丢包。
5. 检查接口工作模式与链路协商
确认两端接口速率、双工模式一致，避免因协商问题导致大包丢：
display interface GigabitEthernet x/x/x |
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论