这是基于RYU+Mininet的SDN架构设计仿真校园网络的第四部分
总体详见：【基本中型网络的仿真（RYU+Mininet的SDN架构）-以校园为例】
上一章：【RYU+Mininet的SDN架构-设计校园网络（一）】【RYU+Mininet的SDN架构-设计校园网络（三）】
https://blog.csdn.net/weixin_53284122/article/details/129393512?spm=1001.2014.3001.5502
五、设计验证与结果分析
5.1 SDN的验证和结果分析
（1）操作验证分析
图5-1 RYU控制器运行simple_switch_13.py程序
从图5-2中可以看到已经连接到控制器C0，控制器C1还未连接到的原因是控制器C1还没有运行防火墙程序（后续会讲到）。
图5-2 拓扑对于远程控制器的反应
（2）实验验证
后续防火墙技术，STP，OSPF，DHCP的成功也可以验证SDN。
5.2 OSPF的验证与结果分析
（1）路由表项对比分析
在主机通过dhcp分配到ip后，ospf协议开始运行，以路由器R3的路由表为例，网络收敛前的表项：
图5-3 R3未收敛时的路由表项展示图
经过约40s后，路由完全收敛，再次查看R3的路由表：
图5-4 R3收敛后的路由表项展示图
（2）抓包分析
用wireshark抓包后，我们发现有大量的ospf的hello报文
图5-5ospf运行时报文展示
（3）网路ping测试
从下图中可以看到，在路由收敛前，只有在同一子网中的主机可以ping通，跨子网的主机ping不通。
图5-6 路由收敛前的pingall情况
当路由收敛后，不同子网下的主机也能ping通（不通的为防火墙规则）
图5-7 路由收敛后的pingall情况
5.3 STP的验证与结果分析
（1）流表分析
运行ryu和拓扑代码后，开始运行stp
图5-8 stp运行时产生的流表输出
经过约40s后，s链路收敛，流表输出中告知s3的port2被关闭；
图5-9 R3链路收敛后的展示图
（2）抓包分析
用wireshark抓包后，我们发现有大量的广播的stp报文
图5-10 stp运行时报文展示
（3）网路ping测试
从下图中可以看到，stp协议运行成功
图5-11 stp收敛后的pingall情况
（4）异常情况测试
我们考虑stp的初衷是，增强链路的健壮性，设置冗余链路。这也要求当正常链路出现故障（断开）后，网络也能保持联通。 所以我们以断开s2与s3的链路为例：
图5-12 断开s2与 s3的链路
我们发现，链路断开后，网络发生了变化，立刻有stp的流表输出，说明网络正在计算新的拓扑。
图5-13链路变化后的流表输出
等stp重新收敛后，进行pingall测试，结果与链路变化前一致，达到了设计目的：
图5-14链路变化后的pinall情况
5.4 DHCP的验证与结果分析（其中例子）
（1）实验效果
在地址池设定如下的情况下：
图5-15 地址池设定
实验结果如下
图5-16 实验过程图示
（2）结果分析
截获到如图所示的报文：
图5-17 截获报文总览
对Discover报文进行分析：
图5-18 Discover报文总览
由图可知广播地址为255.255.255.255，Src为0.0.0.0（设定需要DHCP服务主机的初始IP）。
对offer报文进行分析:
图5-19 offer报文总览
Src为192.168.2.3即设定的该子网内的DHCP服务器的IP地址，此时目的IP为255.255.255.255即进行广播，其中附带了所分配的IP地址为192.168.2.20。
对Request报文进行分析:
图5-20 Request报文总览
此时Src仍为0.0.0.0，发送方式为广播。
对ACK报文进行分析:
图5-21 ACK报文总览
此时可以看到Src为192.168.2.3，重复了Your (client) IP address:192.168.2.20。
至此，整个DHCP服务运行完成。
5.5 NAT的验证与结果分析
（1）内网ping外网连通性测试
同时使用网络中的h1和h2ping外网，最终的连通性如下：
图5-22 ping外网验证图
可以看到h1和h2都是可以成功ping通外网的。
（2）NAPT测试
之后我们再通过windows上的抓包可以验证h1和h2在ping外网时使用的是同一个IP地址。
图5-23 ping外网wireshark抓包图
上图中可以看到h1和h2都在使用192.168.137.136这一个地址ping外网。证明我们实现了NAPT功能。
（3）Linux虚拟机ping内部主机
我们在linux虚拟机中ping h1的IP地址，其结果如下：
图5-24 ping内网验证图
同时我们在wireshark的抓包中也能抓到相应的报文：
图5-25 ping内网wireshark抓包图
5.6防火墙的验证与结果分析
（1）网络连通性测试
在整个网络进行pingall测试，发现只有H1(应用环境中的教师主机)可以访问服务器H7和H8，其余的主机和路由器是不能访问服务器的，符合我们的预期的效果和设置的规则。
图5-26 防火墙pingall测试结果展示图
（2）流表分析
从交换机S4的流表中可以看出设置的四条规则的操作时正常的，说明：防火墙是默认阻塞所有的报文，我们设置可以通过的IP流向的报文以此来达到防火墙目的。当然，同时我们也可以设置默认所有的报文都可以通过，设置不可以通过报文的规则。由于应用场景的需求，我们采用了第一种方案。
图5-27交换机S4的流表展示
（3）控制器终端分析
从下图中可以看到，控制器终端C1的返回结果，相应的规则已经被加入到防火墙中。
图5-28 控制器C1终端防火墙规则设置返回结果
从控制终端的流表中也可以看到，被阻塞的报文如下。只要是我们在防火墙程序中没有设置的规则，都会被防火墙程序阻塞，无法通过交换机S4。
图5-29 控制器C1的流表
5.7 WLAN的验证与结果分析
（1）网络连通性测试
由于pingall命令产生了非常多行结果，这里只展示部分截图。pingall可以很直观地看出WLAN内部的连通性没有问题。
图5-30 WLAN中使用pingall命令测试结果的部分截图
（2）后台扫描结果演示
为了更清晰地演示后台扫描过程与结果，此处只保留sta1一个站点，并且我们改变了ap3的位置，使得sta1与站点间的距离关系更加直观。
①如图，sta1最初距离ap1最近。根据最强信号优先原则，sta1应该关联ap1。
图5-31 后台扫描实验使用的网络拓扑
②验证：sta1确实关联ap1，黄框内为ap1的MAC地址。
图5-32 后台扫描实验中设备关联最初情况
③打开sta1命令行，观察sta1后台扫描过程。
图5-33 后台扫描实验中打开sta1的终端
④改变sta1的物理位置。
图5-34 后台扫描实验中改变sta1的位置
⑤sta1后台扫描发现ap2。
图5-35 后台扫描实验中sta1发现ap2
⑥能够看到实际上sta1与接入点的关联确实发生了变化。
图5-36 后台扫描实验中设备关联最终情况
（3）结果分析：
通过上面的实验可以得到结论：通过配置后台扫描参数，终端能够在连接到某一个AP后仍然以某一个时间周期进行扫描，并且主动连接到与当前AP的SSID相同且信号最强的AP。这说明我们配置的终端能够实现ESS内的漫游