eNSP AI 平台
本项目是一个面向 eNSP（华为网络模拟器）实验/教学场景 的前后端分离平台：支持导入 .topo 拓扑、自动连接本地 eNSP 设备 Console 抓取 display current-configuration，并结合拓扑与配置进行故障分析、输出修复建议与命令。同时集成 Ping 工具、子网计算器、网络扫描等常用辅助能力。如需获取项目进一步优化开发，请站内私信。
适用场景：课程实验、网络排障训练、批量配置生成、拓扑可视化与工具化分析。
1. 核心能力概览
1.1 AI 智能修复（重点）
- 上传 eNSP 导出的
.topo文件
- 平台解析拓扑并识别设备（AR/S 系列交换机/USG 防火墙/PC 等）
- 对每台设备自动连接
127.0.0.1:<com_port>（.topo中自带的 Console 端口） - 自动执行
display current-configuration抓取设备当前配置（支持自动翻页，避免---- More ----截断） - 规则化“预分析”（确定性证据）+ LLM 深度分析（可选）
- 输出：问题分析、排查步骤、按设备下发的修复命令，并附带“采集到的配置内容”
1.2 网络工具集
- Ping 工具：支持持续 ping、SSE 流式返回、历史记录
- 子网计算器：辅助 IPv4 子网划分/地址规划
- 网络扫描：接口发现、扫描历史记录（以本机网络信息与探测结果为主）
1.3 用户与历史
- 轻量用户注册/登录（SQLite）
- Ping/扫描历史记录（SQLite，默认保留最近 50 条）
2. 技术栈与目录结构
2.1 技术栈
- 前端：Vue 3 + Vite + Element Plus + Pinia + Vue Router
- 后端：Python Flask + Flask-CORS
- 拓扑解析：lxml（解析 eNSP
.topoXML） - AI 能力：LangChain + langchain-openai（可配置任意兼容 OpenAI API 的网关）
- 数据库：SQLite（
users.db）
2.2 目录结构（核心）
ensp/ ensp-frontend/ # 前端（Vue3/Vite） ensp-backend/ # 后端（Flask） test.topo # 示例 topo 文件后端关键文件：
ensp-backend/app.py：Flask API 入口、拓扑解析、AI 修复、Ping/扫描等ensp-backend/telnet_client.py：eNSP Console Telnet 采集实现（含翻页与控制码清理）ensp-backend/llm_service.py：LLM 调用与输出结构（RepairSolution）ensp-backend/database.py：SQLite 用户与历史记录ensp-backend/topo_generator.py：拓扑/配置生成相关能力（与 AI 修复不同链路）
前端关键文件：
ensp-frontend/src/views/AIRepairView.vue：AI 修复页面（采集统计、配置输出、预分析证据、修复结果）ensp-frontend/src/router/index.js：路由与登录态守卫
3. AI 修复的工作原理（端到端）
AI 修复链路的目标是：先确保拿到“真实配置”，再做“基于证据的分析”。
3.1 拓扑解析
.topo 本质是 XML。平台解析得到：
nodes[]：设备 id/name(model)/com_port/坐标edges[]：设备间连接关系（当前未解析端口号，仅保留设备级连接）
其中 com_port 是 eNSP 分配的 Console 端口（例如 2000/2001…），用于后续自动采集配置。
3.2 配置采集（Telnet Console）
平台对每台设备：
- 连接
127.0.0.1:<com_port> - 发送命令：
screen-length 0 temporary（尽量关闭分页） - 执行：
display current-configuration | no-more（优先拿全量） - 若设备不支持
| no-more，自动回退到display current-configuration - 采集过程中若出现分页提示
---- More ----，会自动发送回车继续直到结束 - 清理终端输出中的 ANSI 光标控制码（例如
\x1b[42D），避免“乱码”
采集结果会以每台设备维度返回：
ok / skipped / error：采集是否成功、是否跳过、失败原因config_len：配置长度config_key_lines：提取的关键配置块/关键行config_preview：配置预览（为避免页面过大，默认截断到前 12000 字符）
3.3 规则化预分析（确定性证据）
仅靠大模型容易出现“看到 OSPF 就归因 OSPF”的问题。为避免这种“幻觉式推理”，平台在 LLM 之前增加了 确定性预分析：
- 从配置解析接口块，提取每个
interface下的ip address - 如果某设备 没有任何接口 IP，直接给出高置信发现（例如“源设备缺少接口 IP”）
- 根据拓扑链路检查：链路两端 L3 设备是否存在共同网段（否则标记为可疑）
- 从问题描述中尝试抽取“源设备 + 目标 IP”，并识别目标 IP 的归属设备/接口（如果能从配置里匹配到）
预分析结果会以 precheck 字段返回，并注入大模型上下文，让模型优先解释“证据明确的低级错误”（如接口未配 IP）。
3.4 LLM 深度分析（可选）
如果配置了 OPENAI_API_KEY 等环境变量，平台会调用模型输出结构化 JSON：
analysis：基于证据的原因分析solution_steps：排查/修复步骤commands：按设备给出可执行命令列表
若 LLM 不可用，平台会返回可用的降级提示，并保留采集的配置与预分析证据，仍可用于人工排障。
4. 常见误判的根因与本项目的改进点
在 eNSP 实验中，“删接口 IP 导致不通”这类问题非常常见。早期版本的 AI 结果容易出现：
- 只给“OSPF/路由传递问题”这种泛化结论
- 未明确指出“接口 IP 缺失/网段不一致”这类硬证据
主要根因：
- LLM 在没有强证据时容易做经验推断
- 拓扑解析未包含端口级映射，模型难以做精确链路定位
- 配置上下文过长/过散，模型抓不到“缺失配置”的关键证据
本项目的改进：
- Telnet 全量采集 + 自动翻页
- 清理控制码，保证输出可读
- 引入规则化预分析（高置信证据）
- 将“证据”在前端直接展示，避免黑盒
5. API 设计（摘要）
后端默认地址：http://localhost:5000
5.1 AI 修复
POST /api/ai-repair- FormData：
file:.topoissue: 问题描述文本
- 返回：
analysis/solution_steps/commandsdevice_collection：设备采集明细（含配置预览）precheck：预分析证据
- FormData：
5.2 LLM 配置
GET/POST /api/system/llm-config- 用于读取/写入
.env中的模型配置（注意不要提交.env到 GitHub）
- 用于读取/写入
6. 本地运行
6.1 前置条件
- Windows 环境（eNSP 主要运行于 Windows）
- eNSP 已启动且拓扑中设备已运行完成
- Python（建议使用虚拟环境）
- Node.js / npm
6.2 启动后端
进入 ensp-backend/：
pip install -r requirements.txt python app.py默认监听：http://127.0.0.1:5000
6.3 启动前端
进入 ensp-frontend/：
npm install npm run dev -- --host 0.0.0.0 --port 5173如果 5173 被占用，Vite 会自动换到 5174/5175…，以控制台输出为准。
