552 lines
27 KiB
Markdown
552 lines
27 KiB
Markdown
---
|
||
tags: [计算机网络, Switch, Hub, Router, VLAN, STP, RSTP, EtherChannel, L3Switch, MAC, CEF, ARP, IGMP, DAI, BPDU]
|
||
create time: 2026-05-17 23:20
|
||
---
|
||
|
||
# Switch vs Hub vs Router
|
||
|
||
## 概述
|
||
|
||
这三种设备是构建局域网的核心组件，但它们工作在完全不同的 OSI 层，转发决策的依据也不同。理解它们的差异是设计网络拓扑的基础。
|
||
|
||
| 特性 | Hub（集线器） | Switch（交换机） | Router（路由器） |
|
||
|------|-------------|-----------------|-----------------|
|
||
| OSI 层级 | 物理层 L1 | 数据链路层 L2 | 网络层 L3 |
|
||
| 寻址依据 | 无（全量复制） | MAC 地址 | IP 地址 + 路由表 |
|
||
| 冲突域 | 全部共享 | 每个端口独立 | 每个接口独立 |
|
||
| 广播域 | 全部共享（一个广播域） | 不隔离（同 VLAN 内） | **天然隔离** |
|
||
| 性能 | 极低（半双工） | 高（全双工并行） | 依赖 CPU/ASIC |
|
||
| 现代使用 | ❌ 已淘汰 | ✅ 局域网核心 | ✅ 网关/边界 |
|
||
|
||
## Hub（集线器）——已淘汰的共享介质
|
||
|
||
### 工作原理
|
||
|
||
Hub 本质上就是一个多端口的中继器（Repeater）。收到任何端口的电信号，放大后复制到所有其他端口。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A["PC-A 发送"] -->|"信号"| H["Hub"]
|
||
H -->|"原样复制"| B["PC-B 收到"]
|
||
H -->|"原样复制"| C["PC-C 碰撞"]
|
||
|
||
style H fill:#FF6B6B,color:#fff
|
||
```
|
||
|
||
### 致命缺陷
|
||
|
||
1. **所有端口在同一冲突域**：两台同时发送 = 碰撞 → CSMA/CD 退避
|
||
2. **只能半双工**：同一时刻要么收要么发
|
||
3. **无法隔离故障**：一台 PC 中毒疯狂发包会影响所有人
|
||
4. **安全性差**：所有流量对所有端口可见
|
||
|
||
> [!question] 思考
|
||
> Hub 已经被淘汰了，为什么我们还要了解它？因为 **Switch 的泛洪行为本质上就是退化成了 Hub**——理解 Hub 的缺陷，才能理解后面 CAM 表攻击的危害。
|
||
|
||
### 冲突域 vs 广播域
|
||
|
||
这两个概念贯穿整个 L2 学习，必须清晰区分：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
subgraph "冲突域 Collision Domain"
|
||
CD1["同一时刻只能有一方发送, 否则碰撞"]
|
||
end
|
||
|
||
subgraph "广播域 Broadcast Domain"
|
||
BD1["一条广播帧能到达的所有设备集合"]
|
||
end
|
||
|
||
Hub["Hub: 所有端口 = 1 个冲突域, 1 个广播域"]
|
||
SW["Switch: 每端口 = 1 个冲突域, 同 VLAN = 1 个广播域"]
|
||
RT["Router: 每接口 = 既隔离冲突域, 也隔离广播域"]
|
||
|
||
style CD1 fill:#FF6B6B,color:#fff
|
||
style BD1 fill:#87CEEB,color:#000
|
||
```
|
||
|
||
> [!question] 思考
|
||
> 交换机能隔离冲突域，但不能隔离广播域（VLAN 内）——那广播风暴的防护靠什么？答案是 **VLAN 分割广播域** + **STP 防环**，这也是后面两篇笔记的核心主题。
|
||
|
||
## Switch（交换机）——现代 LAN 核心
|
||
|
||
### 工作原理
|
||
|
||
Switch 维护一张全局 MAC 表（CAM 表），记录"哪个 MAC 地址在哪个端口"的映射关系。收到帧时查表，只将帧转发到目标端口，实现"点对点"通信。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
S["Switch MAC表 mac_A→Port1, mac_B→Port2"]
|
||
|
||
A["PC-A Port1"] -->|"发给 mac_B"| S
|
||
S -->|"仅从 Port2 发出"| B["PC-B"]
|
||
|
||
D["PC-D Port4"] -->|"未知目标"| S
|
||
S -->|"泛洪到 Port1,2,3"| N["Port1到3都收到, 只有正确的会处理"]
|
||
|
||
style S fill:#98FB98,color:#000
|
||
```
|
||
|
||
> [!question] 思考
|
||
> Switch 的泛洪和 Hub 的复制有什么区别？Hub 是**无差别地复制所有帧**，而 Switch 只在 **MAC 表中找不到目标时**才泛洪。一旦学到地址，就走精确转发——这就是"智能"的地方。
|
||
|
||
### MAC 表学习流程
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant SW as Switch
|
||
participant A as PC-A mac_A
|
||
participant B as PC-B mac_B
|
||
|
||
A->>SW: Frame mac_A→mac_B from Port1
|
||
SW->>SW: Learn mac_A on Port1
|
||
SW->>B: Flood mac_B unknown
|
||
|
||
B->>SW: Reply Frame mac_B→mac_A from Port2
|
||
SW->>SW: Learn mac_B on Port2
|
||
|
||
A->>SW: Next Frame mac_A→mac_B from Port1
|
||
SW->>SW: Forward directly to Port2
|
||
```
|
||
|
||
> [!info] MAC 地址表的老化
|
||
> 交换机的 CAM 表条目不是永久的。如果某个 MAC 地址在**老化时间**（默认通常 300 秒 / 5 分钟）内没有再出现，该条目会被自动清除。这保证了表项不会被已离线设备永久占据，但也是 MAC 泛洪攻击能生效的前提——攻击者必须持续发送伪造帧来维持表满状态。
|
||
|
||
### Switch 的关键优势
|
||
|
||
| 特性 | 说明 |
|
||
|------|------|
|
||
| **每个端口一个冲突域** | 端口间互不影响 |
|
||
| **全双工通信** | 收发光纤分开，可同时对发对收 |
|
||
| **硬件转发** | ASIC 芯片查 MAC 表，延迟 < 1μs |
|
||
| **背板带宽** | 交换机内部总线，决定交换能力上限 |
|
||
| **VLAN 支持** | 802.1Q 实现逻辑分割 |
|
||
|
||
> [!tip] 关于全双工
|
||
> 全双工 = 收发同时进行，物理上收发走不同线对（或波长）。这意味着**冲突域的概念在全双工下已不存在**——不需要 CSMA/CD。
|
||
|
||
> [!info] IGMP Snooping：多播流量的守护者
|
||
> 交换机默认会把多播帧像广播一样泛洪到所有端口。**IGMP Snooping** 让交换机监听 IGMP 报文，学习哪些端口有多播组成员，只将多播流量转发到有接收者的端口。典型场景：IPTV 组播、视频会议。没有 IGMP Snooping 的交换机在多播场景下会严重浪费带宽。
|
||
|
||
### 常见 Switch 规格参数
|
||
|
||
| 参数 | 说明 | 典型值 |
|
||
|------|------|-------|
|
||
| 端口速率 | 千兆/万兆/25G/100G | 1/10 Gbps |
|
||
| 端口数 | 24/48 口最常见 | — |
|
||
| 背板带宽 | 内部交换容量 | 双向 ≥ 端口总数 × 速率 × 2 |
|
||
| 包转发率 | PPS (packets per second) | 10G 端口满速 ≈ 14.88M PPS |
|
||
| 缓存 | SRAM 缓冲丢包 | 几 MB ~ 几百 MB |
|
||
|
||
> [!question] 思考
|
||
> 10G 端口满速为什么恰好是 **14.88M PPS**？因为最小以太网帧 64 字节 + 8 字节前导码 + 12 字节帧间距 = 84 字节，10Gbps / (84×8 bits) ≈ 14.88M。记住这个数字，面试常考。
|
||
|
||
### 交换模式：帧怎么被转发的？
|
||
|
||
交换机在转发帧时，有三种读取策略，它们在**延迟**和**可靠性**之间做出不同的取舍：
|
||
|
||
| 模式 | 行为 | 延迟 | 错误检测 | 适用场景 |
|
||
|------|------|------|---------|---------|
|
||
| **Cut-through** 直通转发 | 读完目标 MAC 就立刻开始转发 | 最低 | ❌ 不校验 | 对延迟极端敏感的高频交易 |
|
||
| **Store-and-Forward** 存储转发 | 完整接收帧 → CRC 校验 → 无误再转发 | 较高 | ✅ 完整校验 | **现代交换机默认模式** |
|
||
| **Fragment-Free** 无碎片转发 | 读取前 64 字节后转发（过滤冲突碎片） | 中等 | ⚠️ 部分 | 早期 Catalyst 交换机 |
|
||
|
||
> [!info] 为什么 Fragment-Free 检查恰好 64 字节？
|
||
> 以太网规定最小帧长 64 字节。**冲突产生的碎片（runt frame）一定小于 64 字节**——如果一个帧在传输前 64 字节期间没发生冲突，后续碰撞的概率极低。Fragment-Free 通过检查前 64 字节，用较低代价过滤掉了绝大部分冲突碎片，是 Cut-through 和 Store-and-Forward 之间的折中方案。
|
||
|
||
> [!tip] 为什么 Store-and-Forward 成为主流？
|
||
> 早期 ASIC 算力不够，Cut-through 有延迟优势。但现代 ASIC 做 CRC 校验几乎零开销，Store-and-Forward 的可靠性优势（能丢弃损坏帧、避免错误帧浪费带宽）远大于那点微秒级延迟差异。
|
||
|
||
### STP：交换机环路的终结者
|
||
|
||
当交换机之间存在冗余链路时（高可用设计的标配），帧可能在环路中无限循环：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
SW1["SW1 根桥"] -->|"转发"| SW2["SW2"]
|
||
SW1 -->|"转发"| SW3["SW3"]
|
||
SW2 -->|"广播帧循环"| SW3
|
||
SW3 -->|"广播帧循环"| SW2
|
||
|
||
style SW1 fill:#98FB98,color:#000
|
||
style SW2 fill:#FFD700,color:#000
|
||
style SW3 fill:#FFD700,color:#000
|
||
```
|
||
|
||
**环路会导致三大灾难：**
|
||
|
||
1. **广播风暴**：广播帧被无限复制，瞬间耗尽带宽
|
||
2. **MAC 表抖动**：同一帧从不同端口到达，交换机不断更新 MAC 表导致转发表不稳定
|
||
3. **重复帧接收**：终端收到多份相同帧，协议栈混乱
|
||
|
||
**STP（Spanning Tree Protocol, 802.1D）的解决思路：** 通过选举算法，逻辑上"阻塞"某些端口，让拓扑变成一棵无环的树。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
SW1["SW1 根桥 Root Bridge"] -->|"DP"| SW2["SW2"]
|
||
SW1 -->|"DP"| SW3["SW3"]
|
||
SW2 -->|"DP"| SW3
|
||
SW3 -.->|"BLK 阻塞"| SW2
|
||
|
||
style SW1 fill:#98FB98,color:#000
|
||
style SW2 fill:#DDA0DD,color:#000
|
||
style SW3 fill:#FFD700,color:#000
|
||
```
|
||
|
||
> [!info] 图中端口角色
|
||
> - **DP（Designated Port）**：每个网段上负责转发的端口，由到根桥路径开销最小的交换机拥有。**根桥的所有端口都是 DP**（图中 SW1 的三个端口、SW2→SW3 链路上 SW2 的端口均为 DP）。
|
||
> - **RP（Root Port）**：每个非根桥上有且仅有一个到达根桥的最优端口。图中 **SW2 面向 SW1 的端口** 和 **SW3 面向 SW1 的端口** 就是各自 RP。比较规则：路径开销最小 → 对端 Bridge ID 最小 → 对端 Port ID 最小。
|
||
> - **BLK（Blocked）**：逻辑阻塞，不转发数据帧，仅接收 BPDU 以防拓扑变化。图中 **SW3 面向 SW2 的端口被阻塞**，从而打破环路。
|
||
|
||
STP 选举规则：
|
||
|
||
1. **选根桥**：Bridge ID（优先级 + MAC 地址）最小的交换机
|
||
2. **选根端口（RP）**：每个非根桥选一个到根桥"最优路径"的端口（比较路径开销 → 对端 Bridge ID → 对端 Port ID）
|
||
3. **选指定端口（DP）**：每个网段选一个负责转发的端口（通常是离根桥更近的一方）
|
||
4. **阻塞其余端口**：不转发数据帧，只接收 BPDU
|
||
|
||
> [!tip] STP vs RSTP
|
||
> 经典 STP 收敛需要 30~50 秒（Blocking → Listening → Learning → Forwarding），这在现代网络中不可接受。**RSTP（802.1w）** 将收敛时间缩短到**秒级**，是当前生产环境的标准选择。
|
||
|
||
### STP 安全增强机制
|
||
|
||
STP 本身没有认证，恶意设备可以伪造 BPDU 抢占根桥或制造环路。以下三个机制是生产环境必备：
|
||
|
||
| 机制 | 作用 | 应用位置 |
|
||
|------|------|---------|
|
||
| **BPDU Guard** | 如果接收到 BPDU，立即 shutdown 端口 | 连接终端的 Access 端口（防止用户私接交换机） |
|
||
| **Root Guard** | 如果收到更优的 BPDU，将端口置为 root-inconsistent | 非信任方向端口（防止非法设备抢占根桥） |
|
||
| **Loop Guard** | 如果单向链路故障导致收不到 BPDU，将端口置为 loop-inconsistent | RP 和 Alternate 端口（防止单向故障引起环路） |
|
||
|
||
> [!question] 思考
|
||
> BPDU Guard 和 Root Guard 看起来很像，区别在哪？**BPDU Guard 是"绝不允许 BPDU 出现"**——一旦收到就关停，适用于接入层终端端口。**Root Guard 是"允许 BPDU 但不允许更优的"**——保护根桥地位不被篡改，适用于汇聚/核心层非信任方向端口。
|
||
|
||
### EtherChannel：STP 的补丁
|
||
|
||
STP 阻塞冗余端口来防环，但代价是**浪费了那条链路的带宽**。EtherChannel（LACP/PAgP）将多条物理链路捆绑成一条逻辑链路，解决这个问题：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
SW1["SW1"] -->|"物理链路 x4 捆绑为 1 条逻辑链路"| SW2["SW2"]
|
||
Note1["STP 只看到 1 条逻辑链路, 不会阻塞"] -.-> SW1
|
||
```
|
||
|
||
| 特性 | 说明 |
|
||
|------|------|
|
||
| **带宽叠加** | 4 条 1G 链路 = 1 条 4G 逻辑链路 |
|
||
| **STP 透明** | STP 将捆绑组视为单条链路，不阻塞任何成员 |
|
||
| **故障切换** | 某条物理链路断开，流量自动分配到剩余链路 |
|
||
| **协商协议** | LACP（802.3ad，开放标准）/ PAgP（Cisco 私有） |
|
||
|
||
> [!info] 负载均衡哈希算法
|
||
> EtherChannel 的"负载均衡"并非逐包轮询，而是**基于流（per-flow）哈希**——同一对源/目的通信始终走同一条物理链路，保证帧顺序不乱。哈希输入字段的选择直接影响均衡效果：
|
||
>
|
||
> | 哈希模式 | 哈希字段 | 适用场景 |
|
||
> |---------|---------|---------|
|
||
> | `src-mac` | 源 MAC | 服务器下行（多客户端 → 一服务器） |
|
||
> | `dst-mac` | 目的 MAC | 多服务器场景 |
|
||
> | `src-dst-ip`（推荐） | 源 + 目的 IP | 大多数场景，均衡效果最佳 |
|
||
> | `src-dst-mac` | 源 + 目的 MAC | 二层环境 |
|
||
>
|
||
> ```bash
|
||
> # Cisco 配置哈希算法
|
||
> Switch(config)# port-channel load-balance src-dst-ip
|
||
> ```
|
||
|
||
> [!question] 思考
|
||
> 既然 EtherChannel 这么好，为什么不把所有链路都捆绑？因为捆绑的成员链路必须连接相同的两端设备、相同速率/双工，且有数量上限（通常 8 条）。更重要的是——基于流的哈希意味着**单条流仍然只能走一条物理链路**，不能突破单链路速率上限。如果只有少数大流量流，可能出现"看似 4G 实际只用 1G"的不均衡。
|
||
|
||
### CAM 表安全：当 Switch 退化成 Hub
|
||
|
||
交换机的 CAM 表（MAC 表）容量是有限的，通常为数千到数万条。攻击者可以利用这一点：
|
||
|
||
**MAC 泛洪攻击原理：**
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant ATK as Attacker
|
||
participant SW as Switch CAM 8192 entries
|
||
participant V as Victim
|
||
|
||
ATK->>SW: 伪造 10万+ 个随机源 MAC 帧
|
||
SW->>SW: CAM 表溢出
|
||
Note over SW: 无法学习新 MAC, 退化为 Hub 模式, 所有未知流量泛洪到所有端口
|
||
V->>SW: 正常通信帧
|
||
SW->>ATK: 泄漏, 帧被泛洪到攻击者端口
|
||
```
|
||
|
||
**防御措施：**
|
||
|
||
| 措施 | 原理 |
|
||
|------|------|
|
||
| **端口安全 (Port Security)** | 限制每个端口学习的最大 MAC 数，超限则触发违规动作（见下表） |
|
||
| **DHCP Snooping** | 构建 IP-MAC 绑定表，过滤非法 DHCP 响应 |
|
||
| **Dynamic ARP Inspection (DAI)** | 基于 DHCP Snooping 表校验 ARP 报文的合法性 |
|
||
| **802.1X 认证** | 端口级准入控制，未认证设备无法通信 |
|
||
|
||
> [!info] 端口安全的三种违规模式
|
||
>
|
||
> | 模式 | 超限行为 | 是否发送 SNMP Trap | 是否递增 Violation 计数 | 端口状态 |
|
||
> |------|---------|-------------------|----------------------|---------|
|
||
> | **Protect** | 静默丢弃违规帧 | ❌ | ❌ | 保持 UP（最容易被忽视） |
|
||
> | **Restrict** | 丢弃违规帧 | ✅ | ✅ | 保持 UP |
|
||
> | **Shutdown**（默认） | 丢弃违规帧 | ✅ | ✅ | **err-disabled**，需手动 `shutdown` / `no shutdown` 恢复 |
|
||
>
|
||
> 生产环境推荐 **Shutdown** 模式——故障暴露最明显，能迫使运维介入排查。如果担心影响可用性，可配合 `errdisable recovery` 自动恢复。
|
||
|
||
> [!question] 思考
|
||
> 为什么 MAC 泛洪攻击能让 Switch 退化成 Hub？因为 CAM 表满后，交换机无法学习新的 MAC-端口 映射关系，对于所有"未知目标"的帧只能泛洪——这恰恰就是 Hub 的行为。**理解 Hub 的工作方式，才能理解这个攻击的本质。**
|
||
|
||
### ARP 欺骗：另一种 L2 攻击
|
||
|
||
MAC 泛洪是让交换机"退化"，而 ARP 欺骗则是"欺骗"——攻击者直接篡改 ARP 映射关系，将流量劫持到自己手中。
|
||
|
||
**ARP 欺骗原理：**
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant ATK as Attacker
|
||
participant GW as Gateway 192.168.1.1
|
||
participant V as Victim 192.168.1.10
|
||
|
||
ATK->>GW: 伪造 ARP Reply: 192.168.1.10 is at MAC_ATK
|
||
GW->>GW: ARP 表被污染, 192.168.1.10 → MAC_ATK
|
||
|
||
ATK->>V: 伪造 ARP Reply: 192.168.1.1 is at MAC_ATK
|
||
V->>V: ARP 表被污染, 网关 → MAC_ATK
|
||
|
||
Note over V,GW: 所有流量经过 Attacker, 实现中间人攻击
|
||
```
|
||
|
||
> [!info] 为什么 ARP 协议如此脆弱？
|
||
> ARP 协议设计之初没有认证机制——**任何设备都可以主动发送 ARP Reply（免费 ARP），接收方不会验证其真实性**。在没有防护的网络中，攻击者可以随意声称"我就是网关"。这也是为什么 ARP 欺骗至今仍是内网渗透中最常用的手法之一。
|
||
|
||
**ARP 欺骗 vs MAC 泛洪对比：**
|
||
|
||
| 维度 | MAC 泛洪 | ARP 欺骗 |
|
||
|------|---------|---------|
|
||
| 攻击目标 | 交换机 CAM 表 | 终端 ARP 缓存 |
|
||
| 攻击效果 | Switch 退化成 Hub（泛洪） | 流量劫持到攻击者（精准定向） |
|
||
| 流量截获 | 被动嗅探泛洪流量 | 主动中间人，可篡改/重放 |
|
||
| 防御措施 | Port Security | **DAI + DHCP Snooping**（核心组合） |
|
||
|
||
> [!tip] DAI + DHCP Snooping 的防御逻辑
|
||
> **DHCP Snooping** 在交换机上建立一张"IP-MAC-端口"可信绑定表（信任表）。**DAI（Dynamic ARP Inspection）** 则拦截所有 ARP 报文，对照这张绑定表校验：如果 ARP 声称的 IP-MAC 映射不在表中，直接丢弃。两道防线配合，几乎可以完全封堵 ARP 欺骗。详见 [[hhs/NETWORK/08-网络安全/01-DDoS与MITM防御]]。
|
||
|
||
### 风暴控制：流量的最后一道闸门
|
||
|
||
MAC 泛洪攻击针对的是 CAM 表容量，而**广播风暴**针对的是带宽——当广播/多播帧因环路或恶意行为失控时，网络瞬间瘫痪。STP 防环是根本方案，但 **Storm Control** 是每个端口上的最后一道保险：
|
||
|
||
| 参数 | 说明 |
|
||
|------|------|
|
||
| **监控对象** | 广播帧、多播帧、未知单播帧（可分别配置） |
|
||
| **阈值方式** | 带宽百分比 / 帧速率（pps） / 绝对速率（bps） |
|
||
| **超限动作** | 阻塞（shutdown）/ 仅丢弃超限帧（drop）/ 发送 SNMP Trap 告警 |
|
||
|
||
```bash
|
||
# Cisco IOS 配置示例
|
||
interface GigabitEthernet0/1
|
||
storm-control broadcast level 20 # 广播流量超过带宽 20% 时触发
|
||
storm-control multicast level pps 1000 # 多播超过 1000 pps 时触发
|
||
storm-control action shutdown # 超限直接 shutdown 端口
|
||
```
|
||
|
||
> [!question] 思考
|
||
> STP 已经防环了，为什么还需要 Storm Control？因为 STP 只防"环路导致的"广播风暴，**无法防护恶意终端主动发送大量广播帧**。两者是不同层级的防护：STP 是拓扑级（防环），Storm Control 是端口级（限速），在生产环境中应同时启用。
|
||
|
||
## Router（路由器）——跨网段互联
|
||
|
||
### 工作原理
|
||
|
||
Router 运行在 OSI 第三层，根据 **IP 路由表**做出转发决策，不同接口属于不同的子网和广播域。
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
subgraph "LAN 1 - 192.168.1.0/24"
|
||
A["PC-A 192.168.1.10"]
|
||
S["Local Switch"]
|
||
end
|
||
|
||
subgraph "Router Gateway"
|
||
R["Router eth0 .1, eth1 .1"]
|
||
end
|
||
|
||
subgraph "LAN 2 - 192.168.2.0/24"
|
||
B["PC-B 192.168.2.10"]
|
||
S2["Local Switch"]
|
||
end
|
||
|
||
A --> S --> R
|
||
R --> S2 --> B
|
||
|
||
style A fill:#DDA0DD,color:#000
|
||
style B fill:#DDA0DD,color:#000
|
||
style R fill:#98FB98,color:#000
|
||
```
|
||
|
||
### Router 转发动作详解
|
||
|
||
当 PC-A（192.168.1.10）要发数据给 PC-B（192.168.2.10）时：
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant A as PC-A
|
||
participant R as Router
|
||
participant B as PC-B
|
||
|
||
Note over A: 判断 192.168.2.10 不在本地子网, 走默认网关
|
||
A->>R: Frame SrcMAC=A, DstMAC=Gateway, IP Src=192.168.1.10, Dst=192.168.2.10
|
||
Note over R: Step1 Strip Ethernet Header, Step2 校验 IP Checksum, Step3 TTL -1, 若 TTL=0 则丢弃并回 ICMP Time Exceeded, Step4 查路由表 via eth1, Step5 ARP 找 B 的 MAC, Step6 Rebuild Ethernet Header
|
||
R->>B: Frame SrcMAC=Gateway, DstMAC=B, IP Src=192.168.1.10, Dst=192.168.2.10
|
||
Note over R: MAC 改了, IP 没变
|
||
```
|
||
|
||
> [!info] TTL 的作用：防止环路中的无限循环
|
||
> 路由器每转发一个包，TTL 减 1。当 TTL 降为 0 时，路由器**丢弃该包并向源 IP 发送 ICMP Time Exceeded 消息**——这就是 `traceroute` 的工作原理。每一跳路由器都会返回一条 ICMP 消息，从而揭示完整路径。
|
||
|
||
### 关键规则：IP 不变，MAC 逐跳改
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A["原始帧 SrcMAC=A, DstMAC=R1-E0, SrcIP=A, DstIP=B"] -->|"通过 Router1"| M1["帧改写 SrcMAC=R1-E1, DstMAC=R2-E0, IP不变"]
|
||
M1 -->|"通过 Router2"| M2["帧改写 SrcMAC=R2-E1, DstMAC=B, IP不变"]
|
||
|
||
style A fill:#DDA0DD,color:#000
|
||
style M2 fill:#98FB98,color:#000
|
||
```
|
||
|
||
> [!question] 思考
|
||
> 为什么要这样设计？因为 **IP 地址是端到端的逻辑标识**（告诉你"最终目的地"），而 **MAC 地址是逐跳的物理标识**（告诉你"下一跳该发给谁"）。就像寄快递：收件人地址（IP）全程不变，但每个中转站的转运标签（MAC）都会换。
|
||
|
||
### Router 的路由功能
|
||
|
||
路由器的核心能力是**路由**——根据路由表决定数据包的去向。路由来源分三种：
|
||
|
||
| 路由类型 | 说明 | 配置方式 |
|
||
|---------|------|---------|
|
||
| **直连路由** | 接口 UP 后自动学习 | 无需配置 |
|
||
| **静态路由** | 管理员手动指定 | `ip route 10.0.0.0/8 192.168.1.1` |
|
||
| **动态路由** | 协议自动交换（OSPF/BGP） | 启动路由协议进程 |
|
||
|
||
```bash
|
||
# Linux 查看路由表
|
||
$ ip route show
|
||
default via 192.168.1.1 dev eth0
|
||
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
|
||
10.0.0.0/8 via 192.168.1.254 dev eth0 # 静态路由
|
||
|
||
# Cisco IOS 查看路由表
|
||
Router# show ip route
|
||
S 10.0.0.0/8 [1/0] via 192.168.1.254 # S = Static
|
||
C 192.168.1.0/24 is directly connected # C = Connected
|
||
```
|
||
|
||
> [!tip] 路由表中的"最长前缀匹配"
|
||
> 当多条路由都匹配目标 IP 时，路由器选择**掩码最长**的那条。例如同时有 `10.0.0.0/8` 和 `10.1.0.0/16`，发往 `10.1.2.3` 的包会走 `/16` 这条——越精确的路由越优先。
|
||
|
||
> [!info] 管理距离（AD）和度量值（Metric）
|
||
> 当同一条路由从不同来源学到时（如 OSPF 和 RIP 都宣告了 `10.0.0.0/16`），路由器用两个维度做选择：
|
||
> 1. **管理距离 AD（Administrative Distance）**：衡量路由来源的可信度。直连 = 0，静态 = 1，OSPF = 110，RIP = 120——**AD 越小越优先**。
|
||
> 2. **度量值 Metric**：同一协议内比较路径优劣。OSPF 看带宽（Cost），RIP 看跳数——**Metric 越小越优先**。
|
||
>
|
||
> 选择顺序：**最长前缀匹配 → AD 最小 → Metric 最小**。这个三步判定是路由选路的核心逻辑，面试和排障都会用到。
|
||
|
||
### Router 的其他关键功能
|
||
|
||
路由转发只是路由器的一部分能力，现代路由器实际上身兼数职：
|
||
|
||
| 功能 | 说明 | 典型场景 |
|
||
|------|------|---------|
|
||
| **NAT** | 将私有 IP 转换为公有 IP | 家庭路由器、企业出口 |
|
||
| **ACL** | 基于五元组的包过滤 | 禁止外部访问内网特定端口 |
|
||
| **QoS** | 流量优先级调度 | VoIP 优先于普通数据 |
|
||
| **DHCP Server** | 自动分配 IP 地址 | 小型网络无需独立 DHCP 服务器 |
|
||
| **VPN** | 加密隧道 | 远程办公接入企业内网 |
|
||
|
||
> [!question] 思考
|
||
> Switch 和 Router 的功能边界正在模糊——**三层交换机**可以做 VLAN 间路由，**路由器**也能做交换。在你的网络架构中，什么场景用纯 L2 Switch、什么场景用 L3 Switch、什么场景用 Router？带着这个问题继续学习后面的 VLAN 和路由章节。
|
||
|
||
### L3 交换机：Switch 与 Router 的融合
|
||
|
||
传统的 L2 Switch 只看 MAC 转发，跨 VLAN 通信必须绕道路由器——这在大型企业网中成为性能瓶颈。**L3 交换机**将路由功能集成到交换机的 ASIC 硬件中，实现"线速路由"：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
subgraph "传统方案 Router-on-a-Stick"
|
||
VA1["Host-A VLAN10"] -->|"所有跨VLAN流量上行"| TR["Trunk 链路"]
|
||
TR --> R["Router 子接口"]
|
||
R -->|"回传下行"| TR2["Trunk 链路"]
|
||
TR2 --> VB1["Host-B VLAN20"]
|
||
end
|
||
|
||
subgraph "L3 交换机方案"
|
||
VA2["Host-A VLAN10"] --> L3["L3 Switch 内部 SVI 路由"]
|
||
L3 --> VB2["Host-B VLAN20"]
|
||
end
|
||
```
|
||
|
||
| 对比 | Router-on-a-Stick | L3 交换机 |
|
||
|------|-------------------|-----------|
|
||
| 转发方式 | CPU 软件路由 | ASIC 硬件路由 |
|
||
| 性能 | 受路由器 CPU 限制 | 线速转发 |
|
||
| 拓扑 | 需要 Trunk 到路由器 | 内部完成，无需外部设备 |
|
||
| 适用场景 | 小型网络 | 中大型企业网核心 |
|
||
|
||
> [!tip] SVI（交换虚拟接口）
|
||
> L3 交换机通过 **SVI** 实现 VLAN 间路由——为每个 VLAN 创建一个虚拟三层接口（如 `interface Vlan10`，配置 IP `192.168.10.1`），充当该 VLAN 的网关。数据包在交换机内部直接完成路由，无需离开设备。
|
||
|
||
> [!info] L3 交换机为什么比路由器快？
|
||
> 关键在于转发路径不同：
|
||
> - **传统路由器**：收到包 → CPU 查路由表 → CPU 执行 ARP → CPU 封装新帧 → 发出。每一步都经过 CPU，性能受主频限制。
|
||
> - **L3 交换机**：预先从路由表构建硬件转发表（**无需等待第一个包触发**），**所有数据包由 ASIC 直接在硬件层面完成查表 + 改写 MAC + 转发**，完全绕过 CPU。这个通用理念称为"**一次路由，多次交换**"。Cisco 的实现叫 **CEF（Cisco Express Forwarding）**，基于 **FIB（Forwarding Information Base）** + **Adjacency Table** 双表架构——FIB 由路由表预计算而来，存储目标前缀 → 下一跳映射；Adjacency Table 存储每一跳对应的 L2 封装头（源/目的 MAC），两者配合实现"查一次表，改两处数据，直接发出"。华为对应叫 **快速转发**，同样基于 FIB 硬件表。核心思路一致：把软件查表的结果预计算到硬件表中，实现线速转发。
|
||
>
|
||
> 打个比方：路由器像一个每次都走审批流程的公司，L3 交换机像一个把常规流程固化成自动化的公司——第一次走流程建模板，之后同类请求直接自动执行。
|
||
|
||
> [!warning] FIB vs LFIB 易混淆
|
||
> **FIB** 用于标准 IP 转发（本节讨论的场景）；**LFIB（Label FIB）** 是 MPLS 标签转发的概念，两者不要混淆。
|
||
|
||
## 三者的协作关系
|
||
|
||
现实网络中，三者通常协同工作：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
PC["终端 PC"] --> H["Hub 旧时代遗留, 冲突域大, 已淘汰"]
|
||
PC --> SW["Switch 局域网核心, MAC 转发表驱动, 全双工"]
|
||
SW --> RT["Router 网关, IP 路由表驱动, 隔离广播域"]
|
||
RT --> ISP["ISP Router 接入 Internet"]
|
||
PC --> WAP["Wireless AP 接入 Switch, AP 本身不转发"]
|
||
|
||
style H fill:#FF6B6B,color:#fff
|
||
style SW fill:#98FB98,color:#000
|
||
style RT fill:#DDA0DD,color:#000
|
||
style ISP fill:#87CEEB,color:#000
|
||
```
|
||
|
||
## 排障速查
|
||
|
||
| 操作 | Switch | Router | Linux 对等命令 |
|
||
|------|--------|--------|---------------|
|
||
| 查看 MAC 表 | `show mac-address-table` | — | `bridge fdb show` |
|
||
| 查看路由表 | — | `show ip route` | `ip route show` |
|
||
| 查看 ARP 表 | `show arp` | `show arp` | `ip neigh show` |
|
||
| 查看接口状态 | `show interfaces status` | `show ip interface brief` | `ip link show` |
|
||
| 端口安全配置 | `switchport port-security maximum 2` | — | 无直接对等命令（可用 `ebtables` / `tc` 限制） |
|
||
|
||
> [!tip] Linux 网络排障组合拳
|
||
> 快速定位 L2/L3 问题的三板斧：
|
||
> ```bash
|
||
> ip link show # L1/L2: 接口是否 UP？速率/双工？
|
||
> ip neigh show # L2: ARP 解析是否正常？MAC 是否正确？
|
||
> ip route get <目标IP> # L3: 走哪条路由？下一跳是谁？
|
||
> ```
|
||
|
||
## 关联笔记
|
||
|
||
- [[hhs/NETWORK/02-链路层/03-MAC地址与广播域]] — Switch 如何管理 MAC 表和广播
|
||
- [[hhs/NETWORK/02-链路层/05-VLAN与Trunk]] — 三层交换机如何实现 VLAN 间路由
|
||
- [[hhs/NETWORK/03-网络层/04-ARP协议完整流程]] — ARP 如何解析 MAC 地址
|
||
- [[hhs/NETWORK/03-网络层/06-静态路由与默认网关]] — Router 的路由表配置
|
||
- [[hhs/NETWORK/03-网络层/08-NAT原理与应用]] — Router 的 NAT 功能详解
|
||
- [[hhs/NETWORK/08-网络安全/01-DDoS与MITM防御]] — MAC 泛洪等 L2 攻击防御
|