SDN Qos差异化服务实现与问题解决

借助SDN开放的北向接口，用户可以按需定制北向应用，通过应用快速有效地将带宽策略下发到SDN交换机设备，实现带宽策略的快速自动化部署。其架构如下图所示：

OpenDaylight中的OpenFlow实现分为OpenFlowJava和OpenFlowPlugin两部分，其中OpenFlowJava负责面向南向设备完成OpenFlow协议的序列化、反序列化、端口监听以及消息分发，而OpenFlowPlugin负责完成OpenFlow协议的状态管理、会话管理、事务处理等，向SAL层提供服务。

OpenFlowPlugin实现了OpenFlow协议，它提供了REST API接口，这里需要关注添加流表项、添加计量表项等接口；OpenFlowPlugin提供了SalFlowService和SalMeterService服务，在这两个服务接口中定义了插入、删除和更新流表项、计量表项的方法。因此，流量限速插件可以通过组合这些基础功能完成限速功能。

• 数据层

数据平面交换节点通过OpenvSwitch实现，通过OpenFlow协议与控制器连接。

• 控制层

控制平面是由Java语言编写，基于OpenDaylight架构的控制器，通过OpenFlow协议及OVSDB与数据平面交互，通过HTTP REST API与应用层交互。

• 应用层

应用层是通过Python语言编写，可视化的呈现拓扑信息，交换机信息及实时流量统计。

这是本次试验的逻辑框架：

控制层的设计

• 拓扑管理

控制器需要将拓扑信息收集至拓扑结构库中，作为后续的路由算法、转发规则的知识库，保证其更加稳定、高效地工作。控制器需要合理地管理网元设备信息，保证网元设备的连接的稳定性，并实现合理的错误反馈，保证与网元设备通信时的稳定性与正确性。建立OpenFlow连接后，需要保证交换机与控制器之间通信的稳定性。

• 链路状态检测

当系统开始运行后，控制器将周期性的收集来自OpenFlow协议上报的各个交换机数据，并通过LLDP报文探测交换机间链路信息。控制器通过部署的sFlow collector收集交换机端口流量统计信息，并开放出接口提供给上层应用调用。

• 流规则配置

当交换机通过OpenFlow协议与控制器建立连接后，控制器下发基础流表至交换机，匹配ARP请求报文发送至控制器。控制器接收到ARP请求报文后进行广播操作，并通过端口-MAC对应关系学习主机位置信息，下发转发流表项匹配目的主机信息，转发至对应端口，从而实现基础的二层转发功能。

• Qos规则配置

控制器提供接口下发Qos规则配置，先下发Meter表项，指定限制速率。Meter表项下发成功后，下发流表项匹配Qos对应交换机端口，实现主机间通信限速功能

• 工作流程

控制平面工作流程图如下图所示

实验拓扑

环境启动：

1，部署控制平面

Controller1作为ODL控制器、SFLOW采集器、基于SDN的QoS差异化服务应用服务器，提供对数据平面进行集中管控并部署SDN应用。

2，启动数据平面拓扑

在Switch1上进行：

OVS配置Sflow Agent

ovs-vsctl -- --id=@sflow create sflow agent= target=\":6343\" header=128 sampling=10 polling=1 -- set bridge  sflow=@sflow

3，启动Sflow Collector

以下配置在Controller1上进行：

root@openlab:~#cd /home/openlab/sdn-qos/sflow-rt/

root@openlab:#nohup sh start.sh -c &

4，启动控制器

以下配置在Controller1上进行：

root@openlab:tar -zvxf flowmanager-karaf-1.0-SNAPSHOT.tar.zvxf

root@openlab:cd flowmanager-karaf-1.0-SNAPSHOT/bin

root@openlab:/home/openlab/sdn-qos/backbone-karaf-1.0.0-SNAPSHOT/bin#./start

配置交换机连接控制器：

root@openlab:~#ovs-vsctl set-controller br-sw tcp:[controller-ip]:6633

控制器更新sflow collector-ip

以下配置在Controller1上进行：

访问控制器：http://:8181/index.html#/yangman/index

输入用户名、密码admin/admin，在Yangman中下发流表：

Method：POST 

URL：http://127.0.0.1:8181/restconf/operations/topology:update-collector-ip

{"update-collector-ip": {"input": {"collector-ip": ""}}
}

备注：

：sflow collector IP地址。

返回结果如下图

启动“基于SDN的QoS差异化服务”APP

以下配置在Controller1上进行：

root@openlab#cd /home/openlab/sdn-qos/diff-service/  

root@openlab:/home/openlab/sdn-qos/diff-service# python manage.py runserver 0.0.0.0:80

（服务端口可自定义）

演示过程

访问APP服务：http://: 

备注：

server_ip：基于SDN的QoS差异化服务APP服务器IP地址

port：服务器APP监听端口

• 在“IP地址管理”中录入控制器、交换机IP

如下图所示：

• 连接交换机的4台Host 进行ping操作

在实验控制台操作4台Host进行ping包动作，保证控制器能够发现Host的接入

• 在“拓扑管理”中查看拓扑发现情况

在“拓扑管理”中点击右侧按钮，查看拓扑发现情况

• 在“配置管理”中配置金牌/银牌用户进行差异化服务

配置实现：Host 30.0.2.8->Host 30.0.2.6为金牌用户流量，Host 30.0.2.8发送1024Kbps流量，经差异化限速到达Host 30.0.2.6的流量大小为2048Kbps。

1）配置金牌用户

2）host 30.0.2.8使用iperf向host 30.0.2.6发送10Mbps流量：

3) 在“拓扑管理”中刷新拓扑，查看差异化限速情况：

附：

在此过程中遇到几个比较棘手的问题，在此分享一下解决方法：

1，在拓扑管理中，上行流量和下行流量一直显示为0Kbps

因为流量监控是通过sFlow来实现，所以将问题定位到Sflow上，先看一下Sflow Collector是否启动成功

root@openlab:#nohup sh start.sh -c &

这是我们启动Sflow的命令

我们直接运行是不会有错误提示的，这时需要去查看 nohup.out

root@openlab:#less nohup.out

发现Sflow启动失败

这时我们可以重启Controller

然后再执行

root@openlab:#nohup sh start.sh -c &

查看 nohup.out

root@openlab:#less nohup.out

发现已经启动起Sflow Collector服务

这时应该已经可以解决此问题

2，交换机一直未能连接控制器

我们通过此命令来使交换机与控制器连接

root@openlab:~#ovs-vsctl set-controller br-sw tcp:[controller-ip]:6633

这时正常情况下，ovs-vsctl show命令执行的结果

但是，在实验过程中，会有is_connected=true不出现的情况，说明交换机与控制器并未连接成功

使用ovs-ctl stop与ovs-ctl start停止与启动ovs进程也未能解决问题

然后可以通过重启交换机，再在交换机中输入命令

root@openlab:~#ovs-vsctl set-controller br-sw tcp:[controller-ip]:6633

即可解决此问题

3，下发流表后，在交换机中能找到相应的流表，并且流量也确实流经流表，但不按流表规则执行动作

我们在应用层配置，对流量进行限制，并且通过下图也能发现在交换机中，也有对应的流表与Meter表

而且，流量也确实流经了流表，但是，通过应用层的反馈来看，下行速率并没有限制为我们所设置的limited-rate。

此处我们可以将流表的触发条件brust-size与limited-rate重新选择数值来进行设置，与先前错误的流表数值不同，发现在拓扑中下行速率已经得到限制，解决此问题。

4，burst-size

burst-size是什么，说一下我的自我理解，limited-rate是链路总共可用的令牌桶，当你链路上的流量速度超过limited-rate后，可以从burst-size里获得额外的令牌，使得流量在短时间可以突破limited-rate规定的峰值。实际的应用环境比如，微博某某明星有大新闻时，会有很大的流量，而这种流量的增加几乎是瞬间的，并且是在不断变化的，我们规定了burst-size，就可以使链路承受更大的流量波动，他限制了我们流量向上波动最大不能超过burst-size，也就是说，链路流量最大不能超过limited-rate+burst-szie，就算是到达，也仅仅是短时间的。

总结：

此上三个问题，我推测应该与缓存有一定的关系，可能是框架，应用，交换机，或者是浏览器中的缓存导致，今后若有机会，将对缓存机制进行深入研究。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！