更多云服务器知识，尽在hsotol.com
你有没有遇到过这样一个"灵异事件"：
某天早上，公司网络突然卡得离谱，连 ping 网关都开始超时，一查监控却啥都没报警。你以为是出口带宽不够了，结果折腾半天才发现，内网有人在"搞事"------ARP 洪泛。
更离谱的是，这种局部广播风暴不容易被传统监控系统抓住。大多数系统工具压根不会把 ARP 当作"异常"，而在某些私有云或混合部署环境中，它甚至成了最常见的"幽灵杀手"。
所以问题来了：我们能不能用最简单的方式，实时捕捉 ARP 异常，并立即推送告警？
当然可以，今天我们就用最通用、最实战的方式------Shell 脚本 + 飞书 / 邮件通知，打造一个轻量级的内网 ARP 洪泛监控方案。
为什么 ARP 洪泛这么隐蔽，却又这么致命？
先别急着上脚本，咱们先搞清楚这个现象到底怎么回事。
ARP 是什么？
ARP（Address Resolution Protocol）是局域网中的"问路协议"：
- 主机 A 要访问某个 IP，比如 192.168.1.10；
- 它会先发送一个 ARP 请求：请问谁是 192.168.1.10？
- 拥有该 IP 的设备会响应，并告诉它自己的 MAC 地址；
- A 拿到 MAC 后才会发起实际的数据传输。
ARP 洪泛怎么发生的？
- 某台设备中病毒，或者被恶意脚本操控，不停发出 ARP 广播；
- 有时交换机出 bug，也可能出现无意义的 ARP 回环；
- 在虚拟化环境下（比如 KVM/ESXi 里），某些 bridge 桥接口配置错，也可能引起 ARP 风暴；
- 更多时候，是"误配置"导致的：一个 DHCP 客户端不断重复申请但无法绑定 IP，引发 ARP 广播循环。
这种 ARP 风暴有两个特点：
- 广播频率极高（比如每秒几十上百条）；
- 系统不报警，因为它们没有形成明显的错误码或阻塞，Ping 也能通，但网络就是慢。
这就是为什么我们必须自己监控ARP 异常。
实现目标：三件事搞定
我们用最纯粹的方式完成以下 3 件事：
- 实时监听 ARP 包数量，判断是否异常；
- 根据设定的阈值触发告警（比如每秒超过 100 个 ARP 包）；
- 通过飞书机器人 / 邮件将异常发送出去。
第一步：监听 ARP 包的数量变化
我们用 tcpdump 或 ip -s link 都可以拿到数据，但这里更精准一点，直接用：
bash
tcpdump -i eth0 arp但是不能一直盯着屏幕看，所以我们得配合 Shell 脚本统计每秒捕获的 ARP 包数量。
示例代码：
bash
#!/bin/bash
# 配置参数
THRESHOLD=100 # 每秒ARP包超过这个数量就报警
INTERFACE="eth0"
LOG_FILE="/tmp/arp_monitor.log"
SLEEP_INTERVAL=1
while true; do
COUNT=$(timeout $SLEEP_INTERVAL tcpdump -n -i $INTERFACE arp 2>/dev/null | wc -l)
echo "$(date): ARP count = $COUNT" >> $LOG_FILE
if [ $COUNT -gt $THRESHOLD ]; then
echo "【ARP异常告警】当前ARP包数量：$COUNT，超过阈值：$THRESHOLD"
bash /opt/notify_feishu.sh "ARP洪泛预警：$COUNT 条/秒 @$(date '+%F %T')"
fi
done这个脚本每秒捕捉一次当前网卡的 ARP 包数量，如果超过预设值，就调用告警脚本。
第二步：配置飞书告警脚本
飞书的 Webhook 告警非常简单，只需要一个 URL 和一段 JSON 格式的内容。
获取飞书机器人 Webhook：
- 进入飞书群；
- 添加机器人；
- 开启"自定义机器人"，复制 Webhook 链接。
示例告警脚本 /opt/notify_feishu.sh：
bash
#!/bin/bash
ALERT_MSG="$1"
WEBHOOK_URL="https://open.feishu.cn/open-apis/bot/v2/hook/xxxxxxx" # 替换为你的URL
curl -X POST -H "Content-Type: application/json" \
-d "{
\"msg_type\": \"text\",
\"content\": {
\"text\": \"$ALERT_MSG\"
}
}" $WEBHOOK_URL赋予执行权限：
bash
chmod +x /opt/notify_feishu.sh现在，每当 ARP 数量超限时，飞书就会收到告警：
css复制编辑ARP洪泛预警：183 条/秒 @2025-07-03 10:58:33是不是比一堆没用的图表更直接？
第三步：配置邮件告警（可选）
如果你更喜欢 Email：
bash
apt install -y mailutils
echo "$ALERT_MSG" | mail -s "ARP 洪泛预警" your@email.com可以在主脚本里用条件判断选择飞书或邮件，甚至两者都发。
🧪 验证：如何模拟一次 ARP 洪泛？
在测试环境里，你可以用以下命令"伪造" ARP 包：
bash
while true; do
arping -c 1 -I eth0 192.168.1.1
done当然，别在正式环境运行，否则你可能会被"请去喝茶"。
🚨 告警防抖机制与日志轮转
每秒都发告警太频繁？加个简单防抖逻辑：
bash
LAST_ALERT_FILE="/tmp/last_alert_time"
NOW=$(date +%s)
LAST=$(cat $LAST_ALERT_FILE 2>/dev/null || echo 0)
if (( NOW - LAST > 60 )); then
bash /opt/notify_feishu.sh "ARP洪泛预警：$COUNT 条/秒"
echo $NOW > $LAST_ALERT_FILE
fi另外，为了避免日志爆炸，定期轮转日志或写入 logrotate 规则是个好习惯。
📊 进阶玩法：可视化 + Grafana Dashboard？
虽然我们用 shell 脚本搞定了"告警"，但如果你想搞点"图"，可以结合：
- 将 arp 数量统计结果写入 Prometheus exporter 格式；
- 用 Node Exporter + Textfile Collector 抓取自定义 metric；
- Grafana 显示 ARP 包趋势图；
这样你就能实现------实时图 + 飞书告警 + 日志回溯，运维体验直线上升。
🧠 为什么要自己写脚本，而不用现成的监控平台？
你可能会问：不是有 Zabbix、Prometheus、Open-Falcon 吗？为什么还要自己写脚本？
很简单：
- 大多数平台不采集 ARP；
- ARP 包是局域网层广播，容易被网络设备"过滤"；
- 大型监控系统部署周期长、适配难，而脚本 5 分钟就能上线；
- 一台轻量服务器 + 一段脚本，就能对全网ARP异常快速感知，这就是"平民武器"。
结尾提一句（不是套路）
运维不是"全靠工具"，而是"灵活工具 + 主动意识"的结合。
ARP 洪泛这种问题看似小众，但一旦发生，对私有云和内网业务打击巨大。而通过这种"小成本高价值"的 Shell 实战，你就能轻松做到事前感知、实时响应、不打无准备之仗。
下次网络变慢的时候，不用再茫然四顾，你会第一时间看脚本日志，而不是等老板来敲你工位。