前言
此前分享过一篇文章《eNSP 新玩法：交给 WorkBuddy，设备配置自动完成》，里面借助单臂路由实验，简单演示了 MCP 与 Skill 的基础用法。这次准备用 WorkBuddy 完成一个复杂度更高的实验：通过多段自然语言指令，让 AI 在 eNSP 中从零搭建一套具备冗余与负载分担能力的双核心园区网络。
实现思路如下：以自然语言指令驱动 WorkBuddy，搭配 grbj‑ensp MCP 组件以及 grbj‑ensp‑smart‑config Skill，依次完成网络拓扑搭建、设备参数配置、实验报告输出的全流程自动化操作。其中 WorkBuddy 负责将自然语言指令转化为设备 CLI 命令、抓取设备回显输出，并自动整理输出实验报告；而人工只需要明确实验约束边界、启动实验拓扑，并对最终结果做校验即可。
一、设计要点速览
本次实验涉及的关键技术选型：MSTP（多 VLAN 负载分担）、VRRP（网关冗余，两台核心各承担一半 VLAN 的 Master）、基于 VLAN 的 ACL（受限 VLAN 与业务 VLAN 隔离）、DHCP Server 单独接在服务器 VLAN（DHCP-Router 由 AR 路由器承担，eNSP 没有独立的 DHCP 服务器节点）。涉及的对象有 Access/Trunk 端口、Eth-Trunk 聚合、MSTP 多生成树、VLANIF 三层接口、VRRP 虚拟网关、DHCP 中继、ACL 流量过滤共 7 类。具体参数（VLAN 与主备对应关系、IP 地址、ACL 规则号、地址池范围）由 WorkBuddy 完成配置后输出到实验报告。
二、实验拓扑与地址规划
2.1 拓扑概览
本实验共 12 台设备：4 台交换机、1 台路由器、7 台 PC。
- 2 台核心三层交换机：Core-SW1、Core-SW2
- 2 台接入二层交换机：Access-SW1、Access-SW2
- 1 台 DHCP-Router（AR 系列路由器，承担 DHCP Server 角色；拓扑图中按惯例标为 DHCP Server 节点）
- 7 台 PC 业务终端：覆盖 4 个业务 VLAN（其中一个为受限 VLAN，验证 ACL 场景）
2.2 拓扑示意
拓扑按三层结构组织：核心层为 Core-SW1 与 Core-SW2，两机之间通过一条聚合链路横向互联；接入层为 Access-SW1 与 Access-SW2，分别通过聚合链路上行到正上方的核心交换机；Core-SW1 与 Access-SW2、Core-SW2 与 Access-SW1 之间还各有一条交叉链路，由 MSTP 阻塞为备份路径。
具体的 Eth-Trunk 编号、端口号、设备互联明细，由 WorkBuddy 完成配置后输出到实验报告。
2.3 VLAN 与业务映射
| VLAN ID | 业务角色 | 备注 |
|---|---|---|
| 10/20 | 普通用户 VLAN | 数量较多的业务部门终端 |
| 30 | 受限 VLAN | 需通过 ACL 控制其访问目标业务 VLAN |
| 40 | 普通用户 VLAN | 信息类部门终端 |
| 50 | 服务器 VLAN | DHCP-Router 接入所在 |
TIP 为什么 MSTP 实例分配与 VRRP 主网关要保持一致？
MSTP 决定「流量从哪条路上行」，VRRP 决定「流量去哪个网关」。如果两者的根桥/主网关指向同一台核心交换机，同 VLAN 的上行路径与网关就在同一台设备，避免「上行到 A 核心、网关却在 B 核心」造成的额外一跳。本实验就是按这一原则做的设计。
TIP 为什么 DHCP-Router 接在 Access-SW2 下？
把所有终端类设备集中到接入层，让核心保持纯 L2/L3 转发职责，架构边界更清晰。
具体的物理端口、IP 地址、DHCP 地址池、MSTP 实例-VLAN 映射等细节，由 WorkBuddy 完成配置后输出到实验报告。
三、指令 1：让 WorkBuddy 创建综合实验拓扑
下面的指令只描述「要搭什么样的拓扑」，具体的设备型号、端口分配由 WorkBuddy 自主规划。
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 帮我创建一个园区网双核心综合实验拓扑：
- 2 台核心三层交换机（命名 Core-SW1、Core-SW2）+ 2 台接入二层交换机（命名 Access-SW1、Access-SW2）
- 1 台 AR 路由器（命名 DHCP-Router，承担 DHCP Server 角色）
- 7 台 PC 终端（命名 PC1~PC7，覆盖 4 个业务部门 VLAN），外加 1 台 DHCP-Router 独占服务器 VLAN（VLAN 50），接在 Access-SW2 下
拓扑要满足：
- 两台核心之间 1 条链路聚合（提供核心间高带宽）
- 每台核心到正上方的接入交换机 1 条主链路；同时存在 2 条交叉链路（Core-SW1↔Access-SW2、Core-SW2↔Access-SW1），由 MSTP 阻塞为备份路径
- 业务 PC 按 VLAN 分散在两台接入交换机下，PC1 ~ PC3 接 Access-SW1，PC4 ~ PC7 以及 DHCP-Router 接 Access-SW2。
仅创建拓扑，不要做交换机配置。WorkBuddy 会基于 grbj-ensp mcp 生成 topo 文件。
给 Workbuddy 下达指令。
Workbuddy 回显的一些输出。
指令一完成后的输出：
四、启动拓扑与基础检查
WorkBuddy 完成拓扑创建后，用 eNSP 打开生成的 topo 文件，并手动启动全部设备。WorkBuddy 可以生成 topo 文件、下发 CLI 配置并协助验证，但客户端的图形界面仍需手动打开和操作。待设备图标变绿后，说明设备已启动就绪，可以继续下一步配置。
用 eNSP 打开拓扑即可。
将所有的设备启动。
五、指令 2：让 WorkBuddy 完成基础网络配置
确认全部设备启动完成后，发送下面的指令。VLAN ID、Eth-Trunk 编号、端口号等细节由 WorkBuddy 自己规划。
上一步指令创建的拓扑图已经在 eNSP 中启动了，请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 完成以下基础网络配置：
0. PC↔VLAN 与接入侧归属：
- PC1 → VLAN 10，接 Access-SW1
- PC2 → VLAN 20，接 Access-SW1
- PC3 → VLAN 30（受限 VLAN），接 Access-SW1
- PC4 → VLAN 10，接 Access-SW2
- PC5 → VLAN 20，接 Access-SW2
- PC6 → VLAN 40，接 Access-SW2
- PC7 → VLAN 40，接 Access-SW2
- DHCP-Router → VLAN 50，接 Access-SW2
一、基础 VLAN
1. 在 4 台交换机上分别创建 5 个 VLAN，对应 4 个业务部门 + 1 个服务器 VLAN；
2. 按第 0 段绑定表，把 7 台 PC 接入对应 VLAN 的 access 端口；DHCP-Router 接入服务器 VLAN。
二、Trunk 与 Eth-Trunk
3. 把 4 台交换机的 5 组互联端口配置为 trunk，并放行所有业务 VLAN；
4. 5 组互联端口按以下逻辑聚合为 Eth-Trunk：
- 核心之间 1 条聚合链路
- 每台核心到正上方的接入交换机 1 条主链路（Core-SW1↔Access-SW1、Core-SW2↔Access-SW2）
- 每台核心到对侧接入交换机 1 条交叉链路（Core-SW1↔Access-SW2、Core-SW2↔Access-SW1）
- 接入交换机侧把上行物理端口加到对应 Eth-Trunk
三、MSTP 多生成树
5. 在 4 台交换机上配置 MSTP 域（域名自定义即可）；
6. 用 2 个 MSTP 实例分别承载两类业务 VLAN（按业务规划分担），让两台核心各为一个实例的主根、互为备份根；服务器 VLAN 走默认实例，且由 Core-SW1 担任主根，与 VLAN 50 的 VRRP Master 保持一致；
7. 4 台交换机全部启用 stp enable。
完成后输出每台交换器的关键回显（display vlan、display eth-trunk、display stp brief），用于阶段校验。执行完这一步，基础网络层就搭建完成了：VLAN 划分到位、互联链路是 trunk 并已聚合、MSTP 实例与根桥配置到位。此时同一 VLAN 内部还无法通信——因为还没有三层网关。下一步配置 VLANIF 与 VRRP。
给 WorkBuddy 下达第二个指令：
WorkBuddy 运行时的一些输出：
指令一完成后的输出：
还会生成一份中间阶段的校验报告，如果有错误可以在下一步的提示词中校正。
六、指令 3：让 WorkBuddy 完成网关与冗余配置
继续把下面的指令发给 WorkBuddy。具体 IP、网关段位、VRRP 主备分配原则由 WorkBuddy 自己规划，但负载分担语义需要说清楚：让两台核心各承担一部分 VLAN 的 Master，而不是都偏向一台。
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 完成以下三层与冗余配置：
一、VLANIF 网关
1. 在 Core-SW1 与 Core-SW2 上分别为 5 个 VLAN 创建 VLANIF（同一 VLAN 的两台核心 IP 末位区分开即可，比如 .2 与 .3）。
二、VRRP 虚拟网关（负载分担，不是主备集中）
2. 每个 VLANIF 启用 VRRP：VLAN 10/20/50 由 Core-SW1 担任 Master（priority 120），VLAN 30/40 由 Core-SW2 担任 Master（priority 120）；
3. 同一 VLAN 内两台核心的 vrid 取值保持一致。
三、DHCP 中继
4. Core-SW1 与 Core-SW2 的 5 个 VLANIF 都启用 dhcp select relay，中继目的地指向 DHCP-Router（在 DHCP-Router 上启用 DHCP Server，按 4 个业务 VLAN 创建地址池）；
5. DHCP-Router 通过 Access-SW2 与核心交换机之间用服务器 VLAN（VLAN 50）trunk 互联；DHCP-Router 默认网关指向服务器 VLAN 的虚拟网关。
完成后输出每台 VLANIF 的 IP、VRRP 状态、DHCP 中继配置回显，用于阶段校验。执行完这一步，跨 VLAN 通信、三层冗余、DHCP 自动分配地址的能力都已就绪。VLAN 30 暂时还没有访问控制，下一步加 ACL。
给 WorkBuddy 下达第三个指令：
中间阶段的输出：
操作完成后输出，还会生成一份中间阶段的校验报告。
配置完成以后将各个 PC 的 IP 地址的配置方式改为 DHCP，看看能不能获取到地址。每个 PC 都需要配置和检查有没有正确获取 IP 地址，这个步骤 AI 操作不了。
在命令行，输入 ipconfig 查看是否获取到了 IP 地址。
可以手工到交换机上敲命令检查看看配置对不对，你如果完全信任的话也可以不检查，或者到最后再检查都行。
七、指令 4：让 WorkBuddy 完成 ACL 与实验报告
最后一段指令收尾：加 ACL、做完整的连通性验证，并由 WorkBuddy 整理实验报告。具体 ACL 规则号、源/目的网段、地址池参数由 WorkBuddy 自己规划。
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 完成以下收尾工作：
一、ACL 访问控制
1. 在 Core-SW2 上创建一个基本 ACL，规则只一条：阻断受限 VLAN 访问另一个指定业务 VLAN，其他流量放行；
2. 在 Core-SW2（VLAN 30 Master）的 VLAN 30 VLANIF 入方向应用该 ACL（traffic-filter vlan XXX inbound acl 3000 这一类命令格式）。
二、DHCP-Router 配置
3. 在 DHCP-Router 上启用 DHCP 服务，为 4 个业务 VLAN 各创建一个全局地址池（network、gateway、dns、lease 等参数按各 VLAN 用途设置即可）；
4. DHCP-Router 上联 Access-SW2 的接口设为 dhcp select global，让 DHCP 请求从全局地址池下发。
三、连通性验证
5. 让 WorkBuddy 按下面的验证矩阵逐项执行 ping、抓回显（每一步记录到用于报告整理的中间笔记中）：
- 同 VLAN 互通：同一 VLAN 内两台 PC 互 ping
- 跨 VLAN 互通：不同 VLAN 的 PC 互 ping
- 访问服务器 VLAN：业务 PC ping DHCP-Router
- DHCP 获取：让所有 PC 设为 DHCP，确认各 PC 获取到正确 VLAN 网段地址
- VRRP 切换：关闭一台核心的主网关 VLANIF，验证 PC 仍可 ping 通网关；恢复后该核心重新成为主
- MSTP 路径切换：拔掉一条核心到接入的主链路物理线，验证对应 VLAN PC 仍可通信
- ACL 阻断：受限 VLAN ping 目标业务 VLAN 应不通；ping 其他 VLAN 应通；非受限 VLAN 互 ping 应通
四、实验报告生成
6. 按 grbj-ensp-smart-config skill 的「实验报告生成」专章输出 .docx 实验报告。到这一步，全部配置与验证都已自动化完成。完成后会得到一份完整的实验报告，含配置回显、验证结果、故障排查建议。一些需要 GUI 的操作和在 PC 上的操作 AI 操作不了，需要手动操作一下，比如：PC 改为 DHCP 获取地址，在 PC 上做 ping 测试。
给 WorkBuddy 下达第四个指令：
中间阶段的一些内容输出：
操作完成后输出，可以看到 docx 版本的实验报告也生成了。
实验报告展示（部分）
看了实验报告，发现我前面的指令其实有点问题，拓扑图在 Eth-Trunk 的连线是单条线，并没有多跟线。
八、指令 五：让 WorkBuddy 完成连线和配置修改
每条 Eth-Trunk 当前只有 1 个成员口——前面的指令漏掉了每组互联链路应为 2 条物理线的需求；实际生产应至少 2 条物理线才能发挥聚合优势。本指令按下面 5 步走，AI 与人工交替。
第一步：保存配置（AI）
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 将当前所有设备的配置保存一遍，并备份一份到本地。eNSP 丢配置比较常见，保存失败会导致配置丢失。这一步可以让 WorkBuddy 多操作几次确认，或自己手动保存一次。
第二步：关闭拓扑图（人工）
在 eNSP 客户端里关闭当前拓扑图。
第三步：修改拓扑图增加连线（AI）
请使用 grbj-ensp mcp 修改当前 topo 文件，在每组互联链路上补 1 条物理线（5 组共补 5 条物理线），保存到原路径。
第四步：打开拓扑图并启动设备（人工）
在 eNSP 客户端里打开拓扑图并启动全部设备（eNSP 客户端不会监听 .topo 变化，必须重启才能加载新连线）。
从端口号看是有两根线的，只是 AI 绘图的时候线条定位没有偏移导致线条重合了，这个不碍事。
设备开机以后使用命令查看，也可以看到接口是连接正常的，如果介意 AI 将线接在了一起可以再下达指令让 AI 调整线缆的位置。
第五步：配置 Eth-Trunk（AI）
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 扩展 Eth-Trunk 成员口：
1. 把新加端口加入对应 Eth-Trunk，使每条 Eth-Trunk 达到 2 成员口；
2. 重新抓 display eth-trunk 回显，确认每条 Eth-Trunk 成员口数达到 2。
TIP 不想这么麻烦？
直接在 eNSP 客户端里手工增加物理线（5 组共 5 条），然后开始第五步就可以了。
九、WorkBuddy 在背后做了什么
把上面那几段自然语言指令翻译过来，WorkBuddy 实际下发的核心 CLI 大致如下。这部分用来展示 WorkBuddy 的工作模式，并不需要逐条手敲。
9.1 基础 VLAN + Eth-Trunk
vlan batch 10 20 30 40 50
interface Eth-Trunk 1
port link-type trunk
port trunk allow-pass vlan 10 20 30 40 50
trunkport GigabitEthernet 0/0/23
trunkport GigabitEthernet 0/0/24
interface GigabitEthernet 0/0/5
port link-type access
port default vlan 109.2 MSTP 多生成树（Core-SW1 上的命令）
stp region-configuration
region-name GRBJ
instance 1 vlan 10 20
instance 2 vlan 30 40
active region-configuration
stp instance 1 root primary
stp instance 2 root secondary
stp instance 0 root primary
stp enableCore-SW2 上的对应命令为
stp instance 1 root secondary+stp instance 2 root primary。
9.3 VLANIF + VRRP（Core-SW1 上的命令）
interface Vlanif 10
ip address 192.168.10.2 255.255.255.0
vrrp vrid 10 virtual-ip 192.168.10.1
vrrp vrid 10 priority 120
dhcp select relay
dhcp relay server-ip 192.168.50.2Core-SW2 上的 VLANIF 10 对应配置 IP 末位用 .3、priority 保持默认 100（Backup）；VLANIF 30/40 在 Core-SW2 上配 priority 120（Master）。
9.4 ACL（Core-SW2 上的命令）
acl number 3000
rule 5 deny ip source 192.168.30.0 0.0.0.255 destination 192.168.20.0 0.0.0.255
rule 10 permit ip
traffic-filter vlan 30 inbound acl 3000对熟练的网络工程师来说，这些命令并不复杂。WorkBuddy 的价值不在命令本身，而在它把「多设备、多步骤、多验证」的整套工作串成一条流水线，并把每一步的回显与结论整理进实验报告。
TIP 为什么不让 WorkBuddy 一次性下发所有配置？
分段下发的好处是：每一步都可以独立验证，任一步失败都只影响本步及后续，不至于一上来就「全网不通」。涉及 MSTP 根桥选举、VRRP 主备切换、DHCP 中继这些状态敏感的配置，分段排查尤其重要。
十、常见问题：把现象再交给 WorkBuddy 排查
WorkBuddy 偶尔也会漏掉环境细节。这时候不需要自己查文档或翻命令，把现象准确描述给它，它会自己抓回显、给根因、下发修复指令。
以下四类是本次实验最容易出现的问题现象，每一类都已经备好现成的指令模板，直接转发给 WorkBuddy 即可。
现象 1：VLANIF 接口没有 UP
转发以下指令：
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 排查 VLANIF 不 UP 的问题：
- 当前 VLANIF 列表与 UP/DOWN 状态（display interface vlanif brief）
- 在每台相关交换机上抓 display vlan、display port vlan、display eth-trunk 回显
- 给我根因分析与修复方案，并直接执行修复指令现象 2：VRRP 主备角色颠倒
转发以下指令：
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 排查 VRRP 主备颠倒：
- 抓 display vrrp brief 回显
- 检查每台 VLANIF 的优先级、vrid、虚拟 IP
- 给我根因与修复，并直接执行修复指令现象 3：DHCP 终端获取不到地址
转发以下指令：
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 排查 DHCP 获取失败：
- 哪些 VLAN 的终端取不到地址
- 抓 display dhcp relay、display ip pool 回显
- 给我根因与修复，并直接执行修复指令现象 4：ACL 阻断反了或没生效
转发以下指令：
请使用 grbj-ensp mcp 和 grbj-ensp-smart-config skill 排查 ACL 异常：
- 描述预期行为与实际行为
- 抓 display acl 3000、display traffic-filter applied-record 回显
- 给我根因与修复，并直接执行修复指令修复完成后，让 WorkBuddy 重跑一遍第九节的验证矩阵确认。每类问题的指令模板都不长，人工侧的工作只是把现象说清楚、把指令转发过去。整个排查闭环仍由 AI 完成。
延伸思考：当工具可以替代双手
完整跑完本次实验：一个事实浮现——4 段自然语言指令驱动 WorkBuddy 完成了 7 项关键技术的综合配置（VLAN + Trunk、Eth-Trunk、MSTP、VRRP、VLANIF、DHCP 中继、ACL），验证矩阵覆盖了基础连通、DHCP 自动分配、VRRP 主备切换、MSTP 路径切换、ACL 访问控制 5 组共 14 项场景；中间出现配置异常时，把现象描述给 WorkBuddy 即可继续推进。
那么问题来了：WorkBuddy 几乎完成了所有配置，学网络还有意义吗？
这是个值得认真回答的问题。
AI 替代的是重复劳动，业务上下文仍由工程师持有。 WorkBuddy 擅长的是把明确的需求翻译成有序的 CLI 命令，并按预设流程跑验证。本实验的 4 段指令之所以可行，是因为设计阶段已经把「为什么用 MSTP 而不是 STP」「VRRP 主网关为什么分配给 Core-SW1 而不是 Core-SW2」「ACL 应该 deny 哪些网段」这些决策写进了规划方案——AI 在收到指令后能正确执行，但这些决策背后的业务理解、风险权衡、架构判断，AI 不会替人持有。工程师要做的，是把业务上下文翻译成可被 AI 理解的指令。
配置 ≠ 设计意图。 本次实验中，MSTP 实例与 VRRP 主网关保持一致这个细节，是写进规划方案后才在指令里体现的。AI 能从规划文档读到「MSTP-VRRP 同向」这类设计原则并自行应用，但前提是设计意图要先被人显式提供。缺少这类设计意识时，AI 也能跑通一个「配置都对、流量绕远路」的网络——AI 听懂了命令，但没有替人持有「为什么要这样配」。
AI 在故障定位上比工程师更快，但「故障定义权」仍在工程师手里。 WorkBuddy 可以并行抓多台设备的 display 回显、交叉比对配置差异、按预设模式推断根因，这类工作的效率远高于人。但「什么算故障」「这次抖动是否值得响应」「修复方案在业务上是否可接受」这类判断仍要工程师承担：一次 VRRP 短暂抖动，可能是核心重启、可能是链路瞬断、也可能只是配置变更的预期行为，AI 不知道这次故障对业务意味着什么。AI 把诊断做快，工程师决定要不要行动。
AI 工具的驾驭者，差距正在拉大。 会用 AI 配置网络的人，和不会用 AI 配置网络的人，工作效率的差距正在拉大。但这种差距的本质，不是「谁更会用 AI」，而是「谁能在 AI 替代不了的地方（需求定义、方案决策、故障定级）做出更好的选择」。
结论：学网络的意义变了吗？没变。 学的从来都是「建立完整的网络认知模型，能定义问题、判断方案、把工具用对地方」——这一点从没有变。变的是工具和表达方式：CLI 手敲变成了自然语言指令，工程师的双手被工具替代，但定义需求、决策方案、定级故障这三件事，仍要工程师亲自承担。当工具可以替代双手时，工程师的价值会向上迁移到问题定义、方案决策、故障定级三个层面——而这三件事，从来就是学网络的全部意义。
沿着这个方向，本实验的双核心最小架构可以扩展到更多能力：加端口安全（限制每个 access 端口最大 MAC 数）、加 Super VLAN 或 MUX VLAN（私有 VLAN 隔离）、加 DHCP Snooping（防私接 DHCP Server）、加堆叠（用 iStack 把两台核心虚拟成一台，进一步简化 VRRP 配置）、加 OSPF（在双核心之间跑动态路由，让上游链路故障自动收敛）。这些方向都是真实园区网里常见的增强项，本次实验已经为它们留好了接入点。
