基于组表的故障恢复
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