深入浅出企业网三层架构：接入、汇聚、核心的职责与实践

先说明一句：这个问题看起来基础，但能把这个概念讲透的人并不多。我刚入行那年参加网工面试，被考官问到“给企业网做设计时你会怎么分层”，我当时背了一堆术语，结果他一句“那你说说汇聚层和核心层到底谁该先挂？”直接把我问懵了。企业网三层网络架构指的是什么，不是背下“接入层、汇聚层、核心层”七个字就完事，而是要搞懂每层解决什么问题、为什么这样分层、以及在实际落地时有哪些坑和变体。这篇文章我就用自己的经验把这件事拆开讲，顺带聊聊用eNSP怎么在模拟器里搭一个能跑流量的三层架构，再看一眼云时代的三层架构变成了什么形态。

1. 三层架构到底拆掉了什么问题：接入、汇聚、核心的分工边界

1.1 一个平面网络会遇到的三个真实困境

很多人刚接触企业网时，觉得“不就是把交换机串联起来，电脑接上去能上网就行”。但如果你真的负责过一两百人的公司网络，会发现这种平面组网方式撑不了多久，问题集中在三处。

第一个是广播域失控。所有终端在同一个二层网络里，ARP请求、DHCP Discover、NetBIOS消息都会在全网广播。设备少的时候无所谓，设备一多，交换机CPU被广播报文耗掉不少，还会出现“某个终端中毒，全网都卡”的连锁反应。打游戏的时候你可能会遇到“有人开迅雷，整个局域网延迟飙升”，在企业网里这就是典型的广播域与带宽争抢问题。

第二个是环路风险。为了保证可靠性，大家自然会加冗余链路，交换机A连着交换机B，B又连着C，C再连回A。从拓扑上看是好事，但二层没有TTL机制，广播帧会在环路里无限循环，最终把整张网打成广播风暴。STP（生成树协议）能防环路，但它会阻塞冗余端口，等于把花大价钱买来的冗余链路闲置在那里，算是一种无奈妥协。

第三个是设备压力不均。平面网络里如果所有终端都接到一台核心交换机上，这台设备的端口密度、MAC表容量、转发能力都要顶满。一旦它宕机，全网瘫痪。更麻烦的是，你没法对不同部门做策略隔离，财务部、研发部、访客Wi-Fi全在一个大二层里，安全边界形同虚设。

1.2 每一层到底应该干什么

网络界对“三层架构”的定义很成熟：接入层（Access）、汇聚层（Distribution）、核心层（Core），各自分工如下。

接入层是“最后一米”，它离终端最近，主要干的是接入控制的事：哪个口属于哪个VLAN，访客能不能上网，摄像头要不要隔离，都是这一层的任务。

汇聚层是策略集中的地方。它把接入层上来的流量聚合起来，终止各业务VLAN的网关地址，然后按策略决定哪些流量能去核心，哪些要在本地处理。VRRP、链路聚合、ACL这些重活都在这一层完成。汇聚层相当于“区域枢纽”，给下层终端提供默认网关，同时把向上转发的流量收敛成有限的几路上行链路。

核心层是整个网络的高速公路，只负责快速转发跨区域流量，连接汇聚层、出口路由器、数据中心和服务器区。核心层讲究“越快越简单越好”，不应该挂满ACL、QoS、VLAN网关这些复杂配置，因为任何一条策略都会消耗CPU，拖慢转发速度。

讲一个我常用的类比：三层架构很像快递物流。接入层是小区门口的快递驿站，收了你家楼下的所有包裹，按片区打上标签；汇聚层是城市分拨中心，按目的地重新装车、合并发运，把东西送到正确的方向；核心层是全国转运枢纽，只管把大批量货物从一个城市高速送到另一个城市。你不可能让每辆快递车都从驿站直发全国，那公路早就堵死了。

2. 为什么要这样分层：流量模型、成本逻辑与三层迷思

2.1 流量收敛：分层背后是带宽和钱的账

很多人没有想过一个问题：为什么不给每一层都用最高端的交换机？答案是成本不允许，也不需要。

网络流量的特点是不均匀的。终端之间通信时，大量业务其实发生在同一楼层的某个范围内，这属于本地流量；只有访问OA服务器、总部业务系统、互联网时，才需要往上走。接入层需要高密度的百兆/千兆电口，但单端口带宽需求并不高，所以用低端盒式交换机即可。汇聚层把几百个终端的流量汇聚起来，再向上转发，就需要更高的转发能力和上行带宽，通常用带万兆上行口的框式或盒式交换机。核心层是所有跨区域流量的必经之路，必须用转发性能最强的设备。

这就是流量收敛比的设计：从接入到汇聚，一般是20:1到50:1之间；从汇聚到核心，收敛比会缩小到10:1甚至更低。适当的收敛比既能保证网络不拥塞，又不会让每一层都堆最高端的硬件，预算上才吃得消。换句话说，三层架构不只是技术方案，更是一套成本控制模型。

2.2 为什么不是一层、二层、四层：分层的度

那是不是所有企业网都必须严格做成三层？不一定。

小办公室十几台电脑，一台二层交换机加一台路由器就够用了，硬套三层架构纯属浪费。中型园区网则经常做简化版三层：接入层照旧，但不再单独设立汇聚层，而是让核心交换机兼任汇聚，VLAN网关、VRRP都做在核心上。这种“核心汇聚合一”的两层架构很常见，我也帮不少几百人的工厂、学校这样规划过，性能足够，还省设备。

反过来，数据中心的网络结构已经发展出了Spine-Leaf（脊叶）架构，它看起来像“两层”，但逻辑上比传统三层更强调横向扩展能力，任何两个Leaf交换机之间的通信都必须经过Spine，增加一台Leaf就等比例增加横向带宽。这种架构适合服务器之间的东西向流量，而传统三层架构的汇聚层一般无法提供同等的横向吞吐。

所以三层架构不是物理世界唯一正确的答案，它是企业网在可靠性、成本、可维护性三者之间寻找平衡的结果。分多少层，取决于你的流量模型、规模、预算和运维水平。

2.3 三层架构不等于三层路由：一个很多人混淆的概念

一个常见的误区是：既然叫“三层架构”，是不是意味着所有设备都必须起三层路由？其实不是。

三层架构的“三层”指的是网络逻辑层次，也就是把网络结构划分为三个功能平面，而不是说核心、汇聚、接入三层里的每个设备都要跑OSPF或BGP。接入层多数情况下只是做二层转发，负责给终端划分VLAN，终结VLAN网关的工作一般放在汇聚层；汇聚层往下是二层域，往上是三层域，它是天然的VLAN边界和路由边界。

另一种常见误解是“VLAN越多，层次就越多”。VLAN本质只是二层广播域的切分工具，你可以建100个VLAN，但网络结构依然是标准的接入-汇聚-核心三层。相反，部分新建园区也会采用“大二层”设计：接入层把所有VLAN用Trunk上送，汇聚层直接终结网关。VLAN的分布位置与网络层次要分开看，不理解这一点，后续做排障时会走很多弯路。

3. 想验证三层架构？用eNSP亲手搭一个能跑流量的案例

3.1 拓扑设计与设备选型

纸上谈兵没有用，我在学习阶段最喜欢用的验证手段就是华为的eNSP模拟器。它能真实模拟交换机、路由器、终端的行为，搭一套最简单的三层企业网拓扑，然后把配置、验证、故障演练全流程跑一遍，比看十篇文章都管用。

我建议的最小拓扑长这样：

• 两台接入交换机 S1、S2，各下挂一个终端网段（比如PC1和PC2）
• 两台汇聚交换机 D1、D2，双上行分别连接 S1 和 S2，形成冗余
• 两台核心交换机 C1、C2，双下行连接 D1 和 D2
• 一台出口路由器 R1，连接核心交换机做NAT上网（可选）

设备类型上用 S5700 系列交换机做接入和汇聚，核心也可以用 S5700，但如果你希望更真实，可以把核心换成 S12700 之类的框式设备型号。eNSP 里不一定有高端型号，功能层面差异不大，主要是端口数量和命名会变。

这套拓扑其实已经是一个缩水版的双星型三层架构：汇聚层和核心层之间全互联，任何单条链路断掉都不影响业务。你要故意拔一根线，就能很直观地看到VRRP和链路收敛在起作用。

3.2 接入层：先把VLAN划分和端口角色搞清楚

接入层的任务很简单：让PC进入正确的VLAN，然后通过Trunk链路把VLAN送到汇聚层。

先建VLAN：

code复制vlan batch 10 20 30

这里假设VLAN 10是办公网，VLAN 20是访客网，VLAN 30是服务器区。接入交换机上接终端的口配成Access：

code复制interface GigabitEthernet0/0/1
 port link-type access
 port default vlan 10

上联汇聚的口配成Trunk，允许携带这些VLAN：

code复制interface GigabitEthernet0/0/24
 port link-type trunk
 port trunk allow-pass vlan 10 20 30

为什么要区分Access和Trunk？Access口进出的数据帧不带VLAN标签，对终端是透明的；Trunk口则允许在同一物理链路上传输不同VLAN的数据，帧内会打上802.1Q标签。简单理解就是Access口管“接口属于哪个VLAN”，Trunk口管“链路上能过哪些VLAN”。

提示：接入层不要配置VLANIF网关地址。终端网关默认在汇聚层，接入层只负责把帧往上送，这样设计的好处是当网关需要迁移或启用VRRP时，不用到每台接入交换机上改配置。

3.3 汇聚层：终结网关、VRRP冗余与链路聚合

汇聚层是三层架构里配置量最大的位置。每个业务VLAN的网关地址都做在汇聚交换机上，为了让网关不成为单点，通常用两台汇聚交换机组VRRP，对外提供一个虚拟网关IP。

先在汇聚交换机D1上为VLAN 10和20配置VLANIF：

code复制interface Vlanif10
 ip address 10.1.10.2 255.255.255.0
 vrrp vrid 10 virtual-ip 10.1.10.254
 vrrp vrid 10 priority 120
interface Vlanif20
 ip address 10.1.20.2 255.255.255.0
 vrrp vrid 20 virtual-ip 10.1.20.254

另一台汇聚D2配置相同的VLAN和虚拟IP，但优先级低一些，作为备份。这样终端的网关IP是10.1.10.254或者10.1.20.254，无论哪台汇聚宕机，终端都不需要重新配置IP。

汇聚层到核心层之间，我建议使用Eth-Trunk链路聚合。比如用两条万兆口捆成一条逻辑链路：

code复制interface Eth-Trunk1
 trunkport GigabitEthernet0/0/23
 trunkport GigabitEthernet0/0/24

链路聚合的好处有两个：一是增加带宽，两条千兆就变两倍，两条万兆变20G；二是增加可靠性，一根线断掉业务不受影响。聚合之后，和核心互访的口也配置成Trunk或者三层口，这取决于你的路由方式。

3.4 核心层与出口：OSPF动态路由和默认路由

核心层此时不一定需要终结VLAN，但它必须承载跨VLAN和跨区域的流量。最常见的做法是核心和汇聚之间跑OSPF，动态学习路由。

在汇聚D1上：

code复制ospf 1 router-id 10.1.255.1
 area 0.0.0.0
  network 10.1.10.0 0.0.0.255
  network 10.1.20.0 0.0.0.255
  network 10.1.255.0 0.0.0.255

核心C1上类似：

code复制ospf 1 router-id 10.1.254.1
 area 0.0.0.0
  network 10.1.255.0 0.0.0.255
  network 10.1.254.0 0.0.0.255

出口路由器再接核心，做默认路由和NAT。这样终端访问跨网段时，汇聚通过OSPF知道下一跳是核心，核心再交给出口路由器去上网。这套链路配通之后，你会发现三层架构的另一个优势：路由可以自动收敛。一条链路断了，OSPF会在几秒内把流量切换到备份路径，比STP快得多。

3.5 验证命令：确认业务和主备切换都正常

配置完之后千万别急着“看起来通了”就完事，我建议把下面几条验证命令过一遍：

• ping 网关IP：确认终端能访问自己的默认网关
• tracert 对端IP：确认路径确实是终端-汇聚-核心-对端汇聚-对端终端
• display vrrp brief：确认VRRP处于Master/Backup状态
• display ospf peer：确认OSPF邻居状态是Full
• display stp brief：确认二层环路已经被阻塞，Trunk口是Forwarding状态

更严谨的做法是做一次“故障演练”：在终端持续ping对端时，手动shutdown掉汇聚交换机上行口，观察丢包数和恢复时间。VRRP和OSPF正常情况下丢包应该在1-3个以内，如果丢包超过几十个甚至超时，说明收敛机制配置有问题，需要回去查细节。

注意：eNSP模拟器的CPU转发性能和真实设备有差距，OSPF收敛速度、冗余切换耗时不能完全等同生产环境，但配置逻辑和排障思路是一致的。真实设备上务必多测试几次，尤其注意VRRP的抢占配置和上联链路监测，这些细节在生产环境里非常容易踩坑。

4. 三层架构的落地坑位：故障场景与排查链路

4.1 网关放在核心还是汇聚：一次“路由绕路”的教训

有段时间我帮客户优化一个分支办公室网络。他们的拓扑是接入层双链路接到两台汇聚，汇聚再双上行到两台核心，核心上接出口。配置看上去完全合规，但用户反映访问OA系统特别慢，ping网关只有1ms，ping核心却要5到10ms，且不稳定。

排查到最后才发现，问题出在所有业务VLAN的网关都被配置在了核心交换机上，汇聚层只做二层透传。这样一来，不同VLAN之间的流量都必须“接入层 -> 汇聚层 -> 核心层 -> 汇聚层 -> 对端接入层”绕一大圈才能到达，本来能在汇聚层本地交换的流量被强行抬到了核心层。核心层不仅要处理高速转发，还要终结大量VLAN接口，CPU和路由表压力上升，延迟自然变大。

这个案例说明：三层架构里，“网关在哪里”决定了流量路径。网关放在汇聚层，流量能就近转发；网关放在核心层，所有跨VLAN流量都要上核心。小规模网络无所谓，规模一上来，就要认真设计“网关下沉到什么位置”。所以现代网络设计里已经出现“网关下沉+本地转发”的思路，本质就是尽量避免流量在架构里无谓地绕路。

4.2 STP的坑：冗余链路没开保护，广播风暴照样打垮全网

另一次排障经历更刺激。客户说整栋楼断网，交换机设备疯狂闪灯。我登录接入交换机执行display interface brief，发现所有端口流量都异常高，CPU占用接近100%。

初步怀疑是环路导致的广播风暴，但拓扑里加了STP，按理说应该会阻塞冗余端口。我执行display stp brief之后发现确实有端口是Blocking状态，但问题出在边缘端口设置上。某台接入交换机连接PC的口被手工配置成了stp edged-port enable，同时把PC网线又插到了另一台交换机上。边缘端口默认不参与生成树计算，一旦收到BPDU应该自动失效，但如果关了BPDU保护，这个端口就会瞬间进入转发状态，环路直接被打开。

这个案例的教训是：堆叠了冗余链路却不做STP保护策略，等于没做冗余。生产环境里必须开启stp bpdu-protection，否则任何一根误插的网线都可能酿成全网广播风暴。

4.3 排查链路方法论：从物理到逻辑，从接入到汇聚

很多新手在排障时习惯拿tracert一通乱打，其实没有章法。我的排查链路基本是固定的，按下面顺序来，效率高很多：

这套方法的关键是“边界思路”：每次排查先定位“流量到底断在哪个边界”，把范围一步步缩小。比如终端能通网关但不通服务器，问题大概率出在汇聚到服务器的路径上；如果网关都不通，问题就在接入或汇聚的VLAN配置上。三层架构最大的好处之一就是每层都有清晰的边界，排障时不容易乱。

5. 云上还有三层架构吗：从阿里云企业网看网络演进

5.1 云企业网到底解决什么问题

聊完传统企业网三层架构，不可避免要面对一个问题：现在很多新公司已经没有机房了，业务直接上云。公有云上的网络形态还会延续三层架构吗？

拿阿里云的云企业网（CEN）来说，它解决的核心痛点是：你开了多个VPC，每个VPC本身是一套独立网络环境，默认是不能直接互通的。比如研发部的应用部署在华东1的VPC，财务系统在华东2的另一个VPC，两者需要互相访问，你总不能给它们各自配公网IP走公网转一手。云企业网就是把多个VPC，以及本地数据中心通过专线连接的边界路由器（VBR），全部拉进一张大的互联网络里，让它们像在同一个内网里一样互通。

CEN底层用的是阿里云的全球骨干网络，自带冗余链路和智能选路能力。创建云企业网实例时，核心动作就是三步：创建一个CEN实例，把需要互通的VPC/VBR加载进去，再通过路由表实现流量调度。不需要你自己搭VRRP、跑OSPF、配BGP，云产品把这些传统网络里“脏活累活”都封装好了。

5.2 云网络里的“三层架构”长什么样

云上的网络看起来没有交换机、没有网线，但逻辑上仍然是分层的。VPC内的子网和云交换机，扮演的是接入层；VPC天然隔离，通过CEN转发路由器互访，这部分相当于汇聚层；CEN背后覆盖多个地域的骨干传输网，本质就是核心层。只是以前用VLAN、STP、VRRP实现的能力，现在都变成了路由表、路由传播、云原生的高可用机制。

我在云上做设计时，一般直接套传统三层架构的思路：先规划好每个VPC内子网和网段（接入），再设计好各VPC之间的互访策略（汇聚），最后统一通过CEN的传输网络来保证跨地域转发质量（核心）。只不过这里的“配置方式”从命令行变成了控制台或OpenAPI。

5.3 传统网络工程师上云，什么该保留、什么该放弃

这一点对做传统网络出身的人特别重要。我见过不少同事把物理网络的很多操作习惯直接搬到云上，结果事倍功半。我的建议是：IP规划、路由设计、安全边界这些逻辑思维完全保留，但下面的具体动作要改。

该保留的：

• 网段规划能力：VPC里子网分多大、网关在哪，依然影响路由表规模和性能
• 路由设计思维：云上路由表、路由传播、路由策略，本质上和你熟悉的动态路由收敛逻辑是相通的
• 安全边界思想：子网隔离、安全组、网络ACL，对应传统网络里的VLAN和ACL

该放弃的：

• 不要在VPC里自己搭VRRP或做链路聚合，云服务器和交换机的高可用由云平台负责，你搭反而可能和平台能力冲突
• 不要把VLAN思维硬套在云上，VPC就是VPC，一个VPC默认隔离，不需要用VLAN再切
• 不要在一台云服务器上搞“多点路由转发”，云上流量转发应该交给云原生的转发路由器（比如CEN的TR）而不是自己搭建路由器

提示：云企业网实例创建之后，默认VPC之间是可以通过转发路由表互通的，但要注意不同地域之间需要配置带宽包或者按流量计费，否则会有额外的费用项。很多人在第一次创建CEN时容易忽略地域带宽费，结果月底账单出来吓一跳。

最后分享一点我的实际操作体会

如果你现在还在学习阶段，我建议按照这个顺序来：先用eNSP把标准三层架构从头到尾配通一遍，然后故意拔线、断口、改VLAN，做几次故障演练，把VRRP切换、OSPF收敛、STP阻塞这些现象亲眼验证一遍。然后再去看公有云的VPC和CEN，你会发现云产品只是把传统网络里复杂的机制抽象成了API和控制台，底层逻辑没有变。

我踩过最深的坑就是当年太早追求“高级方案”，一上来就学BGP、EVPN，结果VLAN和VRRP都没配明白，后来回头看，三层架构作为企业网的地基，花多少时间打基础都不为过。真到生产环境，你会发现故障率最高的往往不是最复杂的部分，而是最基础的链路、VLAN、网关这些小细节。把基础做实，再谈优化和创新，这条路最稳。