问
如何在抓包的时候使用debug看有没有丢包
3天前提问
- 0关注
- 0收藏，81浏览
交换机 / 防火墙硬件芯片转发的业务报文默认不走 CPU，普通
debugging ip packet看不到硬件转发流量，只能看到上送 CPU 的报文（本机处理报文）H3C。 生产环境严禁直接开无过滤的 debug，极易打满 CPU 导致业务中断，必须用 ACL 做严格流量过滤，仅针对故障流调试H3C。
两种手段区分
- 设备内置抓包 packet‑capture：抓接口硬件层面实际收到 / 发出报文（等价 wireshark），看报文有没有到达本设备接口；
- debug 调试：看报文进入 CPU 之后，软件转发阶段丢弃原因（ACL、URPF、分片、会话、防攻击等）；
- 两者配合：
packet‑capture确认报文已经进到接口；再用 debug 看 CPU 处理环节为什么丢包。
方案一：packet‑capture 设备抓包（先确认报文是否到达设备接口）
1、接口抓包，保存为 pcap 文件
#抓入方向，过滤源目IP，写入flash:/test.pcap
packet‑capture interface GigabitEthernet 1/0/1 capture‑filter "host 192.168.1.10 and host 10.0.0.5" limit‑captured‑frames 200 write flash:/test.pcap
capture‑filter：wireshark 过滤表达式；- 抓完后用 FTP 把
test.pcap下载到电脑，wireshark 打开看接口是否收到报文、是否发出报文H3C。
如果 packet‑capture 接口抓包看不到报文：丢包发生在本设备上游链路、网线、对端设备，不需要开设备 debug。
方案二：debug 调试（只排查上送 CPU 的报文；硬件线速转发流量 debug 不可见）
适用场景：ping 设备本机、管理报文、需要 CPU 处理的报文；普通业务硬件转发流量 debug 看不到，优先使用报文示踪
packet‑followH3C。
步骤 1：配置 ACL，严格限定只抓故障流（关键，防止 CPU 过载）
system‑view
acl number 3000
rule permit icmp source 192.168.1.10 0 destination 10.0.0.5 0
rule permit icmp source 10.0.0.5 0 destination 192.168.1.10 0
#不要permit any！
步骤 2：终端打开 debug 输出（必须 Console，不要远程 telnet/ssh 做大量 debug 输出）
<H3C>terminal monitor
<H3C>terminal debugging
步骤 3：打开对应 debug 开关（二选一）
#1、IP错误调试，重点看软件层面丢包原因，推荐优先开这个
debugging ip error acl 3000
#2、完整IP报文调试（输出量大，谨慎使用）
debugging ip packet acl 3000
日志关键字：
Release MBUF代表报文被软件模块丢弃，后面会打印丢弃阶段原因（分片失败、uRPF、防攻击、会话不存在等）H3C。
✅调试结束必须关闭所有 debug（必做）
<H3C>undo debugging all
display debugging #确认全部关闭
方案三【防火墙 / ACG 推荐：报文示踪 packet‑follow，最适合排查转发丢包】
SecPath 防火墙 V7，专门用来追踪报文在设备内部经过各个业务模块的完整路径，可以看到在哪一个业务模块被丢弃、丢弃原因，比普通 debug 更适合业务转发流量，支持 ACL 过滤故障流H3C。
#1、ACL匹配故障流
acl number 3000
rule permit ip source 192.168.1.10 0 destination 10.0.0.5 0
#2、开启报文追踪，绑定ACL
debugging packet‑follow acl 3000
#3、查看统计，看哪个模块丢弃
display packet‑follow statistics
#结束关闭
undo debugging packet‑follow
配套查看丢包统计命令（不用开 debug 就可以先看）
#防火墙：软件层面报文丢弃统计
display system internal ip packet‑drop statistics
#交换机接口错包统计（物理层丢包）
display interface GigabitEthernet 1/0/1
#查看端口队列QoS丢弃
display qos queue statistics interface GigabitEthernet 1/0/1
完整现场排查逻辑（按顺序）
- 先看物理层：
display interface，检查 CRC、errors、drops 计数器，确认不是网线 / 光模块物理丢包； - 使用 packet‑capture 接口抓包：确认报文有没有进入本设备接口；
- 抓包接口收不到报文 → 问题在上游，本设备不需要 debug；
- 接口收到报文，但是出接口抓包没有报文 → 丢包发生在本机设备内部；
- 如果是防火墙 / 安全设备：优先
packet‑follow报文示踪，定位业务模块丢弃； - 如果是上送 CPU 的报文（ping 设备本身、管理流量），用
debugging ip error acl xxx，必须 ACL 严格过滤流量； - 调试完成，
undo debugging all全部关闭 debug，防止后续业务隐患。
⚠️高危注意事项
- 不要远程 SSH/Telnet 做大量 debug 输出，Console 串口操作；
- 绝对禁止
debugging ip packet不带 ACL 过滤，流量大设备直接 CPU 打满业务中断； - 硬件芯片线速转发的业务流量，普通
debugging ip packet看不到，这是平台机制，不是 bug； - 做完调试一定要 undo debugging all，遗留 debug 后台会持续消耗 CPU。
暂无评论
编辑答案
➤
✖
亲~登录后才可以操作哦!
确定
✖
✖
你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
✖
举报
×
侵犯我的权益
>
对根叔社区有害的内容
>
辱骂、歧视、挑衅等（不友善）
侵犯我的权益
×
侵犯了我企业的权益
>
抄袭了我的内容
>
诽谤我
>
辱骂、歧视、挑衅等（不友善）
骚扰我
侵犯了我企业的权益
×
您好，当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱，我们会在审核后尽快给您答复。
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
抄袭了我的内容
×
原文链接或出处
诽谤我
×
您好，当您发现根叔知了上有诽谤您的内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱，我们会尽快处理。
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
对根叔社区有害的内容
×
垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载
>
辱骂、歧视、挑衅等（不友善）
骚扰我
诱导投票
不规范转载
×
举报说明
暂无评论