1 交换进阶要覆盖什么
交换网络把主机接入同一片可以传递以太网帧的范围。主机上的进程通过网络接口通信，交换机依据目的 MAC 地址选择出口；遇到尚未学习到的目的地址，则可能在所属 VLAN 内泛洪。广播也在所属 VLAN 内传播。这里的“范围”决定了故障会影响哪些机器，也决定了哪些接口能够直接接触彼此的二层流量。交换进阶首先要学会控制这个范围，再谈增加链路数量。
设想 1 个机房内有管理主机、构建服务器和实验虚拟机。管理员希望管理接口留在 VLAN 10，构建业务留在 VLAN 20，临时实验留在 VLAN 30。服务器上可以运行 shell、日志采集进程和文件同步进程，但进程名称不决定它属于哪个 VLAN。实际归属由主机接口、虚拟交换连接以及物理交换端口共同决定。仅把目录命名为“管理区”，或给进程换 1 个账号，都不会改变网络边界。
本课围绕 3 个问题展开：哪些端口属于同一广播域，冗余链路如何避免形成持续转发的环路，以及发生故障时如何用端口配置和主机观测相互印证。学习目标不是记住设备菜单，而是画出可检查的拓扑，预测帧能去哪里，并把预期写进基线。VLAN 间通信通常需要3层设备及相应策略；VLAN 编号本身不会自动生成访问控制规则。
在操作系统侧，先分清逻辑接口与实际连接。ip -br link 可以查看接口状态，ip -br addr 可以查看地址，ip route 可以查看路由。接口显示 UP 只说明某些本地状态满足条件，不能证明远端 VLAN 配置正确。地址存在也不能证明广播域正确。排查时先记录接口名称、接线位置、预期 VLAN 和测试目的，再解释 ping、邻居表及抓包结果，避免凭 1 个成功响应就宣布设计正确。
2 VLAN、Trunk 与二层边界
VLAN 把交换网络划分为多个逻辑广播域。相同 VLAN 的端口可以跨交换机连接，但沿途链路必须正确承载该 VLAN。不同 VLAN 即使使用相似的地址，也不会因为接在同一台交换机上就自然互通。反过来，使用不同 IP 网段并不必然表示二层隔离；如果端口实际落在同一 VLAN，它们仍可能接收到同一广播域内的帧。地址规划和交换边界必须分别核对。
接入端口通常连接不处理 VLAN 标签的终端，交换机把进入该端口的无标签帧归入配置好的 VLAN。Trunk 端口则用于在 1 条链路上传送多个 VLAN，常见于交换机互联、虚拟化宿主机上联和具备 VLAN 接口的服务器。IEEE 802.1Q 标签让接收端能够识别帧的 VLAN 归属。标签是一种转发标记，不是加密，也不会隐藏帧中的业务内容。
Trunk 配置至少要说明允许哪些 VLAN，以及如何处理无标签流量。部分设备把承接无标签流量的 VLAN 称为 native VLAN，另一些界面使用 PVID 等术语；具体入站分类、出站是否带标签，以及允许列表如何生效，应以设备文档为准。不能只核对端口旁边是否写了“Trunk”。两端对无标签流量的解释不一致时，同一帧可能在两侧被归入不同 VLAN，造成误接、泄漏或难以解释的单向通信。
例如交换机 A 和 B 之间只需传送 VLAN 10、20，就把允许集合明确写为这 2 个 VLAN，并核对两端一致。未来增加 VLAN 30 时，应把它当作需要评审的边界变更。默认允许所有 VLAN 虽然能减少临时操作，却使新建 VLAN 可能未经逐链路检查便延伸到其他区域。允许列表的作用是约束传播范围，不能替代路由、防火墙或终端权限设置。
Linux 主机也能主动发送带标签的流量。实验环境中可使用 sudo ip link add link eth0 name eth0.20 type vlan id 20 建立 VLAN 子接口，再用 sudo ip link set eth0.20 up 启用它。随后通过 ip -d link show eth0.20 核对 VLAN ID。这里的 eth0 必须替换为实际父接口。这些命令改变本机配置，远程管理所依赖的接口不宜直接拿来试验；可使用独立网卡或后文的隔离命名空间。
如果主机连接的是仅接纳无标签终端的接入端口，创建子接口不会自动把交换机变成 Trunk。若主机确实承担多个 VLAN，则要同时检查子接口、上联允许列表及每个 VLAN 的地址与路由。使用 Linux bridge 的宿主机还应查看 bridge vlan show，确认桥端口的 VLAN 成员、PVID 和出站无标签设置。每层配置都要对应到同一张表，否则“主机配了 20”与“交换机放行了 20”之间仍可能隔着错误的桥端口。
3 生成树与环路防护
冗余连线可以在设备或链路故障时提供替代路径，但以太网中的广播帧没有用于限制交换跳数的 TTL。若交换机 A、B、C 连成闭环，收到广播后都向其他出口复制，副本就可能沿环路反复流转。未知单播也可能被卷入，MAC 学习记录还会因同一源地址从不同方向出现而不断变化。结果不仅是带宽占满，也可能是交换控制处理繁忙、主机收包增多和管理连接中断。
生成树的基本目的，是让物理上存在冗余的拓扑在某个生成树实例内形成无环的有效转发路径。交换机通过控制报文交换拓扑信息，选出根桥，再决定各端口承担的角色和转发状态。入门时先理解“哪些链路当前能转发，哪些端口为了消除环路而不转发普通数据”。阻塞端口并不等于网线拔掉，它仍可参与相应控制交互，并可能在拓扑变化后转为转发。
根桥应有明确的规划。若任由默认参数决定根的位置，设备替换或接入新的交换设备后，实际路径可能偏离预期。设计中应写明主根、备选根及其适用范围。选路还受到链路开销和比较规则影响，所以仅凭图上“这条线画得更短”不能判断阻塞位置。需要先给出根和开销假设，再用运行状态确认。相同开销时还存在进一步的比较条件，本课不展开逐字段选举过程。
快速生成树能够改善某些故障情况下的收敛过程，但“快速”并不保证所有业务完全无感。链路检测、拓扑变化、设备配置和主机重试都会影响实际恢复。不同 VLAN 如何映射到生成树实例，也取决于采用的模式与配置；不能把在 VLAN 10 观察到的状态直接推广到所有 VLAN。基线需要记录模式与实例范围，复杂映射留到实际需要时再深入。
面向终端的端口可以配置边缘属性，以减少正常终端接入时的等待；同时应考虑 BPDU 防护等机制，阻止意外接入的交换设备改变拓扑。边缘属性适用于确认不会形成交换环路的终端连接，不能因为想让上联更快就随意启用。收到异常控制报文后，端口可能被防护机制关闭。此时应先确认接入了什么设备，再处理告警和恢复端口，直接反复启用可能让同一故障再次发生。
生成树、防护功能和广播限速解决的是相关但不同的问题。生成树控制有效路径，边缘端口防护约束意外拓扑，广播风暴控制限制部分异常流量的影响。限速不能证明环路消失，生成树也不能替代正确的 Trunk 边界。设计时把每种机制的作用写清，事故时才能判断是拓扑失效、接线错误还是保护阈值不合适，而不是把所有故障都归为“交换机不稳定”。
4 动手：画一张二层拓扑与阻塞口
先完成纸面推演。画出 A、B、C 这 3 台交换机，连接 A—B、A—C、B—C，假定只观察 1 个生成树实例，并指定 A 为根桥。令每条链路开销相同，再假定 B 的桥标识比较结果优于 C。此时 B、C 到 A 的直连通常分别成为各自的根路径，B—C 链路上 C 侧成为替代端口、不转发普通数据。图中要标出端口所在侧，单写“B—C 阻塞”无法准确表达端口状态。
接着模拟 A—C 断开。C 失去原来的根路径，可能通过 B 到达 A，B—C 上原先不转发的端口随拓扑重新计算而启用。此时观察的不只是“ping 是否回来”，还包括故障发生时间、端口状态变化时间和业务恢复时间。由于恢复包含多个环节，这些时间不一定相同。把断开哪条链路、预期替代路径和现场输出一起记录，才可以复现实验结论。
操作系统实验先验证 VLAN 边界，不直接制造物理环路。以下命令在具有网络管理权限、安装了 iproute2 的临时 Linux 实验机上运行，名称必须事先确认未占用。命名空间模拟终端，veth 模拟网线，Linux bridge 模拟支持 VLAN 过滤的交换设备。实验不配置网关，也不连接真实网卡，因此测试只涉及本地实验连接。
sudo ip netns add s34-a
sudo ip netns add s34-b
sudo ip link add s34-br type bridge vlan_filtering 1
sudo ip link set s34-br up
sudo ip link add s34-pa type veth peer name s34-ea
sudo ip link add s34-pb type veth peer name s34-eb
sudo ip link set s34-ea netns s34-a
sudo ip link set s34-eb netns s34-b
sudo ip link set s34-pa master s34-br
sudo ip link set s34-pb master s34-br
sudo ip link set s34-pa up
sudo ip link set s34-pb up
sudo bridge vlan del dev s34-pa vid 1
sudo bridge vlan del dev s34-pb vid 1
sudo bridge vlan add dev s34-pa vid 20 pvid untagged
sudo bridge vlan add dev s34-pb vid 20 pvid untagged
sudo ip -n s34-a link set lo up
sudo ip -n s34-b link set lo up
sudo ip -n s34-a link set s34-ea up
sudo ip -n s34-b link set s34-eb up
sudo ip -n s34-a addr add 192.0.2.1/24 dev s34-ea
sudo ip -n s34-b addr add 192.0.2.2/24 dev s34-eb
sudo ip netns exec s34-a ping -c 3 192.0.2.2命令成功执行后，2 个终端端口都把无标签流量归入 VLAN 20，预期能够完成邻居解析并通信。用 bridge vlan show 核对成员关系，用 bridge fdb show br s34-br 查看学习到的 MAC。然后先删除 s34-pb 的 VLAN 20 成员，再把该端口添加为 VLAN 30 的 PVID、出站无标签成员。此时地址仍在同一网段，但端口广播域已经分开，ping 应失败。
sudo bridge vlan del dev s34-pb vid 20
sudo bridge vlan add dev s34-pb vid 30 pvid untagged
sudo ip -n s34-a neigh flush dev s34-ea
sudo ip netns exec s34-a ping -c 3 192.0.2.2
sudo ip -n s34-a neigh show清除邻居缓存是为了让测试重新经历地址解析，减少旧状态对解释的干扰。若 ping 意外成功，检查是否存在其他连接、地址或测试对象错误；失败本身也需要结合成员表与邻居状态判断。这个实验只验证 VLAN 分类，不验证真实设备的生成树模式或 Trunk 兼容性。完成后执行 sudo ip netns del s34-a、sudo ip netns del s34-b 和 sudo ip link del s34-br 清理，命名空间删除后其 veth 对也会随之移除。
5 MLAG / 堆叠的取舍
当服务器希望同时利用多个上联时，常会遇到堆叠和 MLAG。堆叠通常把多台物理设备作为某种统一逻辑设备管理；MLAG 通常让分属不同设备的端口对下游表现为可以共同聚合的连接。具体能力和故障行为依实现而异，不能仅凭名称认定控制面完全独立、所有配置自动同步，或任何设备故障都不会影响业务。
普通链路聚合也有适用边界。服务器使用 LACP 聚合时，对端必须提供兼容的逻辑聚合关系。把服务器的 2 个聚合成员随意接到互不协调的交换机上，不会自动获得可靠冗余。应先确认设备能力，再核对成员端口、聚合模式、允许 VLAN 和服务器侧状态。Linux 上可通过 cat /proc/net/bonding/bond0 查看实际 bond 信息；这里的路径是运维时使用的接口示例，bond 名称应按现场调整。
聚合后的总容量也不等于每条连接都能独占全部成员带宽。常见实现按照流的某些字段选择成员，以尽量保持报文顺序。假设有 2 条 10 Gbit/s 成员链路，多个合适分布的流可能利用更高的总带宽，但 1 条普通连接通常仍受某条成员链路容量限制。发现文件传输没有达到 20 Gbit/s 时，先看流的数量与分布、磁盘和 CPU，再判断链路是否异常。
堆叠可能简化日常配置，但管理集中也可能扩大某些配置错误或升级操作的影响范围。MLAG 可能保留更多设备间的独立性，同时引入对等连接、状态协调和故障隔离要求。对等连接断开但设备仍在运行时，如何避免双方错误地同时承担不兼容的角色，是必须查明的故障行为。本课只要求识别这种风险，不展开协调协议内部实现。
评估时可以列出普通上联故障、单设备掉电、设备间连接中断和维护升级这 4 类事件，对每类写出预期仍可用的路径。再记录监控是否能区分成员链路故障与整个聚合故障，以及团队是否能在管理连接受影响时恢复配置。若机房规模较小、维护经验不足，具有清晰生成树路径的简单方案也可能更容易运营。选择依据应是恢复目标和验证能力。
6 常见坑：环路与广播风暴
广播风暴常表现为多个主机同时出现丢包、延迟增大、远程 shell 卡顿，交换端口流量或广播计数快速上涨。主机上运行的日志进程也可能因大量事件写盘，使文件系统占用或写入延迟恶化。这些现象互相影响，但不能仅凭“CPU 高”确定根因。正常的软件发布、备份和地址扫描也可能增加流量，需要结合广播比例、MAC 学习变化与拓扑事件建立判断。
操作系统侧可以先记录 date -Is，再执行 ip -s link show dev eth0 观察收发、丢弃与错误计数。间隔观察时关注增量，并注明间隔时长，避免把累计值当作当前速率。ip neigh show 可以帮助查看邻居解析异常；ping -c 5 适合做有限探测。若发现丢包只发生在单台主机，还应检查网卡、地址冲突和本机负载，不能立即扩大成全网拓扑事故。
抓包时采用范围和数量限制，例如 sudo tcpdump -ni eth0 -c 100 'arp or ether broadcast'。它可以展示重复的地址解析或广播，却不能单独证明环路在哪里。普通主机看不到其他端口的全部流量，VLAN 标签还可能因抓包位置和网卡卸载而不可见。需要在交换侧结合端口计数、MAC 漂移日志、生成树变化记录，以及准确时间进行比对。
确认疑似环路后，优先通过独立管理通道定位最近接入或变更的连接，按已知拓扑隔离可疑冗余边。不要在看不清连接关系时连续关闭多个上联，否则既可能扩大中断，也会丢掉判断依据。每次只改变明确的故障变量，并记录端口、动作时间与指标变化。流量下降只能说明影响减轻，还应核对有效路径已无环，以及关键 VLAN 仍具有预期连通性。
常见诱因包括有人把终端墙口互连、虚拟机桥误把 2 个上联接成透明路径、交换机互联口误设边缘属性，或不同设备的生成树配置不兼容。不要因为某段使用了服务器就假定它不会交换帧。Linux bridge、虚拟化平台和某些网络设备都可能参与转发。资产记录除了进程与文件系统用途，还应记录主机是否承担桥接、聚合或 VLAN 转发职责。
7 案例：错误 Trunk 导致的 VLAN 泄漏
某实验环境把管理网络设为 VLAN 10，把测试虚拟机设为 VLAN 20。交换机 A 与 B 通过 Trunk 相连，运维人员为了临时接入旧终端，把 A 侧无标签流量归入 VLAN 10，却把 B 侧相同链路的无标签流量归入 VLAN 20。在该设备组合的实际出站行为中，A 侧 VLAN 10 流量会以无标签形式发上链路，B 侧则把收到的无标签帧分类为 VLAN 20。边界因此出现了非预期连接。
故障最早由测试主机抓到管理地址的 ARP 请求暴露。用户能否直接登录管理服务还取决于地址、路由、主机防火墙和身份验证，不能由抓到 ARP 推导为“所有管理服务均可访问”。但管理广播进入测试域本身就违反设计。案例中应先确认意外帧的来源和入站分类，再界定可达范围，不应因为暂时登录失败就忽略已发生的二层泄漏。
排查先画出主机接口、接入口、Trunk 两端及 VLAN 归属。维护人员保存两端允许列表、无标签处理方式和端口成员关系，再在经过授权的位置做有限抓包。证据显示，同一来源的广播在 A 侧属于管理 VLAN，经互联链路传输后在 B 侧进入测试 VLAN。这里的关键不是某张截图上是否有标签，而是配置语义、采样位置和帧来源能否共同解释分类过程。
修复时在维护窗口统一两端无标签策略，明确允许列表，并让需要跨链路的业务 VLAN 按已确认的标签规则传送。对设备所要求的 native VLAN 或 PVID，也要明确用途和成员范围，避免连接业务终端。配置提交前保存可恢复版本，提交后检查端口状态、生成树状态与管理可达性；若涉及远程管理链路，应确保现场或独立管理连接可用。
验证包含正向与隔离测试：管理主机仍能访问管理网关，测试虚拟机仍能访问自身网关，测试侧重新触发观测后不再出现该管理广播。跨区业务则按设计的3层路径和策略验证。负向测试应覆盖明确的样本和时间窗口，“这次没抓到”只是证据的一部分。最终把两端配置差异和错误传播路径写入记录，作为以后新增 Trunk 时的检查项。
8 把二层设计写进网络基线
网络基线首先是一张可以对照现场的表。每个端口至少记录设备、接口、连接对象、用途、接入或 Trunk 模式、允许 VLAN、无标签处理、聚合归属和责任人。对于生成树，还需记录根桥规划、实例范围、预期替代端口与边缘防护。端口描述要能对应到机架、宿主机或布线记录；只有“服务器上联”通常不足以支持事故中的快速判断。
基线应同时保存静态意图与运行证据。配置文件说明“希望怎样工作”，端口状态、VLAN 成员、聚合状态和 MAC 学习则说明“采样时怎样工作”。快照要有时间和设备标识，配置变更应有版本。存入受控目录或版本库时，去除口令等敏感内容，并保留有用的接口上下文。不要把多个设备输出无标识地追加到同一文件，导致恢复时无法辨别来源。
每次增加 VLAN，都应从终端到互联链路逐段核对允许范围；每次增加网线，都应判断是否产生新的二层路径。变更单写明预期状态、验证方法、回退条件和恢复入口。例如新增构建 VLAN 40 时，说明哪些宿主机上联需要承载它、哪些接入口需要归入它，以及它应通过哪个3层接口访问其他网络。禁止用“先全部放开，后续再收紧”代替边界设计。
观测阈值可以关注广播增量、端口丢弃、MAC 漂移和生成树变化，但阈值必须结合正常业务采样。部署时有短时广播并不一定是风暴，持续漂移也可能来自错误聚合或真实拓扑问题。告警中最好同时附上设备、端口、VLAN 和近期变更，便于值班人员沿图定位。告警不能只报告“网络异常”，否则仍需在事故中重新拼装拓扑。
验收应包含至少 1 次可控故障演练，例如在隔离环境中断开规划好的冗余链路，比较替代路径和实际恢复。记录业务是否中断、持续多久、是否出现意外广播以及维护入口是否可靠。演练结论只适用于测试过的拓扑与条件，不能覆盖所有设备故障。随着设备替换、宿主机桥配置和业务范围变化，基线也必须同步更新。
9 从交换走向 NAT 与 VPN（S35）
交换设计回答帧属于哪个二层范围、沿哪些有效路径传播。跨网段通信则通常需要路由，边界设备可能进一步执行 NAT 或承载 VPN。进入这些主题前，必须先能解释主机如何到达自己的网关。如果本地 VLAN 错误，邻居解析就可能失败；此时修改 NAT 规则或重建 VPN 隧道，通常碰不到真正的故障点。
可以用固定顺序建立连接路径：先用 ip -br addr 确认源接口地址，再用 ip route get 198.51.100.10 查看系统计划使用的出口、源地址和下一跳，然后查看对应邻居状态。命令中的目的地址是文档示例，现场要替换为实际目标。若下一跳无法解析，先检查本地连接与 VLAN；若能到达网关而远端失败，再继续查路由、策略及后续边界。每个结论都限定到当时的源、目的与测试方式。
NAT 改变报文中的某些地址或端口映射，VPN 提供跨网络的逻辑连接；它们都不会自动修正错误的 Trunk 允许列表或消除交换环路。不同 VPN 形态可能承载不同层次的流量，下一课再区分，不能看到“隧道”就假定会延伸广播域。这里先保留清晰接口：本课交付可靠的本地接入与二层边界，下一课在此基础上解释跨边界的通信。
例如 VLAN 20 的主机访问远端地址时，若路由指向本地网关，它先解析网关的 MAC，发出的帧以网关 MAC 为目的，而 IP 目的仍是远端地址。交换机在 VLAN 20 内查找该 MAC 对应的出口，不会依据远端 IP 选择 Trunk。主机邻居表记录下一跳 IP 与 MAC 的关系，交换机转发表记录 VLAN、MAC 与端口的关系，两者不能互相替代。若网关邻居状态持续为 INCOMPLETE，可沿接入口、Trunk、网关接口检查 ARP 请求和应答在哪段消失；若邻居已有记录但流量不通，还要确认记录是否陈旧，以及网关 MAC 是否学在预期端口。错误聚合造成的 MAC 漂移可能让帧间歇性走错出口，表现得像远端隧道不稳定。
准备交接时，为每个业务列出源 VLAN、源网段、默认网关和预期远端，不把 VLAN ID 当作 IP 地址。再列出是否允许跨区访问，以及由哪处策略控制。这样当用户报告“VPN 连上但文件同步失败”时，运维人员可以从进程使用的地址和主机路由开始，逐段验证到网关，再检查映射与隧道。故障定位由可观察的接口串起来，也就不必依赖盲目重启。
放进方案里
为包含管理主机、构建服务器和实验虚拟机的机房编写方案时，先按用途建立 VLAN 10、20、30，并分别列出网段、网关与责任人。物理拓扑标明每个终端口和互联口，Trunk 只承载经过评审的 VLAN，两端无标签处理保持一致。宿主机另附桥端口与 VLAN 子接口表，使虚拟机到物理交换机之间的归属可追踪。
冗余部分明确根桥、备选根、生成树实例范围及正常情况下的替代端口，写出任意规划内单链路故障后的预期路径。若采用 MLAG 或堆叠，补充设备间连接中断和单设备维护的处理方式，并确认服务器聚合配置兼容。容量说明区分聚合总带宽与单流能力，避免把接口速率相加当作文件传输保证。
验收同时检查可达性与边界：同 VLAN 的测试终端能够完成邻居解析，不应相连的 VLAN 不出现非预期广播，跨区通信沿指定网关与策略进行。在隔离或受控维护环境中断开指定冗余链路，记录端口变化和业务恢复时间。测试需注明源接口、目的、时间与采样位置，保留端口计数和成员表，避免只提交 ping 截图。
运行部分安排广播增量、MAC 漂移、聚合成员及生成树变化的监控，指定告警责任人和独立管理入口。每次变更保存配置版本，注明回退触发条件；发现管理广播进入实验区时，先按拓扑隔离并核对 Trunk 分类。交给 S35 的清单包括源 VLAN、网段、网关与远端访问需求，使 NAT 和 VPN 设计建立在已验证的本地连接上。
为边界验收指定 1 台管理源主机和 1 台实验观测主机，在约定窗口主动触发管理 ARP，保存源侧已发出与实验侧未收到的配对证据。为冗余验收预先填写最大允许恢复时间；超时、根桥偏移或关键 VLAN 丢失均判为不通过，恢复原连接后重新核对成员表与阻塞端口。
10 小结：下一步 NAT 与 VPN（S35）
交换进阶的核心是把广播域、有效路径和故障范围写清楚。VLAN 划定逻辑边界，Trunk 延伸指定范围，生成树让冗余拓扑保持无环；MLAG 与堆叠需要结合实际故障行为选择。主机命令、桥成员表和交换侧状态提供不同位置的证据，应沿拓扑相互核对。
进入 S35 前，可以尝试回答：同网段但不同 VLAN 为什么可能无法解析邻居？物理链路正常时，哪个端口仍可能不转发普通帧？为什么 2 条 10 Gbit/s 聚合链路不能保证单次文件传输达到 20 Gbit/s？能解释这些问题，并画出本机到网关的路径，就具备继续学习 NAT 与 VPN 的基础。