专栏： 《计算机网络基础》· 第五篇·链路 / 物理层
承接： 《链路层导论：帧如何交给邻站》
讲解维度： 概念 → 原理 → 应用 → 问题定位
读完你能： 讲清以太网帧与 MAC 学习；解释交换机为何不是「路由器」；用 ethtool / 双工与环路思路排有线故障
导读：插上网线之后，真正跑的是「帧」
有线办公、机房机柜、家用光猫下挂的小交换机------绝大多数时候，局域网的事实标准仍是 以太网（Ethernet）。
网络层已经决定：从 eth0 发给下一跳 192.168.1.1。
网卡驱动真正推到线上的，却是带 目的 MAC / 源 MAC 的以太网帧。中间那台八口小盒子、机柜里那排接入交换机，主业不是查 IP 路由表，而是靠 MAC 地址表 决定从哪个口送出。
很多人第一次抓包会愣一下：Wireshark 最外层明明写着 Ethernet，里面才套着 IP。
其实这很正常------你在办公网里「通不通」，经常先卡在这一层：链路有没有 up、口有没有学到 MAC、广播有没有被风暴淹没。
主机A 交换机 主机B / 网关
│ 帧(目的=B的MAC) │ │
│────────────────►│ 查MAC表 │
│ │──────────────────────►│本篇把帧格式、学习老化、洪泛、双工协商和环路直觉摊开，并给几组本机能做的小实验。VLAN、无线另章展开；这里先把「有线二层」摸熟。
一、概念：以太网在认什么、管什么？
1.1 它解决的问题
以太网 ：以 帧 为单位、用 MAC 标识邻站、在局域网内交付的链路层技术族。速率从百兆到 100G+ 都有，介质可以是铜缆、光纤，甚至虚拟交换机上的 veth------骨架仍是「帧 + MAC +（常常还有）交换」。
它不管「跨很多个网络怎么选路」；那是 IP 的事。它也不保证可靠投递：FCS 错了就丢，重传多半靠上层。日常排障时，把它当成：
同一广播域里，邻站之间怎么把比特收成一帧、再交给对的人。
1.2 它管什么 / 默认不管什么
| 它管 | 默认不管 |
|---|---|
| 本段链路的邻站寻址（MAC） | 跨网段选路（那是路由） |
| 成帧、类型字段、FCS 校验 | 「一定到达」、保序、重传 |
| 交换机内的学习 / 转发 / 洪泛 | 加密（那是 TLS / MACsec 等另话题） |
| 速率、双工、链路是否 up | 端口号、进程监听（传输层 / 应用） |
经典边界再念一遍：
Link detected: no → 先查线、口、光模块、对端供电
同网段 ARP 全 FAILED → 可能 VLAN / 口隔离 / 对端关机（下一章）
ping 通但 443 不通 → 多半不是以太网本身的锅1.3 MAC：邻站门牌，不是「全世界唯一身份证」
常见 48 位，写成 aa:bb:cc:dd:ee:ff。前半段常能看出厂商 OUI，后半段区分设备------但排障时别迷信「绝对唯一」：克隆、虚拟化、容器、高可用漂移都会改写或漂移 MAC。
记住三件事：
-
跨路由器之后，每一跳都会换一层链路封装；帧上的目的 MAC 是「当前这一跳的邻站」，不是远端服务器的 MAC
-
交换机主要靠 源 MAC 学习、目的 MAC 转发；它一般不拆开帮你改 IP
-
ff:ff:ff:ff:ff:ff是广播------同广播域里人人都该听见（能不能处理是另一回事）
1.4 Ethernet II 帧：你天天在抓的那层信封
现网最常见的是 Ethernet II（DIX）格式。直觉版：
目的MAC(6) | 源MAC(6) | EtherType(2) | 载荷 | FCS(4)线上还会有前导码（Preamble）/ SFD 帮着对齐比特流；抓包工具通常从目的 MAC 开始给你看。字段人话：
| 字段 | 你要知道的 |
|---|---|
| 目的 MAC | 这一跳交给谁；全 F 为广播；组播有特定范围 |
| 源 MAC | 谁发的------交换机用它「学习：这人在哪个口」 |
| EtherType | 里面是啥：0x0800 IPv4，0x86DD IPv6，0x0806 ARP... |
| 载荷 | 常见承载 IP / ARP 等；长度受 MTU 约束 |
| FCS | 帧校验序列；错了接收侧通常直接丢，上层可能表现为偶发重传 |
还有一套经典 802.3 + LLC/SNAP 的故事（长度字段 vs EtherType 的判别），现代 IP 网络里你更常撞到 Ethernet II。抓包时最外层「Ethernet」就是这份信封；-e 打开链路层地址后，很多「同网段玄学」会突然变清楚。
最小帧、最大帧有历史包袱（早期还要给 CSMA/CD 留槽时间）。今天全双工交换占主流，你更常关心的是：载荷默认按 1500 字节 IP MTU 来设计；机房若开巨型帧，两端与路径都要对齐------这和隧道章里的 MTU 故事是亲戚。
常见：Ethernet 载荷 ≤ 1500 → 对应 IP MTU 1500
巨型帧（jumbo）：载荷可到 9000 量级（实现各异）
两端一个开一个不开 → 大包怪、小包正常1.5 单播 / 组播 / 广播
| 类型 | 目的 MAC 特征 | 典型用途 |
|---|---|---|
| 单播 | 具体主机 MAC | 普通点到点通信 |
| 广播 | ff:ff:ff:ff:ff:ff |
ARP 请求、部分发现 |
| 组播 | 特定范围（最低位等特征） | 发现协议、部分流媒体 |
广播会扩散到 广播域------在没划 VLAN 的朴素交换网里，往往就是「这些口串在一起的那片」。同域里 ARP、DHCP、误接环路，都会让交换机与主机一起加班。下一章会看到：ARP 请求正是靠广播「喊一嗓子」的。
1.6 交换机 vs 路由器（边界要清）
| 二层交换机 | 路由器 / 三层设备 | |
|---|---|---|
| 主要看 | MAC 地址表 | IP / 路由表 |
| 典型动作 | 同网段（同广播域）内转发帧 | 跨网段选下一跳 |
| 改不改 IP 头 | 一般不改 | TTL 等会变 |
| 环路风险 | 二层环 → 风暴 / MAC 抖动 | 路由环 → TTL 耗尽 |
家用「路由器」盒子里往往 路由器 + 交换机 + Wi‑Fi AP 焊在一起。后面四个 LAN 口彼此像小交换机；WAN 口才更像路由边界。排障时要问清楚：坏的是 交换口 / 链路协商 ，还是 路由 / NAT / Wi‑Fi。
有些盒子系统设置里还能看到「AP 隔离」「访客网络」------那是在二层或策略上把口切开，表现会像「都连着同一个 SSID / 同一台盒子，却互 ping 不通」。
二、原理：学习、洪泛、环路与协商
2.1 MAC 学习：从源地址记住「人在哪个口」
交换机并不预知全世界的 MAC。它靠偷看进来的帧：
口1 收到帧：源MAC=AA
→ 表项：AA → 口1
口3 收到帧：源MAC=CC
→ 表项：CC → 口3人话版：谁从哪个口说话，就把「人名（MAC）→ 门口编号」记下来。
下次有帧要找 AA，就不用满屋子喊，直接从口 1 送出去。
表项有 老化时间（不同设备默认从几十秒到几分钟不等）：人不说话久了，条目会忘------再出现时重新学。主机休眠、笔记本合盖、虚拟机暂停，都可能让表项过期；醒来后第一阵流量里，你会短暂看到更多洪泛，直到表重新填满。
学习还会被「异常」打脸：同一 MAC 突然从另一个口进来，表项会迁移到新口。正常场景包括笔记本换了墙上的口、虚拟机漂移；异常场景包括环路导致 MAC 在多口之间乱跳------后面环路一节再展开。
2.2 转发：已知单播、未知单播、广播
目的 MAC 在表里 → 从对应口送出（已知单播）
目的 MAC 不在表里 → 向除来源口外的端口洪泛（未知单播 flood）
目的是广播 / 部分组播 → 在广播域内扩散（受 VLAN 等限制）「未知单播洪泛」是很多人对交换机的第一误解：以为交换机会像路由器一样「查不到就丢」。二层默认更像：
不认识这个人？先问问整层楼------除了刚才说话那扇门。
所以刚清空 MAC 表、或大量主机同时上线时，交换机会更「吵」。表学满之后，单播流量才安静下来。广播本身无法靠「学目的 MAC」消掉------广播的目的就是让域内都听见。
2.3 为什么交换机「不是路由器」------用一次转发对比
同一台接入交换机上，主机 A 要访问同网段主机 B：
1. A 已通过 ARP 知道 B 的 MAC（下一章）
2. A 发出以太网帧：目的=B的MAC，源=A的MAC，里面是 IP 包
3. 交换机看目的 MAC：在表 → 从 B 所在口送出
4. IP 头里的源/目的 IP 全程不变；TTL 也不因「过交换机」而减若 B 在另一个网段，帧的目的 MAC 往往是 网关的 MAC ；交换机只负责把帧送到网关口，网关再改链路封装、查路由往外扔。
把这两步混在一个脑模型里，就会出现「交换机上能学到外网服务器 MAC」这种幻觉------学不到，也不该学到。
2.4 环路与 STP 直觉：广播如何把网打爆
早期以太网共享介质靠 CSMA/CD 听信道；今天全双工点到点链路占主流，冲突域被切得很碎。但 二层环路 并没有退休------两台交换机之间随手插两根线，又没有任何环路保护时：
广播帧被反复复制 → 广播风暴
未知单播也可能被放大
MAC 表项在不同口之间抖动 → 闪断、极慢、CPU 打满有一次机房巡检，两台接入之间多插了一根「备份」网线，又没开环路防护：监控大盘先是接口流量直线起飞，再是一整层楼的电话开始响。看起来像遭受攻击，其实是帧在环上滚雪球。
园区网常用 STP / RSTP / MSTP 一类生成树：在逻辑上堵住冗余边，需要时再切换。数据中心有更多现代方案（本专栏不展开协议细节）。你只要先建立排障指纹：
整片广播域同时炸、交换机 CPU 飙高、同一 MAC 在多口乱跳------先怀疑环路，再怀疑「是不是业务发布把流量打爆了」。
生成树的直觉不是「让网络变快」，而是「有冗余拓扑时，先保证不要自己咬自己」。口状态若长期卡在 listening / blocking 一类（不同厂商显示名不同），也可能表现为「线插着却不通」------这时别只盯着 IP。
2.5 速率与双工：自协商，以及那次「一边强制一边自动」
链路两端要谈妥两件大事：
| 项目 | 含义 |
|---|---|
| Speed | 100M / 1G / 10G... |
| Duplex | 全双工 / 半双工 |
| Auto-negotiation | 是否自动谈上述参数 |
现代设备默认自协商，多数时候插上就能 work。坑在「有人好心强制」：
有一次两端一边把电口强制成 100M full，另一边保持自动。链路灯还是绿的，ping 小包偶发能通，大文件传输却错包狂涨、速度像回到拨号时代。查了半天才发现是经典 双工不匹配：一端以为全双工，一端实际落到半双工，碰撞 / 错误计数在悄悄报警。
ethtool eth0
# 关注：Speed / Duplex / Auto-negotiation / Link detected示意输出（健康千兆口）：
Settings for eth0:
...
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
...
Link detected: yes若你看见 Speed: 100Mb/s 却预期是千兆，先查线缆品类（有些线只能跑到 100M）、水晶头、口脏污、对端是否限速，再查是否有人写了强制速率。
2.6 FCS、错包与「慢」的物理味道
FCS 不对的帧，网卡 / 交换机通常直接丢掉。你在 ip -s link 或 ethtool -S 里看到的 rx errors、frame、crc、collisions（名称因驱动而异）往上爬时，常见根因包括：
双工不匹配
线缆质量差 / 过长 / 干扰
光模块不匹配、光衰过大
网卡或交换口硬件故障
异常巨型帧 / MTU 不一致（表现也可能是丢大包）链路显示 up 不等于「这一跳很干净」。有线故障里，「极慢、偶断、重传多」常常比「彻底 link down」更磨人------后者至少灯灭了，前者还得盯计数器。
2.7 巨型帧与 MTU（和网络层交界）
以太网载荷默认常按 1500 字节 IP MTU。机房存储、部分 HPC / 东西向流量会开 jumbo frame，把载荷抬到 9000 一类量级（具体以设备为准）。
要求很朴素、却容易忘：
发送端、接收端、中间交换机路径
对巨型帧的支持与配置要一致不一致时的症状像隧道章：小包正常，大包失败或极慢；有时只在某一跳开始丢。云上的「虚拟以太网」未必把宿主机巨型帧能力完整暴露给你------别假设公有云弹性网卡默认 9000。
三、应用：从家里到机房到云
3.1 家用：光猫、小交换机、随手换口
光猫/路由器 LAN 口 → 小交换机 → 多台电脑 / NAS / 电视盒子你换网线、换口，本质是换交换端口；IP 可能仍是 DHCP 租约那一个，但链路协商会重来，交换机要重新学习你的 MAC。
家里若串了两台傻瓜交换机又绕成环，一样能风暴------廉价设备往往没有靠谱的环路保护。
3.2 园区 / 公司接入
电脑 → 接入交换机 → 汇聚 → 核心 → 出口路由器口上常绑 VLAN 、端口安全、802.1X、DHCP Snooping 一类能力。「插上却上不了网」不一定是 IP 配错，也可能是：口在 guest VLAN、没通过认证、MAC 数超限被打到隔离 VLAN。
这时 ethtool 可能显示 link up，邻居表却一直空------别只在主机上改地址，问问网管这个口允许什么。
3.3 数据中心与服务器双上行
服务器双上行、TOR 交换机、聚合链路（bonding / LAG）......细节繁多，但排障仍常从这几行开始：
光模块是否亮、对端是否 up
ethtool 速率 / 双工是否预期
RX/TX errors、FCS、drop 是否在涨
聚合口是否一边 down 一边 up 导致哈希倾斜「业务机看着 CPU 不高却打不满带宽」，有时是单队列 / 单流哈希撞到一根成员链路上------那是性能话题的入口；本篇先要求你能证明：链路层有没有在丢、有没有在半速跑。
3.4 云上的「虚拟以太网」
云主机的 eth0 后面往往是虚拟交换机 + 覆盖网络。你仍可用：
ip link
ethtool eth0 # 视虚拟化实现，信息可能简化甚至很少安全组 / 网络 ACL 是另一层过滤；「虚拟网卡 up 但业务不通」要同时想策略。虚拟场景里广播、混杂模式、MAC 反欺骗规则也可能和物理机房不一样------但 MAC 学习 / 洪泛 的基本剧情仍在，只是演员换成了 vSwitch。
3.5 和下一章的衔接：帧发出去之前还缺一块拼图
主机已经知道下一跳 IP，还要知道下一跳 MAC，才会把目的 MAC 填进帧头。
这块翻译工作是 ARP（IPv6 侧常是 ND）。以太网保证「有帧、有交换」；ARP 保证「帧上的门牌填得对」。同网段不通时，两章要连着看。
四、问题定位：有线链路怎么查？
4.1 故障速查
| 现象 | 以太网侧常见根因 | 先做什么 |
|---|---|---|
完全不通，灯不亮 / NO-CARRIER |
线、口、供电、光模块、对端关机 | 换线换口；ip link 看 LOWER_UP |
| Link up 但极慢、错包涨 | 双工不匹配、线劣、干扰、坏口 | ethtool；盯 rx/tx errors |
| 速率只有 100M（预期千兆） | 线序/线材、强制速率、口能力 | 查协商与线缆；对齐两端配置 |
| 同交换机部分主机互访失败 | VLAN / 口隔离 / 风暴边缘 | 对照口配置；抓广播是否异常 |
| 整片网同时卡死、交换机 CPU 高 | 二层环路、广播风暴 | 找环、看 MAC 抖动、临时拆冗余线 |
| 大包失败、小包正常 | MTU / 巨型帧不一致 | 两端与中间路径对齐 MTU |
| ping 通业务不通 | 多半不是二层主因 | 转端口 / 防火墙 / 应用 |
4.2 决策树
有线「不通 / 极慢」
│
├─ Link detected: no / NO-CARRIER
│ → 换线、换口、查对端、查光衰/模块
│
├─ Speed / Duplex 与预期不符，或一端强制一端自动
│ → 统一自协商或统一强制；避免混用
│
├─ ip -s link / ethtool -S 错包、碰撞持续上涨
│ → 双工、线缆、干扰、坏网卡/坏口
│
├─ 同网段 ARP 失败 / 邻居 FAILED
│ → 下一章；同时怀疑 VLAN、口隔离、对端没上线
│
├─ 整片广播域同时炸、MAC 多口乱跳
│ → 环路 / 风暴；先物理拆环再谈业务
│
└─ 链路干净、邻居也正常
→ 转路由、防火墙、应用
4.3 常用命令（Linux）
ip -br link
ip -s link show eth0 # RX/TX errors, dropped, overruns...
ethtool eth0
ethtool -S eth0 | head -n 40 # 驱动统计，字段名因卡而异持续观察错误是否增长（比看一眼绝对值有用）：
watch -n1 'ip -s link show eth0 | sed -n "1,12p"'抓帧看 MAC 与类型：
sudo tcpdump -ni eth0 -e -c 20
# -e 打印链路层地址；留意目的是否广播、EtherType 是否预期4.4 和「网卡中断 / 多队列」的关系（ foreshadow ）
多队列网卡上，不同队列常对应不同中断；性能调优会看 /proc/interrupts、RPS/XPS 一类旋钮。
本专栏横切篇会再碰；这里只需知道：链路层之上，驱动与中断决定收包效率------链路 up 且无错包，仍可能被软中断或单队列卡住上限。
五、动手：把帧、协商和计数器摸实
下面以常见 Linux /
iproute2+ethtool为例。接口名请换成你机器上的（ip -br link查看）。部分云主机 / Wi‑Fi 网卡对ethtool支持有限，选有线口做更有感觉。
实验 A：读链路状态与协商参数
ip -br link
ethtool eth0在纸上填：
接口名：__________
状态（UP / LOWER_UP？）：__________
Speed：__________
Duplex：__________
Auto-negotiation：__________
Link detected：__________期望：有线插好时 Link detected: yes，办公千兆口常见 1000Mb/s + Full + Auto-negotiation: on。
若 NO-CARRIER 或 Link detected: no，先别排 IP------物理/链路还没交付成功。
示意：
$ ip -br link
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 52:54:00:ab:cd:ef <BROADCAST,MULTICAST,UP,LOWER_UP>实验 B：盯错误计数------「安静」还是「在流血」
先拍一张快照，过 30～60 秒再拍一次（或用 watch）：
ip -s link show eth0
# 记录 RX errors / dropped / overruns 与 TX 侧计数
sleep 30
ip -s link show eth0期望：空闲或轻载时，错误类计数基本不动。
若你一边跑 iperf3 / 大文件拷贝，一边看见 errors 持续增加，优先走双工与线缆方向，而不是先重启业务进程。
可选：看驱动详细统计（字段名五花八门，搜索 crc、frame、align、collision）：
ethtool -S eth0 | rg -i 'err|crc|frame|drop|collision|fec'实验 C：用 tcpdump -e 看见以太网头
在授权环境、尽量选流量不多的口：
sudo tcpdump -ni eth0 -e -c 15示意输出（字段随版本略有差异）：
12:01:03.112233 aa:bb:cc:dd:ee:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: ...
12:01:03.112401 aa:bb:cc:dd:ee:fe > aa:bb:cc:dd:ee:01, ethertype ARP (0x0806), length 42: ...
12:01:03.112520 aa:bb:cc:dd:ee:01 > aa:bb:cc:dd:ee:fe, ethertype IPv4 (0x0800), length 98: ...你要能指着屏幕说出：
谁是源 MAC、谁是目的 MAC
这一帧是广播还是单播
EtherType 是 ARP 还是 IPv4/IPv6若满屏都是 ff:ff:ff:ff:ff:ff 且速率异常高，结合交换机 CPU / 业务是否全员遭殃，把「风暴 / 环路」提到优先怀疑列表。
实验 D（可选）：对比 MTU
ip link show eth0 | rg mtu
ping -c 2 -s 1472 -M do 192.168.1.1 # 1472+28≈1500；地址换成你的网关
ping -c 2 -s 8000 -M do 192.168.1.1 # 若路径不支持巨型帧，通常失败期望：在默认 1500 路径上，大 ping 以 DF 方式会失败或提示需要分片；不要在生产随手改交换机巨型帧------这是思想实验 + 受控环境实验。
本章小结
以太网用帧在局域网交付；MAC 标识邻站
交换机学源 MAC、按目的 MAC 转发；未知单播则洪泛
广播域决定 ARP 等能吵多远；环路可把吵闹变成灾难
速率/双工靠协商；一端强制一端自动是经典慢速坑
FCS/错包计数是有线「在流血」的信号
巨型帧与 MTU 必须路径一致
先看 link 与 ethtool，再怪业务