Hi, Thanks for the mail. You can report bugs to https://bugs.launchpad.net/neutron/ , as I see you are right with the return value, as I see the method _is_looped_path_attrs called only from [1]. If you can push a patch for this that would be the best of course, but if it is not possible just open the bug please and perhaps reference this mail also ([2]) Best wishes Lajos Katona (lajoskatona) [1]: https://opendev.org/openstack/os-ken/src/branch/master/os_ken/services/proto... [2]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... <anas.jouhdy@gmail.com> ezt írta (időpont: 2025. jún. 27., P, 15:23):

Hi,

As it is my first message here, do not hesitate to tell me if something is wrong with the ticket ! I think there is a bug in this file https://opendev.org/openstack/os-ken/src/branch/master/os_ken/services/proto... on the method "_is_looped_path_attrs" on line 1655. In the case we found a loop, we should return True instead of None.

For example in my case, I have an Openstack BGP speaker that advertise correctly the reachable subnets in Openstack. The external peer (Cumulus switch in my case) re-advertise the IP prefix of the subnets to my Openstack BGP speaker when it learns them. This rightfully raise an error in the log thanks to this method "_is_looped_path_attrs" telling that the update coming from the external peer will be ignored as the local AS was found in the AS Path but after that, the debug log implies that the path was still added to the potential path that can reach the subnet. This then become an issue when we detach our subnet from the router, because only the local path will be removed and the route will not be withdrawn (because the new best path will be the "false" route learned back from Cumulus)

Do not hesitate to ask for precision !