Hi all, I think I looked in all the regular places and inferred that reporting issues might best be done here. The gitlab issue tracker shows no issues.
The problem I have seen is where BIRD BGP is running a passive process. The initiator peer is running the product at https://metallb.universe.tf <https://metallb.universe.tf/>. This product can only initiate sessions. Due to (what I assume) is a bug in the product, it was able to initiate a session from a TCP socket source address that was not matched to the router ID. More specifically, both BGP processes were running on the same host, with MetalLB configured to take a router ID that was a secondary (internal / private) interface and and BIRD using the primary interface address (so as to be able to connect to other external peers). I believe the BIRD team would be interested in this because when BIRD BGP accepted a connection with the same source address as it’s own Router ID, even though the session provided a different router ID, it caused BIRD the BIRD RIB and kernel exports to show the source of the route to be a completely different BGP peer. In this case, the different peer was the default route of a stub area, so incoming traffic to these addresses formed a routing loop. It’s unclear to me whether this is a bug or a feature. If it is indeed a feature or unavoidable side effect that needs to be supported all the same, what would have been desirable is if there was at least some log message of the form “this is probably not what you want” when a peer connected in this manner. More information can be found at https://github.com/danderson/metallb/issues/422 <https://github.com/danderson/metallb/issues/422> and the referenced PR. I’m happy to help reproduce the problem if needed. Thanks for a great product!! best, Brian
