编者按：最近涉及的一个实验，需要获取链路接口的实时信息，比如带宽、流量统计等。起初打算从OpenFlow协议中的计数器入手，OpenFlow交换机对每一个流维护一个计数器，控制器可以从这些计数器上查询每条链路的实时流量信息。随着网络规模增大，流量增加，对计数器管理会变得越来越消耗系统资源，如Floodlight FAQ所提到对控制器而言这样的监控很难准确的，所以否定了在控制器上实现流量监控的想法，转而考虑通过第三方平台监控每条链路的实时流量信息。sFlow可以提供周期性的网络接口统计采样和数据包采样，能够提供各接口的流量信息，且几乎不会对被统计设备造成任何负担，管理成本极低。sFlow的部署分为两部分：sflow agent和sflow collector。sflow agent内嵌入网络设备中获取设备的实时信息并封装成sFlow报文发送给sflow collector。sflow collector汇总后得出统计数据。初次使用sFlow监控流量，做了一个DDOS防御及队列调整实验。
一、sFlow监控之DDOS防御实验
1.1 实验环境
本实验是在一台物理主机上完成实验拓扑，主要工作是进行控制器部署和sFlow部署。通过Mininet模拟一个switch、三台host。控制器使用Floodlight，由于Mininet已经部署了sflow agent，所以只需要部署sflow collector。
实验拓扑如下图：
sFlow官网推荐了几款sFlow软件如sflow-trend,sflow-rt等，这里我选择的是sflow-rt，安装sflow-rt很简单。
1.下载官方压缩包（注：也可参考《基于Mininet的网络流量监控》）；
2.解压安装：
|
1 2 3 |
$tar -zxvf sflow.tar.gz $cd sflow/sflow-rt $./start.sh |
在ovs交换机上还要配置sflow agent，输入以下命令：
|
1 |
$sudo ovs-vsctl -- --id=@sflow create sflow agent=eth0 target=\"192.168.2.233:6343\" header=128 sampling=10 polling=1 -- set bridge s1 sflow=@sflow |
注意：agent是要监听的网卡，这个网卡一定要能监听到我们所需的交换机的流量，target是sflow collector所在的ip地址，bridge设定需要监听的交换机。
1.2 实验原理
sflow-rt统计到的每个接口的流量信息，可以通过sflow-rt的rest api获取json数据并对json数据进行解析获得。对解析到的数据进行判断分析后即可实施策略。本次实验原理如下：
1.首先对sflow-rt进行配置，设定metric=ddos,并设定它的阈值，当监测到的流量超过这个阈值时即判断为ddos；
定义地址组：
|
1 |
curl -H "Content-Type:application/json" -X PUT --data "{external:['0.0.0.0/0'], internal:['10.0.0.0/8']}" http://localhost:8008/groups/json |
定义流 ：
|
1 |
curl -H "Content-Type:application/json" -X PUT --data "{keys:'ipsource,ipdestination', value:'frames', filter:'sourcegroup=external&destinationgroup=internal'}" http://localhost:8008/flow/incoming/json |
定义阈值：
|
1 |
curl -H "Content-Type:application/json" -X PUT --data "{metric:'ddos', value:1000}" http://localhost:8008/threshold/incoming/json |
2.若判断为ddos，即调用Floodlight的staticflowentrypusher对ddos攻击包进行丢弃；
由于sflow获取的的openflow信息是使用snmp中定义的ifindex对各接口进行标记，而openflow有它自己的标记方式，所以应该对openflow端口号和ifindex端口号进行映射。本次实验采用nodejs作为应用语言。
1.3 实验结果
本次实验DDOS攻击采取host1向host2泛洪的方式。命令如下：
|
1 |
mininet>h1 ping -f h2 |
运行DDOS防御应用前：
我们可以看到，未运行ddos防御应用时，h1向h2泛洪的数据包达到了大约每秒30k个包。
接下来运行ddos防御应用：
|
1 |
nodejs ddosm.js |
运行DDOS防御应用后：
可以看出，运行ddos防御应用后，h1向h2泛洪的包迅速被完全的丢弃了。
二、sFlow监控之队列调整实验
2.1 实验介绍
基于sFlow的DDOS防御实验的成功，坚定了继续基于sFlow做流量监控的想法。本次实验主要目的是基于sFlow监控的基础上，通过Floodlight实现进行队列调整。
2.2 实验设计
1.拓扑结构沿用实验一的拓扑结构：switch+3hosts+floodlight+sflow，拓扑图如实验一所示。
2.设计思想：switch上有三个端口分别连接有host1,host2,host3。在端口3上设置3条队列，分别带宽设置为：
|
1 2 3 |
— —id=@q0 create queue other-config:min-rate=1000000000 other-config:max-rate=1000000000 — —id=@q1 create queue other-config:max-rate=20000000 other-config:min-rate=20000000 — —id=@q2 create queue other-config:max-rate=2000000 other-config:min-rate=2000000 |
主机host1和host2同时向host3发送数据包，通过sFlow流量监控，获取端口1和端口2的速率分别为R1和R2，然后进行判断：
- 若R1>R2:端口1到端口3的队列—>q0 端口2到端口3的队列—>q2
- 若R2>R1:端口1到端口3的队列—>q2 端口2到端口3的队列—>q0
- 若R1=R2:端口1到端口3的队列—>q1 端口2到端口3的队列—>q1
2.3 实验结果
首先让host1和host2分别向host3泛洪：
|
1 2 |
h1> ping -f h3 h2> ping -f h3 |
执行队列调整应用后终端显示:
可以看出，由于端口1(注意：eth0~eth2依次对应端口1~3)的速率比端口2的速率快，应用立即通知Floodlight控制器下发流表给端口1和端口2设定不同的出口队列，再来看看Floodlight控制器的流表：
从流表可以看到，控制器已经下发了队列调整流表项。
端口1的速率变化：
端口2的速率变化：
从图中我们可以看到，最初阶段，端口1和端口2的速率均在2M左右；从时间17:13:18开始，也就是实施队列调整应用后，端口1的速率上升到了大于2M阶段，而端口2的速率下降到了500k以下。
三、实验总结
流量监控是软件定义网络SDN中很重要的一环，在获取各个接口的实时信息后，可以实现很多的服务，如负载均衡、QoS、流量工程等。这也是初次尝试sFlow，还有很多不足的地方，我的想法是，做好sFlow与控制器的交互，完善流量监控的功能，为以后的各种服务提供帮助。
