简介：《网络应用设计与系统集成》课程中的Mininet实验报告文档，面向网络工程、SDN入门学习者及需要完成拓扑仿真实验的高校学生，聚焦Mininet环境搭建与拓扑构建的实操记录。资源包共1个doc文件，大小约1.37MB，以实验报告形式整合实验目的、实验内容、技术背景、具体步骤与操作要点，便于直接参考报告结构与实验流程。已有1069人学习下载，具备一定参考热度。文档围绕Miniedit可视化建拓扑、命令行创建、交互式添加主机交换机、节点ping测试展开，并延伸到Python脚本构建linear、single、tree等拓扑及带宽、延迟、队列、丢包率等性能限制设置，附有控制器、交换机、主机配置与拓扑保存运行等环节。适合需要对照实验报告梳理Mininet基本命令、复现拓扑构建过程或补充SDN仿真实验记录的学生与初学者使用。

1. 三种建拓扑的路径摆在面前：miniedit、mn 命令行、Python API 先上哪个

Mininet 这个名字，很多人第一次见是在一份实验报告里：十六页 Word，配图全是截图，步骤写得很细，但真到自己机器上敲第一行sudo mn就开始卡。它解决的事情其实很具体——在一台普通机器上把主机、交换机、链路用进程和虚拟网卡模拟出来，让 SDN 拓扑、OpenFlow 流表、链路参数这些原本要占用机柜才能验证的东西，变成几分钟内可以反复推倒重来的实验。这份资源就是一份完整的 Mininet 拓扑构建实验记录，覆盖可视化建图、命令行建图、交互式加设备、Python 脚本自定义、链路性能限制五段，适合正在做网络课程设计、需要交一份能跑通的实验报告，或者要给团队搭一套 SDN 验证环境的人。

2. miniedit 可视化建拓扑：从画布拖拽到可运行的 Level 2 脚本

先跑可视化工具是有道理的。命令行建拓扑快，但你脑子里那张图和机器里那张图对不对得上，只有画出来才知道。miniedit 的价值不在于"能画图"，而在于它把界面上的每一根连线翻译成addLink()，最后导出一份可以脱离 GUI、直接在终端重放的 Python 脚本——这份脚本才是能进版本库、能贴进报告、能在别的机器上复现的东西。所以这一章的目标不是学会点鼠标，而是把"画出来的拓扑"转成"跑得起来的代码"。

2.1 定位并启动 miniedit：路径、权限和显示环境

miniedit 不是一个装了 Mininet 就自动进 PATH 的命令，它的真身是 Mininet 源码树里的examples/miniedit.py。发行版仓库装的和源码 clone 的，位置不一样，所以第一步不是猜路径，是让它自己报位置。

# 更新文件索引后按文件名找，比盲猜目录靠谱 sudo updatedb locate miniedit.py # 索引没建好或者 updatedb 不可用时，用 find 兜底 sudo find / -name miniedit.py 2>/dev/null # 假设定位到 ~/mininet/examples/miniedit.py，进目录再启动 cd ~/mininet/examples sudo python3 miniedit.py

这三条命令里有两个参数值得盯住。sudo不是习惯性加的：miniedit 建拓扑要创建 veth 对、要操作 Open vSwitch 网桥、要进网络命名空间，这些动作没有 root 会直接在建链路那一步失败，报错往往指向RTNETLINK answers: Operation not permitted，跟 GUI 一点关系都没有。python3则要对上你机器上 Mininet 的实际绑定版本，Mininet 2.3 之后主线支持 Python 3，但部分发行版仓库里的包仍然挂在 Python 2 上，用错解释器会在import tkinter那一行就断掉——注意是 tkinter 不是 Tkinter，Python 3 里全小写了，这是老教程最容易误导人的一处。

启动失败的另一个高频现场是显示环境。通过 SSH 连过去的纯命令行会话里跑 miniedit，会得到no display name and no $DISPLAY environment variable。这不是权限问题也不是安装问题，就是没有图形出口。两种处理：在虚拟机桌面里开终端，或者本地用ssh -X转发并在登录后echo $DISPLAY确认有值。我一般直接在带桌面的虚拟机里做这一段，省掉 X11 转发的延迟和字体缺失。

提示：如果locate和find都找不到，说明装的是精简包，examples 目录没随包安装。这种情况直接把 Mininet 源码仓库 clone 下来，进examples目录跑，不必去改系统包。

2.2 画布上真正要改的三处配置：控制器、交换机、主机

拖一台交换机加两三台主机再连线，这一步谁都会。真正决定后面能不能 ping 通的，是右键 Properties 里的那几项，以及 Edit 菜单下 Preferences 里的全局开关。报告里把配置拆成控制器、交换机、主机、全局四块，顺序是有讲究的——控制器决定流表谁来下发，交换机决定数据面用什么实现，主机决定地址和资源，全局决定导出脚本长什么样。

这里最容易被跳过的是 Preferences 里的 Start CLI。不勾它，导出的脚本末尾就没有CLI(net)，你双击运行或者python3 xxx.py跑完，屏幕上刷完启动日志就结束了，人会以为"拓扑没建起来"，其实建起来了又立刻被net.stop()拆掉了。我见过有人在这上面耗半小时，反复重装 Mininet。

主机 IP 那一栏还有个细节：留空时 Mininet 会按ipBase顺序分配 10.0.0.1、10.0.0.2 这样的地址，顺序取决于主机的创建次序。你在画布上先拖哪台、后拖哪台，会改变导出的addHost顺序，也就改变了 IP 归属。想让 h1 永远是 10.0.0.1，就在 Properties 里写死，别指望自动分配的稳定性。

2.3 Export Level 2 Script：导出的脚本长什么样，怎么读

配完点 File → Export Level 2 Script，得到一个.py文件。这个"Level 2"的含义是脚本里包含完整的构建、启动、CLI、停止四段，属于可以直接执行的级别，不是只描述拓扑结构的片段。导出的内容大致是下面这个骨架，我按实际会出现的结构做了注释：

#!/usr/bin/python from mininet.net import Mininet from mininet.node import Controller, OVSKernelSwitch from mininet.cli import CLI from mininet.log import setLogLevel def createNetwork(): # ipBase 决定自动分配地址的网段，与 GUI 里 Preferences 的设置有对应关系 net = Mininet(topo=None, build=False, ipBase='10.0.0.0/8') # 控制器必须先加，加完才能 addController 绑定 c0 = net.addController(name='c0', controller=Controller, protocol='tcp', port=6633) # 交换机名与画布上的标签一致，端口号按连线顺序递增 s1 = net.addSwitch('s1', cls=OVSKernelSwitch) # 主机地址来自 Properties，没填则是自动分配 h1 = net.addHost('h1', ip='10.0.0.1/8') h2 = net.addHost('h2', ip='10.0.0.2/8') # 每条连线对应画布上的一根线，顺序即端口顺序 net.addLink(s1, h1) net.addLink(s1, h2) return net if __name__ == '__main__': setLogLevel('info') net = createNetwork() net.build() net.start() CLI(net) # 勾了 Start CLI 才会有这一行 net.stop()

读这份脚本要抓三个点。第一，addController的port=6633是 OpenFlow 1.0 的老端口，选 1.3 协议时应该走 6653，导出脚本若不跟着改，会出现交换机连不上控制器、pingall全失败的现象。第二，addLink的调用顺序就是端口编号顺序，s1-eth1对第一台主机，s1-eth2对第二台，后面排查连通性时用net命令看到的端口号和这里必须对得上。第三，ipBase='10.0.0.0/8'这个掩码很宽，主机配10.0.0.1/8意味着整个 10.0.0.0/8 都算直连，跨交换机的机器不需要路由就能通——这在实验里是方便，但在做路由实验时会掩盖问题，该改成/24的时候要改。

跑导出脚本之前记得清理上一次的残留：sudo mn -c。这条命令会删掉遗留的 veth 对、OVS 网桥和命名空间。不清就跑，常见报错是Error creating interface pair或者端口已经被占用，看起来像脚本写错了，其实只是上一轮的尸体没埋。

3. mn 命令行与交互式 py：single/linear/tree 三种骨架怎么选

可视化适合把结构想清楚，命令行适合快速验证一个想法。sudo mn一行就能起一张网，加--topo就能换骨架，加--link就能挂链路参数，这套组合在需要反复试不同拓扑规模时比开 GUI 快得多。而进入 Mininet 交互界面之后用py前缀执行 Python 语句，则是第三条路：不退出、不重启，在运行中的网络上动态加设备。三条路各有适用面，混着用才是常态。

3.1 --topo 参数族：从 minimal 到 linear 的节点对账

--topo后面跟的是内置拓扑类名加参数，参数写错不报错、只是拓扑跟你以为的不一样，所以先把账对清楚。

命令行还有几个参数值得一起带上：

# --mac 让 MAC 地址变成 00:00:00:00:00:01 这种短号，抓包时肉眼可读 # --switch ovsk 指定 Open vSwitch 内核态，性能接近真实网卡 # --controller ovsc 显式指定自带控制器，排除控制器缺失导致的 ping 失败 sudo mn --topo linear,4 --mac --switch ovsk --controller ovsc --link tc,bw=10,delay=5ms

--mac是我强烈建议每次都加的。默认 MAC 是随机生成的十六进制串，Wireshark 里一排6e:1a:...根本分不清谁是谁；开了之后 h1 就是00:00:00:00:00:01，抓包、看流表、写 ACL 实验都省事。--link tc,bw=10,delay=5ms则要求链路使用TCLink，这样带宽和延迟才会真的落在网卡队列上，不加这个参数，后面所有性能实验的数字都是宿主机物理网卡的数字，跟拓扑无关。

3.2 tree,depth=2,fanout=2 展开：为什么是 3 台交换机 4 台主机

这个参数组合最容易算错。depth指层数，fanout指每个非叶节点的子节点数。depth=2 意味着一层根、一层叶；fanout=2 意味着根下面挂 2 个节点。所以交换机是 1 根 + 2 叶 = 3 台，主机挂在叶交换机上，每台 2 个，共 4 台。如果写成 depth=3、fanout=2，就是 1 + 2 + 4 = 7 台交换机，8 台主机，规模翻倍得很快。

算清楚这个数不是为了做题，是为了配带宽。树形拓扑里根交换机到叶交换机的那两条链路是汇聚链路，四条主机链路是接入链路，两边的bw必须区分开，否则做出来的"核心拥塞"实验其实是在接入链路上拥塞，结论完全不对。我一般按接入 10Mbps、汇聚 5Mbps 这种不对称比例配，跑 iperf 的时候两台同叶主机互打能跑满 10，跨叶主机互打就会被压到 5，一眼就能看出瓶颈在哪一层。

3.3 交互式 py：addHost、addSwitch、addLink 的顺序不能乱

进入mininet>提示符之后，所有以py开头的输入都会被当作 Python 语句执行，net这个对象已经在作用域里。动态加设备的正确顺序是：先建节点对象，再建链路，最后配地址。

# 1. 加一台主机和一个交换机 mininet> py net.addHost('h3') mininet> py net.addSwitch('s2') # 2. 建链路：addLink 内部会自动完成两端的端口 attach mininet> py net.addLink(s1, net.get('s2')) mininet> py net.addLink(net.get('s2'), net.get('h3')) # 3. 新主机没有走地址分配流程，必须手动配 IP 和路由 mininet> py net.get('h3').cmd('ifconfig h3-eth0 10.0.0.3/24') mininet> py net.get('h3').cmd('ip route add default via 10.0.0.1') # 4. 验证：从原有主机 ping 新主机 mininet> h1 ping -c 2 10.0.0.3

第三步是最容易漏的。addHost只创建命名空间和网卡，不会给这张网卡配地址——地址分配发生在net.build()和net.start()阶段，而交互模式下这两个阶段早就跑完了。所以新加的 h3 在dump里看到的 IP 是空的，直接pingall会对它全红。手动ifconfig之后才通。这也是为什么报告里那句py net.get('h3').cmd('ifconfig h3-eth0 10.3')能生效：ifconfig接受简写地址，10.3会被补成10.0.0.3，但如果你的ipBase不是 10.0.0.0/8，这个简写就指到别的网段去了，写全10.0.0.3/24更稳。

还有一个常见的多余动作：addLink之后再补一句py s1.attach('s1-eth3')。很多实验报告里保留了这一行，但addLink内部已经完成了两端端口绑定，再attach会在交换机上多挂一个没有对端的端口，端口编号也可能跟addLink分配的错开。表现就是net命令看到的拓扑里 s1 有三个口，但只有一个口有流量，ping 不通还找不到原因。删掉attach那一行，或者只在纯手工建端口（不用addLink）时才用它。

3.4 nodes、net、dump、pingall 四条诊断命令的读法

Mininet 交互界面里有一组命令，作用相当于听诊器，出问题时按顺序敲一遍基本能定位到层。

mininet> nodes # 列出所有节点名，确认设备加进来了没有 mininet> net # 打印拓扑和每个节点的端口对应关系 mininet> dump # 打印每个节点的接口、IP、PID mininet> pingall # 全主机两两互 ping，输出矩阵

nodes回答"设备在不在"，如果新加的 h3 不出现在列表里，说明addHost那一步就失败了，后面不用查。net回答"线连对没连对"，它会输出s1-eth1<->h1-eth0这种配对，端口号错位在这条命令下一览无余。dump回答"地址配没配上"，h3-eth0:10.0.0.3这样才算配好，只有h3-eth0没有冒号后面那截就是没地址。pingall回答"通不通"，输出是一个主机名矩阵，X表示不通，注意这个命令默认每个方向只发一个包，偶发丢包可能表现为 X，用--ping-args增加包数更准。

注意：pingall只覆盖net.hosts里的主机。动态加的 h3 虽然在列表里，但如果没配 IP，它参与 ping 时每一格都是 X，会让你误判成链路问题。先dump看地址，再pingall。

4. Python 脚本自定义拓扑：Topo 类、写死 IP 与性能限制

命令行能盖住的场景有限：真实实验里往往是"三台主机挂一台交换机、其中一条链路限 5Mbps 加 10ms 延迟、另一台主机限 50% CPU"这种混合要求，靠--topo拼不出来。这时候就得写脚本。写脚本的收益不只是灵活，更重要的是可版本化——拓扑结构进 Git，谁改了哪条链路、参数从多少调到多少，diff 一目了然，比截图和口头描述可靠得多。

4.1 Topo 子类骨架：build 里的三个动作

自定义拓扑的标准写法是继承Topo类并实现build()，里面只做三件事：加交换机、加主机、加链路。参数通过addHost和addLink的关键字传进去。

from mininet.topo import Topo class Tree22(Topo): def build(self): # 1. 先建交换机，命名要能看出层级 s1 = self.addSwitch('s1') for i in (1, 2): s = self.addSwitch('s%d' % (i + 1)) # 汇聚链路：带宽高、延迟低 self.addLink(s1, s, bw=100, delay='2ms') for j in (1, 2): idx = (i - 1) * 2 + j # 2. 建主机时直接写死地址，避免依赖分配顺序 h = self.addHost('h%d' % idx, ip='10.0.%d.%d/24' % (i, j)) # 3. 接入链路：带宽低、带丢包，用来做瓶颈实验 self.addLink( s, h, bw=10, delay='5ms', loss=2, max_queue_size=100 )

这段代码里bw单位是 Mbps，delay接受'5ms'这种带单位的字符串，loss是百分比，max_queue_size是队列包数。写死 IP 用10.0.i.j/24这种按层级编排的方式，后面抓包和写流表时，看到10.0.2.1就知道是第二台叶交换机下第一台主机，不用回头翻拓扑图。

有个细节容易忽略：addHost的ip=参数只写地址不写掩码时，Mininet 会补上ipBase的掩码。我一般显式写/24，因为/8会让所有主机都认为彼此直连，跨叶通信看起来通了，实际上是二层泛洪过去的，路由实验就白做了。

4.2 setIP、ipBase 与 addHost(ip=) 三种定址方式怎么选

给主机定地址有三条路，差别在生效时机和适用场景，混用会打架。

选型逻辑很直接：只要脚本后面有ping写死 IP、有iperf -c 10.0.1.1、有 OpenFlow 流表匹配特定网段，就必须用第二种，把地址钉死。setIP只在动态场景用，因为它会把接口先 down 再 up，跑到一半的连接会断，如果这时候正好在跑 iperf，数字会很难看。

4.3 把 bw、delay、loss、cpu 挂上去：TCLink 与 CPULimitedHost

参数写在addLink和addHost里不等于生效。bw、delay、loss、max_queue_size这几个参数要求链路类必须是TCLink，cpu要求主机类必须是CPULimitedHost。忘了指定，参数会被静默忽略，脚本不报错，跑出来全速，人会以为限制配得太宽松。

from mininet.net import Mininet from mininet.node import CPULimitedHost, Controller from mininet.link import TCLink from mininet.cli import CLI from mininet.log import setLogLevel def run(): setLogLevel('info') topo = Tree22() # 三个类必须同时指定，缺一个对应的参数就失效 net = Mininet( topo=topo, host=CPULimitedHost, # 启用 cpu= 参数 link=TCLink, # 启用 bw/delay/loss/max_queue_size controller=Controller ) net.start() CLI(net) net.stop() if __name__ == '__main__': run()

主机层面的 CPU 限制写法是self.addHost('h1', cpu=0.5)，0.5 表示占用单核的 50%，底层靠 cgroup 实现，所以宿主机内核必须挂载 cgroup，容器里跑经常因为这条不满足而失效。链路层面，use_htb=True可以显式指定用 HTB 队列规则做限速，默认就是它，写出来只是为了让读脚本的人知道限速发生在哪一层。

参数之间会互相影响，这点必须有预期：delay='5ms'是单向延迟，ping看到的 RTT 约等于两倍，也就是 10ms 左右；loss=2表示 2% 丢包，ping -c 20期望丢 0～1 个包，丢一半说明链路压根没配好；max_queue_size=100在带宽小、突发大的场景下会触发丢包，如果你只想要延迟不想要丢包，队列要开大。这几个数字不是独立的，调一个往往要跟着调另一个。

4.4 用 ping 和 iperf 验收：限制到底生效了没有

脚本跑起来不等于参数生效。验收分两步，ping 看延迟，iperf 看带宽。

# 延迟验收：RTT 应该接近 delay 的两倍 mininet> h1 ping -c 5 10.0.2.1 # 带宽验收：先起服务端，再在另一台主机上打流 mininet> h1 iperf -s & mininet> h2 iperf -c 10.0.1.1 -t 5

判断标准要写清楚，否则数字出来也不知道对不对。配了delay='5ms'，ping输出的time应该在 10ms 上下浮动，明显低于这个值说明延迟参数没落到链路上，明显高于且波动很大说明宿主机负载过高，测的不是链路延迟。配了bw=10，iperf的 TCP 吞吐应该在 9～9.5Mbps 之间，因为 TCP 头和握手有开销，跑到 10.0 反而不正常；如果跑出 100Mbps 以上，基本可以确定link=TCLink没生效，或者addLink用的是不带参数的默认链路。

对称拓扑里还要注意方向。iperf客户端在 h2、服务端在 h1，流量走 h2 的上行链路，如果两条链路参数不对称（比如一条 10Mbps 一条 5Mbps），换个方向数字就变。做对比实验时把方向固定下来，或者两个方向都测一遍写进报告，别让读者猜。

5. 避坑与排查：五条把实验卡死的现场记录

5.1 启动与环境类问题

第一条：miniedit 起不来，报no display name and no $DISPLAY environment variable。现象是命令敲下去立刻退出，日志里只有这一行。原因是当前会话没有图形出口，通过远程命令行连过去的终端天然没有DISPLAY。解决办法是回到虚拟机桌面环境执行，或者本地用带 X11 转发的连接方式并在登录后确认echo $DISPLAY有输出。排查完还是不行，就查xauth权限，别在 Mininet 本身上找原因。

第二条：pingall全红，一个都不通。现象是拓扑建起来了，nodes和net都正常，但主机之间零连通。九成是控制器没起来或者交换机没连上控制器，OpenFlow 流表为空，交换机收到包不知道往哪转。排查顺序：s1 ovs-vsctl show看is_connected是不是 true，ps -ef | grep controller看控制器进程在不在，然后检查addController里的端口和协议版本是否匹配——选 1.3 协议却填 6633 端口是很常见的错配。实在查不出来，用--controller ovsc显式指定自带控制器，先排除环境问题。

第三条：重复运行脚本报Error creating interface pair或Cannot find device。现象是同一个脚本昨天能跑今天不能跑。原因是上一次异常退出（Ctrl+C、断连、虚拟机挂起）留下了 veth 对、OVS 网桥和命名空间，新的一轮建同名设备撞车。解决方法是每次开跑前sudo mn -c，这条命令会做完整清理。清完还报错，就用ip link | grep -v和ovs-vsctl show手工确认有没有漏网的网桥，必要时ovs-vsctl del-br手动删。

5.2 拓扑与参数类问题

第四条：交互式加完主机，pingall对它全红，但链路明明加上了。现象是nodes里有 h3，net里也能看到s1-eth3<->h3-eth0的配对，就是不通。原因是交互模式下地址分配阶段已经过去，新主机没有 IP。解决方法是手动py net.get('h3').cmd('ifconfig h3-eth0 10.0.0.3/24')，需要跨网段再补一条默认路由。另一个变体是addLink之后又调了attach，导致交换机多出一个没有对端的端口，端口号跟net里显示的对不上，这种情况下把attach删掉重来。

第五条：配了 bw 和 delay，iperf 还是跑满千兆。现象是参数写了，脚本不报错，测出来的吞吐跟物理网卡一个量级。原因是Mininet()构造时没指定link=TCLink，addLink里的bw/delay/loss被静默忽略。同类问题还有cpu=不生效，那是没指定host=CPULimitedHost。解决办法是把这三个类补齐，然后重新用 ping 的 RTT 和 iperf 的吞吐做一次验收，别只看脚本里写没写参数。这条坑最阴的地方在于它不报错，只看代码看不出来，必须靠测量兜底。

6. 一套跑通全部拓扑的验收习惯：清理、对账、测量

把上面几章的东西串起来，落地动作其实就三步，我把它固化成一张检查表，每次开新实验前过一遍，比事后翻报告找原因省时间得多。

配套的循环脚本可以省掉手工重复，但只用在内置拓扑上：

#!/bin/bash # 依次跑四种骨架，每种跑完立刻清理，避免残留互相干扰 for t in "single,3" "linear,4" "tree,depth=2,fanout=2" "minimal"; do echo "===== testing topo: $t =====" sudo mn -c > /dev/null 2>&1 # --test pingall 表示建完拓扑自动执行全量 ping 然后退出 sudo mn --topo $t --mac --test pingall done sudo mn -c

--test pingall是关键参数，它让 Mininet 建完拓扑就直接跑全量 ping 再退出，不需要人工进 CLI 敲命令，适合放在批量脚本里做冒烟测试。注意这个参数下看不到中间过程，只输出结果矩阵，定位问题时还得回到交互模式用dump和net逐层看。

最后说一个我自己的习惯。这份实验报告里最有价值的部分不是那些截图，而是"操作要点"里把每一步拆成了可执行动作——定位 miniedit、右键配属性、导出脚本、跑脚本。这套拆法本身就是验收清单的雏形。从那以后我每次开一个新的拓扑实验，都会先把sudo mn -c、nodes对账、ping验延迟、iperf验带宽这四步固定走一遍，任何一步对不上就停下来查，绝不带着"应该是通的"的假设往下做性能实验，因为后面所有数字都建立在这个假设上，假设错了，整份报告都得重写。希望帮到你。

本文还有配套的精品资源，点击获取