简介：本资源是一套基于华为eNSP平台构建的企业级网络模拟实验环境，面向网络工程初学者、高校通信/计算机专业学生及备考HCIA/HCIP认证的工程师，解决网络规划设计与安全策略落地缺乏实操场景的问题。压缩包共32个文件，含12个efz设备镜像（用于路由器、防火墙等虚拟设备加载）、9个txt配置脚本（覆盖核心层、汇聚层、接入层及FTP、远程管理等典型业务）、6个PC.xml终端配置、1个.topo拓扑定义文件及1份.docx设计文档，辅以HTML索引页和CFG备份文件，整体仅2.62MB，轻量易部署。已有72人下载学习，可直接导入eNSP运行完整拓扑，直观理解三层架构划分、VLAN间路由、ACL访问控制、防火墙策略部署等关键设计逻辑，并通过多节点PC.xml与flash.efz组合复现实验终端状态，配合txt配置文件快速掌握企业网从规划到安全加固的全流程实践路径。
1. ENSP 模拟企业网实例（精品拓扑）：一套能直接加载、验证三层架构与边界防护策略的可运行拓扑包
这不是一个“画出来好看”的拓扑图，而是一套在华为 eNSP 5.16+ 环境下实测可启动、可 ping 通、可 telnet 登录、可抓包验证 ACL/防火墙策略的完整企业网仿真环境。它真实还原了典型三层架构——核心层（Core1）、汇聚层（AR1 + FW1）、接入层（多台交换机 + PC.xml 终端），并预置了远程管理（telnet/SSH）、FTP 文件传输、Web 服务（index.html）、跨 VLAN 通信、静态路由与 OSPF 基础互通等关键能力。更关键的是，它把网络安全从概念落到设备级动作：FW1.txt 明确配置了 NAT Server、安全域划分、域间策略、URL 过滤规则；AR1 上启用了 ACL 限制 FTP3.txt 所示的特定端口访问；所有 flash.efz 和 vrpcfg.zip 都是真实设备启动所需的镜像与配置快照，不是空壳文件。适合刚学完 HCIA-Datacom 或正在备考 HCIP 的工程师快速复现企业网部署流程，也适合讲师直接导入课堂做故障注入演练——比如故意删掉 Core1.txt 中的 OSPF network 命令，让学生用 display ospf peer 看邻居断连现象。别被“.topo”后缀骗了，它不是静态图纸，而是带状态、带配置、带业务流的黑匣子。
2. 拓扑结构解析与设备角色映射：从 .topo 文件到真实设备行为的逐层拆解
2.1 拓扑图（.topo）本质：eNSP 工程文件的 XML 结构与设备绑定逻辑
.topo文件并非图片，而是 eNSP 工程的序列化描述文件，本质是 XML 格式。它不存储设备配置，只记录设备类型、ID、位置、连线关系及关联的.cfg/.xml文件路径。本包中ensp模拟企业网实例（精品拓扑图）.topo文件内嵌了 12 类设备节点（含 3 台 AR 路由器、2 台 USG6000V 防火墙、4 台 S5700 交换机、3 台 PC），并通过<link>标签定义了 18 条物理链路。关键点在于：每个<device>节点的cfgFile属性指向对应设备的配置源，例如：
<device id="AR1" type="AR1220" cfgFile="AR1.txt" ... /> <device id="FW1" type="USG6000V" cfgFile="FW1.txt" ... /> <device id="PC1" type="PC" cfgFile="PC.xml" ... />这意味着你双击拓扑中 AR1 图标时，eNSP 实际加载的是AR1.txt中的 CLI 配置命令，而非空白设备。这种“配置外挂”机制让拓扑具备可复现性——只要.topo+ 所有引用的.txt/.xml/.efz文件齐全，就能 100% 还原原始环境。我一般会先用文本编辑器打开.topo，搜索cfgFile=快速确认所有依赖文件是否都在压缩包根目录，避免因文件名大小写或路径错误导致设备启动失败。
2.2 设备角色与功能分工：三层架构如何通过配置文件协同工作
| 设备 ID | 类型 | 关键配置文件 | 核心职责 | 验证命令示例 |
|---|---|---|---|---|
| Core1 | AR2220 | Core1.txt | OSPF Area 0 核心路由器，宣告所有直连网段，作为全网路由中枢 | display ip routing-table |
| AR1 | AR1220 | AR1.txt | 汇聚层路由器，连接接入交换机与 FW1；配置 ACL 限制 FTP3.txt 所示的 21/23 端口 | display acl all |
| FW1 | USG6000V | FW1.txt | 边界防火墙，划分 trust/untrust 安全域，配置 NAT Server 映射内网 Web 服务 | display firewall session table |
| S1-S4 | S5700 | 接入层.txt | 二层接入交换机，配置 VLAN 10/20/30，启用 DHCP Snooping 防 ARP 欺骗 | display vlan |
| PC1-PC3 | PC | PC.xml | 预设 IP/MAC/DNS 的终端，PC.xml 中<ip>标签定义了固定地址（如 192.168.10.10） | ipconfig（Windows） |
提示：所有 PC.xml 文件均采用
<ip>+<mask>+<gateway>三元组硬编码 IP，而非 DHCP 自动获取。这是为确保实验环境确定性——避免因 DHCP 服务器故障导致整网失联。若需测试 DHCP 流程，可手动修改 PC.xml 中<dhcp>标签为true，再在 AR1 上启用dhcp enable并配置地址池。
2.3 配置文件与设备镜像的版本强耦合：为什么必须用配套 flash.efz
eNSP 启动设备时，会将.efz文件解压为设备的 Flash 存储镜像。本包中包含 15 个flash.efz文件（如2623B870-06D3-4ae2-BE3A-422A68ED9330.flash.efz），每个对应一台设备的初始系统镜像。这些镜像版本与.txt配置文件严格匹配：
FW1.txt中使用firewall packet-filter basic-enable命令，该命令仅在 USG6000V V500R005C20 及以上版本支持；Core1.txt中ospf 1 router-id 1.1.1.1后紧跟area 0.0.0.0，这是 AR2220 V200R010C00 的语法，若强行用 V200R005C00 镜像会报错Unrecognized command found at '^' position。
因此，绝不能用自己下载的任意版本镜像替换本包中的.efz。我曾因图省事用新版 USG6000V 镜像启动 FW1，结果发现security-policy命令被拆分为interzone+policy两步，原有 FW1.txt 配置全部失效，调试 3 小时才定位到镜像版本差异。
3. 加载与启动全流程：从解压到业务连通的六步实操指南
3.1 环境准备：eNSP 版本、依赖组件与路径规范
必须使用eNSP 5.16（Build 521）或 5.17（Build 530），低版本不支持 USG6000V V500R005C20 镜像，高版本（如 5.18）存在 PC.xml 解析兼容性问题。安装时勾选以下组件：
- VirtualBox 5.2.44（非最新版！6.x 会导致 PC 设备无法启动）
- WinPcap 4.1.3（抓包必需，Wireshark 用不到）
- CloudEngine 交换机插件（虽本包未用 CE 设备，但缺失会导致拓扑加载失败）
注意：所有文件解压后必须放在无中文、无空格、路径深度 ≤3 层的目录下，例如
D:\ensp-enterprise\。eNSP 对 Unicode 路径处理异常，曾有用户因解压到D:\我的文档\ensp\导致 PC.xml 读取乱码，PC 获取不到 IP。
3.2 拓扑加载与设备初始化：规避“启动失败40”和“井号卡死”
启动 eNSP → 新建工程 → 导入
.topo文件
不要点“打开拓扑”，必须用“新建工程”再“导入”，否则设备配置路径会丢失。批量设置设备启动参数
右键拓扑空白处 → “工程设置” → “设备启动参数” → 勾选“启动时自动加载配置”。此步关键：若未勾选，设备启动后是空白状态，需手动startup saved-configuration，但本包配置已固化在.txt中，无需额外保存。逐台启动并观察日志
重点监控 AR1 和 FW1：- AR1 启动后应显示
AR1>提示符，若卡在#说明AR1.txt中user-interface vty 0 4缺少authentication-mode password； - FW1 启动后若持续输出
#####（井号），大概率是flash.efz损坏或版本不匹配，立即停止并校验 MD5（本包所有.efz文件 MD5 已附在说明.txt中）。
- AR1 启动后应显示
3.3 业务连通性验证：四层验证法确保网络可用
| 验证层级 | 操作步骤 | 预期结果 | 失败排查方向 |
|---|---|---|---|
| L1 物理层 | 查看所有设备右下角状态灯：绿色=链路 UP，灰色=DOWN | 所有直连链路状态灯均为绿色 | 检查.topo中<link>是否遗漏port属性 |
| L2 数据链路 | 在 PC1 上ping 192.168.10.1（S1 的 VLANIF10 接口） | 通，且arp -a可见 S1 的 MAC 地址 | 检查 S1 的interface Vlanif10是否undo shutdown |
| L3 网络层 | 在 PC1 上ping 192.168.100.1（Core1 的 Loopback0） | 通，tracert 192.168.100.1显示路径经 AR1→Core1 | 检查 Core1 的ospf 1是否network 192.168.100.0 0.0.0.255 |
| L4 应用层 | PC1 浏览器访问http://192.168.200.100（FW1 NAT Server 映射的内网 Web 服务） | 显示index.html内容，且display firewall session table可见 HTTP 会话 | 检查 FW1 的security-policy是否放行source-zone trust→destination-zone untrust |
4. 网络安全策略落地：从 FW1.txt 到可审计的边界防护实践
4.1 防火墙策略配置解析：安全域、NAT Server 与 URL 过滤的协同逻辑
FW1.txt是本包网络安全的核心，其策略设计遵循“最小权限”原则：
# 步骤1：定义安全域（明确信任边界） firewall zone trust add interface GigabitEthernet1/0/0 # 连接内网 Core1 firewall zone untrust add interface GigabitEthernet1/0/1 # 连接外网 AR1 # 步骤2：配置 NAT Server（端口映射） nat server policy webserver inside-address 192.168.200.100 80 outside-address 202.100.1.100 80 # 步骤3：设置域间策略（精确控制流量） security-policy rule name allow_web_in source-zone untrust destination-zone trust destination-address 202.100.1.100 32 service http action permit # 步骤4：启用 URL 过滤（基于内置分类库） url-filter profile block-malware rule 1 url-category malware action block firewall url-filter enable关键点在于：destination-address必须填NAT 后的公网地址（202.100.1.100），而非内网地址（192.168.200.100）。若填错，策略永远不匹配。我第一次调试时就栽在这里——以为策略针对内网目标，结果display firewall session table显示所有 HTTP 请求都被丢弃，直到用display security-policy statistics发现命中数为 0，才意识到地址写反了。
4.2 ACL 访问控制：AR1 上的精细化流量过滤实践
AR1.txt中的 ACL 并非简单拒绝，而是分层管控：
# ACL 2000：限制 FTP 服务器（FTP3.txt）的访问源 acl number 2000 rule 5 deny tcp source 192.168.30.0 0.0.0.255 destination 192.168.20.100 0 destination-port eq ftp rule 10 permit ip # 应用在接口入方向（防止非法源发起连接） interface GigabitEthernet0/0/1 traffic-filter inbound acl 2000此处source 192.168.30.0 0.0.0.255表示禁止财务部 VLAN30 的所有 PC 访问 FTP 服务器（192.168.20.100），但允许其他部门访问。验证时，在 PC3（VLAN30）上执行ftp 192.168.20.100应超时，而在 PC1（VLAN10）上应成功登录。若 ACL 未生效，检查traffic-filter是否应用在inbound方向——eNSP 中outbound方向 ACL 仅对转发流量有效，对本机发起的 FTP 请求无效。
4.3 远程管理加固：Telnet/SSH 与 Web 登录的差异化配置
远程管理、fwqq、AR1、wbwl.txt文件揭示了管理面安全设计：
| 设备 | 协议 | 配置要点 | 安全等级 |
|---|---|---|---|
| AR1 | Telnet | user-interface vty 0 4下authentication-mode password+set authentication password cipher | ★★☆ |
| FW1 | Web | web-manager enable+web-manager security enable（强制 HTTPS） | ★★★★ |
| Core1 | SSH | stelnet server enable+rsa local-key-pair create+user-interface vty 0 4下authentication-mode aaa | ★★★★★ |
血泪经验：FW1 的 Web 登录默认是 HTTP，必须手动执行
web-manager security enable才启用 HTTPS。若跳过此步，浏览器访问https://202.100.1.100会失败，而http://202.100.1.100虽能打开，但密码明文传输——这正是wbwl.txt（“勿暴露”谐音）提醒的风险点。
5. 避坑指南：eNSP 企业网拓扑加载与策略验证的五大翻车现场
5.1 现象：PC 启动后获取不到 IP，ipconfig显示 169.254.x.x
原因：PC.xml 中<dhcp>标签为false，但未配置静态 IP；或 AR1 的 DHCP 地址池未激活（ip pool创建后未在接口启用dhcp select global）
解决：打开 PC.xml，确认<ip>192.168.10.10</ip>存在；若需 DHCP 模式，修改<dhcp>true</dhcp>并在 AR1 的interface GigabitEthernet0/0/0下执行dhcp select global
5.2 现象：FW1 启动后display firewall session table为空，但 PC 能 ping 通外网
原因：防火墙缺省策略为deny，但未配置security-policy放行任何流量，导致所有穿越流量被静默丢弃
解决：执行display security-policy all查看策略是否存在；若无，按FW1.txt中security-policy段落逐行粘贴，特别注意source-zone/destination-zone顺序不可颠倒
5.3 现象：OSPF 邻居建立失败，display ospf peer显示down
原因：Core1 与 AR1 的 OSPF 区域号不一致（Core1 在 area 0，AR1 配在 area 1），或接口未启用ospf enable
解决：在 AR1 上执行display current-configuration interface GigabitEthernet0/0/0，确认含ospf 1 area 0.0.0.0；若缺失，补ospf 1 area 0.0.0.0 network 192.168.1.0 0.0.0.255
5.4 现象：FTP 服务可连接但无法列目录，ftp> ls返回550 Permission denied
原因：FTP 服务器（FTP3.txt 所指设备）的 ACL 或防火墙策略阻止了LIST命令所需的数据连接端口（通常为 20）
解决：在 AR1 上display acl 2000，确认 rule 5 仅限制destination-port eq ftp（21端口），未误封ftp-data（20端口）；若封了，添加rule 15 permit tcp destination-port eq ftp-data
5.5 现象：Web 页面index.html无法访问，但ping 202.100.1.100通
原因：NAT Server 配置正确，但security-policy未放行service http，或 FW1 的web-manager未启用
解决：执行display nat server确认映射存在；执行display security-policy rule name allow_web_in确认service http在service字段；最后检查display web-manager输出是否含Web manager is enabled
6. 进阶技巧：用拓扑包做故障注入与策略灰度验证
6.1 故障注入三板斧：精准制造、快速定位、闭环验证
真正的工程师不只满足于“跑通”，而是主动制造故障来训练排错肌肉。本包提供天然沙盒：
- 制造路由黑洞：在 Core1.txt 中删除
ospf 1下某条network命令（如network 192.168.30.0 0.0.0.255），观察 PC3（VLAN30）是否无法访问 Web 服务，再用display ip routing-table protocol ospf确认该网段路由消失； - 触发 ACL 拒绝：在 AR1 上临时添加
rule 1 deny ip source 192.168.10.0 0.0.0.255 destination 192.168.20.0 0.0.0.255，然后从 PC1ping 192.168.20.100，用display acl 2000查看 rule 1 的匹配计数器是否递增； - 验证防火墙会话老化：在 FW1 上执行
display firewall session table verbose，找到一条 HTTP 会话，记录其Aging-time（如 30s），等待超时后再次访问 Web，确认新会话创建且计数器重置。
提示：每次故障注入后，务必用
reset counters interface清除接口计数器，避免历史数据干扰判断。我习惯在每次实验前执行save保存当前状态，故障复现后reboot设备回滚——比手动改配置更可靠。
6.2 策略灰度验证：用 PC.xml 批量切换终端角色验证 ACL 效果
PC.xml文件本质是 XML 格式的终端配置模板。本包中 5 个PC.xml文件（07E96104-...、34D520B8-...等）对应不同部门终端，其<ip>和<vlan>属性已预设。利用此特性可做灰度测试：
- 修改
PC1.xml的<vlan>30</vlan>为<vlan>10</vlan>（模拟财务部终端临时划入行政部）； - 在 eNSP 中右键 PC1 → “设置” → “导入配置” → 选择新
PC1.xml； - 启动 PC1，验证其能否访问 FTP 服务器（VLAN10 允许，VLAN30 禁止）；
- 若成功，说明 ACL 策略按 VLAN 精准生效，无需重启设备。
此方法比修改交换机端口 VLAN 更安全——不会影响其他终端，且可逆。从那以后我每次做 ACL 验证，都强制走一遍 PC.xml 替换流程，因为真实企业网中，终端迁移比改 ACL 频繁得多，必须确保策略对终端属性变更敏感。
希望帮到你。
本文还有配套的精品资源，点击获取
