关键在于桥、端口、流表三者对齐：ovs-vsctl add-br创建网桥后需用show确认状态，internal端口须配netns和promisc，流表下发前须验证OpenFlow版本与dpid，VXLAN隧道需双向配置remote_ip并开放UDP 8472。
直接上手配置 OVS 实现 SDN 网络，关键不是“装完就行”，而是桥、端口、流表三者必须对齐：桥是容器，端口是入口/出口，流表才是真正的控制逻辑。跳过流表只建桥和端口，等于搭好马路却没红绿灯——车能跑，但没法调度。
ovs-vsctl add-br 创建网桥后必须确认状态
执行 ovs-vsctl add-br ovs-br0 只是写入数据库，不等于网桥已就绪。常见错误是立刻配 IP 或加端口，结果报 Device "ovs-br0" does not exist。
- 必须用
ovs-vsctl show查看输出中是否出现Bridge "ovs-br0"块，且无is_connected: false - 若缺失，检查
systemctl status openvswitch是否 active（running），尤其 Ubuntu 20.04 安装后常需手动systemctl daemon-reload再 start - 不要给网桥本身配 IP（如
ip addr add），除非你明确要宿主机走该桥通信；否则应把物理网卡（如ens33）以type=patch或直接add-port方式接入桥
internal 类型端口必须配合 netns 使用，否则无法通信
type=internal 的端口（如 p0）本质是内核创建的虚拟网卡，但默认处于 host network namespace，会与宿主机路由冲突。直接 ifconfig p0 up 后 ping 不通是常态。
动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。
- 必须用
ip netns add ns0创建独立网络命名空间 - 用
ip link set p0 netns ns0将端口移入，再进ip netns exec ns0配置 IP 和 promisc 模式 - 若漏掉
ifconfig p0 promisc up，即使 IP 正确，OVS 数据面也无法收包（ovs-appctl dpif/show中可见dropped计数上涨） - 验证连通性务必用
ip netns exec ns0 ping 192.168.0.101，而非宿主机直接 ping
ovs-ofctl 添加流表前先确认 OpenFlow 版本和 datapath ID
流表不生效最常见原因是协议版本错配或目标交换机识别错误。比如在 Mininet 里启动的 s1 和手动 ovs-vsctl add-br 创建的 ovs-br0 是两个完全独立的 datapath。
- 先运行
ovs-ofctl -O OpenFlow13 show ovs-br0，确认输出含dpid:字段且无failed to connect - 若提示
connection refused，说明 ovs-vswitchd 未启用 OpenFlow 接口，需检查ovs-vsctl get-manager是否为空；空则需ovs-vsctl set-manager ptcp:6640（仅测试环境） - 下发流表时，
in_port值必须是 OpenFlow 端口号（即ofport_request设置值），不是 Linux 接口名；例如p0设了ofport_request=100，流表就得写in_port=100，写in_port=p0会静默失败 - 测试基础转发时，优先用
ovs-ofctl -O OpenFlow13 dump-flows ovs-br0看是否真有流存在，别只信命令返回“success”
VXLAN 隧道端口必须双向配置 remote_ip，且防火墙放行 UDP 8472
单边配 options:remote_ip=192.168.190.130 只能发包不能收，因为 VXLAN 解封装依赖对端 IP 回填到外层 IP 头。实测中 70% 的隧道不通问题出在这里。
- 主机 A 配
remote_ip=192.168.190.130，主机 B 就必须配remote_ip=192.168.190.128（A 的实际 IP） - 两台宿主机均需开放 UDP 8472 端口：
ufw allow 8472/udp（Ubuntu）或firewall-cmd --add-port=8472/udp --permanent（CentOS） - 用
tcpdump -i any port 8472在对端抓包，若只有发包无收包，基本可断定 remote_ip 配错或防火墙拦截 - VXLAN 接口上线后，
ovs-vsctl show中该端口状态应为status: {tunnel_egress_iface="ens33", tunnel_egress_iface_status="up"}，若显示down则物理链路或 IP 配置有误
真正卡住人的地方往往不在命令语法，而在 datapath 与 OpenFlow 控制面之间的隐式契约：ovs-vsctl 管配置，ovs-ofctl 管流表，两者操作对象必须是同一个 bridge 实例；而 netns、VXLAN、OpenFlow 版本这些细节，任何一个错位都会让整个控制逻辑静默失效——它不报错，只是不工作。
