1. 二层转发的底层逻辑：不是路由，而是查表、泛洪与老化
很多刚入行的朋友容易把“二层转发”和“路由”搞混，一听到转发就觉得是交换机在做“路径选择”。其实二层转发根本不选路，它只做三件事：学习源MAC、查找目的MAC、决定丢弃或泛洪。这三件事每天都在交换机的每一个端口上重复成千上万次，原理并不复杂，但真正能把它讲透、用对的人并不多。
1.1 MAC地址表是转发的唯一依据
每一台交换机内部都维护着一张MAC地址表（也叫CAM表或转发表）。这张表记录了三个核心内容：MAC地址、所属VLAN、对应的出接口。交换机转发一个二层帧时，唯一的依据就是这张表：查得到目的MAC就单播转发，查不到就泛洪，查到源MAC是自己某个接口才可能丢帧（防环回）。
MAC地址表的建立不需要手动配置，完全靠“学习”自动完成。举个例子，主机A接在交换机的GE0/0/1口，当它发出第一个帧时，交换机会提取帧头里的源MAC地址，把它记录到表里，并绑定GE0/0/1口。这就是“源MAC学习”。所有转发的正确性，都建立在每个MAC只被学到正确端口这一前提上；一旦这个前提被破坏（比如环路、接错线、伪造MAC），二层转发就会出现各种诡异故障。
1.2 一个完整的数据帧在交换机内部的旅程
我习惯把二层转发拆成四个步骤，排查时按这个顺序捋，基本不会漏：
- 接收与校验：端口收到一个以太网帧，先查帧校验序列（FCS）是否正确，错误帧直接丢弃。
- 学习源MAC：提取源MAC，更新MAC地址表。如果这个源MAC已经存在但端口不同，表项会被更新到新端口，这就是“MAC漂移”的由来。
- 查找目的MAC：用目的MAC查MAC地址表。
- 执行动作：查到了就往对应端口单播转发；查不到，就在这个帧所属VLAN内的所有端口泛洪（除接收端口外）；如果目的MAC是广播地址或组播地址，同样需要泛洪。
正常业务中，绝大多数帧是单播帧，所以只要MAC表完整，转发效率非常高。但很多人忽略了：第一次通信时，由于MAC表还没有目的地址表项，帧必然是泛洪的。这也是为什么在大型广播域里，新设备上线瞬间会产生一波广播/泛洪流量。等通信双方互相学习完MAC，后续帧才转为精确单播转发。
1.3 老化时间与反复学习的实战含义
MAC地址表不是永久保存的，每条表项都有老化时间。华为、H3C以及绝大多数主流交换机，默认老化时间是300秒（思科也是类似，部分型号默认为300秒或可调）。这意味着如果一台设备超过5分钟没有任何流量，它的MAC表项就会被清掉，下一次通信需要重新泛洪学习。
这个机制平时没什么存在感，但在排查“断断续续、时通时不通”的问题时非常关键。我遇到过一台服务器在夜间备份时总是延迟很高，后来发现是因为备份窗口里服务器基本只收包不发包，MAC表项老化后，回程流量一直在泛洪，导致网络质量波动。解决办法很简单：对关键服务器的MAC表项做静态配置，或者临时调长老化时间，比如用mac-address aging-time 600（华为/H3C命令）这类手段处理。
2. VLAN与广播域：二层转发为什么天然被“圈”在VLAN内
二层转发的另一个核心特征是“广播域”。在没有VLAN的纯二层网络中，一台设备发广播，广播会送到交换机上除源口外的所有端口。接入设备一多，广播流量互相干扰，安全性也几乎没有。VLAN的出现就是用来切分广播域的：每个VLAN就是一个独立的广播域，二层帧只能在同一个VLAN内部转发。
2.1 Access口与Trunk口在转发时的真实差异
每台交换机端口都有链路类型，最常见的是Access（接入）口和Trunk（干道）口。两者的本质差异不是“能不能传多个VLAN”这么简单，而是帧如何处理VLAN标签（802.1Q Tag）：
- Access口：端口划分给一个固定VLAN，通常接终端设备。发往Access口的帧不带Tag；进入Access口的帧，会被交换机打上该端口所属VLAN的Tag。
- Trunk口：端口允许传输多个VLAN的帧，帧本身携带802.1Q Tag；交换机通过Tag识别帧属于哪个VLAN，才能把帧正确转发到对应VLAN内的端口。
因此，Trunk口上能同时跑多个VLAN，靠的不是什么魔法，而是帧里的VLAN ID标记。Access口则简单粗暴：一个口一个VLAN，进出都打统一标签或去掉标签。
搜索热词里提到“接入配置access后2个PC可以互通”“接入口配置trunk并放通VLAN”，这两句话其实描述的是同一个场景的正反两面：两个PC接入同一交换机的Access口且属于同一个VLAN，自然互通；如果这两个PC的接入端口被配成Trunk，还想互通，就要求Trunk放通正确的VLAN，而且对端设备（比如另一个交换机）也必须以Trunk方式对接，标签才能生存传递。
2.2 同一个VLAN内的通信到底怎么通
假设交换机上有两个PC：PC-A和PC-B，都在VLAN 10。PC-A发一个帧给PC-B，帧头带上VLAN 10的Tag（或由Access口打上Tag），交换机在VLAN 10的范围内查MAC表，找到PC-B的MAC对应端口后转发过去。整个过程完全没有IP层的参与，哪怕两台PC的IP不在同一网段，只要二层通，帧也能到对方手里，但对方会因为IP不匹配而丢弃——这就是“二层通、三层不通”的典型场景：二层转发只看MAC和VLAN，不看IP。
这一点必须记住，因为在排查问题时非常容易把人带偏：你从PC-A ping PC-B，如果两台PC IP不同网段，ping不通是很正常的，但很多人的第一反应是去查交换机配置，其实二层根本没毛病。真正的问题是三层网关和路由缺失。
2.3 跨VLAN通信为什么一定要上三层
VLAN把广播域隔离了，同时也把二层转发圈死了。跨VLAN的帧绝不会被交换机“顺便”转到另一个VLAN——这样做等于撕裂了VLAN的隔离边界。所以跨VLAN通信必须借助三层设备，也就是路由。常见的实现方式有三种：
低成本方案是路由器转发；传统方案是单臂路由（路由器子接口）；主流方案是三层交换机上配置VLANIF接口实现VLAN间路由。
关于单臂路由多说一句：很多教程喜欢用它演示VLAN间通信，但实际生产场景中单臂路由存在吞吐瓶颈（所有跨VLAN流量都挤在一个物理链路和路由器CPU上），所以只适合小规模实验环境。真正的生产环境，稍维护一点的网络都会用三层交换机来做VLAN间路由，直接在每个VLAN上配置VLANIF接口作为网关。
3. 跨VLAN通信的门槛：网关、ARP与三层交换机的配合
跨VLAN通信是“二层转发+三层路由”的联合动作。很多人卡在这里，是因为没搞清网关和ARP在这个过程中到底扮演了什么角色。
3.1 网关的作用：替终端把帧“递”给路由器
假设PC-A在VLAN 10（IP 192.168.10.2），PC-B在VLAN 20（IP 192.168.20.2），两台PC要通信。PC-A发现目的IP（192.168.20.2）和自己不在同一网段，就知道不能直接二层发给PC-B，而必须把帧发给网关（192.168.10.1）——也就是三层设备上VLAN 10的接口地址。这个网关地址，就是PC-A眼中“负责帮它跨网段转发的那个设备”。
所以，PC-A发出的数据帧，目的MAC是网关的MAC，目的IP是PC-B的IP，源则是PC-A自己的MAC和IP。交换机收到这个帧后，按二层规则转发——把帧送到网关所在端口（三层交换机上大概率就是VLANIF接口对应的端口或VLAN内端口）。这其实还是一个二层转发过程，只是“目的MAC”变成了网关的MAC。
3.2 ARP在这个过程中的关键位置
这里出现一个隐蔽环节：PC-A怎么知道网关的MAC？答案是发ARP请求。ARP请求是一个广播帧，目标MAC是全F（FFFFFFFFFFFF），在VLAN 10内泛洪，网关收到后回复自己的MAC地址。PC-A拿到网关MAC之后，才能封装出那个“目的MAC=网关MAC”的数据帧。
同样，网关要转发数据给PC-B时，也需要知道PC-B的MAC。它会在PC-B所在的VLAN 20里发ARP请求，拿到PC-B的MAC后再封装帧转发过去。所以，每一次跨VLAN通信，外表看是IP路由在导，本质上是三层设备在替两端做“ARP中介”。如果中间某个环节ARP失效（比如VLANIF接口没启用、网段掩码配错、物理链路不通），通信就会卡死，而二层转发层面看起来一切正常。
3.3 三层交换机的转发细节：一次路由，多次交换
三层交换机处理跨VLAN流量时有个经典机制：“一次路由（Route once），多次交换（Switch many）”。第一个数据包到达三层引擎后，三层交换机会解析路由并学到下一跳的MAC信息，然后在硬件转发表中直接建立一条“IP转发捷径”（如华为的硬件路由表 / 思科的CEF表）。后续同一条流的数据包不需要再上送CPU做路由查询，直接按硬件表项二层封装转发，转发速度可以做到线速。
这就是为什么三层交换机比传统路由器+二层交换机的组合更流行。但要注意：三层交换机的VLANIF接口必须处于Up状态，并且两个VLAN之间要有可达路由，否则即使二层MAC表学得再好，跨VLAN流量也是到不了对端PC的。
这里顺带提一个常见故障：华为交换机接思科三层交换机，包无法转发。我在实际工作中遇到过好几次，原因往往不是二层配置错误，而是三层路由协议或VLANIF接口配置不匹配。比如华为侧把某个VLANIF配置了不同网段，思科侧用另一个网段，两边路由表互相不可达；或者两边Trunk放通的VLAN列表不一致，导致某些VLAN的包在Trunk上被直接丢弃。排查时先确认二层通不通（在两端交换机上互相ping VLANIF地址），二层通了再查三层路由通告和策略，这个顺序千万不要倒。
4. ACL单向访问的配置真相：二层只能通，控制必须落到三层
搜索热词里出现“华为交换机ACL单向访问不管用”“如何让A能访问B但B不能访问A”，这个问题我几乎每个月都会遇到。很多人把ACL配在了接口的入方向，结果要么两边都通，要么两边都不通，就觉得很邪门。
4.1 为什么二层转发机制与ACL“单向”相悖
二层的转发是双向的不是有意为之的——而是因为二层转发只看MAC和VLAN，MAC地址表本身就包含双向通信的记录。交换机为了实现双向通信，必须让A到B和B到A的帧都能被正确转发。你如果在二层交换机上配置一个VLAN内的ACL想实现“A到B通、B到A不通”，就等于要求交换机在转发B的回包时丢弃它——这不光是策略问题，更是协议行为的底层逻辑问题：TCP/IP通信是请求-响应模型，B给A的回包是本次通信的正常组成部分，不是独立业务。
因此，真正的“单向访问”控制，必须放在三层，也就是通过ACL控制转发决策，而不是二层转发。在三层交换机上，ACL作用于一个VLANIF接口的入方向或出方向，它检查的是IP五元组（源IP、目的IP、协议、源端口、目的端口），而不是MAC表。
还有一点想提醒：即使在三层，单向ACL也未必是“A能访问B、B不能访问A”这么简单，而是要区分“访问”和“响应”。比如你想让A能访问B的Web服务，而B不能访问A的任何服务，你可以在到B方向的ACL放行A访问B的流量（源A到目的B的80端口），同时在B到A方向的ACL拒绝其他流量。这样A发起请求、B返回响应，响应属于已经建立的会话，通常用状态化防火墙才行；纯ACL是无状态的，需要设计好两方向的规则，否则会拦掉正常响应。
4.2 华为交换机单向访问的配置示例
下面给一个在华为交换机上实现“A（192.168.10.2）能访问B（192.168.20.2），但B不能访问A”的经典配置思路。假设三层交换机上VLAN 10和VLAN 20均已配置VLANIF接口，并且转发已通：
# acl number 3001 rule 5 permit ip source 192.168.10.2 0.0.0.0 destination 192.168.20.2 0.0.0.0 rule 10 deny ip source 192.168.20.2 0.0.0.0 destination 192.168.10.2 0.0.0.0 # interface Vlanif10 traffic-filter inbound ip-group 3001 rule 10 #需要注意的点有三处：一是ACL规则编号的顺序很关键，华为ACL按规则号从小到大匹配，先匹配先生效；二是在VLANIF 10的入方向拒绝B到A的流量，这样B发往A的包在到达VLANIF 10之前就被丢弃；三是这里只是基础配置，生产环境往往还需要放行ARP、DHCP等协议，否则会造成额外的“通则不通”问题。
4.3 双向通信与状态化防火墙的边界
我还要强调一个概念：传统ACL是无状态的。你放行了“A→B的TCP 80端口”，B返回的SYN-ACK包源端口是80，目的端口是A的随机端口，如果不放行对应方向，回包就会被自己的ACL拦掉。所以“单向访问”要实现得优雅，很多情况下需要借助高级ACL（如华为的advanced ACL可以匹配TCP的established标志位）或直接上防火墙做状态化会话处理。交换机自带的ACL适合做粗粒度的隔离，不适合做精细的会话级双向控制。
说白了，二层转发决定“能不能通到端口”，三层ACL决定“这个包允不允许被路由”，防火墙决定“这个会话合不合法”。三者分工不同，不要指望用一个二层交换机的ACL解决所有问题。
5. 实战排查技巧：从交换机接口ping到DHCP、再到MAC表与环路问题
排查交换网络故障，最忌讳一上来就重启设备或乱改配置。我习惯按“物理层→链路层→网络层→上层业务”逐层排查。这里把搜到的高频排查问题集中展开讲。
5.1 从交换机指定接口发起ping：H3C/华为的用法
很多人调试网络时需要在交换机上发ping测试，但默认ping走的源地址是交换机的管理地址或路由出接口地址，有时候并不是你想要的。H3C交换机可以用ping -a指定源地址；在华为交换机上同样支持：
ping -a 192.168.10.1 192.168.20.1这个命令的作用是：指定源IP为192.168.10.1（通常是VLANIF 10的地址），去ping 192.168.20.1。如果通，说明VLANIF 10到VLANIF 20之间的三层链路正常；如果不通，再检查VLANIF接口up状态、路由表和ACL策略。注意，ping -a只用于三层接口测试，不能用来指定物理端口——因为三层ping基于IP栈，与具体物理端口无直接关系。
如果你确实想测试某个二层端口连出去的那条链路上的设备，更直接的做法是在该端口下配一个临时的三层接口地址（把Access口临时改成三层口），或者用loopback测试思路。不过生产环境不建议轻易改端口类型，宁可接线测试仪或查对端设备状态。
5.2 查看DHCP配置：排查“设备拿不到地址”的标准动作
内网存在DHCP服务器时，交换机做的基本工作是透传广播。但“有物理DHCP服务器无法获取IP”的案例，我总结下来几乎都是以下几个原因：
- DHCP服务器与客户端不在同一广播域，而交换机没有做DHCP Relay；
- 交换机端口开启了DHCP Snooping，把合法服务器的响应当非法帧丢弃；
- VLAN或Trunk配置错误，DHCP Discover广播没送到服务器所在VLAN；
- 服务器和客户端之间有ACL过滤了UDP 67/68端口。
华为交换机上查看DHCP相关配置，常用命令如下：
display dhcp snooping user-binding summary // 查看DHCP Snooping绑定表项 display dhcp relay interface Vlanif 10 // 查看DHCP Relay配置 display dhcp server statistics // 查看DHCP服务器统计（如果该交换机是DHCP Server）我看到很多人问“华为交换机查看dhcp配置”时，其实分不清“交换机自己是DHCP Server”和“交换机透传DHCP”这两种场景。如果交换机自己分配IP（小网络常见），用display ip pool查看地址池和租约；如果交换机只是二层透传，重点检查VLAN放通和DHCP Snooping信任口配置。我遇到过最隐蔽的一次故障：DHCP Snooping默认开启，管理员在接入端口下忘了配dhcp snooping trusted，合法服务器响应被当伪造报文丢弃，终端分配不到IP，排查了一下午才发现是这个原因。
5.3 二层环路与交换机死机的核心原因
“交换机死机”“网络瘫痪”这类问题，大概率是二层环路引发的广播风暴。二层没有TTL机制，一个广播帧如果遇到环路会在交换机之间反复转发、指数级膨胀，最终占满所有端口带宽，让交换机CPU被中断风暴打满。表现就是设备疯狂丢包、远程登录极慢甚至掉线、交换机指示灯狂闪、连接console查看发现CPU使用率100%。
排查环路最直接的证据是MAC地址表漂移。正常网络里每个MAC只会出现在一个固定端口；如果某个MAC表项在短时间内频繁在两个端口之间跳变，说明这两个端口构成环路或用网线/环路器接在了一起。华为交换机查看MAC漂移的命令：
display mac-address flapping也可以看接口统计，比如display interface GigabitEthernet 0/0/1，观察入方向广播与单播比例是否异常。
解决环路的核心不是拔线，而是启用STP（RSTP/MSTP），让生成树协议自动阻断冗余链路。很多小型网络为了省事不配STP，这是把自己的网络放在一个随时会爆炸的定时炸弹上。
6. 光口链路设计：聚合还是主备，二层转发的可靠边界
再聊一个和二层转发直接相关的部署话题：交换机光口到底是做链路聚合还是主备。搜索热词里频繁出现这个问题，说明很多人在做网络规划时拿不准。
6.1 链路聚合与主备的本质区别
链路聚合（Link Aggregation，如LACP/静态聚合）是把多个物理口绑成一个逻辑口，提升带宽并实现负载均衡。它有一个前提：两端设备必须都支持并正确配置聚合，且聚合模式（静态/动态）一致。如果两端配置不一致，比如一端是LACP动态聚合、另一端是静态聚合，就会出现“通一下断一下”的尴尬现象。
主备模式（比如STP的阻塞状态）则是同一时刻只让一条链路转发，另一条处于备份状态，故障后切换。它的好处是配置简单、不需要对端配合协议；缺点是带宽只有一链路，浪费冗余链路。
注意一个容易犯错的地方：链路聚合只能在二层（或三层接口）层面绑定相同速率、双工模式、VLAN配置的端口。混插不同速率的光模块做聚合虽然有时也能起来，但稳定性差，我建议直接避免。
6.2 二层转发表如何看聚合
配置链路聚合后，MAC地址表项对应的出接口就不再是具体物理口，而是聚合口的逻辑名（如Eth-Trunk 1）。转发时，流量根据哈希算法在聚合组成员口之间分担。所以如果你用display mac-address查看时发现出接口变成了Eth-Trunk，不要奇怪，这是正常的。
排查聚合链路问题时，重点检查两件事：
display eth-trunk 1 // 查看聚合组成员状态 display mac-address interface Eth-Trunk 1 // 每次学习都走逻辑口如果发现成员口处于Down状态或协议不一致，要立刻检查物理模块是否插稳、两端报文协商是否成功。还有一个经常被忽略的细节：二层聚合和三层聚合的配置方式不同。二层时先创建Eth-Trunk，再把物理口加入，最后配VLAN接口；三层时需要先把物理口改成三层模式再聚合。
6.3 什么样的网络适合聚合，什么样的适合主备
我的个人建议是：核心到汇聚、汇聚到接入的链路，流量模型为“多对多”时优先用链路聚合，提升总带宽并降低单点故障风险。服务器双网卡接入交换机时，除非服务器支持网卡绑定并和交换机做配套LACP，否则宁可用主备模式，免得服务器侧不配合导致整个链路不稳。对于两台设备间只跑两条10G光口、对带宽需求不高的场景，做主备更省心——毕竟备份链路平时不承载流量，故障切换也快。
之前处理过一个边缘交换机下接监控网络的案例，光口做聚合后发现监控码流反而出现了抖动，排查后确认是交换机哈希算法对大量小包（视频RTP流）的负载均衡不生效，流量全挤在一个成员口上。把聚合改成两个独立二三层链路+STP主备后，问题消失。做IT网络设计，不要为了“高大上”盲目聚合。
7. 从二层转发的角度看设备选型与网络规划
说了这么多，最后把视野稍微放远一点：做网络规划和设备选型时，二层转发能力其实是决策的重要维度，但很多人只关心端口数量和速率，忽略了一些转发层面的指标。
7.1 转发带宽与缓存：被低估的两个参数
交换机都会标注“交换容量”“包转发率”。交换容量决定了设备内部总线或交换芯片能处理的总带宽，包转发率决定每秒能转发多少包（通常用Mpps表示）。选型时要算一个账：接入设备数量×每台平均业务流量，再加上30%左右的余量，不能只看端口是多少G，还得看核心交换芯片是否能扛住并发。
另一个被低估的参数是缓冲（Buffer）。二层转发遇到瞬时拥塞时，数据包会先缓存在端口缓冲里，缓冲不足就会直接丢包。视频监控、语音通话这类突发小包流量，尤其吃缓存。同样标称48口千兆的两台交换机，芯片缓存一个512KB、一个4MB，在监控大流量场景下的表现会差出不少。
7.2 千兆交换机与三层交换机的分界
“千兆交换机”这个词本身不必然对应二层还是三层，很多千兆交换机纯二层，只能做接入。如果业务需要VLAN间路由，就必须上三层交换机。判断方法很简单：查看设备能不能创建VLANIF接口并配置IP。如果不能，它就是纯二层设备，只能负责接入和VLAN隔离，跨VLAN必须另接路由器或三层核心。
7.3 小型网络规划的推荐落地方案
在我自己维护的小型网络中，推荐的架构是：核心用一台三层交换机（支持24口千兆+4个万兆光口），各个接入交换机用二层千兆交换机，通过光纤Trunk上联到核心。核心做VLAN间路由、DHCP Relay（如有必要）、ACL策略。接入层全部启用RSTP，冗余链路做聚合或主备。这套方案几百人的办公网络基本够用，而且故障面小、排查路径清晰。
如果你正在学习或备考网络认证，我的建议是不要只背命令，而是先在模拟器（如eNSP）里把“二层交换机+VLAN+单臂路由+三层交换+VLAN间路由+ACL”这一整个链路搭一遍，把数据包的走向一步步追出来。等到你看到一个ping不通的现象能直接从“二层还是三层、表项还是策略”这个维度去定位，你就真正理解了交换机二层转发，而不只是记住了几个命令。
