ryu+ovs 在容器网络中的应用

前言 博主之前从事过基于ovs的自研cni的研发,当时是选择ryu作为ovs的南向控制端,这次来好好的剖析一下该ryu-controller程序的架构、工作流程和思想。 项目概述 功能定位: 本程序基于 Ryu SDN 框架构建,是 CNI项目的核心网络控制组件。OVS CNI 组件的控制端,负责通过 OpenFlow 协议向 OVS 交换机下发流表规则。 * 整体架构 1. RyuController 类 主控制器,继承自 RyuApp 和 FlowManager,负责: OpenFlow 交换机连接管理 数据包处理(Packet-In 事件) 流表生成和下发 与 cni-ctl 的交互 2. FlowManager 类 流表管理器,负责: 流表的增删改查 流表匹配字段和动作的格式化 异步请求和回调管理 3. DefaultFlowGenerator 类 默认流表生成器,负责初始化 OVS 流表结构。 核心流表表 (FlowTable): 1 2 3 4 5 6 7 8 9 10 11 12 13 14 DEFAULT_TABLE = 0 # 默认入口表 CT_SVC_TRACE_TABLE = 2 # Service 追踪表 CT_EP_TABLE = 3 # 连接跟踪端点表 STATIC_TABLE = 4 # 静态规则表 FILTER_TABLE = 5 # 过滤表 LEARN_TABLE = 6 # 学习表 CT_CHECK_TABLE = 10 # 连接状态检查表 CT_SVC_TABLE = 12 # Service 连接跟踪表 BASE_LEARN_TABLE = 15 # 基础学习表 CT_COMMIT_TABLE = 20 # 连接提交表 CT_NAT_TABLE = 30 # NAT 处理表 LOCAL_TABLE = 60 # 本地处理表 NORMAL_TABLE = 70 # 转发表 EXTERNAL_TABLE = 80 # 外部处理表 寄存器用途 (reg0-reg7)...

2025-09-13 · 3 分钟 · 561 字 · kl

探索SDN实操_05_sdn Ovn实操

前言 OVN 架构核心组件和角色 OVN 是 Open vSwitch (OVS) 的一个扩展,它提供了一个更高级别的、声明式的接口来定义虚拟网络,并自动将这些定义转换为底层的 OpenFlow 规则。其核心思想是提供一个平台,允许用户通过逻辑网络概念来操作网络,而无需直接与 OpenFlow 规则交互。 OVN 的核心组件包括: OVN 北向数据库 (OVN Northbound DB / OVN-NBDB): 角色:这是 OVN 的控制平面接口,也是网络管理员或云管理平台 (如 OpenStack, Kubernetes) 与 OVN 交互的地方。 内容:存储逻辑网络模型的高级抽象,例如: 逻辑交换机 (Logical Switches) 逻辑路由器 (Logical Routers) 逻辑端口 (Logical Ports) ACLs (Access Control Lists) NAT 规则 QoS 策略等。 特点:它不关心物理网络的细节,只关注“期望的状态”。所有的配置都通过 ovn-nbctl 工具或北向 API (例如 OVN Kubernetes 集成中的 K8s API) 写入到这个数据库。 ovn-northd 守护进程: 角色:OVN 的中央控制逻辑。它持续监控 OVN-NBDB 的变化。 功能:作为 NBDB 和 SBDB 之间的翻译器。当 NBDB 中的逻辑配置发生变化时,ovn-northd 会将这些高级逻辑概念翻译成更具体、但仍是抽象的“逻辑流” (Logical Flows) 和其他信息,并将这些信息写入 OVN 南向数据库。它进行复杂的路由计算、ACL 评估等,以决定数据包在逻辑网络中应该如何转发。 OVN 南向数据库 (OVN Southbound DB / OVN-SBDB): 角色:这是 OVN 的数据平面抽象。 内容:存储由 ovn-northd 翻译而来的“逻辑流”(Logical Flows),以及物理网络拓扑信息(如哪个 hypervisor 上运行着哪些逻辑端口)。 Chassis 表:记录每个 hypervisor (物理节点) 的信息。 Port_Binding 表:记录逻辑端口绑定到哪个物理节点和哪个 OVS 端口。 Logical_Flow 表:存储由 ovn-northd 生成的、描述数据包在逻辑网络中如何转发的规则(类似于 OpenFlow 流规则,但仍是抽象的逻辑层)。 特点:它仍然不直接包含 OpenFlow 规则,而是包含足够的信息让底层的 ovn-controller 知道如何生成 OpenFlow 规则。 ovn-controller 守护进程: 角色:在每个计算节点 (hypervisor) 上运行的代理。它是 OVN 数据平面的执行者。 功能: 监控 OVN-SBDB,获取与当前计算节点相关的逻辑流和端口绑定信息。 将这些逻辑流实时翻译成 OpenFlow 规则,并下发到本地 OVS 实例。 管理本地 OVS 网桥(通常是 br-int,一个集成网桥),创建和配置连接到虚拟机的 OVS 端口 (VIF)。 向 SBDB 报告本节点的物理端口信息(例如,哪个 OVS 端口连接到哪个 VM)。 特点:负责将抽象的逻辑网络最终具象化为物理的 OpenFlow 规则,从而控制数据包的转发。 OVN 工作流总结 管理员/云平台通过 ovn-nbctl 或 API 配置 OVN-NBDB (定义逻辑交换机、逻辑端口等)。 ovn-northd 监听 OVN-NBDB 的变化,将其翻译成逻辑流,并写入 OVN-SBDB。 每个计算节点上的 ovn-controller 监听 OVN-SBDB 中与自己相关的逻辑流和端口绑定。 ovn-controller 将这些逻辑流转换为具体的 OpenFlow 规则,并下发到本地 OVS 实例,同时配置 OVS 端口。 数据包在 OVS 网桥上根据这些 OpenFlow 规则进行转发。 实践一:OVN 环境搭建与操作 1....

2025-08-10 · 9 分钟 · 1767 字 · kl

探索SDN实操_04_sdn Ryu Controller

前言 SDN 核心思想:控制平面与数据平面分离 SDN(软件定义网络)最核心的思想就是控制平面 (Control Plane) 与 数据平面 (Data Plane) 的分离。 数据平面 (Data Plane / Forwarding Plane): 职责:负责实际的数据包转发,也就是“怎么走”。 组成:由网络设备(如交换机、路由器)构成。这些设备现在被称为数据平面设备或转发器 (Forwarders)。 特点:它们变得“愚蠢”且可编程。它们不再自行决定数据包的转发路径,而是严格遵循控制平面下发的指令(流规则)进行操作。 南向接口 (Southbound Interface):是数据平面设备与控制平面通信的接口。它允许控制器向数据平面设备下发流规则,并接收数据平面设备的事件(如 Packet-In)。OpenFlow 是最广为人知和广泛使用的南向接口协议。 控制平面 (Control Plane / Control Layer): 职责:负责网络的“大脑”,决定数据包的转发逻辑和策略,也就是“往哪走”。 组成:由一个或多个网络控制器 (Network Controllers) 组成(例如 OpenDaylight, ONOS, Ryu, Floodlight 等)。 特点:集中化管理,具有网络的全局视图。它根据网络管理员的策略或应用程序的需求,计算出最佳的转发路径和规则,然后通过南向接口下发给数据平面设备。 北向接口 (Northbound Interface):是控制器与上层应用 (Applications) 或业务编排系统通信的接口。它允许应用程序向控制器请求网络服务、配置网络策略或获取网络状态。REST API 是最常见的北向接口形式。 总结: 传统网络:控制平面和数据平面紧密耦合在每个网络设备中。 SDN 网络:将控制平面从数据平面设备中抽离出来,集中到控制器中。控制器通过南向接口控制数据平面,并通过北向接口暴露网络服务给上层应用。 南向接口 (Southbound Interface) 和 北向接口 (Northbound Interface) 南向接口 (Southbound Interface): 目的:控制器 <-> 转发设备。 功能:控制器向转发设备下发流规则、查询设备状态;转发设备向控制器报告事件(如 Packet-In,当遇到未知数据包时)。 例子:OpenFlow, NETCONF, OVSDB 等。OpenFlow 是目前 SDN 领域最主流和最具代表性的南向接口协议。 北向接口 (Northbound Interface): 目的:控制器 <-> 上层应用。 功能:应用程序通过北向接口向控制器请求网络资源、配置网络策略(例如“创建一条带宽为 100Mbps 的隧道”),或者获取网络拓扑、流量统计等信息。 例子:RESTful API (最常见), Java API, Python SDK 等。 Ryu控制器实操 💡 用 Python 编写一个简单的 Ryu L2 Learning Switch...

2025-08-02 · 7 分钟 · 1338 字 · kl

探索SDN实操_03_OpenFlow协议流表实操

前言 💡 学习一些流表相关 Match (匹配字段):定义了数据包的哪些属性(如源/目的 MAC、IP、端口、VLAN ID 等)需要被匹配。 Action (动作):定义了当数据包匹配到某个流规则后,控制器或交换机应该对数据包执行的操作(如转发到端口、丢弃、修改字段、封装/解封装 VLAN 等)。 Flow Rule (流规则):是 Match 和 Action 的组合。它告诉 OpenFlow 交换机:“如果一个数据包满足这些匹配条件,就执行这些动作。” Flow Table (流表):OpenFlow 交换机内部用于存储流规则的集合。 Pipeline (多级流表):OpenFlow 1.0 版本只有一个流表。从 OpenFlow 1.1 开始引入了多级流表(Pipeline)概念,数据包可以按顺序经过多个流表进行处理。每个流表可以有不同的匹配和动作逻辑。这提供了更大的灵活性,例如,第一个流表可以处理安全策略,第二个流表处理路由,第三个流表处理 QoS 等。 手动下发流规则,实现: 让两个端口互通(模拟二层交换机)。 丢弃来自某个MAC地址的流量。 将流量从一个端口转发到另一个端口。 实操 环境搭建 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 #1....

2025-07-22 · 7 分钟 · 1471 字 · kl

探索SDN实操_02_ovs-bridge模拟一个简单的多租户网络

前言 💡 实操一下使用 ovs-vsctl 来管理OVS。包括创建/删除网桥,添加/删除端口,设置接口类型和VLAN Tag等。搭建一个包含多个OVS网桥的实验环境,模拟一个简单的多租户网络 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 #1....

2025-07-20 · 8 分钟 · 1494 字 · kl