Hi Brian, Can you give specific examples of what is happening? Configuration samples, show running route information from cli, etc.
On Sat, Apr 6, 2019 at 9:19 PM Brian Topping <[email protected]> wrote: > > 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. 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 and the referenced PR. > > I’m happy to help reproduce the problem if needed. > > Thanks for a great product!! > > best, Brian
