Hi, Sorry for delay. I reproduced the situation. The cause may be that the disconnection is incomplete when the speaker is being shutdown while the connection is existing.
Let me investigate this problem. In the meantime, please delete all peers before shutting down. Thanks, Fujimoto On 2018年03月14日 00:58, Jens Harbott wrote:
These issues were found while I was testing the neutron-dynamic-routing service in OpenStack, see https://bugs.launchpad.net/neutron/+bug/1750383 and https://bugs.launchpad.net/neutron/+bug/1750129 But using a modified version of the sample program shown at http://ryu.readthedocs.io/en/latest/library_bgp_speaker.html I can reproduce them with only ryu: ---<--->---<--->---snip---<--->---<--->---snap---<--->---<--->--- import eventlet # BGPSpeaker needs sockets patched eventlet.monkey_patch() # initialize a log handler # this is not strictly necessary but useful if you get messages like: # No handlers could be found for logger "ryu.lib.hub" import logging import sys log = logging.getLogger() log.addHandler(logging.StreamHandler(sys.stderr)) from ryu.services.protocols.bgp.bgpspeaker import BGPSpeaker def dump_remote_best_path_change(event): print ('the best path changed:', event.remote_as, event.prefix,\ event.nexthop, event.is_withdraw) def detect_peer_down(remote_ip, remote_as): print ('Peer down:', remote_ip, remote_as) if __name__ == "__main__": speaker = BGPSpeaker(as_number=65001, router_id='10.0.0.1', bgp_server_port=0, best_path_change_handler=dump_remote_best_path_change, peer_down_handler=detect_peer_down) speaker.neighbor_add('10.42.0.4', 65001) print ("BGP started") count = 1 while True: eventlet.sleep(10) prefix = '10.20.' + str(count) + '.0/24' print ("add a new prefix", prefix) speaker.prefix_add(prefix) count += 1 if count == 3: break # eventlet.sleep(10) # print ("Remove neighbor") # speaker.neighbor_del('10.42.0.4') eventlet.sleep(10) print ("Shutting down") speaker.shutdown() eventlet.sleep(300) ---<--->---<--->---snip---<--->---<--->---snap---<--->---<--->--- The result differs depending on whether there is actually a BGP peer listening at the remote end, leading to the scenarios described in the two bugs above. When the BGP session is connected at the time of the shutdown, these tracebacks are being shown repeatedly: hub: uncaught exception: Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 80, in _launch return func(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/utils/evtlet.py", line 63, in __call__ self._funct(*self._args, **self._kwargs) File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py", line 542, in _expired self.send_notification(code, subcode) File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py", line 374, in send_notification self._send_with_lock(notification) File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py", line 386, in _send_with_lock self.connection_lost('failed to write to socket') File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py", line 596, in connection_lost self._peer.connection_lost(reason) File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/peer.py", line 2328, in connection_lost self._protocol.stop() File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py", line 405, in stop Activity.stop(self) File "/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/base.py", line 314, in stop raise ActivityException(desc='Cannot call stop when activity is ' ActivityException: 100.1 - Cannot call stop when activity is not started or has been stopped already. When the BGP session is not connected, there is no error, but using tcpdump one can see connection attempts continuing after the shutdown. As a workaround, removing all neighbors works, if I do that (currently commented in the sample code), both issues disappear. I do think however that ryu should be doing this automatically. Fixes welcome. ;) ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel