用于迷你网络配置的Ryu控制器

Question

我在研究一个小型网络的环形拓扑。在三角形配置中，有三个接入点: ap1、ap2和ap3相互连接。有一个站点(sta1)不是移动的(总是连接到ap3)，还有一个移动站(sta2)，它在ap1和ap2之间随机移动。范围是从sta2到ping sta1。我用了一个storm控制器来避免广播风暴。它不能很好地工作，因为例如，当sta2连接到ap1时，我可以ping它，但是当它移动到ap2时，我就不能再点击它了。我该如何解决这个问题？我附上我的ryu代码：

    <---sta2--->
  ap1---------ap2
   -           -
    -        - 
      - ap3 -
        sta1

from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_3
from ryu.lib import dpid as dpid_lib
from ryu.lib import stplib
from ryu.lib.packet import packet
from ryu.lib.packet import ethernet
from ryu.app import simple_switch_13


class SimpleSwitch13(simple_switch_13.SimpleSwitch13):
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]
    _CONTEXTS = {'stplib': stplib.Stp}

    def __init__(self, *args, **kwargs):
        super(SimpleSwitch13, self).__init__(*args, **kwargs)
        self.mac_to_port = {}
        self.stp = kwargs['stplib']

        # Sample of stplib config.
        #  please refer to stplib.Stp.set_config() for details.
        config = {dpid_lib.str_to_dpid('0000000000000001'):
                  {'bridge': {'priority': 0x8000}},
                  dpid_lib.str_to_dpid('0000000000000002'):
                  {'bridge': {'priority': 0x9000}},
                  dpid_lib.str_to_dpid('0000000000000003'):
                  {'bridge': {'priority': 0xa000}}}
        self.stp.set_config(config)

    def delete_flow(self, datapath):
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        for dst in self.mac_to_port[datapath.id].keys():
            match = parser.OFPMatch(eth_dst=dst)
            mod = parser.OFPFlowMod(
                datapath, command=ofproto.OFPFC_DELETE,
                out_port=ofproto.OFPP_ANY, out_group=ofproto.OFPG_ANY,
                priority=1, match=match)
            datapath.send_msg(mod)

    @set_ev_cls(stplib.EventPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):
        msg = ev.msg
        datapath = msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser
        in_port = msg.match['in_port']

        pkt = packet.Packet(msg.data)
        eth = pkt.get_protocols(ethernet.ethernet)[0]

        dst = eth.dst
        src = eth.src

        dpid = datapath.id
        self.mac_to_port.setdefault(dpid, {})

        self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)

        # learn a mac address to avoid FLOOD next time.
        self.mac_to_port[dpid][src] = in_port

        if dst in self.mac_to_port[dpid]:
            out_port = self.mac_to_port[dpid][dst]
        else:
            out_port = ofproto.OFPP_FLOOD

        actions = [parser.OFPActionOutput(out_port)]

        # install a flow to avoid packet_in next time
        if out_port != ofproto.OFPP_FLOOD:
            match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
            self.add_flow(datapath, 1, match, actions)

        data = None
        if msg.buffer_id == ofproto.OFP_NO_BUFFER:
            data = msg.data

        out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
                                  in_port=in_port, actions=actions, data=data)
        datapath.send_msg(out)

    @set_ev_cls(stplib.EventTopologyChange, MAIN_DISPATCHER)
    def _topology_change_handler(self, ev):
        dp = ev.dp
        dpid_str = dpid_lib.dpid_to_str(dp.id)
        msg = 'Receive topology change event. Flush MAC table.'
        self.logger.debug("[dpid=%s] %s", dpid_str, msg)

        if dp.id in self.mac_to_port:
            self.delete_flow(dp)
            del self.mac_to_port[dp.id]

    @set_ev_cls(stplib.EventPortStateChange, MAIN_DISPATCHER)
    def _port_state_change_handler(self, ev):
        dpid_str = dpid_lib.dpid_to_str(ev.dp.id)
        of_state = {stplib.PORT_STATE_DISABLE: 'DISABLE',
                    stplib.PORT_STATE_BLOCK: 'BLOCK',
                    stplib.PORT_STATE_LISTEN: 'LISTEN',
                    stplib.PORT_STATE_LEARN: 'LEARN',
                    stplib.PORT_STATE_FORWARD: 'FORWARD'}
        self.logger.debug("[dpid=%s][port=%d] state=%s",
                          dpid_str, ev.port_no, of_state[ev.port_state])

Answer 1

我认为是什么引起了这个问题

我认为，sta2最初能够ping sta1的原因是因为OpenFlow开关中的流表是空的。当sta2调用sta1时，控制器将流添加到OVSSwitch中，从而在流表中创建一个流条目。

由于流表中的这一项，由于位置已知并设置了一条路线，这两个站能够互相平接。一旦站点迁移到ap2，就不会创建新的流条目并将其附加到流表。为什么？因为控制器认为流表中的流条目是准确的，因此不需要再次查询网络中的路径。

验证这一索赔的一种方法

这可以通过使用小型控制台提供的dpctl功能来验证。下面我使用的是稍微不同的网络架构，但我的理论仍然有效。

sta5从ap3迁移到ap1

在这种情况下，sta5最初出现在ap3中，我们可以选择sta3，当sta5仍然与‘ap3’相关联时，它在ap2中处于初始的移动状态。

sta5 pings sta3

运行dpctl dump-flows允许我们看到流是在初始ping完成后添加的。

dpctl转储流响应

现在，一旦sta5迁移到ap1，您就会注意到ping失败了，流也没有被改变，从而证明了我在上面的陈述。

sta5已迁移到ap1，并未能ping sta3。

可能的解决办法

为了缓解这个问题，有几种方法，

1. 通过它和dpctl del-flows，正在迁移的车站你的特别方式。
2. 开发一个脚本，以便在站离开AP范围后分离流。
3. 当交换机进入新的AP范围时，开发一个脚本来分离站的流。

我意识到这是一个相当晚的反应，但希望它能帮助那些最终面对这个问题的人。