OpenDayLight Helium实验三 OpenDaylight二层转发机制实验 2

鉴于在个人笔记本上虚拟机运行ODL实在太慢，把实验的场景搬到了实验室。

实验上：OpenDayLight Helium实验三 OpenDaylight二层转发机制实验

抓包实验

紧接着，在运行Mininet的虚拟机上，执行命令pingall，回到ODL的图形化web界面，查看拓扑图：

在OpenDaylight的Web页面查看Troubleshoot选项卡，查看当前两台交换机上已经下发的流表。

由于版本是氦版本的，和实验介绍的版本有出入，所以部分内容不一致。

在nodes里面查看流表：

流表1：

流表2：

nodes中的另外一个选项：table

执行以下命令查看当前两个交换机上的流表内容:

ovs-ofctl dump-flows s1
ovs-ofctl dump-flows s2

s1:

s2:

查看链路信息：

openflow1：

openflow2：

在OpenDayLight中查看采用默认网关配置

实验分析(摘自原文)

下面结合抓包文件过滤openflow_v1 && (arp || icmp)来分析基于OpenDaylight的二层转发机制，流程图如下：

1.源主机h1（10.0.0.1）发出ARP请求h3（10.0.0.3）的MAC，交换机SW1并不知道如何转发该包，因此将其通过Packet In消息发送到Controller处理。

2.Controller收到ARP请求后，会要求每一台SW所对应10.0.0.0/8网段的非SW互联端口（只有这些端口是连接主机或传统网络的）发出ARP来请求10.0.0.2的MAC地址。这里Controller并不是简单的将收到ARP原封不动的发出，而是将源IP改为默认网关IP地址，然后发出。

3.只有h3（10.0.0.3）才会响应ARP，它将ARP Response发送到SW2。SW2也不知道如何处理，因此将ARP封装在Packet In中发送到Controller。

4.Controller发现这是ARP响应，并且正是之前10.0.0.1发送的ARP请求，因此它会将该ARP通过OF协议发到SW1，同时指示SW1将其送出的端口（也就是h1对应的端口）。SW1执行该操作。

5.Controller在收到h3的ARP后也得知了10.0.0.3的位置，它根据网络拓扑计算，可以得到全网到达10.0.0.3和10.0.0.1的转发路径，并将流表通过OF Flow Modify消息推送到每一台交换机上。

6.h1收到ARP Response后完成ARP解析过程，然后它构造ICMP PING Request数据包，其中源和目MAC分别为h1和h3的MAC，源和目IP分别为h1和h3的IP。由于SW1和SW2都已经成功的装载了到h3(10.0.0.3)的流表，因此该数据包将被顺利发送到h3。

7.h3收到该ICMP PING Request，源是h1，但是此时它尚未有h1的MAC，于是还要进行一次ARP解析，SW2再次将ARP请求封装成Packet In消息发送Controller。

8.Controller已经得知h1的MAC，可直接响应，并通过OF向SW2返回ARP结果和所需要送出的端口（h2接入的端口）。

9.h3学到ARP后，即可构造ICMP Response包，发送到SW2，SW2根据h1目的地址匹配转发表将其转发到SW1，SW1根据h1目的地址匹配转发表将其发送到h1对应的端口。h1到h3的双向通道至此完全打通。

2016/9/29