OpenDaylight OpenvSwitch ping实验

在本机安装odl和ovs，本来想安装mininet，结果由于centos 6的版本安装真心麻烦到吐，各种软件依赖，依赖完还是失败T_T。自己用ovs+namespace模拟mininet主机。安装完的主机和交换机的拓扑：
ovs_mininet

首先启动odl hydron版本
执行脚本：

#!/bin/bash 

#input $1 = controller ip, $2 = controller port
if [[ $# -ne 2 ]]  
then  
    echo "parameter illegal"
    exit 1
fi

#del bridge
allbr=`ovs-vsctl --timeout=1 list-br`  
for i in $allbr  
do  
    ovs-vsctl del-br $i
done

ovs-vsctl add-br brx  
ovs-vsctl add-br bry

#add peer-port
ovs-vsctl add-port brx vportx_y  
ovs-vsctl add-port bry vporty_x

ovs-vsctl set interface vportx_y type=patch  
ovs-vsctl set interface vportx_y option:peer=vporty_x

ovs-vsctl set interface vporty_x type=patch  
ovs-vsctl set interface vporty_x option:peer=vportx_y

#set controller
ovs-vsctl set-controller brx tcp:$1:$2  
ovs-vsctl set-controller bry tcp:$1:$2

#add host
ip netns add netx  
ip netns add nety

#add port to netx
ovs-vsctl add-port brx vportx_host -- set interface vportx_host type=internal  
ip link set vportx_host netns netx 

#add port to nety
ovs-vsctl add-port bry vporty_host -- set interface vporty_host type=internal  
ip link set vporty_host netns nety

#show
ovs-vsctl show

#add vport ip
ip netns exec netx ifconfig vportx_host 10.0.0.1/24  
ip netns exec nety ifconfig vporty_host 10.0.0.2/24

首先hostx ping hosty：ip netns exec netx ping 10.0.0.2。结果不通，因为这个ovs交换机没有设置l2自动学习，所以不会转发，但这个时候查看odl的图会发现从10.0.0.1到brx连接了一条边。
从hosty ping hostx：ip netns exec nety ping 10.0.0.1:

PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.  
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=13.2 ms  
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.281 ms  
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.035 ms  
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.040 ms

done!

注意：

关闭控制器一段时间后，发现还是可以ping通。其原因如下：
(1) 控制器断掉后，交换机进入紧急模式，重置所有的tcp连接。此时，所有分组将匹配指定　的紧急模式表项，所有正常表项将被删除。
(2) 此时交换机变成普通交换机，对收到的包查看是否有匹配，没有则将首先进行洪泛，若有转发记录，则根据转发记录转发。
(3) ovs-ofctl dump-flows brx发现没有流表项。因为此时的交换机是普通交换机，所以没有openflow流表项。
使用命令行添加的流表项可以在控制界面中显示，反之控制界面中添加的流表会下放，也可以在命令行中获取。
用10.0.0.2 ping 10.0.0.1的时候发现，每过一段时间都会突然ping不通了，过一会又通了。查看流表发现，是因为10.0.0.2到10.0.0.1方向的流表丢失了，但是反方向还存在。如果是因为流表过期的话，为什么反方向的流表还会存在？重启又好了，应该是控制器不稳定。

重新使用mininet，两台主机，wireshark进行实验，分析一下抓包过程。同样配置，抓到的wireshark如下：

其中66:69为h1的mac address，10.0.0.1为h1的ip地址。同理，7e:c3是和10.0.0.2是h2的mac和ip地址。

209　h1发送arp探测h2的arp地址。ovs交换机发送of_packet_in告知controller。
211 controller下发of_packet_out告知可以广播。
212 controller下发of_packet_out给ca:74这个mac地址，告知其代为进行arp。但是我没搜到这个mac地址，个人认为是包括s1和s2两个交换机的地址，此处应该为s1。不知道具体是怎么对应的。
213 ca:74对应另外一个交换机s2，告知其进行arp。
216 7e:c3也就是h2收到arp包，发回icmp包给交换机s2。此消息为packet_in，因为没有之前流表匹配信息。
218 controller下发流表给s2，填充关于h1主机的流表信息：如果包的dst是10.0.0.1，则转发port 2口。port 2恰好对应s2-s1的口。
216 of_barrier_request。barrier信息，controller下发该消息确保已经被交换机执行完毕，就像一个屏障一样。
221 对218的packet_in发回允许信息，告知s2执行。
223 交换机s2对barrier回复。
224 controller下发流表给s1，填充关于h1主机的流表信息：如果包的dst是10.0.0.1，则转发对应的mac地址，比如：00:00:00:00:01。该mac地址恰好为h1的出口网卡链路地址。
225　controller继续下发of_barrier_request信息给s1。
228 交换机s1对barrier回复。
229 已经探知h2的链路地址，h1开始发ping包给h2。该消息为packet-in。
231 对上一条的ping包产生packet-out消息。
232 h2链路地址发回icmp包，但此时由于h2并不知道h1的mac地址，同样需要发广播包探知h1主机的mac地址。此消息为packet-in
233 上一条的packet-out。
234 由于已经缓存66:69的信息，controller下发packet-out消息告知66:69发回arp包给7e:c3。
235 controller发流表添加信息给s2，告知添加流表：如果包的dst是10.0.0.2，则转发对应对应的mac地址。
236 of_barrier_request
238 of_barrier_reply
239 controller发流表添加信息给s1，告知添加流表：如果包的dst是10.0.0.2，则转发port 2，恰为s1-s2。
239 of_barrier_request
240 of_barrier_reply

说明：

装载请注明出处：http://vinllen.com/opendaylight-ovs-pingshi-yan/

Your browser is out-of-date!

Vinllen Chen

OpenDaylight OpenvSwitch ping实验

注意：

说明：

Discussions