SDN实战入门：从Mininet+Ryu环境搭建到防火墙与负载均衡实验

简介：本资源为西安交通大学计算机专业《软件定义网络》课程配套实验作业包，面向高校网络方向本科生及SDN初学者，聚焦OpenFlow协议实践、Mininet拓扑构建、Ryu控制器开发与网络行为分析等核心能力训练。压缩包共73个文件，含20个Python控制器脚本（如network_awareness.py、shortest_path.py）、31张实验截图与拓扑图（png/jpg）、5份Markdown实验报告与4份PDF指导手册（含guidebook1-4.pdf），另有Shell脚本、Mininet配置文件及补丁文件等，全面覆盖Lab1-Lab4四阶段实验任务，总大小24.17MB。已有68人下载学习，资源结构清晰，按实验编号分目录组织，每个lab均包含可运行拓扑生成脚本、控制器实现、测试用例与完整报告模板，便于读者复现实验、理解SDN控制逻辑抽象与流表编程机制，并掌握网络感知、最短路径转发、广播环路抑制等典型场景的工程实现思路。

1. 项目概述：从一份课程作业看SDN实战入门

最近在整理资料时，翻到了当年在西安交大计算机系学习《软件定义网络》这门课时，完成的一系列Lab作业压缩包。这个名为“lab作业.zip”的文件，里面装的不仅仅是几行代码和实验报告，更像是一把钥匙，开启了我对现代网络架构从“黑盒”到“白盒”认知的大门。对于很多计算机、网络工程甚至网络安全方向的同学来说，SDN（软件定义网络）已经从一个前沿概念变成了必须掌握的核心技能点。无论是为了应对课程大作业、准备面试，还是真正想理解云数据中心、5G核心网背后的流量调度逻辑，动手做几个SDN实验都是最有效的途径。

这份作业包的核心，就是通过一系列由浅入深的实验，让你亲手“定义”网络。传统网络中，交换机、路由器这些设备各自为政，配置复杂且僵化。而SDN的核心思想是控制与转发分离：将网络设备的控制逻辑（大脑）抽离出来，集中到一个称为控制器的软件中，而设备本身（交换机）只负责根据控制器下发的流表进行高速数据转发（手脚）。这样一来，网络就变得像软件一样可编程、可灵活调度。我们的实验，正是围绕如何编写这个“大脑”（控制器应用）以及如何给“手脚”（交换机）下达指令来展开的。如果你正在为类似的课程作业、毕业设计甚至仅仅是技术好奇而搜索“SDN lab”，那么我接下来拆解的这些内容，或许能给你提供一个清晰的路线图。

2. 实验环境搭建与工具选型解析

动手之前，先把“厨房”收拾好。SDN实验环境搭建是第一个拦路虎，但一旦配置妥当，后续所有实验都会顺畅无比。我们的实验主要基于Mininet和Ryu控制器这一经典组合，这也是国内外多数高校SDN课程的首选。

2.1 为什么选择Mininet + Ryu？

市面上SDN仿真和实验平台不少，比如基于容器的、基于GNS3集成真实镜像的。但Mininet+Ryu的组合在教学和入门实践上优势明显：

• 轻量且保真：Mininet通过进程虚拟化在一台机器上快速创建包含主机、交换机、链路的真实网络，其创建的OpenFlow交换机与硬件交换机在数据平面行为上高度一致，但资源消耗远低于虚拟机。
• Python友好：无论是Mininet的自定义拓扑脚本，还是Ryu控制器的应用开发，都主要使用Python。这对于学生和开发者来说，学习曲线平缓，调试方便。
• 生态成熟：资料多，社区活跃。你遇到的大部分问题，几乎都能找到解决方案。

我当时的选择是在Ubuntu 20.04 LTS的虚拟机中完成所有实验。Windows用户可以通过WSL2或VirtualBox安装Ubuntu来实现。一个关键避坑点：务必确保你的虚拟化平台（如VMware或VirtualBox）已开启虚拟化支持（Intel VT-x/AMD-V），并在BIOS中启用，否则Mininet的性能会极差甚至无法运行。

2.2 一步步搭建你的实验台

1. 系统与基础依赖：

   sudo apt update sudo apt upgrade sudo apt install git python3-pip mininet

   安装Mininet时，推荐使用apt安装稳定版本。安装完成后，运行sudo mn --test pingall进行快速测试，如果所有虚拟主机都能相互ping通，说明Mininet核心功能正常。

2. 安装Ryu控制器： Ryu的安装建议通过pip进行，并最好在Python虚拟环境中操作，以避免包冲突。

   pip3 install virtualenv virtualenv ryu-env source ryu-env/bin/activate pip install ryu

   安装完成后，可以通过ryu-manager --version查看是否成功。

3. 安装Open vSwitch（OVS）： Mininet默认使用的交换机内核可能不支持所有OpenFlow特性。为了进行更高级的实验（如VLAN、QoS），我们需要安装用户态的OVS。

   sudo apt install openvswitch-switch sudo systemctl start openvswitch-switch sudo systemctl enable openvswitch-switch

   实操心得：很多教程会教你从源码编译OVS，但对于入门实验，apt安装的版本完全足够，能省去大量解决编译依赖的时间。

4. 配置可视化工具（可选但推荐）： 为了直观地看到网络拓扑和流量，可以安装Mininet的图形化界面和Ryu的拓扑查看器应用。

   • 对于Mininet，可以在自定义拓扑Python脚本中，在创建Mininet对象时加入controller=RemoteController，然后运行脚本后使用mininet> py net.plot()（需提前安装matplotlib）生成拓扑图。
   • 对于Ryu，运行控制器时加载ryu.app.gui_topology.gui_topology应用，即可通过浏览器访问http://<控制器IP>:8080查看实时拓扑。

环境搭好只是第一步，就像盖房子打好了地基。接下来，我们要开始设计房子的蓝图——网络拓扑。

3. 核心实验一：基础拓扑构建与连通性测试

第一个实验通常是“Hello World”级别的，目标是熟悉Mininet的API，创建一个自定义拓扑，并验证主机间的连通性。

3.1 设计一个简单的自定义拓扑

我们不会满足于Mininet自带的单一线性或树形拓扑。假设我们要创建一个简单的“数据中心脊叶拓扑”的微缩版：2台核心交换机（Spine）和4台接入交换机（Leaf），每台Leaf下连接2台主机。

#!/usr/bin/env python3 from mininet.topo import Topo from mininet.net import Mininet from mininet.cli import CLI from mininet.log import setLogLevel class MyTopo(Topo): def build(self): # 创建交换机 spine1 = self.addSwitch('s1') spine2 = self.addSwitch('s2') leaf1 = self.addSwitch('s3') leaf2 = self.addSwitch('s4') leaf3 = self.addSwitch('s5') leaf4 = self.addSwitch('s6') # 创建主机，并连接到Leaf交换机 for i in range(1, 5): # leaf1和leaf2 host = self.addHost(f'h{i}') self.addLink(host, leaf1 if i<=2 else leaf2) for i in range(5, 9): # leaf3和leaf4 host = self.addHost(f'h{i}') self.addLink(host, leaf3 if i<=6 else leaf4) # 连接Spine和Leaf (Full Mesh) for spine in [spine1, spine2]: for leaf in [leaf1, leaf2, leaf3, leaf4]: self.addLink(spine, leaf) if __name__ == '__main__': setLogLevel('info') topo = MyTopo() # 关键：这里指定使用Ryu作为远程控制器 net = Mininet(topo=topo, controller=None) net.addController('c0', controller=RemoteController, ip='127.0.0.1', port=6633) net.start() CLI(net) # 进入Mininet命令行交互界面 net.stop()

关键点解析：controller=None和后续的addController是为了让我们能够连接外部的Ryu控制器，而不是Mininet自带的简易控制器。port=6633是OpenFlow协议的默认端口。

3.2 启动控制器并测试连通性

1. 启动Ryu控制器：首先在一个终端窗口，运行一个最简单的Ryu应用（例如二层学习交换机）。

   ryu-manager ryu.app.simple_switch_13

   simple_switch_13是Ryu内置的一个应用，实现了支持OpenFlow 1.3协议的简易学习交换机逻辑，它会自动处理ARP和MAC地址学习。

2. 运行拓扑脚本：在另一个终端窗口，运行你刚才写的Python脚本。

   sudo python3 my_topo.py

   此时，Mininet会创建拓扑，并尝试连接到运行在127.0.0.1:6633的Ryu控制器。在Ryu的终端，你应该能看到交换机连接的日志信息。

3. 测试连通性：在Mininet的命令行界面（mininet>），进行测试。

   mininet> pingall

   如果所有主机都能相互ping通，恭喜你，你的第一个SDN网络已经跑通了！这意味着Ryu控制器成功接管了所有交换机，并正确下发了流表，使得数据包能够被正确转发。

常见问题与排查：

• 问题：pingall失败，提示Host Unreachable。
• 排查：
  1. 首先检查Ryu控制器是否正常运行，是否有交换机连接的日志。
  2. 在Mininet CLI中，使用net命令检查拓扑链接是否正确，例如net。
  3. 使用dpctl命令查看某个交换机的流表，例如sh ovs-ofctl dump-flows s1（需在主机shell中执行，或Mininet CLI中使用h1 ovs-ofctl ...）。如果流表为空，说明控制器可能没有成功下发流表，检查控制器应用逻辑和网络连接。
• 实操心得：在复杂拓扑中，初次pingall可能会因为ARP请求超时而部分失败。可以尝试先让h1 ping h2一次，触发ARP学习，然后再执行pingall，成功率会高很多。这是因为学习交换机的流表是“按需”生成的。

4. 核心实验二：实现自定义转发逻辑（防火墙）

掌握了基础连通性后，我们要开始编程了。第二个经典实验是实现一个简单的SDN防火墙。传统防火墙需要逐台设备配置ACL（访问控制列表），而在SDN中，我们只需在控制器上写一段逻辑，就能统一管理所有交换机的转发规则。

4.1 理解OpenFlow流表与匹配-动作范式

在动手写代码前，必须理解OpenFlow交换机如何工作。它维护着一张流表，每个流表项包含：

• 匹配域：匹配数据包的特征，如源/目的IP、MAC、端口号、协议类型等。
• 优先级：数字越高，优先级越高。
• 计数器：统计匹配的数据包和字节数。
• 指令：匹配后执行的动作，例如：转发到某个端口、丢弃、修改报文头、跳转到其他流表等。

我们的防火墙目标很简单：禁止特定两个主机（比如h1和h5）之间的所有IP通信。

4.2 编写Ryu防火墙应用

我们将创建一个新的Python文件my_firewall.py。

from ryu.base import app_manager from ryu.controller import ofp_event from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER from ryu.controller.handler import set_ev_cls from ryu.ofproto import ofproto_v1_3 # 使用OpenFlow 1.3 from ryu.lib.packet import packet, ethernet, ipv4 class SimpleFirewall13(app_manager.RyuApp): OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION] def __init__(self, *args, **kwargs): super(SimpleFirewall13, self).__init__(*args, **kwargs) # 定义被禁止的通信对：(源IP, 目的IP) self.blocked_pairs = [('10.0.0.1', '10.0.0.5'), ('10.0.0.5', '10.0.0.1')] @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER) def switch_features_handler(self, ev): """交换机连接时，下发默认流表（丢弃所有未知流量）""" datapath = ev.msg.datapath ofproto = datapath.ofproto parser = datapath.ofproto_parser # 添加一条默认的TABLE-MISS流表项，优先级为0，动作为转到控制器 match = parser.OFPMatch() actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER, ofproto.OFPCML_NO_BUFFER)] self.add_flow(datapath, 0, match, actions) # 下发防火墙规则（优先级更高） self.install_firewall_rules(datapath) def add_flow(self, datapath, priority, match, actions): """通用的添加流表项函数""" ofproto = datapath.ofproto parser = datapath.ofproto_parser # 构造FlowMod消息 inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS, actions)] mod = parser.OFPFlowMod(datapath=datapath, priority=priority, match=match, instructions=inst) datapath.send_msg(mod) def install_firewall_rules(self, datapath): """安装具体的防火墙规则""" parser = datapath.ofproto_parser for src_ip, dst_ip in self.blocked_pairs: # 匹配特定IP对的数据包 match = parser.OFPMatch(eth_type=0x0800, # IPv4 ipv4_src=src_ip, ipv4_dst=dst_ip) # 动作为空列表，即丢弃 self.add_flow(datapath, 10, match, []) @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): """处理交换机上传的未知数据包（例如ARP）""" # 这里可以实现学习交换机逻辑，或者直接泛洪处理ARP msg = ev.msg datapath = msg.datapath ofproto = datapath.ofproto parser = datapath.ofproto_parser pkt = packet.Packet(msg.data) eth = pkt.get_protocol(ethernet.ethernet) # 如果是ARP请求/回复，进行泛洪 if eth.ethertype == 0x0806: # ARP actions = [parser.OFPActionOutput(ofproto.OFPP_FLOOD)] out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id, in_port=msg.in_port, actions=actions, data=msg.data) datapath.send_msg(out)

代码逻辑拆解：

1. switch_features_handler：当交换机首次连接到控制器时触发。我们做两件事：一是添加一条低优先级（0）的默认流表，将不匹配任何规则的数据包（如初始的ARP请求）发送给控制器处理；二是调用install_firewall_rules安装高优先级（10）的防火墙规则。
2. install_firewall_rules：遍历我们定义的禁止通信的IP对，为每一对创建一条匹配项，动作为空（即丢弃）。
3. packet_in_handler：处理被默认流表送上来的数据包。这里我们简单处理了ARP协议，直接泛洪，以保证网络基础发现功能正常。

4.3 实验验证

1. 停止之前运行的Ryu控制器，用我们的防火墙应用启动：

   ryu-manager my_firewall.py

2. 再次启动Mininet拓扑。
3. 在Mininet CLI中测试：

   mininet> h1 ping h5

   此时，ping命令会一直卡住，因为ICMP请求包在进入交换机时，匹配到了我们下发的丢弃规则。而h1 ping h2（非禁止IP对）则应该是通的。
4. 关键验证步骤：登录到交换机上查看流表。 打开一个新的终端，运行：

   sudo ovs-ofctl -O OpenFlow13 dump-flows s1

   你会在输出中看到类似这样的流表项：

   cookie=0x0, duration=10.0s, table=0, n_packets=3, n_bytes=210, priority=10,ip,nw_src=10.0.0.1,nw_dst=10.0.0.5 actions=drop cookie=0x0, duration=10.0s, table=0, n_packets=0, n_bytes=0, priority=10,ip,nw_src=10.0.0.5,nw_dst=10.0.0.1 actions=drop cookie=0x0, duration=10.1s, table=0, n_packets=15, n_bytes=1134, priority=0 actions=CONTROLLER:65535

   这清晰地展示了我们下发的两条丢弃规则（优先级10）和一条默认上送控制器的规则（优先级0）。n_packets计数器显示了匹配到的包数量，这是调试和监控的宝贵信息。

注意事项：

• 规则冲突：我们的防火墙规则优先级（10）高于默认规则（0），因此会优先匹配。如果定义多条规则，必须仔细设计优先级。
• 状态与无状态：这是一个最简单的无状态防火墙，只检查单方向的一个数据包。更复杂的防火墙需要考虑连接状态（如允许已建立连接的返回流量），这需要应用层维护连接状态表。
• 性能考量：所有流表匹配都在交换机的TCAM（三态内容寻址存储器）中进行，速度极快。但TCAM资源有限，在大型网络中需要精心设计流表项，避免过度泛化匹配导致表项爆炸。

5. 核心实验三：实现负载均衡器

第三个实验难度升级，我们要实现一个简单的负载均衡器。场景是：一台虚拟服务器（VIP：10.0.0.100）背后有两台真实服务器（10.0.0.7, 10.0.0.8）。所有发往VIP的流量，由SDN交换机根据简单策略（如轮询）分发到后端的真实服务器。

5.1 设计负载均衡逻辑

这个实验综合运用了OpenFlow的组表和修改报文动作。组表是OpenFlow 1.1+引入的一个强大特性，允许定义一个动作桶列表，并指定选择桶的方式（如轮询、哈希、故障转移等）。 我们的设计如下：

1. 客户端（如h1）访问VIP（10.0.0.100）。
2. 边缘交换机（如Leaf1）收到数据包，匹配目的IP为VIP。
3. 交换机执行一个GROUP动作，指向一个SELECT类型的组。
4. 组内有两个动作桶：
   • 桶1：修改目的IP为10.0.0.7，并从端口3转发。
   • 桶2：修改目的IP为10.0.0.8，并从端口4转发。
5. 组表会按照轮询算法选择一个桶执行，从而实现负载均衡。
6. 真实服务器处理完请求后，返回的报文源IP是其自身地址（10.0.0.7/8），需要边缘交换机再将其源IP修改回VIP，才能返回给客户端。这通常需要另一条流表项来处理回程流量。

5.2 编写Ryu负载均衡应用

由于代码较长，这里概述核心部分，关键在switch_features_handler中设置组表和流表。

class SimpleLoadBalancer13(app_manager.RyuApp): OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION] VIP = '10.0.0.100' REAL_SERVERS = [('10.0.0.7', 3), ('10.0.0.8', 4)] # (IP, out_port) def switch_features_handler(self, ev): datapath = ev.msg.datapath ofproto = datapath.ofproto parser = datapath.ofproto_parser # 1. 创建SELECT类型的组 buckets = [] for server_ip, out_port in self.REAL_SERVERS: actions = [ parser.OFPActionSetField(ipv4_dst=server_ip), # 修改目的IP parser.OFPActionOutput(out_port) # 从指定端口转发 ] bucket = parser.OFPBucket(actions=actions) buckets.append(bucket) group_id = 1 req = parser.OFPGroupMod(datapath, ofproto.OFPGC_ADD, ofproto.OFPGT_SELECT, group_id, buckets) datapath.send_msg(req) # 2. 添加流表项，匹配目的IP为VIP的流量，执行GROUP动作 match = parser.OFPMatch(eth_type=0x0800, ipv4_dst=self.VIP) actions = [parser.OFPActionGroup(group_id=group_id)] self.add_flow(datapath, 20, match, actions) # 3. 添加处理回程流量的流表项（从真实服务器回来） for server_ip, in_port in self.REAL_SERVERS: match = parser.OFPMatch(eth_type=0x0800, ipv4_src=server_ip, in_port=in_port) actions = [ parser.OFPActionSetField(ipv4_src=self.VIP), # 修改源IP为VIP parser.OFPActionOutput(ofproto.OFPP_NORMAL) # 正常转发（或指定到客户端的端口） ] self.add_flow(datapath, 20, match, actions)

关键点解析：

• OFPGT_SELECT：表示组类型为选择，控制器可以指定选择算法（如轮询、哈希），默认通常是轮询。
• OFPActionSetField：这是修改报文头字段的关键动作。注意，不是所有交换机都支持修改所有字段，需要查证其支持的OpenFlow能力集。
• 回程流量处理：这是负载均衡器实现中容易遗漏的一环。必须将真实服务器返回报文的源IP改回VIP，否则客户端会发现收到的回复来自一个未知的IP，导致连接中断。

5.3 实验验证与排错

1. 在Mininet拓扑中，确保h7和h8作为真实服务器，并运行简单的HTTP服务（如python3 -m http.server 80）。
2. 启动负载均衡控制器应用。
3. 从客户端h1不断访问VIP：h1 curl 10.0.0.100。
4. 观察h7和h8的服务器日志，应该能看到请求被交替访问。

常见问题：

• 问题一：客户端curl命令超时或无法连接。
• 排查：
  • 检查组表和流表是否下发成功：sudo ovs-ofctl -O OpenFlow13 dump-groups s1和dump-flows s1。
  • 检查动作OFPActionSetField是否被交换机支持。有些旧版本或简化实现的虚拟交换机可能不支持修改IP地址。可以尝试先用OFPActionOutput直接转发到某一台服务器，测试基础路径是否通。
  • 使用Wireshark抓包：这是最强大的排错手段。在Mininet CLI中，可以在主机或交换机上启动tcpdump。例如，在h1上抓取发往VIP的包：mininet> h1 tcpdump -i h1-eth0 -nn host 10.0.0.100。观察数据包在经过负载均衡交换机后，目的IP是否被正确修改。
• 问题二：客户端能收到回复，但curl提示curl: (56) Recv failure: Connection reset by peer。
• 排查：这通常是回程流量处理有问题。检查从服务器端口（3,4）进入的流量，其流表项是否正确将源IP改回了VIP。同样，抓包查看从h7或h8返回的报文，其源IP在离开边缘交换机时是否变为了10.0.0.100。

实操心得：负载均衡实验是理解SDN“软件定义”威力的绝佳例子。在传统网络中，要实现同样的四层负载均衡，你需要购买昂贵的硬件负载均衡设备或部署复杂的软件（如LVS、Nginx）并配置复杂的路由策略。而在SDN中，你只需在控制器上编写百来行Python代码，就能在网络层实现相同的功能，并且策略变更极其灵活。这个实验也深刻揭示了SDN的一个核心优势：将复杂的网络功能从专用硬件中解耦，通过通用软件实现，并集中控制。

6. 实验拓展与性能调优思考

完成上述三个核心实验，你已经掌握了SDN入门的关键技能：环境搭建、拓扑创建、基础转发、安全策略和高级流量工程。但这份作业的延伸价值远不止于此。基于此，你可以进行更多探索：

6.1 拓展方向建议

1. 网络状态监控：在Ryu应用中集成ryu.app.ofp_monitor，实时收集交换机的端口统计信息、流表计数器，并可视化展示网络流量。这能让你理解网络的“呼吸”。
2. QoS（服务质量）保障：利用OpenFlow的计量表和队列，为特定流量（如视频流）提供带宽保障或限制。例如，在拓扑中实现保证h1到h2的流量至少有10Mbps的带宽。
3. 路径故障快速切换：利用Ryu的拓扑发现功能（ryu.topology），实时监控链路状态。当检测到某条链路故障时，自动计算新的最优路径并下发流表，实现亚秒级的故障恢复，模拟SD-WAN中的关键能力。
4. 与云计算平台集成：尝试在OpenStack或Kubernetes环境中部署OVS，并让你的Ryu控制器去管理这些生产环境中的虚拟交换机，理解SDN在云原生中的实际应用。

6.2 性能调优与生产考量

课程实验通常在资源有限的虚拟环境中进行，但了解生产环境的挑战很重要：

• 控制器性能与可靠性：单点控制器是实验中的瓶颈和单点故障源。生产环境需要分布式控制器集群（如ONOS、OpenDaylight），通过东西向接口同步网络状态。
• 南向接口延迟：控制器与交换机之间频繁的Packet-In/Flow-Mod消息交互会引入延迟。解决方案是主动流表下发和表间流水线优化，尽可能让流量在数据平面快速转发，减少与控制器的交互。
• 流表规模管理：TCAM资源昂贵且有限。需要设计聚合流表项，避免为每一个微流（如每个TCP连接）都创建一条流表项。合理使用通配符和优先级。
• 安全加固：控制器API和通道必须严格认证和加密，防止恶意主机伪装成交换机接入或篡改流表。

回过头看，西安交大的这套SDN实验作业，设计得非常精妙。它没有停留在概念讲解，而是通过“连通性-防火墙-负载均衡”这条主线，让你亲手触摸到SDN的核心脉络：分离、集中、编程。每一个实验踩过的坑、解决的bug，都比读十篇论文更能加深理解。如果你正在完成类似的作业或项目，我的建议是：不要只满足于跑通代码。多问几个为什么，多用ovs-ofctl和tcpdump看看底层发生了什么，尝试修改参数看看结果如何变化。这份“lab作业.zip”解压开的，是一个充满可能性的软件定义世界。

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