Floodlight 启动及下发流表流程分析
2015-05-16 12:03
246 查看
在Main中先是加载模块,启动REST服务,而后构建一个实现了IFloodlightProviderService接口的实例(即Controller)并运行,进入Controller的run()方法;
位置:net.floodlightcontroller.core.Main.java ;
功能:初始化IFloodlightModuleContext变量,启动Controller和RESTApi Service
位置:net.floodlightcontroller.core.internal.Controller.java
Run()方法启动Controller,监听Switch的请求和将监听事前发送给各个监听模块。
此时所有的环境初始化工作已经完成,构建一个基于netty的TCP server,最重要的是流水线factory OpenflowPipelineFactory 的设置,里面是controller上流,下流处理的handler。
Floodlight 使用的是Netty架构,在Controller.java 入口函数中显示创建ServerBootstrap:
[code] //使用到了JBoss 的Netty框架 //创建Netty的服务端ServerBootstrap final ServerBootstrap bootstrap = createServerBootStrap(); bootstrap.setOption("reuseAddr", true); bootstrap.setOption("child.keepAlive", true); bootstrap.setOption("child.tcpNoDelay", true); bootstrap.setOption("child.sendBufferSize",Controller.SEND_BUFFER_SIZE); //创建处理Switch连接的工厂 ChannelPipelineFactory pfact = new OpenflowPipelineFactory(this, null); //设置服务端处理连接的工厂 bootstrap.setPipelineFactory(pfact); InetSocketAddress sa = (openFlowHost == null) ? new InetSocketAddress(openFlowPort) : new InetSocketAddress(openFlowHost, openFlowPort); //将服务端加入线程池 final ChannelGroup cg = new DefaultChannelGroup(); cg.add(bootstrap.bind(sa)); log.info("Listening for switch connections on {}", sa);
设置套接字选项ChannelPipeline,此时监听套接字就准备好处理来自SW的各种消息;这里最核心的就是 OpenflowPipelineFactory ,会加入各个业务相关的Handler,ChannelPipeline工厂代码如下:
[code] public ChannelPipeline getPipeline() throws Exception { OFChannelState state = new OFChannelState(); ChannelPipeline pipeline = Channels. pipeline(); pipeline.addLast( "ofmessagedecoder", new OFMessageDecoder()); pipeline.addLast( "ofmessageencoder", new OFMessageEncoder()); pipeline.addLast( "idle", idleHandler ); pipeline.addLast( "timeout", readTimeoutHandler ); pipeline.addLast( "handshaketimeout", new HandshakeTimeoutHandler(state, timer , 15)); if (pipelineExecutor != null) pipeline.addLast( "pipelineExecutor", new ExecutionHandler(pipelineExecutor )); //OFChannelHandler 是核心 pipeline.addLast( "handler", controller.getChannelHandler(state)); return pipeline; }
当Channel建立,接收到来自OF SW的消息之后就会调用 messageReceived() 方法;根据不同的of msg类型,分发给 processOFMessage 进行具体处理;此外,如果这个消息需要进行对SW的回复,或者有其他监听者感兴趣,就呼叫 handleMessage 进行额外的处理,代码贴出来。
[code] protected void handleMessage(IOFSwitch sw, OFMessage m, FloodlightContext bContext){ Ethernet eth = null; switch (m.getType()) { case PACKET_IN: OFPacketIn pi = (OFPacketIn)m; // 默认情况下总是true if (Controller.ALWAYS_DECODE_ETH) { eth = new Ethernet(); //解析packet_in消息到eth中,所以下面的bcStore可以直接存储 eth.deserialize(pi.getPacketData(), 0, pi.getPacketData().length); counterStore.updatePacketInCounters(sw, m, eth); } // fall through to default case... default: List<IOFMessageListener> listeners = null; if (messageListeners.containsKey(m.getType())) { listeners = messageListeners.get(m.getType()).getOrderedListeners(); } FloodlightContext bc = null; if (listeners != null) { // Check if floodlight context is passed from the calling // function, if so use that floodlight context, otherwise // allocate one if (bContext == null) { bc = flcontext_alloc(); } else { bc = bContext; } if (eth != null) { IFloodlightProviderService.bcStore.put(bc,IFloodlightProviderService.CONTEXT_PI_PAYLOAD, eth); //缓存到hashmap中,所以当我们添加自己的模块来监听packetin消息的时候,可以从中取出,做自己的业务处理。 } Command cmd; for (IOFMessageListener listener : listeners) { if (listener instanceof IOFSwitchFilter) { if (!((IOFSwitchFilter)listener).isInterested(sw)) { continue; } } // 遍历所有对packetin感兴趣的listener,分别执行他们的receive方法; cmd = listener.receive(sw, m, bc); if (Command.STOP.equals(cmd)) { break; } } } if ((bContext == null) && (bc != null)) flcontext_free(bc); } }
3. 在循环中随时处理SW的更新消息,开始分发事件给监听者:
[code] // main loop // 不断处理阻塞队列中SW的更新信息 while (true ) { try { IUpdate update = updates.take(); update.dispatch(); } catch (InterruptedException e) { return; } catch (StorageException e) { log.error("Storage exception in controller " + "updates loop; terminating process", e); return; } catch (Exception e) { log.error("Exception in controller updates loop", e); } }
4. 那么Controller中的BlockingQueue中的更新信息是在何时加入的呢?这里只跟踪交换机加入的情况,很容易想到当监听套接字收到一个来自OF SW请求的时候。所以我们看 OFChannelHandler ,可以视为是业务相关的第一个UpstreamHandler,在通道连接的时候会回送一个HELLO消息,这里的重点看处理消息的过程,进入函数 messageReceived 接下来的处理流程(如下),在收到 GET_CONFIG_REPLY 消息之后说明这个SW准备好了(会把握手状态改为 HandshakeState.READY),而后会把这个SW加入到activeSwitches 和 updates中。
Floodlight controller和OF SW交互流程图:
更新阻塞队列的代码是:
[code] updateActiveSwitchInfo(sw); SwitchUpdate update = new SwitchUpdate(sw, true); try { // 把update加到BlockingQueue里,如果BlockQueue没有空间,则调用此方法的线程被阻断 // 直到BlockingQueue里面有空间再继续. this.updates .put(update); } catch (InterruptedException e) { log.error("Failure adding update to queue" , e); }
通过上面的分析,相当于有了一个生产消费者模型,生产者就是交换机的加入或者移除消息,消费者就是Controller的处理过程,取出消息进行计算,为拓扑更新服务。具体过程仍然是一个监听者模式,把SW的更新信息分发到各个订阅者中进行处理(看SwitchUpdate类),代码如下:
[code] public void dispatch() { if (log .isDebugEnabled()) { log.debug("Dispatching switch update {} {}", sw, added); } // 遍历这些listeners,处理加入或移除事件 if (switchListeners != null) { for (IOFSwitchListener listener : switchListeners) { if (added ) listener.addedSwitch( sw); else listener.removedSwitch( sw); } } }
那么订阅 SwitchUpdate 消息的类是谁呢?LinkDiscoveryManager!交换机的加入或者移除活动肯定会带来链路信息的改变,当加入一个新SW的时候,就会通过发送 LLDP frame 来发现拓扑结构(参见 Floodlight Controller 路由原理 )。代码如下
[code] public void addedSwitch(IOFSwitch sw) { //这里的设计需要优化 // It's probably overkill to send LLDP from all switches, but we don't // know which switches might be connected to the new switch. // Need to optimize when supporting a large number of switches. sendLLDPTask.reschedule(2000, TimeUnit.MILLISECONDS ); // Update event history evHistTopoSwitch(sw, EvAction. SWITCH_CONNECTED, "None"); }
5.当一个packet到达openflow交换机,会进行流表的匹配,如果没有找到相应的流表项,就会发送一个packet_in消息到达SDN controller端,控制器根据一定的路由算法决策后,会向该路径上的所有交换机下发流表(也就是发送FLOW_MOD消息,里面有对应的action)。这里要知道的是在SDN的环境下,控制器具有全局拓扑信息,每当有链路状态改变时就会跟新拓扑,而路由的计算是需要下发转发规则的时候进行。下面对这个流程进行详细分析。
链路发现模块会关注两种消息 PACKET_IN 和 PORT_STATUS ,从而分析链路的变更。这里看对于PACKET_IN ,LinkDiscoveryManager的处理过程:
LinkDiscoveryManager完成的工作是增加或更新链路状态,加入到一个LDUpdates队列中,接下来看拓扑管理模块TopologyManager,它在启动的时候会新起一个线程 NewInstanceWorker :首先根据消息类型来增删该链路的状态,然后创建一个计算拓扑的实例TopologyInstance来计算出拓扑并存储,具体过程如下:
当完成拓扑计算后,当来了一个packet_in,就会根据源目SW得到路径。
接下来防火墙,负载均衡模块会发挥作用(这里先略过)。
最后路由模块会完成最终的下发流表操作,这里看Forwarding模块中的processPacketInMessage()。
会从packet中得到相应的源目设备实例IDevice,而后判断是否在同一个openflow island上,如果不在的话就
doFlood(sw, pi, cntx),这里主要看二者在同一个island的情况。然后得到每个设备的AttachmentPoints,
然后找到二者能够连通的粘合点,接下来得到路劲,最后构造flow_mod消息,写入通道,下发给SW。
相关文章推荐
- SDN启蒙(2):Floodlight 启动及下发流表流程分析
- Floodlight启动流程分析图
- Floodlight 启动流程分析
- activity 启动流程分析
- android开发之源码级分析(系统启动流程 & Handler消息机制 & AsyncTask机制)
- 【嵌入式Linux学习七步曲之第四篇 Linux内核移植】PPC Linux启动流程分析
- Linux 启动流程即init程序分析--1
- 从0移植uboot (二) _uboot启动流程分析
- PX4源码分析5_PX4启动流程
- uboot 启动流程分析
- Android APP启动方式、启动流程及启动优化分析
- k8s源码分析-----kubelet启动流程分析(续)
- 安卓系统的启动流程(源码分析)
- streamsets Data Collecotor启动流程分析
- 嵌入式Linux启动流程分析
- [转载] linux启动流程分析(4)---汇编部分(5)
- ServerBootStrap启动流程源码分析
- Android4.0源码Launcher启动流程分析
- Activiti系列:带有serviceTask的或者定时启动任务的流程部署失败的原因分析
- linux 启动详解 分析 启动流程