局域网互联这件事，说穿了就是把一堆各自为政的小网络焊成一张大网，同时还得保证广播不失控、环路不爆炸、故障不扩散。数据通信与网络里这一章——连接局域网、骨干网与虚拟局域网（VLAN）——讲的正是这段"焊接工艺"。很多同行学完TCP/IP就直接跳到路由协议，觉得二层的东西"太简单"，结果真到机房里遇到广播风暴、MAC地址表抖动、Trunk口不通、VLAN间ping不通，才知道这一章的分量。它解决的问题非常具体：当你有一栋楼、一栋楼里十几个部门、每个部门几十台机器的时候，怎么在物理上连成一片、在逻辑上又切成互不干扰的若干块。适合谁看？刚入行的网络运维、准备考证的在校生、做弱电集成的工程师，以及那些被"为什么这台交换机插上就全网变慢"困扰过的朋友。下面我按自己的理解，把这一章从原理到实操完整拆一遍。
1. 这一章到底在解决什么工程问题
1.1 从"两台机器连起来"到"两个网络连起来"的思维跃迁
学网络最开始的那几章，讲的是两台机器怎么用一根线通信：编码、调制、成帧、差错检测。那是一个点对点的世界。可现实里没人只连两台机器，现实是一个机房几十台、一栋楼几百台、一个园区上千台。当设备数量上去之后，问题性质就变了——不再只是"信号能不能传过去"，而是"谁能收到""收到多少""出问题怎么隔离"。
这就是局域网互联的起点。连接两个LAN，最朴素的想法是拿根线把两边的交换机接起来，但这一接，马上冒出三个新问题：第一，两边的广播域合并了，A网里一台机器的ARP广播会飘到B网；第二，两边如果有多条链路互联，二层环路立刻形成，以太网帧没有TTL字段，会在环里无限打转；第三，两边的地址空间、安全策略、管理边界全部糊在一起，出了故障根本定位不了。
所以这一章的技术主线其实是一条"逐层加码"的路线：物理层用中继器把信号延长一点，数据链路层用网桥/交换机做帧级别的过滤和转发，网络层用路由器做广播域和策略的切割，最后再用虚拟局域网VLAN在交换机内部做逻辑切割，把"一台物理交换机"变成"多台相互独立的虚拟交换机"。每一层加码，都对应着解决上一层的某个具体痛点。
理解这条主线特别重要，因为它决定了你选设备的逻辑。很多人问"我这里要不要上三层交换机"，其实答案取决于你要不要在那个位置切广播域。不要切，二层交换机足够；要切，就得上三层能力。判断标准只有一条：广播域边界画在哪里，三层设备就放在哪里。
1.2 影响范围：这套东西不只管园区网
有人觉得这一章是"老古董"，只有传统园区网才用。实际恰恰相反，它是整个数据中心和云网络的底座。你今天在云平台上开一台虚拟机，背后就是VXLAN之类的隧道在承载二层语义；而VXLAN的设计动机，本质上就是"VLAN只有4094个可用，不够用了"。再比如容器网络里大量使用的二层overlay，思路和802.1Q封装一脉相承——都是给原始帧外面套一个标签，用来标识它属于哪个逻辑网络。
再看工业场景。工厂产线上的PLC、传感器、视觉相机跑在同一批交换机上，但控制流量和视频监控流量必须严格隔离，否则一段大流量视频就把实时控制报文挤掉了。做法就是基于端口的VLAN划分，把控制网放一个VLAN、视频网放一个VLAN，物理上共用线缆和交换机，逻辑上互不可见。这是这一章最实在的落地价值。
还有一类场景是"临时组网"，比如展会、临时办公区、培训教室。人走网拆，但IP规划不能乱。用VLAN做逻辑分区，换场地的时候只改端口归属，不动布线，省下的是实打实的人工成本。
2. 连接LAN的三类设备：各自干哪一段活
2.1 中继器与集线器：为什么会进博物馆
中继器工作在最底层，它做的事情极其简单——把收到的电信号整形、放大、再发出去。信号在铜缆里传输会衰减，超过规定距离就识别不出来了，中继器就是给信号"续命"的。集线器本质上是多端口中继器，一头进来，所有端口都发出去。
问题就在这个"所有端口都发出去"。集线器不认MAC地址，不做任何判断，一台机器发的帧会复制到每一个端口。这意味着整个集线器构成一个冲突域——所有挂在上面的设备共享同一段带宽，用CSMA/CD抢信道。10台机器挂在一个10M集线器上，平均每台理论带宽1M，而且机器越多，碰撞概率越高，实际吞吐率还会打折扣。
我见过不少老机房角落里还躺着一两个集线器，被当作"应急扩展口"用。这里必须提醒：**集线器插进现代交换网络，是广播风暴和性能塌方的头号嫌疑人。**因为它的"无脑复制"特性会把单播帧也变成广播，交换机学到的MAC地址表会因此频繁抖动，严重的时候整网都在泛洪。真遇到了，第一件事是把它拔掉换成交换机。
顺带说一个容易混淆的点：冲突域和广播域不是一回事。集线器扩大冲突域，不扩大广播域（因为它不隔离）；交换机每个端口是一个独立冲突域，但默认所有端口同属一个广播域；路由器每个接口既隔离冲突域也隔离广播域。这个三层概念理清楚了，后面VLAN就好懂了——VLAN做的事，就是让一台交换机内部产生多个广播域。
2.2 网桥与二层交换机：自学习是核心机制
网桥和交换机在原理上是同一类东西，交换机就是多端口、硬件转发的高速网桥。它们干的事比集线器聪明得多：看目的MAC地址，只往该去的那个端口发。
这个"该去的端口"是怎么知道的？靠自学习。具体过程是这样的：交换机收到一个帧，先看源MAC，把"这个源MAC来自我哪个端口"记进MAC地址表；再看目的MAC，如果表里查得到，就从对应端口转发出去（这叫转发）；如果查不到，就向除接收端口外的所有端口复制一份发出去（这叫泛洪）；如果目的MAC和源MAC在同一个端口上，直接丢弃（这叫过滤）。
这里有个细节很值得琢磨：**自学习是靠"源地址"完成的，不是靠目的地址。**因为源地址一定是真实存在的，而目的地址可能是广播、可能是组播、可能是还没通信过的陌生地址。所以交换机永远处于"边转发边学习"的状态，一张表是动态长出来的。
MAC地址表有老化机制，业界常见默认值是300秒。为什么要有老化？因为设备会移动、会下线、IP会换绑，表项如果不清理就会变成僵尸条目，导致帧被转发到错误的端口。300秒这个数字是经验值——太短会导致频繁泛洪，太长会导致迁移后的设备一段时间收不到流量。实际排障时，如果你发现某台机器换了网口之后要等好几分钟才恢复通信，八成就是老化时间在作祟，可以让它主动发包触发重新学习，或者手工清一下表。
交换机的转发模式也值得说一句。常见有三种：存储转发、直通、无碎片直通。存储转发要收完整帧、校验CRC通过才发，延迟大但能过滤掉错帧；直通只读前6字节目的MAC就转发，快但会把坏帧也送出去；无碎片直通折中，读前64字节。现在主流的接入交换机基本都是存储转发，因为现在的芯片处理速度足够快，延迟差异在微秒级，而过滤坏帧带来的收益是实实在在的。
2.3 路由器：广播域的终结者
交换机能隔离冲突域，但隔离不了广播域。一台交换机上所有端口默认在同一个广播域里，任何一台机器发ARP请求，全网所有机器都得处理一遍。几十台还扛得住，上千台就是灾难——CPU被中断打满，有效带宽被广播吃掉。
路由器（或者具备三层能力的交换机）就是干这个的：**它的每个接口是一个独立的广播域，广播帧到此为止，不会跨接口传播。**同时它还负责在不同网段之间做转发决策，靠的是IP地址和路由表。
这里有个认知需要纠正：很多人以为"路由器比交换机高级"，其实两者解决的是不同维度的问题。交换机解决的是"同一个网段内部，怎么高效地把帧送到对面"；路由器解决的是"跨网段，怎么找到路"。二层快、三层可控，这是本质区别。这也是为什么现代网络设计里，接入层用二层交换机（便宜、端口密度高、转发快），汇聚/核心层用三层设备（做网段划分和策略控制）。
2.4 三类设备的选型对照
| 设备类型 | 工作层次 | 隔离冲突域 | 隔离广播域 | 典型用途 | 现在的地位 |
|---|---|---|---|---|---|
| 中继器/集线器 | 物理层 | 否 | 否 | 延长传输距离 | 基本淘汰，仅应急 |
| 网桥/二层交换机 | 数据链路层 | 是（每端口） | 否 | 终端接入、同网段转发 | 接入层主力 |
| 路由器/三层交换机 | 网络层 | 是 | 是 | 网段互联、策略控制 | 汇聚核心主力 |
这张表我建议直接背下来。排障的时候，只要先问一句"现在这个问题是冲突域层面的还是广播域层面的"，思路立刻清晰一半。
3. 透明网桥的隐形炸弹：环路与生成树
3.1 环路是怎么把一台交换机打死的
二层环路是网络里最经典的"自己把自己搞死"的案例。假设两台交换机之间接了两根线（这在施工时太常见了，为了冗余，或者单纯插错了），会发生什么？
第一，广播帧从A发出，交换机1从端口1收到，泛洪给端口2；交换机2从端口2收到，泛洪回端口1；交换机1又从端口1收到……无限循环。这是广播风暴。
第二，更隐蔽的是MAC地址表抖动。同一个源MAC的帧会从两个不同端口到达交换机，交换机的表项就在两个端口之间反复横跳，CPU占用飙升，正常转发能力下降。
第三，同一帧会被目标主机收到多份，上层协议可能出现莫名其妙的重复响应。
我在一个实验室环境里亲眼见过这个过程：插错一根网线，三十秒内整个机柜的指示灯全部狂闪，所有机器掉线。拔掉那根线，五秒内恢复。这个体验比看十遍教材都印象深刻。
注意：二层帧没有TTL，也没有"跳数"概念。三层IP包有TTL，转够跳数就丢弃，所以三层环路通常表现为"慢"或者"部分不可达"，而二层环路表现为"瞬间全崩"。这是两者最直观的区别。
3.2 生成树协议：用逻辑阻断换物理冗余
解决思路非常巧妙：既然物理上有环，那就人为地在逻辑上断开某些端口，让活跃拓扑变成一棵无环的树。一旦主链路故障，再把之前断开的端口打开补上。这就是生成树协议（STP）。
它的计算过程分三步，我用大白话讲：
**第一步，选根桥。**所有交换机互相发一种叫BPDU的报文，里面带着自己的"桥ID"。桥ID = 桥优先级（2字节）+ 桥MAC地址（6字节）。优先级默认32768，可配置，且必须是4096的整数倍。所有交换机比大小，桥ID最小的当根桥。注意：优先级相同时比MAC，MAC小的赢——所以理论上，出厂最早的设备最容易当根桥，这显然不是你想要的结果，工程上一定要手工指定根桥。
**第二步，每台非根桥选根端口。**根端口就是"离根桥最近的那个口"。怎么算近？比路径开销。路径开销是累加的：沿途所有链路的开销加起来，数值小的赢。如果开销相同，比上游交换机的桥ID，再相同比上游端口ID。每台非根桥有且只有一个根端口。
**第三步，每条链路选指定端口。**每条链路上，开销更小的那一端成为指定端口，负责转发；另一端成为阻塞端口，只收BPDU不转发数据。根桥上所有端口都是指定端口。
3.3 手工推演一次STP选举
干讲原理太虚，我们推一遍。假设三台交换机A、B、C组成三角形，A-B带宽1G，B-C带宽100M，A-C带宽1G。优先级全部默认32768，MAC地址 A < B < C。
根桥选举：优先级相同，比MAC，A最小，A当根桥。A的两个端口（连B、连C）都是指定端口，转发。
B选根端口：从B到A有两条路。直连A，1G链路，开销4；绕C到A，B-C是100M（开销19）+ C-A是1G（开销4）= 23。4 < 23，所以B连A的端口是根端口。
C选根端口：直连A，1G，开销4；绕B，19+4=23。选直连A的端口。
现在看B-C这条链路。B端的开销：到根桥的总开销是4（通过根端口）。C端的开销也是4。相同，则比上游桥ID，B的桥ID小于C，所以B这边是指定端口（转发），C这边是阻塞端口。
最终活跃拓扑：A-B、A-C两条链路转发，B-C被阻塞。如果A-C断了，B-C会经过重新收敛打开，冗余目的达成。
这个推演我建议每个学网络的人都亲自做三五遍，换不同拓扑、不同带宽、不同优先级。做完之后，你对"为什么这条链路不通"就能一眼看出来。
3.4 STP的版本演进与收敛速度
最早的802.1D标准，端口状态有五种：阻塞、侦听、学习、转发、禁用。从阻塞到转发要经历两个转发延迟，每个默认15秒，加起来30秒，再加上最大老化时间20秒，最坏情况50秒才能恢复。这个速度在今天完全不可接受——50秒，一个在线业务早就超时了。
于是有了RSTP（802.1w），端口状态精简为三种：丢弃、学习、转发，引入了边缘端口、替代端口、备份端口的概念，收敛速度从几十秒降到毫秒到秒级。边缘端口（直接接终端的口）配置之后，插上线立刻转发，不参与STP计算，也不产生拓扑变化通知——这一条极其重要，接入口不配边缘端口，一台电脑开关机就会触发全网拓扑重算，虽然RSTP下影响小，但仍然是隐患。
再往后还有MSTP（802.1s），支持多实例，可以让不同的VLAN走不同的转发路径，实现负载分担。比如VLAN10走A-B链路，VLAN20走A-C链路，两条链路都不闲着。这在双核心组网里非常常用。
| 协议 | 标准 | 端口状态数 | 典型收敛时间 | 适用场景 |
|---|---|---|---|---|
| STP | 802.1D | 5 | 30-50秒 | 老设备，仅兼容 |
| RSTP | 802.1w | 3 | 1秒内 | 当前通用 |
| MSTP | 802.1s | 3 | 1秒内 | 多VLAN负载分担 |
实操心得：接入层交换机上，凡是接电脑、接AP、接打印机的端口，一律配成边缘端口并开启BPDU保护。BPDU保护的作用是——如果这个端口上收到了BPDU（说明有人偷偷接了一台交换机进来），立刻把端口关掉。这一招能挡掉大量因为"私自接小交换机"引发的环路事故。
3.5 路径开销的数值陷阱
这里有一个非常容易踩的坑：路径开销有两套标准。老标准（802.1D-1998）按带宽给固定值：10M=100，100M=19，1G=4，10G=2。问题是10G和100G都是2，区分不出来，而且带宽越高数值越接近，比例失真。
新标准（802.1t）用了一个公式：开销 = 20000000 / 带宽（单位bps）。于是10M=2000000，100M=200000，1G=20000，10G=2000。
关键在于：**同一个网络里，所有设备必须用同一套开销标准。**如果一台设备按老标准算、另一台按新标准算，选出来的树可能是错的，甚至可能选出环。这在混插不同品牌、不同年代设备的时候特别容易发生。我建议项目开工前先确认一遍所有交换机的开销模式，统一配置。
4. 骨干网设计：把多台交换设备串起来的艺术
4.1 三种骨干拓扑的取舍
**骨干网（Backbone Network）**的作用是把多个局域网段连接起来，它自己不直接接终端，只负责高速转发。教材里通常讲三种形态：
总线型骨干，就是一根主干线，各网段通过接头挂上去。成本低，但主干一断全网瘫痪，而且接头处容易出问题。现在基本见不到了，只在一些老工业现场还有残留。
星型骨干，中心一台设备，所有网段都连到它上面。这就是"折叠式骨干"的原型——把骨干功能集中到一台或一对核心交换机上。优点是管理简单、故障定位快；缺点是中心设备是单点，必须做冗余。
点对点骨干，各网段之间通过独立链路两两相连，或者通过一个交换矩阵互联。这种形态在数据中心里最常见，因为可以做全互联或者脊叶架构，任意两点之间路径多、延迟低。
实际工程里我最推荐的是"双核心折叠式骨干"：两台核心交换机做冗余，接入交换机双上行分别接两台核心，配合MSTP做负载分担。这样任何一台核心挂了、任何一条链路断了，业务都能在秒级恢复。
4.2 带宽规划和收敛比的现实算法
骨干带宽怎么定？教材里不会给你计算公式，但实际有经验法则：收敛比。接入层到汇聚层，常见收敛比是20:1；汇聚层到核心层，常见4:1到10:1。
举个例子。一栋楼有200个接入端口，全部千兆到桌面。如果按1:1配，汇聚到核心需要200G，这显然不现实。按20:1算，汇聚上行需要10G——两根万兆链路。这个数字是这么来的：200个端口 × 1G = 200G 接入总带宽，除以收敛比20，得到10G上行。
那么收敛比定多少合适？取决于业务特征。普通办公，20:1绰绰有余，因为不可能所有人同时跑满带宽。设计院、影视后期这种大文件传输场景，建议10:1甚至更低。监控场景反过来，摄像头是恒定码流，几乎不存在"空闲"，收敛比必须按接近1:1算，否则一定会丢帧。
4.3 分层设计在实操中的落地
现在主流做法是三层结构：接入层、汇聚层、核心层。
接入层负责终端接入，用二层交换机就够了，端口密度高、价格低。这一层的重点是安全特性：端口安全（限制每个口能学到的MAC数量）、DHCP Snooping（防私接DHCP服务器）、边缘端口+BPDU保护。
汇聚层是二层和三层的分界线，通常在这里做VLAN间路由、做策略、做广播域收敛。这一层设备要有三层能力，同时端口数量不能太少。
核心层只做高速转发，配置越简单越好。核心层不要做ACL、不要做NAT、不要做任何复杂的策略，任何一条策略都是在给每一包流量增加延迟。
4.4 一个实际的带宽分配案例
某培训教室，60台机器，全部千兆到桌面，教师机需要投屏，还有一套录播系统。接入交换机两台48口，双上行到核心。
接入总带宽：60 × 1G = 60G（实际按端口算96G，但只有60个口在用）。收敛比取15:1，上行需要4G。配置两根万兆做链路聚合，带宽20G，远远够用，还留了余量给录播推流。
录播推流的码率我按8Mbps算，60路同时录制也不过480Mbps，占比很小。真正吃带宽的是"教师机投屏到60台机器"，如果是组播，一路流量复制到60个端口，实际占用不大；如果是单播，那就是60份，8Mbps × 60 = 480Mbps，也在预算内。
这个案例说明一件事：**带宽规划不能只看端口数，要看流量模型。**组播和单播差几十倍，忽略这一点，规划就是拍脑袋。
5. VLAN：在交换机内部再切一刀
5.1 VLAN解决的到底是什么
VLAN这个东西，名字里带"虚拟"，容易让人想复杂。说白了就一句话：让一台物理交换机，表现得像多台互相独立的交换机。
不划VLAN的时候，一台48口交换机就是一个广播域，48个口共享广播。划了VLAN之后，1-12口是VLAN10，13-24口是VLAN20，两组之间完全隔离——A组发的广播，B组一个字节都收不到；A组的机器想访问B组，必须经过三层设备。
它带来的好处是四条，我按实际价值排序：
**第一，缩小广播域。**这是最核心的价值。广播流量不跨VLAN，网络规模上去之后性能不会塌方。
**第二，安全隔离。**不同VLAN之间默认不通，这本身就是一道门槛。财务网和访客网划在不同VLAN，访客就算拿到内网IP也访问不了财务系统，除非三层设备上明确放行。
**第三，管理灵活。**人员调部门，不用重新布线，改一下端口归属就行。这在开放式办公区特别实用——工位是共享的，人来人走，网络跟着人的账号走，而不是跟着墙上的网口走。
**第四，不受物理位置限制。**VLAN可以跨交换机划分：一楼的三个口和三楼的五个口可以同属一个VLAN，只要中间Trunk链路放行这个VLAN就行。
5.2 四种划分方式，实际怎么选
| 划分方式 | 依据 | 优点 | 缺点 | 实用度 |
|---|---|---|---|---|
| 基于端口 | 交换机物理端口 | 配置简单、性能好、最常用 | 换端口就要重配 | 主力方案 |
| 基于MAC地址 | 终端MAC | 跟着人走 | 配置量大、伪造MAC可绕过 | 少量特殊场景 |
| 基于协议 | 帧内协议类型 | 可区分协议栈 | 现在几乎用不上 | 基本淘汰 |
| 基于子网 | IP子网 | 逻辑清晰 | 需要三层设备参与，性能略差 | 特殊场景 |
绝大多数场景，基于端口就是答案。简单、快、没有额外开销。基于MAC的方案听着美好——"人走到哪，VLAN跟到哪"——但实际操作中，你要为每一台设备手工录入MAC，几百台设备就是几百条配置，而且换网卡就失效。只有在会议室、培训教室这种"设备固定、位置不固定"的场景稍微有点用。
5.3 802.1Q标签：一个4字节的身份证
VLAN要跨交换机传播，就必须在帧里带上标识。标准做法是IEEE 802.1Q，在原始以太网帧的源MAC和类型字段之间，插入4个字节。
这4个字节的结构是：2字节的标签协议标识（值0x8100，交换机看到这个值就知道"这是个带标签的帧"），然后是2字节的控制信息——里面3位是优先级（PCP），1位是丢弃指示（DEI），剩下的12位是VLAN ID。
12位决定了一个上限：2的12次方 = 4096个VLAN。其中VLAN 0和4095保留不用，所以实际可用范围是1到4094，共4094个。VLAN 1是默认VLAN，所有端口出厂时都在里面。
这个4094的上限，就是后来各种overlay技术诞生的直接原因。一个中大型云环境，租户数量早就超过4094了，所以才有VXLAN那种用24位标识的方案（1600多万个）。这也是为什么说"理解了VLAN，就理解了现代overlay的一半"。
链路类型有两种，一定要分清：
Access口（接入口），接终端。它只属于一个VLAN，收发的帧不带标签。终端网卡根本不认识802.1Q标签，所以交换机必须在进出的方向上做标签的剥离和添加。
Trunk口（干道口），交换机之间互联，或者接AP、接虚拟化主机。它同时承载多个VLAN，帧带标签传输。标签的作用就是告诉对端"这个帧属于哪个VLAN"。
这里有个细节：Trunk口上有一个"本征VLAN（Native VLAN）"的概念，这个VLAN的帧在Trunk上传输时不打标签，对端默认按本征VLAN处理。默认本征VLAN是VLAN 1。这带来一个安全风险：如果有人利用本征VLAN和某个业务VLAN做标签欺骗，就可能跨VLAN访问。所以工程上通行的做法是——把本征VLAN改成一个专用的、不放任何业务的VLAN，并且两端必须一致。
注意：Trunk两端本征VLAN不一致，是"VLAN跳变"攻击的经典条件，同时也可能导致某些流量莫名其妙串到错误的VLAN。配置完Trunk，第一件事就是确认两端本征VLAN相同。
5.4 打标签会撑大帧，MTU要留余量
802.1Q插入4字节，意味着最大帧长从1518变成1522。这个变化看起来微不足道，但在特定场景下会出问题：如果链路上有设备做了严格的1522字节限制，带标签的大包就会被丢弃，表现为"小包能通、大包ping不通"。
我把这个问题列出来，是因为它的排查体验极差——ping 100字节能通，ping 1500字节不通，很多人第一反应是MTU问题，然后去改IP层MTU，改来改去没用，因为问题在二层。正确的思路是：先确认是不是标签导致的帧超大，再确认中间设备的最大帧长配置。
一般交换机默认就能处理1522甚至更大的帧，问题多出在老旧设备或者做了特殊限制的链路上。虚拟化环境中更要留意，因为虚拟机内部的MTU、虚拟交换机的MTU、物理交换机的MTU是三个独立的配置点。
5.5 VLAN间路由的两条路：单臂路由与三层交换
VLAN隔离带来了一个新问题：不同VLAN之间怎么通信？答案是必须经过三层设备。
**方案一：单臂路由。**在路由器的一个物理接口上划多个子接口，每个子接口对应一个VLAN，配置802.1Q封装和该VLAN的网关IP。路由器和一个Trunk口相连，一个物理口承载所有VLAN的网关。
优点是设备成本低，一台路由器搞定。缺点是性能瓶颈明显——所有VLAN间的流量都要挤过这一条物理链路，而且路由器做的是软件转发（很多中低端设备），时延高。带宽受限这个问题在实际项目里非常致命，我见过一个场景：十几个VLAN全部挤在一条千兆链路上做单臂路由，高峰期跨VLAN访问延迟飙到几百毫秒，业务系统直接报警。
**方案二：三层交换机SVI。**在三层交换机上创建虚拟接口（SVI），每个VLAN一个SVI，配上网关地址，开启路由功能。VLAN间流量在交换机内部通过硬件直接转发，速度快、没有物理链路瓶颈。
现在只要预算允许，一律选三层交换。单臂路由只在预算极度受限的小型场景还有一席之地，比如几个人的小办公室，总共三五个VLAN。
6. 一套完整可复现的VLAN实验流程
6.1 实验拓扑设计
我设计一个最小但覆盖全面的拓扑，两台交换机、四个VLAN、两条Trunk、一台三层设备做网关。
- 交换机A：端口1-4划VLAN10（办公），5-8划VLAN20（访客），24口做Trunk
- 交换机B：端口1-4划VLAN10，5-8划VLAN20，24口做Trunk
- 交换机A的24口和交换机B的24口互连
- 三层交换机C的24口接交换机A的23口，做VLAN10和VLAN20的网关
- 本征VLAN统一改为VLAN99，两端一致
6.2 配置步骤与命令
先配置交换机A的VLAN和接入端口。以下命令是业界常见的语法风格，各家设备的具体写法会有差异，思路是一致的。
# 创建VLAN vlan 10 name office vlan 20 name guest vlan 99 name native exit # 配置接入端口 interface range GigabitEthernet0/1-4 switchport mode access switchport access vlan 10 spanning-tree portfast spanning-tree bpduguard enable exit interface range GigabitEthernet0/5-8 switchport mode access switchport access vlan 20 spanning-tree portfast spanning-tree bpduguard enable exit这几行里，portfast（边缘端口）和bpduguard（BPDU保护）是我强烈建议默认带上的。它们的成本是零，收益是避免全网拓扑抖动和挡住私接交换机。
接着配Trunk。
interface GigabitEthernet0/24 switchport mode trunk switchport trunk allowed vlan 10,20,99 switchport trunk native vlan 99 exitallowed vlan这一行很关键。默认Trunk放行所有VLAN，这在安全上不理想——不必要的VLAN不应该出现在不需要它的链路上。按需放行是基本功。
交换机B配置镜像一致即可，重点是Trunk两端的允许列表和本征VLAN必须对齐。
然后配三层网关。
# 开启路由功能 ip routing # 创建SVI interface vlan 10 ip address 192.168.10.1 255.255.255.0 no shutdown exit interface vlan 20 ip address 192.168.20.1 255.255.255.0 no shutdown interface vlan 99 ip address 192.168.99.1 255.255.255.0 no shutdown三层设备连接交换机A的那个口，也要配成Trunk，允许10、20、99通过，本征VLAN设为99。
6.3 网关地址的规划逻辑
为什么网关取网段的第一个可用地址（.1）？这纯粹是习惯，取什么都可以，只要是网段内的可用地址。但习惯统一有好处：排障的人一看IP就知道网关在哪。
网段规划的算法很简单：确定每个VLAN要容纳多少台设备，向上取最近的2的幂，再留一倍余量。办公VLAN预计100台，取/24（254个可用），足够了。如果预计300台，就得用/23。
这里有个坑：**VLAN和子网不是一一强绑定的。**一个VLAN可以承载多个子网，一个子网也可以跨多个VLAN（虽然很少见）。但工程上强烈建议一一对应，因为不对应的时候，排障复杂度是成倍增加的。
6.4 验证命令与预期结果
配置完了，怎么确认真的对了？按这个顺序验证：
# 1. 看VLAN是否存在 show vlan brief # 2. 看Trunk状态和允许列表 show interfaces trunk # 3. 看MAC地址表，确认终端学到了正确端口 show mac address-table # 4. 看生成树，确认根桥和端口角色 show spanning-tree vlan 10预期结果：VLAN10里有4个端口（交换机A的1-4），VLAN20里有4个，VLAN99没有任何接入端口。Trunk口显示允许10、20、99，本征VLAN是99。
连通性测试分三组：
| 测试项 | 源 | 目的 | 预期 |
|---|---|---|---|
| 同VLAN跨交换机 | VLAN10终端 | VLAN10另一终端 | 通 |
| 跨VLAN | VLAN10终端 | VLAN20终端 | 通（经三层） |
| VLAN隔离验证 | 删除三层SVI | VLAN10终端 | 不通，证明隔离生效 |
第三组测试容易被忽略，但它才是证明"VLAN真的隔离了"的关键证据。我第一次做这个实验的时候，就是因为SVI建好了没测隔离，后来才发现自己把两个VLAN都配到了同一个网段，等于白划。
7. 常见问题与排查速查表
7.1 五个真实踩过的坑
**坑一：Trunk配了，但VLAN没放行。**现象是两个交换机上同VLAN的机器ping不通，但各自VLAN内部正常。原因是Trunk默认允许列表没改，或者新加了VLAN忘了加进允许列表。排查命令是看Trunk的允许列表，一条一条对。这个坑我踩过不止一次，现在配完Trunk必查一遍。
**坑二：本征VLAN两端不一致。**现象很诡异——业务VLAN能通，但管理地址偶尔丢包，或者抓包能看到莫名其妙的VLAN标签。原因是两端的Native VLAN不同，未打标签的帧被归到了不同的VLAN。解决办法是两端统一。
**坑三：Access口和Trunk口接反了。**把终端接到配了Trunk的口上，或者把交换机接到配了Access的口上。前者终端可能完全不通（因为终端不认标签），后者会导致VLAN丢失（所有VLAN压成一个）。手工配置的时候，一定要养成"配完立刻查"的习惯。
**坑四：三层设备没开路由功能。**SVI配好了，IP也配了，但跨VLAN就是不通。很多设备默认关闭IP路由，必须显式开启。检查方法是看路由表里有没有直连网段。
**坑五：STP收敛导致短暂不通。**刚插上网线，ping不通，等几秒又通了。这是正常的STP收敛过程。配了边缘端口就不会有这个问题。如果配了还这样，说明端口没识别成边缘（可能是配置没生效，或者端口上收到了BPDU）。
7.2 故障速查对照表
| 现象 | 可能原因 | 定位方法 | 处理 |
|---|---|---|---|
| 同VLAN跨交换机不通 | Trunk未放行该VLAN | 查Trunk允许列表 | 加入允许列表 |
| 跨VLAN全部不通 | 三层未开路由/SVI未up | 查路由表、查SVI状态 | 开路由、检查VLAN是否存在 |
| 部分终端不通 | 端口VLAN配错 | 查MAC表定位端口 | 改端口VLAN |
| 网络时快时慢 | 二层环路 | 查STP拓扑变化计数 | 找环路、开BPDU保护 |
| 大包不通小包通 | MTU/帧长限制 | 分段ping测试 | 调整最大帧长配置 |
| 换端口后长时间不通 | MAC表老化未更新 | 查MAC表 | 清表项或等待老化 |
| 广播流量异常高 | 广播域过大/环路 | 抓包看广播占比 | 划VLAN、查环 |
7.3 几条不入书但很值钱的经验
**经验一：VLAN编号做规划，别随手编。**我习惯按"区域+用途"编码，比如10-19是办公、20-29是访客、30-39是监控、90-99是管理。这样看到VLAN号就知道大概是什么业务，排障时省下大量翻文档的时间。
**经验二：管理VLAN单独划，不要用VLAN 1。**VLAN 1是所有端口的默认VLAN，也是最容易被攻击的目标。把管理地址放到一个独立的VLAN，只允许运维网段访问，这是最基本的安全加固。
**经验三：配置前先画图，标清楚每个口的归属。**我在项目上见过太多"配到一半忘了哪个口是哪个VLAN"的情况。一张手绘的端口表，能省掉后面几个小时的返工。
**经验四：改Trunk配置前，先想清楚会不会断管理。**如果管理流量走Trunk，你改本征VLAN或者改允许列表的瞬间，自己可能就掉线了。稳妥做法是先从另一条路径登录，或者准备好带外管理。
**经验五：不要在接入交换机上做复杂的ACL。**接入层设备CPU弱，大量ACL会拖垮转发性能。策略尽量往汇聚层放，接入层只做端口安全和基础隔离。
8. 我个人在这套东西上的几点体会
这些年下来，我对这一章最大的感受是：**二层的问题，90%都能用"画图+对表"解决。**画一张拓扑图，标清楚每条链路、每个口、每个VLAN；做一张配置对照表，两端逐项比对。剩下的10%才需要抓包分析。很多新手一上来就抓包，抓了半天看不出所以然，其实问题就在某一行配置上。
另一个体会是关于冗余的。冗余是好东西，但冗余必须配STP，否则冗余就是事故源。我在实际项目里定过一条规矩：**任何两台交换机之间如果存在第二条物理路径，上线前必须确认STP已经生效，且根桥已经手工指定。**这条规矩救过我好几次。
还有一点，关于"教材和现实的差距"。教材上讲透明网桥，假设拓扑是静态的、稳定的；现实里拓扑天天在变，笔记本插拔、无线AP漫游、虚拟机迁移。所以现在真正重要的不是"网桥怎么转发"，而是"拓扑变化怎么快速收敛、怎么限制影响范围"。这也是为什么边缘端口、BPDU保护这些特性比STP本身更值得花时间研究。
最后分享一个小习惯：每次做完VLAN配置，我都会故意把某个Access口改错VLAN，然后观察现象、定位、改回来。这个过程花不了两分钟，但能让你对"配错了长什么样"形成肌肉记忆。真到生产环境出问题的时候，这种记忆比任何文档都快。
