Ubuntu 18.04下Mininet与RYU的SDN实验环境搭建全记录

前几天把工作台角落那台旧笔记本重新刷成了 Ubuntu 18.04，目的很纯粹：把它改造成一台 SDN 实验机。要装的软件也早就定好了——Mininet 负责在单机上模拟出各类网络拓扑，RYU 控制器负责接上这些交换机、按逻辑下发流表。这个组合在 SDN 学习和控制器开发里出现频率极高，身边要动手做实验的同学，十有八九都会碰到同一套流程。可实际上手之后才发现，安装步骤看着简单，真正容易卡住的地方却一个都不少：Python 版本对不对、依赖库编不编译得过、Open vSwitch 起来没有，随便哪个环节出问题，最后都表现为“控制器连不上”。这篇文章把我从零安装到联动调试的全过程按顺序写下来，包括每一步为什么要这么做、常见问题怎么定位，适合想自己动手搭 SDN 环境而不是直接下载现成镜像的读者。

1. 为什么 Ubuntu 18.04 + RYU + Mininet 仍是很多 SDN 实验的默认组合

1.1 这套组合到底在模拟什么

先把三者分工说清楚，后面排查问题才能找到方向。RYU 是一个用 Python 编写的开源 SDN 控制器，它向下通过 OpenFlow 协议和交换机通信，向上给应用层提供编程接口。你可以把 RYU 理解成“网络大脑”：交换机会把未知目的地的包交上来，控制器根据网络状态决定怎么处理，然后向交换机下发流表。Mininet 则是一个网络仿真工具，它利用 Linux 命名空间和虚拟网卡，在一台物理机上同时跑出多台主机、多个交换机和多条链路。最妙的是它仿真的不是“逻辑模拟”，而是让数据包真正经过内核网络协议栈，所以实验效果很接近真实环境。

Ubuntu 18.04 在这里的角色是底座系统。很多 SDN 教材、课程实验甚至论文复现，给的默认前置条件都是这个版本。为什么这么执着？因为它默认自带的 Python 3.6，恰好落在 RYU 依赖库兼容性最好的区间里。装这套环境时你会发现，RYU 本身并不挑剔，挑剔的是它的间接依赖，比如 lxml、greenlet、eventlet 这些 Python 库，它们在较新的 Python 解释器上经常出现编译问题或运行时崩溃。而 Python 3.6 对这些库来说是一个经过大量验证的组合，装起来顺滑得多。

1.2 为什么在这个版本上最省心

有些读者可能会问：为什么不用更新的 Ubuntu 22.04 或 24.04？我也试过，结论是能装，但折腾成本明显上升。较新系统默认的 Python 3.10+ 环境下，RYU 安装时经常遇到eventlet或greenlet版本冲突，有时候 pip 能装上，一运行ryu-manager就报内部导入错误，排查起来非常绕。反过来，Python 3.6 虽然“老”，但 RYU 的生态几乎就是围绕这一代 Python 成长起来的，依赖关系干净，踩坑概率低得多。

这里还要说一个现实因素：很多 SDN 相关的 OpenFlow 实验，用的交换机模型默认就是 OpenFlow 1.3，而 RYU 对 OpenFlow 1.3 的支持非常成熟，典型例子就是它自带的simple_switch_13应用。你要是在新系统上装 RYU，光让 OpenFlow 1.3 跑通平滑，可能就得先解决一遍依赖地狱。所以我的建议很直接：如果你只想把精力花在 SDN 本身，而不是浪费在环境兼容性上，Ubuntu 18.04 这套经典组合是最稳妥的选择。当然，18.04 的标准支持周期已经结束，如果你只是把它当成隔离的实验环境、不暴露公网，用来做学习和开发问题不大。

2. 环境准备：更新系统、Python 版本和 pip 指向

2.1 装完系统后的第一轮 apt 更新

新系统到手别急着装 Mininet，先把基础软件源和系统包刷新一遍，避免后面安装时因为索引太旧而拉不到正确版本的软件包。

sudo apt update sudo apt upgrade -y sudo reboot

这一步没什么技术含量，但非常值得做。尤其是装完系统后隔了很长时间才开箱的情况，不更新的话，Mininet 可能从旧索引里装到一个有已知问题的版本，白给自己添堵。

更新完继续装基础工具，Python 开发头文件一定要装，否则后面 RYU 的依赖在编译时会直接报缺少头文件：

sudo apt install -y git net-tools python3-pip python3-dev vim

这里逐个说明用途：git用于拉取 Mininet 源码，net-tools提供ifconfig等传统网络工具，python3-dev是 Python 扩展编译必须的头文件包，vim纯粹是方便改配置文件。python3-dev最容易被忽略，但少了它，pip 安装 lxml 时一定会失败。

2.2 先摸清楚 python、python3 与 pip、pip3 的区别

Ubuntu 18.04 的默认环境里，python命令通常指向 Python 2.7，python3指向 Python 3.6。这点看起来基础，但实际是很多安装失败的根源。如果你习惯性地敲python --version，看到的是 2.7，又下意识地用pip装包，那所有包都会进到 Python 2 的环境里，后面ryu-manager自然用不上。

建议先确认一下当前状态：

python --version python3 --version pip --version pip3 --version

正常情况下，pip指向 Python 2 的包管理，pip3指向 Python 3.6 的包管理。在 Ubuntu 18.04 上装 RYU，请始终使用pip3，后面启动 RYU 也使用python3环境下的命令。

还有一点要提醒：不要轻易去改系统里 Python 的软链接，比如把默认的python指到python3。网上很多教程会教你用update-alternatives切换，但 Ubuntu 系统底层很多脚本依赖默认 Python 版本，改完经常出现apt都跑不起来的情况。如果你只是想用 Python 3.6 跑 RYU，直接用python3和pip3就够了，没必要全局替换。

2.3 要不要给 RYU 单独建虚拟环境

我个人的建议是：建一个。原因很简单，RYU 的依赖数量不少，直接往系统环境里装，以后你再装其他 Python 项目，很容易把某个依赖版本顶掉，反过来又把 RYU 弄挂。用虚拟环境隔离掉，省心很多。

创建并启用：

python3 -m venv ~/ryu-venv source ~/ryu-venv/bin/activate

激活后，命令行提示符前面会出现(ryu-venv)之类的标记。后续所有 RYU 的安装和启动命令都在这个环境里执行。为了少一层权限麻烦，虚拟环境里的pip不需要sudo，这一点也避免了很多新手因为sudo pip导致的环境错乱。

这里也顺带回应一个常见疑惑：Mininet 和 RYU 不在同一个环境里，能联动吗？完全可以。Mininet 起的是系统级虚拟网络设备，RYU 只需要通过 TCP 端口 6633 跟交换机通信，两者之间的交互走网络协议，与 Python 环境是否隔离无关。

3. Mininet 安装：三种途径与我的最终选择

3.1 apt 直接安装：快，但版本偏旧

最省事的安装方式当然是 apt：

sudo apt install -y mininet

装完用mn --version看版本。Ubuntu 18.04 仓库里的 Mininet 版本通常偏旧，日常教学实验其实够用，因为它默认带上了 Open vSwitch、xterm 等核心组件。但它的缺点也很明显：有些辅助脚本和较新的拓扑命令没有，想复现某些论文实验时可能缺功能。如果你只是跑通 SDN 流程、验证 RYU 的行为，apt 版本完全没问题。

另外一个需要注意的点是，apt 安装 Mininet 不一定自动帮你装好 Open vSwitch 的完整服务和工具。我遇到过装完 Mininet 后启动拓扑提示找不到ovs-vsctl的情况。稳妥起见，顺手把 Open vSwitch 也装一遍：

sudo apt install -y openvswitch-switch

3.2 源码安装：可控，但耗时

如果需要更新的 Mininet 版本，或者想自定义内核模块，可以从源码安装：

git clone https://github.com/mininet/mininet.git cd mininet git checkout 2.3.0 sudo util/install.sh -a

install.sh -a会安装 Mininet 的全部组件，包括 Open vSwitch、无线模拟支持等。这个脚本跑起来比较久，期间要编译不少东西，而且会安装系统级依赖，中途不要随便中断。它的优点是版本可控、组件完整，后续需要二次开发时更顺手。

在实际操作中，我一般更推荐一个中间的取舍：环境对 Mininet 版本没有特殊要求时，直接用 apt 安装；如果明确要复现某个仓库示例、或需要最新 OVS 特性，再选源码安装。实验环境的稳定性比版本新更重要。

3.3 装完怎么验证 Mininet 真的能跑

装完 Mininet 后，先跑一个最简单的自检测试：

sudo mn --test pingall

这条命令会创建一个默认拓扑（两台主机连一台交换机），然后让两台主机互相 ping。如果环境正常，最后会看到类似下面的结果：

*** Ping: testing ping reachability h1 -> h2 h2 -> h1 *** Results: 0% dropped (2/2 received)

看到 0% dropped，说明 Mininet 和底层 Open vSwitch 已经正常工作。这一步很关键，千万别跳过。很多问题在自测阶段就会暴露，比如内核模块没加载、OVS 服务没起来等，提前发现总比后面混合在一起排查容易。

4. RYU 控制器安装：依赖处理与启动验证

4.1 在虚拟环境里用 pip 安装 RYU

确保前面创建的虚拟环境已经激活，然后安装 RYU：

pip install ryu

如果要固定版本，可以指定pip install ryu==4.34。在 Python 3.6 环境下，这个命令会拉到 RYU 的依赖，包括lxml、greenlet、eventlet、routes等。

如果你的网络访问 PyPI 较慢，可以临时使用国内镜像源，比如：

pip install ryu -i https://pypi.tuna.tsinghua.edu.cn/simple

安装过程中最容易出的问题就是lxml编译失败。lxml 需要编译原生扩展，缺编译依赖就会报错。尽量在安装 RYU 前先把编译环境补齐：

sudo apt install -y libxml2-dev libxslt1-dev

装完这两个再回来装 RYU，会顺畅很多。

4.2 源码安装方式的补充

有些时候你拿到的 RYU 版本在 PyPI 上没有，或者你想跑仓库里的最新分支，那就走源码安装：

git clone https://github.com/faucetsdn/ryu.git cd ryu python setup.py install

源码安装的核心好处是能直接查看 RYU 自带的示例应用目录，在ryu/app/下能看到simple_switch_13.py、simple_switch_1.py、rest_router.py等大量现成控制器应用。偶尔排查问题时，直接打开源码里的这些文件看逻辑，比对着文档猜要快得多。

4.3 启动简单交换应用验证 RYU

安装完成后，先确认命令可用：

ryu-manager --version

正常会输出类似ryu-manager 4.34的版本号。如果提示找不到命令，多半是虚拟环境没激活，或者 pip 安装路径没有加入 PATH。

版本没问题后，启动 RYU 自带的二层学习交换应用：

ryu-manager ryu.app.simple_switch_13

启动日志里会显示加载了哪些应用，包括ryu.app.simple_switch_13和ryu.controller.controller等模块，并默认监听 6633 端口。如果你看到终端卡在“等待交换机接入”的状态，说明 RYU 已经正常运行，正在等你从 Mininet 那边创建拓扑。

这里有一个很容易误判的点：RYU 启动后如果一直没有任何交换机连接，它是不会报错的，就那么静静等着。所以不要误以为没反应就是没启动成功，确认端口监听状态会更靠谱：

sudo lsof -i:6633

或者：

ss -lnt | grep 6633

能看到监听中的6633端口，就说明控制器这边已经完全就绪。

5. 让 Mininet 里的交换机连上 RYU：从流表看联动

5.1 先启动控制器，再启动拓扑

RYU 和 Mininet 联动的核心，是让 Mininet 里的 Open vSwitch 启动后主动去连接 RYU，而不是自己用内置控制器。所以顺序很重要：先启动 RYU，再启动 Mininet。

保持第一个终端运行着ryu-manager ryu.app.simple_switch_13，打开第二个终端，输入：

sudo mn --topo linear,3 --controller=remote,ip=127.0.0.1,port=6633 --switch=ovs,protocols=OpenFlow13

这条命令创建了一个包含三台交换机、三台主机的线性拓扑。关键是--controller=remote,ip=127.0.0.1,port=6633，它告诉交换机要连接本机上 6633 端口的控制器。--switch=ovs,protocols=OpenFlow13则明确交换机走 OpenFlow 1.3 协议，这样能和 RYU 的simple_switch_13应用匹配上。

如果你在旧的 Mininet 版本中省略了protocols=OpenFlow13，经常会出现“控制器连接上了，但流表始终不生成”的诡异情况。本质是 OpenFlow 协议版本协商不一致，RYU 用 1.3 在等，交换机却试图用 1.0 或旧版协议握手。这个参数最好每次都带上。

5.2 在 Mininet 里发起 pingall

Mininet 启动成功后，终端会进入交互式 CLI，提示符变成mininet>。此时你未必看得到 RYU 那边有明显日志，因为simple_switch_13是一个安静的应用，它不会每收到一个包就打印一行。真正验证联动成功的方式是数据通没通。

在 mininet 交互界面里执行：

mininet> pingall

如果一切正常，结果会是三台主机之间全部可达，丢包率 0%。这时候别急着开心，再去看看流表，确认这不是偶然的网络直通。

5.3 用 ovs-ofctl 确认流表已下发

数据通了的背后，是 RYU 真的接管了交换机，并且把相应的流表写入了 Open vSwitch。我们可以直接在系统层面查看：

sudo ovs-ofctl dump-flows s1

输出里能看到类似这样的流表项：

cookie=0x0, duration=12.345s, table=0, n_packets=3, n_bytes=252, priority=0 in_port=1,dl_dst=... actions=output:2

这行记录的意思是：交换机收到从端口 1 进来的数据包，如果目的 MAC 地址匹配到了某个主机，就把包从端口 2 转发出去。这正是 RYU 的simple_switch_13应用通过学习 MAC 地址后下发的流表。看到这些条目，才说明 RYU 和 Mininet 的链路真正打通了。

第一次 ping 时，有些包会送到控制器去处理，所以流表可能是在前几个包之后才生成。如果你想看“控制器实时学习”的过程，可以先在 Mininet 里执行h1 ping h2，立刻去dump-flows s1，大概率能看到刚刚生成的流表。

5.4 收尾清理：mn -c 的作用

实验做完不要直接关终端，先用 Mininet 的清理命令恢复环境：

mininet> exit

退出后再执行：

sudo mn -c

mn -c会把拓扑残留的虚拟网卡、命名空间、临时进程全部清掉。这一步很重要——不清理的话，下次再启动拓扑可能提示端口被占用或ovs网桥残留，尤其是反复调试的时候，残留越多越容易出怪问题。

6. 安装过程中绕不开的几个坑

6.1 lxml 编译卡住与编译依赖缺失

这是 RYU 安装阶段出现频率最高的问题。报错内容通常是lxml在安装时编译失败，或者长时间卡在 Building wheel。原因很直接：lxml 需要 C 库头文件，系统里没装libxml2-dev和libxslt1-dev，它就编不过去。解决方式前面已经说过，安装前先把编译依赖补齐。另外，在 Python 3.6 环境下，尽量不要强行使用最新的 lxml 版本，Ryu 的依赖会自动锁定一个兼容版本，让 pip 自己去解析就好。千万不要手动去装一个最新版 lxml 再回来装 RYU，那样反而可能把依赖关系搞乱。

6.2 apt_pkg 模块丢失

如果你在装完某些 Python 包后，突然发现apt命令报错，提示ModuleNotFoundError: No module named 'apt_pkg'，大概率是系统的 Python 包管理环境被动过了。最常见的原因是你把默认的python软链接改成了python3，导致 apt 依赖的原生模块找不到了，或者是系统中存在多个 Python 版本的apt_pkg包。

解决思路不是去下载python3-apt重新装一下那么简单，核心问题是别再随意给系统 Python 动手术。如果已经出了这个问题，可以尝试：

sudo apt-get install --reinstall python3-apt

但我更建议从源头避免：在 Ubuntu 18.04 上做任何 Python 环境操作，都使用python3 -m pip或虚拟环境，不要修改/usr/bin/python的软链接。

6.3 Open vSwitch 服务没起来

Mininet 启动时如果提示找不到 OVS 或者交换机无法创建，先检查 Open vSwitch 服务状态：

sudo systemctl status openvswitch-switch

如果服务是inactive或failed，启动它：

sudo systemctl start openvswitch-switch sudo systemctl enable openvswitch-switch

这个问题在 apt 安装 Mininet 后尤其常见，因为 Mininet 本身不保证帮你正确启动 OVS 守护进程。安装完openvswitch-switch后，最好手动确认服务已经 active。还有一个相关联的提示：部分虚拟机环境里，Open vSwitch 需要内核模块支持，如果是在虚拟机里跑 Ubuntu，请确保虚拟化配置允许加载这些模块。

6.4 端口被占用、控制器连不上的排查

控制器连不上，先别急着怀疑 Mininet 或 RYU 本身，先确认端口。默认 OpenFlow 端口是 6633，但偶尔会被其他程序占用。查看：

sudo lsof -i:6633

如果发现不是ryu-manager在监听，而是别的进程，那就把它处理掉，或者给 RYU 换一个监听端口：

ryu-manager --ofp-tcp-listen-port 6653 ryu.app.simple_switch_13

对应地，Mininet 那边的连接参数也要改成port=6653。这种灵活切换的方法在多个控制器实验同时跑的场景下非常有用。

还有一个经常搞混的点：控制器连上不等于协议就正确。如果你启动 Mininet 时没指定protocols=OpenFlow13，Open vSwitch 可能用 OpenFlow 1.0 去连接 RYU，RYU 的simple_switch_13能握手成功，但数据路径上会出现“有流量不响应”或者“ping 偶尔通偶尔丢包”的现象。排查的时候，记得把--switch=ovs,protocols=OpenFlow13这个参数考虑进去。

下面把前面提到的几类典型问题整理成一份快速对照表，方便以后排查时直接查阅：

6.5 关于 Ubuntu 18.04 生命周期的一个提醒

最后多说一句。Ubuntu 18.04 的标准支持周期已经结束，这意味着它不会再接收常规安全更新。官方层面的建议确实是升级系统，但在 SDN 实验这种隔离、短暂、不暴露公网的场景里，它仍然有不可替代的价值：依赖兼容性最好、教程资料最全、遇到的问题几乎都能搜到。我的建议是，用来做离线实验、本地开发没有问题，但不要拿它做长期在线服务或者连接不受信任的网络。如果做好了物理隔离，它就是我目前用下来最省心的 SDN 实验底座。

装完这套环境后的真实感受是：SDN 的实验链路并不复杂，折腾基本集中在环境搭建环节。我个人的习惯是先把simple_switch_13这个最小闭环跑通，也就是控制器成功接管交换机、流表能正常下发，再往上叠复杂应用，否则后续排错时很容易分不清是控制器逻辑问题还是环境问题。如果你也卡在某个安装环节，按上面那张表一条条对照，基本都能解决。最后再分享一个小技巧：实验做完，把mn -c和检查 6633 端口有没有残留进程这两个动作养成肌肉记忆，能替你省掉至少一半的“下次打开就出错”的烦恼。