从日志和抓包里提取 MAC 地址:网络排查与资产盘点实操

做网络运维的人都遇到过这种场景:手里一份几千行的 DHCP 日志,或者一段从交换机控制台复制下来的 show mac address-table 输出,要从里面把所有设备的 MAC 地址挑出来,数一数到底接入了多少台机器。肉眼一行行找,既慢又容易漏。这篇讲清楚怎么把这件事做对。

MAC 地址长什么样,正则怎么匹配

一个标准 MAC 地址是六组两位十六进制数,中间用冒号或连字符分隔,比如 00:1A:2B:3C:4D:5E 或 00-1A-2B-3C-4D-5E。少数厂商设备会写成点分三组的思科风格 001a.2b3c.4d5e。

要在一大段文本里把它们找全,核心是这条匹配规则:六组「两位十六进制 + 分隔符」的结构。写成正则大致是 ([0-9A-Fa-f]{2}[:-]){5}[0-9A-Fa-f]{2},意思是前面五组「两位十六进制加一个冒号或连字符」,最后再跟一组两位十六进制。注意十六进制只认 0 到 9 和 A 到 F,所以 0G:11:... 这种带 G 的串会被正确排除,它只是长得像而已。

实际日志里还会冒出差一点的东西,比如只有五组的 00:1A:2B:3C:4D,或者分隔符忽然从冒号变成连字符的混搭。这些近似匹配恰恰需要被标出来,而不是悄悄丢掉,这样你才能分清真地址和只是凑巧像的十六进制片段。

一段真实日志的提取过程

假设你从 DHCP 服务器拉了这么几行:

Jun 13 09:12:04 dhcpd: DHCPACK on 192.168.1.32 to 00:1a:2b:3c:4d:5e via eth0
Jun 13 09:12:08 dhcpd: DHCPDISCOVER from a4-83-e7-11-22-33 via eth0
Jun 13 09:13:55 dhcpd: lease 192.168.1.32 renewed for 00:1a:2b:3c:4d:5e
Jun 13 09:15:01 kernel: usb device 1d6b:0002 attached

把这段粘进 MAC 地址提取器,扫描结果是:

00:1a:2b:3c:4d:5e
a4-83-e7-11-22-33

注意第三行那个 00:1a:2b:3c:4d:5e 和第一行重复了,去重之后只留一条。最后一行的 1d6b:0002 是 USB 设备的厂商号和产品号,只有两组,不符合六组结构,自然不会被当成 MAC 拣出来。两台真实设备,清清楚楚。

去重是资产盘点的关键一步

盘点设备数量时,同一台机器在日志里出现几十上百次很常见:每次续租、每次重连都会留一行记录。如果不去重,你数出来的是「日志事件数」,不是「设备台数」,这两个数能差出一个数量级。

去重之前最好先规范化。从网页或工单复制来的文本常带隐藏空白,有的写大写有的写小写,00:1A:2B 和 00:1a:2b 是同一台设备却会被当成两条。先统一成一种写法再去重,数字才靠得住。如果你只想确认格式是否合法,可以单独走一遍 MAC 地址列表校验,把无效项和合法项分开看。

我自己怎么用

上个月排查一个接入交换机端口异常,我把交换机的 MAC 地址表整个复制下来,大概一千两百行,夹杂着端口号、VLAN 号和老化时间。直接粘进提取器,几秒钟出来一份去重后的列表,一共 86 个 MAC。再对照资产登记表一比,发现有 4 个地址登记表里根本没有,顺藤摸瓜查到是有人私接了一台未报备的交换机。要是手工从一千两百行里抠,我那天估计就别想干别的了。

导出成你下一步要用的格式

挑出来的列表很少是终点。盘点表要 CSV,写脚本批量查厂商要 JSON,丢进数据库筛选要 SQL 的 IN 子句。提取器支持在逐行、CSV、JSON、Markdown、SQL IN 和 TypeScript union 之间切换,选好直接下载,不用再手工加引号和补逗号。带行号的 CSV 还能当审计线索,回头有人问这个地址哪来的,翻回原文就能定位。

为什么坚持本地处理

设备的 MAC 地址连同所在网段,本身就是一份内网拓扑情报,不该随便发到外部服务器。这个提取器的解析、校验、去重、导出全部在你当前浏览器标签页里跑,上传的文本文件通过本地 File API 读取,不经过 Toolora 的服务器。整份 DHCP 日志也好,交换机控制台输出也好,设备清单始终留在你的内网。几 MB 的文件瞬间扫完;真碰上几个 GB 的大日志,先在本地用 grep 把含地址的行筛出来,再粘进来即可。

把混乱的日志和抓包文本变成一份干净、去重、可交接的设备清单,这件事本来就该几秒钟搞定,而不是靠肉眼熬一下午。

---

Made by Toolora · Updated 2026-06-13