交换机底层转发逻辑与VLAN/STP环路排障配置实战

交换机这东西，很多刚入行的朋友觉得它"插上电就能用"，直到某天办公室里一半人断网、机柜里指示灯疯闪，才发现这台铁盒子远没看上去那么老实。玄子Share这个系列里，我一直想把这些年摸过的设备、踩过的坑整理成一份能直接照着干的笔记，这篇就集中聊交换机的底层工作逻辑和配置落地——它是什么、凭什么能同时让几十台机器互不干扰地通信、MAC地址表里到底存了什么、VLAN怎么切、Trunk为什么不冒泡、环路一出现为什么整网几秒钟就瘫。不管你是刚接触网络的在校学生，还是已经开始上手管理小型办公网、实验室网络的运维新手，只要你能摸到设备的Console口，这篇里的思路和命令骨架都能直接搬去用。我不会只给你一堆命令让你背，而是把每个动作背后的判断逻辑讲透，因为现场排障时，能救命的是"知道它为什么这么转发"，而不是"记得那条命令怎么写"。

1. 从一台交换机的开机自检说起：它到底在忙什么

很多人第一次拆开一台接入层交换机，看到面板上一排指示灯，插上网线灯就亮，以为工作已经完成了。实际上从通电那一刻起，设备做的事情分两个层面：控制平面在拼命跑协议、算拓扑、维护各种表项，数据平面则在按硬件芯片里已经下好的规则做线速转发。理解这个分工，你才能明白为什么有些故障"配置看着全对但就是不通"——配置只影响控制平面怎么算，最终转发是芯片按转发表执行的，表和配置对不上，一切都白搭。

1.1 冲突域、广播域与"为什么不用集线器"

早期的集线器是纯物理层设备，一个口收到的电信号会原封不动地从其他所有口发出去。这意味着同一时刻只能有一台设备在说话，两个人同时发数据，电信号在共享介质上叠加，直接变成乱码，这就是冲突。所有挂在集线器上的设备共享一个冲突域，规模一大，碰撞概率指数级上升，实际吞吐掉得比想象中狠得多。

交换机做的是另一件事：它把每个端口都划成独立的冲突域。端口A发数据，只从目标端口出去，端口B和C完全不知道发生了什么，可以同时收发。这就把原来"一根独木桥"变成了"每个房间一条独立通道"。但要注意，冲突域被切碎了，广播域并没有——一个广播帧进来，交换机依然会从同VLAN的所有端口复制出去。所以"交换机隔离冲突域、路由器隔离广播域"这句话严格讲只对了一半：交换机靠VLAN也能切广播域，只不过那是逻辑上的隔离，不是物理的。

现场一个常见误区是把"换成交换机就不卡了"当万能药。如果卡的原因是广播域太大、ARP请求满天飞，换一台更高端的二层交换机并不能解决问题，得靠划VLAN或者上三层。我见过某办公区一个平层两百多台机器全在一个VLAN里，DHCP获取慢、打印机发现不了、偶尔整片掉线，最后的处理方式就是按部门切成四个VLAN，故障率立刻降下来。

1.2 MAC地址表是怎么"长"出来的

交换机转发的依据是MAC地址表，业界也叫CAM表。它的学习机制非常朴素：任何一个帧从某个端口进来，交换机就把这个帧的源MAC、入端口号、所属VLAN ID这三元组记下来，同时打上一个时间戳。注意是源MAC，不是目的MAC——这一点新手最容易记反。它的潜台词是："这个地址的主机，从我这边这个口能够到达。"

举个例子，主机A（MAC为AA）从G0/0/1口发出一个帧去找主机B，交换机看到源MAC是AA、入端口是1，于是在表里写下"AA → 端口1"。下次有帧要发给AA，交换机查表就知道从1口送出去，不用再泛洪。整个过程不需要任何配置，也不需要协议协商，纯靠数据流量"喂"出来。

这张表的容量是硬指标。接入层设备一般几千条，核心设备能到几万甚至几十万条。表满了会发生什么？新学到的地址挤不进来，或者老的被提前挤掉，结果就是本来已经学过的目的地址又变成"未知单播"，重新泛洪。轻微表满你感觉不到，严重表满就是整网性能断崖式下跌。所以别小看这个参数，做网络规划时，一个VLAN里主机数量乘以每台机器的MAC数（虚拟机会额外占用），要留出足够余量。

老化时间这个参数值得单独说一句。默认值通常是300秒，意思是五分钟内没再收到这个源MAC的流量，表项就删掉。调大能减少泛洪，但拓扑变化后旧表项残留时间变长，可能把流量送到错误的端口；调小响应快，但泛洪变多。绝大多数场景保持默认就行，只有做服务器高可用或者快速切换的场景，才会考虑往小调。

2. 三个转发动作背后的判断逻辑：泛洪、转发与丢弃

交换机收到一个帧，做的事情其实只有三种：从某个特定端口转发出去、从多个端口复制出去（泛洪）、或者直接丢掉。听起来简单，但每一种动作的触发条件不一样，搞清楚这些条件，你就拿到了排障的钥匙——因为"包没到"和"包到了但被丢了"是两个完全不同方向的排查路径。

2.1 未知单播泛洪的边界在哪里

具体的判断顺序是这样的：先看目的MAC是不是广播地址（全F）、组播地址，或者是本机要处理的地址；如果是广播，就在该VLAN内除入端口外的所有端口泛洪。如果不是广播，就查MAC表：查到了且出端口不等于入端口，就从那个端口转发；查到了但出端口恰好就是入端口，说明目的主机和源主机在同一口后面（比如串联了一台小交换机），直接丢弃，省得浪费带宽；查不到，就是未知单播，同样在该VLAN内泛洪。

这个"VLAN内"是关键词。VLAN划分之后，泛洪范围严格限定在同一个VLAN里，不会跨到别的VLAN去。这也是VLAN最实在的价值之一：把广播和未知单播控制在可接受的范围内。我见过有人把VLAN当成纯粹的管理标签，以为只是名字不同，结果在一个VLAN里塞了整栋楼的终端，广播风暴一来全部沦陷，这就是没理解泛洪边界。

还有一个容易被忽略的细节：未知单播泛洪是正常行为，不是故障。有些同事抓包看到大量未知单播就紧张，其实只要主机在通信前有ARP解析，每个新会话最初几个包必然泛洪，这是设计使然。真正需要警惕的是持续的、量很大的未知单播，那通常意味着MAC表异常（表满、漂移、学习被禁用）或者存在单向流量。

2.2 老化时间与MAC表容量，被忽视的两个参数

前面提到老化时间默认300秒，这里补充实操层面的观察方法。查表命令各家写法略有差异，但核心逻辑一致：

# 查看整体MAC表项，含VLAN、MAC、类型、端口 display mac-address # 只看某个VLAN display mac-address vlan 10 # 查某个具体MAC从哪个口学到的 display mac-address 00e0-fc12-3456 # 看表项使用率，判断是否接近上限 display mac-address summary

实践中我建议养成一个习惯：接手一个不熟悉的网络，先导出一份MAC表，看两件事。第一，同一个MAC是否在不同端口之间来回出现，如果有，多半是环路或者链路聚合配置错误；第二，MAC表项数量是否贴近设备上限，如果贴着上限跑，说明这个VLAN规划已经到极限了，得提前考虑拆分。

另外，端口安全功能会直接影响学习行为。开启端口安全并限制最大MAC数之后，超出的源MAC不再被学习，对应的流量可能被丢弃或触发告警。这在接入层防私接很有用，但配置时一定要留出余量——终端后面串一个无线路由器，光这个路由器自己就可能占用两三个MAC，限制成1个会让用户莫名其妙断网。

# 端口安全配置骨架，限制每个口最多学2个MAC，超出后限制但不宕口 interface GigabitEthernet 0/0/5 port-security enable port-security max-mac-num 2 port-security protect-action restrict

restrict表示超限丢弃并告警，protect是静默丢弃，shutdown会直接把端口关掉。线上环境我一般先用restrict观察一段时间日志，确认没有误伤再考虑更严格的策略，一上来就shutdown很容易把整个办公室搞断网。

3. 环路：二层网络里最贵的一课

二层网络没有TTL机制，这是它和三层最本质的差别。三层包每经过一个路由器，TTL减一，减到零就丢，天然防环；二层帧没有这个字段，一个帧如果遇到环路，就会永远转下去，而且每一圈都在复制。这是所有二层环路故障的根本原因，也是为什么STP这类协议虽然老、虽然慢，却依然是几乎所有交换机的默认开启项。

3.1 广播风暴是怎么在几秒钟内打垮整网

推演一下环路形成的过程。假设两台交换机之间有两条链路（比如误接了两根网线，或者一端接了墙上的两个信息点），并且STP没有生效。主机A发出一个ARP广播，交换机1从两个端口都泛洪出去，交换机2从两个端口各收到一份，再各自泛洪回来，交换机1又收到两份、泛洪出四份……帧的数量按指数增长。百兆链路上，这个雪球滚满带宽只需要几秒。

现场表现很有特征：所有端口指示灯同步高频闪烁、交换机CPU利用率飙到接近100%、管理页面打不开、ping网关丢包率接近100%、同一VLAN内的设备全部失联。这时候如果你去抓包，会看到同一个源MAC的同一个帧在几毫秒内重复出现几百上千次。

处理方式没有捷径：快速定位环路点，拔线。经验做法是从核心往下逐级拔，或者观察哪些端口的流量和广播包速率异常高，先隔离。有条件的话看设备的日志，环路检测功能通常会直接报出是哪个端口检测到了自己的BPDU或者环路帧。

# 环路检测相关配置骨架 loop-detection enable interface GigabitEthernet 0/0/10 loop-detection enable loop-detection action shutdown # 开启BPDU保护，防止接入口收到BPDU（有人私接交换机） interface GigabitEthernet 0/0/1 stp edged-port enable stp bpdu-protection

这里有个血泪教训：edged-port（边缘端口，等价于其他厂商的PortFast）配置在接终端的口上，能让终端插上就通，跳过STP的监听学习阶段。但如果这个口实际接的是一台小交换机，而对方也在跑STP，双方一交互就可能把拓扑搅乱。所以配套一定要开BPDU保护，一旦边缘口收到BPDU就直接把口关掉并告警，宁可断一个口，也不能让整网跟着抖。

3.2 STP的端口状态机与收敛代价

STP的核心思路是：在物理上存在冗余的拓扑里，逻辑上主动阻塞掉一部分端口，形成一棵无环的树。一旦主链路故障，被阻塞的端口再"顶上来"。为了实现这个，它需要选出一个根桥，然后每台非根交换机选出一个根端口（离根最近的），每条链路上选出一个指定端口（负责往该网段转发），剩下的全部阻塞。

选举依据是桥ID，由优先级（默认32768）加MAC地址组成，数值小的赢。所以想让某台设备当根桥，最直接的办法是把它的优先级调低，比如4096。不调的话，根桥往往由MAC最小的那台设备"随机"当选，很可能是一台性能最弱的接入交换机，这就很尴尬了——所有的流量都要绕到它那里再转发。

老式STP（802.1D）的端口状态依次是：阻塞、监听（15秒）、学习（15秒）、转发。加上拓扑变化时的老化等待，一次完整的收敛动辄30到50秒。这50秒里，终端表现为"网线插着但上不了网"。对办公场景尚可忍受，对生产环境就是事故。所以现在基本都上RSTP（802.1w），端口角色精简为根端口、指定端口、替代端口、备份端口，收敛做到秒级甚至更快，而且向后兼容老STP。

MSTP的坑我要单独提一句：它要求同一区域内所有设备的域名、修订级别、VLAN与实例的映射表逐字一致，差一个字符就会分成不同的域，实例对应不上，负载分担直接失效。我见过有人复制配置时把修订号从1写成了2，排查了两个晚上才发现。

4. VLAN把一台交换机切成好几台

如果说STP是"保命"的，那VLAN就是"干活"的。它的本质是把一台物理交换机在逻辑上切成多台虚拟交换机，每个VLAN是一个独立的广播域，VLAN之间默认完全隔离。这个隔离是二层的，不需要任何访问控制列表就天然存在，这也是它比"用ACL挡一下"更干净的地方。

4.1 802.1Q标签与Access/Trunk的取舍

VLAN要跨设备传递，就必须在帧上做标记。802.1Q标准是在以太网帧的源MAC之后插入4个字节：2字节的标签协议标识（固定值0x8100）、2字节的控制信息（其中12位是VLAN ID，可用范围1到4094）。这4个字节一插，帧的最大长度从1518变成1522，某些老设备或者特殊应用对这个敏感，会表现出大包不通、小包正常的诡异现象，遇到时先查MTU和这个标签长度。

端口分为两类角色。Access口一般接终端，它只属于一个VLAN：进来不带标签的帧，交换机给它打上这个口的PVID（默认VLAN）；出去的时候把标签剥掉，终端看到的是普通帧，完全感知不到VLAN的存在。Trunk口一般用于设备互联，能承载多个VLAN：带标签的帧进来，检查VLAN ID是否在允许列表里，在就放行，不在就丢；不带标签的帧进来，打上PVID。出去的时候，如果VLAN ID等于PVID且没配置强制带标签，就剥标签发出，否则带着标签发。

这里有个非常经典的坑：两端Trunk口的PVID不一致。比如一端PVID是1，另一端是10，那么不带标签的帧在两端会被归到不同的VLAN，表现为"链路是up的，但就是不通"。所以规范的做法是，Trunk口显式配置PVID，并且两端保持一致，同时用allowed vlan明确列出允许通过的VLAN，不要图省事写all。

# VLAN创建与端口划分骨架 vlan batch 10 20 30 interface GigabitEthernet 0/0/1 port link-type access port default vlan 10 interface GigabitEthernet 0/0/24 port link-type trunk port trunk allow-pass vlan 10 20 30 port trunk pvid vlan 1 # 检查结果 display vlan display port vlan

display port vlan这条命令我强烈建议每次配完必看，它会把每个口的类型、PVID、允许通过的VLAN一次性列出来，比逐个接口去翻快得多，而且能直接暴露PVID配错这种问题。

4.2 跨VLAN通信必须经过三层

VLAN隔离是二层的，所以VLAN 10的机器想访问VLAN 20的服务器，必须有设备做三层转发。两种主流方案：一是单臂路由，在路由器的物理口上划子接口，每个子接口封装对应的VLAN ID；二是用三层交换机配SVI（VLAN接口），给每个VLAN一个网关地址。

单臂路由的问题是所有VLAN间流量都要挤在一条物理链路上来回，带宽和延迟都受影响，现在除了小型场景基本不用。三层交换机方案在设备内部用硬件转发，性能好得多，是现在的主流做法。

# 三层交换机上的SVI配置骨架 interface Vlanif 10 ip address 192.168.10.1 255.255.255.0 interface Vlanif 20 ip address 192.168.20.1 255.255.255.0 # 终端网关分别指向 192.168.10.1 和 192.168.20.1

配完SVI之后，如果VLAN间还是不通，按这个顺序查：一、终端网关有没有配对；二、SVI是不是up状态（对应的VLAN里至少要有一个up的物理口，否则SVI会down，这是个高频坑）；三、三层交换机的路由表里有没有这两个直连网段；四、有没有ACL把流量挡了。第三步很多人会忽略，其实SVI配好地址后直连路由会自动生成，如果没看到，说明SVI根本没起来。

5. 拿到一台新设备的完整配置链路

前面讲的都是原理和判断逻辑，这一节把它落成一套能照着走的流程。我习惯把新设备上线分成四步：物理接入与初始化、VLAN与端口规划、管理面配置、验证与保存。顺序不能乱，尤其是最后一步，忘了保存的痛懂的都懂。

5.1 Console接入与基础初始化

新设备开箱，先别急着插网线。用Console线连接笔记本和设备的Console口，终端软件参数设成波特率9600、数据位8、停止位1、无校验、无流控。上电后能看到启动信息，进系统后先看版本和当前配置：

display version display current-configuration

第一件事是改主机名和时钟，主机名要能一眼看出位置和角色，比如SW-3F-A-01，比默认的HUAWEI或者Switch有用一百倍。时钟建议配NTP，日志时间不准会给后期排障带来巨大麻烦——你根本对不上"故障发生时间"和"日志记录时间"。

然后是管理地址和远程登录。管理VLAN单独规划一个，比如VLAN 99，不要和业务VLAN混在一起：

vlan 99 description MGMT interface Vlanif 99 ip address 10.10.99.2 255.255.255.0 ip route-static 0.0.0.0 0.0.0.0 10.10.99.1

远程登录方面，Telnet是明文传输，现在基本应该淘汰，改用SSH。配置时注意认证方式选AAA，并且一定要限制源地址范围，别让管理口对整个网络敞开。

stelnet server enable aaa local-user admin password irreversible-cipher YourStrongPass local-user admin privilege level 15 local-user admin service-type ssh user-interface vty 0 4 authentication-mode aaa protocol inbound ssh

密码这块我不展开写具体策略，只提醒一点：别用设备出厂默认密码，也别用部门名加年份这种。曾经有台设备因为默认口令没改，被内网扫描工具直接登进去改配置，整层楼瘫痪了半天。

5.2 VLAN规划与端口分配的实操顺序

VLAN规划这件事，最忌讳边配边想。我的习惯是先画一张表：VLAN ID、名称、网段、网关、用途、覆盖范围。这张表定下来之后再动手配，能避免大量返工。

编号上留出间隔，10、20、30这样，以后中间加VLAN不用整体重排。名称用大写英文加简短描述，别用中文，某些老设备的命令行对中文支持不好，显示乱码反而增加排查成本。

端口分配时，接入端口按物理位置连续分配，比如1到8口给办公区A，9到16口给办公区B，同时在描述里写清楚。描述字段看着不起眼，实际价值极高——半年后你或者别人再来查线，一句description 3F-East-Desk-01能省下半小时。

interface GigabitEthernet 0/0/1 description 3F-East-Desk-01 port link-type access port default vlan 10 stp edged-port enable

批量配置时，很多设备支持端口组，能一次下发到多个口：

port-group group-member GigabitEthernet 0/0/1 to GigabitEthernet 0/0/8 port link-type access port default vlan 10

但要注意，批量配置完之后一定要抽查几个口确认生效，尤其是使用to范围语法时，端口编号不连续（比如0/0/9之后是0/0/10还是0/0/0/10，不同型号不一样）会导致范围解析出错。我一般配完立刻display current-configuration interface扫一眼。

5.3 管理地址、远程登录与配置保存

配置写完，最容易被忽略的是保存。命令行下的修改都在运行配置里，掉电就没了。不同厂商的保存命令不一样，有的save，有的write memory，有的copy running-config startup-config。养成配完就保存的习惯，特别是在做变更之前，先保存一次当前状态，出问题还能回滚。

# 保存前先看看改了什么 display current-configuration | include vlan # 保存 save

更稳妥的做法是做配置备份，把当前配置导出到本地或者备份服务器，命名带上日期和变更说明。这个习惯在你做批量变更时能救命——改错了，把备份灌回去，十分钟恢复，比重头排查快得多。

验证环节也别省。配完之后至少测这几项：终端能不能拿到地址、能不能ping通网关、能不能访问其他VLAN的指定资源、管理地址能不能远程登录、双机冗余场景下断一条链路业务是否中断。这几项过了，才算真正上线。

6. 现场最容易踩的五个坑与排查顺序

原理和配置讲完，最后这部分是我这些年踩出来的经验。交换机故障有个特点：现象往往很吓人，原因却常常很无聊。关键是建立一个固定的排查顺序，别被现象带着跑。

6.1 MAC漂移与环路告警的现场判断

MAC漂移是环路最直接的信号。同一台设备的MAC，在一秒内从端口5学到又跑到端口8，来回跳，说明这两个端口之间存在二层环路路径。设备日志里通常会有明确的漂移告警，包含MAC地址和两个端口号，看到这个基本可以锁定环路范围。

但要区分一种情况：服务器做了网卡绑定（双网卡主备或者负载均衡），如果配置不当，两个网卡同时用同一个MAC发包，从交换机角度看也是漂移，但实际上没有环路。区别在于——环路会导致广播包速率暴涨、CPU飙升，而双网卡绑定只是偶发漂移，广播速率正常。所以判断时不能只看漂移告警，要结合广播包统计一起看。

# 观察端口广播包速率，环路时这个数字会异常高 display interface GigabitEthernet 0/0/10 # 查看MAC漂移记录 display mac-address flapping record

处理顺序：先定位端口，再判断是不是接错了线。如果交换机之间有双链路，正确的做法是配置链路聚合，把两条物理链路绑成一条逻辑链路，而不是靠STP去阻塞其中一条——前者能用满带宽，后者浪费一半。

6.2 Trunk不通的逐层排查法

Trunk不通是接入层最常见的故障之一，排查要有固定顺序，从物理层往上逐层排，别跳步。

第一层看物理状态。display interface里看是不是up、速率双工是否协商一致。千兆口一般自协商没问题，但有些老设备或者光电转换器会导致一端100M全双工、另一端100M半双工，表现是能通但丢包严重、大包基本不通。这种情况手动固定双工和速率往往能解决。

第二层看端口类型。两端必须都是Trunk（或者一端Trunk一端Hybrid且放行规则正确），如果一端是Access，那它只会收发一个VLAN的流量，其他VLAN全部丢弃。

第三层看允许列表。port trunk allow-pass vlan里有没有包含业务VLAN，这是最高频的错误——配了Trunk但忘了放行新加的VLAN，结果新VLAN的终端全都不通。

第四层看PVID。前面提过，两端PVID不一致会导致不带标签的帧归到不同VLAN。

第五层看VLAN是否真的创建了。有些设备上，端口放行了VLAN 30，但VLAN 30本身没创建，流量照样过不去。用display vlan确认一下，顺带看端口有没有真正加入这个VLAN。

还有一类更隐蔽的问题：生成树把某个端口阻塞了。表现是链路物理up、配置全对，但流量就是不过去。display stp brief能看到每个端口的状态，如果是ALTE或者DISCARDING，说明被STP挡了，这时候要去查拓扑和优先级，而不是继续在VLAN配置上打转。

我个人在实际操作中的体会是，交换机的配置量其实不大，真正花时间的是"确认它按你想的方式在工作"。所以每改一处，顺手敲一条查看命令，把结果和预期对一遍，比事后集中排查高效得多。另外一个私藏的小技巧：给每个重要端口加描述、给每个VLAN加描述、给每台设备配好主机名和NTP，这三件事做好，未来任何一次排障都会轻松一大截。这些信息在配置里只占几行，但它们是你在凌晨两点面对一堆告警时，唯一能快速建立上下文的东西。