以太网交换机原理：MAC表、VLAN、STP与三层转发实战

很多人可能跟我一样，第一次真正接触以太网，不是从教材开头啃起，而是拿着一条网线往笔记本上一插，看到屏幕右下角的小图标从红叉变成正常，然后就开始选课、看视频、刷新闻了。我当年也是这样，直到后来有段时间蹲在机柜旁边看交换机指示灯闪烁，才意识到：以太网能跑起来，背后其实是大量设备在不停地“做决定”。这个系列的第一篇聊了以太网的起源、冲突检测和集线器时代的半双工，这篇就顺着往下走，重点说说从交换机出现之后，数据帧在二层网络里到底是怎么流转的，顺便把VLAN、生成树、跨VLAN路由这几件绕不开的事讲透。

1. 从冲突域到交换域：以太网的关键转折

1.1 集线器时代的“车多路窄”

上篇聊过最早期的以太网，一根同轴电缆串联所有设备，谁要发数据，先在总线上听一听有没有其他人在发（载波侦听），没人发才开口，一旦同时开口就撞车，撞完车需要退避一段时间再重发。这套机制叫CSMA/CD，本质就是一条“公共走廊”上大家自觉排队。到了后来用集线器组网，情况也没好到哪去——集线器本质上是把收到的信号复制给所有端口，发数据的人占用的还是那一整段带宽。

举个直观的例子：一台24口的集线器，如果每个端口接的都是一台电脑，整台设备只有100Mbps的带宽，24台电脑必须分着用。更要命的是所有设备都在同一个冲突域里，A往B发数据，C、D、E的网卡也会收到这个信号，只是根据目标MAC地址判断不是自己需要的帧，然后丢进垃圾堆而已。效率有多低，想想办公室里二十几个人合用一部电话就明白了。

所以集线器时代，网络经常出现“一用起来就很慢”的现象，不是因为带宽真不够，而是因为大量的冲突退避占用了时间。CSMA/CD的“碰撞后等待随机时间重发”机制在设备少、流量小的时候还行，设备一多、包一密集，重传就会像滚雪球一样涌过来。

1.2 交换机让每条路都变成独立车道

交换机的出现，是从根上改变了这个局面。交换机转发数据不是靠广播，而是靠内部的交换矩阵和MAC地址表，每个端口都可以同时收发数据，而且互不干扰。也就是说，A和B在通信的时候，C和D也可以同时通信，大家用的是各自的独立带宽。这个改变直接消灭了“所有设备抢一条公共走廊”的问题，也把冲突域缩小到了“端口到网线另一端的设备”这一条线上。

还有一个容易被忽略的变化：全双工。同一根网线的两对线，交换机端和终端设备可以同时发、同时收，于是100Mbps端口的理论速率直接变成双向各100Mbps，不存在“发的时候必须等收完”这种事了。既然全双工模式下不存在碰撞，CSMA/CD在这个场景里基本退役，所以后来千兆、万兆以太网里，你几乎听不到“冲突”这个词。

我自己一直觉得，理解以太网的关键不在于记IEEE 802.3标准里那一堆缩写，而在于搞清楚“数据在哪一层被决定怎么走”。集线器时代，设备是佛系转发节点，广播到底；交换机时代，分工明确，精确投递，这背后靠的就是下面要讲的MAC地址表。

1.3 MAC地址表：交换机的“通讯录”

交换机刚开机时，MAC地址表是空的。它怎么知道往哪个端口转发数据？答案是学。交换机每收到一个帧，都会做三件事：

• 记录帧的源MAC地址，以及这个帧是从哪个端口进来的，写入MAC地址表，同时刷新老化计时器；
• 查找目的MAC地址，看这张表里有没有匹配项；
• 有匹配项就只从对应端口转发出去；没有匹配项，就把帧向除接收端口以外的所有端口转发（这叫泛洪）。

整个过程看起来简单，但非常关键。MAC地址表默认老化时间通常300秒，也就是说如果一个设备长时间不发数据，交换机就会忘了它，下次再来数据就得重新学习。你可能会问：那网络里那么多设备，这张表不是要爆炸？并不会，因为MAC表是存在交换芯片的硬件表项里，正常情况下几千条表项对一台几十口交换机的芯片来说完全不是压力。

这里有个值得注意的细节：交换机会把源MAC学习到“接收端口”上，但如果你私自改了电脑网卡的MAC地址，交换机会在同一个端口上学到不同的MAC，表项会更新，这在排查“是不是有人冒用了我的IP/MAC”时是很好的线索。在网络设备管理后台看到MAC表异常跳动，往往是链路环路的早期信号，这一点在后面的章节还会细说。

2. 一个帧的旅程：MAC寻址与转发决策

2.1 以太网帧布局：数据开口前要做的事

讨论工作原理前，先得把以太网帧本身看清楚。标准以太网帧从前往后大致是这几个部分：前导码和帧起始定界符、目的MAC地址、源MAC地址、类型/长度字段、数据负载、帧校验序列。前导码算物理层的引导信号，很多书会把它们放在帧外面，真正转发时关注的是后面这几项。

这里最需要注意的是：帧里面从头到尾，没有任何“IP地址”字段，目的和源MAC地址才是二层的“门牌”。IP地址在三层报文里，被当作数据负载的一部分打包在以太网帧里。所以当你抓到包看到一个ARP请求里面全是FFFF.FFFF.FFFF这种广播地址时，别怀疑网卡是不是坏了，这只是因为在二层向所有人提问“谁是某个IP”。

帧尾部是FCS，通常是CRC32校验值。FCS的作用是让接收方知道这个帧在传输过程中有没有被篡改或损坏。接收方收到帧后会重新算一遍校验码，跟帧尾的FCS对比，不一致就丢弃。所以网络上的“噪声”干扰对以太网并不是毫无影响，只是被FCS这一层防线过滤掉了，你只会看到丢包率上升，而不会直接看到收到“错的内容”。

2.2 单播、广播、未知单播的三种命运

一个帧到了交换机，根据目的MAC地址的不同，处理方式完全不同。大致分成三种情况：

• 目的MAC是某个具体设备的单播地址，且MAC表里有记录：交换机精确转发，只从对应端口出去，这是最理想的情况，效率最高。
• 目的MAC是广播地址（FF:FF:FF:FF:FF:FF）：交换机必须向除了接收端口以外的所有端口转发。这是以太网虽然高效但带着的一个“历史包袱”，后面广播域的问题就出在这里。
• 目的MAC是单播地址，但MAC表里没有记录（未知单播）：交换机没法判断该往哪走，只能先泛洪，让目标设备收到后回一个帧，交换机才能学到它的位置。

很多人第一次看交换机转发原理时会觉得“未知单播也泛洪太蠢了”，但换个角度想，如果交换机不泛洪而直接丢弃，那这个帧就永远送不到了。泛洪是二层网络保证可达性的兜底手段，代价就是浪费一部分带宽。这也是为什么“二层网络规模不能无限扩大”——人越多，未知单播和广播越多，交换机消耗在这些无谓帧上的资源就越多。

2.3 ARP：IP地址与MAC地址之间的翻译官

好了，现在最关键的来了。网络层关心的是IP地址，但以太网帧只认MAC地址，那“我跟你用IP通信”和“我在以太网上发给MAC”这两件事是怎么衔接的？答案就是ARP（地址解析协议）。

ARP工作流程描述起来非常简单。假设PC1要跟同一网段的PC2通信，PC1的IP协议栈先判断出目标IP和自己在同一个网段，于是需要把目标IP“换算”成MAC地址。PC1先查自己的ARP缓存表，没有对应表项，就发一个ARP请求：目标MAC是广播地址，内容是“谁是192.168.1.2，请把MAC地址告诉我”。这个请求会被交换机泛洪到全网段。PC2收到后发现问的正是自己，回一个ARP响应，目的MAC是PC1，内容是“我是192.168.1.2，我的MAC是XX:XX:XX:XX:XX:XX”。PC1收到响应，把映射关系写进ARP缓存，之后就可以封装以太网帧发送了。

我建议新手都去看一次这个完整交互，方法很简单，在PC1上ping一下PC2，同一时间在PC2上开抓包工具，过滤“arp”，你几乎每次都能看到这个请求-响应成对出现。看完你会发现很多抽象概念一下子落地了：广播、单播、二层寻址、三层寻址的分工，全都在这两个包里体现得淋漓尽致。

另外还有一个概念叫免费ARP（Gratuitous ARP），设备在IP地址配置成功时，会主动向全网发一个ARP请求，问“这个IP是谁的”。它有两个作用：一是检测IP冲突，如果有人回应，说明这个IP已经被占用；二是让网络中所有交换机快速学习到这台设备的MAC地址。如果你在抓包里看到自己网段里有设备在发免费ARP，说明那台设备刚开机或者刚换了IP，属正常现象。

3. 当二层网络变大：广播域膨胀与VLAN隔离

3.1 广播风暴：一张大网里的“噪音污染”

前面说过，广播帧到达交换机之后会被复制到所有端口。一个二层网络里，只要有两个以上设备，就不可避免地存在广播，比如ARP查询、DHCP的Discover请求、还有一些服务协议的发现报文。设备少的时候没关系，但一旦网络里接了几百台终端，广播帧的总量会非常可观。

举个例子：我曾经在办公区接过一次“全员网络卡顿”的工单，所有终端ping网关都丢包，但测速又不是全零。最后查下来，是某个设备网卡故障一直在快速轮询，每秒钟发出几百个广播帧，整张网的交换机都在转发，CPU负载升高，正常数据的转发就被拖慢了。这种场景就像大家在一条安静的马路上正常开车，突然有人按着喇叭超速来回冲，所有车都得给他让路。

广播风暴之所以难查，是因为发起者往往不是某一台核心设备，而是某个不起眼的终端或者网卡的Bug。要限制它的影响范围，就要把网络从物理意义上拆分——拆出来的那一块块区域，就叫广播域。VLAN（虚拟局域网）就是干这件事的。

3.2 VLAN：用逻辑方式给广播域砌墙

VLAN的思路非常朴素：在同一台物理交换机上，通过配置把端口划分成多个逻辑网络，每个VLAN内部是一个独立的广播域，VLAN之间的广播不会互相穿透。比如一栋楼里财务部门、技术部门、行政部门，你可以让它们在物理上接同一台交换机，但分属VLAN 10、VLAN 20、VLAN 30，这样财务部门发个广播，技术部门根本感知不到。

VLAN ID理论上范围是0到4095，可用的一般是1到4094。为什么上限是4094？因为802.1Q标准里VLAN标签字段占了12个bit，2的12次方就是4096，其中0和4095保留。这个数字现在看起来没什么，但在设计当年已经算很大，后来网络设备又搞出各种双标签、运营商QinQ，都是在原始限制下的扩展。

划分VLAN不只是为了隔离广播，它同时解决了网络管理的问题：同一VLAN里的设备可以用同一个子网规划IP，移动终端时只要端口配置对，重新插上就能通信。还有一个很现实的原因——安全。两个部门物理上共享一台交换机时，VLAN隔离能防止未授权的访问，二层访问被天然切断，连数据包都过不去。

3.3 802.1Q标签与Access/Trunk的配合

划分VLAN之后，帧在交换机之间传递时必须携带VLAN信息，否则对端的交换机就不知道该把它划到哪个广播域里。这就是802.1Q干的事：在以太网帧的源MAC地址和类型字段之间插入4字节的VLAN标签，其中包含12位VLAN ID。加了标签之后，帧的最大长度从传统1518字节变成1522字节，这个细节在考虑MTU和巨型帧时非常重要。

说到端口类型，最常用的两种是Access口和Trunk口。第三方接入终端用的通常配成Access口，这个口进来的帧默认打上某个VLAN的标签；往交换机之间互连用的通常配成Trunk口，它允许承载多个VLAN的帧，每个帧都带着标签。有人会把Trunk口叫“主干口”，从名字也能理解：链路本身对VLAN是透明的，它只是负责搬运各种标签的帧。

配置VLAN时有一个隐藏难点是不带标签的帧落到Trunk口上到底算哪个VLAN？这就要提Native VLAN（本征VLAN）了。802.1Q规定，Trunk口上的帧如果不打标签，默认属于本征VLAN。两台交换机必须把本征VLAN配成一致，否则一个打标签一个不打标签，两边谁也认不出谁。我见过不少跨交换机VLAN不通的故障，最后都出自这个小小的本征VLAN配置不一致。配置逻辑大致是这样：先创建VLAN编号，再把终端接入的物理端口划到对应VLAN里，最后把交换机的上联互端口配置成Trunk并放行需要跨交换机传递的VLAN号。很多人容易漏最后一步，结果本端VLAN配好了，对端也配好了，中间Trunk口只放了默认的VLAN 1，跨交换机的业务一直不通。网上各种配置教程很多，但我想强调的还是那句：不管用什么厂商的设备，先把“这个口是Access还是Trunk、Trunk又允许了哪些VLAN、本征VLAN是谁”这三件事搞清楚，VLAN这块基本就稳了。

4. 环路与生成树：二层网络的自我防卫

4.1 冗余链路是双刃剑

实际组网中，没人敢只留一条链路连接交换机——设备断电、网线被老鼠咬断、光模块自然老化、甚至某个接口因为灰尘接触不良，任何一种故障都会让整段网络瘫痪。所以稍微正经一点的组网设计，都会在两台交换机之间布置两条甚至更多条物理链路，实现冗余。想法很美好：一条断了，另一条顶上，网络几乎无感知。

问题是，这么做的后果往往不是“高可用”，而是“高事故”。二层网络并没有TTL（生存时间）这种“包只活N跳”的机制，帧在环路里会被无限转发。如果网络里存在物理环路，一个广播帧从交换机A的端口1进来，会被从端口2转发出去，到了交换机B，B又从它的端口2转回来给A，然后A又把这一帧复制到所有端口……循环往复，广播帧像滚雪球一样越滚越多，最终把交换机的CPU和背板带宽淹没，这就是环路导致的广播风暴。同时交换机的MAC表也会因为“同一个MAC一会儿在端口1一会儿在端口2”而反复震荡。

很多人以为环路只出现在两台交换机之间看着像“环”的连接里，其实一台交换机自己的两个端口用一根网线对接，也成环；三层设备下挂两台交换机之间互联，同样是环。所以组网完第一件事，不是关心速率，而是确认有没有未受保护的环路。

4.2 STP选举：根桥、根端口与指定端口

生成树协议（STP）解决的正是这个问题。它的思路听起来有点“霸道”：物理环路照常存在，但在逻辑上把网络修剪成一棵无环的树，多余的端口被放入阻塞状态。等某条正常链路断掉后，被阻塞的端口再苏醒，切换到转发状态，保证冗余的作用还在。

STP的算法核心是一次分布式选举。整个交换网络会先选出一个根桥（Root Bridge），标准是比较BID，BID由优先级和MAC地址组成，优先级低（数字小）的优先，优先级相同看MAC地址小。根桥是整个树逻辑上的“根”，所有数据路径都以它为起点规划。然后每台非根桥上选出一个根端口（Root Port），这个端口是这台交换机通往根桥的最短路径。接下来每条链路上选一个指定端口（Designated Port），负责在这段链路上转发帧。剩下的端口就是阻塞端口（Blocking Port），只接收BPDU，不转发数据帧。

这里有个经验之谈：如果你有多个交换机，希望某个性能更好的交换机成为根桥，却不能随便改MAC，正确做法是把它的STP优先级数值调小，通常推荐调到比默认32768小很多的值，比如4096，让其余交换机保持默认或更大的优先级。不同厂商命令行不一样，但逻辑都一样，无非是一个优先级数值的配置。

4.3 RSTP：把50秒收敛压缩到秒级

传统STP最被人诟病的就是收敛速度。从链路故障到端口切换到转发状态，需要先经过阻塞、监听、学习这几个计时器阶段，加起来最大可能要50秒。在现代网络里，50秒的网络中断对应用来说完全不可接受，所以RSTP（快速生成树协议）出现了。

RSTP对端口角色做了扩展，分为根端口、指定端口、替换端口和备份端口，同时改进了协商机制：指定端口在接入时会主动向对端发送一个提议报文，对端如果同意，立即回一个同意报文，链路状态直接进入转发，省掉了等待时间。正常情况下RSTP在链路故障后可以在几秒内完成收敛。

我实际测过，单条链路断开到备用链路接上去，RSTP的收敛时间通常在2-3秒以内，很多场景甚至低于1秒，这对普通办公网络和数据中心都够用了。重点提醒一下：如果你在交换机上看到端口状态长时间停留在learning或listening而不是直接跳到forwarding，那多半是STP配置有问题，或者设备之间参数不匹配。查看生成树状态时，我更关心两列：端口角色和端口状态。角色应该是根/指定/替换之一，状态应该是转发或阻塞，一旦看到“不明角色”或者端口全部阻塞，先查环路和优先级配置。

5. 跨VLAN通信与三层交换：从二层走向三层

5.1 物理路由器与单臂路由方案

VLAN把广播域隔开了，代价是不同VLAN之间默认完全不能通信。但实际业务里，财务部门要访问服务器、技术部门要连开发环境，跨VLAN通信是刚需，这就需要三层设备来路由。

最早的经典做法叫“单臂路由”：把一台路由器的物理接口分成多个逻辑子接口，每个子接口绑定一个VLAN ID，再给每个子接口配上对应VLAN的网关IP。交换机上把连接路由器的口配成Trunk口，允许相关VLAN的帧通过。数据到达路由器后，路由器看到目的IP不在同一子网，查路由表，从对应子接口发出去。整个过程相当于路由器一条胳膊伸进VLAN世界里挨家挨户收投递。单臂路由原理清晰、配置简单，但瓶颈很明显：所有跨VLAN流量都在同一条物理链路上转发，链路带宽就是天花板，流量一多就成瓶颈。

5.2 三层交换机里的虚拟网关

现代的方案几乎都用三层交换机。三层交换机的本质是“二层交换引擎+三层路由引擎”合体，只不过它把路由做得非常快，常见做法是通过VLANIF接口（也叫SVI、逻辑虚拟接口）来实现网关。给VLANIF接口分配IP地址，这个IP就是该VLAN内终端的网关地址，交换机内部能直接按三层的思路转发，不再需要外部路由器。

对比一下单臂路由和三层交换：单臂路由依赖物理链路，带宽受限；三层交换在三层报文进来时，可以在交换芯片内部完成后查表转发，走了高速通道，不仅延迟低，还能做到硬件线速转发。关键点在于，VLANIF接口只是逻辑上的三层路由接口，它本身没有物理端口，但每个VLAN内的终端只要网关指向它，就能在三层交换机内部完成路由。配置上也很直白：给每个VLAN的虚拟接口配上IP，让终端把网关指到这个IP上，三层交换机自己就会处理VLAN间的转发。

5.3 一次完整ping背后的完整数据流向

这部分是我最想让你掌握的，因为理解了它就理解了“局域网内数据包到底怎么走”。假设有两台PC：PC1在VLAN 10，IP是192.168.10.2/24，网关是192.168.10.1；PC2在VLAN 20，IP是192.168.20.2/24，网关是192.168.20.1。两台设备接在同一台三层交换机上。现在PC1去ping PC2。

第一步，PC1检查目标IP和自己的IP是否同网段。发现在192.168.20.0/24，不在本地网段，于是不直接ARP询问PC2，而是先查ARP缓存表，获取网关192.168.10.1的MAC地址。如果缓存没有，就发一个ARP请求：“谁是192.168.10.1”。

第二步，交换机收到这个ARP请求，判断目的MAC是广播，把这请求泛洪到整个VLAN 10内，最终答应的不是别的设备，而是交换机自己，因为它就是VLAN 10的网关。交换机回一个ARP响应，告诉PC1：网关的MAC是VA-VA-VA-VA-VA-VA。

第三步，PC1把ICMP请求报文封装成IP包，目的IP是192.168.20.2，然后封装成以太网帧，目的MAC写的是网关的MAC。这帧到达三层交换机后，交换机看到目的MAC是自己的网关MAC，就知道这是“要出三层”的包，于是剥离二层帧头，走到三层路由流程。

第四步，三层交换机查路由表，发现192.168.20.0/24就在自己身上，对应VLAN 20的VLANIF接口。于是把这个IP包重新封装进一个新的以太网帧，目的IP还是192.168.20.2，但目的MAC呢？现在PC2的MAC未知，那得先ARP一下，交换机在VLAN 20里发ARP请求，找出192.168.20.2对应的MAC，PC2回应后，交换机就能发出目的MAC为PC2的帧。

第五步，PC2收到帧，去掉MAC头、IP头，看到ICMP请求，构造ICMP回显，按同样的流程返回PC1。整个流程走完，ping才显示通。

你会发现一个很核心的规律：整个过程中，源和目的IP从未改变，但源和目的MAC每一跳都在变；三层设备负责重新封装二层头，二层设备只看MAC做转发，这就是计算机网络分层设计最精妙的地方。我在给团队新人讲的时候经常用一句人话总结：“IP是门牌号，MAC是身份证，门牌号决定你去哪栋楼，身份证决定快递员把包裹送到哪个人手上。”

6. 实战排查：用表驱动的方法定位二层故障

6.1 第一件事永远是看MAC地址表

网络出了问题，比如某台终端突然ping不通网关，很多人第一反应是重启终端、重启交换机，我恰恰不建议这样。重启会清空设备的运行状态，很多有用的线索（MAC表、ARP缓存、端口统计）就没了。正确做法是先从管理后台拿到这台终端对应的交换机端口信息，看看MAC地址表里还有没有这台终端的MAC表项。

MAC表的查看命令在不同厂商那写法不太一样，但逻辑无外乎看三列：VLAN、MAC地址、端口，命令的大致形式是show mac address-table。如果你在交换机上查不到某终端的MAC，说明二层链路就有问题，比如网线没通、端口down、VLAN没放通；如果查到了，但对应端口不是终端实际接入的端口，或者同一MAC在两个端口上都出现，那基本可以断定出现了环路或有人改MAC。

我自己总结的检查列表，按优先级排：首先，端口状态有没有up；其次，MAC表里有没有目标设备；然后，看端口所属VLAN和终端实际VLAN是否一致；最后，看端口收发包计数是否在增长。这套组合拳能解决大部分看似玄学的联通性问题。

6.2 ARP异常：抓包能看到那些“奇怪”的包

当链路正常但网络还是很慢时，就需要抓包了。抓包工具建议过滤三个方向的内容：只过滤ARP，看ARP包的数量；只过滤ICMP，看数据延迟；过滤广播，看广播占比。

有一次我在一个二层域里排查“周期性卡顿”，抓包过滤ARP后发现平均每秒钟有几十个广播ARP请求，而且都来自不同主机，不是某一台在捣乱。再深挖才发现是有人把IP配错了，让两台终端用同一个IP，双方都在不停发免费ARP抢地址。这种现象一旦发生，整网都会受影响。通过抓包定位后，把重复IP的其中一台改成正确IP，问题立刻消失。所以遇到网络“又卡又没断”的情况，ARP计数和重复地址是必查项。

6.3 常见故障速查与我的排障顺序

最后整理一张简洁的速查表，方便你对照症状找方向。

这是基本的排障思路。但在实战里，我更推荐的顺序是四步走：第一步，画拓扑，把设备、端口、VLAN、IP标注清楚；第二步，从源设备开始，沿着数据路径逐跳看ARP缓存和MAC表，哪个环节断了就去修哪；第三步，链路层全部正常后，才开始看三层网关和路由表；第四步，所有正常但性能差，抓包统计广播和异常流量。

这四步看着简单，但尤其适合网络基础还不牢的人，因为它逼着你始终掌握“数据往哪走”“应该走哪条路”这两个核心概念，不靠猜，不靠重启解决一切。

我自己后来带人排查网络问题时，一直强调同一个观点：二层的问题别在三层找，MAC表看明白了，再看ARP、再看路由，一层一层往下剥。真正的网络原理，不是你背了多少协议名字，而是从一张MAC表里，能看出这台设备几秒钟之前发生过什么。这篇文章写到这里，其实也只完成了从集线器到三层交换这半段旅程，后面还有链路聚合、QinQ、大二层这些东西，等下一篇再继续踩坑。