The scenario can be described as follow:
link up
send 5 lldp packet
send 6th lldp packet
link down
then go to link up, on and on
Then I found the reason, it is in topology/swithes.py
768 if port_data.lldp_dropped() > self.LINK_LLDP_DROP:
769 deleted.append(link)
I think that is to say, the port have sent LINK_LLDP_DROP lldp packets
LINK_LLDP_DROP = 5
I found port_data.sent is increased when lldp packet is sent, and is set to
0 when lldp_received is called.
lldp_received is called once, at
682 if not self.links.update_link(src, dst):
# reverse link is not detected yet.
# So schedule the check early because it's very likely it's
up
try:
self.ports.lldp_received(dst)
except KeyError as e:
# There are races between EventOFPPacketIn and
# EventDPPortAdd. So packet-in event can happend before
# port add event. In that case key error can happend.
# LOG.debug('lldp_received: KeyError %s', e)
pass
else:
self.ports.move_front(dst)
self.lldp_event.set()
As comment descriped, port_data.sent is set zero when reverse link is not
detected, and schedule check early.
So why not set port_data.sent to 0 when reverse link is detected?
I make the change, set port_data to 0 whatever reverse link is detected.
And link up and down on and on is disappeared.
But I run into another problem
Link up is slow.
When the ports at both link side is up, it take about 5~10 seconds to
generate a link up event.
So, what's problem I have met?
Thank you
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
