企业官网建设流程全解析

1. 从工位到机柜：第三阶段为什么一定要碰管理型交换机

1.1 前两篇笔记和现实之间的落差

这套“网络工程师笔记”写到第三篇，我正好处在从“背命令”到“上手干活”的转折点上。前两篇笔记里，我记录的是 IP 地址规划、掩码计算、静态路由这些桌面上就能完成的功课，键盘一敲，纸上算完，心里就觉得“我好像会了”。真到了项目现场才发现，这种会，离“能处理问题”还差得很远。

原因很简单：办公网的核心不在路由器上，而在交换机上。你面对的是一排排带着几十个端口的二层设备，端口旁边插着工位网线、打印机、无线AP、监控摄像头。用户关心的不是“OSI第七层是啥”，而是“为什么我这边网页打不开”“为什么隔壁部门能上内网我不能”。而这些问题的答案，八九成都要落到交换机的 VLAN 划分和二层链路状态上。

所以第三篇笔记，我把它定位成“交换篇”。它讲的是我从一个只会看接口 up / down 的新人，到能独立完成 VLAN 规划、跨交换机打通业务、处理二层环路的过程。这篇笔记适合正在做网络运维实习、刚接手公司内部网络维护、或者自己折腾企业级交换机的人看。哪怕你手头只有一台旧交换机，这篇文章里的思路也能让你少走不少弯路。

1.2 办公网真正让人头疼的是广播

先说一个我在现场才彻底搞懂的概念：广播域。

刚接触网络基础的人都背过一句话——交换机隔离冲突域，不隔离广播域。背归背，真到了二层设备连了一大片的环境里，你才会意识到这句话有多重。

我第一周跟着前辈去巡检，看到一套办公网的拓扑：核心交换机下挂着十几台接入交换机，接入交换机之间还有级联线，打印机、门禁、无线AP全混在同一个二层里。两百多台终端，彼此都能收到对方的广播帧。当时我抓了一下包，发现整个内网里 ARP 广播和未知单播占了差不多三成流量。平时不觉得，一旦某个网段里有人开了 P2P 下载或者中了蠕虫，整片网络都能被拖慢，而且你根本定位不到源头。

这就是广播域过大的典型症状。终端越多，广播越密，每台设备的 CPU 都要花资源处理跟自己无关的广播报文，最后大家互相拖累。

解决思路也简单：把这一大片二层网络，按业务或部门切成一个个更小的广播域。这就是 VLAN 的核心作用。VLAN 划分之后，广播只会在同一个 VLAN 内部传播，跨 VLAN 的流量必须经过三层设备转发。对办公网来说，这既隔离了广播，也顺带做了部门间的访问控制。我后来在规划表上写下的第一行，就是“财务部单独一个 VLAN，员工区单独一个 VLAN”，这个动作本身，就是初级网络工程师从“只跟着配线”到“开始设计网络”的第一步。

2. 动手配置：VLAN规划、Access端口和Trunk链路

2.1 先有规划表，再有命令行

很多人上手就敲命令，结果 VLAN ID 混乱，过俩月自己都看不懂。我踩过这个坑之后，养成了一个习惯：拿起命令行之前，先在表格里把 VLAN 规划写清楚。

当时我负责一个小型办公网的改造，规模不大，但业务划分明确。规划表长这样：

这张表有几个讲究。VLAN 1 默认存在，管理地址最好不要放在 VLAN 1 里，原因后面排障部分会细说；VLAN ID 用 10、20、30 而不是 2、3、4，是为了后续插入新业务时不用重编；管理 VLAN 单独占一个，把运维流量和业务流量分开。这些都是很小的细节，但规划表做得好，后面配置和排障都能省一半时间。

2.2 接入端口配置与验证

规划表确定之后，才开始碰设备。以某主流交换机的命令行风格为例，接入交换机上创建 VLAN 的步骤是：

vlan 10 name OFFICE exit

把端口划分进对应 VLAN 是这样做的：

interface GigabitEthernet0/1 switchport mode access switchport access vlan 10

这里switchport mode access告诉交换机这个端口是接终端的，不带 VLAN 标签；switchport access vlan 10则把该端口划进 VLAN 10。不理解这两行的人，常会漏掉其中一行，导致端口虽然在 up 状态，但终端拿到的 VLAN 不对。

配置完成之后，我必看三条命令的输出：

show vlan brief show interfaces status show interfaces switchport

show vlan brief能看到每个 VLAN 里有哪些端口；show interfaces status主要看端口有没有亮起来、速率协商是否正常；show interfaces switchport则是确认端口的实际模式是 access 还是 trunk，防止“我以为是 access，结果命令没生效”。这三条命令一共几秒钟就能跑完，但能拦住至少一半的低级错误。

2.3 Trunk干线配置：别让VLAN只活在单台设备上

如果只有一个交换机，VLAN 到这一步就结束了。但办公网一般不止一台交换机，跨交换机的同 VLAN 通信，就需要在交换机之间的级联链路上配 Trunk。

Trunk 的核心作用是让同一条物理链路同时承载多个 VLAN 的流量，通过 802.1Q 标签区分帧属于哪个 VLAN。我习惯把上行口配置成这样：

interface GigabitEthernet0/24 switchport mode trunk switchport trunk allowed vlan 10,20,30,99

注意，allowed vlan这一步不是可选的。如果不写这一行，Trunk 口默认放行所有 VLAN，虽然能通，但安全性和可控性都差。比如访客 WiFi 的 VLAN 本来只想让它局限在接入层，结果因为 Trunk 默认放行，流量顺着链路跑到了核心。限制放行 VLAN，既是习惯，也是对广播域边界的尊重。

配置完之后，用show interfaces trunk查看这条链路是否正常协商成 Trunk，以及放行了哪些 VLAN。这个输出里最需要留意的字段是“Native VLAN”，默认是 VLAN 1。Trunk 两端如果不一致，会产生一种很隐蔽的故障，后面排障部分接着讲。

3. 现场排障最容易翻车的三个点

3.1 接口模式不对称导致链路“假通”

刚接触交换机的初级工程师，第一个排障场景往往不是 VLAN 不通，而是“配置完了，PC 能 ping 通网关，但跨交换机不通”。这类问题排查起来，最容易忽略的就是链路两端的接口模式。

我举个实际场景：交换机 A 的 G0/1 口连交换机 B 的 G0/1 口，A 侧我配成了 trunk，B 侧还是默认的 access。物理链路是 up 的，交换机自己也能互相学到 MAC，但终端上网就是时通时断。原因是 B 侧把 A 发来的带 VLAN 标签的帧当成普通帧处理，标签对不上，直接丢掉。

查这个问题，最快的命令是：

show interfaces switchport

它会清楚显示每个端口的“Administrative Mode”和“Operational Mode”。两边一对比，模式不一致当场就能看出来。记住一个排查原则：链路两端的接口模式、放行 VLAN 列表、Native VLAN，必须完全对齐。这个原则在 Trunk 链路上尤其重要。

3.2 默认VLAN1、管理地址和“丢了网关”的三角关系

再讲一个我自己差点翻车的点。很多设备的默认管理地址放在 VLAN 1，所有端口默认也属于 VLAN 1。正常情况下，你从一台 PC 登录交换机管理地址没有任何问题。

但一旦你把某个接入端口划进 VLAN 10，这台 PC 就和 VLAN 1 隔离开了。此时如果你还想着“管理地址配了就能通”，那就错了——PC 在三层上到达网关之前，二层上先得能和 VLAN 1 的网关通信。

更隐蔽的是，某些交换机的管理 VLAN 被配置成 VLAN 10，但 Trunk 链路没有放行 VLAN 10，管理地址直接失联，你只能跑一趟机房重启或者 console 进去改配置。这种情况在割接现场特别常见。解决办法有三个：一是管理 VLAN 单独用一个 ID，比如 99；二是 Trunk 放行列表里永远包含管理 VLAN；三是给管理地址单独指定一个不被业务影响的三层接口。

我把这条写进笔记里，是因为它不像接口模式不对称那么直白，但一旦中招，你的运维通道就断了，属于“一次失误，进不了设备”的典型。

3.3 只在一半交换机上建了VLAN——黑洞就是这么来的

还有一种故障更隐蔽：交换机 A 上建了 VLAN 10，Trunk 也放行了 VLAN 10；但交换机 B 上根本没有 VLAN 10。结果交换机 A 发出的带 VLAN 10 标签的帧，到了交换机 B 之后，由于 B 上不存在这个 VLAN，帧直接被丢弃。

这类问题的特点是：端口状态正常、链路 up、MAC 表也能看到条目，但业务就是不通。查错的方向如果只停留在链路层，会浪费很多时间。正确做法是登录对端交换机，先看：

show vlan brief

确认对端是否创建了相同的 VLAN。所以我在配置跨交换机的 VLAN 时，会先在所有相关交换机上把 VLAN 建好，再配置 Trunk。顺序反了，就会出现“半边 VLAN”的黑洞。这个名称是我自己给这个现象起的，就是为了提醒自己：VLAN 不是在一台设备上创建完就完事的，它会随着 Trunk 链路延伸到每一台相关的交换机，少一边都不行。

4. 二层环路与生成树STP：冗余设计为什么不会自己爆炸

4.1 一次拔线引发的广播风暴现场

接入交换机之间因为级联线比较多，很容易不小心形成环路。我见过一次典型的广播风暴，起因说出来特别简单：某层楼有两台接入交换机，为了千兆带宽，同事在上面加了一根级联线，和原有的线形成了物理环路。

刚开始没人注意，广播帧顺着环路一圈圈转发，越转越多，MAC 表在设备里来回跳变，CPU 使用率飙升。不到十分钟，整个二层网络的设备都开始丢包，网关 ping 不通。我们当时的第一反应是拔线，拔掉冗余那根之后，网络几十秒内恢复正常。

这件事让我记住了二层环路的威力：它不需要任何恶意程序，光靠 ARP 广播就能把网络打瘫。更麻烦的是，冗余链路本来是为了提高可靠性才加的，结果反而成了事故源。如果只靠拔线解决，那冗余设计就完全失去意义。所以必须有一种机制，让环路存在，但逻辑上只保留一条可用路径，剩下那条作为备份，平时阻塞，主路径断了再顶上。这个机制就是生成树协议 STP。

4.2 STP是怎么把环剪成树的

STP 的原理，说穿了就是在一张物理网状的图里，通过选举机制找出一棵逻辑上的树，然后阻塞掉不在树上的冗余端口。广播帧沿着树走，自然不会兜圈子。

具体过程分为几步。首先是根桥选举，优先级高的交换机成为根桥；然后每台非根交换机选出一个根端口，这个端口是通往根桥开销最小的路径；再然后每条链路上选出一个指定端口，负责向该链路转发数据；剩下的端口进入阻塞状态，不转发普通数据帧，只监听 BPDU。

我初学的时候觉得这些概念太抽象，后来用了个笨办法理解：把根桥想象成整个网络的中心广场，所有数据想从任意一点去另一点，都必须经过广场，路径不能绕圈。多余的路线被封住，但封住的是数据帧，不是管理报文。一旦主动路径断了，备用端口会说上话就上话，把链路重新打开。

4.3 千万别为了省事把STP关掉

网上有些“经验帖”为了消除广播风暴，会教你直接关掉 STP。这是一个极其危险的建议。关了 STP 之后，二层环路不再有保护，任何一根不小心接上的跳线都能立刻引发广播风暴，而且影响范围是整个广播域。

我的建议是：保持 STP 开启，并且根据网络规模选择合适的模式。小型办公网用 RSTP 足矣，收敛时间从 STP 的几十秒缩短到几秒，砍掉环路之后，网络几乎无感知。配置完冗余链路之后，记得用show spanning-tree看一眼端口角色，确认确实有一个端口处于 BLK（阻塞）状态。如果所有端口都是 FWD（转发），说明你的冗余链路并没有生效，环路风险依然存在。

5. 跨VLAN必须面对的新课：网关放在哪一层

5.1 单臂路由：最便宜也最容易理解的方案

VLAN 划分完，隔离的目标达成了，但业务又提出了新需求：财务部偶尔要访问服务器区的共享文件，员工区要访问服务器上的办公系统。跨 VLAN 通信，必须过三层设备。这就引出了初级工程师绕不开的第二个知识点——VLAN间路由。

最朴素的做法是单臂路由。用一台路由器，一个物理接口接到交换机上，然后在路由器上划分子接口，每个子接口对应一个 VLAN，并配上该 VLAN 的网关地址。命令大概长这样：

interface GigabitEthernet0/0.10 encapsulation dot1Q 10 ip address 192.168.10.254 255.255.255.0

每次看到这段配置，我都提醒自己难点在那个encapsulation dot1Q。这句话让子接口能识别 802.1Q 标签，知道进来的帧属于哪个 VLAN。漏了它，子接口就是一个“没有门牌号”的门口，数据帧根本进不来。

单臂路由的优点是成本低、配置直观，缺点是所有跨 VLAN 流量都要挤在一条物理链路上，流量一大就卡。适合业务流量不大的小网络。

5.2 三层交换机和SVI：当网速开始有要求

办公网流量起来之后，单臂路由往往不够用。这时候，三层交换机就该上场了。

三层交换机的做法是创建交换机虚拟接口 SVI，直接在三层交换机上给每个 VLAN 配网关，然后开启路由功能。以同样风格的命令为例：

interface vlan 10 ip address 192.168.10.254 255.255.255.0

VLAN 10、20、30、99 各建一个 SVI，三层交换机用自己的硬件转发跨 VLAN 流量，速度和单臂路由完全不在一个量级。小型网络里，用一台三层交换机作为核心，同时承担网关和路由，是目前最主流的做法。

我吃过亏的地方在于：一开始不知道三层交换机默认不启用 IP 路由功能。SVI 配了地址，但跨 VLAN 数据到了交换机之后找不到路由表，直接丢弃。解决方法是打开路由开关，不同厂商的命令不一样，但思路一致：让三层交换机的 VLAN 接口之间可以互相转发。这也提醒我，排查跨 VLAN 不通时，不要只盯配置，先确认这台设备是不是真的具备并启用了三层转发能力。

5.3 跨VLAN不通时的排查顺序

每次跨 VLAN 出现问题，我习惯按这个顺序查：先确认终端到本 VLAN 网关能不能通，不通，往回查接入链路和 VLAN 划分；能通但跨 VLAN 不通，再看网关设备的路由表和接口状态；路由表没问题，再查设备之间有没有 ACL 拦截。这个顺序是一层层往上走的，从二层到三层到策略，每一步都有对应的验证命令。免得一上来就在终端上盲目 ping，最后绕一大圈才发现是 Trunk 链路的问题。

6. 第三阶段养成的两个小习惯：变更验证和笔记沉淀

6.1 每次变更后必须跑的三条验证命令

第三阶段我犯过的最大的错误，是配置完交换机之后不做验证就直接收工。表面上配置命令都执行成功了，但某台设备上漏了一条命令，或者某个端口没有生效，问题要等到业务跑起来才暴露，代价就是一整个下午的紧张排查。

所以我给自己定了一条规矩：任何变更做完，立刻跑这三条命令，不看结果不进下一步。

show vlan brief show interfaces status show interfaces trunk

show vlan brief确认 VLAN 和端口映射对不对；show interfaces status确认物理层有没有问题，端口是不是按预期 up；show interfaces trunk确认跨交换机链路的 Trunk 状态和放行列表是否一致。这条习惯看起来很基础，但能拦住大量低级失误。至少在我自己身上，它把“配置完还要返工”的概率压低了一多半。

6.2 我的笔记只记“反例”，不抄官方文档

关于笔记这事，我也想多说一句。一开始我的笔记密密麻麻，全是命令语法，抄得跟说明书一样。后来发现，真到排障的时候，最管用的不是那些语法，而是“反例”——就是那些我踩过坑、花了很长时间才定位到的异常场景。比如接口模式不对称、Native VLAN 不一致、半边 VLAN 黑洞、STP 端口阻塞状态没生效。这些反例才是经验本身。

所以我现在的笔记结构很简单：每个主题先写一两行正常配置，然后用大篇幅记录“什么情况下会挂”“挂掉之后怎么判断”“关键验证命令的输出应该长什么样”。这篇文章里提到的很多细节，都是从这批反例里提炼出来的。如果你也是刚入行的网络工程师，我强烈建议不要只收藏别人的“配置模板”，而是开始维护自己的“排障手册”，把每次翻车的过程写下来。三个月之后，这本手册会比你在网上能找到的任何教程都有价值。