简介这是一份面向网络运维与故障排查人员的实战案例文档围绕Wireshark抓包处理网络故障展开重点解决VLAN内端口流量突增、AP空载却出现大量数据包等异常场景。资源包共1个docx文件大小385KB内容以锐捷交换机为案例梳理AC巡检发现无线网段流量异常、POE交换机镜像端口配置、关闭端口安全策略、monitor session建立与show monitor验证等前置操作。文档进一步说明如何用Wireshark分析抓包文件区分内网与外网异常IP并通过核心交换机、AC查询MAC地址和接入层端口定位异常终端或映射端口。文中还记录了SSDP协议攻击导致端口流量升高的排查与恢复对比可帮助读者把抓包现象对应到设备命令、故障位置和处置步骤。已有1550人学习适合需要提升网络故障定位能力的中初级运维人员参考。1. 空载端口跑到 5000 kbps为什么先抓包再动手园区网里最容易被忽略的故障不是断网而是“没断但很忙”。某次巡检我发现一台接入交换机上接 AP 的端口平时空载只有 200 多 kbps那天涨到 5000 kbps 以上而且所有无线网段所在的 VLAN 在同步上涨。用 Wireshark 抓包处理网络故障的价值就在这它不猜它把链路上真实跑的东西摊在你面前。这套流程针对的是“端口流量异常、业务却没明显中断”这一类问题从流量基线判定、交换机端口镜像、抓包取证一路走到用 MAC 地址表和无线控制器把异常设备定位到某个房间的具体端口。做网络运维的可以直接照搬做网络故障排查类毕设、课设的也能按这个结构搭自己的方案。2. 排查链路设计从流量异常到可复现的抓包取证一上来就抓包是新手最容易犯的错。一个园区几十台接入交换机你不可能每台都插电脑就算插了抓到的几个 G 文件里 99% 是正常业务看一天也看不出问题。所以真正的第一步不是开 Wireshark而是把“哪台设备、哪个端口、哪个 VLAN”圈到一个足够小的范围里让后面每一次抓包都有明确目标。这一段讲的就是怎么圈、圈到什么程度、以及圈完之后现场要准备什么。2.1 先给“异常”定三档判据空载端口不是 0 kbps。SNMP 轮询、STP BPDU、LLDP 邻居通告、ARP 老化探测、无线 AP 与 AC 之间的控制报文这些都在持续跑所以一个健康的空载口稳定在 200 kbps 上下很正常。判断异常不能看“有没有流量”而要看“偏离基线多少、持续了多久、是不是同 VLAN 一起涨”。我一般按三档处理档位端口平均速率持续时间处置动作正常基线 ±30%空载口约 150–300 kbps常规巡检周期内记录基线不动观察500–2000 kbps连续 3 个采样周期约 15 分钟查同 VLAN 其他端口是否同步上涨取证超过 2000 kbps或全 VLAN 同步上涨持续 10 分钟以上配置镜像抓包取证采样点要选对接入端口看单终端上联口看整个弱电间AC 侧看无线隧道。网管系统 5 分钟粒度采集一次就够了不用上秒级秒级数据量太大反而看不出趋势。基线也不是拍脑袋定的是拿过去两周同一时段的平均值算出来的接入端口按“工作日白天”和“夜间”分开统计否则白天正常业务一上来基线本身就失真了。提示判据里的数字不是死标准是按自己网络的实际情况调的。启用 SNMP 与 LLDP 的环境空载基线会比不启用时高一截拿别人的阈值套自己的网第一天就会误报。2.2 四段式链路发现、圈定、取证、定责把整个过程拆成四段每段有明确的输入和输出责任清晰事后也能复盘。第一段是发现。来源可以是巡检脚本、网管告警也可以是用户反馈“某个教室网卡”。输出是一条线索某 VLAN、某台 POE 交换机、某个端口速率异常。这一步不要试图下结论只记录现象。第二段是圈定。拿着 VLAN 号去交换机上找同 VLAN 的 POE 端口挑一个最靠近可疑终端的接入口作为镜像源。选口的原则是“离终端越近越好”接入端口流量小、噪音少抓到几百兆就足够看出问题直接抓核心上联几十 G 的流量打过来笔记本网卡先扛不住。第三段是取证。配置镜像、接抓包机、跑 Wireshark输出一个 pcap 文件加一份初步统计。这一段的核心要求是可复现同一个源口、同样的过滤条件换个人来抓也应该得到同样的结论。第四段是定责。看抓到的包里异常流量的源 IP内网地址就走“MAC 表 LLDP 逐跳回溯”或“AC 用户管理反查”这两条路外网地址就走防火墙 NAT 映射那条路。两条分支的处理方式完全不同混在一起讨论只会浪费时间。2.3 抓包点的选择接入口、上联口还是核心口同一个故障抓包点选错工作量能差十倍。三种位置的取舍我整理成了下面这张表实际排障时按这张表对着选就行。抓包点能看到什么丢包风险适用场景接入交换机接入口AP 口该 AP 下挂的所有终端流量低端口速率通常百兆以内已知异常集中在某个 AP 或某间教室POE 交换机上联口整个弱电间的所有终端中高峰期可能过载只知道 VLAN不知道具体房间核心交换机下联口整栋楼甚至全网的聚合流量高镜像口很容易被打满全网性异常需要看总体分布镜像口被打满是很现实的问题。笔记本千兆网卡实际能稳定接收的镜像流量也就七八百兆核心口一镜像Wireshark 直接报“dropped packets”你以为的“流量不大”其实是丢包后的假象。所以我一般从接入层抓起确认了协议特征和源 IP 之后再决定要不要往上层扩。2.4 现场准备与变更边界抓包机的准备经常被忽略但翻车往往就出在这。机器要有线网卡直连镜像口关掉网卡的节能和休眠磁盘至少留 20 GB 空间Wireshark 用当前稳定版即可不必追新。时间一定要和交换机对齐交换机配了 NTP抓包机也配同一源否则抓包时间和交换机日志差几分钟事后对不上事件这份证据就废了一半。变更本身要走流程配置前先留底把回滚命令写在记事本上。我习惯在动手前跑三条命令确认现状# 变更前留底确认当前有没有镜像会话、目的口跑的是什么业务 show running-config | include monitor show running-config interface gigabitEthernet 0/24 show interfaces status | include 0/24 # 变更后回滚用提前写下来别等出事再翻手册 # no monitor session 1 # ip verify source port-security # arp-check参数说明show running-config | include monitor用来确认没有历史镜像会话残留避免 session 编号冲突show running-config interface看目的口下有没有业务配置如果这个口还挂着 VLAN 或接了终端得先跟使用方确认能不能动show interfaces status看端口 up/down 和速率避免选了一个本身就是 down 的口做目的口。回滚命令里的三条按顺序执行先拆镜像会话再恢复端口安全顺序反了会短暂出现安全策略空窗。3. 端口镜像落地源口、目的口与端口安全策略的处理镜像配置本身只有几行命令但它前面有一个几乎所有人都会踩的坑端口安全策略。这层策略在正常转发时是保护在镜像场景下就变成干扰源它会把镜像进来的、不是从本口学到的 MAC 和 IP 判为非法直接丢掉。结果就是镜像配置看着成功抓包机上却只有广播包让人怀疑人生。3.1 为什么镜像前必须先关两项安全校验接入交换机上通常启用了 IP Source Guard 和 ARP Check 这类端口安全功能原理是维护一张“本端口允许的 IP-MAC 绑定表”进来的报文对不上表就丢。镜像口的特殊性在于它收到的报文源 MAC 根本不属于这个端口绑定表里当然查不到于是一律被丢弃。抓包机看到的现象是链路是 up 的Wireshark 有少量报文但就是看不到业务流量。处理方式是关掉目的口上的这两项校验。被镜像的源口一般不用动它的转发逻辑没变关了反而增加风险。不同品牌交换机的命令不一样下面这套是本次项目所用设备的形式换个品牌要先查手册命令名可能差一两个字含义基本相同# 关闭目的口上的 IP 源防护与 ARP 校验避免镜像流量被安全策略丢弃 no ip verify source port-security no arp-check # 建立镜像会话源口 1接 AP目的口 24接抓包笔记本 # both 表示收发双向都镜像只关心终端上行时可改成 ingress monitor session 1 source interface gigabitEthernet 0/1 both monitor session 1 destination interface gigabitEthernet 0/24 switch # 确认镜像会话建立结果 show monitor show monitor session 1逐段说明一下参数。no ip verify source port-security关闭的是 IP 源防护no arp-check关闭的是 ARP 合法性检查两条都在目的口下执行执行完端口会短暂 down 再 up属于正常现象。monitor session 1里的 1 是会话编号多数设备支持 1 到 4如果编号已被占用换成 2 或 3 即可不要硬删别人的会话。source interface ... both指定被镜像口both是收发双向只想看终端往外发的可疑流量可以用ingress流量能少一半。destination interface ... switch里的switch关键字表示这个口只做镜像输出、不参与正常转发漏掉这个关键字部分型号会报错或者行为不符合预期。3.2 源口与目的口的对应关系要写清楚现场最容易乱的环节是“哪个口对哪个口”。我的做法是在配置前先写一行备注24 口是目的口插抓包机1 口是源口原来接 AP不动。这样即使是两个人配合也不会出现“拔了 AP 插电脑”这种事故。目的口选空闲口优先如果实在没有空闲口就挑一个业务量最小的口并且提前通知使用方因为这个口在镜像期间不能正常转发业务。配置片段含义现场调整方式session 1镜像会话编号编号冲突时换 2/3/4source interface ... both被镜像的源口双向只看上行改ingressdestination ... switch镜像输出口不转发业务必须带switch关键字no ip verify source port-security关闭 IP 源防护目的口下执行no arp-check关闭 ARP 校验目的口下执行3.3 三条命令确认镜像是否真的生效配置敲完不等于通了。先执行show monitor输出里会列出会话编号、源口、目的口和方向四项都对上才算配置正确。再执行show monitor session 1看会话状态是不是 active。最后回到抓包机打开 Wireshark 的接口列表看对应网卡的实时流量曲线如果曲线是一条平线说明镜像没生效或者网线没插好如果曲线有小幅波动先抓 30 秒看看是不是只有广播和多播只有广播通常意味着端口安全没关干净。注意确认镜像生效之前不要急着开始长时间抓包。方向错了、口选错了抓下来的文件全是无用数据后面分析的时间全部白费。3.4 回滚与变更记录抓包结束就拆镜像不要留到“下次再说”。残留的镜像会话会持续把源口流量复制到目的口既浪费背板带宽也让下一个接手的人搞不清这个口在干什么。回滚顺序是先no monitor session 1拆会话再恢复端口安全的ip verify source port-security和arp-check最后用show running-config | include monitor确认干净。变更记录里写清时间、设备、端口、配置前后的差异、执行人这份记录在事后复盘和答辩时比抓包文件还好用因为它能证明每一步动作都是有依据的。4. 抓包分析与定位处置SSDP 泛洪识别、MAC 逐跳回溯与 AC 侧确认pcap 文件拿到手很多人第一反应是往下滚一屏一屏地看。几万个包滚完眼睛花了结论还是没有。正确的顺序是先看统计、再看协议、最后才看单包。统计能告诉你“谁在说话、说了多少”协议能告诉你“说的是什么”单包只是在需要取证的时候拿出来给人看的那一张截图。4.1 打开文件先看三张图第一张是协议分层统计Wireshark 菜单里的 Protocol Hierarchy它能一眼看出哪个协议占了绝大多数字节。正常网络的协议分布是分散的TCP、UDP、ARP、TLS 各占一块异常流量往往表现为某一个协议畸高比如 UDP 占到 80% 以上。第二张是会话统计Statistics 里的 Conversations切到 UDP 或 TCP 标签按字节数或包数排序。排在第一位的那个 IP如果它的流量比第二名高出一个数量级基本就是嫌疑对象。这一步是整段分析里性价比最高的操作三十秒内就能把范围从“几万个包”缩到“一个 IP”。第三张是 I/O 图看流量随时间的变化曲线。正常业务有波峰波谷跟上下课、作息对得上攻击流量通常是一条持续的高位直线或者规律的锯齿。曲线形状能帮你判断这是人為行为还是程序在跑。4.2 SSDP 泛洪长什么样本次案例最终定位到的是基于 SSDP 协议的异常流量。SSDP 是设备发现协议跑在 UDP 1900 端口目的地址是组播地址 239.255.255.250正常场景下终端每分钟发几个包做服务通告量极小。被恶意程序利用之后同一台设备会以每秒几十甚至几百包的频率持续发送端口流量自然就顶上去了。判断特征我总结了四条源 IP 高度集中往往就一个目的地址固定在组播段包长集中在 130 到 400 字节之间且长度分布很窄单位时间内包数量级异常。四条里中三条基本可以定性。用显示过滤器能快速验证# 只看 SSDP 流量确认目的地址与端口 udp.port 1900 # 锁定嫌疑源 IP 之后单独看它发了多少 ip.src 10.20.30.44 udp.port 1900 # 排除 ARP、DHCP 等噪音看剩下的有效业务流量 !(arp || icmp || udp.port 67 || udp.port 68) # 按包长筛SSDP 通告包多集中在这个区间 frame.len 130 frame.len 400过滤器写完之后配合 Statistics 里的“应用为过滤器”功能能直接看到命中包数和字节数比手工数靠谱。我一般的判定口径是单个源 IP 的 SSDP 包数占该时间段总包数的 60% 以上且持续超过 5 分钟就按异常处理不用再纠结“是不是正常设备在发现服务”。观察项正常表现异常表现源 IP 数量多个终端分散发送集中在一到两个 IP发送频率每分钟个位数每秒数十到数百目的地址组播地址偶有单播响应固定组播无响应交互包长分布长短混杂集中在窄区间4.3 内网源 IPMAC 表加 LLDP 逐跳回溯确认是内网地址之后下一步是找到这台设备接在哪个物理端口。路径是从核心往下逐跳查每一跳用两条命令。先在核心交换机上按 MAC 后几位查 MAC 地址表拿到下行端口# 按 MAC 地址后几位模糊匹配拿到下联端口 show mac-address-table | include 3c2e # 查看该端口的 LLDP 邻居拿到下一跳设备的管理地址 show lldp neighbors # 登录下一跳设备后重复同样的查询直到接入层 show mac-address-table | include 3c2e show interfaces status | include Gi0/20参数说明include后面跟 MAC 的后三到四位就够全填反而容易因为格式差异匹配不上show lldp neighbors输出里重点看对端设备名和管理地址这就是下一跳要登录的设备到了接入层之后MAC 表里对应的端口就是终端实际插的那个口再配合配线架编号和房间信息就能找到物理位置。这条路径的可靠性最高但耗时也最长一层一层登录过去熟练的话十五到二十分钟。紧急情况下有更快的办法直接在核心或接入层把该 MAC 加入黑名单先断网止血网络恢复正常之后再慢慢找设备。4.4 AC 侧反查用户管理里按 IP 找 MAC 和所连 AP本次故障的设备接在无线网络上所以走了一条更快的路。无线控制器AC的用户管理页面能按 IP 直接搜到在线用户输出里带 MAC 地址和所关联的 AP 名称AP 名称本身通常就编码了楼栋和房间信息。整个过程不到两分钟比逐跳查交换机快得多。这条路有一个前提AC 上的 AP 位置台账必须是实时维护的。本次项目里这份台账是随施工同步更新的所以能直接指导现场找到设备如果台账是两年前的搜出来的 AP 名称对不上实际位置反而会把方向带偏。所以我的建议是AC 反查优先用但用完要去现场核对别把台账当唯一依据。定位手段适用条件耗时主要依赖核心 MAC 表 LLDP 逐跳有线、无线均可15–20 分钟各层设备可登录AC 用户管理反查无线终端在线2–5 分钟AP 位置台账准确MAC 黑名单临时隔离紧急止血1 分钟无需定位4.5 两类处置路径内网修复与外网映射切换内网源的处置相对直接。能到现场就断网处理本次案例里那台设备是教室一体机断网后重装系统再接入网络复测异常报文消失。不方便到现场或者情况紧急就先在交换机上按 MAC 禁用该设备联网等业务空闲时再处理。禁用只是止血不是修复这一点要在记录里写清楚避免过几天被人当成“已解决”归档。外网源的处置逻辑不一样。先在防火墙上看 NAT 映射表确认被抓包里的目的端口对应的是哪条映射规则然后把这个映射切到另一个端口。如果切换之后新端口很快又被扫到说明对方在做端口段扫描这时候再上报给线路服务方协助溯源同时把对外地址切换到备用地址。整个过程的关键是“先切端口再上报”顺序反了攻击流量还在打溯源信息也被冲淡了。5. 常见问题与排查镜像、抓包、定位三个环节的翻车点这套流程走下来配置命令其实只占十分钟剩下的时间都花在“为什么没效果”上。下面这几条是实际项目里出现频率最高的每条按现象、原因、解决三步写遇到时对着查。5.1 镜像配了但抓不到业务流量现象show monitor显示会话已建立抓包机网卡也有流量但 Wireshark 里只有零星广播包看不到终端的 TCP 流量I/O 图几乎是平的。原因目的口的端口安全策略没有关闭。IP 源防护和 ARP 校验会把镜像进来的、绑定表里查不到的报文直接丢弃配置看起来全对实际数据在进入抓包机之前就被交换机扔了。解决回到目的口下执行no ip verify source port-security和no arp-check再抓 30 秒验证。如果还是只有广播检查源口是不是选错了——把上联口当成了接入口或者源口本身处于 down 状态。配置完之后show interfaces status看一眼端口的 up/down 和速率比反复猜快。5.2 镜像生效后网络反而更卡现象配完镜像本来只是某个端口慢结果整个弱电间的用户开始反馈卡顿网管上该交换机 CPU 也上去了。原因目的口本身还在承载业务。镜像流量是复制出来的额外流量如果目的口同时还挂着 VLAN、接终端这部分流量会和镜像流量抢带宽端口直接打满。另一个常见原因是源口选在了上联口整个弱电间的流量被复制一份交换机背板压力翻倍。解决目的口必须选纯空闲口配置前用show running-config interface确认这个口下没有业务配置源口优先选接入口不要图省事直接镜像上联。已经配错的立刻no monitor session 1拆掉等业务低峰期重配。5.3 抓包文件只单向、时间还和日志对不上现象抓到的包里只有终端发出去的请求看不到回应或者排查时想把抓包时间和交换机日志对上发现差了七八分钟完全对不上事件顺序。原因单向多半是源口方向写成了ingress只镜像了入向流量也可能是抓包机网卡工作在半双工或者镜像会话里的方向参数没生效。时间对不上则是抓包机没有配 NTP长期运行累积漂移再加上时区设置不一致。解决源口方向改成both抓包机网卡强制全双工千兆抓包前确认抓包机和交换机指向同一个时间源Wireshark 里把时间显示格式统一成本地时间。这一步花两分钟能省掉事后几小时的对照工作。5.4 MAC 表里查不到那台设备现象抓包已经确认了异常 MAC但在核心交换机上show mac-address-table | include查不到或者查到的端口和预期完全不符。原因MAC 表有老化时间通常 300 秒终端休眠、无线漫游、重新关联都会让表项消失或漂移另外核心交换机是三层转发跨网段流量的源 MAC 已经被改写成网关 MAC拿终端的 MAC 去核心查当然查不到。解决把查询点下移到接入层在离终端最近的交换机上查命中率最高无线终端优先走 AC 用户管理反查不要死磕交换机 MAC 表。查的时候用 MAC 后三到四位做模糊匹配全地址经常因为分隔符格式差异匹配失败。5.5 按 AC 台账找到位置现场却没有设备现象AC 上显示这台设备关联在某 AP 下按名称找到房间进去发现那台设备根本不在或者已经换了位置。原因AP 位置台账没有随施工更新设备迁移、房间调整之后没同步也可能是无线终端漫游AC 显示的关联 AP 是最近一次信号最强的那个不一定是物理上最近的那个。解决把 AC 反查结果当作“缩小范围”而不是“最终答案”同时用交换机侧的 MAC 表交叉验证一次台账要求随工更新做不到实时更新的话就在处置记录里注明“依据某年某月台账”后续再校准。紧急情况下先用 MAC 黑名单止血定位可以慢慢做。6. 验收与复盘流量回落口径、证据链归档与讲解顺序处置做完不等于结束判断“真的好了”需要一组可量化的指标而不是“用户说不卡了”。我一般看四个数异常端口的平均速率是否回落到基线 ±10% 以内抓包复测时 SSDP 或对应异常协议的包数占比是否降到 1% 以下同一源 IP 在 10 分钟复测窗口内是否还有高频发送交换机 CPU 和 AC 在线用户数是否回到正常区间。四个数里有一个不达标就说明处置不彻底可能还有第二台设备在发同样的报文。验收项采集方式合格标准端口平均速率网管 5 分钟粒度取处置后 30 分钟均值回落至基线 ±10%异常协议占比复测抓包Protocol Hierarchy 统计低于 1%同源高频发送复测抓包按源 IP 排序10 分钟内无持续高频设备负载交换机 CPU、AC 在线数回到故障前水平复测抓包不要省。本次案例里重装系统后重新镜像抓了一次SSDP 报文基本消失端口流量从 5000 多 kbps 降到 400 多 kbps。这里有个细节值得说400 kbps 不是绝对标准因为这个环境启用了 SNMP 等管理协议空载基线本身就在 400 左右如果是不启用这些协议的环境正常值应该更低接近 200 kbps 甚至更低。拿别人的回落值当自己的验收线很容易误判成“还没修好”。证据链的归档顺序也直接决定了事后讲解能不能讲清楚。我的习惯是按时间线排先是巡检发现流量异常的截图和基线数据然后是镜像配置前后的show monitor输出接着是抓包文件的统计截图和关键过滤器命中结果再往后是定位路径MAC 表查询结果、LLDP 邻居、AC 用户信息最后是处置动作和复测数据。这条线摆出来任何一个没参与过的人都能顺着走一遍不需要你在旁边解释。答辩或者内部复盘时讲解顺序建议反过来讲先给结论——哪个端口、什么协议、多少流量、怎么处置、复测多少再回头讲你是怎么从 5000 kbps 一步步缩到那台设备的。听众的注意力在前三分钟先给结果他们才愿意听过程。中间讲技术细节时重点讲判断依据而不是命令本身比如“为什么判 SSDP 而不是普通组播”“为什么先查接入层而不是核心”这些才是能体现思路的地方。命令谁都能查手册判据是踩过坑才有的。从那以后我每次配镜像之前都强制走一遍备份配置、写下回滚命令、确认目的口是空闲口、确认抓包机和交换机时间同源。这四步花不到五分钟但能挡掉后面八成的返工。希望帮到你。本文还有配套的精品资源点击获取
简介这是一份面向网络运维与故障排查人员的实战案例文档围绕Wireshark抓包处理网络故障展开重点解决VLAN内端口流量突增、AP空载却出现大量数据包等异常场景。资源包共1个docx文件大小385KB内容以锐捷交换机为案例梳理AC巡检发现无线网段流量异常、POE交换机镜像端口配置、关闭端口安全策略、monitor session建立与show monitor验证等前置操作。文档进一步说明如何用Wireshark分析抓包文件区分内网与外网异常IP并通过核心交换机、AC查询MAC地址和接入层端口定位异常终端或映射端口。文中还记录了SSDP协议攻击导致端口流量升高的排查与恢复对比可帮助读者把抓包现象对应到设备命令、故障位置和处置步骤。已有1550人学习适合需要提升网络故障定位能力的中初级运维人员参考。1. 空载端口跑到 5000 kbps为什么先抓包再动手园区网里最容易被忽略的故障不是断网而是“没断但很忙”。某次巡检我发现一台接入交换机上接 AP 的端口平时空载只有 200 多 kbps那天涨到 5000 kbps 以上而且所有无线网段所在的 VLAN 在同步上涨。用 Wireshark 抓包处理网络故障的价值就在这它不猜它把链路上真实跑的东西摊在你面前。这套流程针对的是“端口流量异常、业务却没明显中断”这一类问题从流量基线判定、交换机端口镜像、抓包取证一路走到用 MAC 地址表和无线控制器把异常设备定位到某个房间的具体端口。做网络运维的可以直接照搬做网络故障排查类毕设、课设的也能按这个结构搭自己的方案。2. 排查链路设计从流量异常到可复现的抓包取证一上来就抓包是新手最容易犯的错。一个园区几十台接入交换机你不可能每台都插电脑就算插了抓到的几个 G 文件里 99% 是正常业务看一天也看不出问题。所以真正的第一步不是开 Wireshark而是把“哪台设备、哪个端口、哪个 VLAN”圈到一个足够小的范围里让后面每一次抓包都有明确目标。这一段讲的就是怎么圈、圈到什么程度、以及圈完之后现场要准备什么。2.1 先给“异常”定三档判据空载端口不是 0 kbps。SNMP 轮询、STP BPDU、LLDP 邻居通告、ARP 老化探测、无线 AP 与 AC 之间的控制报文这些都在持续跑所以一个健康的空载口稳定在 200 kbps 上下很正常。判断异常不能看“有没有流量”而要看“偏离基线多少、持续了多久、是不是同 VLAN 一起涨”。我一般按三档处理档位端口平均速率持续时间处置动作正常基线 ±30%空载口约 150–300 kbps常规巡检周期内记录基线不动观察500–2000 kbps连续 3 个采样周期约 15 分钟查同 VLAN 其他端口是否同步上涨取证超过 2000 kbps或全 VLAN 同步上涨持续 10 分钟以上配置镜像抓包取证采样点要选对接入端口看单终端上联口看整个弱电间AC 侧看无线隧道。网管系统 5 分钟粒度采集一次就够了不用上秒级秒级数据量太大反而看不出趋势。基线也不是拍脑袋定的是拿过去两周同一时段的平均值算出来的接入端口按“工作日白天”和“夜间”分开统计否则白天正常业务一上来基线本身就失真了。提示判据里的数字不是死标准是按自己网络的实际情况调的。启用 SNMP 与 LLDP 的环境空载基线会比不启用时高一截拿别人的阈值套自己的网第一天就会误报。2.2 四段式链路发现、圈定、取证、定责把整个过程拆成四段每段有明确的输入和输出责任清晰事后也能复盘。第一段是发现。来源可以是巡检脚本、网管告警也可以是用户反馈“某个教室网卡”。输出是一条线索某 VLAN、某台 POE 交换机、某个端口速率异常。这一步不要试图下结论只记录现象。第二段是圈定。拿着 VLAN 号去交换机上找同 VLAN 的 POE 端口挑一个最靠近可疑终端的接入口作为镜像源。选口的原则是“离终端越近越好”接入端口流量小、噪音少抓到几百兆就足够看出问题直接抓核心上联几十 G 的流量打过来笔记本网卡先扛不住。第三段是取证。配置镜像、接抓包机、跑 Wireshark输出一个 pcap 文件加一份初步统计。这一段的核心要求是可复现同一个源口、同样的过滤条件换个人来抓也应该得到同样的结论。第四段是定责。看抓到的包里异常流量的源 IP内网地址就走“MAC 表 LLDP 逐跳回溯”或“AC 用户管理反查”这两条路外网地址就走防火墙 NAT 映射那条路。两条分支的处理方式完全不同混在一起讨论只会浪费时间。2.3 抓包点的选择接入口、上联口还是核心口同一个故障抓包点选错工作量能差十倍。三种位置的取舍我整理成了下面这张表实际排障时按这张表对着选就行。抓包点能看到什么丢包风险适用场景接入交换机接入口AP 口该 AP 下挂的所有终端流量低端口速率通常百兆以内已知异常集中在某个 AP 或某间教室POE 交换机上联口整个弱电间的所有终端中高峰期可能过载只知道 VLAN不知道具体房间核心交换机下联口整栋楼甚至全网的聚合流量高镜像口很容易被打满全网性异常需要看总体分布镜像口被打满是很现实的问题。笔记本千兆网卡实际能稳定接收的镜像流量也就七八百兆核心口一镜像Wireshark 直接报“dropped packets”你以为的“流量不大”其实是丢包后的假象。所以我一般从接入层抓起确认了协议特征和源 IP 之后再决定要不要往上层扩。2.4 现场准备与变更边界抓包机的准备经常被忽略但翻车往往就出在这。机器要有线网卡直连镜像口关掉网卡的节能和休眠磁盘至少留 20 GB 空间Wireshark 用当前稳定版即可不必追新。时间一定要和交换机对齐交换机配了 NTP抓包机也配同一源否则抓包时间和交换机日志差几分钟事后对不上事件这份证据就废了一半。变更本身要走流程配置前先留底把回滚命令写在记事本上。我习惯在动手前跑三条命令确认现状# 变更前留底确认当前有没有镜像会话、目的口跑的是什么业务 show running-config | include monitor show running-config interface gigabitEthernet 0/24 show interfaces status | include 0/24 # 变更后回滚用提前写下来别等出事再翻手册 # no monitor session 1 # ip verify source port-security # arp-check参数说明show running-config | include monitor用来确认没有历史镜像会话残留避免 session 编号冲突show running-config interface看目的口下有没有业务配置如果这个口还挂着 VLAN 或接了终端得先跟使用方确认能不能动show interfaces status看端口 up/down 和速率避免选了一个本身就是 down 的口做目的口。回滚命令里的三条按顺序执行先拆镜像会话再恢复端口安全顺序反了会短暂出现安全策略空窗。3. 端口镜像落地源口、目的口与端口安全策略的处理镜像配置本身只有几行命令但它前面有一个几乎所有人都会踩的坑端口安全策略。这层策略在正常转发时是保护在镜像场景下就变成干扰源它会把镜像进来的、不是从本口学到的 MAC 和 IP 判为非法直接丢掉。结果就是镜像配置看着成功抓包机上却只有广播包让人怀疑人生。3.1 为什么镜像前必须先关两项安全校验接入交换机上通常启用了 IP Source Guard 和 ARP Check 这类端口安全功能原理是维护一张“本端口允许的 IP-MAC 绑定表”进来的报文对不上表就丢。镜像口的特殊性在于它收到的报文源 MAC 根本不属于这个端口绑定表里当然查不到于是一律被丢弃。抓包机看到的现象是链路是 up 的Wireshark 有少量报文但就是看不到业务流量。处理方式是关掉目的口上的这两项校验。被镜像的源口一般不用动它的转发逻辑没变关了反而增加风险。不同品牌交换机的命令不一样下面这套是本次项目所用设备的形式换个品牌要先查手册命令名可能差一两个字含义基本相同# 关闭目的口上的 IP 源防护与 ARP 校验避免镜像流量被安全策略丢弃 no ip verify source port-security no arp-check # 建立镜像会话源口 1接 AP目的口 24接抓包笔记本 # both 表示收发双向都镜像只关心终端上行时可改成 ingress monitor session 1 source interface gigabitEthernet 0/1 both monitor session 1 destination interface gigabitEthernet 0/24 switch # 确认镜像会话建立结果 show monitor show monitor session 1逐段说明一下参数。no ip verify source port-security关闭的是 IP 源防护no arp-check关闭的是 ARP 合法性检查两条都在目的口下执行执行完端口会短暂 down 再 up属于正常现象。monitor session 1里的 1 是会话编号多数设备支持 1 到 4如果编号已被占用换成 2 或 3 即可不要硬删别人的会话。source interface ... both指定被镜像口both是收发双向只想看终端往外发的可疑流量可以用ingress流量能少一半。destination interface ... switch里的switch关键字表示这个口只做镜像输出、不参与正常转发漏掉这个关键字部分型号会报错或者行为不符合预期。3.2 源口与目的口的对应关系要写清楚现场最容易乱的环节是“哪个口对哪个口”。我的做法是在配置前先写一行备注24 口是目的口插抓包机1 口是源口原来接 AP不动。这样即使是两个人配合也不会出现“拔了 AP 插电脑”这种事故。目的口选空闲口优先如果实在没有空闲口就挑一个业务量最小的口并且提前通知使用方因为这个口在镜像期间不能正常转发业务。配置片段含义现场调整方式session 1镜像会话编号编号冲突时换 2/3/4source interface ... both被镜像的源口双向只看上行改ingressdestination ... switch镜像输出口不转发业务必须带switch关键字no ip verify source port-security关闭 IP 源防护目的口下执行no arp-check关闭 ARP 校验目的口下执行3.3 三条命令确认镜像是否真的生效配置敲完不等于通了。先执行show monitor输出里会列出会话编号、源口、目的口和方向四项都对上才算配置正确。再执行show monitor session 1看会话状态是不是 active。最后回到抓包机打开 Wireshark 的接口列表看对应网卡的实时流量曲线如果曲线是一条平线说明镜像没生效或者网线没插好如果曲线有小幅波动先抓 30 秒看看是不是只有广播和多播只有广播通常意味着端口安全没关干净。注意确认镜像生效之前不要急着开始长时间抓包。方向错了、口选错了抓下来的文件全是无用数据后面分析的时间全部白费。3.4 回滚与变更记录抓包结束就拆镜像不要留到“下次再说”。残留的镜像会话会持续把源口流量复制到目的口既浪费背板带宽也让下一个接手的人搞不清这个口在干什么。回滚顺序是先no monitor session 1拆会话再恢复端口安全的ip verify source port-security和arp-check最后用show running-config | include monitor确认干净。变更记录里写清时间、设备、端口、配置前后的差异、执行人这份记录在事后复盘和答辩时比抓包文件还好用因为它能证明每一步动作都是有依据的。4. 抓包分析与定位处置SSDP 泛洪识别、MAC 逐跳回溯与 AC 侧确认pcap 文件拿到手很多人第一反应是往下滚一屏一屏地看。几万个包滚完眼睛花了结论还是没有。正确的顺序是先看统计、再看协议、最后才看单包。统计能告诉你“谁在说话、说了多少”协议能告诉你“说的是什么”单包只是在需要取证的时候拿出来给人看的那一张截图。4.1 打开文件先看三张图第一张是协议分层统计Wireshark 菜单里的 Protocol Hierarchy它能一眼看出哪个协议占了绝大多数字节。正常网络的协议分布是分散的TCP、UDP、ARP、TLS 各占一块异常流量往往表现为某一个协议畸高比如 UDP 占到 80% 以上。第二张是会话统计Statistics 里的 Conversations切到 UDP 或 TCP 标签按字节数或包数排序。排在第一位的那个 IP如果它的流量比第二名高出一个数量级基本就是嫌疑对象。这一步是整段分析里性价比最高的操作三十秒内就能把范围从“几万个包”缩到“一个 IP”。第三张是 I/O 图看流量随时间的变化曲线。正常业务有波峰波谷跟上下课、作息对得上攻击流量通常是一条持续的高位直线或者规律的锯齿。曲线形状能帮你判断这是人為行为还是程序在跑。4.2 SSDP 泛洪长什么样本次案例最终定位到的是基于 SSDP 协议的异常流量。SSDP 是设备发现协议跑在 UDP 1900 端口目的地址是组播地址 239.255.255.250正常场景下终端每分钟发几个包做服务通告量极小。被恶意程序利用之后同一台设备会以每秒几十甚至几百包的频率持续发送端口流量自然就顶上去了。判断特征我总结了四条源 IP 高度集中往往就一个目的地址固定在组播段包长集中在 130 到 400 字节之间且长度分布很窄单位时间内包数量级异常。四条里中三条基本可以定性。用显示过滤器能快速验证# 只看 SSDP 流量确认目的地址与端口 udp.port 1900 # 锁定嫌疑源 IP 之后单独看它发了多少 ip.src 10.20.30.44 udp.port 1900 # 排除 ARP、DHCP 等噪音看剩下的有效业务流量 !(arp || icmp || udp.port 67 || udp.port 68) # 按包长筛SSDP 通告包多集中在这个区间 frame.len 130 frame.len 400过滤器写完之后配合 Statistics 里的“应用为过滤器”功能能直接看到命中包数和字节数比手工数靠谱。我一般的判定口径是单个源 IP 的 SSDP 包数占该时间段总包数的 60% 以上且持续超过 5 分钟就按异常处理不用再纠结“是不是正常设备在发现服务”。观察项正常表现异常表现源 IP 数量多个终端分散发送集中在一到两个 IP发送频率每分钟个位数每秒数十到数百目的地址组播地址偶有单播响应固定组播无响应交互包长分布长短混杂集中在窄区间4.3 内网源 IPMAC 表加 LLDP 逐跳回溯确认是内网地址之后下一步是找到这台设备接在哪个物理端口。路径是从核心往下逐跳查每一跳用两条命令。先在核心交换机上按 MAC 后几位查 MAC 地址表拿到下行端口# 按 MAC 地址后几位模糊匹配拿到下联端口 show mac-address-table | include 3c2e # 查看该端口的 LLDP 邻居拿到下一跳设备的管理地址 show lldp neighbors # 登录下一跳设备后重复同样的查询直到接入层 show mac-address-table | include 3c2e show interfaces status | include Gi0/20参数说明include后面跟 MAC 的后三到四位就够全填反而容易因为格式差异匹配不上show lldp neighbors输出里重点看对端设备名和管理地址这就是下一跳要登录的设备到了接入层之后MAC 表里对应的端口就是终端实际插的那个口再配合配线架编号和房间信息就能找到物理位置。这条路径的可靠性最高但耗时也最长一层一层登录过去熟练的话十五到二十分钟。紧急情况下有更快的办法直接在核心或接入层把该 MAC 加入黑名单先断网止血网络恢复正常之后再慢慢找设备。4.4 AC 侧反查用户管理里按 IP 找 MAC 和所连 AP本次故障的设备接在无线网络上所以走了一条更快的路。无线控制器AC的用户管理页面能按 IP 直接搜到在线用户输出里带 MAC 地址和所关联的 AP 名称AP 名称本身通常就编码了楼栋和房间信息。整个过程不到两分钟比逐跳查交换机快得多。这条路有一个前提AC 上的 AP 位置台账必须是实时维护的。本次项目里这份台账是随施工同步更新的所以能直接指导现场找到设备如果台账是两年前的搜出来的 AP 名称对不上实际位置反而会把方向带偏。所以我的建议是AC 反查优先用但用完要去现场核对别把台账当唯一依据。定位手段适用条件耗时主要依赖核心 MAC 表 LLDP 逐跳有线、无线均可15–20 分钟各层设备可登录AC 用户管理反查无线终端在线2–5 分钟AP 位置台账准确MAC 黑名单临时隔离紧急止血1 分钟无需定位4.5 两类处置路径内网修复与外网映射切换内网源的处置相对直接。能到现场就断网处理本次案例里那台设备是教室一体机断网后重装系统再接入网络复测异常报文消失。不方便到现场或者情况紧急就先在交换机上按 MAC 禁用该设备联网等业务空闲时再处理。禁用只是止血不是修复这一点要在记录里写清楚避免过几天被人当成“已解决”归档。外网源的处置逻辑不一样。先在防火墙上看 NAT 映射表确认被抓包里的目的端口对应的是哪条映射规则然后把这个映射切到另一个端口。如果切换之后新端口很快又被扫到说明对方在做端口段扫描这时候再上报给线路服务方协助溯源同时把对外地址切换到备用地址。整个过程的关键是“先切端口再上报”顺序反了攻击流量还在打溯源信息也被冲淡了。5. 常见问题与排查镜像、抓包、定位三个环节的翻车点这套流程走下来配置命令其实只占十分钟剩下的时间都花在“为什么没效果”上。下面这几条是实际项目里出现频率最高的每条按现象、原因、解决三步写遇到时对着查。5.1 镜像配了但抓不到业务流量现象show monitor显示会话已建立抓包机网卡也有流量但 Wireshark 里只有零星广播包看不到终端的 TCP 流量I/O 图几乎是平的。原因目的口的端口安全策略没有关闭。IP 源防护和 ARP 校验会把镜像进来的、绑定表里查不到的报文直接丢弃配置看起来全对实际数据在进入抓包机之前就被交换机扔了。解决回到目的口下执行no ip verify source port-security和no arp-check再抓 30 秒验证。如果还是只有广播检查源口是不是选错了——把上联口当成了接入口或者源口本身处于 down 状态。配置完之后show interfaces status看一眼端口的 up/down 和速率比反复猜快。5.2 镜像生效后网络反而更卡现象配完镜像本来只是某个端口慢结果整个弱电间的用户开始反馈卡顿网管上该交换机 CPU 也上去了。原因目的口本身还在承载业务。镜像流量是复制出来的额外流量如果目的口同时还挂着 VLAN、接终端这部分流量会和镜像流量抢带宽端口直接打满。另一个常见原因是源口选在了上联口整个弱电间的流量被复制一份交换机背板压力翻倍。解决目的口必须选纯空闲口配置前用show running-config interface确认这个口下没有业务配置源口优先选接入口不要图省事直接镜像上联。已经配错的立刻no monitor session 1拆掉等业务低峰期重配。5.3 抓包文件只单向、时间还和日志对不上现象抓到的包里只有终端发出去的请求看不到回应或者排查时想把抓包时间和交换机日志对上发现差了七八分钟完全对不上事件顺序。原因单向多半是源口方向写成了ingress只镜像了入向流量也可能是抓包机网卡工作在半双工或者镜像会话里的方向参数没生效。时间对不上则是抓包机没有配 NTP长期运行累积漂移再加上时区设置不一致。解决源口方向改成both抓包机网卡强制全双工千兆抓包前确认抓包机和交换机指向同一个时间源Wireshark 里把时间显示格式统一成本地时间。这一步花两分钟能省掉事后几小时的对照工作。5.4 MAC 表里查不到那台设备现象抓包已经确认了异常 MAC但在核心交换机上show mac-address-table | include查不到或者查到的端口和预期完全不符。原因MAC 表有老化时间通常 300 秒终端休眠、无线漫游、重新关联都会让表项消失或漂移另外核心交换机是三层转发跨网段流量的源 MAC 已经被改写成网关 MAC拿终端的 MAC 去核心查当然查不到。解决把查询点下移到接入层在离终端最近的交换机上查命中率最高无线终端优先走 AC 用户管理反查不要死磕交换机 MAC 表。查的时候用 MAC 后三到四位做模糊匹配全地址经常因为分隔符格式差异匹配失败。5.5 按 AC 台账找到位置现场却没有设备现象AC 上显示这台设备关联在某 AP 下按名称找到房间进去发现那台设备根本不在或者已经换了位置。原因AP 位置台账没有随施工更新设备迁移、房间调整之后没同步也可能是无线终端漫游AC 显示的关联 AP 是最近一次信号最强的那个不一定是物理上最近的那个。解决把 AC 反查结果当作“缩小范围”而不是“最终答案”同时用交换机侧的 MAC 表交叉验证一次台账要求随工更新做不到实时更新的话就在处置记录里注明“依据某年某月台账”后续再校准。紧急情况下先用 MAC 黑名单止血定位可以慢慢做。6. 验收与复盘流量回落口径、证据链归档与讲解顺序处置做完不等于结束判断“真的好了”需要一组可量化的指标而不是“用户说不卡了”。我一般看四个数异常端口的平均速率是否回落到基线 ±10% 以内抓包复测时 SSDP 或对应异常协议的包数占比是否降到 1% 以下同一源 IP 在 10 分钟复测窗口内是否还有高频发送交换机 CPU 和 AC 在线用户数是否回到正常区间。四个数里有一个不达标就说明处置不彻底可能还有第二台设备在发同样的报文。验收项采集方式合格标准端口平均速率网管 5 分钟粒度取处置后 30 分钟均值回落至基线 ±10%异常协议占比复测抓包Protocol Hierarchy 统计低于 1%同源高频发送复测抓包按源 IP 排序10 分钟内无持续高频设备负载交换机 CPU、AC 在线数回到故障前水平复测抓包不要省。本次案例里重装系统后重新镜像抓了一次SSDP 报文基本消失端口流量从 5000 多 kbps 降到 400 多 kbps。这里有个细节值得说400 kbps 不是绝对标准因为这个环境启用了 SNMP 等管理协议空载基线本身就在 400 左右如果是不启用这些协议的环境正常值应该更低接近 200 kbps 甚至更低。拿别人的回落值当自己的验收线很容易误判成“还没修好”。证据链的归档顺序也直接决定了事后讲解能不能讲清楚。我的习惯是按时间线排先是巡检发现流量异常的截图和基线数据然后是镜像配置前后的show monitor输出接着是抓包文件的统计截图和关键过滤器命中结果再往后是定位路径MAC 表查询结果、LLDP 邻居、AC 用户信息最后是处置动作和复测数据。这条线摆出来任何一个没参与过的人都能顺着走一遍不需要你在旁边解释。答辩或者内部复盘时讲解顺序建议反过来讲先给结论——哪个端口、什么协议、多少流量、怎么处置、复测多少再回头讲你是怎么从 5000 kbps 一步步缩到那台设备的。听众的注意力在前三分钟先给结果他们才愿意听过程。中间讲技术细节时重点讲判断依据而不是命令本身比如“为什么判 SSDP 而不是普通组播”“为什么先查接入层而不是核心”这些才是能体现思路的地方。命令谁都能查手册判据是踩过坑才有的。从那以后我每次配镜像之前都强制走一遍备份配置、写下回滚命令、确认目的口是空闲口、确认抓包机和交换机时间同源。这四步花不到五分钟但能挡掉后面八成的返工。希望帮到你。本文还有配套的精品资源点击获取
