SDN第6次上机作业

基于组表的故障恢复

fast failover:执行第一个live的Action Bucket,每一个Action Bucket都关联了一个指定的port或者group来控制它的存活状态。Buckets会依照Group顺序依次被评估,并且第一个关联了一个live的port或者group的Action Bucket会被筛选出来。这种Group类型能够自行改变Switch的转发行为而不用事先请求Remote Controller。如果当前没有Buckets是live的,那么数据包就被丢弃,因此这种Group必须要实现一个管理存活状态的机制。

搭建拓扑并连接控制器

from mininet.topo import Topo

class MyTopo( Topo ):

    def __init__( self ):

        # initilaize topology
        Topo.__init__( self )

        # add hosts and switches
        host1 = self.addHost( ‘h1‘ )
        host2 = self.addHost( ‘h2‘ )
        switch1 = self.addSwitch( ‘s1‘ )
        switch2 = self.addSwitch( ‘s2‘ )
        switch3 = self.addSwitch( ‘s3‘ )
        switch4 = self.addSwitch( ‘s4‘ )

        # add links
        self.addLink(host1,switch1)
        self.addLink(switch1,switch2)
        self.addLink(switch1,switch3)
        self.addLink(switch2,switch4)
        self.addLink(switch3,switch4)
        self.addLink(switch4,host2)

topos = { ‘mytopo‘: ( lambda: MyTopo() ) }

连接控制器

···

mn --custom topo1.py --topo mytopo --controller=remote,ip=127.0.0.1,port=6633

···

Pingall并查看S2,S3的流表

在mininet进行pingall操作验证连通性,同时新建终端通过sudo ovs-ofctl dump-flows s2 –O OpenFlow13查看s2流表以及s3流表。

可以发现s2的所在链路是通的。而s3的数据包被drop

在S1上下发组表

ODL组表入口:opendaylight-inventory->config->nodes->node->group

ff 是组表类型

在S1中下发流表使组表生效

下发组表至S4(同S1)

按照下发组表到s1的方法下发组表至s4,这是为了让数据回来的时候能够自动切换到s3所在链路,而不是继续往s2所在链路上发送,同样需要再发一条流表使它生效

在S3上下发流表

在s3上下发两条流表覆盖drop动作,port1进入转发至port2,port2进入转发至port1

在S4上下发流表

在s4上下发流表使s3所在链路进入的数据包转发至h2所在端口

进行ping操作

在mininet上进行h1 ping h2操作,通过sudo ovs-ofctl dump-group-stats s1 -O OPenFlow13查看流表匹配状态,可以看到只有bucket0 生效,即所有数据包都通过s2所在路径传输

第一次h1 ping h2

将s2所在链路的端口set down

通过命令将s1的2端口关闭,s4的1端口关闭。目的是为了s1和s4上的组表生效

sudo ovs-ofctl -O OpenFlow13 mod-port s1 2 down
sudo ovs-ofctl -O OpenFlow13 mod-port s4 1 down

第二次h1 ping h2

进行h1 ping h2操作,通过sudo ovs-ofctl dump-group-stats s4 -O OPenFlow13查看组表状态,可以看到另一个bucket的匹配数据有增长,证明另一条链路启用

原文地址:https://www.cnblogs.com/linzhenyuyuchen/p/8185076.html

时间: 2024-11-01 23:15:23

SDN第6次上机作业的相关文章

SDN第四次上机作业

SDN第四次上机作业 实验目的 1.使用图形化界面搭建拓扑如下并连接控制器 2.使用python脚本搭建拓扑如下并通过命令行连接控制器 3.使用任一种方法搭建拓扑连接控制器后下发流表 实验步骤 1.建立以下拓扑,并连接上ODL控制器. 2.利用ODL下发流表,使得h3在10s内ping不通h1,10s后恢复. 3.借助Postman通过ODL的北向接口下发流表,再利用ODL北向接口查看已下发的流表.

SDN第五次上机作业

SDN第五次上机作业 实验目的 1.搭建如下拓扑并连接控制器 2.下发相关流表和组表实现负载均衡 3.抓包分析验证负载均衡 实验步骤 1.建立以下拓扑,并连接上ODL控制器. 原文地址:https://www.cnblogs.com/ZHOULR/p/8127854.html

SDN第4次上机作业

作业链接 1.建立以下拓扑,并连接上ODL控制器 2.利用ODL下发流表,使得h3在10s内ping不通h1,10s后恢复 3.借助Postman通过ODL的北向接口下发流表,再利用ODL北向接口查看已下发的流表 -下发流表 -查看流表

SDN第五次上机作业--基于组表的简单负载均衡

0.作业链接 http://www.cnblogs.com/easteast/p/8125383.html 1.实验目的 1.搭建如下拓扑并连接控制器 2.下发相关流表和组表实现负载均衡 3.抓包分析验证负载均衡 2.实验步骤 1.建立以下拓扑,并连接上ODL控制器. tupo 对应端口信息 2.利用ODL下发组表.流表,实现简易负载均衡(提交要求:利用sudo ovs-ofctl dump-flows br0 -O OpenFlow13及 sudo ovs-ofctl dump-groups

SDN第三次上机作业

实验目的 在给定如上实验拓扑情况下,用vlan得到下列虚拟网段 h1--h4互通 h2--h5互通 h3--h6互通 其余主机间无法通信 创建以下拓扑(可采用任意方式) 利用OVS命令下发流表,实现VLAN功能 参考链接:http://blog.csdn.net/rocson001/article/details/73163041 实战截图 利用OVS命令查看流表 参考链接:http://blog.csdn.net/rocson001/article/details/73163041 实战截图

SDN第四次上机作业(忘记提交了。。)

1.建立以下拓扑,并连接上ODL控制器. 2.利用ODL下发流表,使得h3在10s内ping不通h1,10s后恢复. 3.借助Postman通过ODL的北向接口下发流表,再利用ODL北向接口查看已下发的流表. 原文地址:https://www.cnblogs.com/ComeAndGetSome/p/8111650.html

SDN 第五次上机作业

1.搭建如下拓扑并连接控制器 2.下发相关流表和组表实现负载均衡 s1: s2: s3: s4: 3.抓包分析验证负载均衡 s4-eth1: *s4-eth2: s4-eth3 原文地址:https://www.cnblogs.com/deepYY/p/8125670.html

SDN第六次上机作业

实验目的 1.搭建如下拓扑并连接控制器 2.下发相关流表和组表实现链路的故障恢复 实验步骤 1.建立以下拓扑,并连接上ODL控制器. ODL拓扑界面截图: 2.利用ODL下发组表.流表,实现链路的故障恢复 利用sudo ovs-ofctl dump-flows s2(s3) -O OpenFlow13查看s2和s3的流表的截图: 对s1和s4下发组表后,再下发流表使组表生效,之后通过sudo ovs-ofctl dump-groups s1(s4) -O OpenFlow13查看s1和s4的组表

17秋 SDN课程 第二次上机作业

1.控制器floodlight所示可视化图形拓扑的截图,及主机拓扑连通性检测截图 拓扑 连通性 2.利用字符界面下发流表,使得'h1'和'h2' ping 不通 流表截图 连通性 3.利用字符界面下发流表,通过测试'h1'和'h3'的联通性,来验证openflow的hardtime机制 初始连通性 下发具有hardtime的流表 测试结果 原文地址:https://www.cnblogs.com/qq952693358/p/8313500.html