冲突域的分界点：路由器（Router）天然隔离冲突域。交换机的每个端口是一个独立的冲突域。集线器（Hub）的所有端口在一个冲突域里。
**排查实战：**
我遇到过一起典型的性能投诉。某部门说网络“间歇性卡顿”，Ping网关有时延迟上千毫秒。当时我第一反应就是——是不是有人在用Hub？
结果进去一看，果然。一个角落的工位为了省钱，用了一个8口Hub串联了5台电脑和一个IP电话。整个网段都在抢信道。
**排查步骤很简单：**
1. **看硬件指示灯：** Hub的“Collision”灯狂闪，不用测了，铁定冲突严重。
2. **检查双工状态：** 看网卡是否被协商成半双工。我习惯在交换机上用 `show interface
# 在思科交换机上查看端口双工和冲突计数器
Switch> enable
Switch# show interfaces FastEthernet 0/1
FastEthernet0/1 is up, line protocol is up
Hardware is Fast Ethernet, address is xxxx.xxxx.xxxx (bia xxxx.xxxx.xxxx)
MTU 1500 bytes, BW 100000 Kbit
Half-duplex, 100Mb/s
...
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
...
1 runts, 0 giants, 0 throttles
1 input errors, 0 CRC, 0 frame
0 output errors, 0 collisions, 0 late collisions
# 如果“late collisions”非零，说明冲突域过大或线缆超长。
注意：半双工环境下，如果产生“late collision”（后碰撞），多半是网线超过了100米限制，或者物理环路。碰到这个，直接查物理布线。
#### 广播域：二层网络里的“大喇叭”
广播域，说白了就是“谁都能收到广播帧”的范围。以太网里的ARP、DHCP依赖广播。但广播多了，就是一场灾难。
一个交换机所有的端口默认在一个广播域里。路由器（三层设备）隔离广播域。如果你把两台交换机叠在一起不做任何隔离，整个二层网络就是一个巨大的广播域。
**广播风暴是实打实的问题。**
我曾经处理过一个故障：某栋楼全部断网。抓包一看，ARP请求满街跑，每秒几千个，交换机CPU直接暴涨到100%。查了半天，发现是某台傻瓜交换机被环路搞疯了，一直在泛洪广播帧。这就是广播域失控的典型案例。
**定位方法：**
1. **交换机上的接口计数器：** 查看端口广播流量占比。
2. **抓包分析：** 用Wireshark看广播帧的MAC地址。如果看到一堆 `FF:FF:FF:FF:FF:FF`，并且间隔很短，说明有异常。
3. **三层隔绝：** 可以用VLAN划分广播域。或者直接在网关设备（路由器/L3交换机）上启用`ip directed-broadcast`（谨慎使用，默认关闭）。
**对比记忆：**
| 特性 | 冲突域 | 广播域 |
| :--- | :--- | :--- |
| **典型设备** | Hub（冲突域内所有端口） | Hub、Switch（广播域内所有端口） |
| **分界点** | 交换机端口/路由器 | 路由器/L3交换机/VLAN |
| **故障表现** | 丢包、高延迟、Late Collision | CPU高、ARP泛洪、瘫痪 |
| **排查工具** | show interface counters | show interface counters, Wireshark |
#### CRC错误定位：物理层的“伤痕检测”
CRC错误，也就是循环冗余校验错误。它直接说明这个帧在传输过程中受到了物理层损伤。原因多半是——
* 网线质量差（阻抗不匹配、线序错误）。
* 网卡故障（硬件坏了，发出来的帧就是错的）。
* 电磁干扰（电源线、强磁场贴着网线走）。
* 光模块光功率过低或过高。
**我个人习惯，排查CRC错误有个黄金三连招。**
1. **排除时钟抖动：** 确认两端双工、速率强制一致。一旦协商成半双工和非对等速率，CRC错误几乎是必然的。
2. **更换物理介质：** 这是我最常用的招数。低概率50%的物理层问题，换一根标准超五类或六类网线能瞬间解决。
3. **看错误计数：** 很多运维人员只看端口状态“UP”，不看错误计数器。我建议定期做 `show interface counters errors`。
# 华为交换机查看CRC错误
display interface GigabitEthernet 0/0/1
GigabitEthernet0/0/1 current state : UP
...
Input: 1024 packets, 10240 bytes
Output: 2048 packets, 20480 bytes
Input error: 12,
CRC error: 12, # 这里的CRC error数很关键
Frame error: 0,
Runts: 0, Giants: 0
...
如果CRC错误只在入方向递增，说明问题出在本端网线或对端网卡。如果出方向有错误（在支持出方向CRC检查的设备上），通常是对端设备有问题。
**定位流程：**
1. 先看“CRC error”是否增长。
2. 如果增长：换本端端口、换网线。
3. 如果仍增长：更换对端网卡或光模块。
4. 如果是光纤：查光功率（发光功率正常范围一般是-3dBm到-15dBm）。
我曾经处理过一个光链路故障。光模块发光功率-23dBm，属于临界偏低。链路上偶尔能通，经常CRC错误。我换了个高灵敏度光模块后，错误归零。
#### 一张图串起来
下面这张图帮助理解这三层故障的排查逻辑。说白了，从物理层（CRC）往上看，你会先看到冲突（半双工），然后看到广播（二层泛洪）。底层的物理问题不解决，上层的逻辑排查就是白费力。