网络策略冲突检测与自动修复系统

基于 Agent 和 LLM 的网络策略冲突检测与自动修复实验系统，支持将修复后的策略映射到 Mininet / Ryu 仿真网络中验证。

项目概述

项目的主流程是：

1. 自然语言意图
2. 意图翻译为 Policy IR
3. 冲突检测
4. 冲突修复
5. 将策略下发到 Mininet / Ryu 进行验证

当前系统重点支持以下能力：

• 将自然语言意图翻译为网络策略
• 检测策略之间的冲突
• 通过 RAG 知识库辅助生成修复方案
• 将策略映射到 Mininet / Ryu 仿真环境中验证

当前端到端流程

结合当前代码，系统的实际处理链路是：

1. 自然语言意图输入
2. 意图翻译为 Policy IR
   • 入口：
     • agents/intent_translation_agent.py
   • 输出：
     • 一条意图可能对应一条或多条 Policy
3. 为策略集绑定标识
   • 入口：
     • utils/policy_identity.py
   • 结果：
     • 同一次意图翻译出的策略共享同一个 intent_id
     • 每条策略分配稳定的 policy_id
4. 单意图内部冲突检测
   • 入口：
     • agents/conflict_detection_agent.py
     • analyze_single_intent()
   • 目的：
     • 先检查同一意图内部生成的多条策略是否自相矛盾
5. 冲突修复
   • 入口：
     • agents/conflict_repair_agent.py
   • 依赖：
     • rag/knowledge_base.py
6. 修复后再次检测
   • 当前仍优先按单意图内部检测验证
7. 流表验证
   • 当前主要通过：
     • Mininet
     • Ryu
     • ovs-ofctl
   • 正式自动部署器仍未完成

Policy IR 与标识

• 一次请求翻译出的策略集合共享同一个 intent_id
• 每条策略拥有稳定的 policy_id
• 冲突检测首先发生在策略层
• 是否允许整批部署，可结合同一 intent_id 下是否仍存在冲突决定

冲突建模与字段语义

当前系统的冲突检测不是直接对自然语言做判断，而是先把意图翻译成 Policy IR，再基于字段语义做建模、检测和修复。

一条策略的核心字段及含义如下：

字段	含义	在冲突建模中的作用
intent_id	同一次用户意图生成的策略集合标识	用于把多条策略聚合回同一意图，支持按意图视角做部署决策
policy_id	单条策略的稳定标识	用于冲突报告、修复结果和部署输出中的精确引用
match.src_ip	源地址或源网段（CIDR）	决定策略影响哪些源主机或区域
match.dst_ip	目标地址或目标网段（CIDR）	决定策略影响哪些目标主机或服务区
match.src_port	源端口或端口范围	用于区分客户端来源端口特征，通常在精细化匹配时使用
match.dst_port	目标端口或端口范围	常用于区分 Web、DB、视频等业务类型
match.protocol	协议类型，如 TCP、UDP、ICMP	影响两个策略是否命中同一类流量
match.dscp	差分服务码点	用于区分 QoS 类流量
match.vlan_id	VLAN 标识	用于区分二层广播域或租户隔离域
action	策略动作，如 ALLOW、DENY、QOS、REDIRECT、MIRROR、LOG	是行为冲突、冗余冲突判断的核心字段
scope	策略生效节点集合，如交换机、链路或区域对应设备	决定策略是否在同一网络位置发生交集；在你的拓扑里应尽量和真实路径、区域映射绑定
time_window	生效时间窗	只有时间重叠的策略才可能构成直接冲突
priority	优先级，数值越大优先级越高	用于建模遮蔽、覆盖和最终执行顺序
resource_constraints	资源约束，如 bandwidth_mbps、队列、时延目标	是资源冲突和 QoS 修复的重要输入
description	人类可读的策略说明	便于报告、审计和修复解释

冲突建模的基本逻辑

系统当前主要按下面几个维度判断两条策略是否构成冲突：

1. match 是否重叠
   只有当源/目标/端口/协议等条件可能命中同一类流量时，才进入后续冲突判断。

2. scope 是否重叠
   即使两个策略动作相反，只要生效节点完全不同，也不应直接判为同一位置上的冲突。

3. time_window 是否重叠
   如果两条策略在不同时间段生效，通常不构成同时冲突。

4. action 是否语义互斥或重复
   例如 ALLOW/DENY 可能形成行为冲突，同动作且同匹配条件可能形成冗余冲突。

5. priority 是否导致遮蔽或覆盖
   高优先级泛化规则可能遮蔽低优先级的具体例外规则。

6. resource_constraints 是否超过共享资源容量
   多条策略如果同时要求同一瓶颈链路上的带宽，可能构成资源冲突。

与当前拓扑结合时的注意点

• scope 不应长期停留在演示性质的默认值上，后续应尽量和 topology_info.json、runtime_port_map.json、区域映射和路径推导结果绑定。
• 对扩展菱形校园网络拓扑而言，low_bw_path 与 high_bw_path 的选择会直接影响资源冲突判断。
• 如果用户意图缺少关键字段，尤其是 action、源/目标实体、scope、路径偏好、QoS 约束，建议后续引入澄清式追问，而不是一律静默补默认值。

意图翻译实现

当前意图翻译的实现位于：

• agents/intent_translation_agent.py

当前实现方式

1. 优先使用 LLM

• 通过提示词要求模型输出 JSON 数组
• 每个 JSON 对象对应一条策略
• 因此当前实现天然支持：
  • 一条自然语言意图翻译成多条策略

2. 再做结构化解析

• _parse_response() 尝试从 LLM 输出中提取 JSON 数组
• 每个对象再通过 _dict_to_policy() 转成 Policy

3. 失败时走 fallback

• _fallback_parse() 基于关键字做简化解析
• 这是兜底逻辑，不是正式高精度翻译器

当前实现的限制

• 关键字段缺失时，当前实现仍偏向：
  • LLM 猜测
  • fallback 默认补全
• 当前还没有正式的“澄清式追问”机制
• scope 默认值仍偏演示性质，尚未完全拓扑感知

当前默认/回退行为

当前代码里仍然存在一些默认补全行为，例如：

• action 缺失时默认 ALLOW
• priority 缺失时默认 100
• scope 缺失时可能回退到类似 {"switch_1", "switch_2"}
• fallback 中也可能默认生成较宽泛的策略

这意味着：

• 当前系统可以跑通流程
• 但若要做严谨实验，后续仍需要把“关键字段缺失 -> 追问/阻断”的逻辑补上

冲突检测算法实现

当前检测实现主要位于：

• core/detection/engine.py
• agents/conflict_detection_agent.py

一、底层检测引擎

底层仍然是策略级检测引擎，主要分两层：

1. 预筛选

• 函数：
  • prefilter_pair(p1, p2)
• 当前实现依据：
  • Policy.overlaps_with()
• 只要两条策略在以下维度可能重叠，才进入详细检测：
  • match
  • scope
  • time_window

2. 四类核心冲突检测

• 行为冲突 BEHAVIOR_CONFLICT
• 冗余冲突 REDUNDANCY_CONFLICT
• 遮蔽冲突 SHADOWING_CONFLICT
• 资源冲突 RESOURCE_CONFLICT

二、当前新增的意图感知检测

当前代理层已经补充了两阶段检测骨架：

1. analyze_single_intent(policies)

• 先检查同一个 intent_id 下策略集内部是否冲突

2. analyze_intent_aware(policies)

• 先按 intent_id 分组
• 逐组做单意图内部检测
• 只让内部无冲突的策略集进入跨意图检测池

三、当前主工作流实际接入状态

当前 main.py 已经接入：

• 单意图内部优先检测

也就是说当前主工作流不再是“翻译完直接把所有策略摊平检测”，而是：

1. 翻译得到同一意图下的策略集
2. 先检查这批策略内部有没有冲突
3. 修复后再次按单意图内部检测验证

四、当前还没完成的部分

虽然代理层已经有了 analyze_intent_aware()，但目前还没有：

• 多意图批量输入主流程
• 跨意图统一报告输出
• 基于 intent_id 的全局部署决策

所以当前阶段应理解为：

• 单意图内部检测已经落地
• 跨意图检测骨架已加，但主流程未完全接通

从策略到流表：当前实现与缺口

这部分当前是“部分已做、完整闭环未完成”。

已有基础

1. 策略表示层

• 文件：
  • core/policy/models.py
• 负责把策略表示成统一的 Policy IR

2. 规则转换雏形

• 文件：
  • utils/policy_converter.py
• 当前已支持：
  • 把 Policy 转为 OpenFlow 风格的流表项字典
  • 把 scope 中的交换机项展开成 Ryu 风格配置项

3. 拓扑与端口映射基础

• 文件：
  • configs/topology_info.json
  • configs/runtime_port_map.json
• 当前已提供：
  • 区域语义
  • 角色语义
  • 服务语义
  • 交换机相邻端口号
  • low_bw_path / high_bw_path / mirror_path

当前还没有完成的部分

目前系统还没有正式完成：

1. 拓扑感知的规则生成

• 还没有一个正式模块把：
  • Policy IR
  • topology_info.json
  • runtime_port_map.json 组合起来，自动生成逐交换机 OpenFlow 规则

2. 正式部署器

• 还没有一个正式的：
  • flow_rule_generator
  • flow_deployer 之类的模块

3. 控制器接管

• 当前仍未实现适配该校园拓扑的正式业务控制器

当前实际验证方式

因此，当前“从策略到流表”的实际验证方式主要是：

• 人工分析策略语义
• 结合：
  • topology_info.json
  • runtime_port_map.json
• 手工使用：
  • ovs-ofctl add-flow

这也是为什么当前 README 中会把后续工作重点放在：

• 静态流表脚本化
• 路径实验
• Policy IR -> Flow Rules 自动化
• 自定义控制器

快速开始

安装依赖

pip install -r requirements.txt

启动后端和前端

# 启动后端 API
python start_api.py

# 启动前端
python start_frontend.py

默认前端地址：

http://localhost:7860

环境变量配置

在项目根目录创建 .env：

# LLM API（至少配置一个）
SILICONFLOW_API_KEY=sk-your-key
DEEPSEEK_API_KEY=sk-your-key

# Agent
AGENT_MODEL_NAME=deepseek-ai/DeepSeek-V3
AGENT_TEMPERATURE=0.1

# Ryu REST 地址（部署到虚拟机时改成虚拟机 IP）
RYU_CONTROLLER_URL=http://<虚拟机IP>:8080

研究说明

1. 代码是否只适用于固定示例

不是。当前实现是通用的。

• Policy IR 支持 src_ip、dst_ip、src_port、dst_port、protocol、action、scope、priority、resource_constraints 等字段
• 冲突检测逻辑基于 Policy IR 语义，不依赖特定主机名
• 部署到仿真网络时，如果使用主机名，需要和仿真拓扑中的主机映射一致

2. 冲突检测实验适合什么拓扑

建议在固定拓扑上做实验，以保证结果可复现。

当前项目已经补充了一个专门用于策略冲突验证的拓扑：

• topologies/extended_diamond_campus.py
• configs/topology_info.json
• docs/topology_description.md

这个拓扑适合验证：

• 行为冲突
• 冗余冲突
• 遮蔽冲突
• 资源冲突

3. RAG 与 Agent Memory 的区别

概念	含义	本项目中的实现
RAG 知识库	外部知识存储，通过检索增强生成	rag/knowledge_base.py，存储规则与案例，供修复阶段检索
Agent Memory	对话或会话历史	当前主流程未专门实现多轮对话记忆

建议理解为：

• RAG：持久化知识，用于修复时参考
• Agent Memory：多轮对话上下文，用于持续交互

4. RAG 知识库里放什么

建议放两类内容：

• 策略规则
• 历史修复案例

当前默认内容定义在：

• rag/knowledge_base.py

5. 论文或实验建议采集的指标

类别	指标	说明
LLM 调用	Token 消耗	统计输入 / 输出 token
LLM 调用	API 调用次数	每次请求调用模型的次数
性能	端到端时延	从请求到返回的总耗时
性能	各阶段耗时	意图翻译、检测、修复、部署耗时
效果	意图翻译成功率	是否正确生成 Policy IR
效果	冲突检测准确率 / 召回率	与人工标注对比
效果	冲突修复成功率	修复后剩余冲突数量
效果	修复迭代次数	达到无冲突所需轮数
部署	策略下发成功率	是否成功写入 Ryu / OVS

项目结构

conflict-detection/
├── api/                 # FastAPI 后端
├── frontend/            # Gradio 前端
├── core/
│   ├── policy/          # Policy IR 模型
│   └── detection/       # 冲突检测引擎
├── agents/              # 各类 Agent
├── rag/                 # RAG 知识库
├── simulation/          # Ryu / Mininet 接口
├── utils/               # 配置、日志、转换工具
├── topologies/          # Mininet 拓扑脚本
├── configs/             # 拓扑静态信息与运行时映射
├── docs/                # 说明文档
├── main.py              # 主工作流
├── start_api.py         # 启动 API
└── start_frontend.py    # 启动前端

冲突类型

类型	枚举	说明
行为冲突	BEHAVIOR_CONFLICT	预筛选后动作互斥，如 ALLOW/DENY、DENY/QOS
冗余冲突	REDUNDANCY_CONFLICT	同动作下完全重复，或被同优先级规则完全覆盖
遮蔽冲突	SHADOWING_CONFLICT	高优先级泛化规则遮蔽低优先级具体规则
资源冲突	RESOURCE_CONFLICT	多条策略对同一资源的总需求超过容量

仿真网络

项目支持 Mininet + Ryu 仿真验证，详见：

• docs/SIMULATION_GUIDE.md
• docs/topology_description.md

扩展菱形校园网络拓扑

新增拓扑：

• topologies/extended_diamond_campus.py

静态拓扑信息：

• configs/topology_info.json

拓扑说明：

• docs/topology_description.md

该拓扑保留：

• RemoteController 127.0.0.1:6633
• OVSSwitch
• OpenFlow13

拓扑启动后会自动导出：

• configs/runtime_port_map.json

该文件记录交换机到相邻节点的运行时端口号，便于后续把修复后的 Policy IR 转换为具体 OpenFlow output 端口。

当前版本已经从原始 8 交换机、8 主机扩展为 10 台交换机 + 12 台主机，共 22 个节点，新增内容包括：

• 访客区：s9、h_guest
• 实验室区：s10、h_lab1、h_lab2
• 文件服务器：h_file

扩展后更适合验证：

• 访客区与学生区的差异化访问控制
• 实验室设备与实验室学生主机的差异化授权
• 文件服务器大流量业务的 QoS 与资源冲突
• 在 low_bw_path 与 high_bw_path 之间做显式路径选择

当前拓扑的地址设计采用“双层语义”：

• Mininet 主机运行时统一使用 /8，保证在无 LinuxRouter 的情况下维持二层可达
• topology_info.json、Policy IR 语义映射和冲突检测建模仍保留各区域的逻辑 /24 前缀

例如：

• 运行时：h_stu1 = 10.0.1.1/8
• 语义分区：student_zone = 10.0.1.0/24

当前拓扑中的语义配置建议按三层理解：

• zone：网络区域，例如 student_zone、staff_zone、server_zone
• role：主机或访问主体身份，例如 teacher_role、admin_role、guest_role
• service：服务器业务类型，例如 web_service、db_service、cache_service、file_service

其中：

• h_teacher 和 h_admin 现在同属 staff_zone
• 二者通过 teacher_role 和 admin_role 区分身份语义
• h_lab1 统一描述为“实验室用户主机”，与 h_lab2 的设备角色区分开

使用边界

• Mininet 拓扑只负责提供虚拟网络
• simple_switch_13 只适合基础连通性测试
• 正式的 ALLOW、DENY、QOS、REDIRECT、MIRROR、LOG 需要由自定义 Ryu 控制器或 ovs-ofctl 静态流表下发
• 路径选择实验不能依赖 simple_switch_13
• 路径、区域和端口映射信息保存在 topology_info.json 与 runtime_port_map.json

当前进展

已完成

以下内容已经完成，并且在当前项目文件中可以对应到具体实现：

• Policy IR 基础模型、冲突检测流程、RAG 修复主流程已经具备基础可运行版本
• 自然语言意图翻译阶段已经支持：
  • 一条意图翻译成多条策略
  • 同一批翻译结果共享同一个 intent_id
  • 每条策略绑定稳定的 policy_id
• 已新增并扩展 Mininet 校园拓扑为 10 台交换机 + 12 台主机，共 22 个节点
• 已保留并验证基础控制平面：
  • RemoteController 127.0.0.1:6633
  • OVSSwitch
  • OpenFlow13
• 已实现运行时端口映射导出：
  • configs/runtime_port_map.json
• 已完成当前拓扑的语义配置整理：
  • staff_zone 替代 teacher_zone / admin_zone
  • 新增 roles
  • 新增 services
• 已明确采用“双层地址语义”设计：
  • 运行时主机地址统一 /8
  • 逻辑分区前缀保留 /24
• 已在 Mininet 中完成的验证包括：
  • 22 节点拓扑能够启动
  • 10 台交换机能够注册到 Ryu 控制器
  • runtime_port_map.json 能正常导出
  • 主机运行时 /8 地址已抽查确认
  • 在显式静态流表下，s5 上 h_stu1 <-> h_stu2 可以成功互通
• 冲突检测逻辑已经补充了单意图内部优先检测：
  • agents/conflict_detection_agent.py 中新增了 analyze_single_intent()
  • 当前工作流在修复前、修复后都会先检测同一 intent_id 下策略集内部是否冲突
• 冲突检测代理已经补充了跨意图检测骨架接口：
  • analyze_intent_aware()
  • 当前实现会先按 intent_id 分组，再只让内部无冲突的策略集进入跨意图检测池
  • 这一能力目前已在代理层实现，但尚未接入完整的多意图主工作流入口

当前已验证结论

当前可以确认的结论如下：

• 拓扑结构本身可用，22 节点扩展没有破坏基础启动流程
• 控制器环境可用，但当前仍是基础控制器环境，不是正式的业务控制器
• simple_switch_13 适合验证交换机注册和基本学习行为，但不足以作为正式策略实验控制器
• 当前主工作流已经从“直接检测一组策略”收紧为：
  • 先检测单意图内部策略集
  • 修复后再次按单意图内部检测验证
• 当前还没有形成“多意图批量输入 -> 跨意图统一检测 -> 统一修复”的完整工作流
• 跨区域通信与路径选择实验，后续应依赖：
  • 显式 ovs-ofctl 静态流表下发
  • 或自定义控制器逻辑

当前代码逻辑概览

结合当前文件，主流程和关键模块可以概括为：

1. 意图翻译

• 文件：
  • agents/intent_translation_agent.py
  • utils/policy_identity.py
• 当前逻辑：
  • 自然语言意图先翻译为 Policy IR
  • 一条意图可能生成多条策略
  • 这些策略会共享同一个 intent_id
  • 每条策略会绑定稳定的 policy_id

2. 冲突检测

• 文件：
  • core/detection/engine.py
  • agents/conflict_detection_agent.py
• 当前逻辑：
  • 底层检测引擎仍然基于策略级两两比较
  • 已存在 prefilter_pair()，按 match / scope / time_window 做预筛选
  • 当前主工作流先做单意图内部冲突检测
  • 检测代理已支持“意图感知两阶段分析”，但多意图入口还未接通

3. 冲突修复

• 文件：
  • agents/conflict_repair_agent.py
  • rag/knowledge_base.py
• 当前逻辑：
  • 对已检测出的冲突生成修复方案
  • 修复后再次调用冲突检测验证
  • 当前仍以“单次输入意图 -> 修复 -> 再检测”为主

4. 仿真拓扑与部署基础

• 文件：
  • topologies/extended_diamond_campus.py
  • configs/topology_info.json
• 当前逻辑：
  • 22 节点拓扑已固定
  • 运行时主机地址统一 /8
  • 逻辑区域前缀保留 /24
  • 启动后自动导出 runtime_port_map.json

5. 控制平面

• 当前已有：
  • Ryu + simple_switch_13 + ofctl_rest
• 当前没有：
  • 适配该校园拓扑的正式业务控制器
• 当前定位：
  • 控制器只用于交换机注册、基础学习、REST 查询
  • 正式实验仍应依赖显式流表或后续自定义控制器

待完成工作

以下工作仍然没有完成，后续需要继续推进：

1. README / 文档之外的语义一致性收口

• 继续检查 configs/topology_info.json、docs/topology_description.md 在不同环境下的编码显示是否一致
• 必要时统一清理文档编码与显示问题

2. 拓扑实验规则脚本化

• 目前验证主要依赖在 mininet> 中手工执行 ovs-ofctl add-flow
• 后续应整理成可重复执行的脚本或部署模块，避免每次重启后重新手工输入

3. 多意图主工作流接入

• 当前 ConflictDetectionAgent 已有跨意图检测骨架接口

• 但 main.py 仍然是单意图入口

• 后续需要补：

  • 多意图输入格式
  • 多意图聚合
  • 内部冲突与跨意图冲突分开输出
  • 基于 intent_id 的部署决策
  4. 跨区域路径实验
  • 当前只完成了 s5 本地双向互通的显式流表验证
  • 还需要完成：
    • h_stu1 -> h_web 走 low_bw_path
    • h_stu1 -> h_web 走 high_bw_path
    • h_guest -> h_web
    • h_lab1 -> h_file
  5. 最小修复器增强
  • 当前修复器的真实能力仍然偏弱：
    • 行为冲突和遮蔽冲突主要通过轻量调整 priority 兜底
    • 冗余冲突和资源冲突还没有真正完成自动修复
  • 后续计划补一套确定性最小修复规则，作为正式待做项：
    • 行为冲突
      1. 先比较 priority
      2. 如果高优先级策略本身是更具体的例外策略，则优先保留
      3. 对低优先级策略优先尝试做 scope / time_window / match 切分
      4. 只有切分失败时，才把调优先级作为兜底动作
    • 冗余冲突
      1. 完全相同的策略仅保留一条
      2. 同动作覆盖关系下，允许做简单合并
      3. 对无额外语义差异的被覆盖策略，标记删除或 inactive
    • 遮蔽冲突
      1. 明确标记哪条策略被更高优先级策略完全覆盖
      2. 优先尝试缩小作用域、调整时间窗、细化匹配条件或提升优先级
      3. 若仍不可达，则将被遮蔽策略标记为 inactive
    • 资源冲突
      1. 先尝试重新选路，例如在 low_bw_path 与 high_bw_path 之间切换
      2. 再尝试按 priority 分配
      3. 再尝试 weighted fair sharing
      4. 最后才做 SLA 降级或拒绝低优先级策略
  • 这一阶段的目标是把修复器从“只会简单改优先级”提升到“可解释、可复现、和拓扑绑定的最小修复”
  6. Policy IR 到流表的正式映射模块
  • 当前还没有完善的 Policy IR -> OpenFlow 规则 自动生成与部署流程
  • 后续需要补：
    • flow_rule_generator
    • flow_deployer
    • 或等价的批量部署脚本
  7. 自定义控制器逻辑
  • 当前不计划立刻实现
  • 后续在拓扑和规则部署稳定后，再编写适配该校园拓扑的控制器代码
  8. 冲突检测实验闭环
  • 后续还需要把：
    • 自然语言意图
    • Policy IR
    • 冲突检测
  • 冲突修复
  • 流表部署
  • Mininet 验证 串成完整闭环实验

当前阶段建议的工作顺序

建议按下面顺序推进，而不是并行混做：

1. 先把 22 节点拓扑的基础验证做稳定
2. 再把静态流表部署整理成可重复执行的脚本
3. 再完成 low_bw_path / high_bw_path 的路径实验
4. 再把多意图入口和跨意图检测接入主工作流
5. 再增强最小修复器，使修复不再只依赖简单 priority 调整
6. 然后再接入冲突检测与修复后的策略部署
7. 最后再实现自定义控制器

Ubuntu 虚拟机 / VMware 使用补充

如果你是在 Ubuntu 虚拟机中运行 Mininet / Ryu，并通过 VMware 共享文件夹访问代码，建议按下面方式操作。

1. 进入 Python 虚拟环境

当前实验环境中，Ryu 虚拟环境路径记录为：

source ~/venvs/ryu38/bin/activate

成功后，提示符前会出现：

(ryu38)

2. 共享文件夹根目录

VMware 共享目录常见挂载位置：

/mnt/hgfs

如果系统启动后 /mnt/hgfs 为空，先手工重新挂载：

sudo mkdir -p /mnt/hgfs
sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid=$(id -u) -o gid=$(id -g)
ls /mnt/hgfs

如果之前挂载异常，也可以先卸载再重新挂载：

sudo umount /mnt/hgfs
sudo vmhgfs-fuse .host:/ /mnt/hgfs -o allow_other -o uid=$(id -u) -o gid=$(id -g)

定位项目目录：

cd /mnt/hgfs
find /mnt/hgfs -maxdepth 3 -type d -name "conflict-detection"

3. 启动控制器

ryu-manager ryu.app.simple_switch_13 ryu.app.ofctl_rest

4. 验证控制器 REST

curl http://127.0.0.1:8080/stats/switches

5. 启动默认 Mininet 拓扑

sudo mn --controller=remote,ip=127.0.0.1,port=6633 --switch ovsk,protocols=OpenFlow13

6. 启动扩展菱形校园网络拓扑

先进入项目目录，再执行：

sudo python3 topologies/extended_diamond_campus.py

7. 验证新拓扑

进入 mininet> 后先执行：

nodes
net
sh cat configs/runtime_port_map.json

如果要在 mininet> 里调用 Ubuntu shell 命令，需要加 sh，例如：

sh ovs-ofctl -O OpenFlow13 show s1

更多文档

文档	说明
docs/SIMULATION_GUIDE.md	Mininet / Ryu 仿真环境使用说明
docs/CONFLICT_ALGORITHM.md	冲突检测算法说明
docs/DEVELOPMENT_NOTES.md	开发笔记
docs/topology_description.md	扩展菱形校园网络拓扑说明

常见问题

1. LLM 调用失败

检查 .env 中的 API Key 是否正确。

2. Ryu 连接失败

检查：

• ryu-manager 是否已启动
• RYU_CONTROLLER_URL 是否正确
• ofctl_rest 是否已加载

3. Mininet 部署失败

检查：

• sudo mn -c 是否已执行
• OVS 是否正常
• 交换机协议是否为 OpenFlow13

4. 在 mininet> 中执行 shell 命令报错

在 mininet> 中执行 Ubuntu shell 命令时，需要加 sh：

sh ovs-ofctl -O OpenFlow13 show s1