简介这份PDF是《软件定义网络SDN基础教程》的课后习题参考答案面向正在学习SDN课程的高校学生、网络方向考研备考者以及希望转型SDN的网络工程师帮助解决课后练习无从下手、概念理解不透彻的问题。资源包内仅含1个PDF文件约1008KB篇幅紧凑便于打印或移动端随时查阅。内容覆盖SDN基础知识与仿真环境两大章节逐题给出参考答案涉及SDN相比传统网络在灵活性、可编程性、集中控制与创新推动方面的优势以及可扩展性、一致性、可用性三类挑战同时梳理ONF四平面架构中数据平面、控制平面、应用平面、管理平面的职责划分并解释南向接口与北向接口在控制转发分离和网络可编程中的关键作用还包含Mininet仿真环境搭建与拓扑文件编写示例。目前已有175人学习适合作为课程复习、考前突击与实验预习的对照材料。1. 从一份习题答案说起SDN 基础教程的课后题到底值不值得逐题啃很多人第一次接触软件定义网络都是从“背概念”开始的控制平面、数据平面、OpenFlow、流表、Mininet名词记了一堆真让你画一张端口转发表、写一段拓扑脚本、配一条 OVS 流表手就停了。这份《软件定义网络SDN基础教程-习题答案 .pdf》的价值恰恰在这里——它不是又一本讲原理的教材而是把教材里那些“看起来懂了、动手就废”的课后题逐题给出了参考答案和操作步骤。第一章讲 SDN 与传统网络的差异、四平面架构、控制与转发如何分离第二章直接落到 Mininet 仿真环境给了完整的拓扑 Python 脚本和 MAC 地址学习的推演过程第三章进数据平面讲白盒交换机、Open vSwitch 部件构成还给了流表项和 QoS 的具体配置命令第四、五章覆盖 OpenDaylight 控制器、OpenFlow 协议交互和 NETCONF第六、七章是应用开发与综合案例。适合谁正在上 SDN 课程、要交作业或备考的人以及想从“知道 SDN”跨到“能跑起一个小拓扑”的初学者。它不教你写论文但能让你把教材里的每个知识点落到一条命令、一张表上。2. 把四平面架构和转控分离讲透习题答案里的架构题怎么用2.1 四平面不是四个框是四层职责边界教材里 SDN 架构常被画成四个叠在一起的平面很多人背完就忘。这份答案里第一章第 2 题把 ONF 定义的四个平面拆得很清楚数据平面由若干网元构成每个网元包含一个或多个 SDN 数据路径数据路径本身没有控制能力只负责转发和处理数据内部又分控制-数据平面接口代理、转发引擎表、处理功能模块三部分控制平面就是 SDN 控制器包含北向接口代理、SDN 控制逻辑、控制-数据平面接口驱动逻辑上完整即可物理上可以是多控制器协同或层级式集群应用平面是用户需要的 SDN 应用通过北向接口与控制器交互一个应用可以使用多种北向 API也可以把自身功能再抽象封装成更高级的北向接口管理平面负责静态工作比如网元设置、指定控制器、定义控制器和应用的控制范围。这四层的关键不是“有几层”而是每层之间的接口协议不同。数据平面和控制平面之间走南向接口控制平面和应用平面之间走北向接口控制器之间还有东西向接口。答案里特别点出北向接口的设计是否完善直接影响整个 SDN 的可编程能力。这句话在答题时是得分点在实际选型时也是判断一个控制器好不好用的核心标准。2.2 控制与转发分离以 FIB 表为界哑交换机的由来第一章第 3 题问“SDN 如何实现控制平面与数据平面分离”答案给了一个很具体的切分点以网络设备的 FIB 表为界。交换设备只保留 FIB 和高速交换转发能力变成一个轻量级的、“哑”的数据平面上层的控制决策全部由远端统一控制器节点完成控制器上能看到全局信息并做优化决策数据平面和控制平面之间用南向接口协议连接这个协议提供数据平面可编程性。这里有个容易被忽略的细节分离之后原来分布式运行在各个网络节点里的控制平面功能被集中了。传统网络里集线器、交换机、路由器各自分布式地跑控制平面要部署新功能就得升级所有相关设备SDN 把控制平面集中实现后新功能部署只需要在控制节点做集中的软件升级。这就是“灵活”二字的物理来源不是口号。2.3 优势与代价可扩展性、一致性、可用性三座山第一章第 1 题是典型的论述题答案把优势和问题都列了。优势方面通过软件方式灵活定义转发功能控制平面集中实现新功能部署只需控制节点软件升级架构开放对整个网络抽象后提供完备编程接口用户可个性化定制网络资源开放可编程有可能打破厂商在设备、协议、软件上的垄断让更多人参与网络技术研发。问题方面答案列了三条每一条都值得展开理解。可扩展性数据控制分离后原来分布式的控制平面集中化了网络规模扩大时单个控制节点的服务能力可能成为性能瓶颈所以控制架构的可扩展性是主要研究方向。一致性传统网络的状态一致性由分布式协议保证分离后集中控制器要承担这个责任如何快速侦测分布式节点状态不一致并快速解决是研究方向。可用性传统网络设备高可用发向控制平面的请求实时得到响应网络比较稳定分离后控制平面网络的延迟可能导致数据平面可用性问题。提示这三条在考试里是标准答案在实际项目里是选型 checklist。如果你要在一个大规模网络里上 SDN先问自己控制器集群能不能水平扩展、状态同步机制是什么、控制通道断了数据平面能不能降级转发。2.4 可编程性落在北向接口上第一章第 4 题问“SDN 如何实现网络可编程”答案的落点很明确对上层应用开发者来说编程接口主要体现在北向接口上。北向接口提供一系列丰富的 API开发者在此基础上设计应用不必关心底层硬件细节就像在 x86 体系计算机上编程不用关心寄存器和驱动。北向接口设计是否完善直接影响整个 SDN 的可编程能力。这段答案的价值在于它把“可编程”从抽象概念拉到了具体位置——不是南向的 OpenFlow而是北向的 API。南向负责让控制器能控制设备北向负责让开发者能控制控制器。两者缺一不可但面向应用开发时北向才是主战场。3. Mininet 仿真环境动手拓扑脚本、MAC 学习和仿真边界3.1 Mininet 到底在仿真里扮演什么角色第二章第 1 题问 Mininet 在 SDN 仿真中的作用答案给的定义很干脆Mininet 是一个可以在有限资源的普通计算机上快速建立大规模 SDN 原型系统的网络仿真工具由虚拟终端节点、OpenFlow 交换机、控制器也支持远程控制器组成可以模拟真实网络对各种想法或网络协议进行开发验证。目前 Mininet 已经作为官方演示平台对各个版本的 OpenFlow 协议进行演示和测试。这里的关键词是“有限资源”和“快速建立”。你不需要一堆物理交换机一台普通笔记本就能跑起一个包含多台主机、多台交换机的拓扑。代价是仿真终端不支持复杂应用部署UI 易用性也一般——这是第六章第 1 题明确列出的不足。3.2 手写拓扑文件不用可视化应用也能生成拓扑第二章第 2 题要求不使用 Mininet 可视化应用写一份拓扑文件并在 Mininet 中使用。答案给了一份完整的 Python 脚本我把它整理成可直接运行的版本并补上注释#!/usr/bin/python from mininet.net import Mininet from mininet.node import Controller, RemoteController, OVSController from mininet.node import CPULimitedHost, Host, Node from mininet.node import OVSKernelSwitch, UserSwitch from mininet.node import IVSSwitch from mininet.cli import CLI from mininet.log import setLogLevel, info from mininet.link import TCLink, Intf from subprocess import call def myNetwork(): # 创建 Mininet 对象topoNone 表示不使用内置拓扑buildFalse 表示先不构建 net Mininet(topoNone, buildFalse, ipBase10.0.0.0/8) info(*** Adding controller\n) # 添加控制器 c0使用默认 Controller 类协议 tcp端口 6633 c0 net.addController(namec0, controllerController, protocoltcp, port6633) info(*** Add switches\n) # 添加两台 OVS 内核态交换机 s2 net.addSwitch(s2, clsOVSKernelSwitch) s1 net.addSwitch(s1, clsOVSKernelSwitch) info(*** Add hosts\n) # 添加三台主机指定 IPdefaultRouteNone 表示不设默认路由 h2 net.addHost(h2, clsHost, ip10.0.0.2, defaultRouteNone) h1 net.addHost(h1, clsHost, ip10.0.0.1, defaultRouteNone) h3 net.addHost(h3, clsHost, ip10.0.0.3, defaultRouteNone) info(*** Add links\n) # 连接关系h1-s1, s1-s2, s2-h2, s2-h3 net.addLink(h1, s1) net.addLink(s1, s2) net.addLink(s2, h2) net.addLink(s2, h3) info(*** Starting network\n) net.build() info(*** Starting controllers\n) for controller in net.controllers: controller.start() info(*** Starting switches\n) net.get(s2).start([c0]) net.get(s1).start([c0]) info(*** Post configure switches and hosts\n) CLI(net) # 进入交互式命令行 net.stop() if __name__ __main__: setLogLevel(info) myNetwork()逻辑说明脚本先创建空的 Mininet 对象再依次添加控制器、交换机、主机、链路最后 build 并启动。参数说明ipBase10.0.0.0/8指定主机 IP 的基础网段port6633是 OpenFlow 默认端口如果你用的控制器监听 6653这里要改clsOVSKernelSwitch表示使用 Open vSwitch 内核态交换机性能比 UserSwitch 好但依赖内核模块。运行方式就是答案里的步骤保存为 topo.py执行sudo python topo.py。注意必须用 sudo因为创建虚拟网络接口需要 root 权限。3.3 MAC 地址学习用 linear 拓扑把过程跑一遍第二章第 3 题要求创建拓扑并画出端口转发表说明 MAC 地址学习过程。答案给的创建命令是mn --topo linear,2,2 --mac --switch ovsk --controllernone参数说明--topo linear,2,2表示线性拓扑2 台交换机、每台交换机下挂 2 台主机--mac让主机 MAC 地址和 IP 地址最后一位对应方便观察--switch ovsk指定 OVS 内核态交换机--controllernone表示不启动控制器这样交换机就退化成普通的二层学习交换机正好用来观察 MAC 学习。答案把学习过程拆成了八个步骤初始时交换机 A 和 B 的 MAC 表为空主机 11 向主机 33 发帧交换机 A 收到后学习源 MAC 和端口查表无目的 MAC 则向除源端口外所有端口广播交换机 B 收到后同样学习源 MAC 和端口继续广播主机 22 发现目的 MAC 不是自己丢弃主机 33 接收之后主机 44 向主机 11 发帧交换机 B 查表已有主机 11 的条目单播转发到对应端口交换机 A 收到后学习主机 44 的 MAC 和端口查表单播转发到主机 11。整个过程的核心就两条收到帧先学源 MAC 和入端口再查目的 MAC 决定单播还是广播。3.4 仿真环境和传统仿真平台的差异第二章第 5 题问 SDN 仿真环境和传统网络仿真环境的异同。答案指出传统平台如 NS2、OPNET 存在缺陷难以准确模拟网络实际状态不具备交互特性基于这些平台开发的代码不能直接部署到真实网络。Mininet 基于 Linux Container 架构是轻量级进程虚拟化网络仿真工具最重要的特点是所有代码几乎可以无缝迁移到真实硬件环境。这个“无缝迁移”是 Mininet 区别于 NS2 的核心卖点。你在 Mininet 里写的控制器应用、下发的流表换到真实 OpenFlow 交换机上基本不用改。代价是 Mininet 的仿真终端不支持复杂应用部署UI 也简陋。所以常见做法是用 Mininet 做功能验证和协议开发用真实设备做性能和兼容性测试。4. 数据平面与 Open vSwitch流表、白盒交换机和 QoS 配置4.1 数据平面的三个基本功能第三章第 1 题问数据平面的功能答案列了三个方面。转发决策交换设备收到数据分组后将目的地址与 MAC 地址表或路由表匹配确定转发目的端口表项匹配由交换芯片实现。背板转发交换机通过背板连接各端口数据分组经转发决策后由背板从入端口转发到目的端口交换结构分共享总线、共享内存和 CrossBar 三种。输出链路调度各端口有接收和发送缓冲队列数据分组暂存接收队列等待处理决定发送后进入发送队列终端忙则一直存储。这三条在传统交换机和 SDN 交换机上都成立区别在实现方式。4.2 SDN 交换机与传统交换机的差异第三章第 2 题把差异讲得很细。转发决策上支持 OpenFlow 的 SDN 交换机用流表代替传统二层和三层转发表每个表项代表一种流解析和处理动作数据分组进入后先与流表匹配匹配成功执行动作无匹配则上交控制器。背板转发上数据中心是 SDN 应用最广泛场景对交换速率要求高但速率瓶颈主要在交换芯片背板提供足够交换速率并不难。输出链路调度上支持 QoS 的交换机可能根据字段分类进入优先级队列支持 OpenFlow 的 SDN 交换机对 QoS 的支持主要有基于流表项设置报文入队列、根据 Meter 限速、基于 Counter 计费、基于 Group 的 Select 功能进行队列调度。答案特别点出背板转发和输出链路调度没给 SDN 交换机带来太大挑战但转发决策带来了很大难题。因为 OpenFlow 流表逻辑粒度更高可以包含更多层次网络特征使交换机集交换、路由、防火墙、网管功能于一身这正是 SDN 灵活性的由来但也对交换芯片性能提出新要求。4.3 白盒交换机硬件标准化后的软件生意第三章第 3 题讲白盒交换机。白盒原本指没有品牌的计算机ODM 厂商如 Accton、Celestica、Quanta 进入网络设备市场希望用户像挑个人计算机一样挑网络设备。网络设备软硬件接口标准化后ODM 厂商可以购买交换芯片按客户要求生产白盒交换机用户自行安装网络操作系统和应用由网管人员编程控制转发行为。白盒交换机没有软件无法使用每台需要一个独立于硬件的网络操作系统Linux 因为开源工具丰富、有 GCC 和 Python 本地环境、能在板上编译自开发应用成为理想选择。要真正部署到 SDN 中还必须能与 SDN 控制器如 Ryu、Floodlight交互。4.4 Open vSwitch 的三个基本部件第三章第 5 题问 OVS 的组成答案分三部分。ovs-vswitchd 守护进程慢速转发平面位于用户空间完成基本转发逻辑包括地址学习、镜像配置、802.1Q VLAN、LACP、外部物理端口绑定、基于源 MAC 和 TCP 的负载均衡或主备支持 OpenFlow可通过 sFlow、NetFlow 或 SPAN 保证网络可视性配置后数据交由 ovsdb-server 存储管理。核心数据转发平面openvswitch_mod.ko 模块位于内核空间完成数据分组查询、修改、转发、隧道封装、维护底层转发表。控制平面分布在不同物理机上的软件交换机通过 OpenFlow 控制集群组成分布式虚拟化交换机实现不同租户虚拟机隔离。每个数据转发保持一个 OpenFlow 连接数据流第一次通过软件交换机时被转发到控制器处理控制器根据 1 到 4 层信息匹配定义转发、丢弃、修改或排队策略第二次转发直接由核心转发模块处理。4.5 流表项和 QoS 的具体配置第三章第 7 题要求添加流表项端口 2 流入、源 IP 10.0.0.1 的 IPv4 数据包目的 IP 改为 10.0.0.2。答案给的命令是ovs-ofctl add-flow br0 idle_timeout1000,priority1,in_port2,dl_type0x0800,nw_src10.0.0.1,actionsmod_nw_dst:10.0.0.2参数说明idle_timeout1000表示空闲 1000 秒后流表项失效priority1是匹配优先级in_port2匹配入端口dl_type0x0800匹配 IPv4 以太网类型nw_src10.0.0.1匹配源 IPactionsmod_nw_dst:10.0.0.2表示修改目的 IP 为 10.0.0.2。注意这条命令只改目的 IP没有指定输出动作实际使用时通常还要加output动作。第三章第 8 题是网吧 OVS 场景要求用 eth8 监控 eth1 和 eth4并为三个端口提供 QoS 保障。监控配置ovs-vsctl -- set bridge br-sw mirrorsm -- --idm create mirror namemymirror select-dst-porteth1 uuid select-src-porteth4 uuid output-porteth8 uuidQoS 配置ovs-vsctl set interface eth1 ingress_policing_rate100000 ovs-vsctl set interface eth1 ingress_policing_burst50000 ovs-vsctl set interface eth4 ingress_policing_rate100000 ovs-vsctl set interface eth4 ingress_policing_burst50000 ovs-vsctl set interface eth8 ingress_policing_rate100000 ovs-vsctl set interface eth8 ingress_policing_burst50000参数说明ingress_policing_rate单位是 kbit/s100000 对应 100 Mbit/s 左右题目要求 1000 kbit/s 的话这里数值要按实际换算ingress_policing_burst是突发流量上限单位 kbit。监控配置里select-dst-port和select-src-port分别指定目的和源端口output-port指定监控输出端口。4.6 删除网桥时端口会怎样第三章第 6 题问不删除 eth0 直接删除 br0br0 及挂接端口是否一并删除。答案直接删除 br0br0 会被删除br0 上的端口从 br0 上删除但 eth0 实际网卡依旧存在。这个细节在实验里很关键——你删了网桥以为网卡也没了结果 ifconfig 一看 eth0 还在只是不再属于任何网桥。5. 控制平面、协议接口与常见问题排查5.1 控制器层次化架构的两层第四章第 1 题问控制平面层次化架构。答案分两层。基本功能层提供控制器基本功能首先要完成协议适配包括与底层交换设备交互的南向接口协议和用于控制平面分布式部署的东西向接口协议协议适配完成后提供模块管理、事件机制、任务日志、资源数据库四方面功能支撑上层应用开发。网络基础服务层提供基础网络功能模块作为控制器实现的一部分通过调用基本功能层接口实现设备管理、状态监测等涵盖交换机管理、主机管理、拓扑管理、路由、转发策略、虚拟网管理。5.2 OpenDaylight 登录问题和端口修改第四章第 3 题问 OpenDaylight 无法登录Unable to Login的原因和解决办法。答案一种原因可能是控制器所在机器内存不足需要扩大内存排除后通过 logout 退出 Karaf 控制台进入上级目录删除 data 目录rm -rf data进入 bin 目录执行./karaf clean再次按顺序安装组件。第四章第 4 题问从 Helium 版本开始的默认 Web 端口。答案默认 8181可手动修改修改distribution-karaf-0.6.0-Carbon/etc目录下的 jetty.xml如改为 8080Property namejetty.port default8080/5.3 OpenFlow 协议交互和 NETCONF 分层第五章第 2 题讲安全通道建立控制器开启 TCP 6633 端口等待连接交换机启动后连接该端口双方交换证书完成身份认证每个交换机至少配置两个证书一个认证控制器一个向控制器认证认证通过后互发 Hello 消息携带各自支持的最高协议版本号接收方采用二者中较低版本通信发现共同支持版本则建立安全通道否则发错误消息并终止连接。第五章第 3 题讲抓包分析交互过程答案列了七步TCP 三次握手建立连接控制器端口 6633互发 Hello 协商版本不一致产生 Error控制器发 Features Request交换机回 Features Reply 汇报 buffer 数目、流表数、动作等控制器通过 Set Config 下发配置Get Config Request 请求上传修改后配置交换机回 Get Config Reply通过 Packet_out、Packet_in 消息内置 LLDP 包探测拓扑通过 Multipart Request/Reply 获取流和端口状态通过 Echo Request/Reply 保证连接有效。第五章第 5 题讲 NETCONF 四层传输层要求面向连接、身份认证完整性和机密性、必须支持 SSH消息层采用 RPC 通信模式用rpc和rpc-reply元素提供与传输协议独立的请求响应操作层提供低级别操作管理设备配置和检索状态信息内容层由配置数据和通知数据组成未指定具体模型结构而是指定数据建模语言 YANG通过增加修改 YANG 文件扩展协议。5.4 常见问题排查现象一Mininet 启动拓扑时报 “Unable to contact the remote controller”。原因控制器没启动或者拓扑脚本里控制器 IP、端口写错或者控制器监听端口和脚本里port6633不一致。 解决先确认控制器进程在跑netstat -tlnp | grep 6633看端口是否监听如果控制器用的是 6653把脚本里port6633改成 6653远程控制器要确认 IP 可达。现象二OVS 流表添加成功但数据包不按预期转发。原因流表项优先级设置不当被其他表项覆盖或者 actions 里只改了字段没指定 output或者 idle_timeout 太短表项已失效。 解决ovs-ofctl dump-flows br0查看当前所有流表项和优先级确认匹配条件和动作补上 output 动作把 idle_timeout 调大或设为 0 表示永不超时。现象三OpenDaylight 登录界面打不开或提示 Unable to Login。原因机器内存不足或者 Karaf 控制台残留的 data 目录状态不一致。 解决先扩内存然后退出 Karaf删除 data 目录执行./karaf clean重新按顺序安装组件。这个操作相当于给控制器吃后悔药清掉脏状态。现象四删除 br0 后以为 eth0 也没了结果网络配置混乱。原因删除网桥只删除网桥本身和端口绑定关系物理网卡 eth0 依然存在但可能失去了原有 IP 配置。 解决删除网桥前先记录 eth0 的 IP、网关、DNS删除后重新给 eth0 配回地址或者用ovs-vsctl del-port br0 eth0先解绑再删网桥。现象五Mininet 里主机 ping 不通但拓扑显示已启动。原因控制器没下发流表交换机默认行为是丢弃或上交控制器或者主机 IP 不在同一网段或者 ARP 没解析。 解决先pingall看整体连通性如果全不通检查控制器是否正常下发流表如果部分不通检查主机 IP 和子网掩码用h1 arping h2手动触发 ARP 看能否解析。6. 从习题答案到能跑的实验北向 API 和 SDN 防火墙的进阶用法第七章第 1 题问 SDN 北向 API 的作用答案很直接控制器北向 API 由控制器提供可通过调用接口对控制器连接的交换机进行管理操作包括流表的增删改查、拓扑获取、交换机配置更改。这意味着你不需要登录每台交换机敲命令而是通过 HTTP 请求或 RPC 调用让控制器替你下发策略。常见做法是用 Postman 或 curl 向控制器的 REST API 发 GET/POST 请求比如获取交换机 ID、下发流表、查询拓扑。第七章第 2 题问 SDN 防火墙特点。答案SDN 基本特性包括转控分离、控制平面可编程和集中控制。借助中心化控制机制企业可以从全局网络设备采集流量信息建立基于流量的实时和历史信息库精准识别、阻断异常流量实现基于流的类防火墙功能。借助开放北向接口用户可以按需定制北向应用快速有效地将安全策略下发到安全设备实现安全措施快速部署和安全事件及时响应。把这两题连起来看一个可落地的进阶练习是用 Mininet 搭一个简单拓扑控制器用 Ryu 或 OpenDaylight通过北向 API 下发一条流表实现“禁止 h1 访问 h2 的 80 端口”。具体步骤先启动控制器确认北向 API 端口可访问用 curl 或 Postman 获取拓扑和交换机 ID构造流表 JSON匹配源 IP、目的 IP、目的端口 80动作设为 dropPOST 到控制器的流表下发接口在 Mininet 里用h1 curl h2验证被阻断用h1 curl h3验证其他流量正常。这个练习把第七章的北向 API 和防火墙特点落到了具体操作上。验证方法上我一般会走三步第一步ovs-ofctl dump-flows确认流表真的下到了交换机第二步在主机侧用curl或nc验证策略生效第三步删掉流表再验证一次确认策略可撤销。这三步走完你才算真正把“北向 API 控制网络行为”这件事跑通了。从那以后我每次做 SDN 实验都强制先确认控制器端口和版本协商再检查流表优先级和超时最后一定用 dump-flows 和实际流量各验证一遍。这套习惯帮我省掉了大量“命令敲了但没生效”的排查时间。希望帮到你。本文还有配套的精品资源点击获取