简介这份资源面向网络运维工程师与网络故障排查初学者围绕Wireshark抓包处理网络故障这一主题提供一份实战案例讲解文档。内容以锐捷交换机环境为例涵盖VLAN端口流量异常、镜像端口配置、抓包分析、内外网IP攻击定位与处置等典型场景帮助读者掌握从发现异常到定位故障终端的完整排错思路。资源包共1个文件为docx格式文档压缩包大小约385KB内容紧凑适合作为日常巡检与故障应急的参考手册。目前已有1549人学习下载说明其在网络运维群体中具有一定实用价值。文档中结合具体命令与操作截图展示了通过show mac-address、show lldp等命令逐层定位接入层交换机端口的方法并介绍了利用AC管理页面快速查找异常终端MAC与AP位置的技巧对提升实际故障处理效率有直接帮助。1. 从一次空载端口跑满 5000KBPS 说起Wireshark 抓包到底能解决什么日常巡检时发现一个反常现象某个平时空载只有 200 多 KBPS 的 AP 端口流量突然飙到好几千 KBPS而且不是单个 VLAN 的问题——所有无线网段 VLAN 都出现了 5000KBPS 以上的异常流量。这种场景下Ping 和 Traceroute 基本帮不上忙因为它们只能告诉你通不通绕不绕没法告诉你谁在发什么包。Wireshark 抓包处理网络故障的价值就在这里它把交换机端口上的原始流量完整还原出来让你看到每一个报文的源 IP、目的 IP、协议类型和载荷内容从而定位到具体是哪台终端、跑了什么协议、在攻击谁。这套方法适合网络运维、驻场工程师和负责园区网排障的从业者尤其是管理大量接入交换机、AP 和 VLAN 划分的环境。下面按镜像配置 → 抓包 → 分析 → 定位 → 处置的完整链路拆一遍交换机以锐捷为例其他品牌思路一致、命令不同。2. 镜像端口配置锐捷交换机上的 source 与 destination 怎么下抓包的前提是让 Wireshark 能看到目标端口的流量。交换机本身不会把某个端口的报文广播给其他口必须显式配置端口镜像SPAN。这一步是整个流程里最容易翻车的地方——配错了要么抓不到包要么把镜像口本身搞瘫。2.1 为什么必须先关端口安全策略很多园区的接入交换机默认开了 IP Source Guard 和 ARP Check目的是防止 IP 欺骗和 ARP 攻击。但这两条策略会拦截镜像流量里的部分报文导致你在 Wireshark 里看到的包不完整甚至一个包都抓不到。常见做法是在镜像目的端口也就是你电脑接的那个口下先 NO 掉这两条命令。# 进入镜像目的端口本例为 24 口 interface gigabitEthernet 0/24 # 关闭 IP 源防护 no ip verify source port-security # 关闭 ARP 检查 no arp-check这里要注意被镜像端口本例的 1 口接了 AP不需要关安全策略因为它是流量来源关不关不影响镜像复制。只有目的口需要处理因为你的抓包电脑要接收这些复制过来的报文安全策略会把它当成异常流量拦掉。提示不同品牌交换机的端口安全命令不一样。华为叫ip source check user-bind enableH3C 叫ip verify source具体以你手头设备的命令手册为准。本文案例统一用锐捷的命令格式。2.2 建立镜像会话source 和 destination 的参数含义关完安全策略后在全局配置模式下建立镜像会话。锐捷的写法是monitor session一个会话号对应一组源和目的。# 创建镜像会话 1源端口为 1 口方向为 both收发都镜像 monitor session 1 source interface gigabitEthernet 0/1 both # 指定镜像目的端口为 24 口 monitor session 1 destination interface gigabitEthernet 0/24 switch参数逐个说清楚monitor session 1会话编号一台交换机可以建多个镜像会话编号不冲突即可。source interface gigabitEthernet 0/1 both源端口是 1 口both表示同时镜像入向和出向流量。如果你只关心某个方向可以改成rx只收或tx只发。排障时一般用both避免漏包。destination interface gigabitEthernet 0/24 switch目的端口是 24 口末尾的switch表示把镜像报文以普通交换报文的形式发出去这样你的电脑网卡能正常接收。有些平台不加switch关键字会导致目的口只发不打标签的原始帧普通网卡可能识别不了。配完之后用show monitor确认会话状态。输出里会显示 session 1 的 source 和 destination 是否都 up如果 destination 显示 down检查 24 口有没有插网线、端口有没有被 shutdown。2.3 抓包电脑的连接方式和网卡设置电脑用网线接 24 口1 口上的 AP 保持原样不动。这里有个细节抓包电脑的网卡不需要配 IP 也能抓到包因为镜像流量是二层转发过来的Wireshark 直接监听网卡就行。但如果你想让电脑同时能管理交换机可以配一个同网段的管理 IP不影响抓包。打开 Wireshark选择对应的物理网卡不要选任何虚拟网卡或 Loopback。如果列表里分不清哪个是物理口看网卡名称里带以太网或Ethernet的那个或者拔插网线看哪个接口的指示灯在闪。注意抓包时不要开混杂模式以外的过滤先全量抓几秒确认有流量进来再设过滤条件。上来就写http过滤很可能把真正的异常协议漏掉。3. 从抓包文件到故障定位SSDP 报文和 IP 溯源怎么读抓到包只是第一步真正花时间的是分析。很多人抓了几百兆的 pcap 文件打开一看全是密密麻麻的报文不知道从哪下手。下面按实际排障顺序拆。3.1 先看协议分层统计锁定异常协议Wireshark 打开抓包文件后第一件事不是逐个看包而是点Statistics → Protocol Hierarchy。这个窗口会按协议分层列出每种协议的报文数量和字节占比。正常空载端口的流量里ARP、STP、LLDP 这些基础协议占大头TCP/UDP 的应用流量很少。如果某个协议突然占了 80% 以上那就是嫌疑对象。本例中协议分层里 SSDP 的占比异常高。SSDP 是简单服务发现协议基于 UDP 1900 端口正常用于设备自动发现比如投屏、DLNA。但一台设备如果中了 SSDP 反射攻击的招会向大量目标发送 SSDP 查询报文造成流量暴涨。3.2 用显示过滤器缩小范围确认异常协议后在 Wireshark 的显示过滤器栏输入过滤条件把无关报文排除掉。# 只看 SSDP 报文 ssdp # 只看源 IP 为 192.168.10.55 的报文 ip.src 192.168.10.55 # 组合过滤某 IP 发出的 SSDP 报文 ip.src 192.168.10.55 ssdp过滤器语法里是精确匹配是逻辑与。如果你想按网段过滤可以用ip.src 192.168.10.0/24。过滤之后报文列表会大幅缩短方便你观察源 IP 的分布。3.3 判断内网 IP 还是外网 IP走不同处置路径抓包结果里异常流量的源 IP 无非两种内网 IP 或外网 IP。这两条路的处置方式完全不同。外网 IP 的情况打开数据包详情看目的端口和调用端口。如果确认某个映射端口没有其他服务在用可以直接在防火墙上关闭映射如果有业务在用就切换到另一个映射端口。切换后如果新端口仍被扫描攻击常见做法是提报到网络运营商对攻击源做溯源同时把专线 IP 切到运营商提供的备用 IP。内网 IP 的情况这是更常见的场景。通过抓包拿到异常设备的 IP 和 MAC 地址后需要一层层往下找物理位置。具体命令链路如下# 在核心交换机上用 MAC 后几位查下联端口 show mac-address-table | include 3c2e.ff01 # 得到下联端口后用 LLDP 查看邻居设备 show lldp neighbors # 进入汇聚层交换机同样用 MAC 查下联端口 show mac-address-table | include 3c2e.ff01 # 再进接入层交换机继续查 show mac-address-table | include 3c2e.ff01每一步的逻辑是一样的MAC 地址表告诉你这个 MAC 从哪个端口学到的LLDP 告诉你这个端口对面接的是哪台设备。逐层往下最终定位到接入层交换机的具体端口那个端口上插的就是异常设备。3.4 用 AC 管理平台反查 AP 和终端位置如果异常设备是无线终端还有一条更快的路登录 AC 管理页面在用户管理里输入 IP 地址直接能看到该用户的 MAC 和所连接的 AP。前提是 AC 平台上的运维数据是实时更新的——本例中恰好满足这个条件所以直接通过 AC 定位到了 AP 所在位置找到了一台教学一体机。提示如果 AC 平台的数据不是实时更新的还是走交换机命令那条路更可靠。紧急情况下可以先用 MAC 地址在核心交换机上禁用该设备联网恢复网络后再慢慢找物理位置。4. 避坑与排查镜像抓包最容易翻车的五个点这一节记录的是实际排障中反复遇到的坑每一条都按现象 → 原因 → 解决写清楚。现象一配了镜像Wireshark 一个包都抓不到。原因镜像目的端口的安全策略没关或者目的口被 shutdown 了。 解决进目的口确认no ip verify source port-security和no arp-check都执行了再用show interface gigabitEthernet 0/24看端口状态是不是 up。现象二能抓到包但只有广播报文没有单播流量。原因镜像会话的 source 方向配成了rx或tx只镜像了一个方向。 解决改成both重新抓。排障场景下不要省这个关键字。现象三抓包文件里大量重复报文分析困难。原因镜像口同时镜像了多个 VLAN 的流量或者源端口本身流量就很大。 解决在 Wireshark 里用显示过滤器按 VLAN 或 IP 缩小范围不要试图一次分析所有报文。也可以临时把 source 改成只镜像特定 VLAN。现象四用 MAC 查端口时核心交换机上查不到。原因MAC 地址表项已经老化或者 MAC 地址输入格式不对。 解决锐捷的 MAC 格式是xxxx.xxxx.xxxx用后几位查时注意加点。如果表里没有先在核心交换机上 ping 一下目标 IP 触发 ARP 学习再查。现象五定位到端口后发现端口上接的是一台交换机而不是终端。原因接入层下面还串了小交换机或 HUB。 解决继续用 LLDP 往下查或者直接拔掉端口网线看哪个设备断网。这种情况在办公区很常见不要假设每个端口都直连终端。5. 处置后的验证与日常巡检习惯找到异常设备只是完成了一半另一半是验证处置效果并建立可复用的巡检习惯。5.1 处置后的验证方法本例中异常设备是一台教学一体机断网重装系统后恢复。验证方式是再次抓包看 SSDP 报文是否消失、端口流量是否回落。# 重装后再次抓包用同样的过滤器看 SSDP ssdp # 对比协议分层里的 SSDP 占比 Statistics → Protocol Hierarchy重装后抓包结果显示SSDP 报文已经消失端口流量从 5000 多 KBPS 降到 400 多 KBPS。这里有个基准值要注意本项目网络设备启用了 SNMP所以默认交换机流量在 400KBPS 左右。如果没有启用 SNMP 等相关协议空载流量应该更低200KBPS 甚至更低才算正常。验证时不要拿一个绝对值去套所有环境要结合自己网络的协议启用情况判断。5.2 把抓包能力变成日常巡检的一部分这次故障能快速定位靠的不只是 Wireshark 用得好还有两个前置条件一是 AC 平台上的运维数据实时更新过二是核心交换机的 MAC 地址表和 LLDP 邻居信息完整。如果这两样缺一个定位时间至少要翻倍。我一般会建议团队养成几个习惯习惯具体做法频率巡检时记录空载端口流量基线用网管平台导出各端口 24 小时平均流量每周定期核对 AC 用户数据检查 AC 管理页面里的用户-AP 映射是否与实际一致每月保留核心交换机 LLDP 拓扑导出show lldp neighbors结果存档每季度镜像配置模板化把锐捷/华为/H3C 的镜像命令写成模板排障时直接套一次编写最后说一个我自己的教训早期排障时总想一步到位抓到包就急着找哪个 IP 在攻击结果忽略了协议分层统计绕了很多弯路。从那以后我每次打开抓包文件都强制先走一遍Statistics → Protocol Hierarchy确认异常协议之后再设过滤器。这个顺序看起来慢实际上省时间。希望帮到你。本文还有配套的精品资源点击获取
