--- 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 攻击防御