波仔
📡 第二章 彻底理解L2交换机
📄 一句话概括

「MAC 地址数」就是 MAC 表的容量，单位是表项，不是「能接几台设备」。 表满了不报错：它退化成集线器，网络还能用，但慢、而且所有人都能听到别人。

📝 本节和前面几节的关系

02.07 讲完端口，从这里开始讲「端口之外还带什么功能」。 第一个就是最基础的 MAC 地址数——它决定了「泛洪会不会失控」。

一、它不是「能接几台设备」

表是按「源 MAC ＋ 端口」学的，所以一台设备可能占多条：双网卡占 2 条、每台虚拟机占 1 条。

所以选型要按「虚拟化密度」估，不按「机柜里有几台机器」估。

一个典型柜顶： 20 台物理服务器（双网卡）＋ 600 台虚拟机 ＋ 12 个存储与管理口 ＋ 200 条上行学到的地址 ＝ 1212 条。 8K 够用。

二、表满了会怎样

不报错、不断网，它会「泛洪」。新地址挤掉老地址，老地址下次查不到，就从所有口发出去。

症状特征：交换机 CPU 不高、端口没报错，但一抓包发现大量本该单播的帧在多口同时出现。

这类故障最误导人：用户只说「网慢」， 而所有常规指标看起来都正常——只有 MAC 表项数和泛洪计数能看出问题。

三、常见档位

8K：普通接入交换机。够几百台终端。 16K：中端设备。 32K 到 128K：数据中心柜顶。服务的不是 40 台服务器，是几千个虚拟网卡。

还有一条容易忽略的：MAC 表容量与 VLAN 数常常共享同一块芯片资源。 划的 VLAN 越多，每 VLAN 可用的表项可能越少。高密度虚拟化场景要问清这一点。

四、动手 Demo：一台柜顶交换机实际占用多少表项

这段按「20 台双网卡服务器、600 台虚拟机、12 个存储管理口、200 条上行」统计，再算占 8K 的比例。

rows = [(u"物理服务器（双网卡）", 2, 20), (u"虚拟机（每台一个 vNIC）", 1, 600),
        (u"存储与带外管理口", 1, 12), (u"上行学到对端", 1, 200)]
for a, b, c in rows:
    total += b * c
    T([a, u"%d" % b, u"%d" % c, u"%d" % (b * c)], [0, 0, 0, 0])

实跑输出：

--------------------------------------------------------------------
MAC 地址数，8K 到底能接多少台
--------------------------------------------------------------------
**「MAC 地址数」就是 MAC 表的容量。**规格书上写 8K、16K、32K，单位是「条表项」。

**先纠正一个直觉**：它不是「能接多少台设备」。一台设备可能占多条——
**因为表是按「源 MAC + 端口」学的，一台机器有几个网卡、几个虚拟机，就占几条。**

**算一个柜顶交换机的实际占用**：

  来源                        单台占用     数量     表项
  ----------------------------------------------------------
  物理服务器（双网卡）        2            20       40
  虚拟机（每台一个 vNIC）     1            600      600
  存储与带外管理口            1            12       12
  上行学到对端                1            200      200
  合计                        —            —        852

**852 条。**8K（8192）够用，但已经用掉 10%。
**如果这台服务器要跑到 2000 台虚拟机**：

  2252 条，8K 用掉 27%，**接近上限**。

**表满了会怎样？**不会报错，也不会断网——**它会「泛洪」。**
新学到的地址挤掉老的，老地址下次收到帧时又查不到，于是从所有口发出去。
结果就是：**网络能用，但慢、而且所有人都能听到别人的流量。**

**这类故障的特征很好认**：交换机 CPU 不高、端口没报错，
但一抓包发现大量本该单播的帧变成了「多口同时出现」。

**所以选型时 MAC 表要按「虚拟化密度」估，不按「机柜里有几台机器」估。**
这也是为什么数据中心柜顶交换机常配 32K 甚至 128K 表项——
**它服务的不是 40 台服务器，是几千个虚拟网卡。**

合计 1212 条，8K 用掉 15%。看起来余量很大，但把虚拟机改成 2000 台就是 2812 条（34%）， 再翻一倍就到上限了。

所以「8K 够不够」这个问题不能只看今天：虚拟化密度是会涨的， 而 MAC 表容量买定离手。数据中心选 32K 不是因为今天需要，是因为三年后需要。

最后提醒一句：那 200 条「上行学到的地址」容易被漏算。 上行口会学到对面交换机下所有设备的 MAC——接入层几百台终端，上行口就学几百条。 这部分占用是隐性的。

30 秒实验

  1. 在交换机上查 MAC 表项总数与容量上限。
  2. 数一下某台服务器上跑了几台虚拟机、几个虚拟网卡。
  3. 看交换机端口的「泛洪」计数有没有在涨。

常见误区

  1. 以为 MAC 地址数等于能接几台设备。一台设备可能占多条。
  2. 表满会报警。它静默泛洪。
  3. 只看今天的规模。虚拟化密度会涨。
自测三问（点开对答案） 1. MAC 表是按什么学的？ —— 源 MAC 地址加它进来的端口。 2. 表满了会怎样？ —— 不报错，新地址挤掉老地址，查不到就泛洪，交换机退化成集线器。 3. 为什么数据中心要 32K 以上？ —— 虚拟化密度高，几千个虚拟网卡各占一条。

下一节：第二个功能是帧的长度——巨型帧。

相关笔记