前阵子一直在琢磨怎么在实验环境里完整复现一套校园网组网从核心到汇聚到接入加上VLAN划分和策略控制。但真拿几台物理交换机堆一个机架成本和精力都吃不消传统图形化模拟工具对SDN控制器和OpenFlow协议的支持又普遍偏弱。最后我把方案定在Mininet RYUMininet负责在一台机器里虚拟出交换机、终端主机和链路RYU作为SDN控制器统一管理所有交换机的转发行为。这篇是这个系列的第一篇先把整体架构思路、环境搭建、第一版核心-汇聚-接入拓扑跑通以及VLAN隔离怎么做讲清楚。如果你也想在实验室或自己电脑上复现一套SDN校园网这篇应该能帮你少走不少弯路。1. 为什么拿RYU和Mininet来设计校园网络1.1 校园网在SDN视角下的真实需求校园网的传统痛点不在于设备不够好而在于策略太多、变更太频繁。新学年要开新网段、某个学院临时要做带宽保障、办公区和学生宿舍要严格控制互访权限这些事情在传统网络里意味着网管一台一台登录交换机去敲命令行不同厂商设备语法还不一样改错了很难排查。SDN的思路是把“网络智能”从交换机里抽出来交给控制器统一处理。交换机只保留高速转发的数据平面MAC学习、VLAN隔离、ACL、路由这些控制逻辑全部集中到控制器里。对应到校园网的分层设计核心层负责高速转发和路由收敛汇聚层做策略控制和访问隔离接入层负责终端接入和端口安全。在SDN架构里这些策略可以变成控制器里的一段段应用开新业务就是下发新的流表规则改业务就是改控制器里的逻辑不用再去逐台运维设备。这就是我用SDN思路做校园网设计的根本动机。用Mininet仿真是因为它能把整套逻辑放到一台机器上验证用RYU做控制器是因为它轻量、Python生态好特别适合这种以教学和实验为目标的场景。1.2 控制器选型对比RYU胜在哪控制器是SDN架构的大脑选型是最容易纠结的一步。我实际对比过几个主流开源控制器最终选了RYU核心原因是它是Python写的和我熟悉的脚本语言完全对口。后期想写自定义应用比如按时间控制宿舍区网络、临时开个活动网段直接在Python里操作openflow消息就能完成。从资源占用看RYU起一个主进程只需要几百MB内存实验用的4核8G虚拟机可以轻松带起来。ONOS和OpenDaylight功能更完整适合生产级的大规模组网验证但启动就要吃掉2到4GB内存还要装Java环境、调集群配置第一节课就把学生吓跑了。RYU自带了大量现成的REST应用比如simple_switch_13、rest_vlan、ofctl_rest、qos这些都是做校园网功能拆分时能直接拿来用的积木。我给这个选型做过一个简单的对比对比维度RYUONOS/OpenDaylight商业控制产品开发语言PythonJava多为闭源资源占用低几百MB高至少2GB取决于厂商上手门槛低有Python基础就能写App中高模块多、概念重高自带REST应用多适合校园网场景企业级功能但学习成本高绑定硬件生态适合场景教学实验、快速原型、策略验证生产级SDN、多域网络现网规模化部署如果你做的不是实验验证而是真实的校园网建设那当然要另说。但在设计仿真阶段RYU是效率和灵活度最平衡的选择。1.3 仿真器选型Mininet不是唯一但最顺手Mininet能解决的问题是在一台机器上虚拟出一个完整网络。它用进程级虚拟化创建终端主机用Open vSwitch模拟交换机通过虚拟网卡和内核网络协议栈构建链路。我在虚拟机里跑过一套1台核心、2台汇聚、4台接入、12台主机的拓扑系统资源占用依然能接受而且想要多少台设备就加多少台改拓扑不用动物理设备。传统图形化模拟工具也能搭拓扑但在SDN实验里有两个问题一是模拟出来的交换机难以真正支持OpenFlow协议的各个版本控制器与其握手时经常出现协议版本不匹配二是它模拟的重点是设备系统行为而不是“数据平面和控制平面分离”这套SDN逻辑。Mininet则天然就是为SDN教学和实验设计的启动交换机后可以透明地把它连接到远程RYU控制器上OVS会主动发起OpenFlow连接这个过程可控性非常高。后面所有实验我都会围绕“Mininet里的交换机 RYU控制器”这个组合展开。2. 环境搭建第一关Mininet和RYU的安装与踩坑2.1 基础环境怎么准备最省心环境选型这件事我踩过不少坑。最开始在Windows上用WSL跑Mininet结果OVS的模块加载各种不兼容后来切到VMware虚拟机装Ubuntu 20.04 Server版一切顺畅了很多。如果你之前没装过建议直接按这个组合来Ubuntu 20.04 Server 4核CPU 8GB内存 30GB磁盘。桌面版也可以但Server版资源开销小后面用SSH或者直接在控制台操作都方便。配置建议这里多说一句内存尽量不要低于4GB因为Mininet每创建一台虚拟主机就会创建一个network namespace再加上OVS的进程内存太小会出现莫名其妙的启动失败。另外安装完系统后建议先做一次快照后面装环境或者跑实验时搞崩了直接回滚快照能省出大量重新配置的时间。2.2 Mininet安装不要只用apt很多初学者第一反应是sudo apt install mininet我在早期也这么干过。但apt源里的Mininet版本往往比较保守有可能是2.2.x甚至更老和当前主流RYU某些模块配合时会出现OpenFlow版本协商问题。更稳妥的方式是官方源码安装顺便把Open vSwitch、Wireshark这些配套工具也装好git clone https://github.com/mininet/mininet.git cd mininet util/install.sh -a-a参数的含义是安装所有组件包括Mininet本身、Open vSwitch、Wireshark、net-tools等。当然也可以拆开来装比如util/install.sh -n只装Mininet核心-v单独装OVS。新手我建议直接-a免得到时候缺东少西。安装完成后验证一下sudo mn --version sudo mn --test pingallsudo mn --test pingall会创建一个最简单的小型拓扑默认使用OVS交换机然后执行连通性测试。如果输出显示两个主机能ping通就说明Mininet和OVS工作正常。我当时在这一步遇到过no controller specified这样的提示其实不影响默认的自翻转测试但如果pingall全掉包大概率是OVS内核模块没加载好重启一下或者重新编译一下OVS模块就能解决。2.3 RYU安装版本是最大敌人RYU的安装推荐用pip直接装pip3 install ryu不过这里有一个大忌别在Python 3.10及以上版本里裸装最新版否则会踩到eventlet版本的坑。启动的时候报模块初始化失败、WSGI服务崩溃多半都是eventlet和Python版本不兼容导致的。我的做法是显式固定eventlet版本pip3 install eventlet0.30.2 pip3 install ryu如果你更喜欢源码方式也可以git clone https://github.com/faucetsdn/ryu.git cd ryu pip3 install -e .安装完成后执行ryu-manager --version能看到版本号即安装成功。RYU目前主流的稳定版本是4.34它支持OpenFlow 1.0到1.5但校园网实验里我强烈建议统一使用OpenFlow 1.3因为RYU的绝大多数应用默认基于这个版本兼容性最好。2.4 控制器和交换机第一次握手环境装好后先做一次最简单的SDN联通实验确认Mininet里的OVS交换机可以和RYU控制器正常握手。开两个终端窗口终端A启动控制器ryu-manager --observe-links ryu.app.simple_switch_13终端B启动Mininetsudo mn --topo single,3 --controller remote --protocols OpenFlow13关键就在--protocols OpenFlow13这个参数上。很多教程里只写了--controller remote没带协议版本结果控制器那边日志安安静静交换机也迟迟没有注册上来。原因在于Mininet默认的OVS可能会协商到OpenFlow10而RYU的应用大部分只监听OpenFlow1.3两边版本对不上握手自然就失败了。如果一切正常控制器终端会刷出一批日志里面能看到类似EVENTOFPStateChange和交换机能力等事件信息。这说明交换机已经成功注册到控制器上了。此时在Mininet CLI里执行pingall输出应该显示所有主机之间都能连通这是simple_switch_13这个应用在用控制器做MAC自学习的结果。3. 第一版校园网拓扑核心-汇聚-接入三层结构3.1 三层架构背后的设计逻辑校园网不管规模多大逻辑上基本都逃不开三层架构核心层、汇聚层、接入层。核心层跑高速转发处理跨区域的东西向流量通常要保证低延迟和高可用所以核心设备之间往往还有冗余链路。汇聚层是策略的集中点VLAN间路由、ACL访问控制、QoS带宽策略、组播边界都归纳在这一层。接入层直接面向终端用户负责接入认证、端口隔离、防DHCP欺骗等。SDN校园网同样沿用这个分层模型。核心层交换机在RYU里就是一台高速转发设备流表由控制器下发汇聚层交换机通过控制器加载VLAN和路由策略实现跨网段管控接入层交换机负责终端主机的接入隔离。这个架构清晰也便于后续逐层扩展功能。第一版拓扑我刻意没有做成双核心冗余。原因是双核心会牵扯到多路径、环路处理、故障切换这些复杂内容作为系列第一篇先把“单核心起跑、汇聚和接入正常挂载、控制器能管理转发”这套闭环跑通最重要。等VLAN间路由和策略控制做完再回来加双核心就有了对比基础而不是一次又叠加上来出了问题都不知道是哪一块导致的。3.2 用自定义Topo脚本把校园网跑起来Mininet支持在一条命令行里快速创建拓扑但校园网这个规模用命令行就没法维护了。正确的做法是写一个自定义Topo脚本。下面是我第一版使用的拓扑定义文件campus_topo.pyfrom mininet.topo import Topo class CampusTopo(Topo): def __init__(self): Topo.__init__(self) # 核心层1台 core self.addSwitch(c1, dpid0000000000000001) # 汇聚层2台 agg1 self.addSwitch(a1, dpid0000000000000002) agg2 self.addSwitch(a2, dpid0000000000000003) # 接入层4台 s1 self.addSwitch(s1, dpid0000000000000004) s2 self.addSwitch(s2, dpid0000000000000005) s3 self.addSwitch(s3, dpid0000000000000006) s4 self.addSwitch(s4, dpid0000000000000007) # 终端主机 h1 self.addHost(h1, ip192.168.10.1/24) h2 self.addHost(h2, ip192.168.10.2/24) h3 self.addHost(h3, ip192.168.20.1/24) h4 self.addHost(h4, ip192.168.20.2/24) h5 self.addHost(h5, ip192.168.30.1/24) h6 self.addHost(h6, ip192.168.30.2/24) h7 self.addHost(h7, ip192.168.40.1/24) h8 self.addHost(h8, ip192.168.40.2/24) # 核心到汇聚 self.addLink(core, agg1, bw1000, delay1ms) self.addLink(core, agg2, bw1000, delay1ms) # 汇聚到接入 self.addLink(agg1, s1, bw1000, delay1ms) self.addLink(agg1, s2, bw1000, delay1ms) self.addLink(agg2, s3, bw1000, delay1ms) self.addLink(agg2, s4, bw1000, delay1ms) # 接入到主机 self.addLink(s1, h1, bw100) self.addLink(s1, h2, bw100) self.addLink(s2, h3, bw100) self.addLink(s2, h4, bw100) self.addLink(s3, h5, bw100) self.addLink(s3, h6, bw100) self.addLink(s4, h7, bw100) self.addLink(s4, h8, bw100) topos {campus: CampusTopo}这里有一个容易被忽略的细节dpid参数。Open vSwitch每个交换机都有一个datapath_id默认是随机生成的但后续要通过REST API操作指定交换机时用固定dpid可以让控制器和API精确识别对象。比如dpid0000000000000001表示核心交换机c1的datapath_id是十六进制数字1。Mininet教程里经常省略这个参数但做校园网这种多台交换机的拓扑显式指定dpid能省去大量排查问题的时间。启动方式sudo mn --custom campus_topo.py --topo campus --controller remote --mac --protocols OpenFlow13--mac参数让虚拟主机的MAC地址按其编号排序生成比如h1的MAC就是00:00:00:00:00:01这样在查看流表和抓包时看到MAC就能直接对上主机体验非常好。3.3 IP地址和链路参数的规划校园网最大的特征是网段多、隔离需求多。第一版我把整个网络划分为四个区域对应四个C类网段区域网段网关规划后续VLAN ID教学区192.168.10.0/24192.168.10.25410办公区192.168.20.0/24192.168.20.25420宿舍区192.168.30.0/24192.168.30.25430服务器区192.168.40.0/24192.168.40.25440每个区域分配两个终端主机规模不大但足以验证连通性、隔离性和后续的路由策略。这里的网关地址在第二篇做VLAN间路由时会用到现在先预留出来。链路带宽参数也需要花点心思。bw1000表示1000Mbps即千兆核心到汇聚、汇聚到接入都按千兆规划模拟当前校园网的主流水平接入到主机按100Mbps也更贴近真实的终端接入速率。delay1ms是在链路上叠加1毫秒延迟可以让实验的QoS效果更真实。但注意Mininet的链路参数是通过Linux内核的tc实现的如果你本机CPU偏弱开的链路又太多tc配置可能会导致整个Mininet启动变慢甚至报错。2核4G或更低配置的机器建议第一版先把bw参数去掉跑通了再加。4. 把RYU接进来初始连通性与VLAN隔离4.1 启动顺序和参数选择控制器和Mininet的启动顺序建议始终是先控制器后Mininet。如果先起MininetOVS交换机在启动时发现控制器不可达会进入standalone模式自己以传统交换的方式工作等控制器起来后才会重新发起连接虽然最终也能连上但实验起始阶段就没那么干净了。我一般习惯开三个终端终端A跑RYU终端B跑Mininet终端C用来发curl请求或者看日志。这一章的初始连通性验证我先加载RYU自带的二层学习应用ryu-manager --observe-links ryu.app.simple_switch_13--observe-links参数让控制器定期交换LLDP报文来发现链路状态。虽然simple_switch_13本身不依赖它的结果但在这个系列后续要写的拓扑感知、REST配置里都是基础先带着跑没有坏处。随后在终端B启动刚才的自定义拓扑sudo mn --custom campus_topo.py --topo campus --controller remote --mac --protocols OpenFlow134.2 simple_switch_13下的全网互通验证启动完成后先在Mininet CLI里执行pingall第一次执行时RYU的simple_switch_13会逐个接收交换机送来的PacketIn消息通过MAC学习向未知目的端口泛洪随后下发精确到MAC地址的流表规则。因此第一遍pingall主要是触发学习第二遍开始才会看到完整的直连效果。如果输出显示全通说明控制器已经成功接管了所有交换机的转发行为。此时可以在Mininet CLI里查看核心交换机c1的流表c1 dpctl dump-flows -O OpenFlow13能看到类似dl_dstxx:xx:xx:xx:xx:xx actionsoutput:xxx的条目这就是控制器下发的二层转发流表。这里特别要注意-O OpenFlow13参数Mininet 2.3.0里如果不加默认用OpenFlow10去查流表和当前协议版本不一致会报错或者查不出内容。这个阶段全网是互通的四台接入交换机下的所有主机就像挂在同一个巨大二层交换机下面根本没有隔离。对校园网来说这种状态肯定不行教学区、办公区、宿舍区、服务器区必须隔离广播域否则一个区域的广播风暴就会拖垮全网。4.3 用REST API把VLAN切出来RYU自带了一个适合这个场景的应用——rest_vlan通过HTTP接口就能给交换机的各端口划分VLAN不需要自己写OpenFlow应用。先把控制器换到这个模式下ryu-manager --observe-links ryu.app.rest_vlan注意这里我刻意没有同时加载simple_switch_13。原因是simple_switch_13会同步下发基于MAC的转发流表而rest_vlan要下发基于VLAN匹配的流表两者不加区分的共存容易产生优先级冲突第一版实验里没必要去碰这个复杂度。先查一下当前VLAN配置curl http://127.0.0.1:8080/v1/vlans返回一个空列表或者默认信息说明交换机还没有分VLAN。接下来为教学区接入交换机s1的两个主机端口划分VLAN 10curl -X POST -d {vlan_id: 10, port: {s1: 1}} http://127.0.0.1:8080/v1/vlans curl -X POST -d {vlan_id: 10, port: {s1: 2}} http://127.0.0.1:8080/v1/vlans这里的port: {s1: 1}指的是交换机s1的1号端口。在Mininet自定义拓扑里端口编号按照addLink的顺序自动生成s1上先接的主机h1是1号端口第二个主机h2是2号端口。如果分错了端口把汇聚链路也划进VLAN整个拓扑的连通性会出大问题。用同样的方法把另外三个区域划分好curl -X POST -d {vlan_id: 20, port: {s2: 1}} http://127.0.0.1:8080/v1/vlans curl -X POST -d {vlan_id: 20, port: {s2: 2}} http://127.0.0.1:8080/v1/vlans curl -X POST -d {vlan_id: 30, port: {s3: 1}} http://127.0.0.1:8080/v1/vlans curl -X POST -d {vlan_id: 30, port: {s3: 2}} http://127.0.0.1:8080/v1/vlans curl -X POST -d {vlan_id: 40, port: {s4: 1}} http://127.0.0.1:8080/v1/vlans curl -X POST -d {vlan_id: 40, port: {s4: 2}} http://127.0.0.1:8080/v1/vlans配置完成后再用curl http://127.0.0.1:8080/v1/vlans查询能看到所有VLAN和端口的关系已经建立。此时再在Mininet CLI里执行h1 ping h2 -c 3 h3 ping h4 -c 3 pingall会发现同一VLAN内的主机比如教学区的h1和h2仍然能通但跨VLAN的主机比如h1和h3已经无法通信。这正是我们想要的VLAN隔离效果端口被打上VLAN标签后控制器的流表只会将广播和未知帧转发到同VLAN的端口不同VLAN之间的二层流量天然被隔离。这就是校园网“接入层隔离”的最基本形态。教研区和办公区不能互相随意访问、宿舍区和服务器区默认隔离这些现网里的基础需求放到RYU的VLAN模型下本质上都是这套逻辑。4.4 排查“全通变不通”时的思路第一次做VLAN实验的同学最容易困惑的是明明配置了VLAN后跨VLAN不通但这是预期结果为什么pingall输出里有掉包而我却不知道怎么确认是自己配置对了还是配置错了这里分享一套排查思路。第一步看流表。在Mininet CLI里执行s1 dpctl dump-flows -O OpenFlow13重点看流表里有没有带dl_vlan10这类匹配项的规则。如果配置成功rest_vlan会下发规则把VLAN 10的流量从对应端口转发出来。如果看到的是普通的MAC转发规则说明rest_vlan并没有真正生效。第二步看端口计数器。执行s1 dpctl dump-ports -O OpenFlow13对比各端口的收发包数确定流量到底从哪个端口进来、又从哪个端口出去。如果某一跳的计数器没有增长那问题大概率就出在那一段链路上。第三步回头看RYU日志。rest_vlan的每个请求都会在控制器日志里留下操作记录。如果发curl时返回了错误比如提示交换机不存在最常见的原因是控制器还没收到交换机的注册事件也就是说OVS和控制器之间的OpenFlow连接并没有建立成功。此时回过去检查--protocols OpenFlow13这个参数是最高效的修复路径。还有一个非常经典的坑是端口号错位。Mininet里交换机端口编号按addLink调用顺序递增但接上级汇聚的链路口通常排在后面。如果你拿链路接口当主机接口配置VLAN控制器会把这个端口划入某个VLAN于是汇聚链路就被带上了VLAN标签这会导致后续所有跨交换机的同VLAN流量都异常。排查时优先看看有没有把s1到a1的端口误配了VLAN。5. 下一步的思路与个人体会到这里第一版SDN校园网的核心骨架已经完成Mininet里跑着一套核心-汇聚-接入的三层拓扑RYU控制器统一管理所有交换机的转发并通过REST API实现了最基础的VLAN隔离。但从一个真正可用的校园网角度还差三块关键拼图VLAN间路由、DHCP动态地址分配、ACL和QoS策略下发。这也是我在后续几篇里准备按顺序展开的内容。特别是VLAN间路由它和传统二层的区别会非常明显。在传统网络里跨VLAN的三层通信需要在汇聚交换机上配VLANIF接口配置复杂且灵活性差。在RYU里这个事就是控制器的一段Python逻辑收到跨VLAN的IP报文后按目标网段查路由表替换MAC并转发。到时候我也会把REST API和流表下发的过程补全。最后给几个我实际操作中的体会。第一做SDN实验别急着用大而全的拓扑第一版用最小闭环把数据平面和控制平面跑通价值远超一开始就堆几十台交换机。第二Mininet脚本里的dpid一定要显式设置否则后续用REST API管理交换机时名称和datapath_id对不上排查起来非常头疼。第三环境出问题先回滚虚拟机快照不要反复调试半坏的系统SDN实验的复现性比什么都重要。第二篇见。
