企业官网建设流程全解析

1. 先把问题摆正：VLAN隔离与三层转发的边界

单臂路由（Router-on-a-Stick）这个词，在思科网络的学习路径里几乎绕不过去：NA阶段要配，面试要问，实际排障时又经常被翻出来背锅。我见过太多人把子接口配完、show ip interface brief全是 up，结果 PC 之间就是 ping 不通，然后开始怀疑人生——怀疑交换机坏了、怀疑线序错了、甚至怀疑模拟器有 bug。绝大多数时候，问题不在"单臂路由"这四个字上，而在于对VLAN 二层隔离边界和三层转发落点的理解是模糊的。只要这两个概念清晰了，单臂路由的配置其实只有六七行命令，剩下的全是验证和排错。

这篇文章面向三类人：刚接触思科设备、准备做 VLAN 间通信实验的入门者；手上有几台旧设备、想用最低成本打通几个网段的运维；以及配过但没配明白、想搞清楚"为什么这么配"的同行。我会从二层隔离的成因讲起，把帧的往返路径一段一段拆开，再给出一套可以直接照抄的完整配置、验证顺序和故障速查表。中间会穿插几个我自己踩过的坑，比如 trunk 封装命令在部分平台上根本敲不进去、native VLAN 不一致导致的诡异现象——这些都是文档里不会写、但现场一定会遇到的东西。

1.1 为什么同一台交换机下的两台机器会"互相看不见"

先建立一个基本认知：VLAN 不是物理隔离，而是广播域的划分。一台交换机创建了 VLAN 10 和 VLAN 20，把端口分别划进去，这两个 VLAN 在二层就是两个独立的世界。VLAN 10 里的主机发出广播帧，交换机只会往 VLAN 10 的成员端口泛洪，VLAN 20 的端口一个字节都收不到。单播也一样，交换机的 MAC 地址表里每个表项都绑定了 VLAN ID，查找时是"VLAN + MAC"的组合匹配，跨 VLAN 的单播帧在二层根本转发不出去。

现在把场景具体化。PC-A 在 VLAN 10，地址 192.168.10.10/24；PC-B 在 VLAN 20，地址 192.168.20.10/24。PC-A 要 ping PC-B，第一步不是发 ICMP，而是判断目标是否同网段。用掩码一算，192.168.20.10 不在 192.168.10.0/24 里，于是 PC-A 决定"这个包得交给网关"。接着它去 ARP 表里找网关的 MAC，没有，就发一个 ARP 请求广播："谁是 192.168.10.1？"这个广播被限制在 VLAN 10 内部。如果网络上压根没有 192.168.10.1 这个地址的三层设备，ARP 就没有任何人应答，PC-A 的操作系统在等待超时后返回"请求超时"或者"无法访问目标主机"。

这里有个特别容易被误判的细节："请求超时"和"目标主机不可达"是两种完全不同的失败。前者通常是 ARP 没回应或者包发出去了没人回，后者往往是本地路由表或者 ICMP 重定向给的明确反馈。排障时先看这个提示，能省掉一半的瞎猜时间。

1.2 单臂路由到底补上了哪一块

既然缺的是"网关"，那最直白的做法就是给每个 VLAN 配一个三层接口。可路由器的物理接口是有限的，一个接口只能配一个 IP、属于一个网段，难道有十个 VLAN 就插十根线、买十块接口卡？成本上不现实，机架上也没那么多位置。

单臂路由的思路是：用一条物理链路，通过 802.1Q 标签承载多个 VLAN 的流量，在路由器上切出多个逻辑子接口，每个子接口对应一个 VLAN 的网关。物理上只有一根网线连着交换机和路由器，逻辑上却有 VLAN 10 的网关、VLAN 20 的网关、甚至管理 VLAN 的网关。因为所有跨 VLAN 流量都要从这根"独臂"进出，形象上就叫单臂路由。

它解决的核心问题是：在不增加物理接口、不引入三层交换机的前提下，为多个 VLAN 提供三层转发能力。注意这里的措辞——它提供的是"转发能力"，不是"高性能转发能力"。这一点直接决定了它的适用边界，后面第 6 节会用量化方式说清楚。

1.3 什么场景适合用，什么场景趁早换方案

我把常见场景整理成了一张表，这张表比任何教科书定义都好用：

判断标准其实就一句话：跨 VLAN 流量是不是网络里的主要流量。如果绝大多数通信发生在 VLAN 内部，只有零星的管理访问需要跨网段，单臂路由非常经济；如果两个网段之间是持续的大流量交互，那这条单链路迟早会被打满，而且路由器基于软件的转发路径在包转发率上远不如三层交换机的硬件转发。

提示：单臂路由不是"过时技术"，而是"特定规模下的合理选择"。把它当成过渡方案或者小场景方案来用，心态就对了；指望它扛核心骨干，那是在给自己埋雷。

2. 单臂路由的工作原理拆解

配置命令只是表象，真正决定你能不能排掉故障的，是对帧在链路上如何变化的理解。这一节把 802.1Q 标签、子接口的收发逻辑、以及一个 ICMP 包的完整旅途讲透。

2.1 子接口与 802.1Q 标签的对应关系

路由器的物理接口本身不认识 VLAN。你在GigabitEthernet0/0下面创建GigabitEthernet0/0.10，这个.10是子接口编号，宿主的还是同一个物理接口。子接口上最关键的一条命令是：

encapsulation dot1Q 10

它的含义是：这个子接口只处理携带 VLAN ID 10 标签的帧；收到帧时把标签剥掉再交给三层处理，发送帧时打上 VLAN ID 10 的标签再交给物理接口。所以子接口的编号.10和 VLAN ID10在技术上没有强制绑定关系，你完全可以写成.100去对应 VLAN 10。但强烈建议保持一致，否则三个月后回来看配置，自己都要愣三秒。

物理接口在这里的角色是"通道"，它不配 IP 地址（配了也不会用于业务转发，反而容易造成混淆），只负责把带标签的帧原样送进送出。真正的网关地址、ARP 响应、路由表项，全部落在子接口上。

这里必须提一个高频疑问：主接口需不需要no shutdown？需要，而且必须要。子接口的状态是跟随物理接口的，物理接口处于 administratively down，子接口就算配了 IP 也起不来。至于子接口本身要不要单独敲no shutdown，在主流 IOS 版本里创建后默认就是 up 状态，敲了也无害——很多教材统一加这一行，是为了避免不同平台、不同版本的差异带来的争议。我的习惯是主接口明确no shutdown，子接口不敲，配置看起来更干净。

2.2 一个 ICMP 包从 VLAN 10 到 VLAN 20 的完整旅途

这段路径值得逐段拆开看，因为每一次故障都发生在这条路径的某一环上。假设 PC-A（VLAN 10，网关 192.168.10.1）ping PC-B（VLAN 20，192.168.20.10），交换机与路由器之间是 trunk 链路，native VLAN 为 99。

第一步，PC-A 判断目标跨网段，查 ARP 表找 192.168.10.1 的 MAC。没有记录，发出 ARP 请求广播。这个以太网帧从 PC-A 的网卡出来时是不带标签的普通帧，因为终端网卡不懂 802.1Q。

第二步，帧到达交换机的接入端口。该端口配置了switchport access vlan 10，交换机会在帧进入时打上 VLAN 10 的标签，然后查 MAC 表。由于是广播，泛洪到所有属于 VLAN 10 的端口，以及所有允许 VLAN 10 通过的 trunk 端口。

第三步，帧从 trunk 口出去，带着 VLAN 10 的 802.1Q 标签，到达路由器的物理接口。物理接口看到标签，根据encapsulation dot1Q 10的映射，把帧交给子接口 G0/0.10。子接口剥掉标签，发现这是一个 ARP 请求且目标 IP 是自己，于是生成 ARP 应答。

第四步，应答帧从子接口发出，重新打上 VLAN 10 标签，经物理接口送回交换机，交换机再剥标签转发给 PC-A。PC-A 学到网关 MAC，把 ICMP 请求封装好发往网关。

第五步，ICMP 请求重复第二到第三步的路径到达子接口 G0/0.10，标签被剥离后进入路由器的三层处理流程。路由器查路由表，发现 192.168.20.0/24 是直连网段，出接口为 G0/0.20。

第六步，包从 G0/0.20 发出，打上 VLAN 20 的标签，送到交换机，交换机根据标签把帧转发到 VLAN 20 的成员端口，PC-B 收到。

回程完全对称。整个过程里，标签的加与剥一共发生了四次（交换机入口加、路由器入口剥、路由器出口加、交换机出口剥），而路由决策只发生在标签被剥掉之后、重新打上之前。理解了这个"剥离—路由—重打"的节奏，你就能明白为什么子接口封装错了 VLAN ID 会导致"网关 ping 得通、跨网段不通"或者干脆网关都 ping 不通。

2.3 抓包时你实际看到的东西

如果能在 trunk 链路上抓包，会看到帧结构比普通以太网帧多出 4 个字节：

12 位的 VLAN ID 字段决定了可用范围是 0–4095，其中 0 和 4095 保留，实际可用 1–4094。这个数字也解释了为什么大型网络要做 VLAN 规划——4094 看起来很多，但按部门、按楼层、按功能一分，很快就紧张了。

还有一个容易忽略的点：native VLAN 的帧不打标签。当帧属于 native VLAN 时，交换机会把标签剥掉再发到 trunk 上，对端收到无标签帧，默认归入自己配置的 native VLAN。这本来是给旧设备兼容用的设计，但也成了网络里最容易出问题的地方——两端 native VLAN 不一致，无标签帧会被归入不同的广播域，轻则管理地址不通，重则形成跨 VLAN 的流量泄露。

注意：把业务 VLAN 配成 native VLAN 是典型的坏习惯。正确做法是单独划一个不承载业务的管理 VLAN 作为 native，业务 VLAN 全部显式打标签。

3. 实验拓扑与地址规划

动手之前先把图纸画清楚。我见过不少人上来就敲命令，敲到一半发现 IP 网段撞了、VLAN ID 和子接口编号对不上，返工比重做还费时间。

3.1 拓扑设计与设备选型思路

实验拓扑保持最简：一台二层交换机、一台路由器、两台终端。交换机的一个端口接路由器，另外两个端口分别接两台终端。交换机和路由器之间跑 trunk，终端接的是 access 口。

为什么用二层交换机而不是三层交换机？因为三层交换机自带 SVI，敲个ip routing就通了，根本用不上单臂路由，会掩盖掉 802.1Q 标签处理这个核心知识点。做实验的目的是把机制看清楚，不是把网络跑通就完事。

路由器这边，理论上任何带千兆以太网接口的型号都行。如果是较老的 ISR 系列，接口速率可能是百兆，做实验够用，但要注意终端网卡的自协商——百兆对千兆有时候会协商成半双工，表现为"能 ping 通但丢包严重"，这个坑在第 5 节会详细说。

终端可以用真实 PC、虚拟机，也可以用模拟器自带的简易主机节点。用真实设备的好处是能看到操作系统层面的 ARP 表和路由表，排错时信息更完整。

3.2 IP 与 VLAN 规划表

规划原则：VLAN ID 和子网第三段数字对齐，网关统一用 .1，方便记忆也方便排错。

终端地址分配：PC-A 用 192.168.10.10/24，网关 192.168.10.1；PC-B 用 192.168.20.10/24，网关 192.168.20.1。终端侧不需要配 DNS，实验阶段用不到。

交换机的管理地址可以配在 VLAN 99 的 SVI 上，方便后续 telnet 或者 SSH 登录查看状态。这一步不是必须的，但对排障很有帮助——你可以在不插 console 线的情况下看show命令的输出。

3.3 端口与线缆清单

线缆全部用直通线。虽然现代设备普遍支持自动翻转，但实验环境里养成用对线缆的习惯没坏处，减少一个变量就少一个怀疑对象。

4. 配置实操全过程

这一节给出可以直接照抄的配置，每一步后面附上"为什么这么敲"的说明。命令基于常见的 IOS 语法，不同平台在细节上会有差异，我会在容易出问题的地方标出来。

4.1 交换机侧：先把二层地基铺好

配置顺序很关键：先建 VLAN，再划端口，最后配 trunk。反过来做也不会报错，但中间会出现端口处于不存在 VLAN 里的短暂异常状态，容易让人误判。

enable configure terminal ! 第一步：创建 VLAN vlan 10 name OFFICE vlan 20 name GUEST vlan 99 name MGMT exit ! 第二步：接入端口划入对应 VLAN interface FastEthernet0/1 switchport mode access switchport access vlan 10 no shutdown interface FastEthernet0/2 switchport mode access switchport access vlan 20 no shutdown ! 第三步：上联口配成 trunk interface GigabitEthernet0/1 switchport trunk encapsulation dot1q switchport mode trunk switchport trunk native vlan 99 switchport trunk allowed vlan 10,20,99 no shutdown exit ! 第四步：管理地址（可选） interface Vlan99 ip address 192.168.99.2 255.255.255.0 no shutdown

逐条解释几个关键点：

switchport trunk encapsulation dot1q这一行，在只支持 802.1Q 的交换机上（比如常见的 2960 系列）是敲不进去的，会提示命令不存在或者封装方式不支持。这不是配置错了，是设备本来就只有一种封装可选，不需要指定。而在同时支持 ISL 和 802.1Q 的平台上（比如 3560、3750 系列），这一行是必须的，因为默认封装可能是 ISL，不指定就会导致 trunk 起不来或者对端不识别。我建议的做法是：先敲，报错就跳过，别在这一行上纠结。

switchport trunk allowed vlan 10,20,99用的是覆盖式写法。如果你在已有 trunk 上追加 VLAN，记得用add关键字，比如switchport trunk allowed vlan add 30。直接覆盖会把之前允许的 VLAN 全部冲掉，这是现场最容易造成"某个 VLAN 突然不通"的原因之一。

switchport trunk native vlan 99必须和路由器侧保持一致。两端不一致时，trunk 会报 native VLAN 不匹配的告警（部分平台会直接打印日志），而且无标签帧会被归到不同的广播域。管理 VLAN 99 的 SVI 地址配在交换机上，方便后续验证。

4.2 路由器侧：子接口与封装

路由器侧的配置更短，但每一行都不能错：

enable configure terminal ! 主接口：只负责 up，不配 IP interface GigabitEthernet0/0 no shutdown exit ! VLAN 10 网关 interface GigabitEthernet0/0.10 encapsulation dot1Q 10 ip address 192.168.10.1 255.255.255.0 exit ! VLAN 20 网关 interface GigabitEthernet0/0.20 encapsulation dot1Q 20 ip address 192.168.20.1 255.255.255.0 exit ! 管理 VLAN 网关（可选） interface GigabitEthernet0/0.99 encapsulation dot1Q 99 ip address 192.168.99.1 255.255.255.0 exit ! 保存 write memory

几个必须说清楚的地方：

encapsulation dot1Q 10里的dot1Q大小写不敏感，写dot1q也行，但首字母大小写混用在部分老版本上会报语法错误，建议统一写dot1Q。数字 10 是 VLAN ID，必须和交换机上创建的 VLAN 完全一致，错一位就是"网关 ping 不通"。

子接口的 IP 地址就是对应 VLAN 内终端的默认网关。掩码用 /24 意味着每个 VLAN 最多 254 个可用地址，实验够用，实际规划时按终端数量留余量。

子接口不需要no shutdown。在 IOS 上，子接口创建后状态跟随物理接口，物理接口 up 了子接口就 up。如果你在某些资料里看到加了这一行，敲了也没关系，属于无害的冗余。

有一点经常被忽略：主接口上不要配 IP 地址。有些教程为了让管理方便会给物理口配一个地址，结果路由表里多出一条直连路由，和某个子接口网段冲突，导致转发行为异常。管理需求用子接口或者单独的管理口解决。

4.3 终端配置与逐层验证的顺序

终端配置很简单：IP、掩码、网关，三项。不要配额外的静态路由，不要开防火墙。Windows 上如果开了"公用网络"配置文件，可能会拦截 ICMP 回显请求，表现为"对面能 ping 通我，我 ping 不通对面"——这属于终端侧问题，排查时先把防火墙临时关掉确认。

验证必须按层来，跳层验证是排障效率的最大杀手。我的固定顺序是：

! 第一层：二层 VLAN 与端口状态 show vlan brief show interfaces status ! 第二层：trunk 状态与允许列表 show interfaces trunk ! 第三层：接口 IP 与状态 show ip interface brief show ip route ! 第四层：实际连通性 ping 192.168.10.10 ping 192.168.20.10 tracert 192.168.20.10

show vlan brief的输出里，要确认 VLAN 10、20、99 都存在，且 Fa0/1 在 VLAN 10 下、Fa0/2 在 VLAN 20 下、Gi0/1 不出现在任何业务 VLAN 的端口列表里（trunk 口不会作为 access 端口显示）。

show interfaces trunk是最关键的一条命令，输出里要看四个值：Mode 是不是on或者trunk，Encapsulation 是不是802.1q，Native vlan 是不是 99，Allowed vlans on trunk 里有没有 10、20、99。任何一项不对，跨 VLAN 通信都会出问题。

show ip route在路由器上执行，应该看到三条直连路由：192.168.10.0/24、192.168.20.0/24、192.168.99.0/24，出接口分别是对应的子接口。如果只看到两条或者看到的是物理接口，说明某个子接口的封装或 IP 配置有问题。

4.4 一次完整的连通性验证记录

配置完成后，从 PC-A 上 ping PC-B。第一次 ping 的前一两个包可能丢失，这是 ARP 解析的正常现象，后面的包应该稳定返回。

在 PC-A 上执行tracert 192.168.20.10，结果应该是只有一跳，即 192.168.10.1。原因很直接：路由器在中间做了三层转发，PC-A 的包到达网关后被重新封装发往 VLAN 20，对 PC-A 来说，路径上只经过了一个三层设备。如果 tracert 显示两跳或者超时，说明路径上有额外的设备或者某一跳没通。

再在路由器上执行show arp，应该能看到 192.168.10.10 和 192.168.20.10 对应的 MAC 表项，分别绑定在 G0/0.10 和 G0/0.20 上。ARP 表里有记录，说明二层已经通了，剩下的问题只可能出在三层策略或者终端侧。

部分平台支持show vlans命令，能直接列出子接口与 VLAN 的映射关系，比逐个show interface看封装效率高得多。如果你的设备支持，排障时优先用它。

5. 常见问题与排查实录

单臂路由的故障现象高度集中，来来回回就那么几种。把这一节的内容记住，现场能省掉大量试错。

5.1 用"四层定位法"快速缩小范围

我习惯把排查拆成物理、二层、三层、策略四层，每层只回答一个问题，答不上来就停在这一层，不要往下猜。

物理层：接口是不是 up？show interfaces看 line protocol 是不是 up，看有没有 CRC 错误、输入输出错误计数在增长。计数增长说明线缆或者双工有问题。

二层：VLAN 和 trunk 对不对？show vlan brief和show interfaces trunk两条命令基本能覆盖。重点看 trunk 的 allowed 列表和 native VLAN。

三层：IP、掩码、网关、路由表对不对？show ip interface brief看地址，show ip route看直连路由，终端上ipconfig /all（Windows）或ip addr（Linux）看网关配置。

策略层：有没有 ACL、防火墙、端口安全在拦？show ip interface看有没有 inbound/outbound 的 ACL 挂载，show access-lists看匹配计数。终端侧关掉防火墙再测一次。

这四层走完，95% 的问题都能定位。剩下 5% 属于玄学范畴，通常是模拟器 bug 或者硬件故障，换设备验证即可。

5.2 典型故障速查表

5.3 几个文档里不会写的坑

坑一：封装命令在部分平台上敲不进去。前面提过，只支持 802.1Q 的设备上这条命令会报错。新手看到红色报错就以为自己配错了，反复重试。判断方法很简单：查设备型号的规格，或者直接看show interfaces trunk里 Encapsulation 显示的是不是 802.1q。是的话，那一行本来就不需要。

坑二：native VLAN 不一致导致的隐蔽故障。两端 native VLAN 不同时，trunk 仍然能起来（部分平台只告警不阻断），业务 VLAN 的流量也可能正常，但管理 VLAN 或者某些无标签流量会跑到错误的广播域里去。表现是"大部分时候正常，偶尔某台设备访问不了"。排查时一定要在两端都执行show interfaces trunk，把 Native vlan 那一列对一遍。

坑三：trunk allowed 列表用覆盖式写法把默认 VLAN 冲掉。有些平台的 trunk 默认允许所有 VLAN，你敲了switchport trunk allowed vlan 10,20之后，VLAN 1 和 native VLAN 就不在允许列表里了。如果管理地址配在 VLAN 1 上，直接失联。习惯写法是add，除非你明确知道要覆盖。

坑四：模拟器上的子接口状态显示异常。部分模拟器对子接口的 up/down 状态处理不准确，show ip interface brief显示 down 但实际能通，或者反过来。遇到这种"状态和实际行为矛盾"的情况，以实际 ping 结果为准，别被状态输出带偏。

坑五：MTU 与 802.1Q 的 4 字节。打了标签的帧比普通帧长 4 字节。默认 MTU 1500 的链路上，理论上超过 1496 字节的负载加标签后会超限，但实际设备通常能处理（因为 MTU 定义的是三层负载，标签属于二层开销）。不过在跨设备、跨厂商的环境里，偶尔会遇到大包不通、小包正常的情况，这时候可以查一下链路的 MTU 配置是否被人为改过。

坑六：保存配置这件事。实验环境里配完直接断电，重启后配置全丢，然后怀疑设备有问题。write memory或者copy running-config startup-config，养成习惯。

提示：生产环境里慎用debug ip packet和debug arp。这类命令会显著增加 CPU 负担，在流量较大的设备上可能直接把转发打瘫。要用的话，先确认流量规模，配好 ACL 过滤只抓特定主机，用完立刻undebug all。

6. 单臂路由与三层交换的取舍

配置会敲了，下一个问题自然是：什么时候该用它，什么时候该上三层交换。这个问题没有标准答案，但有清晰的量化依据。

6.1 带宽瓶颈到底卡在哪里

单臂路由的物理瓶颈是那条上联链路。假设链路是千兆，所有 VLAN 之间的流量都要共享这 1Gbps，而且是双向共享。如果 VLAN 10 和 VLAN 20 之间需要持续 600Mbps 的互访流量，这条链路已经被占用了一大半，再加上其他 VLAN 的流量和管理流量，很快就会拥塞。

更隐蔽的瓶颈在包转发率。三层交换机靠 ASIC 硬件转发，能做到线速；路由器靠 CPU 加 CEF 转发，小包场景下的 PPS（每秒包数）会明显低于硬件转发设备。同样 1Gbps 的链路，跑 1500 字节的大包和跑 64 字节的小包，对 CPU 的压力差了一个数量级。如果你的跨 VLAN 流量里有大量小包（比如某些实时业务），路由器的 CPU 可能先于链路成为瓶颈。

粗略的估算方法是：统计各 VLAN 之间的峰值互访流量，加总后和上联链路带宽比。占比低于 30%，单臂路由完全够用；超过 70%，就该考虑三层交换或者链路聚合了。30% 到 70% 之间属于灰色地带，看预算和未来规划。

6.2 三种方案的对照

三层交换机的 SVI 方案核心配置只有三行：全局ip routing，然后interface vlan 10下面配ip address，VLAN 20 同理。它把网关直接建在交换机内部，跨 VLAN 流量不出设备，性能优势是数量级的。

6.3 我实际会怎么选

小规模分支、只有一台二层交换机、跨网段访问零星发生——单臂路由是最经济的解法，一台旧路由器就能顶上去，配置十分钟搞定，出问题也好排查，因为路径短、设备少。

网络规模中等、VLAN 数量在十个以上、有明确的性能预期——直接上三层交换，别犹豫。省下的那点设备钱，会在后期的扩容和排障里加倍还回去。

还有一种场景值得单独说：需要把访问控制集中在一台设备上。比如访客 VLAN 和办公 VLAN 之间的访问策略非常复杂，需要在同一台设备上做统一的 ACL、日志、审计。这时候单臂路由（或者防火墙的单臂部署）反而有优势，因为所有跨 VLAN 流量都必须经过这个策略点，收口清晰。当然，代价是性能，得接受这个交换。

7. 几个容易被忽略的扩展点

配置跑通只是起点，把下面这几个点补上，方案才算完整。

7.1 在子接口上做访问控制

单臂路由的一个隐性优势是策略集中。所有跨 VLAN 流量都经过路由器，在子接口上挂 ACL 就能精确控制。比如只允许办公网段访问访客网段的特定服务，其他一律拒绝：

access-list 100 permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 access-list 100 deny ip any any log interface GigabitEthernet0/0.10 ip access-group 100 in

方向要理解清楚：in表示从该子接口进入路由器的流量被检查。ACL 里用反掩码（wildcard mask），0 表示必须匹配，255 表示任意。log关键字会在拒绝时产生日志，排障时有用，但生产环境流量大时要慎用，日志量可能很可观。

ACL 生效后，验证方式是show access-lists看匹配计数有没有增长。计数为 0 说明流量压根没到这条 ACL，问题在更前面。

7.2 抑制广播与未知单播

单臂路由把多个 VLAN 的广播域汇聚到一条链路上，虽然每个 VLAN 的广播是隔离的，但链路上的总广播量是各 VLAN 之和。终端数量多的时候，可以做端口层面的风暴控制：

interface FastEthernet0/1 storm-control broadcast level 20 storm-control action shutdown

level 20表示广播流量超过端口带宽的 20% 时触发动作，shutdown是直接关闭端口（激进但有效），也可以选trap只发告警。阈值要按实际情况调，设太低会误伤正常的 ARP 和 DHCP 流量。

另外，路由器子接口默认开启代理 ARP（ip proxy-arp），在跨网段的特定场景下有用，但也可能被利用来做地址欺骗。如果环境里不需要，可以在子接口上关掉。

7.3 单点问题的缓解思路

单臂路由的可用性短板很明确：路由器挂了，所有跨 VLAN 通信中断；上联链路断了，同样全断。缓解手段有限，但可以做一些：

路由器侧用 HSRP 或者 VRRP 做网关冗余，需要两台路由器；交换机侧用链路聚合把多条链路捆成一条逻辑链路，提升带宽和链路冗余；再往上就是直接换三层交换加堆叠，从根本上解决。

不过说实话，如果对可用性有明确要求，说明这个网络的定位已经不是"小型"了，那单臂路由本身就不是正确选型。与其在单臂路由上叠冗余，不如一开始就选对方案。这个判断比任何配置技巧都重要。

最后分享一个我在实验里反复验证过的检查习惯：每次配完单臂路由，先show interfaces trunk确认 trunk 三要素（模式、封装、允许列表），再show ip route确认三条直连路由，最后从两个 VLAN 各挑一台主机互 ping 并 tracert。这三步走完，配置的正确性基本就有底了。真出问题，也知道该往哪个方向查，而不是对着一屏命令发呆。