OVS源码阅读
文章平均质量分 69
对Openvswitch,Floodlight Controller源代码进行学习,熟悉openflow协议,拥抱开源!
vonzhou
这个作者很懒,什么都没留下…
展开
-
对openvSwitch中不同类型端口的理解
同一主机上的OVS中可以创建多个网桥(即多个datapath实例),每个bridge可以通过patch ports互联,而netdev ports是OVS对底层物理端口的抽象封装,internal 类型的端口比较不好理解,可以看做每个OVS交换机有个可以用来处理数据报的本地端口,可以为这个网络设备配置 IP 地址(比如在把eth0加入某个bridge的时候,它的IP地址就失效了,可以把IP地址原创 2014-10-10 18:49:50 · 10896 阅读 · 5 评论 -
OpenvSwitch中端口的抽象层次结构
OpenvSwitch中对端口的抽象层次结构 struct vport抽象的是OVS中datapath层的每个端口,通过它将ovs中的各种数据结构与Port关联起来,而结构体netdev_vport 就是vport和底层真实网络设备结构net_device 的入口,关键数据结构如下:struct vport { struct rcu_he原创 2014-09-16 15:08:14 · 2728 阅读 · 0 评论 -
OVS 发送OFPT_PORT_STATUS 过程
根据openflow协议,当一个物理端口从ovs datapath 增加,修改或者删除的时候,都会通过ofp_port_status异步消息告知Controller,比如当我们执行 ovs-vsctl add-port br0 eth0 之类的命令后,就会更新ovsdb数据库,而后全局变量 reconfiguring 变为true,从而会重新配置这个ovs。if (reconfig原创 2014-08-24 10:09:57 · 4627 阅读 · 0 评论 -
对 dpif_class 结构体的一点认识
类 dpif_class 抽象的是OVS交换机用户空间和内核层datapath的通信接口(通过netlink),分层是出于性能和生产效率的考虑,通过接口dpif_class,用户层ovs-vswitchd会把发送各种端口,流表,查询等动作到内核层进行实际的执行,比如说我们增加一个端口到ovs中,那么就会从用户空间构造增加端口的 dpif_linux_vport 请求到datapath层。重点要原创 2014-08-18 20:44:26 · 3490 阅读 · 0 评论 -
Floodlight Controller 路由原理
SDN的出现可以使得各种复杂的路由协议从原本的Device OS中剥离出来,放在SDN Controller中,Controller用一种简单的协议来和所有的Router进行通信,就可以获得网络拓扑,从而计算路由,有更好的可扩展性(scalable,而不会出现Full-Mesh)。Floodlight 中路由的原理利用的是LLDP这个协议,当第一个OF SW连接过来的时候,Controller原创 2014-07-21 21:02:00 · 2990 阅读 · 0 评论 -
对扩展openflow协议的一点思考
软件定义X变得越来越火,正所谓,Software is eating the world。软件定义网络也是如此,不论是在工业界还是学术界都将是一次伟大的革命,都在紧随着这个行业的方向,找自己的研究点,关注着标准化的进展。各种Controller,原型系统都相继出现,还有的是是做SDN 的Debug,安全,总之让这个生态系统变得更加健壮。虽然南向接口标准很多,但是openflow适合我们的学习,社区原创 2014-07-18 21:26:19 · 2356 阅读 · 1 评论 -
OVS 响应 OFPT_SET_CONFIG 过程分析
ovs 对于 OFPT_SET_CONFIG消息的处理过程非常简单,其实就是通过TCP协议(或其它)交换了几个整型值,而且交换机不需要对此消息进行回复;只需要解析出消息体(struct ofp_switch_config)然后设置max miss len 即可。通过分析Floodlight发送它的过程 和 OVS 处理它的过程,我们可以对openflow协议有更好的理解。下面是代码流程:原创 2014-07-16 10:46:06 · 2456 阅读 · 1 评论 -
OVS流表查询过程分析
OVS中流表操作的理解关键在于这里哈希表的实现,引入的 flex_array方便了内存的管理,通过 hash&(桶数-1)可以随机的将一个元素定位到某一个桶中。 接下来是代码细节。一. 核心数据结构//流表struct flow_table{ struct flex_array * buckets; //具体的流表项 unsigned原创 2014-06-30 15:54:46 · 9452 阅读 · 0 评论 -
Floodlight中 处理packetin消息的顺序(2)
前面通过阅读代码知道了如何判断各个模块处理某个消息的先后顺序,那么内部是如何实现的呢? 每当一个模块表示对一个消息感兴趣的时候,就会调用IFloodlightProviderService(具体有Controller类实现)的addOFMessageListener方法进行注册订阅,核心工作是由 ListenerDispatcher类来完成:1)每次增加一个观察者的时候都会判断其是否是原创 2014-06-25 16:57:20 · 1888 阅读 · 0 评论 -
Floodlight中 处理packetin消息的顺序(1)
当Controller和SW建立连接之后,就可以处理来自SW的各种OF msg。当接收到 packetin 消息之后,会将其分发给各个监听了这个OFMessage的listeners,所以如果我们要设计自己的控制器模块,只需要实现相应的接口方法,约定执行顺序即可。接口IListener 主要抽象了监听器模块的名字,执行顺序,接口IOFMessageListener则抽象了我们的Controller原创 2014-06-24 15:58:36 · 3592 阅读 · 0 评论 -
Floodlight下发流表过程分析
转载请注明出处:当一个packet到达openflow交换机,会进行流表的匹配,如果没有找到相应的流表项,就会发送一个packet_in消息到达SDN controller端,控制器根据一定的路由算法决策后,会向该路径上的所有交换机下发流表(也就是发送FLOW_MOD消息,里面有对应的action)。这里要知道的是在SDN的环境下,控制器具有全局拓扑信息,每当有链路状态改变时就会跟原创 2014-06-18 20:34:28 · 8724 阅读 · 6 评论 -
OVS处理upcall过程分析
处理upcall的整体框架是:1.由函数handle_upcalls()批量处理(in batches)的是由内核传上来的dpif_upcalls,会解析出upcall的类型。这里主要看在内核中匹配流表失败的MISS_UPCALL。处理完成后会得到多个flow_miss。结构体dpif_upcall代表的是由内核传到用户空间的一个包,包括上传原因,pac原创 2014-06-08 12:14:48 · 5870 阅读 · 0 评论 -
对openflow 1.0协议的扩展
通过这几天对openvswitch代码的分析,以及项目的需要,需要对openflow 1.0进行一定的扩展,发现网上没有这方面的教程,虽然在搞懂ovs代码架构,floodlight controller中利用的事件驱动模型之后,会觉得并不是难事,但是对于刚入门SDN的同学来说,需要一番折腾,这里简单记录一下,希望帮助到其他人。 环境配置:2host + 1 OVS + floodlight原创 2014-06-06 17:03:34 · 2947 阅读 · 4 评论 -
Floodlight 中创建消息对象的方法
在 floodlight 中创建各种openflow message 和 action 等采用的是简单工厂方式,BasicFactory类(实现OFMessageFactory接口,)会根据消息的类型创建不同的对象,达到更好的封装效果;此外这里调用的是枚举类型的方法。下面是具体代码:----------工厂接口,还有OFActionFactory,约束需要具体工厂完成的事情原创 2014-07-01 09:53:51 · 1809 阅读 · 0 评论 -
Floodlight controller和OF SW交互流程图
原创 2014-06-24 15:53:37 · 1846 阅读 · 0 评论 -
Floodlight 中 ChannelPipeline 结构图
1. IdleStateHandler 当Channel上没有执行相应的读写操作一定时间的时候出发一个 IdleStateEvent 事件;2. ReadTimeoutHandler 读超时处理;3. HandshakeTimeoutHandler 设置一个定时器检查连接的状态,握手阶段 ;4 . OFChannelHandler 核心,处理所有的业务。原创 2014-06-23 21:00:22 · 1943 阅读 · 0 评论 -
OFMessageDecoder 分析
OFMessageDecoder 继承了抽象类 FrameDecoder。FrameDecoder 会将接收到的ChannelBuffers 转换成有意义的 frame 对象,在基于流的传输过程中,通常会发生分片和重组的情况,所以就需要一个解码器,根据特定协议的约束,将收到的包理解为相应的,易于应用逻辑层处理的对象。这里调用的是 BasicFactory 的 parseMe原创 2014-06-23 20:18:14 · 1389 阅读 · 0 评论 -
Floodlight之 FloodlightContextStore 数据结构
FloodlightContextStore 代表的是一种缓存模型(利用的是ConcurrentHashMap),里面存储的是上下文相关的对象,能够根据相应的key得到具体的 Object,存在的意义是Floodlight中注册监听某个事件的listener可以在被调用的时候直接从中取出上下文信息(context information)。下面是重要的代码片段.基本数据结构:pub原创 2014-06-23 19:04:37 · 1607 阅读 · 0 评论 -
Floodlight 启动流程分析
1. 在Main中先是加载模块,启动REST服务,而后构建一个实现了IFloodlightProviderService接口的实例(即Controller)并运行;2. 接下来进入Controller的run()方法,此时所有的环境初始化工作已经完成,构建一个基于netty的TCP server,最重要的是流水线factory OpenflowPipelineFactory 的设置,里面是co原创 2014-06-23 10:52:48 · 2539 阅读 · 0 评论 -
从PACKET_IN消息中得到packet data
在Floodlight模块中如果想得到packet in消息,就对相应的消息类型进行监听即可,然后在receive方法中就可以操纵这个上传上来的packet_in。 关键代码: Ethernet eth = IFloodlightProviderService.bcStore.get(cntx,原创 2014-06-16 10:58:25 · 6370 阅读 · 4 评论 -
OVS响应OFPT_FLOW_MOD过程分析
整理处理流程图:1. 通过对of msg进行解码,可以得到具体的flow_mod以及对应的actions,(这里看增加流表的情况),接下来add_flow函数就会根据flow_mod制定的流来构建特定的规则分类器,增加到oftable中。具体过程是:选择一个合适的表;构建一个分类规则(关键代码如下);插入。这样此次通信的任务就完成了,当再有packet因为在datapa原创 2014-06-09 14:05:42 · 4150 阅读 · 2 评论 -
ovs处理openflow消息的流程
ovs处理openflow消息的流程原创 2014-06-07 14:23:50 · 4546 阅读 · 0 评论 -
用户空间发送flow,packet操作告知内核处理过程
用户空间从flow_miss_ops分门别类构造nla告知内核中相应的genl family。接下来分别调用对应的处理函数对流表进行添加删除操作,同时发送通知消息。内核层响应用户空间下发来的流表以及packet操作。原创 2014-03-10 20:32:07 · 3603 阅读 · 1 评论 -
用户空间具体是如何处理dpif_upcall ?(3)执行flow_miss_op->dpif_op,与内核沟通
阶段三:调用datapath interface具体实现类(这里是dpif_linux_class)的operate方法进行批量处理,后面如果有剩余项的话再分别调用/put/del/execute。将对应的参数通过nla发送到内核(内核来真正的执行操作)然后接收回应来更新统计信息。流程图如下:-------------lib/dpif.cvoid dpif原创 2014-03-09 15:00:07 · 7431 阅读 · 0 评论 -
用户空间具体是如何处理dpif_upcall ?(2)构造datapath actions
阶段一完成后会将upcall中的相应信息构造早flow_miss中,接下来批量处理,查找facet,如果没有找到的话就要根据ofproto_dpif->rule和flow_miss->flow来创建facet,然后为其构建subfacet,继而subfacet_make_actions会由subfacet->rule->ofpacts相关信息构造odp_actions,然后根据具体的openflo原创 2014-03-09 12:56:24 · 4512 阅读 · 0 评论 -
用户空间具体是如何处理dpif_upcall ?(1)构造flow_miss批量处理
通过前面的分析,现在用户空间拿到了自内核传上来的关于未能在内核得到匹配的packet的netlink message的信息,接下来批量处理这些upcalls。流程图如下: 这个模块可以分成三个阶段:1)由dpif_upcall得到flow_miss 集合,构造填充相应的字段;2);3)。处理upcall的数据结构有:flow_miss是将具原创 2014-03-08 10:19:46 · 2110 阅读 · 0 评论 -
ovs-vsctl add-port br0 eth1 实际做了什么?
ovsctl这个应用程序主要职责是根据用户的命令和ovsdb沟通,将配置信息更新到数据库中,而vswitchd会在需要重新配置的时候和ovsdb打交道,而后和内核datapath通信执行真正的动作。这里规定了命令的语法格式(vsctl_command_syntax )以及所支持的所有命令,这里主要看add-port相关的。 struct vsctl_command_syntax {原创 2014-02-26 15:42:53 · 11788 阅读 · 1 评论 -
OVS datapath模块分析:packet处理流程
这来主要看看ovs从网络接口收到packet后的一系列操作。 在初始化vport子系统的时候(ovs_vport_init)会struct netdev_vport { struct rcu_head rcu; struct net_device *dev;};const struct vport_ops ovs_netdev_vport_o原创 2014-02-24 20:43:54 · 6042 阅读 · 3 评论 -
packet在内核空间匹配失败后传到用户空间的处理逻辑是什么?
我们知道当packet到达交换机之后会提取出flow key->查询流表,如果匹配成功就执行对应的action,否则构造netlink attribute发送到用户空间对应的进程,这里vswitchd会调用handle_upcalls(ofproto/ofproto-dpif.c)来处理。主要流程图是:结构体 dpif_upcall 表征的是从datapath传到use原创 2014-03-04 18:12:49 · 2544 阅读 · 0 评论