Mininet与软件定义网络实战：从拓扑搭建到流表下发

简介这份PDF文档围绕基于Mininet模拟环境的软件定义网络实验课程设计展开适合网络工程、计算机等专业的研究生课程教学也适合希望快速上手SDN实验的教师和学习者参考。文档针对当前SDN实验科目匮乏、硬件交换设备难以大规模部署、实验环境灵活性不足以及学生入门困难等实际问题给出了体现最新研究进展、增强与传统网络对比实验、模块化组织实验科目的整体设计思路重点介绍了基于Linux Container的Mininet轻量级模拟平台以及配合POX、Kinetic、Pyretic等控制器开展SDN网络环境搭建、特定拓扑绘制、网络分割、二层防火墙编写等实验的具体方案。整份资源为1个PDF文件压缩包大小仅174KB内容聚焦且便于阅读。目前已有104人学习下载可作为SDN课程论文、实验教学改革案例或相关毕业设计的参考资料。1. 一份PDF课程设计背后Mininet与软件定义网络到底在解决什么第一次接触“基于Mininet模拟环境的软件定义网络实验课程设计”这个题目的人多半会以为难点在SDN控制器编程上。实际做过一轮就会发现真正卡住人的是那个看不见摸不着的“网络环境”没有实体交换机没有网线甚至连第二块网卡都不需要却要在一个普通笔记本电脑里跑出一张完整的校园网拓扑。Mininet就是为这件事而生的轻量级虚拟网络模拟器它用操作系统级的虚拟化技术在单台Linux主机上模拟出交换机、主机和链路让软件定义网络SDN的控制逻辑可以在真实网络协议栈上被反复验证。这份课程设计的价值不是把实验做出来而是通过它理解“控制面与数据面分离”这件事到底改变了什么。适合正在做网络方向课设、准备SDN入门、或者想快速搭一套可演示原型的人。2. 从零搭起Mininet实验环境安装选型与最小可用验证2.1 为什么是Mininet而不是GNS3或EVE-NG课程设计选模拟器第一要义是“能跑通”第二是“能改代码”。GNS3和EVE-NG解决的问题是仿真真实设备镜像它们跑的是厂商的IOS、NX-OS或者Linux路由器镜像好处是贴近生产环境坏处是镜像体积大、授权受限、启动慢而且它们本质上不是为SDN设计的——你想给GNS3里的交换机下发OpenFlow流表得先确认这个镜像支不支持相关协议这本身就是个坑。Mininet走的是另一条路它不仿真设备而是用Linux的网络命名空间network namespace加虚拟以太网对veth pair直接在宿主机内核里创建出一张真实可用的网络。每个虚拟主机有自己的文件系统视图、进程空间和网络栈每个虚拟交换机背后是一个用户态进程默认是Open vSwitch链路就是一对veth。这意味着你在Mininet里敲的ping、跑的iperf、抓的包全都是在真实内核协议栈里发生的不是模拟出来的现象。这个区别对课程设计至关重要SDN的核心是控制面与数据面分离Mininet里你可以真正让数据面的流表决定转发而不只是看拓扑图。对比之下GNS3更适合做传统路由交换实验EVE-NG适合需要同时跑多厂商镜像的场景。Mininet的优势是轻、快、可编程、和SDN控制器天然对接。一台4核8GB内存的笔记本跑一个20台主机、6台交换机的拓扑毫无压力这在EVE-NG里光是等镜像起来就得十分钟。2.2 安装方式怎么选apt、源码还是容器常见做法是优先用apt装因为Mininet已经进了Debian/Ubuntu官方源。但不同发行版源里的Mininet版本差异很大Ubuntu 22.04装出来的可能是2.3.x而一些老教程里写的是2.2.x命令行为上会有细微差别。如果只是想快速验证环境apt装完直接跑测试命令就行# Ubuntu/Debian 系列 sudo apt update sudo apt install -y mininet # 验证安装是否完整的标准三步 sudo mn --test pingall sudo mn --version sudo mn --topo single,3 --mac --switch ovs --controller none第一条命令如果输出“*** Results: 0% dropped (2/2 received)”之类的结果说明Mininet内核模块和工具链基本可用。第二命令看版本号第三命令是手动创建一个3台主机的单交换机拓扑并且不用控制器纯数据面连通性测试。注意这里--switch ovs明确指定使用Open vSwitch作为交换机类型--controller none表示不连接任何SDN控制器验证的是Mininet自身的链路和主机网络栈是否正常。如果apt源里的Mininet版本太旧或者你用的发行版没有打包国内常见做法是从Gitee上找Mininet相关的镜像仓库拉源码下来编译。这个过程会多花十几分钟但你能拿到最新的代码而且后续想改Mininet源码本身做一些深度实验也方便git clone https://gitee.com/你的镜像路径/mininet.git cd mininet ./util/install.sh -ninstall.sh脚本的-n参数表示只安装Mininet核心不装Open vSwitch以外的控制器。如果你打算后面用Ryu或ONOS可以加-y安装Ryu或-w安装Wireless工具。这个脚本会顺带安装Open vSwitch、Wireshark等依赖整个过程需要sudo权限而且依赖网络情况。装完以后一定重新开一个终端再执行sudo mn --test pingall因为脚本会更新PATH和内核模块。2.3 控制器环境Ryu、ONOS和OpenDaylight怎么选Mininet本身不带控制器这恰恰是SDN课程的精华所在——交换机把未知流量封装成Packet-In消息发给控制器控制器决定怎么转发。课程设计里选哪个控制器直接决定你后面要写多少代码。Ryu是Python写的上手门槛最低文档和中文资料最多适合做“控制器实现二层转发”“流量监控”这类实验。ONOS和OpenDaylight是Java写的功能强大、支持集群和北向接口但部署重量级内存吃得厉害而且配置文件复杂一个工程课设的时间很可能不够你趟完这些坑。我的建议是如果课程设计的重点在网络行为分析选Ryu如果重点在南北向接口或者多控制器协同再考虑ONOS。Ryu的安装通常是pip install ryu ryu-manager --versionRyu装好后启动一个简单的学习交换机应用ryu-manager ryu.app.simple_switch_13然后在另一个终端启动Mininet并指定连接控制器sudo mn --topo tree,2 --controller remote,ip127.0.0.1,port6653 --mac这里的remote表示连接外部控制器Ryuport6653是OpenFlow 1.3的默认监听端口。很多老教程写的是6633那是OpenFlow 1.0的旧端口Ryu从某个版本开始默认监听6653端口对不上会直接导致交换机和控制器的连接一直处于“TCP连接已建立、但Hello协商失败”的状态。2.4 最小可用实验验证控制面与数据面真的分开环境装好以后先别急着写大拓扑。我一般会先跑一个最直接的验证在不连接控制器的情况下两台主机能不能通。用--controller none启动sudo mn --topo linear,2 --controller none --mac mininet h1 ping -c 3 h2正常情况下这里会通因为OVS的默认行为是没有流表规则时Flow Table miss会走NORMAL动作也就是退化成一个普通二层交换机。这件事和“SDN交换机”是完全不同的逻辑。接着连上控制器再试sudo mn --topo linear,2 --controller remote,ip127.0.0.1,port6653 --mac mininet h1 ping -c 3 h2如果Ryu的simple_switch_13在跑第一次ping时h1发ARP交换机不认识目的MAC会把它封装成Packet-In发给RyuRyu学习到h1的MAC之后把流表下发到交换机第二次ping开始走流表转发。这个过程你在Ryu的日志里能看到packet_in和flow_mod的打印。这一个实验就把SDN的“控制面与数据面分离”讲透了数据面只负责按流表转发控制面负责计算并下发流表。这就是整个课程设计的基石。提示--mac参数很重要它让Mininet把每个虚拟主机的MAC地址设置成和IP地址对应的简单值比如10.0.0.1对应00:00:00:00:00:01方便你在抓包时一眼看出是哪台主机在发包。3. 课程设计的四类核心实验拓扑搭建、流表下发与控制器联动3.1 自定义拓扑用Python API构建你的第一张实训网络课程设计通常不会满足于single或tree这种内置拓扑你需要按题目要求比如“某企业有3个部门每个部门2台主机核心层和汇聚层各1台交换机”自定义拓扑。Mininet的Python API是干这个的标准方式。下面这段代码是一个典型的“三层树形拓扑”#!/usr/bin/env python3 from mininet.topo import Topo from mininet.net import Mininet from mininet.node import OVSController from mininet.cli import CLI from mininet.link import TCLink class ThreeLayerTopo(Topo): def build(self): # 核心层交换机 core self.addSwitch(s1, protocolsOpenFlow13) # 汇聚层交换机 agg1 self.addSwitch(s2, protocolsOpenFlow13) agg2 self.addSwitch(s3, protocolsOpenFlow13) # 接入层交换机 edge1 self.addSwitch(s4, protocolsOpenFlow13) edge2 self.addSwitch(s5, protocolsOpenFlow13) edge3 self.addSwitch(s6, protocolsOpenFlow13) # 交换机互联链路 self.addLink(core, agg1) self.addLink(core, agg2) self.addLink(agg1, edge1) self.addLink(agg1, edge2) self.addLink(agg2, edge3) # 接入层下挂主机 for i in range(2): host self.addHost(h%d % (i1)) self.addLink(host, edge1) for i in range(2): host self.addHost(h%d % (i3)) self.addLink(host, edge2) for i in range(2): host self.addHost(h%d % (i5)) self.addLink(host, edge3) topos {three_layer: ThreeLayerTopo} if __name__ __main__: net Mininet(topoThreeLayerTopo(), controllerOVSController, linkTCLink, autoSetMacsTrue) net.start() CLI(net) net.stop()这段代码里有几个关键点值得说清楚。build方法是Mininet拓扑构建的入口你在里面声明的交换机、主机、链路会被自动装配。addSwitch的protocolsOpenFlow13参数指定交换机使用的OpenFlow协议版本不写的话OVS默认可能走OpenFlow10和Ryu 1.3的协商会出问题。TCLink让链路支持tc参数后面做带宽限制就靠它。autoSetMacsTrue相当于命令行里的--mac为每台主机生成有序MAC便于抓包识别。运行方式sudo python3 three_layer.py进入mininet提示符后先net查看拓扑结构再pingall测试全网连通性。如果连的是Ryu控制器第一次pingall的结果必然是丢包的因为控制器还没下发任何流表每个交换机的流表都是空的这种“首包必丢”是SDN的正常现象不是你的拓扑搭错了。3.2 带宽限制与链路质量模拟让实验数据更像真实网络课程设计的评分点往往不只是“能通”还要有数据支撑。Mininet的TCLink可以给每条链路加带宽、延迟、丢包率这是它比纯软件仿真强的地方——因为tctraffic control是在内核里真正生效的。下面这段命令在已有拓扑上动态修改链路参数mininet py net.configLinkStatus(s1, s2, 1) mininet py net.links[0].intf1.config(bw10, delay5ms, loss1, max_queue_size1000)第一行的configLinkStatus把链路置为up1或down0用于模拟链路故障。第二行的config方法直接对接口配置带宽单位Mbps、延迟、丢包率max_queue_size设置队列深度对应真实交换机端口的缓存大小。配置完成后用iperf验证带宽限制是否生效mininet h1 iperf -s -p 5001 mininet h2 iperf -c 10.0.0.1 -p 5001 -t 10 -i 1iperf的-t 10表示测试10秒-i 1表示每1秒打印一次结果。如果链路带宽配了10Mbpsiperf的输出会稳定在9.x Mbps附近这是tc限速后的正常表现。这里常被误解的一点是Mininet里所有主机共享同一个内核协议栈带宽限制的单位是“每个接口”不是“每台主机”。如果h1上有两个接口分别连了两条链路每条链路各限10Mbps那么h1的总吞吐理论上可以达到20Mbps这个细节写进报告里会显得你确实理解原理。3.3 控制器下发流表手写一个最简单的转发逻辑用Ryu的现成App能跑通但课程设计通常要求你展现对OpenFlow协议的理解所以至少要自己写一个控制器应用。最常见的实现是“二层MAC学习转发”用Python写Ryu应用只需要两个关键函数from ryu.base import app_manager from ryu.controller import ofp_event from ryu.controller.handler import MAIN_DISPATCHER, set_ev_cls from ryu.ofproto import ofproto_v1_3 class LearningSwitch(app_manager.RyuApp): OFP_VERSIONS [ofproto_v1_3.OFP_VERSION] def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.mac_table {} set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): msg ev.msg datapath msg.datapath ofproto datapath.ofproto parser datapath.ofproto_parser in_port msg.match[in_port] dpid datapath.id eth msg.data # 这里简化处理实际要解析以太网帧头部 dst_mac eth[0:6] src_mac eth[6:12] self.mac_table.setdefault(dpid, {}) self.mac_table[dpid][src_mac] in_port if dst_mac in self.mac_table[dpid]: out_port self.mac_table[dpid][dst_mac] else: out_port ofproto.OFPP_FLOOD actions [parser.OFPActionOutput(out_port)] out parser.OFPPacketOut(datapathdatapath, buffer_idmsg.buffer_id, in_portin_port, actionsactions) datapath.send_msg(out)这段代码的逻辑就是交换机收到未知报文时触发Packet-In事件控制器学习源MAC和端口的映射关系如果目的MAC已知就定向转发否则泛洪。真正提交课程设计时你还需要把流表下发FlowMod的部分补上否则每个包都会上送控制器性能极差。下发流表的动作是parser.OFPFlowMod需要指定match、instructions和priority参数并不复杂但你要理解流表项是带优先级的重叠的匹配规则后下发的高优先级生效。启动方式和前面一样sudo ryu-manager learning_switch.py观察启动日志会看到registered datapath之类的信息。然后启动Mininet连上来在mininet里执行dpctl dump-flows查看交换机里实际落地的流表mininet dpctl dump-flows -O OpenFlow13如果控制器工作正常这个命令能看到table-miss以外的流表项例如priority1,dl_dst00:00:00:00:00:02,actionsoutput:2。这组数据就是课程设计报告的“证据”它证明了控制器确实把转发决策写进了数据面。3.4 链路故障与恢复验证SDN的“网络自愈”SDN课程设计里高频出现的题目是“模拟链路故障并观察流量切换”。做法也很直接在Mininet CLI里断开一条正在承载流量的链路观察iperf的吞吐变化再恢复链路看SDN控制器能不能重新计算出新路径。步骤是这样mininet h1 iperf -s -p 5001 mininet h2 iperf -c 10.0.0.1 -p 5001 -t 60 -i 1 mininet link s1 s2 down mininet link s1 s2 uplink s1 s2 down会直接关闭s1和s2之间的虚拟网卡链路状态变化会触发OVS向控制器发送PortStatus消息。如果控制器实现了故障恢复逻辑比如重算路径并下发新的流表iperf的吞吐会在短暂掉零后恢复如果控制器没有这个逻辑流量就永久中断了。这里要注意的是Ryu的simple_switch_13没有链路恢复能力你需要自己做拓扑发现和路径重算或者用ONOS的reactive routing应用。做这个实验时的关键观察指标是“中断时长”。从iperf的输出能看到吞吐掉到0的时间点通过对比链路down的时间戳就能算出控制器的恢复时延。如果恢复时延超过秒级先检查控制器日志里有没有PortStatus事件输出没有的话说明OVS的事件上报配置有问题多半是在启动Mininet时没有用OpenFlow13协议导致事件版本不匹配。4. 把实验数据变成课程设计报告抓包、测速与可视化证据链4.1 抓包证据用tcpdump和Wireshark留下控制面报文课程设计报告不能只有代码和文字说明要有截图和报文分析。Mininet里抓包有两个层次在Mininet内部抓和在宿主机上抓。在Mininet内部抓包最直接的方法是用每个虚拟主机自己的tcpdumpmininet h1 tcpdump -i h1-eth0 -w /tmp/h1.pcap mininet h2 ping -c 5 10.0.0.1-w把报文保存成pcap文件这个文件在宿主机对应路径下也能读到直接用Wireshark打开分析。如果安装了Wireshark图形界面也可以把文件拷出来打开。注意Mininet里的tcpdump不一定默认安装需要先在宿主机上sudo apt install tcpdump因为虚拟主机共享宿主机的内核但用的是独立的目录视图命令本身需要宿主机上有。抓SDN控制面的报文OpenFlow协议需要另一招在宿主机上监听控制器和交换机通信的TCP 6653端口sudo tcpdump -i any -s 0 -w /tmp/openflow.pcap port 6653这样抓到的是OpenFlow的Packet-In、FlowMod、PortStatus等控制报文。课程设计里如果能展示一张Wireshark截图上面标注出Packet-In是IPv4还是ARP、FlowMod里match的字段是什么报告的档次会明显不一样。我见过很多学生的报告通篇只有pingall的输出那只能说明实验跑通了不能说明理解了SDN。4.2 用iperf3做带宽对比测试一个数据表胜过三段文字带宽测试推荐用iperf3而不是iperf前者持续维护中报告里引用也规范。Mininet默认装的是iperf如果要iperf3需要自行安装sudo apt install -y iperf3 mininet h1 iperf3 -s -p 5201 mininet h2 iperf3 -c 10.0.0.1 -p 5201 -t 15 -i 1记录下两组数据带宽限制前后的吞吐、链路中断与恢复前后的吞吐。建议每组测试跑三次取平均值因为Linux内核协议栈和tc队列的行为会有微小波动。整理成一张对比表实验条件平均吞吐(Mbps)首包延迟(ms)说明无带宽限制9400.5回环接口接近线速限速10Mbps9.61.2略低于设定值属正常链路down期间0无法连通无控制器恢复策略链路up后无恢复逻辑0无法连通流表未更新流量仍走旧端口这张表放在报告里比大段文字描述“链路断了以后流量中断了”有力得多。注意表格里的数字只是示例你的实验结果可能有差异但趋势应该一致。4.3 拓扑可视化Mininet自带的绘图能力Mininet没有直接输出拓扑图的命令常见做法是用Python的networkx加matplotlib或者用Graphviz。其实更省事的是在启动Mininet的时候让控制器输出拓扑信息如果你用Ryuryu-manager配合ryu.topology.switches模块会在日志里打印拓扑变化但那不是图。想要一张能放进报告的拓扑图最快的办法是写一个脚本读Mininet的links()和hosts()然后输出Graphviz的dot格式from mininet.net import Mininet from mininet.topo import SingleSwitchTopo net Mininet(topoSingleSwitchTopo(3)) net.start() with open(/tmp/topo.dot, w) as f: f.write(graph G {\n) for host in net.hosts: f.write(f {host.name} [shapebox];\n) for link in net.links: f.write(f {link.intf1.node.name} -- {link.intf2.node.name};\n) f.write(}\n) net.stop()生成dot文件后在宿主机上执行dot -Tpng /tmp/topo.dot -o topo.png就能得到拓扑图。对课程设计来说这张图能直接复用进报告的“实验环境”章节。图形化的价值在于评审老师从图上一眼就能看出你设计的网络结构是树形、环形还是网状这决定了你后面流表设计的复杂度描述是否可信。4.4 报告组织把实验过程整理成评审愿意给高分的结构课程设计报告的结构有固定套路但大部分人会把精力花在“写原理”而不是“写证据”。一个常见误区是原理部分抄教材抄了三页实验结果只有一张pingall截图。按我的经验这份报告的评审关注点是拓扑是怎么设计的、控制器实现和SDN原理的对应关系、实验数据能不能支撑结论。建议按下面这四块组织报告章节内容要点需要展示的证据需求分析题目要求还原成网络需求例如VLAN隔离、带宽保证需求转换表方案设计拓扑结构图、控制器的选择理由、OpenFlow版本选择拓扑图、序列图实验记录分步记录每条命令的输出、抓包截图、流表dump结果终端截图、pcap文件、dpctl输出数据与分析带宽、时延、丢包率的数据表和异常分析iperf输出、对比表格最后一块“数据与分析”是大多数人写得最差的。不要只写“结果符合预期”要写“为什么符合预期”比如限速10Mbps时iperf测到9.6Mbps而不是10Mbps是因为tc的令牌桶算法和TCP拥塞控制之间的交互带宽里有约0.4Mbps被TCP ACK报文占用这是协议行为不是配置错误。这种解释才是加分的点。5. Mininet实验避坑指南五条真实翻车记录与排查路径5.1 交换机和控制器的版本协商失败现象Ryu启动后日志反复打印EventOFPPortStatus或者一堆Hello handshake failedMininet里dpctl dump-flows看不到任何流表主机之间ping不通。原因Mininet创建的OVS默认使用OpenFlow10而Ryu的App声明只支持OpenFlow13。双方Hello报文里的版本号不匹配协商直接失败。另一个原因是端口号老教程里用的是6633新版Ryu默认监听6653控制器的配置里如果写着port6633TCP连接虽然能建立但OpenFlow版本字段对不上。解决在创建交换机时显式指定协议版本。用命令行的方式就是在启动Mininet时加参数--switch ovs,protocolsOpenFlow13用Python脚本就是在addSwitch里写protocolsOpenFlow13。启动Ryu时如果日志还是报错用ss -lnt | grep 6653确认监听端口再用lsof -i:6653查一下是不是被别的进程占用了。5.2 带宽限速不生效iperf结果和没限速一样现象明明在TCLink里设置了bw10但iperf测出来的吞吐还是接近千兆。原因绝大多数情况下是因为用的不是TCLink。默认的Link类型不带tc参数它就是一个纯veth对没有带宽整形能力。另一个原因是限速配在了错误的接口上比如给s1-eth1限速但流量实际走的是s1-eth2。解决确保Mininet初始化时指定linkTCLink不管是在命令行加--linktc还是在Python脚本里Mininet(..., linkTCLink)。配置限速后用tc qdisc show查看接口上的队列规则确认有没有htb或tbf队列出现。没有的话就是限速根本没落到这个接口上。5.3 主机之间ping不通但流表里看起来有规则现象pingall结果丢包率0%但实际业务流量不通或者某些主机能通但另一些不通。原因SDN交换机在连接控制器之后默认的NORMAL转发动作通常失效。真正的转发行为完全由流表决定如果控制器没有下发对应流表数据包会全部触发table-miss上送控制器或者被丢弃。还有一类隐蔽问题流表里匹配的是MAC地址但ARP请求是广播报文控制器如果对广播报文下发的是output:controller的动作ARP请求永远到不了目的主机。解决先dpctl dump-flows -O OpenFlow13确认流表里有dl_dstff:ff:ff:ff:ff:ff对应的广播处理规则。很多学习交换机App没有正确处理广播需要在控制器里单独处理ARP和IPv4广播应该泛洪单播才做精确匹配。写报告的时候把这条规则单独贴出来能体现你确实排查过问题。5.4 重启之后Mininet报“cannot find required executable mn”现象上次关机前还能正常运行Mininet重启后mn命令找不到或者cgroup相关报错。原因Mininet安装时依赖的部分服务和路径没有持久化。常见的是环境变量PATH没有包含/usr/local/bin因为源码编译安装会把mn脚本放到这个目录而当前shell的PATH里没有它。解决先which mn确认找不到就用绝对路径/usr/local/bin/mn跑一次没问题就把export加到~/.bashrc里。更省事的方式是重新执行一次sudo ./util/install.sh -n它会修复符号链接和依赖。另外Mininet对Linux内核版本敏感建议用长期支持版内核新内核偶发兼容性问题。5.5 在VMware虚拟机里跑Mininet网络行为异常现象宿主机是Windows虚拟机里Ubuntu跑Mininet出现虚拟主机之间延迟忽高忽低甚至丢包。原因VMware的虚拟网卡本身会引入时间扰动尤其是NAT模式下veth对的报文处理经过宿主机协议栈表现很不稳定。另一个坑是虚拟机的CPU默认不开启嵌套虚拟化Mininet本身不需要KVM但某些报告可视化工具会依赖虚拟化指令。解决把虚拟机网络模式改成桥接或者直接给虚拟机分配多个虚拟CPU核心并在VMware里启用“虚拟化 Intel VT-x/EPT”。如果你的课程设计规模较大建议直接用物理机装Ubuntu用虚拟机跑Mininet的翻车概率高出一个数量级这不是环境玄学是真实踩过的坑。6. 用Mininet做一次端到端验证从拓扑到流量工程的进阶检查课程设计验收时老师问得最多的一个问题是“你只证明了ping能通但SDN比传统网络强在哪”要回答这个你得从“打通”升级到“流量可控”。这里给一个可以现场演示的进阶检查方案用Ryu控制器加上一个简单的静态路由应用让Mininet里的两台主机通过两条不同路径通信然后手动断开其中一条链路观察控制器是否能把流量切换到备份路径。具体做法不需要很复杂在Ryu里写一个响应链路down事件的App事件回调里删除相关流表让交换机重新触发Packet-In再按新拓扑决策转发。这一步的重点是验证两条路径之间有一个“切换触发点”你可以用ab或者连续ping记录下切换瞬间的丢包数。如果丢包少于3个说明你的控制器在毫秒级完成了重路由如果丢包几十个说明数据面流表超时时间设得太长idle_timeout设30秒的话链路恢复后最长要等30秒流表才失效这期间流量是断的。调小idle_timeout能改善但会增加Packet-In频率这就是SDN里“响应速度”和“控制开销”的权衡比单纯跑通实验有价值得多。做完这个检查整理结果时有三个固定动作第一把dpctl dump-flows的完整输出存成文本作为数据面的原始证据第二把iperf的JSON输出iperf3 -J存下来方便生成图表第三把OpenFlow抓包的pcap文件压缩存档万一报告评审对某个结果有疑问可以回放报文。我自己的习惯是每完成一个阶段就sudo tar czf lab_$(date %Y%m%d_%H%M).tar.gz /tmp/*.pcap /tmp/*.dot固定存档这种习惯在实验多、反复改配置的时候特别管用免得最后交报告时找不到过程数据。希望这套从环境搭建到证据收集的路径能帮你把这份课程设计真正做成一个拿得出手的SDN入门作品希望帮到你。本文还有配套的精品资源点击获取