寻找关于使用RYU进行swithc断开检测的一些照明 - 最后看到更新...

我正在使用Northbound Networks的ZodiacFX交换机，RYU作为MACbook中的控制器运行 . 我已经完成了这个实验，在Pycharm下直接从命令行运行RYU，具有相同的效果 .

我也使用具有类似结果的linux桌面完成了这项工作，尽管没有那么多 .

我有OFPStateChange，DPSet和OFPSwitchFeatures的事件处理程序（简化如下）

@set_ev_cls(ofp_event.OFPEventStateChange, [MAIN_DISPATCHER, DEAD_DISPATCHER])
def state_change_handler(self,ev):
    if ev.state == MAIN_DISPATCHER:
        print 'registering datapath ....'
    elif ev.state == DEAD_DISPATCHER:
        print 'unregistering datapath ....'

@set_ev_cls(dpset.EventDP, [MAIN_DISPATCHER, DEAD_DISPATCHER])
def _switch_state_handler(self, ev):
    if ev.enter:
        print 'connect detected ...'
    else:
        print 'disconnect detected ...;

@set_ev_cls(ofp_event.OFPEventSwitchFeatures, [MAIN_DISPATCHER, DEAD_DISPATCHER])
def switch_features_handler(self,ev):
    # (prints out the datapath info ...)

# ...

我还在一个线程中运行一个定时器循环，使用hub.spawn（）每隔10秒发送一次echo请求，控制器有一个回复处理程序来处理它们 .

当我连接交换机（插入以太网电缆）时，会在几秒钟内检测到它，首先是switch_features_handler（），然后触发state_change_handler（）和_switch_state_handler（），显示预期的信息 .

如果我断开交换机，我的计时器线程会检测并报告没有回复回复（以10秒为间隔重复），但实际的带有ev.enter的EventDP不会出现一段时间 . 那段时间似乎从大约1分钟到5分钟或更长 .

这种时间不一致让我有点疯狂 . 有人可以向我解释RYU内部检测交换机断开的机制吗？任何理由时机到处都是？

所以这是另一个提示 . 我做了第一次将ZodiacFX直接连接到控制器主机（MACbook）以太网的实验 . 后来我还在Zodiac和MACBook之间放了一个（非开放式）开关，在Zodiac和中间开关之间进行物理开关连接/断开，保持中间开关连接到MACbook . 结果是相同的，向我表明断开检测与MACbook以太网连接上的任何硬件载波侦听无关（因为中间交换机保持连接），但RYU控制器本身内部有些东西 .

我很欣赏任何见解，也许还有一些关于如何在RYU中处理这些信息的信息（其他一切都失败了我会在时间允许的情况下深入研究代码）TIA Carl

更新 - 更多信息 - 当我插入开关并且首次检测到它时，它实际上连续两次循环通过各种处理程序 . 我发现这是因为交换机和主机正在重新协商连接速度，并且两个速度设置之间存在断开连接 . 这表明可以快速断开连接 - 但是是否受主机上以太网驱动程序的控制？ “慢速”断开检测是否可能不受该驱动程序中超时计时器的控制？如果是这样，为什么时间变化？

sdn openflow ryu