课程（6 节，按顺序学）

第 1 课 · 交换机凭什么知道往哪个口发

入门 · 约 8 分钟

本课目标：搞清二层交换机全部的工作内容 —— 只有三件事：学、查、转。

先破除一个误解：交换机不聪明

很多人以为交换机里有什么复杂的算法。其实它做的事只有三件：

① 学 —— 收到一个帧，把「源 MAC」和「从哪个口进来的」记进一张表
② 查 —— 要发的时候，按「目的 MAC」去这张表里找出口
③ 转 —— 从找到的那个口发出去

★ 它不看 IP、不看端口号、不看内容，只看以太网帧头里那两个 MAC 地址。
这就是为什么说交换机对通信双方是「透明」的 —— PC1 发帧给 PC3 时，压根不知道中间经过了几台交换机。

⚠️ 最容易记反的地方

学的是「源」MAC，查的是「目的」MAC。

为什么能这样？因为二层链路是双向的。
「PC1 的帧从 GE0/0/1 进来了」这个事实，等价于
「以后要发给 PC1，就从 GE0/0/1 出去」。

★ 一句话记牢：从哪来，以后就往哪回。

动手：看一张空表被填满

去拓扑与 MAC 表页，先点「清空 MAC 表」——你会看到四张表全空了。

然后去帧转发仿真页发一个 PC1 → PC3 的帧，再回来看表。
★ 注意每台交换机学到了什么：SW1 学到了 PC1 和 PC3，SW2 也学到了这两个 ——但记的端口不一样。

实验重点

• 交换机只做三件事：学（源 MAC → 入端口）、查（目的 MAC）、转
• ⚠️ 学源、查目的 —— 这两个方向别记反
• 交换机不看 IP，对通信双方是透明的

第 2 课 · 表里查不到怎么办：泛洪

入门 · 约 10 分钟

本课目标：理解泛洪 —— 二层最反直觉、也最重要的一个行为。

刚开机时，表是空的

交换机刚上电，MAC 表是完全空白的 —— 它不知道任何设备在哪。

这时候来了一个帧，目的 MAC 查不到。它有两个选择：
· 丢掉 —— 那网络永远都通不了，因为表永远学不到东西
· 赌一把：从除入口外的所有口都发一份

★ 它选了后者。这个动作叫泛洪（flooding）。

★★ 泛洪最反直觉的地方

明明是发给一台设备的单播帧，却被送到了所有人手上。

代价是三份：
· 每一台无关主机的网卡都要收下来、比对目的 MAC、发现不是自己的、扔掉 → 白耗 CPU
· 每一条链路都被占用了一份带宽
· 内容可能被不该看到的人抓到 → 安全问题

★ 但请注意：这不是故障，是二层设计里必要的一环 ——没有泛洪，表就永远建不起来。

★ 三种要泛洪的情况，别混

· 广播帧 —— 目的 MAC 是 ffff.ffff.ffff，按定义就该发给所有人（正常行为）
· 未知单播 —— 目的 MAC 是具体的某台设备，但表里查不到（这个才值得警惕）
· 组播 —— 发给一组设备，没配组播优化时也会退化成泛洪

★ 现网抓包时如果看到大量未知单播泛洪，那是有问题的信号 ——第 5 课会讲它真正的成因。

动手：亲眼看到扇出

去帧转发仿真页，先清空 MAC 表，然后发 PC1 → PC3。

★ 看第一步 SW1 那里：画布上会有多条线同时亮起来 ——这就是泛洪的扇出。
而其中只有一个方向是有用的，界面上标了出来。

实验重点

• 查不到 → 泛洪（除入口外所有口都发一份）
• 泛洪不是故障，没有它表就建不起来
• ★ 但未知单播泛洪值得警惕：单播帧被送给了所有人
• 泛洪的代价：无关主机白耗 CPU + 链路白占带宽 + 内容可能被抓包

第 3 课 · 主机手里只有 IP：ARP 补上这道缝

入门 · 约 10 分钟

本课目标：理解 ARP 存在的唯一理由，以及它为什么必须用广播。

缺口在哪

你 ping 一个 IP，或者浏览器访问一个网址 —— 应用层给的是 IP 地址。
但网卡要发帧，帧头里填的是 MAC 地址。

★ 这里有一道缝：知道 IP，但不知道 MAC。
ARP（Address Resolution Protocol）存在的唯一理由就是补这道缝。

★ 为什么必须用广播

ARP 要问「谁是 10.0.0.3」。但这里有个鸡生蛋的问题：

我想问，可我不知道该问谁 —— 因为「该问谁」本身就需要 MAC 地址。

打破这个循环只有一个办法：广播，问所有人。
目的 MAC 填 ffff.ffff.ffff，广播域里每一台设备都会收到并检查：
「这个 IP 是我吗？」—— 是的那台就单播回复。

★ 回复为什么可以是单播？ 因为请求帧里带着源主机的 MAC，应答方已经知道该回给谁了。

★★ 最漂亮的地方：表是被 ARP 建起来的

把第 1、2 课的知识接上来看一次完整的通信：

① ARP 请求（广播）泛洪到全网 → 沿途每台交换机都学到了源主机的 MAC
② 目标单播回复 → 因为表刚建好，这一路都是「查到了」，不再泛洪
③ 真正的数据帧发出 → 一路干净单播

★★★ 是第一个帧（ARP 请求）的泛洪把表建起来的。
这就是为什么现网抓包很少看到泛洪 ——不是没发生过，是发生在你开始观察之前。

★ 跨网段时，ARP 问的是网关

主机发帧前先做一次判断：「目的 IP 和我同网段吗？」

· 同网段 → ARP 问对方的 MAC，帧头目的 MAC 填对方的
· 跨网段 → ARP 问网关的 MAC，帧头目的 MAC 填网关的

⚠️ 第二条是高频错误点：跨网段时帧头里压根不会出现目的主机的 MAC。
二层只负责把帧送到网关，剩下的是三层的事。

动手：走一遍 ARP

去 ARP 协议页，让 PC1 解析 PC3 的 IP。
看两个帧：请求（广播、泛洪）和回复（单播、一路命中）。

★ 然后一定要看页面下半部分那两张并排的表 —— 下一课就讲它们。

实验重点

• ARP 补的缝：知道 IP，但帧头要 MAC
• ★ 请求必须广播（还不知道该问谁），回复可以单播（请求里带着源 MAC）
• ★★ 表是被第一个帧的泛洪建起来的
• ⚠️ 跨网段时 ARP 问的是网关，帧头目的 MAC 填网关的

第 4 课 · ★★ 两张表别搞混：ARP 缓存 vs MAC 表

入门 · 约 8 分钟

本课目标：把二层最容易混的一对概念彻底分开。

并排放一起看

| | ARP 缓存 | MAC 地址表 |
|---|---|---|
| 在谁身上 | 主机 | 交换机 |
| 键 → 值 | IP → MAC | MAC → 端口 |
| 解决什么 | 我知道 IP，帧头却要 MAC | 我知道 MAC，要选一个口发 |
| 怎么来的 | 发 ARP 问出来的 | 收帧时从源 MAC 自己学的 |
| 默认超时 | 20 分钟 | 300 秒 |
| 查看命令 | display arp | display mac-address |

★ 记法：ARP 缓存跨越三层和二层（IP→MAC）；MAC 表纯粹在二层内部（MAC→端口）。

一次 ARP 会同时改两张表

这是最容易混的原因 —— 它们经常同时被填上。

PC1 解析 PC3 一次之后：
· PC1 的 ARP 缓存多了一条：10.0.0.3 → PC3的MAC
· SW1 / SW2 的 MAC 表各多了两条：PC1的MAC → 某个口、PC3的MAC → 某个口

★ 同一次操作、两种完全不同的表。去 ARP 页看那两张并排的表格。

⚠️ 但它们独立老化 —— 这是第 5 课的伏笔

注意上面那张表最后一行的超时时间不一样：20 分钟 vs 300 秒。

这个不对称会造成一个很具体的现网现象，下一课讲。

动手：亲手把它们分开

去拓扑与 MAC 表页，那里有两个独立的按钮：
· 清空 MAC 表（只清交换机的）
· 清空 ARP 缓存（只清主机的）

★ 分别点一次，看清哪张表变了、哪张没变。

实验重点

• ARP 缓存在主机上，IP → MAC
• MAC 表在交换机上，MAC → 端口
• 一次 ARP 会同时填这两张表 —— 所以容易混
• ⚠️ 但它们独立老化，超时时间差了 4 倍

第 5 课 · 表会忘事：老化与未知单播泛洪的真实成因

进阶 · 约 10 分钟

本课目标：理解老化机制，以及现网里未知单播泛洪到底是怎么来的。

为什么必须老化

MAC 表不能只增不减，原因有两个：

· 表容量有限 —— 交换机的 MAC 表是硬件表，几千到几十万条，会满
· 设备会挪位置 —— 笔记本从 3 楼搬到 5 楼，表项不更新就发错方向

所以每条动态表项都带一个计时器：300 秒没再见到这个 MAC，就删掉。
★ 注意「见到」指的是收到它发的帧（源 MAC 是它）——只要它一直在说话，表项就一直刷新，永远不会被老化。

★★★ 于是有了这个现网现象

把两个超时时间放一起：

· 交换机 MAC 表：300 秒
· 主机 ARP 缓存：1200 秒（20 分钟）

MAC 表先忘。

考虑一台「很久说一次话」的设备 —— 备份服务器、打印机、监控探头：
① 它 10 分钟没发过任何帧 → 交换机把它的表项老化掉了
② 但别的主机 ARP 缓存里还记得它的 MAC（20 分钟才过期）
③ 于是主机照常发单播帧给它
④ 交换机查表 → 没有 → 泛洪

★★ 这就是未知单播泛洪的真实成因。
它不是配置错误，是两个默认值不匹配造成的必然结果。

动手：亲手复现它

去拓扑与 MAC 表页：
① 先发一次 PC1 → PC3，让表建好
② 点「清空 MAC 表」——但别清 ARP 缓存
③ 回帧转发仿真页再发一次 PC1 → PC3

★ 这次你会看到：PC1 不发 ARP 了（缓存里有），直接发单播；
但交换机查不到 → 未知单播泛洪。界面会明确标出来。

★ 也可以用「推进时间」按钮，看老化真实发生一次。

怎么治

· 调长 MAC 表老化时间 —— 让它别比 ARP 缓存短太多
· 给关键设备配静态 MAC 表项 —— 静态表项不老化
· 让设备定期说话（很多监控探头就是靠心跳包顺带刷新表项的）

★ 现网优先选第二个：把服务器 / 网关的 MAC 钉死在指定端口上，顺带还防了 MAC 欺骗。

实验重点

• 动态表项 300 秒没见到就老化；只要还在说话就一直刷新
• ★★★ 未知单播泛洪的真实成因：MAC 表 300 秒先忘，ARP 缓存 1200 秒还记得
• 它不是配置错误，是两个默认值不匹配的必然结果
• 治法：调长老化时间 / 配静态表项（不老化）

第 6 课 · ★★★ 泛洪 + 环路 = 灾难

排障 · 约 12 分钟

本课目标：看清二层最严重的故障，以及为什么它比三层的环路可怕得多。

★★★ 根因一句话：以太网帧头里没有 TTL

先对比三层：IP 头里有个 TTL 字段，每经过一台路由器减 1，减到 0 就丢掉。
所以三层的环路虽然也是故障，但报文会自己死掉，网络还能喘气。

再看以太网帧头，一共就这几个字段：
目的 MAC | 源 MAC | 类型 | 数据 | FCS

★ 没有 TTL，没有跳数，没有任何「活了多久」的记录。
一个广播帧进了环路，就会永远转下去。

而且是指数级增长

更糟的是它不只是「一直转」，而是一直翻倍：

① PC1 发出 1 个广播帧
② 第一台交换机泛洪成 N 份
③ 每一份到下一台交换机，又各自泛洪成 N 份 → N² 份
④ 再一轮 → N³ 份……

★ 六七轮之后就是天文数字。而没有任何机制让它们减少。

三个症状同时发生

· 广播风暴 —— 链路带宽被瞬间打满，所有业务全断
· MAC 表震荡 —— 同一个 MAC 从多个端口反复进来，表项被反复覆盖。
★ 这比「表是空的」更糟：表看起来是满的、有内容的，交换机以为自己知道该往哪发，但那个答案一直在变而且经常是错的
· CPU 打满 —— 交换机忙着复制帧

⚠️ 最后一条是现网最可怕的地方：你往往没法远程处理 ——管理口都登不上去，只能到机房拔线。

动手：把网络打死一次

去环路与广播风暴页（当前场景已经是三角环路），点「开始仿真」。

★ 看三样东西：
① 每轮的帧副本数 —— 指数增长
② 链路占用率 —— 很快超过 100%
③ MAC 表震荡列表 —— 同一个 MAC 在两个口之间跳

★ 也可以试试「④ 双链路冗余」场景 ——那是现网最常见的成因：有人为了保险多接了一条线。

★ 解法：STP，以及它的代价

这里有个矛盾要想清楚：冗余链路本身是好事 ——你接第二条线的目的就是「一条断了另一条顶上」。

所以正确的做法不是「不要冗余」，而是「有冗余，但同时只用一条」。

STP（Spanning Tree Protocol，生成树协议） 做的正是这件事：
· 在所有链路里算出一棵生成树
· 把多余的链路阻塞掉（不转发，但保持监听）
· 主链路断了，被阻塞的端口自动接管

★ 代价是被阻塞的链路买了不能用 —— 一半带宽闲置。
这正是数据中心后来用 L3 + ECMP 取代 STP 的原因（去「数据中心 Spine-Leaf」模块的「架构对比」页看那个对比）。

★★ 顺带把两个容易混的缩写分清：
· STP（Spanning Tree，生成树，二层）→ 算一棵树，阻塞冗余链路
· SPF（Shortest Path First，最短路，三层）→ 算最短路，所有链路都能转发
OSPF 和 IS-IS 模块用的是后者。

实验重点

• ★★★ 根因：以太网帧头里没有 TTL，帧进环路就永远转下去
• 副本指数级翻倍，没有任何机制让它减少
• 三个症状：广播风暴 + MAC 表震荡 + CPU 打满
• ⚠️ CPU 打满意味着没法远程救，只能到机房拔线
• ★ 解法是 STP：保留冗余但只用一条，代价是一半带宽闲置