3. 链路层调试：MAC地址表学习、ARP协议工作原理、VLAN标签处理
链路层调试，说白了就是搞清楚交换机怎么认路、设备怎么找人、以及广播域怎么切。这三个东西搞不明白，网络出问题你连从哪下手都不知道。我刚开始带团队那会儿，有个兄弟调了一下午的VLAN不通，最后发现是MAC地址表没刷新——这种坑，踩过一次就记住了。
3.1 MAC地址表学习机制
交换机不是天生就知道每个端口后面连着谁。它得学。怎么学？看源MAC。
一台交换机刚上电，MAC地址表是空的。这时候A发了个帧给B，交换机从端口1收到这个帧，一看源MAC是AA:AA:AA:AA:AA:01，立马在表里记一笔：
MAC地址 端口
AA:AA:AA:AA:AA:01 GigabitEthernet0/0/1然后它查目的MAC，发现表里没有B的地址，怎么办？泛洪——除了接收端口，其他所有端口都发一遍。这就是经典的“未知单播泛洪”。
核心要点：MAC地址表学习只关心源MAC，转发决策只关心目的MAC。这两个动作是独立的，但缺一不可。
我在项目中遇到过一个问题：某台服务器频繁丢包，抓包一看，交换机MAC地址表在疯狂抖动。原因是服务器网卡做了双工协商失败，一直在发错误的MAC地址。嗯，这种问题不查MAC表根本定位不到。
3.1.1 MAC地址表老化
MAC地址表不是永久有效的。默认老化时间一般是300秒。如果某个MAC在300秒内没再发过帧，交换机就会把它删掉。这么做是为了适应网络拓扑变化——你想想看，如果一台笔记本从端口1换到端口2，老条目还在，那数据就送错了。
| 参数 | 默认值 | 调整建议 |
|---|---|---|
| MAC老化时间 | 300秒 | 稳定网络可适当延长，频繁变动网络建议缩短 |
| MAC表容量 | 视设备而定（8K~128K） | 核心层建议不低于32K |
| 静态MAC | 无 | 关键服务器建议绑定静态MAC |
调试技巧：用 show mac-address-table 查看当前表项。如果发现同一个MAC出现在多个端口，大概率是环路或者网卡故障。
3.2 ARP协议工作原理
MAC地址表解决的是二层转发问题，但设备之间通信用的是IP。怎么把IP映射到MAC？这就是ARP干的事。
ARP的工作流程其实很简单：
- 主机A想和主机B通信，但只知道B的IP，不知道B的MAC
- A发一个ARP请求广播：谁的IP是192.168.1.2？请告诉我你的MAC
- B收到后，发现问的是自己，就回复一个ARP应答：我是192.168.1.2，我的MAC是BB:BB:BB:BB:BB:02
- A收到应答，把IP和MAC的对应关系写进ARP缓存
这里有个细节：ARP请求是广播，ARP应答是单播。为什么？因为请求不知道目标MAC，只能广播；应答已经知道请求者的MAC了，直接单播回去就行。
注意：ARP协议没有任何认证机制。谁都可以发ARP应答。这就是ARP欺骗攻击的根本原因。我曾经在一个客户现场抓到过有人私接路由器导致断网——就是ARP欺骗搞的鬼。
3.2.1 ARP缓存与老化
ARP缓存也有老化时间。Windows默认是120秒，Linux默认60秒。老化之后，下次通信需要重新发ARP请求。
我个人习惯在调试时先用 arp -a 看看缓存里有没有目标IP的条目。如果没有，那就是ARP没学到；如果有但通信还是不通，那就检查MAC地址是不是对的。
# Windows查看ARP缓存
arp -a
# Linux查看ARP缓存
ip neigh show
# 清除ARP缓存（调试时常用）
arp -d 192.168.1.2避坑指南：我曾经遇到过一个问题——两台设备配置了相同IP，导致ARP表在两者之间来回跳。现象就是网络时通时断。排查方法很简单：在交换机上查看MAC地址表，发现同一个IP对应的MAC在变。这种问题，ARP表一看就知道。
3.3 VLAN标签处理
VLAN的作用是把一个物理网络切成多个逻辑网络。交换机怎么区分不同VLAN的数据？靠标签。
IEEE 802.1Q标准在以太网帧头里插入了4字节的VLAN标签。结构如下：
| 字段 | 长度 | 说明 |
|---|---|---|
| TPID | 2字节 | 固定值0x8100，标识这是802.1Q帧 |
| PCP | 3位 | 优先级，用于QoS |
| DEI | 1位 | 丢弃指示，用于拥塞控制 |
| VID | 12位 | VLAN ID，范围1-4094 |
交换机端口有两种模式：
- Access口：只属于一个VLAN，收到帧时打上对应VLAN标签，发出时去掉标签。一般连终端设备。
- Trunk口：可以承载多个VLAN，帧带着标签走。一般连交换机或路由器。
调试要点：用 show vlan brief 查看VLAN配置，用 show interfaces trunk 查看Trunk口允许的VLAN列表。很多VLAN不通的问题，就是Trunk口没放行对应VLAN。
3.3.1 VLAN标签处理流程
交换机处理VLAN标签的流程，我画了个图，你看一眼就明白了：
3.3.2 常见VLAN调试问题
我整理了几个实际项目中经常遇到的VLAN问题：
- VLAN不通：先查Trunk口有没有放行对应VLAN。用
show interfaces trunk一看便知。 - 帧被丢弃：检查端口的allowed VLAN列表。我曾经遇到一个案例，Trunk口只放行了VLAN 10-20，但业务用了VLAN 30，结果全丢了。
- 标签不匹配：Access口的PVID和实际VLAN不一致。比如端口PVID是10，但收到的帧带的是VLAN 20标签，交换机会直接丢弃。
重要提醒：VLAN 1是默认VLAN，很多交换机把VLAN 1作为管理VLAN。安全考虑，建议把管理VLAN改成其他ID，比如VLAN 99。我在等保测评项目里，这个配置几乎是必改项。
3.4 三者联动：一个完整的通信过程
把MAC地址表、ARP、VLAN串起来，看一个完整的通信过程：
- 主机A（IP: 192.168.10.1, VLAN 10）想和主机B（IP: 192.168.10.2, VLAN 10）通信
- A检查ARP缓存，没有B的MAC，于是发ARP请求广播
- 交换机从Access口收到这个广播帧，打上VLAN 10标签
- 交换机在VLAN 10内泛洪这个ARP请求（除了接收端口）
- B收到ARP请求，回复ARP应答（单播）
- 交换机学习到B的MAC地址，并转发应答给A
- A学到B的MAC，开始发送数据
- 交换机查MAC表，直接转发，不再泛洪
这个过程看起来简单，但任何一个环节出问题，通信就断了。我调试的时候，习惯按这个顺序排查：先看ARP能不能学到，再看MAC表有没有条目，最后看VLAN配置对不对。这个顺序，基本能覆盖90%的二层问题。