摘要：如果你是做网络运维的，那你一定经历过这种场面：突然网络异常报警、核心交换机CPU打满、用户反馈“全网卡死”……这种时候你多半会直觉——十有八九是环路了。
如果你是做网络运维的，那你一定经历过这种场面：突然网络异常报警、核心交换机CPU打满、用户反馈“全网卡死”……这种时候你多半会直觉——十有八九是环路了。
今天这篇，不是科普什么是网络环路，而是我亲身经历的一次环路事故，怎么快速定位问题点、用什么工具、排查顺序怎么走，全程记录，希望能给你带来些启发。
那天大概是早上9点20左右，一进办公室，电话就响个不停：
“网盘挂了，连不上”“视频会议一会掉一会连”“OA系统打不开”登录核心交换机，第一眼就发现异常：
CPU高达98%，持续跳动；所有上联链路流量暴涨，尤其是广播占比非常高；远端管理口几乎失控，响应延迟严重。简单判断：大概率是环路引起广播风暴。但网络拓扑太大，接入交换机多达百余台，必须马上采取方法缩小排查范围。
最先用的工具是我们自建的可视化监控面板，基于Netdata + Prometheus + Grafana。
我直接打开“广播流量热图”，这张图我们平常也会盯着，一有异常马上能看到：
某栋办公楼3F~5F的接入交换机广播流量明显高于其他；对应那条上联链路出流量飙到了800Mbps，远超日常10倍；同时ARP请求量也剧增，几乎是平常的4倍。锁定区域：三号楼三层某接入段位异常。
我登录那台接入交换机，用命令查MAC地址表：
display mac-address | include dynamic发现一个非常奇怪的现象：
同一个MAC地址不断在不同端口间“跳来跳去”；某个端口（比如GigabitEthernet0/0/5）在短时间内学到数十个不同MAC；MAC表刷新频率极高，说明这口的数据在“飘”。这就是典型的二层环路现象：广播包从一个端口进来，又绕一圈回来了。
我们接着去看该端口连接设备：是一台小型五口交换机，应该是临时加的设备。
我派同事上楼实地查看。果然，在一间会议室里发现了“罪魁祸首”：
某位员工自带的五口交换机，两根网线分别接到了会议室墙上的两个信息插座；而这两个信息口后面，刚好分别通往两台不同的接入交换机；于是——环路就这样闭合了。立即断电、拔线，该会议室瞬间从“风暴中心”退役。
回到机房：
广播流量迅速回落；CPU从98%降到20%左右；网段恢复正常，所有业务系统逐步上线。我们原本只在核心设备上做了限速，接入层忘了开，这次事件过后全量补上：
interface GigabitEthernet0/0/Xstorm-control broadcast cir 512storm-control action shutdown配合802.1x、MAC绑定策略，对接入口做设备识别和隔离：
限制端口最多只允许1个MAC地址；超出即报警、禁用，或转入隔离VLAN；私自接交换机？自动踢出网络。如果该设备开着LLDP/CDP，其实也能提前识别“异常连接结构”：
display lldp neighbor一旦发现某个端口后面接着另一台交换设备（而这台又不是我们授权的），就能提前干预。
Step 1：查看核心设备CPU、广播流量，有无全局异常
Step 2：检查上联链路流量，是否某条异常
Step 3：切换到可疑接入交换机，查端口流量 + MAC漂移情况
Step 4：锁定可疑端口，断开/隔离测试，看网络是否恢复
Step 5：物理排查/询问现场，找出源设备
建议这套方法可以常备成手册贴在机房墙上，真出事的时候少掉头发。
如果你正在做校园网、医院网、写字楼网络建设，建议别等出环路才反应过来。提早开启环路保护、配置风暴抑制、统一拓扑管理，比什么都重要。
也欢迎留言说说你踩过的坑，或者你们的“环路定位妙招”。我们一起更新这本“血泪经验手册”。
来源：wljslmz
