简介一份Mininet网络仿真实验报告适合网络工程、计算机等专业学生完成《网络应用设计与系统集成》课程实验时参考帮助快速掌握Mininet可视化工具及Python脚本构建网络拓扑的方法。报告完整呈现了实验目的、实验内容、技术背景与操作要点具体涵盖Miniedit图形化创建拓扑、命令行创建最小/线性/单交换机拓扑、交互式界面添加主机与交换机、节点间ping测试以及编写Python脚本构建linear、single、tree等拓扑并对主机CPU、链路带宽、延迟、丢包率等性能参数进行限制。资源为1个doc文档压缩包共1.37MB内容页数较多、步骤截图清晰便于对照练习与撰写实验报告。已有1066人学习下载适合需要系统梳理Mininet操作流程、完成课程实验或准备SDN相关实践考核的学生使用。1. 写Mininet实验报告的第一步先想清楚这份报告要证明什么周日晚十一点一整套看上去很完整的Mininet实验报告被老师打回重写拓扑截图有、pingall全通、iperf测出30Mbps带宽、Wireshark里还抓到了几条OpenFlow报文。但老师只反问了一句这个带宽是TCP还是UDP测的丢包率在哪个环节设置的——这份报告只有结果没有过程。Mininet实验报告不是把终端输出粘贴成册而是让读报告的人能按你的步骤在同样的环境里复现出同样的数据。它要证明的是三件事环境真的搭起来了、控制面和数据面真的按预期工作、测量结果确实反映了你设置的那组参数。这个逻辑一旦立住后面的命令、截图、表格都会有归属感而不是拼凑。所以这篇笔记按我的习惯来拆先跑通Mininet的最小环境并留下报告级证据再抓OpenFlow协商、测iperf、记链路参数然后专门讲那些看起来成功其实是假象的坑最后把手工操作脚本化让实验报告经得起复现。2. 用Mininet把实验环境拉起来最小命令、CLI验证与报告级证据2.1 动手前先确认Mininet真的可用三种安装形态下的检查顺序很多实验报告翻车第一刀就砍在环境上。有人用的是虚拟机镜像里的Mininet有人是在物理机上apt装的原生包还有人跑在WSL里——这三种形态的可用性完全不一样。我的建议是先不要写任何报告内容把一组检查命令按顺序跑一遍确认你最依赖的几个能力在。which mn mn --version sudo mn --test pingall sudo ovs-vsctl show sudo mn -c逻辑说明which mn确认命令行工具在PATH里mn --version看版本号报告里这两行输出可以放在“实验环境”一节sudo mn --test pingall会用默认的minimal拓扑1台交换机连2台主机自动创建网络、执行pingall然后退出如果这条路通说明最基础的命名空间与虚拟网卡链路没问题sudo ovs-vsctl show是确认Open vSwitch控制进程真的活着后面的OpenFlow实验全靠它最后sudo mn -c是清理上一次可能残留的网桥和命名空间。参数说明默认拓扑是--topominimal只含h1、s1、h2三个节点适合做冒烟测试。如果这一步pingall就不通先别折腾后面的控制器百分之九十五是环境问题——比如宿主机上装了Dockerdocker0网桥与Mininet的网段冲突或者VMware/NAT网络模式下虚拟网卡MTU被改小了。把这些排查过程写进报告的“异常记录”里反而是加分项。我一般还会顺手确认一下Wireshark和tshark是否可用因为后面要抓OpenFlow报文。缺了就sudo apt install tshark先装好。不要在实验做到一半才想起来抓包工具没有那是给自己挖坑。2.2 写进报告的最小拓扑命令拓扑、控制器与链路参数怎么选报告里“实验步骤”部分最忌讳只写半行命令。下面这条命令是SDN相关实验最常见的起手式它同时把拓扑、控制器、链路参数都定义好了适合直接作为报告的“实验组网”依据。sudo mn --toposingle,3 \ --controllerremote,ip127.0.0.1,port6653 \ --linktc,bw2,delay10ms,loss1 \ --switchovs逻辑说明--toposingle,3表示1台交换机连接3台主机是最小的“单交换机组网”画拓扑图时最直观--controllerremote,ip127.0.0.1,port6653表示交换机去连接一个外部控制器而不是用Mininet自带的none控制器这样你后续才能观察到真实的OpenFlow协商与流表下发--linktc,bw2,delay10ms,loss1是用Linux tc机制给每条虚拟链路限带宽2Mbps、加10ms延迟、加1%丢包率--switchovs明确使用Open vSwitch。参数说明这三个参数是报告里最容易被问到的。bw单位是Mbpsdelay单位是msloss是百分比。为什么用tc而不是默认的无限制链路因为tc会给每对veth网卡挂上htb队列规则真正模拟带宽天花板实测iperf结果才会出现稳定的瓶颈值。如果你不写--linktcMininet默认是空链路iperf跑出来的带宽就是本机回环能跑多少跑多少那个数字基本没有实验意义。拓扑起来后Mininet会进入交互式CLI提示符长得像mininet。报告里至少要留下这几条命令的输出mininet pingall mininet iperf h1 h2 mininet sh ovs-ofctl dump-flows s1 mininet exit逻辑说明pingall验证所有主机之间的连通性报告里必然要放正常的输出是*** Results: 0% dropped (6/6 received)iperf h1 h2是Mininet封装的带宽测试直接输出两个方向的平均吞吐sh ovs-ofctl dump-flows s1是进入OVS内部查看流表控制器是否下发规则、规则超时时间是多少一眼就能看出来exit退出CLI并拆除网络。2.3 报告级证据的截法用script命令留存完整运行日志很多同学交报告是从终端窗口截图图里只有命令和结果前面的警告信息被滚动条吞掉了。老师想看的是完整的实验过程而不是一张精心裁切的结果图。我用一个很土但可靠的办法用script命令把整段操作录成文本日志报告中引用日志片段原始文件作为附件。script -q mininet_run.log sudo mn --toposingle,3 --controllerremote,ip127.0.0.1,port6653 mininet pingall mininet exit exit逻辑说明script -q启动后终端所有输出会同时写入mininet_run.log直到你再次输入exit结束录制。这个日志文件是“过程证据”比截图更有说服力。报告里你可以用等宽字体引用其中几行并注明“完整日志见附件mininet_run.log”。这里有个小习惯录日志前先执行export LC_ALLC保证终端输出是英文而不是本地化语言。否则录下来的日志里混着中文提示报告排版容易乱复现时也容易让人误读状态。3. 报告里最值钱的四张证据控制器协商、iperf数值、链路参数与表格化结论3.1 用tshark抓OpenFlow协商证明你的实验不是“OVS自学习”在冒充控制面一个合格的Mininet实验报告不能只证明“网络通了”还要证明“是这个控制器让网络通的”。这里的关键证据是OpenFlow握手与PacketIn消息。我通常不用Wireshark图形界面而是在控制器的同一台机器上用tshark抓包切出文本记录放进报告。sudo tshark -i any -f tcp port 6653 or tcp port 6633 \ -T fields -e frame.number -e ip.src -e tcp.srcport -e openflow_v4.type逻辑说明-i any抓取所有网卡因为控制器流量可能走loopback-f是抓包过滤只保留与OpenFlow相关的TCP端口-T fields让tshark输出指定字段其中openflow_v4.type是OpenFlow 1.3消息类型字段。启动tshark后再启动一个连到该控制器的Mininet拓扑你会看到类似4 127.0.0.1 6653 5的输出表示收到一条OFPT_FEATURES_REPLY。参数说明OpenFlow协议里常见的type值0是HELLO、4是FEATURES_REQUEST、5是FEATURES_REPLY、10是PACKET_IN、14是FLOW_MOD。报告里只要出现了0和5就说明交换机与控制器完成了握手出现了10说明第一个数据包触发了PacketIn上报后续再出现14说明控制器下发了流表。这三类消息凑齐控制面逻辑就完整了。有一个非常容易踩的坑如果启动Mininet时用的是默认控制器不带--controllerremoteMininet会自己拉一个控制器进程报告里写“连接了外部控制器”就是虚假描述。抓包时看连接对端IP是不是127.0.0.1的6653端口这个细节能帮你的报告自证清白。3.2 iperf数值不能只报平均值TCP重传、窗口与UDP模式的差异老师问“30Mbps是TCP还是UDP”问的就是测量方法的边界。Mininet CLI里直接敲iperf h1 h2底层其实是让h1起服务端、h2起客户端默认用TCP。这个数字受TCP拥塞窗口、接收窗口和网卡卸载机制影响和链路bw参数不一定对得上。我一般在报告里做两组测量TCP吞吐和UDP极限吞吐。mininet xterm h1 h2 # 在h1的窗口里执行 iperf -s -t 20 -i 2 # 在h2的窗口里执行 iperf -c 10.0.0.1 -t 20 -i 2 -w 64k # UDP模式h1端 iperf -s -u -t 20 # h2端 iperf -c 10.0.0.1 -u -t 20 -b 5m逻辑说明iperf -s是服务端-t 20表示持续20秒-i 2表示每2秒打印一次中间结果客户端用-c指定服务端IP-w 64k指定TCP窗口为64KBUDP模式在两端都加-u-b 5m指定发送目标带宽。报告里给出TCP模式的平均带宽、UDP模式的丢包率比只给一个数字严谨得多。参数说明遇到TCP模式测量结果远低于bw设定值时优先怀疑窗口过小试着增大-w如果UDP模式测得带宽能接近链路bw但丢包率很高说明链路参数设置生效了这是一个“预期内的现象”写进报告反而是亮点。3.3 动态修改链路参数验证“带宽限制”真实生效的第二个手段静态启动参数容易让人怀疑“你是不是只在命令行里写了实际没生效”。报告里加一组动态修改链路的实验能把这个疑虑打掉。Mininet支持运行时把某条链路断开、更改流量控制参数再去测一次连通性形成“前测—变更—后测”的闭环。mininet link h1 s1 down mininet ping h1 h2 mininet link h1 s1 up mininet py net.h1.cmd(tc qdisc show dev h1-eth0)逻辑说明link h1 s1 down会把h1与交换机之间的虚拟链路设为down此时h1到h2的ping必然不通输出connect: Network is unreachablelink h1 s1 up恢复链路后再ping就恢复通。这段过程截图放进报告能直接证明拓扑中的链路由Mininet管理而不是宿主机上的物理以太网“碰巧通了”。参数说明最后一行py net.h1.cmd(tc qdisc show dev h1-eth0)是进入Python运行时在h1的网络命名空间里执行tc命令查看h1-eth0上挂的队列规则。输出中含有netem delay 10ms和rate 2Mbit这就是你在启动命令里设的参数已经落地到虚拟网卡的直接证据。3.4 用一张表格把测量结果装进去报告结论的规范结构报告末尾的实验结果部分我习惯用一张表把环境参数、测量方法和结果对齐避免大段文字里藏着关键数字。下面这种结构可以直接套用实验项链路参数测量方法测得结果备注基本连通性无限制pingall0% dropped (6/6)默认minimal拓扑TCP吞吐bw2, delay10msiperf -t 201.87 Mbps接近限速UDP吞吐bw2, delay10msiperf -u -b 5m2.01 Mbps, 12% loss达到瓶颈动态断链同上link down/up断链不通恢复后通验证链路管理这张表的好处是老师第一眼就能看到“链路限速2Mbps实测TCP约1.87Mbps”理解你做了什么、得到了什么。表里一定要写“接近限速”而不是“正好2Mbps”因为tc的htb限速本身有少量误差写得太精确反而显得是编的。4. Mininet实验常见假象与排查数据面通了但控制面没跑、带宽测不准4.1 现象一pingall全通过但控制器日志里没有任何OpenFlow消息这个现象我见了太多次报告写的是“控制器下发流表使网络互通”实际实验时把--controllerremote写错成--controllernone或者外部控制器没启动但网络照样ping全通。原因是Open vSwitch在没有任何控制器连接时会进入一个fallback模式自己像普通二层交换机一样做MAC地址学习与转发。也就是说数据面“通”了但控制面根本没参与。排查方法分三步先确认Mininet启动时是否带了--controllerremote再检查OVS到底连没连上控制器执行ovs-vsctl show看controller列表是否为空最后看tshark有没有抓到握手包。报告里写明这三步的排查过程比掩饰问题更能体现实验素养。4.2 现象二iperf测出来的带宽是链路限速的好几倍有同学在bw2的链路上测出30Mbps第一反应是参数写错了其实不然。Mininet的虚拟链路走的是Linux内核协议栈当TCP发送数据时网卡的TSO/GSO/GRO卸载机制会提前把数据聚合、绕过一部分队列限制导致测出的吞吐高于htb设定的速率。另外iperf的TCP模式如果在同一主机上的两个命名空间之间跑回环路径的缓冲也可能让结果失真。解决方法是在测试前关闭收发端的卸载功能在Mininet CLI里执行mininet py net.h1.cmd(ethtool -K h1-eth0 tso off gso off gro off) mininet py net.h2.cmd(ethtool -K h2-eth0 tso off gso off gro off) mininet iperf h1 h2逻辑说明ethtool -K关闭网卡的TCP分段卸载、通用分段卸载和通用接收卸载让每个数据包按真实大小进入队列htb限速才能准确生效。做这一步后重新跑iperf结果通常会回到接近bw设定值。这个操作可以写进实验步骤里作为“测量前置条件”它会显著提高报告的可信度。4.3 现象三Mininet里ping得通换个终端在宿主机上ping不通实验IP这是命名空间的认知偏差。Mininet创建的主机都在独立网络命名空间里10.0.0.x这个地址只存在于命名空间内部。在宿主机上直接ping 10.0.0.1宿主机自己的路由表和ARP表里根本没有这个地址自然会失败。这不是实验有问题是“从外面ping里面”本身就不该通。解决方法是所有针对实验主机的操作都要进入Mininet环境执行要么用CLI里的h1 ping h2、xterm h1要么用py net.h1.cmd(ifconfig h1-eth0)在命名空间里执行命令。报告里如果放了宿主机route -n的输出再加一句“所有测量均在Mininet命名空间内进行”能避免读报告的人产生同样的误解。4.4 现象四上次实验的痕迹没清干净重启时报“端口被占用”或“网桥已存在”Mininet异常退出后OVS网桥、veth网卡对和命名空间不会自动拆除。下次再启动时系统里残留的ovsbr0或s1就会与新拓扑冲突报错五花八门。我每次实验前都会无脑执行一条清场命令sudo mn -c sudo pkill -f ovscontroller逻辑说明mn -c是Mininet自带的清理命令会删除所有残留网桥和命名空间pkill -f ovscontroller是为了杀掉Mininet可能自动拉起的默认控制器进程避免它占着6633端口影响你后续连接自定义控制器。4.5 现象五抓包只看到OpenFlow握手之后看不到任何PacketIn与数据流正常情况下握手之后只要主机间发包Wireshark里就应该出现PacketIn消息。如果只看到握手包没有后续内容多半是抓包监听位置选错了。Mininet主机的数据流量走的是各自的veth网卡不经过物理网卡也不是所有流量都经过loopbacktshark -i any能抓到所有接口流量但如果你开Wireshark时只选了物理网卡自然看不到。另外注意过滤表达式OpenFlow消息的TCP端口是6653新规范或6633旧版有些发行版里OVS默认监听6633控制器对端端口不一致时握手也起不来。抓包命令里把两个端口都放进去能少踩一半的坑。5. 把手工实验变成可复现的脚本自定义Python拓扑与自动化产出5.1 为什么要把--toposingle,3升级成Python拓扑脚本命令行里的--topo只适合最简拓扑。一旦你想要“每台主机的带宽不同、延迟不同、有些链路还带丢包”命令行参数会变得又长又乱而且报告里说不清。常规做法是写一个自定义Python拓扑文件继承Mininet的Topo类在build方法里定义节点和链路脚本即拓扑也即报告里的“组网图”文字版。#!/usr/bin/env python3 from mininet.topo import Topo from mininet.net import Mininet from mininet.node import OVSSwitch, RemoteController from mininet.cli import CLI class LabTopo(Topo): def build(self, n5, bw2, delay10ms, loss1): s1 self.addSwitch(s1) for i in range(1, n 1): host self.addHost(h%d % i, ip10.0.0.%d/24 % i) self.addLink( host, s1, bwbw, delaydelay, lossloss, use_htbTrue ) if __name__ __main__: topo LabTopo(n5, bw5, delay5ms, loss0) net Mininet( topotopo, switchOVSSwitch, controllerRemoteController(c0, ip127.0.0.1, port6653) ) net.start() CLI(net) net.stop()代码逻辑说明LabTopo继承Topo后通过addSwitch创建交换机通过addHost创建主机并指定IP最后用addLink把主机与交换机连起来同时把带宽、延迟、丢包参数挂在链路上。主程序部分把topo传入Mininet指定交换机类型为OVSSwitch控制器为RemoteController连接本地6653端口。这份文件存成lab_topo.py启动命令只需sudo python3 lab_topo.py。参数说明addHost里的ip10.0.0.%d/24 % i会自动给每台主机生成同一网段递增IP省去手动配置use_htbTrue明确告诉Mininet使用htb队列实现带宽限制如果你不写某些版本默认用的是netem行为会有细微差别。5.2 让脚本自动跑测量并保存结果从交互式实验到自动化实验有了自定义拓扑还可以进一步把“测试”也写进脚本让实验变成一条命令跑完、自动输出日志。对于报告里的“多次重复测量取中位数”这是最省力的实现方式。import subprocess def run_iperf(net): h1, h2 net.get(h1), net.get(h2) result net.iperf((h1, h2), seconds20) print(TCP throughput:, result) with open(iperf_result.txt, w) as f: f.write(str(result) \n) def main(): topo LabTopo(n3, bw10, delay2ms) net Mininet(topotopo, switchOVSSwitch, controllerRemoteController(c0, ip127.0.0.1, port6653)) net.start() net.pingAll() run_iperf(net) net.stop() if __name__ __main__: main()逻辑说明net.iperf((h1, h2), seconds20)是Mininet封装好的iperf调用传入两台主机对象和测试时长返回字符串形式的吞吐结果pingAll()在开头执行先保障拓扑连通再测带宽。整段代码跑完后屏幕上能看到完整测试过程磁盘上多出iperf_result.txt这份文件的路径可以写进报告的“数据附件”清单。参数说明seconds20对应iperf的-t 20参数。如果链路参数改成bw100测试时长建议也适当缩短带宽大时数据量增长很快Mininet的临时文件目录可能被撑爆。5.3 把脚本输出落进报告三次测量与结论写法自动化脚本跑出来的原始输出不能直接粘贴成报告结论需要做一个简单的加工。我一般会连跑三次把三次的吞吐值记录到一张小表里取中位数写进结论同时保留最大值与最小值之间的波动幅度。这个做法看起来是多花了三倍时间但老师一眼就能看出你不是“只挑了一次好看的结果”。测量次数链路限速实测吞吐重传次数第1次10 Mbps9.62 Mbps3第2次10 Mbps9.74 Mbps1第3次10 Mbps9.51 Mbps5中位数10 Mbps9.62 Mbps3报告中结论的写法我习惯用一句话模板“链路限速10Mbps下三次TCP吞吐测试的样本中位数为9.62Mbps波动范围9.51~9.74Mbps与tc限速值偏差小于5%说明链路参数设置有效。”这种写法把参数、方法和结果绑在一起不需要多余的修饰。6. 实验报告可信度自检三次测量、留存日志、写明边界6.1 一个能反复使用的自检命令测三遍并分别留存日志如果你用的是自带--test参数的Mininet自检阶段可以写一个简单的bash循环把三次测量结果分别存成独立文件后续对比它们的差异。for i in 1 2 3; do sudo mn --toposingle,2 \ --linktc,bw10,delay2ms \ --controllerremote,ip127.0.0.1,port6653 \ --testiperf /tmp/mininet_$i.log 21 sleep 1 done逻辑说明循环三次执行Mininet并自动跑iperf测试每次结果写入不同的日志文件。跑完后可以grep -E throughput|Mbits /tmp/mininet_*.log快速对比三次吞吐。这里的--testiperf等价于启动拓扑后自动执行iperf并退出不需要人工介入适合做批量重复实验。6.2 报告里写清测量边界的一句惯用收尾我这边踩过最尴尬的一次是在报告里写了“实测带宽20Mbps符合预期”结果老师追问“这个20Mbps是VM里的虚拟链路还是物理机的真实链路”当时我压根没在结论里区分实验环境与真实环境。之后我养成了一个习惯每个实验报告的结论段都会加一句边界说明比如“本次所有测量均在Mininet虚拟网络命名空间内完成链路为veth虚拟网卡与tc队列模拟不代表真实物理网络性能”。写清楚这个边界不是为了给自己开脱而是让实验结论站得住你验证的是Mininet环境下的组网与控制面逻辑不是物理网络的性能指标。读报告的人不会再拿真实网卡的标准来质疑你的虚拟链路。这些自检动作看起来很琐碎但真的能救急。我认识不少同学报告被打回后才发现自己贴的iperf结果是同事跑出来的或者用的拓扑参数与实际不一致。数据留痕、三次测量、边界标注这三步做好了你交出去的Mininet实验报告才算真正“闭环”。希望帮到你。本文还有配套的精品资源点击获取