https://klworldy.com/categories/%E7%BD%91%E7%BB%9C/ Recent content in 网络 on kl 's blog https://klworldy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E https://klworldy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E Hugo -- 0.133.1 zh Sat, 13 Sep 2025 00:53:56 +0800 https://klworldy.com/posts/ryu-in-cni/ Sat, 13 Sep 2025 00:53:56 +0800 https://klworldy.com/posts/ryu-in-cni/ 前言 博主之前从事过基于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) https://klworldy.com/posts/sdn-study-05_sdn-ovn/ Sun, 10 Aug 2025 15:49:04 +0800 https://klworldy.com/posts/sdn-study-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. https://klworldy.com/posts/sdn-study-04_sdn-ryu/ Sat, 02 Aug 2025 00:52:44 +0800 https://klworldy.com/posts/sdn-study-04_sdn-ryu/ 前言 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 https://klworldy.com/posts/sdn-study-03_openflow/ Tue, 22 Jul 2025 22:34:05 +0800 https://klworldy.com/posts/sdn-study-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. https://klworldy.com/posts/sdn-study-02_multi-tenant-network/ Sun, 20 Jul 2025 15:08:26 +0800 https://klworldy.com/posts/sdn-study-02_multi-tenant-network/ 前言 💡 实操一下使用 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. https://klworldy.com/posts/sdn-study-01_linux-bridge-ovs-bridge/ Tue, 15 Jul 2025 15:08:26 +0800 https://klworldy.com/posts/sdn-study-01_linux-bridge-ovs-bridge/ 前言 准备开个新坑吧，系统的过一遍SDN领域的相关技术，记录一些实验实操。 💡手动创建网络命名空间，用veth pair连接它们，并通过Linux bridge或OVS bridge将它们互联。尝试配置IP地址并ping通。 使用 Linux Bridge 互联 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 # 1. 创建网络命名空间 sudo ip netns add ns1 sudo ip netns add ns2 # 2. 创建 veth pair sudo ip link add veth1 type veth peer name veth1_br sudo ip link add veth2 type veth peer name veth2_br # 3. https://klworldy.com/posts/kube-ovn-logicalnetwork-data-architecture/ Sun, 06 Apr 2025 10:56:00 +0800 https://klworldy.com/posts/kube-ovn-logicalnetwork-data-architecture/ 同vpc、subnet不同node的pod流量 同vpc子网不同node下pod在OVN逻辑层面： 在vpc逻辑路由器下，存在子网逻辑交换机，pod在该交换机下均有对应的逻辑端口，逻辑端口绑定信息中也记录着端口所在的节点chassis ，逻辑数据路径，逻辑端口编号等信息。以上信息在ovs中转化为对应流表。从而支持同vpc子网下pod的跨节点流量。 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 111 112 113 114 115 116 117 118 119 120 121 root@l1:~# kubectl get pod -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-o-2-6bf6f745-ssdqp 1/1 Running 0 29m 11. https://klworldy.com/posts/kube-ovn-vpc/ Mon, 20 Jan 2025 15:00:52 +0800 https://klworldy.com/posts/kube-ovn-vpc/ 前言 临近过年，总算是闲下来了，博主自9月份入职新公司后，一直在做容器网络相关的工作，有了一些积累，乘着年前闲暇做做梳理。 一个CNI 网络插件的设计，我认为可以大致分为控制面的设计和数据面的设计。如何管理IPAM、如何维护k8s cluster、node、pod、svc等等信息属于控制面，如何设计并维护容器网络的数据路径datapath这属于数据面；本篇文章，我想探讨一下kube-ovn这个项目对容器网络数据路径的设计。 数据面总体设计拓扑 为了直观清晰，先上图： VPC、Subnet是kube-ovn中的核心概念，对应到ovn层面就是三层逻辑路由器、二层逻辑交换机。kube-ovn通过这样的对应关系来构建容器网络的逻辑网络拓扑。 默认VPC网络 在 kube-ovn 的部署中，默认容器网络通过创建一个默认 VPC 网络实现。以 Overlay 模式为例，系统会自动生成以下资源： VPC：ovn-cluster 子网：ovn-default 和 join 它们的逻辑关系如图所示可以类比为一个真实的路由器连接两个交换机。 容器网络之间通信 ovn-cluster 路由器通过其ovn-cluster-ovn-default端口连接ovn-default交换机，端口的 IP 地址为 10.16.0.1/16，这也是默认容器网络的网段。 在默认网络中，Pod 的主机网络侧 veth 设备被接入到 OVS 虚拟网桥 br-int，相当于 Pod 内部网络侧的 veth 设备被连接到 ovn-default 交换机的某个端口。 这种网络拓扑的设计使得同一子网内的 Pod 像连接在同一交换机上的设备，可以直接通过二层网络通信。 容器网络与主机网络通信 join子网是专用于默认容器网络与主机网络之间的通信而设计的。 首先，在每个节点上创建 ovn0 网络设备，并将其接入 OVS 虚拟网桥 br-int。在逻辑层中，这表现为 ovn-cluster 路由器通过 ovn-cluster-join 端口连接到 join 交换机，而 join 交换机分别与各节点的 ovn0 设备相连。 其次，在ovn-cluster路由器中存在路由规则：ovn-nbctl lr-route-add router "0.0.0.0/0" 100.64.0.1 ，该规则指示所有未匹配到其他路由的容器网络流量发送到 join 网段。同时node主机上也存在路由ip route add 10. https://klworldy.com/posts/kube-ovn-eip-netfilter/ Thu, 26 Sep 2024 14:45:04 +0800 https://klworldy.com/posts/kube-ovn-eip-netfilter/ 前言 博主近期工作上需要和kube-ovn打交道，后续可能会涉及到基于kube-ovn的二开，因此需要详细了解其特性。昨天在工作中接到了一个关于k8s平台中容器部署的虚拟机中，先ping着外网，然后绑定EIP成功后还是不通，需要把ping关了重新ping才生效，解绑EIP也是如此的问题分析。 VPC kube-ovn中关于VPC的设计，引用原文： VPC 主要用于有多租户网络强隔离的场景，部分 Kubernetes 网络功能在多租户网络下存在冲突。 例如节点和 Pod 互访，NodePort 功能，基于网络访问的健康检查和 DNS 能力在多租户网络场景暂不支持。 为了方便常见 Kubernetes 的使用场景，Kube-OVN 默认 VPC 做了特殊设计，该 VPC 下的 Subnet 可以满足 Kubernetes 规范。用户自定义 VPC 支持本文档介绍的静态路由，EIP 和 NAT 网关等功能。 常见隔离需求可通过默认 VPC 下的网络策略和子网 ACL 实现，在使用自定义 VPC 前请明确是否需要 VPC 级别的隔离，并了解自定义 VPC 下的限制。 在 Underlay 网络下，物理交换机负责数据面转发，VPC 无法对 Underlay 子网进行隔离。 可见kube-ovn中VPC的设计是针对Overlay网络的多租户隔离需求，像单租户下的Overlay网络、Underlay网络分别可以通过k8s中的网络策略、Underlay的Vlan实现隔离需求。 自定义VPC主要是围绕一个VPC网关实现EIP、自定义路由、自定义内部负载均衡、自定义vpc-dns等功能，本次主要设计其EIP功能，拓扑架构如图： VPC Nat Gateway 从具体的CR资源来看其对应关系： 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 111 112 113 114 115 116 117 118 [root@cd56 ~]# kubectl get vpc-nat-gateways. https://klworldy.com/posts/kerneldataflow/ Mon, 16 Sep 2024 11:48:57 +0800 https://klworldy.com/posts/kerneldataflow/ 前言 博主从事云计算行业已经近两年半了，其中接触了近一年半的容器网络，愈发觉得这就是我目前的大体的职业方向。建立该站的初心是希望自己能够对目前接触到的专业知识有进一步的理解掌握，对今后工作中将要接触到的知识理解透彻，逐渐补全自身。废话不多说，网络的话题很大，本篇文章想从Linux内核的网络数据流开始聊起，博主并不擅长C语言，本次归纳只是一个简单的流程梳理，至于其中细节就待今后用到了再细细研究。 内核发送数据包到网络设备的流程 大体流程如图所示： 用户进程调用send方法开始发送数据，最终会调用到系统调用__sys_sendto 方法。在该方法中： 会根据传入的文件描述符查找内核中的socket对象。 将用户空间的待发送数据缓冲区导入到内核空间，并以此构建出msghdr对象。 调用socket_sendmsg，最终选择合适的发送函数（inet6_sendmsg或inet_sendmsg）并执行，进入内核协议栈处理。 在进入到内核协议栈之后， 找到Socket上的具体协议的发送函数，在该发送函数中会创建数据结构sk_buffer，将msghdr对象的数据拷贝到之中，并调用tcp_write_queue_tail函数获取Socket发送队列中的队尾元素，将新创建的sk_buffer添加到【内核socket对象的发送队列尾部】。（如果此时不满足发送条件【比如未发送数据没有达到TCP滑动时间窗口的一半】，则用户进程将数据拷贝到【socket的发送队列】里他的工作就算做完了，此时【内核socket对象的发送队列】里的数据会等到合适的时机进行发送） 根据协议类型（TCP或UDP），间接调用对应的sendmsg函数发送数据，tcp_sendmsg、udp_sendmsg。 调用传输层方法， 拷贝并使用sk_buffer副本，为丢包重传做服务； 并设置好tcp头部，窗口大小设置； 然后通过ip_queue_xmit发送出去； 调用网络层方法， 从本机路由表查询路由； 构建数据报的IP头信息； 调用网络过滤器netfilter 进行进一步处理； 根据MTU判断是否分片处理； 调用neigh_output发送； 调用到邻居子系统， 发送APR请求获取目标Mac地址，然后将sk_buffer中的指针移动到MAC头位置，填充MAC头。 此时的sk_buffer已经是一个完整的以太网数据帧，进入【网络设备子系统】处理。 调用到网络设备子系统， __dev_queue_xmit，初始化qdisc队列排队规则，获取网络设备的传输队列txq，选择其中一个将skb放入。这一步有可能会中断（比如用户线程内核态CPU时间用尽），后续由响应该软中断的【内核ksoftirqd线程】来调用dev_hard_start_xmit方法继续执行。 dev_hard_start_xmit，遍历网络设备传输队列进行发送数据。对于通过回环设备发送的数据，直接进入回环设备的”驱动”里的发送回调函数 loopback_xmit。对于其他设备则： 调用到网卡驱动程序， igb_xmit_frame，在RingBuffer中的数组里选取可用的位置，关联该位置和skb。然后映射数据包到DMA描述符，【网卡驱动程序】通过DMA方式将数据通过【物理网卡】发送出去。 igb_msix_ring，网卡在发送完毕的时候，会给 CPU 发送一个硬中断来通知 CPU。收到这个硬中断后会调用网卡驱动注册的硬中断回调函数触发NET_RX_SOFTIRQ类型的软中断。从而释放skb、清理RingBuffer。 内核接收数据包流程 大体流程如下： 当网卡收到数据以后，CPU发起一个中断，以通知CPU有数据到达。当CPU收到中断请求后，会去调用网络驱动注册的中断处理函数，触发软中断。ksoftirqd 检测到有软中断请求到达，开始轮询收包，收到后交由各级协议栈处理。当协议栈处理完并把数据放到接收队列的之后，唤醒用户进程。 写在最后 本文作为第一篇文章，简单梳理了一下内核发送、接收数据包的大体流程。今后会根据需要逐渐完善其中每个步骤的详细流程，加油吧～