企业官网建设流程全解析

简介：这份资源面向网络运维工程师与网络故障排查初学者，围绕Wireshark抓包定位并处理网络故障展开，属于实战案例型技术文档。内容以锐捷交换机为背景，涵盖VLAN端口流量异常、镜像端口配置、抓包文件分析、内外网IP攻击溯源等典型场景，帮助读者掌握从发现异常到定位终端、恢复网络的完整排错思路。资源包共1个docx文档，约385KB，篇幅紧凑，适合作为日常巡检与应急处理的参考手册。目前已有1548人学习下载，说明其在网络运维群体中具有一定认可度。文档中详细记录了关闭端口安全策略、配置镜像口、通过MAC地址在核心交换机与接入层逐级定位异常设备、借助AC管理页面查找无线用户位置等具体操作，并给出SSDP协议攻击导致端口流量飙升的真实案例与恢复验证数据，读者可据此对照自身网络环境复现排查流程，提升故障响应效率。

1. 空载端口突然跑满 5000Kbps：一次 SSDP 内网攻击的抓包定位

巡检时发现一个平时只有 200 多 Kbps 的空载端口，流量突然涨到好几千 Kbps，AC 上所有无线网段 VLAN 的包量也集体超过 5000Kbps，这种场景下 ping 和丢包率往往还正常，用户端甚至没投诉，但交换机背板和 AP 上行口已经在被无效流量持续冲刷。Wireshark 抓包在这里的价值不是"看协议长什么样"，而是把"哪个 IP、哪个 MAC、哪种协议在刷流量"这三件事从几千 Kbps 的噪声里钉死。这篇内容面向日常做园区网运维、需要独立定位异常流量的工程师，从交换机镜像口配置讲到抓包文件分析，再到用 MAC 反查接入端口，最后落到 SSDP 这类内网攻击的处置和复测。整套流程在锐捷交换机 + AC 管理平台的校园网环境里跑通过，换成华为、H3C 只是命令差异，思路一致。

2. 镜像口配置：把异常 VLAN 的流量引到抓包机

抓包的第一步不是打开 Wireshark，而是让交换机把你要看的流量复制一份出来。园区网里 AP 上行口、汇聚口通常都是 Trunk，直接在上面串一个 Hub 不现实，标准做法是配 SPAN（端口镜像）。锐捷的写法是monitor session，但配之前有个坑：端口安全策略会拦掉镜像流量，必须先关。

2.1 为什么先关端口安全再配镜像

被镜像口和镜像口上如果启用了 IP Source Guard 和 ARP Check，镜像复制出来的报文会因为源 IP/MAC 校验不通过被丢弃，抓包机看到的就是一片空白。所以配置顺序是：先no掉这两条，再建 session。

# 进入被镜像口和镜像口所在接口的配置上下文前，先全局关闭端口安全相关校验 no ip verify source port-security no arp-check # 建立镜像会话：session 1，源为 g0/1（接 AP 的口），双向抓 monitor session 1 source interface gigabitEthernet 0/1 both # 目的口为 g0/24，抓包机接这个口 monitor session 1 destination interface gigabitEthernet 0/24 switch

source interface ... both里的both表示同时镜像收和发两个方向，排查攻击流量时建议用both，只抓rx可能漏掉设备主动外发的探测包。destination ... switch表示目的口工作在交换模式，允许多个源口镜像到同一个目的口，如果只镜像一个口，去掉switch也行。配完用show monitor确认 session 状态是 up，源口和目的口都对得上。

2.2 抓包机的接入与网卡设置

抓包机用网线直连 g0/24，网卡不需要配 IP，也不需要网关，因为镜像口收到的是原始二层帧，配了 IP 反而可能因为 ARP 或 DHCP 报文混进抓包结果里干扰判断。网卡驱动建议用 Npcap，安装 Wireshark 时勾选即可，抓包时在接口列表里选那块物理网卡，不要选"本地回环"或虚拟网卡。

提示：如果抓包机是笔记本，接镜像口前先把无线网卡禁用，避免 Wireshark 默认抓到 Wi-Fi 接口的流量，白抓一场。

2.3 抓包前的过滤与捕获选项

Wireshark 捕获选项里可以预设 BPF 过滤，减少无关报文。排查流量异常时我一般先不设过滤，抓 30 秒到 1 分钟的全量包，因为异常协议事先不一定知道。但捕获缓冲区要设大一点，比如 256MB，避免高速流量下丢包。

抓完保存为 pcapng，文件名带上时间和端口，比如g0-1_20240612_1030.pcapng，后面复盘时不用再猜是哪次抓的。

3. 抓包文件分析：从流量统计锁定异常 IP 和协议

拿到 pcapng 后，先别急着逐包看，用 Wireshark 的统计功能把"谁在刷流量"筛出来，效率比手动翻高一个量级。

3.1 用会话统计定位流量大头

打开Statistics -> Conversations，切到 IPv4 标签，按 Bytes 或 Packets 排序。异常流量通常表现为某个内网 IP 对某个组播地址或外网 IP 的单向大包量。这次案例里排在前面的是一条内网 IP 持续向239.255.255.250:1900发包的记录，包量占比超过 80%。

# Wireshark 显示过滤器，直接筛 SSDP 流量 ssdp # 或者按 UDP 端口筛 udp.port == 1900 # 只看某个可疑 IP 的收发 ip.addr == 192.168.10.55

ssdp是 Wireshark 内置的协议显示过滤器，等价于udp.port == 1900 && http（SSDP 基于 HTTPU）。筛出来后看Statistics -> Protocol Hierarchy，如果 SSDP 占比异常高，基本可以确认是 SSDP 反射或设备异常广播。

3.2 从包内容提取 MAC 和 IP 的对应关系

定位到可疑 IP 后，展开任意一个 SSDP 包，在 Ethernet II 里能看到源 MAC，在 IP 层能看到源 IP。把这对关系记下来，这是后面反查物理端口的钥匙。

# 显示过滤器：筛出可疑 IP 且只看 SSDP 请求 ip.src == 192.168.10.55 && ssdp # 导出该 IP 的所有包到新文件，便于单独分析 # File -> Export Specified Packets -> Displayed

导出后可以用Statistics -> Endpoints看这个 IP 一共发了多少包、平均包长多少。SSDP 攻击的典型特征是包长固定（M-SEARCH 请求约 100 多字节）、发送间隔极短、目标地址固定为组播地址。

3.3 区分内网源和外网源的处理分支

抓包结果里异常 IP 分两种：内网 IP 和外网 IP，处理路径完全不同。

• 内网 IP：走核心交换机show mac-address反查接入端口，或通过 AC 用户管理页面按 IP 查 MAC 和关联 AP。
• 外网 IP：在防火墙上查 NAT 映射，确认被攻击的映射端口，能关就关，不能关就切换映射端口；持续被扫可提报运营商溯源，必要时切备用 IP。

这次案例是内网 IP，所以走的是反查路径。

4. 从 MAC 反查接入端口：核心、汇聚、接入三层定位

拿到异常设备的 MAC 后，定位物理位置靠的是逐层show mac-address加show lldp，这是园区网运维的基本功，比任何网管软件都可靠。

4.1 核心交换机上查下联端口

在核心交换机上执行：

# 用 MAC 后几位查，避免记错完整 MAC show mac-address | include 3c2e.ff # 输出示例： # 3c2e.ff12.3456 VLAN 10 GigabitEthernet 0/12

include后面跟 MAC 的后几段即可，锐捷的 MAC 显示格式是xxxx.xxxx.xxxx。拿到下联端口后，用show lldp neighbors看这个端口对端是哪台汇聚交换机。

show lldp neighbors interface gigabitEthernet 0/12

LLDP 输出里会有对端设备的 System Name 和管理 IP，远程登录到那台汇聚交换机，重复同样的show mac-address | include操作，找到再下一跳的接入交换机。

4.2 接入层定位到具体端口

到接入交换机后，最后一次show mac-address | include会直接给出端口号，比如GigabitEthernet 0/20。这个端口对应的就是异常设备实际插的网口，去现场按端口号找设备即可。

4.3 AC 平台按 IP 反查 AP 位置

如果无线用户是异常源，AC 管理页面比交换机命令更快。在"用户管理"里输入异常 IP，能直接看到用户 MAC、关联 AP 名称和 AP 所在位置。这次案例里 AC 数据是实时更新的，直接定位到某教室的 AP，现场确认是一台教学一体机在发 SSDP 包。

注意：AC 平台数据如果没做实时同步，按 IP 查可能查到旧记录，这时以交换机命令查到的端口为准，两者交叉验证。

4.4 紧急处置：先断网再排查

如果异常流量已经影响业务，不用等定位到物理设备，直接在核心或接入交换机上按 MAC 做端口禁用或 ACL 封禁，先恢复网络，再慢慢找设备。

# 接入交换机上关闭异常端口 interface gigabitEthernet 0/20 shutdown # 或在核心上用 ACL 封禁该 MAC 的流量 mac access-list extended BLOCK_ATTACK deny host 3c2e.ff12.3456 any

shutdown最直接，但会影响该端口下所有设备；ACL 更精细，适合端口下还有其他正常终端的情况。

5. 复测与验证：SSDP 报文消失、流量回落到基线

处置完不是结束，必须复测确认攻击流量真的消失，而不是被临时压制。

5.1 复测抓包的对比方法

重装异常设备系统后，在同一个镜像口再抓一次 30 秒包，用同样的ssdp过滤器看包量。这次案例里复测后 SSDP 报文从占比 80% 降到接近 0，端口流量从 5000 多 Kbps 降到 400 多 Kbps。

# 对比两次抓包的 SSDP 包数 # 第一次：Statistics -> Protocol Hierarchy，SSDP 占比 80%+ # 第二次：同一位置，SSDP 占比 <1%

5.2 基线流量的判断

400 多 Kbps 是不是正常？要看设备启用了哪些协议。这个项目里交换机开了 SNMP，默认轮询流量就在 400Kbps 左右；如果没开 SNMP，空载端口应该在 200Kbps 甚至更低。判断基线时把 SNMP、LLDP、STP 这些周期性协议的流量算进去，不要拿"零流量"当标准。

5.3 长期监控的一个小技巧

镜像口不用一直配着，排查完no monitor session 1关掉，避免长期占用端口。日常监控可以在核心交换机上配 sFlow 或 NetStream，采样比 1:1000，既能看流量趋势又不影响转发性能。下次再出现类似异常，先用 sFlow 定位到异常 IP，再临时开镜像口抓包，比每次全量抓包省事得多。

本文还有配套的精品资源，点击获取