企业官网建设流程全解析

简介：这份PDF资料面向网络工程师、运维人员及备考思科认证的学习者，系统讲解Cisco Catalyst 3560-E系列三层交换机的功能特性与配置方法，帮助读者掌握企业级交换机的部署与运维要点。资源包内含1个PDF文件，大小约591KB，内容涵盖设备概述、软件平台、万兆上行链路与TwinGig SFP转换器、模块化电源、PoE供电、冗余电源等硬件特性，并延伸至高性能IP路由、QoS服务质量、高级安全特性、智能PoE管理及网络管理工具等软件功能。配置部分则从访问设备方式、接口说明与配置、MAC地址表设置、VLAN划分，到路由协议、ACL安全策略、QoS策略及配置备份恢复，形成完整的操作链路。目前已有508人学习，适合希望从理论到实践全面理解3560-E三层交换机的读者参考。

1. 三层交换的真相：为什么 VLAN 间通信不靠路由器也能跑

很多人第一次接触三层交换机时，脑子里都有一个默认前提：不同 VLAN 之间要通信，必须经过路由器，因为路由器才是做三层转发的设备。这个认知在只有二层交换机的环境里完全正确，但一旦换成三层交换机，事情就变了——VLAN 间流量可以在交换机内部直接完成路由，根本不需要外接路由器绕一圈。

这背后的关键，是三层交换机把「路由查找」这件事从软件搬进了硬件。传统路由器用 CPU 逐包查路由表，速度受限于处理器；三层交换机则用 ASIC 芯片维护一张硬件转发表，第一个包走慢路径建立映射，后续同一条流直接走快路径线速转发。这就是「一次路由，多次交换」的由来。

搞懂这个机制，你才能理解为什么 3560 这类设备能同时干二层和三层两件事，也才能看懂后面 VLAN 接口、HSRP、ACL 这些配置到底在操作哪一层。接下来就从硬件架构开始，把这条链路拆开看。

2. 硬件转发架构：ASIC 是怎么把路由塞进芯片的

2.1 交换矩阵与转发引擎的分工

三层交换机内部并不是一个「大 CPU 管所有事」的结构。以 3560 这一代为例，它的数据平面由交换矩阵和转发 ASIC 组成，控制平面才是 CPU 跑 IOS 的地方。交换矩阵负责把包从入端口搬到出端口，转发 ASIC 负责在搬运过程中查表、改包、打标记。

具体到参数，3560G-24TS 的交换矩阵是 32Gbps，包转发率 38.7Mpps；3560-24PS 则是 8.8Gbps 和 6.6Mpps。这两个数字不是随便标的——交换矩阵带宽决定背板能同时承载多少流量，包转发率决定每秒能处理多少个最小帧。两者要匹配，否则会出现「带宽够但包转不过来」的瓶颈。

CPU 在这套架构里的角色被压缩到很小：跑路由协议、维护 ARP 表、处理管理流量、下发转发表项。真正跑数据的是 ASIC。这就是为什么三层交换机在满负载转发时 CPU 占用率可以很低，而路由器做 NAT 或复杂 ACL 时 CPU 容易飙高。

2.2 一次路由多次交换的完整流程

「一次路由，多次交换」这句话经常被提起，但具体怎么走，很多人说不清。拆开看是这样的：

# 假设 VLAN10 主机 10.0.0.1 要访问 VLAN20 主机 20.0.0.1 # 三层交换机上配置了 SVI： interface Vlan10 ip address 10.0.0.254 255.255.255.0 interface Vlan20 ip address 20.0.0.254 255.255.255.0 ip routing

第一个包到达时，ASIC 发现目的 MAC 是自己的 SVI MAC，但目的 IP 不在同网段，于是把包上送 CPU。CPU 查路由表，找到 20.0.0.0/24 出接口是 Vlan20，同时查 ARP 得到 20.0.0.1 的 MAC，然后把「源 10.0.0.1 → 目的 20.0.0.1，出接口 Vlan20，重写目的 MAC」这条映射写进硬件转发表。后续同一条流的包，ASIC 直接命中表项，不再上送 CPU。

这里有个容易忽略的点：硬件转发表是「流级别」的，不是「前缀级别」的。也就是说，它缓存的是具体的源目 IP 对，而不是整条路由前缀。表项有老化时间，长时间不用的流会被清掉，下次再来再走一遍慢路径。这就是为什么有些环境里会出现「间歇性延迟抖动」——流表老化后重新建立，第一个包总是慢的。

2.3 SVI 的本质：VLAN 接口不是物理接口

配置里写的interface Vlan10，很多人把它当成一个「虚拟网卡」来理解，这个类比方向对，但不够准确。SVI 更准确的理解是：它是三层交换机内部的一个逻辑路由接口，绑定到某个 VLAN 的二层广播域上。

当 VLAN10 里的主机发 ARP 请求找网关时，SVI 用自己的 MAC 回应。这个 MAC 来自交换机的背板 MAC 池，每个 SVI 可以共用也可以独立。主机把包发给这个 MAC，交换机收到后知道「这是发给我的三层包」，于是进入路由流程。

SVI 的状态取决于两个条件：VLAN 必须存在，且 VLAN 里至少有一个 up 的物理端口。如果 VLAN 里所有端口都 down 了，SVI 也会 down，路由表里那条直连路由会消失。这个细节在排查「路由突然没了」的时候非常关键——不是路由协议的问题，是 SVI 状态变了。

注意：ip routing这条全局命令必须显式开启，否则三层交换机只做二层转发，SVI 配了也不路由。这是新手最常踩的坑之一。

3. VLAN 与端口配置：从 access 到 trunk 的转发逻辑

3.1 access 端口和 trunk 端口的打标差异

VLAN 配置看起来简单，但端口模式决定了帧在进出时怎么处理标签，这一步搞混，后面全乱。

access 端口的行为是：进方向，收到无标签帧，打上该端口所属 VLAN 的标签；出方向，剥掉标签再发出去。所以接终端的端口配 access，终端完全感知不到 VLAN 的存在。

trunk 端口的行为是：进方向，收到带标签帧，检查标签是否在允许列表里，在就放行；出方向，除了 native VLAN 之外，都带着标签发出去。native VLAN 是个特殊存在——它在 trunk 上收发都不打标签，默认是 VLAN1。

# access 端口配置 interface FastEthernet0/1 switchport mode access switchport access vlan 10 # trunk 端口配置 interface GigabitEthernet0/1 switchport trunk encapsulation dot1q switchport mode trunk switchport trunk allowed vlan 10,20,30 switchport trunk native vlan 99

switchport trunk encapsulation dot1q这行在 3560 上必须写，因为老平台支持 ISL 和 802.1Q 两种封装，不指定会报错。新平台默认只有 dot1q，可以省略。这是版本差异带来的血泪经验——同样的配置在不同 IOS 版本上行为不一样。

3.2 VTP 的同步机制和它的坑

VTP 的设计初衷是让管理员只在一台交换机上建 VLAN，其他交换机自动同步。它靠 revision number 来判断谁的数据新：revision 高的覆盖 revision 低的。

问题就出在这个「高覆盖低」上。如果一台 revision 很高的交换机接入网络，而它的 VLAN 数据库是空的或者错的，它会直接把整个域的 VLAN 配置冲掉。这个翻车场景在真实环境里发生过无数次。

# VTP 配置 vtp domain CORP vtp mode server # 或者 client / transparent vtp password secret vtp version 2

transparent模式不参与同步，只转发 VTP 通告，适合边界设备。client模式不能建 VLAN，只能学。生产环境里我一般建议要么全用 transparent 手动管理，要么严格管控 server 的数量和 revision。VTP pruning 可以剪掉不必要的广播流量，但配置前要确认所有设备的 VTP 版本一致。

3.3 端口隔离和 PVLAN 的实现思路

PVLAN 解决的是一个二层隔离问题：同一个 VLAN 里的主机默认能互相通信，但有些场景（比如托管机房、酒店网络）需要它们互相隔离，同时又能访问网关。

PVLAN 把端口分成三类：isolated 端口只能和 promiscuous 端口通信，community 端口可以和同 community 内的端口通信，promiscuous 端口可以和所有端口通信。上行到网关的端口配 promiscuous，用户端口配 isolated。

vlan 100 private-vlan primary private-vlan association 101 vlan 101 private-vlan isolated interface FastEthernet0/1 switchport mode private-vlan host switchport private-vlan host-association 100 101 interface GigabitEthernet0/1 switchport mode private-vlan promiscuous switchport private-vlan mapping 100 101

底层实现上，PVLAN 是在硬件转发表里加了隔离位，ASIC 查表时根据端口类型决定是否允许转发。这比用 ACL 硬拦效率高得多，因为 ACL 要逐条匹配，PVLAN 是硬件级别的位判断。

4. 路由协议与冗余：HSRP 和 OSPF 在硬件里怎么跑

4.1 HSRP 的虚拟 MAC 和状态切换

HSRP 让两台三层交换机共享一个虚拟 IP 和虚拟 MAC，终端把网关指向虚拟 IP，不用关心哪台是真网关。虚拟 MAC 的格式是0000.0c07.acXX，XX 是组号。

interface Vlan10 ip address 10.0.0.2 255.255.255.0 standby 1 ip 10.0.0.1 standby 1 priority 110 standby 1 preempt standby 1 track FastEthernet0/24 20

priority默认 100，高的当 active。preempt让优先级高的设备在恢复后抢回 active 角色，不配的话它只能等对方主动让位。track监控上行链路，链路 down 时优先级减 20，触发切换。

状态机走的是 Initial → Learn → Listen → Speak → Standby → Active。切换时间默认约 3 秒（hello 3 秒，hold 10 秒），可以调standby 1 timers加快，但调太快容易误切换。

4.2 OSPF 邻居建立和 SPF 计算

OSPF 在 3560 上跑的时候，邻居建立要经过 Down → Init → 2-Way → ExStart → Exchange → Loading → Full 七个状态。卡在 2-Way 通常是 DR/BDR 选举还没完成，卡在 ExStart 多半是 MTU 不匹配。

router ospf 1 router-id 1.1.1.1 network 10.0.0.0 0.0.0.255 area 0 network 20.0.0.0 0.0.0.255 area 0 passive-interface default no passive-interface GigabitEthernet0/1

passive-interface default把所有接口设为被动，再单独放开需要跑 OSPF 的接口，这是防止路由信息从用户端口泄露的标准做法。SPF 算法本身跑在 CPU 上，但算出来的路由下发到硬件转发表，转发还是 ASIC 干。

4.3 路由表和硬件转发表的关系

这里有个关键区分：show ip route看到的是 CPU 维护的软件路由表，show platform ip unicast之类看到的是硬件转发表。两者不一定完全一致。

软件路由表里有的条目，硬件表里可能没有——比如递归路由、某些复杂的策略路由。硬件表容量也有限，3560 这一代最多 11000 条单播路由，超了就要么降级到软件转发，要么丢包。

排查「路由表里有但 ping 不通」的时候，要同时看这两张表。如果软件有硬件没有，说明下发失败，可能是表满或者特性不支持。

5. 安全防护配置：ACL、端口安全和 802.1X 的底层逻辑

5.1 ACL 的匹配顺序和硬件卸载

ACL 是从上往下逐条匹配，匹配到就执行动作，不再往下看。所以顺序很重要，把精确的规则放前面，宽泛的放后面。

ip access-list extended BLOCK_VLAN3 deny ip any 30.0.0.0 0.0.0.255 permit ip any any interface Vlan10 ip access-group BLOCK_VLAN3 in

这个 ACL 实现的是「所有 VLAN 不能访问 VLAN3，但 VLAN3 可以访问其他」。注意方向：在 Vlan10 的 in 方向拦，只影响从 VLAN10 进来的流量，不影响 VLAN3 出去的流量。

ACL 能不能硬件卸载，取决于平台和 ACL 类型。标准 ACL 和扩展 ACL 一般能卸载，带 reflect 或 evaluate 的反射 ACL 可能部分走软件。走软件的那部分会拖慢 CPU，高流量场景下要留意。

5.2 端口安全的 MAC 地址限制

端口安全限制一个端口能学多少个 MAC，超了触发保护动作。

interface FastEthernet0/1 switchport mode access switchport port-security switchport port-security maximum 2 switchport port-security mac-address sticky switchport port-security violation restrict

sticky让学到的 MAC 自动写进 running-config，重启不丢。violation有三种：protect 静默丢弃，restrict 丢弃并告警，shutdown 直接关端口。生产环境用 restrict 比较多，shutdown 太激进，一个误接就断网。

5.3 802.1X 的认证流程

802.1X 是端口级认证，没通过认证的端口只能跑 EAPOL 流量，其他全拦。流程是：终端发 EAPOL-Start，交换机回 EAP-Request/Identity，终端回 Identity，交换机转发给 RADIUS 服务器，服务器和终端完成认证，交换机收到成功消息后开放端口。

aaa new-model aaa authentication dot1x default group radius radius-server host 10.0.0.100 key secret interface FastEthernet0/1 switchport mode access authentication port-control auto dot1x pae authenticator

authentication port-control auto表示端口初始是未授权状态，认证通过才放行。还有force-authorized（永远放行）和force-unauthorized（永远拦）两种模式，调试时用得上。

6. 避坑与排查：那些配置看起来对但就是不通的场景

6.1 SVI 配了但 ping 不通网关

现象：VLAN 建了，SVI 配了 IP，主机网关也指了，但 ping 不通。

原因：最常见的是ip routing没开。其次是 VLAN 里没有 up 的物理端口，SVI 处于 down 状态。还有一种情况是 SVI 的 IP 和主机不在同网段，或者子网掩码写错。

解决：show ip interface brief看 SVI 状态，show running-config | include ip routing确认路由开启，show vlan确认 VLAN 里有活跃端口。

6.2 trunk 两端 native VLAN 不一致

现象：trunk 起来了，大部分 VLAN 能通，但某个 VLAN 不通，或者出现 CDP 告警。

原因：两端 native VLAN 不一致。native VLAN 的帧不打标签，一端认为是 VLAN1，另一端认为是 VLAN99，帧就被丢到错误的广播域里。

解决：show interfaces trunk看两端的 native VLAN，改成一致。建议把 native VLAN 改成一个不用的 VLAN，避免和用户流量混在一起。

6.3 HSRP 双活导致 MAC 表震荡

现象：网络间歇性断，MAC 地址表里同一个 MAC 在两个端口之间跳。

原因：HSRP 配置了 preempt 但优先级没拉开，或者 track 配置不当导致两台设备反复抢 active。也可能是二层环路导致 HSRP hello 包乱窜。

解决：确认优先级差值足够大（建议 10 以上），检查 track 对象是否正确，排查二层环路（show spanning-tree看有没有异常阻塞端口）。

6.4 ACL 配了但没生效

现象：ACL 写好了，应用了，但流量还是能过。

原因：方向搞反了。在 SVI 的 in 方向应用，拦的是进入这个 SVI 的流量；out 方向拦的是从这个 SVI 出去的流量。搞反了就等于没拦。还有一种情况是 ACL 里有一条permit ip any any放在了 deny 前面，把后面的规则全遮住了。

解决：show ip access-lists看匹配计数，确认规则有没有被命中。show ip interface看 ACL 应用的方向。

6.5 端口安全触发后端口 err-disable

现象：端口突然不通，show interfaces status显示 err-disabled。

原因：端口安全 violation 触发了 shutdown，或者 BPDU guard 收到了 BPDU，或者 UDLD 检测到单向链路。

解决：show errdisable recovery看原因，show interfaces status err-disabled看哪些端口被禁。确认原因后shutdown再no shutdown恢复。可以配errdisable recovery cause让特定原因自动恢复，但要知道根因再开，不然会反复触发。

7. 从 3560 看三层交换的设计取舍

3560 这一代设备身上有一个很明显的设计取向：把能塞进硬件的功能尽量塞进去，CPU 只留最必要的控制面工作。路由、ACL、QoS 标记、组播转发，这些在纯路由器上吃 CPU 的活，在 3560 上都由 ASIC 分担。代价是灵活性——硬件表容量有限，特性支持取决于芯片能力，软件升级不一定能带来新功能。

这个取舍在今天的设备上依然成立，只是表更大、芯片更强。理解 3560 的架构，其实是在理解整个三层交换范式的底层逻辑：控制面集中、数据面分布、硬件决定能力边界。

验证一个三层交换环境是否健康，我一般会走这几步：先看show ip route和硬件转发表是否一致，再看 SVI 状态和 VLAN 活跃端口，然后查 HSRP 状态和切换记录，最后看 ACL 和端口安全的命中计数。这套流程走下来，大部分问题都能定位到具体层面。

从那以后我每次配三层交换，都会先把ip routing、SVI 状态、trunk native VLAN 这三项确认一遍再往下做。这三项不出问题，后面的路由和策略才有意义。希望帮到你。

本文还有配套的精品资源，点击获取