交换机与路由器差异：二层转发、三层寻路与选型排障

机房搬迁那阵子，我在现场遇到过一幕挺典型的争执：一位同事坚持要把新采购的接入设备换成带路由功能的型号，理由是“路由器比交换机高级，能省一台设备”。结果真上线之后，办公区里两百多台终端的内网互访全挤在一条千兆上联上跑，视频会议卡得厉害，最后只能返工重新布二层架构。这件事让我意识到，交换机与路由器的差异这个话题虽然出现在几乎每一本入门教材的第一章，但真正把“什么时候该用哪个、为什么”讲透的人并不多。多数人记住的是“交换机工作在二层、路由器工作在三层”这句口诀，一旦碰上三层交换机、VLAN 间路由、子接口这些灰色地带，口诀立刻失效。

这篇内容我想做的，是把两者的差异从“概念层”拉到“选型和排障层”。它适合刚入行的网络运维、自己搭办公网的技术负责人、准备面试的应届生，以及那些买设备时被参数表绕晕的采购同学。读完之后你至少能做到三件事：看一台设备的接口和规格就能判断它在你网络里的位置；遇到跨网段不通时知道该在哪一层动手；算得清包转发率和背板带宽这些参数到底够不够用。所有配置示例我会用通用写法表达，具体语法各家设备有差异，思路是通用的。

1. 概念先摆正：二层转发与三层寻路是两套逻辑

1.1 用送快递的类比把两者分开

我特别喜欢用一栋写字楼和同城物流来类比这两类设备。交换机就像写字楼里的收发室大爷：他手里有一张表，记录着“301 室是小张、502 室是小李”，你拿一个写着 301 的包裹给他，他不用问路，直接送到 301 门口。他关心的是“这个房间里住的是谁”，也就是MAC 地址，而且他只知道本楼里的事，楼外的地址他一概不管。

路由器则是同城物流的分拣中心：它不关心“301 室住的是谁”，只关心“朝阳片区往东走、海淀片区往西走”，也就是目标网段。包裹要出楼，必须先交给物流，物流再一站一站往外送，每一站只管“下一跳交给谁”。

这个类比能解释很多实际现象。比如交换机为什么转发快——它一查表就知道往哪个口送，整个过程没有“决策”，只有“匹配”；路由器为什么相对慢——每一跳都要拆开看目的地、查路由表、扣 TTL、重算校验和，这是一串实实在在的计算。再比如为什么交换机端口便宜而路由器端口贵——交换机每个口只需要处理“本楼内的房间号”，而路由器每个口背后都是一张完整的网段路由表、一套访问控制、甚至一套地址转换逻辑。

提示：这个类比有个边界要提醒——三层交换机也能查路由表，它相当于“收发室大爷同时兼任了本片区的物流调度”。后面 2.4 节会专门讲这个模糊地带。

1.2 从帧结构看差异究竟落在哪一层

把类比放下，回到帧结构。以太网帧的头部是 6 字节目的 MAC + 6 字节源 MAC + 2 字节类型，尾部 4 字节 FCS，最小帧 64 字节，加上 8 字节前导码和 12 字节帧间隙，一个最小包在线上实际占用 84 字节，也就是 672 bit。这个数字后面算包转发率时会反复用到。

交换机读的是帧头，看到目的 MAC 就去查自己的 MAC 地址表，命中就单播转发，没命中就泛洪到同 VLAN 的其它端口。整个过程中，IP 头对它来说只是载荷，它连看都不看。这就是为什么交换机可以说“协议无关”——IPv4、IPv6、甚至非 IP 的工业协议，它一律照转不误。

路由器读的是IP 头，看目的 IP，用掩码最长匹配去查路由表，命中之后把 TTL 减 1，重新封装二层的源目 MAC（源变成自己出接口的 MAC，目的变成下一跳的 MAC），再从对应接口发出去。这个“重新封装二层头”的动作是路由器最本质的特征，也是它和交换机最容易区分的标志。

正因为读的东西不一样，两者对“广播”的态度也完全不同。交换机对广播帧的态度是“同 VLAN 内所有人一人一份”，这是它的默认行为，无法关闭；路由器对广播的态度是“到我这为止”，默认不转发任何广播。所以在网络设计里，交换机划的是广播域，路由器划的是广播域的边界。这句话比“二层三层”有用得多，因为它直接告诉你：网络里广播风暴压不住，问题一定出在交换侧；两个网段之间莫名其妙通不了，先去看路由侧。

1.3 “路由器比交换机高级”这个说法错在哪

回到开头那位同事的误区。这句话的问题在于把两种设备放进了同一条进化链，实际上它们是两条平行的产品线，各自往不同方向演进。

交换机往“端口密度、转发时延、成本”方向走。现在一台 48 口千兆接入交换机，转发时延可以做到微秒级，每端口成本摊下来非常低，这是路由器永远做不到的——路由器每增加一个端口，背后都要增加一套路由计算和策略处理能力。

路由器往“策略能力、连接多样性、路径决策”方向走。它要处理的不只是以太网，还有专线、光传输、无线回传等多种链路；它要做的也不只是转发，还有地址转换、访问控制、流量整形、多路径选路。这些东西交换机不是做不了，而是做了就不划算了。

所以正确的问法是“我这段网络需要的是什么能力”，而不是“哪个设备更高级”。一个内部办公网，90% 的流量是内网互访，那核心矛盾是端口密度和转发性能，交换机是主角；一个多分支互联的场景，核心矛盾是路径选择和地址规划，路由器是主角。设备没有高下，场景才有。

2. 底层机制拆解：一次访问到底走了哪些表

2.1 交换机的 MAC 自学习与泛洪

交换机的 MAC 地址表是自学习来的，不是配出来的。过程很朴素：任何一个帧进来，它把源 MAC 和入端口记到表里，老化时间默认通常 300 秒；然后拿目的 MAC 去查表，三种结果——命中且不是入端口，单播转发；命中且就是入端口，丢弃（说明这台设备和对端在同一侧，不需要绕一圈）；没命中，泛洪到同 VLAN 的除入端口外所有端口。

这个机制有几个实操中必须知道的推论。

第一，MAC 表是有容量上限的。接入层设备常见 8K 到 16K 条，一台设备如果下面挂了一堆虚拟机，每个虚拟网卡一个 MAC，表被打满之后就进入“未知单播泛洪”状态，网络看起来能用但性能骤降。我之前遇到过一次虚机批量克隆导致的地址表溢出，现象就是内网时通时不通，ping 丢包 20% 左右，非常迷惑。

第二，MAC 表老化时间要和生成树收敛时间匹配。如果老化太短，拓扑变化后表项频繁失效，泛洪增多；太长，终端换了端口之后旧表项还在，流量会被送到错误的口子上，直到老化。这类问题的典型症状是“换了个网口，要等五分钟才好”。

第三，泛洪是有边界的，边界就是 VLAN。同一个 VLAN 里的广播和未知单播会泛到所有端口，不同 VLAN 之间不会。这是 VLAN 存在的根本意义——不是为了“分组好看”，而是为了把广播域切小。

# 通用思路示意（各家语法不同，看意图即可） # 查看 MAC 地址表及老化时间 show mac address-table show mac address-table aging-time # 查看某端口学到的 MAC 数量，判断是否异常 show mac address-table interface <端口> show mac address-table count

2.2 路由器的逐跳转发与 TTL 递减

路由器的转发过程可以拆成五步：收帧、校验 FCS、剥掉二层头、用目的 IP 查路由表做最长掩码匹配、TTL 减 1 后重新封装二层头发出。只要 TTL 减到 0，设备就丢弃并发回一个 ICMP 超时报文——traceroute 就是靠这个机制工作的。

这里最值得深挖的是最长掩码匹配。假设路由表里有三条：10.0.0.0/8指向 A、10.1.0.0/16指向 B、10.1.2.0/24指向 C。一个目的地址10.1.2.5同时匹配三条，路由器选最长的/24，走 C。这个规则决定了路由设计的灵活性：你可以用一条大网段做默认出口，再用几条明细网段做例外，不用把每条都写全。

实操中容易踩的坑有两个。

一是掩码写错导致的静默失效。比如该写/24写成了/16，配置不报错，但这条路由会覆盖掉一大片本该走别处的流量。排查方法是对比“预期的路由表”和“实际的路由表”，重点看掩码长度。

二是等价多路径的哈希不均。两条等代价路径存在时，路由器按源目 IP 做哈希分流。如果实际流量集中在一两个会话上，就可能出现一条链路跑满、另一条闲着的情况。这时候看接口流量图会误以为是链路故障，其实是哈希极化。

另外提一句地址转换。企业出口做源地址转换时，路由器要维护一张会话表，记录内网地址端口和外网地址端口的映射。这张表有容量上限，也有老化时间。高并发场景下（比如大量短连接的业务），表被打满就会出现新连接建不起来的现象，症状是“网页打不开但 ping 得通”。这个点后面排查章节还会提到。

2.3 完整链路复盘：一台 PC 访问外部服务的全过程

光讲机制太抽象，我们把一次真实访问拆开看。假设终端 IP 是192.168.10.23/24，网关192.168.10.1（路由器接口），要访问203.0.113.8。

第一步，终端判断目的地址不在自己网段内（用掩码一算就知道），于是决定交给网关。第二步，终端查自己的 ARP 缓存，看有没有网关的 MAC，没有就发 ARP 广播“谁是 192.168.10.1”。第三步，这个广播帧进入交换机，因为目的 MAC 是全 F，交换机泛洪到同 VLAN 所有端口，同时也把终端的 MAC 和入端口学到表里。第四步，路由器接口收到广播，回 ARP 应答，交换机这次已经学到路由器的 MAC 了，直接单播回去。第五步，终端封装完整帧：源 MAC 是自己，目的 MAC 是路由器，源 IP 是自己，目的 IP 是远端服务器，发出去。

第六步，交换机收到这帧，查表命中网关 MAC，从上行口转发。第七步，路由器收到，剥二层头，查路由表，TTL 减 1，源 MAC 换成本接口，目的 MAC 换成下一跳的（同样要 ARP），发出去。后面每一跳重复这个过程，直到到达目的地。

这条链路里，交换机只在第三、四、六步出现，路由器在第七步之后接管。这个分工说明了一件事：内网互访的性能瓶颈永远在交换侧，跨网段互访的性能瓶颈永远在路由侧。定位问题时先想清楚这次访问属于哪一类，能省掉一大半弯路。

注意：上面这条链路里有个容易忽略的细节——终端的 ARP 缓存和交换机的 MAC 表是两个独立的东西。ARP 缓存里存的是“IP 到 MAC”，MAC 表里存的是“MAC 到端口”。排查“能 ping 通网关但 ping 不通同网段另一台机器”这类问题时，要分别看这两张表，别混为一谈。

2.4 三层交换机、子接口、VLAN 间路由该怎么定性

这是最容易被口诀误导的区域。三层交换机确实能查路由表，但它和路由器的差异体现在三个地方。

第一是接口模型。路由器的接口是物理的，一个口一个网段，要做多网段就配子接口；三层交换机的“接口”大多是虚拟接口（VLAN 接口），一个 VLAN 一个网关地址，物理口本身不配 IP。所以三层交换机更适合“每个部门一个 VLAN、每个 VLAN 一个网关”的园区场景，路由器更适合“每个方向一条链路、每条链路一个网段”的出口场景。

第二是转发实现。三层交换机第一个包走软件查路由，之后同样的流会写进硬件转发表，后续包直接线速转发；路由器一般全程走转发平面，但转发平面本身也是专门优化的，且有更丰富的队列和策略能力。所以论纯粹的三层吞吐，三层交换机往往更高；论策略灵活性，路由器更强。

第三是功能边界。三层交换机通常不做地址转换、不做复杂的隧道封装、不做深度流量分析，这些是路由器的活儿。你在三层交换机上硬做出口，往往会发现功能缺失或者性能不达标。

至于子接口，它是“一条物理链路承载多个网段”的手段，本质上还是路由器的接口虚拟化。配置时要记得封装 VLAN 标签，并且两端标签要一致——这个一致性检查我建议写进变更单里，我见过不止一次因为一边打了标签一边没打，导致整条链路静默不通的案例。

3. 选型逻辑：什么场景上什么设备

3.1 家庭与小微场景：一台设备全包的合理性

在家庭和十几人的小办公室里，“一台设备搞定”是合理的选择。市面上常见的家用无线设备本质上是“交换模块 + 路由模块 + 无线模块”的集成体，它内部确实同时干着二层转发和三层寻路两件事。这时候讨论“该用交换机还是路由器”意义不大，因为预算和空间都不允许分体。

但有个细节值得提醒：这类集成设备的交换模块通常是“一个上行口 + 若干个下行口”的结构，下行口之间互访不用经过路由模块，性能没问题；但一旦涉及跨网段（比如你划分了访客网络和内部网络），所有流量都要过路由模块，这时候转发能力就成了瓶颈。实测下来，不少家用设备的有线三层转发能力只有几百兆，跑满千兆宽带做跨网段传输时会明显掉速。

小微场景的另一个建议是不要过早引入 VLAN。十几台设备的环境里，划 VLAN 带来的管理成本往往大于收益。等设备数量上了三四十台、或者出现了明确的隔离需求（访客、财务、监控），再考虑划分。

3.2 企业园区：接入、汇聚、核心的三层结构

标准的园区网络是三层结构，每一层的设备定位非常清晰。

接入层全部是二层交换机，只做一件事：把终端接进来，打上正确的 VLAN 标签，通过 Trunk 上联。这一层不需要路由功能，需要的是端口密度、PoE 供电、以及足够稳定的物理连接。

汇聚层是分界线。它往下收接入交换机的 Trunk，往上连核心，同时承担 VLAN 间路由——这是三层交换机最典型的用武之地。一个部门一个 VLAN，网关就设在汇聚的 VLAN 接口上，部门内部的互访不出汇聚，部门之间的互访在汇聚内部完成硬件转发，效率很高。

核心层负责高速互联和出口对接。这一层有的架构用高性能三层交换机，有的用路由器，取决于出口需求的复杂度。如果出口只需要基本的地址转换和几条静态路由，三层交换机足够；如果需要多运营商线路选路、策略路由、流量分析，那就得上路由器。

这个结构的关键在于把广播域切在接入层，把路由决策放在汇聚层，把策略控制放在核心和出口。层次一乱，后面扩容和维护都会非常痛苦。我见过把网关直接配在核心上的架构，一开始省事，等接入规模上去之后，核心的路由表变成几百条，任何一次变更都要小心翼翼。

3.3 关键参数怎么算：别被规格表忽悠

买设备时最容易被忽悠的就是“背板带宽”和“包转发率”这两个数。它们不是越大越好，而是要跟你的实际需求匹配。判断标准只有一个：能不能做到线速。

先算包转发率。以 24 口千兆 + 4 口万兆的接入交换机为例。千兆口线速包转发率是 1.488 Mpps（算法：1 Gbps ÷ (84 字节 × 8 bit) ≈ 1.488 Mpps，84 字节是最小帧 64 加上前导 8 和间隙 12），万兆口是 14.88 Mpps。满配双向计算：

再看背板带宽，同样是双向：24×1 Gbps×2 + 4×10 Gbps×2 = 128 Gbps。这两个数是配套的，如果一台标称 24 口千兆的设备，包转发率只标 30 Mpps，那它肯定做不到全端口线速，属于“端口够但跑不满”的类型。

还有一个常被忽略的参数是缓存。缓存小的设备在突发流量下容易丢包，尤其是“多口进一口出”的收敛场景。接入层建议每端口至少有几百 KB 的可用缓存，汇聚层要更高。这个参数规格表上经常不写，得查详细手册或者实测。

3.4 一张表看清差异与选型

这张表我建议存下来，做方案评审时对着看一遍，能避免大部分“设备放错位置”的问题。

4. 实操落地：从划分 VLAN 到跨网段互通

4.1 拓扑设计与地址规划

我们用一个具体的小场景走一遍完整流程。某办公区有研发、行政两个部门，各 30 台终端，另有 5 台服务器需要被两个部门访问。目标：两个部门二层隔离，都能访问服务器，都能上网。

地址规划如下：

物理连接：一台 24 口二层接入交换机接终端，一台三层交换机做汇聚兼 VLAN 间路由，一台路由器做出口。接入交换机用 Trunk 上联汇聚，汇聚用三层口上联路由器。

这里有个设计取舍值得说明：为什么不让接入交换机直接做三层？因为接入设备通常性能有限、位置分散、维护成本高，把网关放在汇聚能集中管理，也便于后续做统一的访问控制。这是“网关下沉还是上收”的经典权衡，小规模可以下沉图省事，上了规模一定要上收。

4.2 交换机侧：VLAN 划分与 Trunk 配置

接入交换机的配置意图很明确：把端口划进对应 VLAN，把上联口配成 Trunk 并放行需要的 VLAN。

# 通用思路示意 # 1) 创建 VLAN vlan 10 vlan 20 vlan 30 # 2) 终端端口划入对应 VLAN（access 模式） interface <端口1-12> switchport mode access switchport access vlan 10 interface <端口13-20> switchport mode access switchport access vlan 20 interface <端口21-22> switchport mode access switchport access vlan 30 # 3) 上联口配 Trunk，显式放行 VLAN interface <上行端口> switchport mode trunk switchport trunk allowed vlan 10,20,30,100

几个必须注意的点。第一，Trunk 口要显式指定放行列表，不要图省事用“放行全部”。默认放行全部意味着任何误配的 VLAN 都能穿过来，排查时非常难定位。第二，两端 Trunk 的原生 VLAN 要一致，不一致会导致未打标签的帧被划到不同 VLAN，症状是“部分终端能通、部分不通”，极其迷惑。第三，接入端口建议开启边缘端口属性（生成树里的概念），跳过 listening 和 learning 阶段，终端插上就能通，否则每次插拔要等 30 秒。

汇聚交换机这边，除了同样的 VLAN 和 Trunk 配置，还要建 VLAN 接口作为网关：

# 汇聚侧：创建三层接口作为各 VLAN 网关 interface vlan 10 ip address 192.168.10.1 255.255.255.0 interface vlan 20 ip address 192.168.20.1 255.255.255.0 interface vlan 30 ip address 192.168.30.1 255.255.255.0

配到这里，三个 VLAN 之间已经可以互访了，因为三层交换机本地就有直连路由。如果希望研发和行政之间不能互访、但都能访问服务器，就在三层接口上挂访问控制列表，按源网段和目的网段做过滤。这个策略要写在接口的入方向，效率更高。

4.3 路由器侧：出口配置与路由打通

路由器承担两件事：和内网对接、和外部链路对接。

内网侧配置一个三层口，地址在10.0.0.0/30网段内，比如10.0.0.2/30，对端汇聚是10.0.0.1/30。然后在路由器上写回程路由，告诉它内网那三个网段往哪走：

# 回程路由：内网三个网段指向汇聚 ip route 192.168.10.0 255.255.255.0 10.0.0.1 ip route 192.168.20.0 255.255.255.0 10.0.0.1 ip route 192.168.30.0 255.255.255.0 10.0.0.1 # 或者汇总成一条，减少路由表条目 ip route 192.168.0.0 255.255.0.0 10.0.0.1

这里有个取舍：写明细还是写汇总。明细精确、便于逐条控制，但条目多；汇总简洁、路由表小，但如果将来 192.168.40.0 这个网段要走别的出口，汇总就会把它带错方向。我的经验是内网用明细，出口用默认路由，边界清晰。

出口侧配置源地址转换，让内网地址能出去：

# 出口接口做源地址转换（示意） interface <外网口> ip address <公网地址> <掩码> ip nat outside interface <内网口> ip nat inside # 允许内网网段做转换 access-list 10 permit 192.168.0.0 0.0.255.255 ip nat inside source list 10 interface <外网口> overload

最后的overload表示端口复用，也就是多个内网地址共用一个公网地址的不同端口。这是最常见的出口配置方式。要注意的是，转换会维护会话表，会话有老化时间（TCP 通常比 UDP 长），高并发业务要关注设备的会话容量。

汇聚侧还要配一条默认路由指向路由器：ip route 0.0.0.0 0.0.0.0 10.0.0.2。这条写完，整条链路就通了。

4.4 验证：从下往上逐段确认

配置完成之后的验证顺序，我习惯从下往上，一层一层确认，不要跳。

第一步，终端侧确认地址和网关对不对。第二步，在接入交换机上看 MAC 表，确认终端 MAC 学到了、在正确的端口和 VLAN 里。第三步，在汇聚上看 ARP 表，确认能学到终端的 IP 和 MAC 对应关系。第四步，从汇聚 ping 各 VLAN 的终端，确认三层可达。第五步，从汇聚 ping 路由器内网口，确认互联链路通。第六步，从终端 ping 外网地址，确认转换生效。

# 逐段验证的常用查询 show mac address-table vlan 10 # 终端 MAC 是否学到 show arp # IP 与 MAC 映射是否正常 show ip route # 路由表是否有预期条目 show ip interface brief # 接口状态与地址 show interface <端口> # 收发包计数、错误计数

其中show interface的错误计数特别值得看。如果 input errors 或 CRC 计数在涨，说明物理层有问题——网线质量、水晶头压接、光模块衰减，这些是配置解决不了的，必须先排除。

抓包验证也很重要。在汇聚的上联口做镜像，抓一次终端访问服务器的流量，正常情况下应该看到：终端发出的帧目的 MAC 是网关，源 IP 是终端，目的 IP 是服务器；服务器回来的帧目的 MAC 是网关，源 IP 是服务器，目的 IP 是终端。如果看到的帧 MAC 和 IP 对不上，说明网关配错了或者 ARP 表有问题。

5. 排查实录：那些手册上不会写的坑

5.1 分层定位法：先确认在哪一层出问题

我处理网络问题的第一动作永远是画一条最小路径，然后在这条路径上二分。比如“终端访问不了服务器”，先确认终端能不能 ping 通自己的网关——能通，说明二层和终端配置没问题，问题在三层及以上；不能通，问题在接入侧。

如果网关通、服务器不通，就在汇聚上 ping 服务器。通，说明是策略拦截或者回程路由问题；不通，说明服务器所在网段有问题。这个二分过程最多三轮就能把范围缩到一个设备上，比漫无目的地看日志快得多。

有个细节：ping 通不代表业务通。ping 用的是 ICMP，走的是短连接，而业务可能是 TCP 长连接。我遇到过 ping 完全正常、但业务连不上的情况，最后查出来是会话表满导致新 TCP 连接建不起来。所以验证时最好用实际业务端口做测试，比如用 telnet 或 nc 指定端口探测。

5.2 故障速查表

5.3 几条踩出来的经验

关于环路。接入层最常见的严重故障就是环路，症状是广播风暴、CPU 打满、整片区域瘫痪。生成树协议能防，但前提是配置正确且两端一致。我的习惯是：所有接终端的口开边缘端口并启用保护（收到 BPDU 就自动关闭），所有互联口明确指定角色，禁用不必要的协议变种。上线前用一根网线故意制造环路做一次测试，确认保护真的生效——这个动作花五分钟，能省掉一次半夜救火。

关于双工。千兆电口的自协商绝大多数情况下没问题，但在老旧设备或者劣质线缆上会出现“一端百兆全双工、一端百兆半双工”的错配，症状是速度慢且丢包。看到 CRC 计数和 late collision 计数同时增长，基本可以锁定这个问题。处理方式是两端都固定速率和双工，不要一端自协商一端固定。

关于 MTU。内网 MTU 是 1500，一旦涉及隧道封装（比如跨站点的封装链路），有效载荷会减少，需要调整 MSS 或者在终端侧做分片。症状是“小包能通、大包不通、网页卡在加载阶段”。验证方法很简单，用带-l参数的 ping 逐步加大包长，找到分界点就找到 MTU 了。

关于配置备份。这条跟技术无关但极其重要。任何一次变更前导出配置，变更后立刻再导一次做对比。我见过因为一次误操作把汇聚的三层接口地址删掉、导致整个片区断网的事故，最后靠备份在十分钟内恢复。设备上的配置不是你的资产，配置的版本历史才是。

关于设备选型的冗余度。接入层端口数量建议留 20% 以上余量，汇聚层的包转发率建议留 30% 以上余量。这不是浪费，是给未来两年的增长留空间。我见过一个项目按当下终端数精确采购，结果半年后加了一批摄像头和无线 AP，端口不够只能再加一台设备，架构一下变复杂了。

6. 一点个人体会

交换机与路由器的差异，说到底是“匹配”和“决策”两种处理模式的差异。交换机做的是查表匹配，越快越好，越简单越好；路由器做的是路径决策，越灵活越好，策略越丰富越好。理解了这一点，很多模糊问题就清楚了：三层交换机为什么不做地址转换，因为它天生就不是干决策这活的；路由器为什么端口那么少，因为每个端口背后都是一整套决策逻辑。

我自己的习惯是，接手任何一张网络拓扑图，先拿两种颜色的笔把设备标一遍——蓝色标“只做转发的”，红色标“做决策的”。标完之后，广播域在哪断、网关在哪、策略在哪，一目了然。这个方法比看配置命令快得多，尤其是在接手别人维护的网络时。

最后分享一个小技巧：如果你手上只有一台设备，分不清它到底该按交换机用还是按路由器用，就看它的接口能不能直接配 IP。物理口能配 IP 的，按路由器思路规划；只能给 VLAN 接口配 IP 的，按交换机思路规划。这个判断标准简单粗暴，但实测下来没出过错。