简介：本资源是一份面向网络运维工程师与IT技术支持人员的Wireshark实战排错指南，聚焦真实企业级网络故障场景中的抓包分析与快速定位。内容涵盖VLAN端口流量异常突增、无线AP空载高流量、内网/外网IP攻击溯源等典型问题，详细讲解锐捷交换机镜像配置、Wireshark抓包实操、SSDP协议异常识别、MAC/IP地址逐级定位（从AC到核心再到接入层交换机）、防火墙NAT映射调整及终端隔离处置等完整闭环处理流程。资源为1个385KB的Word文档（.docx），结构清晰，含命令截图、配置示例与结果验证说明，便于随时查阅与现场复用。目前已有1550人学习下载，适合具备基础网络知识、正参与一线运维或备考网络认证的技术人员系统提升抓包排障能力。
1. Wireshark抓包不是“看热闹”，是网络故障的逆向手术刀：从5000KBPS突增流量定位一台教学一体机的真实战况
你有没有遇到过这种场景：某天巡检AC，发现所有无线VLAN端口空载流量突然飙到5000KBPS以上，而正常值本该是200–400KBPS？不是丢包、不是延迟高，是“安静地疯狂发包”。这时候翻日志、查SNMP图表、盯监控面板，全在报“一切正常”——但交换机端口LED灯狂闪，带宽利用率曲线像心电图骤停后又猛跳三下。这不是误报，是内网设备在静默失控。本项目就是从这个真实压测级异常切入：用Wireshark做一次精准的“网络病理切片”。它不靠猜、不靠重启、不靠换线，而是把镜像流量导进Wireshark，用协议解码+过滤器+统计图三连击，3分钟内锁定发起SSDP广播风暴的源头——一台连着AP的教学一体机。整个过程不依赖厂商私有工具、不修改业务配置、不中断用户上网，只靠标准镜像+Wireshark原生功能闭环。适合一线网络运维、驻场工程师、高校IT支持岗，尤其当你面对的是“没告警但明显卡”的黑匣子类故障时，这套打法比等厂商TAC远程更直接、比抓脑壳式排查更可复现。它解决的从来不是“怎么装Wireshark”，而是“当流量突增没日志、没告警、没明确报错时，你第一帧该过滤什么、第二步该看哪个统计页、第三步如何用MAC反向穿透三层交换机定位物理端口”。
2. 镜像配置：锐捷交换机实操全流程与命令级参数拆解（含安全策略绕过逻辑）
2.1 为什么必须关闭ip verify source和arp-check？——镜像端口的“协议洁癖”陷阱
锐捷交换机默认开启端口安全策略，其中ip verify source port-security用于防止IP地址欺骗，arp-check则校验ARP请求中的IP-MAC绑定关系。这两条策略在普通接入口上是安全刚需，但在镜像目的端口上却会成为抓包失败的隐形杀手。原因在于：镜像流量是“复制粘贴”而非“真实转发”，其源MAC/IP可能与目的端口学习到的表项冲突，触发安全策略丢弃镜像帧。Wireshark收不到包，不是网线没插牢，是交换机在后台默默把你复制来的流量“消毒”掉了。
提示：此操作仅针对镜像目的端口（本例中为GigabitEthernet 0/24），被镜像源端口（G0/1）无需关闭任何策略，保持原有安全配置即可。
2.2 镜像会话创建：monitor session命令的四个关键参数含义
锐捷交换机使用monitor session命令建立镜像会话。本例执行两条核心命令：
monitor session 1 source interface gigabitEthernet 0/1 both monitor session 1 destination interface gigabitEthernet 0/24 switchsession 1：会话ID，全局唯一，多会话时需区分（如session 2）；source interface ... both：both表示双向镜像（入+出），若只关心上行流量可用rx，只关心下行用tx；此处必须选both，否则无法捕获SSDP响应包；destination interface ... switch：switch参数是锐捷特有，表示目的端口为“交换模式”（即允许二层转发），区别于router模式（三层路由转发）；若漏写此参数，镜像流量将无法透传至PC网卡；- 目的接口必须是未启用其他业务的空闲口，且不能是堆叠口、聚合口或管理口。
2.3 验证镜像是否生效：三步交叉验证法（不只靠show monitor）
仅执行show monitor显示Session 1 is up并不等于抓包成功。我经历过三次“显示up但Wireshark收不到包”的翻车，最终确认必须同步验证以下三点：
- 物理层确认：用
show interface gigabitEthernet 0/24检查该端口input rate和output rate是否随源端口流量同步变化（如G0/1流量升，G0/24 input rate也升）； - 链路层确认：在连接镜像口的PC上执行
tcpdump -i eth0 -c 10 'ether[12:2] == 0x0800'（Linux）或Wireshark启动后立即看是否出现ARP、LLDP等基础二层帧； - 协议层确认：在Wireshark中设置显示过滤器
eth.addr == aa:bb:cc:dd:ee:ff（填入源端口MAC），若能持续看到该MAC的帧，则镜像通路100%可靠。
注意：若第1步速率无变化，说明镜像未真正启用，需检查是否遗漏
switch参数；若第2步无ARP帧，大概率是ip verify source未关闭；若第3步MAC帧可见但无业务包，需确认源端口是否真有流量（show interface g0/1看input rate）。
3. Wireshark实战分析：从5000KBPS流量中揪出SSDP广播风暴的四步过滤法
3.1 第一层过滤：用ip.len > 100快速筛掉噪声包
原始抓包文件动辄百MB，满屏ARP、LLDP、STP、CDP等维护协议包。直接看TCP流或HTTP会淹没在噪音里。我的血泪经验是：先砍掉90%无效帧，再深挖。SSDP（Simple Service Discovery Protocol）基于UDP，典型请求包长为100–200字节（含HTTP头+XML描述），远大于ARP（60字节）、ICMP echo（84字节）。因此首道过滤器设为：
ip.len > 100此过滤器瞬间将包量压缩至1/10，且保留全部SSDP、DNS、HTTP、TLS等业务相关包。注意：不要用udp.length > 100，因部分SSDP响应包可能被分片，IP层长度才具一致性。
3.2 第二层聚焦：udp.port == 1900锁定SSDP协议主战场
SSDP固定使用UDP端口1900（IANA注册端口），所有M-SEARCH请求、NOTIFY通知、HTTP/1.1响应均走此端口。执行：
udp.port == 1900此时Wireshark仅显示SSDP交互帧。观察时间轴，若发现某IP在1秒内发出10+条M-SEARCH * HTTP/1.1（目标地址239.255.255.250），基本可判定为广播风暴源。本案例中，192.168.10.88在30秒内发送了217条M-SEARCH，而全网其他设备总和不足5条。
3.3 第三层溯源：用ip.addr == 192.168.10.88 && http.host contains "ssdp"确认设备指纹
SSDP请求头中HOST字段固定为239.255.255.250:1900，但响应头（NOTIFY/HTTP/1.1 200 OK）中SERVER或USN字段常含设备型号。对192.168.10.88执行：
ip.addr == 192.168.10.88 && http.host contains "ssdp"展开一条NOTIFY包，在Packet Details面板逐层点开Hypertext Transfer Protocol→Server，可见值为Windows/10.0 UPnP/1.0 DLNADOC/1.50，结合AC用户列表中该IP对应设备为“Win10教学一体机”，设备类型闭环。
3.4 第四层验证：Statistics → Protocol Hierarchy 确认协议占比
点击菜单栏Statistics→Protocol Hierarchy，弹出分层统计窗口。本案例中：
- UDP 占比 82.3%
- 其中
UDP -> SSDP子项占UDP总量的76.1% - TCP仅占5.2%，且几乎全是SSH管理流量（来自AC和核心交换机）
此数据铁证：流量突增非由Web攻击、FTP下载或视频流引起，而是SSDP协议层失控。若此处TCP占比高，应立即切换分析方向至HTTP/HTTPS或TLS握手异常。
4. 内网IP定位：从Wireshark抓包到物理端口的三级交换机穿透术（锐捷命令链）
4.1 第一级：核心交换机查MAC→接入层端口（show mac-address-table）
Wireshark已确认异常IP192.168.10.88，其MAC为a0:b1:c2:d3:e4:f5。登录核心交换机（假设为锐捷RG-S8600），执行：
show mac-address-table | include a0:b1:c2:d3:e4:f5输出示例：
a0:b1:c2:d3:e4:f5 dynamic 10 Gi1/0/20 00:00:45关键信息：Gi1/0/20为该MAC所连的下联端口，VLAN 10。此端口连接的是汇聚层交换机（非最终接入点）。
4.2 第二级：汇聚层查LLDP邻居→接入层IP（show lldp neighbors detail）
Gi1/0/20是核心到汇聚的链路，需知汇聚层设备IP才能SSH登录。执行：
show lldp neighbors interface Gi1/0/20 detail输出关键段：
Chassis ID: 10.20.30.40 Port ID: Gi0/1 System Name: RG-S2928G-E-ACCESS-01Chassis ID即汇聚层交换机管理IP10.20.30.40。记录此IP，SSH登录该设备。
4.3 第三级：接入层查MAC→物理端口（show mac-address-table+show arp交叉验证）
在汇聚层交换机上，show mac-address-table | include a0:b1:c2:d3:e4:f5可能返回空（因MAC表老化或未学习），此时需转向接入层。但接入层设备名未知？用LLDP反查：
# 在汇聚层执行，查Gi0/1下联的接入层设备 show lldp neighbors interface Gi0/1 detail得到接入层IP192.168.200.5。SSH登录后执行：
# 查MAC表（若存在） show mac-address-table | include a0:b1:c2:d3:e4:f5 # 若无结果，查ARP表（更可靠，因ARP老化慢） show arp | include 192.168.10.88show arp输出中Interface列即为该IP所连物理端口，如Gi0/20。至此，定位完成：异常设备接在接入层交换机192.168.200.5的GigabitEthernet 0/20口。
提示：AC平台用户管理界面可直查IP→AP→MAC→物理位置，但前提是AC数据实时同步。若AC离线超2小时，必须走上述三层命令链，这是无依赖的兜底方案。
5. 避坑指南：Wireshark抓包排障中5个高频翻车点与硬核解法
5.1 现象：Wireshark显示“0 packets captured”，但show monitor显示镜像会话UP
原因：镜像目的端口启用了ip verify source或arp-check，导致镜像帧被安全策略丢弃。
解决：在镜像目的端口下执行no ip verify source port-security和no arp-check，再shutdown/no shutdown该端口刷新状态。
5.2 现象：抓包文件中能看到大量ARP请求，但无任何业务包（HTTP/TCP/UDP）
原因：镜像配置为rx单向（仅接收），而业务流量实际走tx方向（如AP向终端发数据），或源端口本身无流量。
解决：确认monitor session命令中source参数为both；用show interface验证源端口input rate和output rate是否非零。
5.3 现象：Wireshark能收到包，但所有IP地址显示为10.0.0.1或192.168.1.1等网关地址
原因：交换机开启了ip local policy route-map或ACL重定向，导致镜像流量被NAT或策略路由修改源IP。
解决：在镜像源端口执行show running-config interface，检查是否存在ip policy route-map或ip access-group调用；临时删除后测试。
5.4 现象：过滤udp.port == 1900后包量极少，但Statistics → Conversations → UDP显示1900端口通信量巨大
原因：Wireshark默认不解析SSDP，udp.port == 1900仅匹配端口号，未识别协议内容；而Conversations统计基于端口，故显示高。
解决：启用SSDP解析：Edit→Preferences→Protocols→UDP→ 勾选Enable dissection of UDP packets on these ports，输入1900，重启Wireshark。
5.5 现象：定位到接入层端口后，拔掉网线设备仍持续发包
原因：该设备为虚拟机或容器，物理端口连接的是服务器，异常进程在宿主机内运行。
解决：登录对应服务器（通过MAC查DHCP日志或show arp得IP），执行netstat -ano | findstr :1900（Windows）或ss -tuln | grep 1900（Linux），定位PID后taskkill /PID <pid> /F或kill -9 <pid>。
6. 进阶技巧：用Wireshark IO Graphs量化验证修复效果与建立基线阈值
6.1 用IO Graphs绘制流量热力图：30秒内识别SSDP风暴衰减曲线
Wireshark的IO Graphs（I/O 图表）是验证修复效果的黄金工具。它不依赖主观判断，用Y轴（每秒包数/字节数）+X轴（时间）生成可视化衰减曲线。操作路径：Statistics→IO Graphs→ 点击+号新建图表。
关键参数设置：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| Name | SSDP_MSEARCH | 自定义名称，便于识别 |
| Filter | udp.port == 1900 && udp.payload && http.request.method == "M-SEARCH" | 精确匹配SSDP搜索请求，排除NOTIFY干扰 |
| Y Axis | Packets/Tick | 选“包数”比“字节数”更敏感，小包风暴易识别 |
| Tick Interval | 1 sec | 每秒统计，匹配人眼可读节奏 |
| Graph Style | Impulse | 脉冲式柱状图，峰值一目了然 |
修复前（教学一体机未断网）：图表呈密集尖峰，每秒30+包；
修复后（断网重装）：尖峰消失，回落至每秒0–1包波动。
提示：若修复后仍有规律性尖峰（如每5分钟一次），说明存在定时任务或服务自启，需查
systemctl list-timers（Linux）或taskschd.msc（Windows）。
6.2 建立VLAN级流量基线：用Telegraf+InfluxDB自动预警突增
手工抓包是救火，自动化基线才是防火。我给某高校部署的方案是：在核心交换机启用SNMPv3，用Telegraf采集各VLAN接口ifInOctets（入向字节数），每30秒推至InfluxDB。Grafana面板配置告警规则：
WHERE derivative(mean("ifInOctets"), 30s) > 5000000 // 含义：30秒内入向流量增量超5MB，即5000KBPS此规则比传统“阈值绝对值”更准——它检测的是变化率，能捕捉200KBPS→5000KBPS的突增，而忽略日常400KBPS→600KBPS的合理波动。当告警触发，自动执行脚本：ssh core-switch "show monitor"+curl -X POST http://ac-api/v1/users?ip=192.168.10.x，5秒内返回异常IP及关联AP。
6.3 一个反直觉但救命的习惯：每次抓包前必做“空载基准采样”
我吃过最大亏，是在某次处理“网页打不开”故障时，直接抓包分析HTTP，结果发现所有TCP SYN都超时。折腾2小时后才发现：问题不在网络，而在客户端DNS配置错误。根源是——我没做基准对比。现在我的铁律是：任何故障抓包前，先在相同端口、相同VLAN、相同时间段，抓1分钟空载流量（无业务操作），存为baseline.pcapng。后续分析时，用Wireshark的File→Merge功能将故障包与基线包合并，再用Statistics→Compare→IO Graphs并排对比。若基线中已有大量ARP/LLDP/STP，说明是交换机固有行为；若故障包中突增tcp.flags.syn == 1 && tcp.flags.ack == 0，才指向TCP连接问题。这个习惯让我少走70%的弯路。
从那以后我每次接到“流量突增”工单，都强制走一遍：空载采样 → 镜像配置 → Wireshark四层过滤 → 三级交换机穿透 → IO Graphs验证。它不炫技，但每一步都踩在故障根因上。希望帮到你。
本文还有配套的精品资源，点击获取
