刚入行那会儿我一度觉得泛洪是个危险词好像交换机一旦泛洪就是要出大事。后来被师傅带着排查过几回奇怪的网络故障才对它有了完全不一样的理解泛洪其实是交换机最基础、也最底层的转发兜底机制它本身不是故障但很多故障都藏在它的工作方式里。给新手网工一句话解释交换机泛洪就是当一个数据帧进入交换机但交换机在自己的 MAC 地址表里查不到这个帧的目的 MAC 地址该从哪个端口出去时它会把这个帧复制一份从除了接收端口以外的所有端口转发出去。听起来像个笨办法但二层交换在不知道目标在哪的时候只能这么干。这篇文章不扯太深的理论就把它为什么存在、什么时候触发、会造成什么后果、网工应该怎么定位和治理讲清楚。不管你是刚摸交换机的小白还是已经配了几年华为、思科、华三设备的老手我都建议把这块基础重新捋一遍因为很多灵异网络事件的根子都在这里。1. 从一次诡异的网络卡顿说起泛洪事故的现场画面先讲一个我实际遇到的例子这样大家对泛洪的感知会更具体。有一回客户报障说办公区网络隔几分钟卡一次VoIP 电话偶尔断音几个网络摄像头会掉线几秒后自动恢复。现场所有接入层交换机都在线链路状态也都 Upping 网关能通但延迟忽高忽低甚至偶尔丢包。最开始我怀疑是环路但登录交换机看 STP 状态没有阻塞端口异常CPU 也没有飙高到离谱。后来又怀疑是某台 PC 中病毒发广播但广播流量看起来并不算特别夸张。最后是在核心交换机上做了端口镜像抓包才看到一个很有意思的现象大量数据帧的目的 MAC 地址在交换机 MAC 地址表里根本找不到对应端口于是这些帧被复制转发到了同一 VLAN 下的所有端口。换句话说各科室的接入端口里都出现了一批和自己无关的流量。这就是典型的大规模未知单播泛洪。这类故障有一个比较迷惑人的特点从某个端口上看流量很大似乎像广播风暴但广播报文的比例并不高从应用侧看业务又不是完全断掉只是间歇性抽风。原因就在于泛洪把大量无用流量塞进了每个端口真正的业务报文需要和这些垃圾流量抢带宽一旦瞬间拥塞语音、视频、监控这类对时延敏感的应用就会先出问题。我当时在接入交换机上看接口 counters发现某些连接摄像头的端口接收和发送的字节数一直在以肉眼可见的速度增长但里面绝大部分帧都不是这个摄像头该收的。进一步查 MAC 地址表发现一个规律凡是间歇性离线或者慢的设备基本都是和另一台大流量服务器处于同一 VLAN而那台服务器在做大文件传输时目的设备因为没有近期通信记录MAC 地址表项已经老化于是交换机只能把它发出的部分数据帧全部泛洪。那次故障的最终处理方案不复杂调整 MAC 地址表老化时间、隔离服务器和终端之间的广播域、在接入端口加风暴抑制。但排查过程给了我一个很深的印象——泛洪不是一个有或无的状态而是一个需要结合流量特征、MAC 表状态、业务模型综合判断的机制。你不能一看见泛洪就说交换机坏了也不能因为广播不多就排除泛洪的可能。2. 泛洪的底层机制MAC 地址表查不到之后发生了什么2.1 交换机的三层转发动作要理解泛洪先要看交换机收到一个数据帧之后的完整决策过程。虽然不同厂商芯片实现有差异但逻辑上都可以归结为三步第一步接收帧记录源 MAC 地址和入端口更新 MAC 地址表这个过程叫MAC 地址学习。第二步查看帧的目的 MAC 地址去 MAC 地址表里查找匹配条目。第三步根据查表结果决定转发行为查到了而且是单播地址从表项对应的端口转发这叫已知单播转发。查不到而且是单播地址从除入端口外的所有端口转发这叫未知单播泛洪。目的 MAC 是广播地址从除入端口外的所有端口转发这是广播帧的正常处理方式。目的 MAC 是组播地址要看交换机是否开启了 IGMP Snooping有没有组播组成员记录如果没有对应表项一般也是泛洪处理。所以你会发现泛洪其实是所有二层交换机都会采用的兜底行为。它和广播型帧的区别在于广播帧是本来就是给所有人看的而未知单播泛洪是一个无奈之举——因为交换机不知道目标在哪只能广而告之让目标设备自己认领。2.2 为什么是除了接收端口以外的所有端口很多新手会问泛洪的时候为什么要把帧发给除接收端口外的所有端口为什么不干脆丢掉或者随机挑一个端口发出去道理很简单交换机不是路由器二层帧里没有 TTL也无法像 IP 路由那样做下一跳递归查找。如果交换机把一个帧从错误的端口发出去目标设备永远收不到而且交换机自己也意识不到发错了。与其这样不如把帧复制到所有可能的路径上让目标设备从其中一个端口收到并回应。当目标设备回应时交换机就能从回应帧中学习到它的 MAC 地址和端口对应关系后续通信走精准转发。至于为什么不能把帧重新发回接收端口也很好理解那等于把数据又还给了发送者没有任何意义而且还可能造成帧在同一链路上来回兜圈子形成数据环路。所以泛洪的定义里始终强调除接收端口外。2.3 MAC 地址表老化泛洪的定时开关MAC 地址表不是无限保存的。设备在交换机上不说话表项就会老化。华为交换机默认的老化时间通常是 300 秒思科很多设备默认也是 300 秒。也就是说一台终端如果超过 5 分钟没有任何通信交换机就会把它从 MAC 表里忘记。这个设计本身是为了防止 CAM 表被历史无效条目占满但也带来了一个副作用老化的设备一旦重新发起通信第一个发往它的数据帧必然查不到表项只能泛洪一次。正常情况下目标设备收到后会立刻回应交换机重新学习影响微乎其微。但在高负载、大流量、多终端的网络里这个老化—重学习的过程会频繁发生。比如一台视频监控服务器要同时轮询 50 个摄像头而摄像头发包频率不高MAC 表项反复老化那服务器每次发起轮询时发往这些摄像头的帧都会触发泛洪。如果这些摄像头和大量办公终端在同一个 VLAN办公网就会感受到无端的流量压力。我在实际配置中有一个经验先搞清楚网络里是否存在周期性、大批量、目标单一的流量模型再决定要不要动老化时间。如果确实有大量低频终端可以把老化时间适当调长比如 600 秒甚至 900 秒但不能调得太长否则 MAC 表容易积累垃圾条目而且终端移动位置后交换机还拿着旧端口转发反而会丢包。3. 哪些帧会被泛洪三种类型全面拆解搞清楚机制之后还要能分辨这个泛洪是不是正常的。我习惯把泛洪分成三类来看因为它们背后的原因和治理手段完全不同。3.1 未知单播泛洪最常见也最容易被忽略未知单播泛洪就是上一节说的查不到目的 MAC 就复制转发。触发它的情况很典型MAC 表项老化设备重新通信时第一帧泛洪终端移动到新端口旧表项没来得及更新新交换机上找不到 MAC网络中存在路由器和交换机之间互指的情况某个 VLAN 里的设备长时间不通信有人做了端口镜像或者二层捆绑配置不当导致交换机无法正常学习 MAC大量伪造源 MAC 的攻击帧灌进来把正常 MAC 表项挤掉。这类泛洪最大的问题是隐蔽。它不像广播风暴那样一眼就能从流量波形上看出来而且很多时候数据量不大只是在某个瞬间突发。如果你只在网络正常的时候看基线很难发现异常。我一般会在核心设备上开启针对未知单播的流量统计平时记录各端口基线值出故障时对比增量。3.2 广播帧的泛洪ARP 和 DHCP 的正常噪音广播帧的泛洪行为是必然的因为广播 MACFF-FF-FF-FF-FF-FF本身就表示发给所有设备。二层交换机收到广播帧天然要把它泛洪到同一 VLAN 的所有端口。正常网络里广播帧并不少见。ARP 请求就是最常见的广播帧比如 PC 要访问网关会先发一个谁的 IP 是 192.168.1.1请告诉我你的 MAC的 ARP 广播。DHCP 客户端在获取 IP 之前也会发 DHCP Discover 广播。这些广播是网络正常工作的必要组成部分只要频率可控网工不需要太担心。真正要警惕的是广播帧数量异常飙升。比如有设备中了蠕虫病毒每秒发出成千上万个 ARP 请求或者有终端开启了不正常的服务发现协议周期性全网广播。这时候问题已经不是泛洪本身而是广播域过大 异常广播源两个因素叠加。所以治理广播泛洪的核心思路就两条控制广播源缩小广播域。3.3 组播帧泛洪没有 IGMP Snooping 时的默认动作组播场景是新手比较容易漏掉的一类。组播帧的目的 MAC 是 01-00-5E 开头的地址它本身是一对多的通信方式。交换机对组播帧的处理要看它是否启用了 IGMP Snooping如果开启了 IGMP Snooping交换机会监听主机和组播路由器之间的 IGMP 报文形成一个组播组成员端口表项。发往该组播组的帧只转发给那些明确表示我想接收的端口。如果没开 IGMP Snooping或者组播表里没有对应组成员记录交换机就会把组播帧当成未知帧处理直接泛洪到整个 VLAN。很多老网络里工程师只关注单播和广播忽略了组播。结果一开视频会议软件、P2P 组播投屏或者组播视频流整个接入交换机所有端口都在收同一份视频流流量翻倍上涨。这里我强烈建议只要网络里存在 IPTV、视频会议、组播投屏等应用一定要在交换机上开启 IGMP Snooping并配置查询器或指定组播路由器端口避免组播流量变成全端口复制。下面是三类泛洪的特征对比收藏起来排查时直接对照帧类型触发条件是否正常典型场景主要治理手段未知单播泛洪MAC 表查不到目的地址偶发正常频发异常表项老化、终端移动、MAC 表耗尽调老化时间、查环路、控制 MAC 学习数量广播帧泛洪目的 MAC 为广播地址正常但需控量ARP、DHCP、服务发现风暴抑制、VLAN 隔离、查异常广播源组播帧泛洪无 IGMP Snooping 成员表可以避免IPTV、视频会议、组播投屏开启 IGMP Snooping配置组成员端口4. 泛洪的危害为什么网工不能听之任之既然泛洪是交换机的基本机制那是不是不用管它当然不是。泛洪在机制上没错但过度泛洪、恶意泛洪和体系性的泛洪放大是实实在在会导致业务受损的。4.1 带宽被无意义流量吃光最直接的危害就是带宽浪费。假设一个 VLAN 里有 200 台终端某台服务器发往一个未知单播地址的帧被泛洪到所有 200 个端口那么这个帧在接入交换机上就产生了 199 份副本。每份副本都会占用对应端口的一部分带宽。如果这种泛洪流量是持续的比如服务器在批量同步数据、备份系统在跑任务那么所有无关终端的端口都会感受到背景流量。对于百兆接入的摄像头、老式打印机、IP 电话这种背景流量很容易造成拥塞。表现出来就是网速慢、语音断断续续、监控画面卡顿但看链路利用率又不是每个端口都跑满。因为带宽是被一大群低速率小帧慢慢蚕食的而不是一个持续大流量一下子打满。4.2 安全隐私问题不该收到数据的人收到了数据泛洪的另一个隐患是安全。帧被复制到同一 VLAN 的所有端口意味着这些端口上的抓包工具都能看到本该发给特定目标的数据内容。在没有额外加密的前提下FTP、Telnet、HTTP 这类明文流量很容易在泛洪过程中被无关人员截获。这就是为什么在金融、政务、企业内部办公网中单纯的 VLAN 隔离已经不够了还需要再做端口安全、MAC 地址绑定、甚至 private VLAN 来防止不必要的泛洪扩散。安全基线里经常提到的端口隔离本质上就是想减少泛洪的接收方数量。4.3 MAC 泛洪攻击从交换机退化成集线器最严重的一种情况是恶意 MAC 泛洪攻击也叫 CAM 表溢出攻击。攻击者向交换机发送大量源 MAC 地址不断变化的伪造帧把 CAM 表的学习空间全部占满。这时候交换机再也学不到合法终端的 MAC 地址只能把所有未知帧全部泛洪。后果是什么交换机从根据 MAC 地址精准转发的设备退化成了一个类似集线器的东西——所有流量都在泛滥。攻击者只要把自己的网卡设为混杂模式就能抓到本来不该它接收的两个终端之间的通信内容。这是二层安全里非常经典的一种攻击方式很多等保测评、渗透测试项目都会检查这一点。防御手段也很明确在接入端口开启端口安全port-security限制端口学习的 MAC 地址最大数量对服务器等关键设备做 MAC 和端口静态绑定开启 DHCP Snooping、IPSG、DAI 等防御机制从源头拦截伪造源 MAC 的报文监控核心设备 CAM 表利用率超过阈值告警。下面是一个自助排查用的速查表现象可能原因快速判断方法网络间歇性卡顿MAC 表老化、未知单播泛洪看端口广播/组播比例抓包看目的 MAC大量端口带宽异常泛洪、广播风暴、环路看端口 counters 是否有大量 Broadcast/Multicast抓包发现无关流量泛洪导致数据扩散确认目的 MAC 是否在 MAC 表中有记录交换机 CPU 高ARP 泛洪、MAC 泛洪攻击查看 CPU 占用率和协议报文统计CAM 表利用率过高MAC 泛洪攻击或终端数量过多查看 MAC 表项数量和来源端口5. 排查与治理从抓包到配置的完整思路遇到疑似泛洪问题的网络不要急着去改全局配置也不要一上来就怀疑交换机坏了。按下面的顺序走能省很多冤枉路。5.1 定位谁在泛洪端口计数器和抓包两手抓第一步看端口流量统计。登录接入或汇聚交换机查看所有端口收发的错误帧、广播帧、组播帧计数器。如果某个端口在短时间内广播或组播帧数量暴涨那这个端口背后要么有异常设备要么接了下联交换机带着一大片终端。第二步做端口镜像抓包。把怀疑有问题的端口流量镜像到一台笔记本用 Wireshark 打开重点看统计菜单里的Conversations或I/O Graph。如果发现大量目的 MAC 地址非常分散、不是广播地址却出现多个端口都在收的帧基本可以确定是泛洪。再结合源 MAC 和对应 IP找到那个喷流量的设备。第三步查 MAC 地址表。在核心交换机上查看特定 MAC 地址对应哪个端口。如果在接入层交换机上查不到某个终端的 MAC 表项但它明明在线那说明这台交换机正在对该终端方向的流量做泛洪。逐跳往上查直到找到学不到 MAC或者MAC 频繁消失的那台设备问题根源大概率就在它身上。5.2 立即止血配置风暴抑制和端口安全定位到异常之后第一步是止血防止故障扩大。不同厂商命令有差异但思路都一样华为交换机上可以在接口下配置风暴抑制限制广播、组播、未知单播的速率interface GigabitEthernet0/0/1 broadcast-suppression 5 // 设置广播流量占用带宽比例上限为5% multicast-suppression 5 unicast-suppression 5思科交换机上则是interface GigabitEthernet0/1 storm-control broadcast level 5 storm-control multicast level 5 storm-control unicast level 5风暴抑制的比例不是固定的。有的厂商用百分比有的用 pps每秒包数有的用 kbps配置前先看单位。我一般会从较低的阈值开始调比如 5% 或 1000 pps然后观察业务是否受影响。因为开得太狠会把正常的广播协议也压住导致 ARP 不通、路由协议邻居闪断反而添乱。端口安全也建议在接入层全面启用至少要做到限制单端口 MAC 学习数量。华为的例子interface GigabitEthernet0/0/1 port-security enable port-security max-mac-num 5 port-security protect-action restrict思科的例子interface GigabitEthernet0/1 switchport port-security switchport port-security maximum 5 switchport port-security violation restrict这里的restrict模式是丢弃非法帧并告警而不是直接 shutdown 端口比较适合生产环境。对打印机、IP 电话这种固定设备建议直接做 sticky MAC 绑定防止 MAC 地址漂移。5.3 治本从架构上减少泛洪扩散止血之后要找根因。如果泛洪的根本原因是 VLAN 太大一台设备发个广播全网都受影响那就要做 VLAN 规划把不同部门、不同业务拆开。现在企业网基本都按业务划分 VLAN但很多老网络是一个大二层平铺几百台设备一个 VLAN这种设计在故障面前非常脆弱。如果泛洪来源是组播优先开启 IGMP Snooping。华为交换机通常在 VLAN 下开启vlan 10 igmp-snooping enable思科则默认开启但要确认交换机是否学习到了组成员端口。如果 VLAN 里有组播路由器还要配置 igmp snooping querier否则成员关系可能学不到。如果泛洪来源是异常终端在发大量伪造 MAC需要结合 DHCP Snooping 和 DAI动态 ARP 检测来拦截。华为交换机上的基本配置思路dhcp enable dhcp snooping enable vlan 10 dhcp snooping enable arp dhcp-snooping detect enable interface GigabitEthernet0/0/1 dhcp snooping enable dhcp snooping trusted核心侧连 DHCP 服务器的口要配置为 trusted接入侧保持默认 unstrusted。这里有个很容易踩的坑很多人只在接入交换机上开了 DHCP Snooping但上游交换机没有同步配置导致 DHCP 报文被丢弃所有终端拿不到 IP。改配置之前一定要确认全链路都对齐。5.4 关于 MAC 地址表老化时间调整的实操建议最后再单独说一句老化时间。很多人一看交换机上有mac-address aging-time这个命令就喜欢调成 0表示永不过期觉得这样就不会有未知单播泛洪了。这种想法要不得。把 MAC 老化时间设成 0意味着所有学习到的 MAC 表项永远不消失。终端一旦移动位置交换机还拿着旧端口信息转发流量全走错路网络直接瘫痪。我见过不止一次这种好心办坏事的案例。正确的做法是对于接入层终端为主的交换机维持默认 300 秒即可如果有大量低频通信终端可以适当调到 600 秒对于核心层可以稍微调短一点比如 120 到 180 秒这样终端迁移后能更快重新学习不建议低于 30 秒否则每台设备都在高频泛洪整体性能更差。6. 泛洪、广播、广播风暴、环路这些概念到底啥关系文章最后把几个经常被混在一起的概念理一理因为网上很多资料讲得比较乱初学者很容易被绕晕。6.1 泛洪不是广播广播也不是泛洪泛洪是一种转发动作广播是一种帧类型。交换机对广播帧的处理方式是泛洪对未知单播帧的处理方式也可能泛洪。所以你可以说广播帧被泛洪了但不能说泛洪就是广播。这两者的本质区别在于广播帧的目的地址是特殊地址所有设备都必须处理未知单播泛洪的帧目的地址是一个普通单播 MAC只是交换机暂时不知道它在哪个端口被迫广而告之。6.2 广播风暴和泛洪是放大器和后果的关系广播风暴通常是因为二层环路导致广播帧不断被复制、转发、再复制。一个广播帧从交换机 A 的某个口出去经过交换机 B 又从另一个口回到交换机 AA 再泛洪到所有口如此循环最终广播帧数量指数膨胀网络彻底瘫痪。在这个过程里泛洪是广播风暴传播的必经动作但根因是环路不是泛洪。所以遇到广播风暴第一反应应该是查 STP 状态、找物理环路而不是一味地压低风暴抑制阈值。把环路剪断泛洪自然就停了。6.3 经常被误判为泛洪故障的其他原因排查故障时不要把注意力全锁在泛洪上。以下情况同样会造成类似症状端口协商异常某台设备变成了半双工导致大量冲突和重传网卡故障发出大量错误帧交换机不停转发这些坏帧光模块或网线质量差CRC 错误帧很多影响转发效率上下联带宽不匹配比如摄像头接到百兆口而流媒体服务器接到千兆口瞬时流量超过百兆口能力。所以完整排查思路应该是先确认物理层没问题再看二层协议状态然后看流量特征最后才去动风暴抑制和端口安全配置。6.4 一句话回答泛洪到底好不好既有用又危险。它是交换机在不知道目标在哪时的兜底机制保证网络不会因为一次查表失败就丢包但它同时也是广播风暴、MAC 泛洪攻击、组播流量泛滥的传播通道。网工的职责不是消灭泛洪而是控制泛洪的影响范围让正常协议能跑异常流量能被掐住。我个人做网络底稿时有个习惯所有接入端口默认开风暴抑制和端口安全收敛广播域核心上联口只做必要的信任配置其余全关每季度看一次 CAM 表利用率和各端口广播/组播占比。多数泛洪问题都能在这个节奏里被提前发现而不是等到用户投诉才去救火。交换机泛洪这个知识点说到底是二层交换的基石。把这个机制吃透了再去看 STP、VLAN、组播、端口安全这些内容会顺畅很多。尤其是刚入行的网工别急着学各种命令行高级配置先把数据帧进交换机后到底经历了什么想清楚后面所有排障思路都会有根。
交换机泛洪机制详解：从MAC地址表到未知单播的排查与治理
刚入行那会儿我一度觉得泛洪是个危险词好像交换机一旦泛洪就是要出大事。后来被师傅带着排查过几回奇怪的网络故障才对它有了完全不一样的理解泛洪其实是交换机最基础、也最底层的转发兜底机制它本身不是故障但很多故障都藏在它的工作方式里。给新手网工一句话解释交换机泛洪就是当一个数据帧进入交换机但交换机在自己的 MAC 地址表里查不到这个帧的目的 MAC 地址该从哪个端口出去时它会把这个帧复制一份从除了接收端口以外的所有端口转发出去。听起来像个笨办法但二层交换在不知道目标在哪的时候只能这么干。这篇文章不扯太深的理论就把它为什么存在、什么时候触发、会造成什么后果、网工应该怎么定位和治理讲清楚。不管你是刚摸交换机的小白还是已经配了几年华为、思科、华三设备的老手我都建议把这块基础重新捋一遍因为很多灵异网络事件的根子都在这里。1. 从一次诡异的网络卡顿说起泛洪事故的现场画面先讲一个我实际遇到的例子这样大家对泛洪的感知会更具体。有一回客户报障说办公区网络隔几分钟卡一次VoIP 电话偶尔断音几个网络摄像头会掉线几秒后自动恢复。现场所有接入层交换机都在线链路状态也都 Upping 网关能通但延迟忽高忽低甚至偶尔丢包。最开始我怀疑是环路但登录交换机看 STP 状态没有阻塞端口异常CPU 也没有飙高到离谱。后来又怀疑是某台 PC 中病毒发广播但广播流量看起来并不算特别夸张。最后是在核心交换机上做了端口镜像抓包才看到一个很有意思的现象大量数据帧的目的 MAC 地址在交换机 MAC 地址表里根本找不到对应端口于是这些帧被复制转发到了同一 VLAN 下的所有端口。换句话说各科室的接入端口里都出现了一批和自己无关的流量。这就是典型的大规模未知单播泛洪。这类故障有一个比较迷惑人的特点从某个端口上看流量很大似乎像广播风暴但广播报文的比例并不高从应用侧看业务又不是完全断掉只是间歇性抽风。原因就在于泛洪把大量无用流量塞进了每个端口真正的业务报文需要和这些垃圾流量抢带宽一旦瞬间拥塞语音、视频、监控这类对时延敏感的应用就会先出问题。我当时在接入交换机上看接口 counters发现某些连接摄像头的端口接收和发送的字节数一直在以肉眼可见的速度增长但里面绝大部分帧都不是这个摄像头该收的。进一步查 MAC 地址表发现一个规律凡是间歇性离线或者慢的设备基本都是和另一台大流量服务器处于同一 VLAN而那台服务器在做大文件传输时目的设备因为没有近期通信记录MAC 地址表项已经老化于是交换机只能把它发出的部分数据帧全部泛洪。那次故障的最终处理方案不复杂调整 MAC 地址表老化时间、隔离服务器和终端之间的广播域、在接入端口加风暴抑制。但排查过程给了我一个很深的印象——泛洪不是一个有或无的状态而是一个需要结合流量特征、MAC 表状态、业务模型综合判断的机制。你不能一看见泛洪就说交换机坏了也不能因为广播不多就排除泛洪的可能。2. 泛洪的底层机制MAC 地址表查不到之后发生了什么2.1 交换机的三层转发动作要理解泛洪先要看交换机收到一个数据帧之后的完整决策过程。虽然不同厂商芯片实现有差异但逻辑上都可以归结为三步第一步接收帧记录源 MAC 地址和入端口更新 MAC 地址表这个过程叫MAC 地址学习。第二步查看帧的目的 MAC 地址去 MAC 地址表里查找匹配条目。第三步根据查表结果决定转发行为查到了而且是单播地址从表项对应的端口转发这叫已知单播转发。查不到而且是单播地址从除入端口外的所有端口转发这叫未知单播泛洪。目的 MAC 是广播地址从除入端口外的所有端口转发这是广播帧的正常处理方式。目的 MAC 是组播地址要看交换机是否开启了 IGMP Snooping有没有组播组成员记录如果没有对应表项一般也是泛洪处理。所以你会发现泛洪其实是所有二层交换机都会采用的兜底行为。它和广播型帧的区别在于广播帧是本来就是给所有人看的而未知单播泛洪是一个无奈之举——因为交换机不知道目标在哪只能广而告之让目标设备自己认领。2.2 为什么是除了接收端口以外的所有端口很多新手会问泛洪的时候为什么要把帧发给除接收端口外的所有端口为什么不干脆丢掉或者随机挑一个端口发出去道理很简单交换机不是路由器二层帧里没有 TTL也无法像 IP 路由那样做下一跳递归查找。如果交换机把一个帧从错误的端口发出去目标设备永远收不到而且交换机自己也意识不到发错了。与其这样不如把帧复制到所有可能的路径上让目标设备从其中一个端口收到并回应。当目标设备回应时交换机就能从回应帧中学习到它的 MAC 地址和端口对应关系后续通信走精准转发。至于为什么不能把帧重新发回接收端口也很好理解那等于把数据又还给了发送者没有任何意义而且还可能造成帧在同一链路上来回兜圈子形成数据环路。所以泛洪的定义里始终强调除接收端口外。2.3 MAC 地址表老化泛洪的定时开关MAC 地址表不是无限保存的。设备在交换机上不说话表项就会老化。华为交换机默认的老化时间通常是 300 秒思科很多设备默认也是 300 秒。也就是说一台终端如果超过 5 分钟没有任何通信交换机就会把它从 MAC 表里忘记。这个设计本身是为了防止 CAM 表被历史无效条目占满但也带来了一个副作用老化的设备一旦重新发起通信第一个发往它的数据帧必然查不到表项只能泛洪一次。正常情况下目标设备收到后会立刻回应交换机重新学习影响微乎其微。但在高负载、大流量、多终端的网络里这个老化—重学习的过程会频繁发生。比如一台视频监控服务器要同时轮询 50 个摄像头而摄像头发包频率不高MAC 表项反复老化那服务器每次发起轮询时发往这些摄像头的帧都会触发泛洪。如果这些摄像头和大量办公终端在同一个 VLAN办公网就会感受到无端的流量压力。我在实际配置中有一个经验先搞清楚网络里是否存在周期性、大批量、目标单一的流量模型再决定要不要动老化时间。如果确实有大量低频终端可以把老化时间适当调长比如 600 秒甚至 900 秒但不能调得太长否则 MAC 表容易积累垃圾条目而且终端移动位置后交换机还拿着旧端口转发反而会丢包。3. 哪些帧会被泛洪三种类型全面拆解搞清楚机制之后还要能分辨这个泛洪是不是正常的。我习惯把泛洪分成三类来看因为它们背后的原因和治理手段完全不同。3.1 未知单播泛洪最常见也最容易被忽略未知单播泛洪就是上一节说的查不到目的 MAC 就复制转发。触发它的情况很典型MAC 表项老化设备重新通信时第一帧泛洪终端移动到新端口旧表项没来得及更新新交换机上找不到 MAC网络中存在路由器和交换机之间互指的情况某个 VLAN 里的设备长时间不通信有人做了端口镜像或者二层捆绑配置不当导致交换机无法正常学习 MAC大量伪造源 MAC 的攻击帧灌进来把正常 MAC 表项挤掉。这类泛洪最大的问题是隐蔽。它不像广播风暴那样一眼就能从流量波形上看出来而且很多时候数据量不大只是在某个瞬间突发。如果你只在网络正常的时候看基线很难发现异常。我一般会在核心设备上开启针对未知单播的流量统计平时记录各端口基线值出故障时对比增量。3.2 广播帧的泛洪ARP 和 DHCP 的正常噪音广播帧的泛洪行为是必然的因为广播 MACFF-FF-FF-FF-FF-FF本身就表示发给所有设备。二层交换机收到广播帧天然要把它泛洪到同一 VLAN 的所有端口。正常网络里广播帧并不少见。ARP 请求就是最常见的广播帧比如 PC 要访问网关会先发一个谁的 IP 是 192.168.1.1请告诉我你的 MAC的 ARP 广播。DHCP 客户端在获取 IP 之前也会发 DHCP Discover 广播。这些广播是网络正常工作的必要组成部分只要频率可控网工不需要太担心。真正要警惕的是广播帧数量异常飙升。比如有设备中了蠕虫病毒每秒发出成千上万个 ARP 请求或者有终端开启了不正常的服务发现协议周期性全网广播。这时候问题已经不是泛洪本身而是广播域过大 异常广播源两个因素叠加。所以治理广播泛洪的核心思路就两条控制广播源缩小广播域。3.3 组播帧泛洪没有 IGMP Snooping 时的默认动作组播场景是新手比较容易漏掉的一类。组播帧的目的 MAC 是 01-00-5E 开头的地址它本身是一对多的通信方式。交换机对组播帧的处理要看它是否启用了 IGMP Snooping如果开启了 IGMP Snooping交换机会监听主机和组播路由器之间的 IGMP 报文形成一个组播组成员端口表项。发往该组播组的帧只转发给那些明确表示我想接收的端口。如果没开 IGMP Snooping或者组播表里没有对应组成员记录交换机就会把组播帧当成未知帧处理直接泛洪到整个 VLAN。很多老网络里工程师只关注单播和广播忽略了组播。结果一开视频会议软件、P2P 组播投屏或者组播视频流整个接入交换机所有端口都在收同一份视频流流量翻倍上涨。这里我强烈建议只要网络里存在 IPTV、视频会议、组播投屏等应用一定要在交换机上开启 IGMP Snooping并配置查询器或指定组播路由器端口避免组播流量变成全端口复制。下面是三类泛洪的特征对比收藏起来排查时直接对照帧类型触发条件是否正常典型场景主要治理手段未知单播泛洪MAC 表查不到目的地址偶发正常频发异常表项老化、终端移动、MAC 表耗尽调老化时间、查环路、控制 MAC 学习数量广播帧泛洪目的 MAC 为广播地址正常但需控量ARP、DHCP、服务发现风暴抑制、VLAN 隔离、查异常广播源组播帧泛洪无 IGMP Snooping 成员表可以避免IPTV、视频会议、组播投屏开启 IGMP Snooping配置组成员端口4. 泛洪的危害为什么网工不能听之任之既然泛洪是交换机的基本机制那是不是不用管它当然不是。泛洪在机制上没错但过度泛洪、恶意泛洪和体系性的泛洪放大是实实在在会导致业务受损的。4.1 带宽被无意义流量吃光最直接的危害就是带宽浪费。假设一个 VLAN 里有 200 台终端某台服务器发往一个未知单播地址的帧被泛洪到所有 200 个端口那么这个帧在接入交换机上就产生了 199 份副本。每份副本都会占用对应端口的一部分带宽。如果这种泛洪流量是持续的比如服务器在批量同步数据、备份系统在跑任务那么所有无关终端的端口都会感受到背景流量。对于百兆接入的摄像头、老式打印机、IP 电话这种背景流量很容易造成拥塞。表现出来就是网速慢、语音断断续续、监控画面卡顿但看链路利用率又不是每个端口都跑满。因为带宽是被一大群低速率小帧慢慢蚕食的而不是一个持续大流量一下子打满。4.2 安全隐私问题不该收到数据的人收到了数据泛洪的另一个隐患是安全。帧被复制到同一 VLAN 的所有端口意味着这些端口上的抓包工具都能看到本该发给特定目标的数据内容。在没有额外加密的前提下FTP、Telnet、HTTP 这类明文流量很容易在泛洪过程中被无关人员截获。这就是为什么在金融、政务、企业内部办公网中单纯的 VLAN 隔离已经不够了还需要再做端口安全、MAC 地址绑定、甚至 private VLAN 来防止不必要的泛洪扩散。安全基线里经常提到的端口隔离本质上就是想减少泛洪的接收方数量。4.3 MAC 泛洪攻击从交换机退化成集线器最严重的一种情况是恶意 MAC 泛洪攻击也叫 CAM 表溢出攻击。攻击者向交换机发送大量源 MAC 地址不断变化的伪造帧把 CAM 表的学习空间全部占满。这时候交换机再也学不到合法终端的 MAC 地址只能把所有未知帧全部泛洪。后果是什么交换机从根据 MAC 地址精准转发的设备退化成了一个类似集线器的东西——所有流量都在泛滥。攻击者只要把自己的网卡设为混杂模式就能抓到本来不该它接收的两个终端之间的通信内容。这是二层安全里非常经典的一种攻击方式很多等保测评、渗透测试项目都会检查这一点。防御手段也很明确在接入端口开启端口安全port-security限制端口学习的 MAC 地址最大数量对服务器等关键设备做 MAC 和端口静态绑定开启 DHCP Snooping、IPSG、DAI 等防御机制从源头拦截伪造源 MAC 的报文监控核心设备 CAM 表利用率超过阈值告警。下面是一个自助排查用的速查表现象可能原因快速判断方法网络间歇性卡顿MAC 表老化、未知单播泛洪看端口广播/组播比例抓包看目的 MAC大量端口带宽异常泛洪、广播风暴、环路看端口 counters 是否有大量 Broadcast/Multicast抓包发现无关流量泛洪导致数据扩散确认目的 MAC 是否在 MAC 表中有记录交换机 CPU 高ARP 泛洪、MAC 泛洪攻击查看 CPU 占用率和协议报文统计CAM 表利用率过高MAC 泛洪攻击或终端数量过多查看 MAC 表项数量和来源端口5. 排查与治理从抓包到配置的完整思路遇到疑似泛洪问题的网络不要急着去改全局配置也不要一上来就怀疑交换机坏了。按下面的顺序走能省很多冤枉路。5.1 定位谁在泛洪端口计数器和抓包两手抓第一步看端口流量统计。登录接入或汇聚交换机查看所有端口收发的错误帧、广播帧、组播帧计数器。如果某个端口在短时间内广播或组播帧数量暴涨那这个端口背后要么有异常设备要么接了下联交换机带着一大片终端。第二步做端口镜像抓包。把怀疑有问题的端口流量镜像到一台笔记本用 Wireshark 打开重点看统计菜单里的Conversations或I/O Graph。如果发现大量目的 MAC 地址非常分散、不是广播地址却出现多个端口都在收的帧基本可以确定是泛洪。再结合源 MAC 和对应 IP找到那个喷流量的设备。第三步查 MAC 地址表。在核心交换机上查看特定 MAC 地址对应哪个端口。如果在接入层交换机上查不到某个终端的 MAC 表项但它明明在线那说明这台交换机正在对该终端方向的流量做泛洪。逐跳往上查直到找到学不到 MAC或者MAC 频繁消失的那台设备问题根源大概率就在它身上。5.2 立即止血配置风暴抑制和端口安全定位到异常之后第一步是止血防止故障扩大。不同厂商命令有差异但思路都一样华为交换机上可以在接口下配置风暴抑制限制广播、组播、未知单播的速率interface GigabitEthernet0/0/1 broadcast-suppression 5 // 设置广播流量占用带宽比例上限为5% multicast-suppression 5 unicast-suppression 5思科交换机上则是interface GigabitEthernet0/1 storm-control broadcast level 5 storm-control multicast level 5 storm-control unicast level 5风暴抑制的比例不是固定的。有的厂商用百分比有的用 pps每秒包数有的用 kbps配置前先看单位。我一般会从较低的阈值开始调比如 5% 或 1000 pps然后观察业务是否受影响。因为开得太狠会把正常的广播协议也压住导致 ARP 不通、路由协议邻居闪断反而添乱。端口安全也建议在接入层全面启用至少要做到限制单端口 MAC 学习数量。华为的例子interface GigabitEthernet0/0/1 port-security enable port-security max-mac-num 5 port-security protect-action restrict思科的例子interface GigabitEthernet0/1 switchport port-security switchport port-security maximum 5 switchport port-security violation restrict这里的restrict模式是丢弃非法帧并告警而不是直接 shutdown 端口比较适合生产环境。对打印机、IP 电话这种固定设备建议直接做 sticky MAC 绑定防止 MAC 地址漂移。5.3 治本从架构上减少泛洪扩散止血之后要找根因。如果泛洪的根本原因是 VLAN 太大一台设备发个广播全网都受影响那就要做 VLAN 规划把不同部门、不同业务拆开。现在企业网基本都按业务划分 VLAN但很多老网络是一个大二层平铺几百台设备一个 VLAN这种设计在故障面前非常脆弱。如果泛洪来源是组播优先开启 IGMP Snooping。华为交换机通常在 VLAN 下开启vlan 10 igmp-snooping enable思科则默认开启但要确认交换机是否学习到了组成员端口。如果 VLAN 里有组播路由器还要配置 igmp snooping querier否则成员关系可能学不到。如果泛洪来源是异常终端在发大量伪造 MAC需要结合 DHCP Snooping 和 DAI动态 ARP 检测来拦截。华为交换机上的基本配置思路dhcp enable dhcp snooping enable vlan 10 dhcp snooping enable arp dhcp-snooping detect enable interface GigabitEthernet0/0/1 dhcp snooping enable dhcp snooping trusted核心侧连 DHCP 服务器的口要配置为 trusted接入侧保持默认 unstrusted。这里有个很容易踩的坑很多人只在接入交换机上开了 DHCP Snooping但上游交换机没有同步配置导致 DHCP 报文被丢弃所有终端拿不到 IP。改配置之前一定要确认全链路都对齐。5.4 关于 MAC 地址表老化时间调整的实操建议最后再单独说一句老化时间。很多人一看交换机上有mac-address aging-time这个命令就喜欢调成 0表示永不过期觉得这样就不会有未知单播泛洪了。这种想法要不得。把 MAC 老化时间设成 0意味着所有学习到的 MAC 表项永远不消失。终端一旦移动位置交换机还拿着旧端口信息转发流量全走错路网络直接瘫痪。我见过不止一次这种好心办坏事的案例。正确的做法是对于接入层终端为主的交换机维持默认 300 秒即可如果有大量低频通信终端可以适当调到 600 秒对于核心层可以稍微调短一点比如 120 到 180 秒这样终端迁移后能更快重新学习不建议低于 30 秒否则每台设备都在高频泛洪整体性能更差。6. 泛洪、广播、广播风暴、环路这些概念到底啥关系文章最后把几个经常被混在一起的概念理一理因为网上很多资料讲得比较乱初学者很容易被绕晕。6.1 泛洪不是广播广播也不是泛洪泛洪是一种转发动作广播是一种帧类型。交换机对广播帧的处理方式是泛洪对未知单播帧的处理方式也可能泛洪。所以你可以说广播帧被泛洪了但不能说泛洪就是广播。这两者的本质区别在于广播帧的目的地址是特殊地址所有设备都必须处理未知单播泛洪的帧目的地址是一个普通单播 MAC只是交换机暂时不知道它在哪个端口被迫广而告之。6.2 广播风暴和泛洪是放大器和后果的关系广播风暴通常是因为二层环路导致广播帧不断被复制、转发、再复制。一个广播帧从交换机 A 的某个口出去经过交换机 B 又从另一个口回到交换机 AA 再泛洪到所有口如此循环最终广播帧数量指数膨胀网络彻底瘫痪。在这个过程里泛洪是广播风暴传播的必经动作但根因是环路不是泛洪。所以遇到广播风暴第一反应应该是查 STP 状态、找物理环路而不是一味地压低风暴抑制阈值。把环路剪断泛洪自然就停了。6.3 经常被误判为泛洪故障的其他原因排查故障时不要把注意力全锁在泛洪上。以下情况同样会造成类似症状端口协商异常某台设备变成了半双工导致大量冲突和重传网卡故障发出大量错误帧交换机不停转发这些坏帧光模块或网线质量差CRC 错误帧很多影响转发效率上下联带宽不匹配比如摄像头接到百兆口而流媒体服务器接到千兆口瞬时流量超过百兆口能力。所以完整排查思路应该是先确认物理层没问题再看二层协议状态然后看流量特征最后才去动风暴抑制和端口安全配置。6.4 一句话回答泛洪到底好不好既有用又危险。它是交换机在不知道目标在哪时的兜底机制保证网络不会因为一次查表失败就丢包但它同时也是广播风暴、MAC 泛洪攻击、组播流量泛滥的传播通道。网工的职责不是消灭泛洪而是控制泛洪的影响范围让正常协议能跑异常流量能被掐住。我个人做网络底稿时有个习惯所有接入端口默认开风暴抑制和端口安全收敛广播域核心上联口只做必要的信任配置其余全关每季度看一次 CAM 表利用率和各端口广播/组播占比。多数泛洪问题都能在这个节奏里被提前发现而不是等到用户投诉才去救火。交换机泛洪这个知识点说到底是二层交换的基石。把这个机制吃透了再去看 STP、VLAN、组播、端口安全这些内容会顺畅很多。尤其是刚入行的网工别急着学各种命令行高级配置先把数据帧进交换机后到底经历了什么想清楚后面所有排障思路都会有根。
