集线器、交换机、路由器这三样东西几乎每一本网络入门的资料里都要讲一遍但真把它们摆在同一张拓扑图上能把“为什么这里放交换机、那里放路由器、那个角落为什么还给留了一台老集线器”讲清楚的人并不多。我见过不少刚入行的朋友配置命令敲得飞快一到排障就卡壳根子往往不在命令行而在于脑子里没有一张清晰的“设备能力地图”——不知道某个设备看得懂什么、看不懂什么、会把流量怎么处理。这篇内容就围绕集线器、交换机、路由器的工作原理区别展开把三层设备的分层定位、转发逻辑、冲突域与广播域、地址表与路由表的生成过程、带宽与包转发率的算法以及实际组网和排障中真正会踩的坑一次讲透。无论你是刚接触网络、还在背 OSI 七层模型的新手还是已经能独立配交换机和路由器、但想把底层逻辑补扎实的从业者都能从里面拿到能直接用的东西。1. 先把三个盒子放回分层里差异一眼就出来了1.1 它们比的不是性能高低而是“看得懂什么”很多人下意识地把这三者理解成一条性能阶梯集线器最差、交换机中等、路由器最强。这个理解是错的而且错得会误导后面的所有判断。它们在设计上根本不是同一个维度的东西真正的区别在于工作在哪一层、能识别报文里的哪一部分信息。打个生活化的比方。集线器像一台复读机谁在它耳边说话它就把声音原样放大传给房间里所有其他人它完全不管说话内容是什么、是不是该给某一个人听。交换机像一个楼层前台它手里有一张工位对照表看一眼信封上写的工号MAC 地址就知道该把东西送到哪张桌子不用全楼广播。路由器则像跨城市的物流中转站它不看工号看的是城市和街道IP 地址与网段决定这东西下一站该发往哪个城市。对应到分层模型上集线器工作在物理层处理的是比特流也就是电信号的高低电平它眼里没有“帧”这个概念交换机工作在数据链路层处理的是以太网帧能读懂帧头里的源 MAC 和目的 MAC路由器工作在网络层处理的是 IP 包能读懂源 IP、目的 IP、协议号还负责改 TTL、做地址转换。这个层级的差异直接决定了三件事谁能隔离冲突、谁能隔离广播、谁能连接不同网段。后面所有的性能差异、安全差异、故障现象差异全是这三件事的推论而不是反过来。1.2 冲突域和广播域一把能解释九成现象的钥匙我刚带人的时候发现把这两个概念讲透比讲十遍设备参数都有用。冲突域指的是同一时刻只能有一台设备发送数据的范围——在这个范围里两台设备同时开口信号就会互相叠加、彼此破坏这在以太网里叫冲突Collision。广播域指的是一个广播帧能够到达的范围——广播帧的目的 MAC 是全 F任何收到它的设备都必须处理不管自己是不是目标。这两者的边界恰好就是三种设备的分水岭。我在下面这张表里把关系列清楚建议直接记住这个结构比死记硬背设备参数有用得多设备工作层次每个端口是否独立冲突域是否隔离广播域转发依据集线器物理层否所有端口同属一个冲突域否无比特复制扩散二层交换机数据链路层是每端口一个冲突域否整机默认一个广播域目的 MAC 地址路由器网络层是是每接口一个广播域目的 IP 与路由表要注意一个容易被忽略的细节VLAN 也能切广播域但它属于交换机的功能扩展不是交换机的基本属性。默认配置下的交换机所有端口在同一个广播域里一个广播帧会从除接收口以外的所有端口发出去。很多“网络莫名其妙变慢”的故障根源就是某个环节产生了广播风暴而这个广播风暴之所以能蔓延到整层楼正是因为中间那台交换机没有做广播域隔离。理解了这张表很多现象就不用猜了。为什么集线器接的设备一多就卡因为冲突域没被切开大家抢同一条信道。为什么交换机下某台机器中毒发包整层楼的机器都受影响因为广播域没被切开广播帧和未知单播被泛洪到了所有端口。为什么路由器两边的设备互相“看不见”因为它天然隔离广播ARP 请求根本过不去这是设计意图不是故障。2. 集线器物理层的复读机慢是结构性的2.1 一个比特进来从所有端口出去集线器的内部结构简单到几乎没有“逻辑”可言。它本质上是一个多端口中继器某个端口收到电信号经过整形放大补偿线路衰减、重新生成规整的波形然后复制到除接收端口以外的所有端口上发出去。整个过程不解析帧头不校验地址不做任何缓存也没有队列。信号进来和出去之间的延迟只有硬件转发的那一点时间通常在微秒级以内。这个设计带来两个直接后果。第一是共享介质物理上虽然是一堆网线接在同一个盒子上但逻辑上等同于所有人接在同一根同轴电缆上任何时刻只能有一个人说话否则就撞车。第二是半双工接在集线器上的设备不能同时收发因为一旦同时发收发线对上都会有信号自己的发送会和自己收到的别人信号叠在一起直接冲突。这也是早期以太网设备必须靠 CSMA/CD 协议来协调的根本原因。顺带说一个实践中的认知点集线器不是“不检查错误”而是它检查不了。它转发的比特流里如果帧校验序列FCS是错的它照样原封不动地扩散出去坏帧会占用所有端口的带宽。交换机则不同收到坏帧直接丢弃不会浪费其他端口的带宽。这个差异在高负载时非常明显。2.2 CSMA/CD那套被遗忘的抢麦规则既然所有设备共享同一条信道就必须有一套规则来决定谁先说。这套规则就是带冲突检测的载波侦听多路访问CSMA/CD它的流程可以拆成四步我用开会抢话的场景类比一下会更直观。第一步先听后说载波侦听发言前先听一下频道上有没有人在讲如果信道忙就等一直等到静默。第二步边听边说冲突检测开始发言后仍然要保持监听因为可能刚好有两个人同时判断信道空闲、同时开口。第三步撞了就停一旦检测到冲突立刻停止发送转而发送一个 32 位的干扰序列Jam 信号目的是把冲突信号加强、拉长确保网络上所有设备都能可靠地感知到这次冲突而不是有的人感知到了、有的人没感知到。第四步随机退避停止发送后各自等待一段随机时间再重试。退避时间的算法是二进制指数退避公式是退避时间 随机整数 × 时隙时间其中随机整数的取值范围随重试次数翻倍第一次冲突取 0 或 1第二次取 0 到 3第三次取 0 到 7依次翻倍重试到第 10 次以后范围固定在 0 到 1023累计重试 16 次仍失败则向上层报错、丢弃这一帧。这个“范围翻倍”的设计很有意思它让冲突的双方在下一轮里被拉开距离的概率越来越大同时它也是自适应的——网络越拥塞退避窗口越大主动降低抢信道的激烈程度。代价是重试次数多了以后等待时间明显变长表现出来就是你感觉“网络有时候会莫名其妙顿一下”。2.3 一台集线器能带多少台机器算一遍就清楚了厂商宣传的“10M 集线器”说的是整台设备共享 10Mbps不是每个端口 10Mbps。这一句话就能解释绝大多数疑问。假设 10 台终端接一台 10Mbps 集线器理论上平均每台分到 1Mbps但这只是理想值实际还要扣掉冲突带来的时间损失——每次冲突至少要浪费一个时隙加上退避等待冲突越多有效吞吐越低。业界的经验是共享式以太网在负载达到 30% 到 40% 时冲突开销就开始明显侵蚀吞吐实际叠加下来10 台机器的体验远不如理论上的平均 1Mbps。再往深一层冲突还和线缆长度强相关因为 CSMA/CD 要求发送方在帧发完之前就能检测到冲突所以“冲突窗口”必须大于信号走完整个网络最远往返路程的时间。在 10Mbps 以太网里一个时隙定义为 512 比特时间也就是 51.2 微秒这约束了整个网络的直径。以太网早期有个著名的“5-4-3 规则”最多 5 个网段、最多 4 个中继器集线器、其中最多 3 个网段可以接设备。这不是厂商拍脑袋定的而是传播时延算出来的物理上限。所以问“集线器能带几台机器”标准答案不是某个数字而是能带几台取决于业务流量模型和布线长度但无论怎么算它都是一个共享带宽设备加一台机器就摊薄一次。我一般给的建议是如果非要用尽量控制在 5 台以内、只跑小流量业务并且注意不要级联太多层。2.4 今天还在用集线器的场景以及必须避开的坑坦白说纯集线器在新组网里基本没有位置了。但在一些特殊场景里它仍然会被翻出来老旧设备的兼容验证、某些需要“所有端口收到同样流量”的调试环境、以及某些对成本极度敏感的临时链路。这里有一条必须提醒的经验想监听流量别顺手拿集线器接进现网。很多人听说了“集线器会把流量扩散到所有端口”就想当然地拿它串在链路中间做抓包。问题是一个 10Mbps 半双工的集线器串进一条千兆全双工链路不仅把带宽砍到原来的百分之一还把双工模式从全双工降成半双工同时因为共享冲突原本正常的业务会被拖慢甚至丢包。想抓包正规做法是交换机端口镜像或者专用的分光/串接设备不要把生产链路拿去做实验。另外要警惕一个隐蔽问题集线器年代久远很多老设备的电源和端口已经老化接触不良会产生大量 CRC 错误帧而它自己又不会统计和丢弃直接把坏帧扩散出去。现象就是链路“时通时断、速度忽高忽低”用 ping 看延迟忽大忽小但又不完全断。遇到这种第一件事不是查配置而是换掉那台老盒子。3. 交换机切开冲突域的那把刀3.1 一张 MAC 地址表是怎么自己长出来的交换机之所以聪明核心在于它内部维护了一张MAC 地址表有的资料叫转发表、CAM 表记录着“哪个 MAC 地址出现在哪个端口上”。这张表不是手工配的是设备自己学出来的这个过程叫自学习逻辑就三步。第一步学习源地址。任何一帧进入某个端口交换机第一件事就是把帧头里的源 MAC 和这个入端口绑定写进表里并重置这个表项的定时器。含义是“从这个口进来的帧源地址是它说明这台设备在我这个方向”。第二步查目的地址。拿到目的 MAC 后去表里找。第三步决定动作找到对应端口就只从那个端口发出去这叫转发Forward查不到就从除接收口外的所有端口发出去这叫泛洪Flooding如果查到对应端口恰好就是接收口本身直接丢弃这叫过滤Filter因为收发在同一侧的流量没必要再送回去。表项不是永久的有老化时间多数设备的默认值在 300 秒左右。这个设计的好处是设备换端口、换机器时表能自动修正不用人工清理坏处是长时间没有流量的设备记录会被清掉下次通信又得重新泛洪一次。所以你会看到一种现象一条空闲了很久的链路突然有了流量前一两个包会带一点额外的延迟和泛洪之后才恢复正常——这不是故障是表项老化重建的正常过程。这里有个实操细节值得记MAC 表容量是有上限的。低端设备可能只有几百到几千条一旦表满新学到的地址会覆盖不掉或者干脆学不进来表现就是大量流量退化成泛洪整机性能断崖式下跌。这一点在接入设备多、或者遭遇地址泛洪攻击时特别容易暴露排查时直接看表项使用率和泛洪计数就能定位。3.2 四种转发行为四种典型现象把上面的逻辑展开交换机对一帧的处理就是四种结果每一种都对应着你能观察到的现象我整理成表方便对照行为触发条件现象与影响转发目的 MAC 在表里且对应端口不是入端口只占两个端口的带宽其他端口无感过滤目的 MAC 对应的端口就是入端口帧被丢弃通常发生在同口环路或本口自环未知单播泛洪目的 MAC 不在表里除入端口外全网段扩散安全与带宽双重风险广播/组播泛洪目的 MAC 为全 F 或组播地址全体端口扩散是广播风暴的物理基础未知单播泛洪是最容易被忽略的一项。很多人以为“只有广播帧才会扩散”其实不是。任何没学过地址的单播帧都会泛洪包括刚开机、刚换端口、刚过老化时间的设备产生的第一个包。这也解释了为什么在某些监控或者工业控制场景中一个网段里的设备频繁上下线会在交换机上看到持续的泛洪流量。广播帧则更彻底它是不会“学会”的永远泛洪。ARP 请求、DHCP 发现报文这些都属于广播所以一个广播域里的设备越多广播帧带来的总开销越大。这就是为什么大型网络必须切广播域——不是为了好看是为了把广播的波及范围压在某一个 VLAN 或某一个接口下。3.3 全双工和微段化把带宽口径彻底改写了交换机每端口一个冲突域这句话的实际意义是每个端口各自独立互不干扰而且端口可以工作在全双工模式下——发送和接收各走一对线同时进行不需要 CSMA/CD 协调。既然没有冲突了CSMA/CD 在交换机端口上自然就关闭了这一点很多人不知道全双工链路下冲突计数永远是 0如果看到某端口有冲突计数那基本可以断定双工模式配置不匹配一端全双工、一端半双工或自协商失败这是非常典型的故障特征。带宽的计算口径也随之改变。很多采购参数里写的“背板带宽”或“交换容量”算法是端口数量 × 单端口速率 × 2全双工双向。一台 24 口千兆交换机就是 24 × 1Gbps × 2 48Gbps。如果厂商标称值明显低于这个数说明内部存在阻塞满配时可能跑不满线速。另一个更实在的指标是包转发率也叫吞吐率单位是 Mpps每秒百万包。线速转发的算法要基于最小以太网帧帧长 64 字节加上前导码 8 字节和帧间隙 12 字节实际占用 84 字节也就是 672 bit。千兆端口跑满时的包转发率 1,000,000,000 bit/s ÷ 672 bit ≈ 1.488 Mpps。一个千兆端口约 1.488 Mpps24 口就是 35.7 Mpps 左右万兆端口则是 14.88 Mpps。为什么要算这个因为交换机内部的转发引擎是有处理能力的上限的如果标称的包转发率达不到端口数算出来的线速值那么在大量小包比如游戏、语音、DNS 查询冲击下就会开始丢包而大包业务比如文件传输却完全正常。这种“大包没事、小包丢”的现象很多人一开始会怀疑线路其实根源是转发引擎能力不足。我一般在选型时会拿这两个数做交叉验证交换容量对得上、包转发率也对得上才算是真正无阻塞。3.4 VLAN 和生成树交换机真正好用的两条腿单台交换机的自学习逻辑其实不复杂训练有素的人一下午就能摸清。交换机真正的工程价值体现在两个扩展能力上VLAN 和生成树。VLAN的作用是把一台物理交换机切成多台逻辑交换机每个 VLAN 是一个独立广播域。实现上靠 802.1Q 标签在以太网帧头插入 4 个字节其中 12 位是 VLAN ID可用范围 1 到 40940 和 4095 保留。端口分两种角色接终端的叫 Access 口进出都不带标签由交换机负责打标和去标交换机之间互联的叫 Trunk 口允许多个 VLAN 的带标签帧通过。这套机制解决了两个实际问题一是把广播域压小二是让不同部门/不同业务在物理上共用一个布线系统但逻辑上互不相通。有一点必须说清楚VLAN 隔离的是二层广播域不是三层路由。跨 VLAN 通信必须经过三层设备路由器或者三层交换机因为不同 VLAN 的主机 IP 通常在不同网段二层根本处理不了。这也是很多人配完 VLAN 后发现“同 VLAN 能通、跨 VLAN 不通”的原因不是配错了是缺了三层网关。生成树解决的是环路问题。二层网络最怕环路因为以太网帧头里没有 TTL 这种“跳数上限”字段一旦成环广播帧会在环里无限循环、不断复制几秒钟就能把链路带宽占满整网瘫痪这就是广播风暴。生成树的思路是交换机之间交换 BPDU 报文选出一个根桥然后各交换机计算到根桥的最短路径把多余的端口逻辑上阻塞掉物理上保留、逻辑上不通一旦主链路故障被阻塞的端口再自动放开。经典 STP 收敛要 30 到 50 秒RSTP 能压到秒级MSTP 在此之上支持多实例、按 VLAN 负载分担。我在实际项目里吃过一次教训做接入层改造时为了省事把新交换机直接上电接入没检查生成树配置结果两台设备之间的链路被误判BPDU 处理不一致短时间出现了环路告警和端口震荡业务抖了将近一分钟。从那以后我的习惯是任何交换机上线前先确认三件事生成树模式是否统一、边缘端口有没有开、BPDU 保护有没有配。3.5 动手验证看一眼 MAC 表抓一次 ARP理论讲再多不如自己看一眼。验证交换机自学习最简单的方式是三步。先看终端的邻居缓存和接口信息Linux 下ip -br addr ip neigh showWindows 下ipconfig /all arp -a然后在终端 A 上 ping 终端 B再去看交换机的 MAC 地址表不同设备的查看入口不一样通常是“MAC 地址表”或“转发表”相关的查看项有的设备也支持通过网管界面看。你会发现 A 和 B 的 MAC 分别挂在各自的接入端口上并且表项后面带着一个剩余老化时间。再做一次更有意思的验证把终端 B 关机重复 ping同时抓包。你会看到交换机对 B 的 MAC 一开始仍然按表转发等表项老化或 B 关机后无人应答之后流量开始泛洪网络上出现针对 B 的 ARP 请求广播直到底层确认不可达。这个过程把“未知单播泛洪”和“广播泛洪”两个概念同时演示了一遍比看十页文档直观。4. 路由器它管的不是线是网段4.1 路由表长什么样最长前缀匹配怎么算交换机看 MAC路由器看 IP。路由器的核心数据结构是路由表每一条表项至少包含三样信息目的网段/掩码、下一跳地址或出接口、度量值。它的作用就是回答一个问题这个目的 IP我该从哪个口发出去、交给谁。路由表里的条目来源有三种直连路由接口配了 IP 且状态 up自动生成、静态路由手工配置、动态路由跑协议学来的比如 OSPF、BGP 这类。三种来源的可信度用管理距离/优先级来排序直连最优先静态次之动态再次之所以同一目的网段有多条来源时先比优先级优先级相同再比度量值。真正决定转发的是最长前缀匹配规则在所有匹配目的地址的表项里选掩码最长最精确的那条。这条规则的逻辑很朴素——越具体的描述越可信。举个例子假设路由表里有这么几条目的网段/掩码下一跳说明0.0.0.0/0203.0.113.1默认路由兜底192.168.0.0/16192.168.1.1汇总路由192.168.1.0/24直连本地网段192.168.1.128/25192.168.1.254细分网段现在有一个目的地址 192.168.1.200。它同时匹配 /0、/16、/24、/25 四条按最长前缀最精确的是 /25所以走 192.168.1.254。如果目的地址是 192.168.1.100只匹配 /0、/16、/24 三条最长是 /24直连于是路由器直接在本地网段发 ARP 找这台主机。这个匹配是按位比较的不是按数字大小所以要特别注意掩码边界。我见过有人把 192.168.1.128/25 配成了 192.168.1.128/24结果整个 /24 的流量都往错误的方向走排查了半天才发现是掩码少算了一位。4.2 一个包的真实旅程IP 基本不变MAC 逐跳重写这是理解路由器最关键的一环也是考试和面试里最爱问的点。假设主机 A192.168.1.10要访问另一网段的主机 B198.51.100.20中间经过两台路由器。整个过程里源 IP 和目的 IP 全程不变除非中间有 NAT但源 MAC 和目的 MAC 每一跳都在变。具体是这样走的。主机 A 先用目的 IP 和自己的子网掩码做与运算发现 B 不在本网段于是决定把包交给默认网关。它发一个 ARP 请求问“谁是这个网关 IP”拿到网关的 MAC然后组帧源 MAC 是自己的目的 MAC 是网关的。第一台路由器收到后先校验、减 TTL然后查路由表决定下一跳接着用下一跳的 IP 发起 ARP 拿到下一跳的 MAC重新组帧源 MAC 换成自己出接口的 MAC目的 MAC 换成下一跳的 MACIP 头原样保留TTL 已经减 1。如此重复直到最后一台路由器发现目的网段直连直接 ARP 找到主机 B 的 MAC把帧送过去。把这套流程整理成表更清楚环节源 IP目的 IP源 MAC目的 MACTTLA 发出192.168.1.10198.51.100.20A 的 MAC网关1 的 MAC64网关1 转发192.168.1.10198.51.100.20网关1 出接口 MAC网关2 的 MAC63网关2 转发192.168.1.10198.51.100.20网关2 出接口 MACB 的 MAC62TTL 的作用是防止包在网络里无限打转每经过一台路由器减 1减到 0 就丢弃并回一个 ICMP 超时报文。这就是 tracertWindows或 tracerouteLinux能工作的原理——它故意发 TTL 从 1 开始递增的包靠沿途路由器回的超时报文把路径一段段画出来。所以看到 traceroute 某一跳是星号通常是那台设备配置了不回 ICMP而不是链路真的断了。理解了“MAC 逐跳重写、IP 端到端不变”很多现象就顺理成章了为什么改 IP 之后不用改交换机配置因为交换机根本不看 IP。为什么跨网段通信必须先配网关因为没有网关主机不知道第一跳该把帧送给谁的 MAC。为什么同一台主机的 ARP 表里只有网关的 MAC 而没有远端主机的 MAC因为它从来不需要知道远端主机的 MAC。4.3 ARP、默认网关、NAT、DHCP 各自站在哪一环路由器周边有四个配角理解了分工组网时就不容易乱。ARP负责把 IP 翻译成 MAC是二层和三层之间的桥。它在本地广播域内工作跨不过路由器这也是判断“某故障是二层还是三层问题”的分水岭如果 ARP 都学不到问题在二层或物理层如果 ARP 正常但不通问题在三层及以上。默认网关是主机路由表的最后一条兜底规则。主机发现目的地址不在本网段就交给网关。这里有个容易忽略的点主机判断“是否同网段”用的是自己的掩码不是网关的掩码所以网关地址配错掩码边界会导致“以为是同网段、实际不是”现象很怪——本地部分地址通另一部分不通。NAT网络地址转换解决的是私网地址访问外网时的地址映射问题。最常见的形式是端口级复用NAPT/PAT把多个内网地址映射到同一个公网地址的不同端口上靠一张转换表记录对应关系。它顺带带来一个副作用外部无法主动访问内网主机除非手工做端口映射。这也是为什么内网服务要对外提供访问必须在边界设备上配映射规则。DHCP负责自动下发地址四步交互发现客户端广播找服务器、提供服务器回应可用地址、请求客户端广播确认要用哪个、确认服务器最终确认并下发掩码、网关、DNS。这四步里有三步是广播所以 DHCP 服务器和客户端必须在同一广播域或者中间配了中继把广播转成单播送到远端服务器。4.4 动手看路由表怎么读静态路由怎么加看路由表是最基础也最实用的技能。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是直连路由。Windows 下用route print会分成接口列表、IPv4 路由表、持久路由三块重点看“网络目标/网络掩码/网关/接口/跃点数”这几列跃点数越小优先级越高。加一条静态路由Linuxip route add 198.51.100.0/24 via 192.168.1.1 dev eth0Windowsroute add 198.51.100.0 mask 255.255.255.0 192.168.1.1验证路由是否生效用tracert 198.51.100.20Windows或traceroute 198.51.100.20Linux看第一跳是不是你配置的下一跳。这里有个我踩过的坑加了静态路由但没生效查了半天发现是出接口写错了包被送到了错误的接口上而该接口恰好也有到目的网段的路由形成了次优路径现象是“能通但延迟异常高”。所以配静态路由时下一跳和出接口都写明确能避免这类歧义。4.5 路由器为什么“慢”三层交换机又是怎么来的老式的软件路由器转发一个包要走完整流程收包、拆帧、校验、查路由表、减 TTL、重算校验和、可能还要做 ACL 过滤和 NAT 转换、重新组帧、发出去。这套流程走 CPU一个包要几微秒到几十微秒折算下来就是几十万到几百万 pps 的量级跟交换机硬件转发动辄几十上百 Mpps 完全不在一个量级。这就是“路由器慢”印象的来源——它慢在通用处理不在设计缺陷。后来出现了三层交换机思路是“一次路由、多次交换”第一个包走软件流程查路由、建立转发表项后续同一条流的包直接由硬件 ASIC 按缓存表项高速转发。现代的实现已经把这个过程做得更彻底直接用硬件查 FIB转发信息库根本不需要“第一次走软件”。所以今天说“三层交换机比路由器快”这句话是有条件的它快在纯三层转发场景但如果要做复杂的 NAT、策略路由、深度报文检测、加密隧道还是得靠专门的路由设备或者更强的处理平台。选型时别被一个“快”字带偏先看清自己的流量模型。顺带说这也是很多机房核心层用三层交换机做 VLAN 间路由、而边界用路由器做出口的原因内网大流量走硬件转发出口做地址转换和策略各司其职这是长期实践总结出来的分工不是习惯问题。5. 对比与选型别抄结论抄判断方法5.1 关键参数对照一张表看全把前面所有内容压缩成一张对照表方便随时回查对比项集线器二层交换机路由器工作层次物理层数据链路层网络层转发依据无目的 MAC目的 IP冲突域全部端口一个每端口一个每接口一个广播域全部端口一个默认一个VLAN 可切每接口一个双工模式半双工全双工全双工是否隔离广播否默认否是是否连接不同网段否否需三层功能是带宽特性全员共享每端口独享每接口独享典型延迟极低微秒内低相对高常见故障冲突、带宽摊薄、坏帧扩散环路、泛洪、表满、双工不匹配路由错配、NAT 表满、MTU 问题5.2 四类场景四种摆法家庭或小工作室一台无线路由设备基本包办所有角色——它内部其实同时包含了交换模块、路由模块和无线接入模块。这时候你不用纠结三者区别但要知道它内部的交换模块是不隔离广播的所以家里设备一多广播流量会上升但通常不影响使用。小型办公网接入层用二层交换机负责端口密度和 VLAN 划分出口用路由器负责地址转换和上网策略。这里的判断标准很简单如果要跨网段通信、要接外网必须有路由器或三层交换机如果只是同网段扩展端口二层交换机足够。机房或中型网络接入层二层交换机做端口接入和 VLAN汇聚层用三层交换机做 VLAN 间路由和策略控制核心/边界用路由器做出口。这里要特别注意生成树的设计和广播域的规划VLAN 数量不是越多越好每个 VLAN 都要占用三层网关资源规划混乱后期维护成本极高。工业、监控、临时链路这类场景关注的是稳定性和实时性往往不需要复杂的路由功能。交换机选型重点看工作温度、供电方式、端口防护和是否有环网冗余协议。这类环境里我曾经因为省事用了商用品夏天机柜温度一上来就开始丢包重启后来换成工业级才稳定这个教训值得记——环境适应性是参数表里最容易被忽略的一栏。5.3 五个流传很广的误解第一“交换机隔离广播”。不对默认不隔离只有配了 VLAN 才隔离而且是靠 VLAN 这个逻辑划分不是靠端口本身。第二“路由器一定比交换机快”。不对纯三层转发场景下三层交换机快得多路由器胜在功能全面和策略灵活。第三“集线器和交换机只是新旧区别”。不对它们是工作机制的根本不同一个共享一个独享集线器接多台设备必然互相拖累这不是性能差不差的问题是结构决定的。第四“有了三层交换机就不需要路由器”。不对出口的地址转换、策略控制、链路备份这些还是路由设备更成熟。三层交换机擅长的是内网高速转发。第五“MAC 地址表配好就不用管了”。不对它是自学习的会老化、会溢出、会被攻击污染。实际维护中要关注表项数量、泛洪计数和老化行为尤其是设备频繁上下线的场景。6. 排查实录现象倒推层级比盲猜快十倍6.1 常见问题速查表排障最忌讳一上来就改配置。我的习惯是先看现象用现象反推层级再动手验证。下面这张表是我这些年攒下来的高频对照现象最可能的原因优先验证动作一台上网全组变慢集线器共享带宽或广播风暴看冲突计数、广播包速率时通时断、延迟忽大忽小物理层问题线缆、接触、双工不匹配看端口 CRC 错误、双工状态同网段能通跨网段不通缺网关或路由缺失查主机网关、查路由表同 VLAN 通跨 VLAN 不通缺三层网关或 VLAN 接口未配查 VLAN 接口状态与地址全部不通且端口灯狂闪二层环路查生成树状态、端口流量大包通、小包丢转发引擎能力不足或 MTU 问题测不同包长的丢包率刚接上的设备头几个包慢MAC 表项老化重建、ARP 学习观察泛洪计数变化某台设备突然全网可见未知单播泛洪或地址欺骗查 MAC 表异常表项6.2 我的排查顺序从下往上逐层排除遇到“网不通”我基本按这个顺序走绝大多数问题能在前三步定位。第一步物理层。看端口灯、看链路状态Linux 用ip -br link确认接口是不是 up、速率和双工协商成了什么。如果看到半双工或者速率不对先解决协商问题别急着往上查。第二步二层。看 ARP 能不能学到对端ip neigh show或arp -a。ARP 学不到说明广播域不通往下查 VLAN、查端口是否在同一个广播域、查有没有端口被生成树阻塞。ARP 能学到但 ping 不通往三层走。第三步三层。查本机路由表、查网关配置、逐跳tracert。这里有个技巧tracert 如果第一跳就不通是本机到网关的问题如果中间某跳开始不通问题在那一段如果能到倒数第二跳、最后一跳不通多半是目的端防火墙或回程路由问题。回程路由这个坑很隐蔽——去程通、回程没路由现象就是“请求发出去了但收不到回应”用抓包在目的端能看到请求进来、却没看到回应出去。第四步应用层与策略。到这一步链路和路由都通了问题往往在端口、ACL、NAT 映射或者服务本身。用ping加端口探测比如 telnet 到目标端口区分是网络不通还是服务没起。6.3 三个我印象最深的坑第一个是双工不匹配。现象是低速时一切正常一上大流量就开始丢包、延迟飙升。原因是链路一端强制全双工、另一端自协商成了半双工半双工那端会把全双工端同时收发的行为当成冲突。查法是看两端的双工状态和冲突计数解决方法是两端统一要么都自协商要么都强制同一种模式。这个坑的迷惑性在于ping 小包完全正常只有压测才暴露。第二个是MAC 表溢出引发的泛洪。某次接入设备较多网络开始出现莫名的延迟和广播量上升查了半天配置都对最后看交换机的表项使用率已经接近上限大量新地址学不进来流量退化成泛洪。解决办法不是加配置是重新规划接入规模、切小广播域。这提醒我选型时表容量这个参数不能只看“够用”要看峰值和余量。第三个是MTU 不一致导致的大包黑洞。现象很典型网页能打开小包文件传一半卡死大包ping 大包直接不通。原因是路径中某一段 MTU 更小而报文带了“禁止分片”标志中间设备既不能转发也不能分片只能丢弃还不一定回错误。验证方法是用不同大小的包逐步试探ping 时指定包长并禁止分片找到那个临界值然后调整 MTU 或者修正 MSS。这类问题在任何跨运营商、跨隧道封装的链路上都可能出现属于必查项。我个人的体会是这三类故障的共同点在于“都发生在设备之间的交界处”——双工是两端配置的交界MAC 表是学习能力与规模的交界MTU 是两段链路参数的交界。所以我现在排查时会优先去看“边界”而不是“中心”很多问题就出在两边没对齐的那一点上。同理选型和设计时凡是要把两种不同设备、不同网段、不同参数接在一起的地方都值得多花十分钟确认参数一致这十分钟往往能省掉后面几小时的排查。