opendaylight

某厂面试归来，发现自己落伍了！>>> 在IntelJ中使用MAVEN构建OSGI项目时例如opendaylight，引用其他项目是打包成bundle的会报错误，实际上是可以编译通过的。 解决方案： Inspections --> OSGI --> Package accessibility 勾选掉就可以了 来源： oschina 链接： https://my.oschina.net/u/1271447/blog/3197499

SDN期末作业——负载均衡 一．作业部分 １．负载均衡程序 代码链接 ２．演示视频 视频链接 ３．程序分工 小组：incredible five 构建拓扑：俞鋆 编写程序：陈绍纬、周龙荣 程序调试和视频录制：陈辉、林德望 ４．个人工作 在期末作业中我和绍伟主要负责程序代码的编写，在做期末作业的过程中我们小组聚在一起开了两次会议，第一次确定要做的内容并分工，第二次将自己的部分和别人的对接。关于代码部分，我们参考了学长的代码，然后对于我们的拓扑结构进行了初步的构思，慢慢开始和队友合作一起编写代码。由于对python语言的不熟悉，编写代码的过程中还是查找了不少资料也和队友一起讨论了多次，最终完成了代码，并虚拟机上运行，和大家一起完成了验收。 程序思路 场景二默认包从s1-s4路径发送，所以先给s2、s3下发流表，使之通行。 （s2、s3流表链接） 。我们小组没有去底层交换机收集信息，再对数据处理得到动态负载均衡，最后经过小组讨论，将s1-s4、s1-s2-s4、s1-s3-s4三条线路默认1：2：2的关系，以经历的线路为基准进行负载均衡，对s4下发流表，使用hardtime机制，让3条线路在一段时间内的占比为2:1:1以达到负载均衡。 拓扑图 拓扑代码 from mininet.topo import Topo class MyTopo( Topo ): def __init__(

在前面介绍学习了OpenDaylight的几个重要模块后，这里再来介绍下完整开发一个模块的过程。 OSGI的bundles提供被其他OSGI组件调用的服务。这个教程中展示的是Data Packet Service去解析数据包（其接口为 IDataPacketService）。 这个小组件不能提供函数供其他bundles调用，但是可以让我们很好的理解为了接收到一个 Packet-in消息事件，必须要实现 IListenDataPacket 接口。当Packet-in消息到达控制器，SAL模块就会通知实现这些接口的组件。 详细过程请见 http://www.frank-durr.de/?p=84 实验室的婷婷学姐翻译了此篇文章，就直接贴过来了，供大家学习 译文 ： 在这个教程里，我会详细解释如何为opendaylight开发一个OSGI组件来实现常规的网络控制逻辑。与REST 接口不同，当一个packet到达并在交换设备流表中失配的时候，将会触发一个packet-in事件，OSGI组件接收packet-in事件。因此，为了实现流响应式编程，OSGI组件是研究OpenDaylight一个很好的切入口。 即使是对于有经验的java程序员，开发OSGI组件的学习曲线也是相当陡峭的，OpenDaylight使用十分强大的开发工具，例如Maven和OSGI、这些程序架构都十分的复杂

OpenDaylight作为一款开源SDN网络控制器，依托于强大的社区支持以及功能特性，成为了目前主流的SDN网络控制器开发平台。在比较稳定的OpenDaylight Helium版本中，已经为开发者提供了大量的网络管理功能与二次开发接口。但是由于OpenDaylight架构复杂以及开发工具的多样化，造成了二次开发思路不够清晰的问题。本文旨在为读者梳理出一条比较清晰的OpenDaylight二次开发路线，降低OpenDaylight的二次开发难度。 一、 OpenDaylight架构简析 要想清晰的看到OpenDaylight为我们提供了什么，最直观的方式就是对OpenDaylight架构图进行梳理，如图1： 图1 如大家所知道的那样，OpenDaylight的结构层次从下到上依次划分为数据平面（包括物理交换设备与虚拟交换设备等）、南向接口与协议插件、控制平面（包括核心控制部分与相关服务）、上层网络应用与服务。数据平面设备的相关技术开发已经超出了OpenDaylight二次开发范畴，因此我们的目光限定在南向协议与插件、控制器服务与上层应用的开发。总体来说，OpenDaylight的二次开发可以分为以下三个层面： 基于OpenDaylight REST APIs的上层网络应用开发 基于SAL内核相关服务的控制器组件与上层网络应用开发

虽然依旧能在市场上看到思科的可扩展网络控制器(XNC)，但是你可能已经注意到思科在最近的一段时间内，一直在谈论其开放SDN控制器（替代XNC）。 显然，思科拥有了基于OpenDaylight氢版本的其他控制器，XNC已经到了退出历史的舞台的时刻。那么该控制器对OpenDaylight架构做了哪些根本性的改变在下面我们将谈到。 OpenDaylight 的核心 思科的开放SDN控制器的变化在控制平台的服务抽象层，位于南向接口之上，如OpenFlow。这意味着隔离了应用程序所在的北向接口。这样，应用程序和网络设备端都可以与抽象层进行交互，这意味着你不需要担心是否一个应用程序知道如何与特定的设备交流。 2014年初发布了OpenDaylight的第一个版本——氢，使用了由API驱动的服务抽象层(AD-SAL)，由思科XNC构造。但是AD-SAL模式有其局限性，也就是它需要知道网络中设备所有的类型。如果要引入一个新的接口，必须要更新更新设备的驱动和控制器。 所以即使推出了OpenDaylight氢版本，思科仍然帮助推动另一种模式:模型驱动的服务抽象层(MD-SAL)。MD-SAL的关键是Yang模型而不是设备APIs。应用程序可以向模型请求更新，然后抽象层向网络设备转发请求。 在这个模型中，控制器不需要识别网络设备的类型。该模型还能使OpenDaylight更模块化；开发团队可以独立工作

OpenDaylight Controller:MD-SAL:Startup Project Archetype Contents [ hide ] 1 Introduction 2 Setup 3 Part 1 - Build with a simple 'Example' module 3.1 Ok it's all downloaded....now what? 3.2 Time to build the 'example' project 3.3 Starting your 'example' project for the first time 3.4 Check for basic functioning 4 Part 2 - Hello World - Defining a Simple RPC 4.1 Run the archetype and create the 'hello' project 4.2 Have a look at 'hello' project 4.3 Build 'hello' project using: 4.4 Check for basic functioning 4.5 Understanding where the log line came from (the entry point) 4.6 Adding a very

关于本次实验首先要感谢技术大神教我学会BGP 、ISIS、MPLS、SR等协议以及ODL与Pathman-SR操控网络。为了本次实验花了二天时间学习BGP、MPSL 以及花了几个小时学习ISIS。后面的ODL安装、SR的搞了×××个星期。ODL也好、还是Pathman-SR也好都是坑，坑到我差点放弃，还好有技术大锅指点才得以顺利完成。 ODL(OpenDayLight)是一个基于SDN开发的模块化、可扩展、可升级、支持多协议的控制器框架,其实内容可参考官网。以下是ODL控制器架构图: 一、 以下内容需要安装系统： 1.1 Linux CentOS(6.8) + JDK (1.7以上版本)，个人习惯CentOS + Python (2.7.3) 1.2 ODL(Nitrogen SR1 0.7.1)，ODL安装有点比较简单，请参考官网。但有个坑，我作为新手是把插件全部安装， 1.3 Pathman-SR需要JDK 1.7版本的支持，安装也比较简单，安装官网安装文档一步一点操作，后面只需修改IP就行了 1.4 EVE-NG，这个是神器啥都实验可以搞，福利啊！需导入支持SR协议的XR、XE路由器的IOS。 下图为本次实验的网络拓扑图： P-01运行BGP 、ISIS 、 Segment Routing并为作RR与ODL ControllerL连接 PE-01与PE-02运行BGP

实验参考 Open vSwitch流表应用实战 实验过程 启动验证 登录OpenDaylight虚拟机，验证OpenDaylight启用是否启用： ps –ef|grep java 查看OpenDaylight所在虚拟机的IP及路由： #ifconfig 查看Mininet所在虚拟机的IP及路由： #ifconfig OpenDaylight所在虚拟机和Mininet所在虚拟机能够互相通信 创建拓扑并连接控制器 流表的简单操作 先查看交换机上的流表，显示的是数据流指向控制器，让控制器来下发流表： sh ovs-ofctl dump-flows s1 在Mininet中pingall一下，交换机下面的两台主机h1、h2应能互相通信，如果不能通信，请检查交换机是否与ODL正确连接 此时再查看交换机s1中流表应多出两条控制器下发的流表： 我们看到每条流规则由一系列字段组成，它们由基本字段、条件字段和动作字段三部分组成。有了流表后交换机就根据流表来进行数据包的操作，当然我们也可以人工的进行流表的新增、修改、删除操作，在我们这个环境下可直接在终端下输入命令 添加删除流表 例如让交换机丢弃从2号端口发来的所有数据包： # sh ovs-ofctl add-flow s1 priority=12,in_port=2,actions=drop 增加这条流表以后