环境准备
环境
- ubuntu16.04
- mininet
- pox
- scapy
安装mininet
- sudo apt-get update
- sudo apt-get upgrade
- git clone git://github.com/mininet/mininet
- mininet/util/install.sh -a
- 进入路径mininet/util
- -a：安装mininet所有功能
- 输入以下命令进行测试sudo mn --test pingall
安装pox
由于使用了mininet安装时添加了参数-a，所以在安装了mininet的同时，也安装了许多其他的软件，其中就包括了pox
使用pox
启动pox控制器
- python pox.py -address=127.0.0.1 -port=6633 samples.pretty_log forwarding.l2_learning py
- -address：设置控制器ip地址
- -port：设置控制器端口
- samples.pretty_log：pox的组件，美化控制台字体
- forwarding.l2_learning：pox的组件，负责二层转发，可以让openflow交换机变成一个具有二层转发学习的交换机
- py：进入python的交互式界面，可以继续对pox控制器进行控制器
使用mininet连接pox控制器
- 新开一个命令行，输入sudo mn --custom topo.py --topo topo --controller=remote,ip=127.0.0.1,port=6633 --mac
- 输入后，在启动pox的命令行，会看到提示有新的交换机connect
测试演示
0.topo
我们部署一台交换机s0，三台主机连接到该交换机
1.修改交换机的流表数量为100，来模拟模拟交换机内存不足的情况
- sudo ovs-vsctl add bridge s0 flow_tables 1=@nam1 -- --id=@nam1 create flow_table flow_limit=100：该命令会给交换机s0设置流表0上限为100条（一台交换机有多个流表）
- sudo ovs-vsctl list bridge：查看交换机的设置情况
- sudo ovs-ofctl dump-flows s0：查看交换机的流表
- sudo ovs-vsctl list flow_table：查看流表的设置
2.使用scapy发送大量的流量（二层），促使控制器不断的install新的流表
- 我们发送udp的数据包，只需要修改源端口，就会触发pox给交换机下方新的流表
- 将h2作为接收端，运行接收脚本，统计实际接收的数据包数量，和发送的数据包数量对比
import socket
address = ('10.0.0.2', 8080)
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(address)
i = 1
while True:
data, addr = s.recvfrom(2048)
print "i:", i, "received:", data, "from", addr
i = i + 1
s.close()
- 将h1作为发送端，不断发送只有源端口修改的数据包
from scapy.all import *
for i in range(100, 1100):
print('now:', i)
pkt = Ether(src='00:00:00:00:00:01', dst='00:00:00:00:00:02')/IP(src='10.0.0.1', dst='10.0.0.2')/UDP(sport=i, dport=8080)/str(i)
sendp(pkt, iface='h1-eth0')
3.运行结果
我们在设置流表上限最多为100条的情况下，可以看到在发送数据包个数大于100时，出现了数据包的丢包，同时在pox控制器端也出现了下发流表的报错
由于pox模块forwarding.l2_learning下发的流表带有hard_time字段，当数据包超过100后，新的数据包到来后，被交换机上报到控制器，但是在控制器下发流表回交换机的环节，因为流表达到上限，而旧的流表还没有过期，导致了无法install新的流表，数据包没有办法被处理，进而出现了丢包
4.结论
在实际场景，交换机的流表数量远远大于100，出现流表溢出的情况的可能性较低，但是可以看出，如果能有办法达到这个临界值的话，是可以造成交换机正常工作的。
其实只是要说明这个以上结论，只要将流表上限设为1，那么pingall命令都将会无法ping通，就已经足够说明危害了，但是该思路存在进一步改进的地方，毕竟去发送这么大的流量去溢出流表，似乎有点大材小用了，应该尝试去试着用小流量就可以造成流表操作的异常，当然，这也就和题目的dos不相干了。并且该危害也只影响到了交换机，对控制器没有影响，也不够威力
改进的方向
- 继续朝着dos的方向，利用交换机的reactive模式下，会将数据包完整的上发给控制器，而不仅仅只是header，通常控制链路（交换机与控制器之间的链路）会比数据链路的数据容量小，那么就存在了可能性去利用这一点来影响控制器，又或者控制器连接处理的能力有限，使一台交换机不断的进行请求访问，让控制器没有剩余的能力去处理其他正常交换机的请求，来影响控制器服务
- 针对交换机对flow_table的操作，不同的交换机实现不同，有的模块可能使用硬件，有的使用软件，有的交换机匹配流表的操作是使用软件，并且基于hash表的方式实现，来达到O（1）的性能，但是hash表是存在hash碰撞的可能性，如果人为的去制造这个碰撞，使得所有流表都是一样的hash值，那么查找和添加流表的性能就会远远低于O（1），进而影响处理交换机处理数据包的性能