On Tue, Mar 24, 2026 at 10:01:18PM +0000, Tomáš Matuš via Bird-users wrote:
Hello BIRDs! Hello Ondra.
In my lab I have an all-active multihomed host to PE1 and PE2, BIRD is there as a PE3. I noticed that when both PE1 and PE2 announce a Type 2 route for the multihomed MAC (b8:69:f4:e0:4e:04) BIRD only uses one and does not fallback to the other when the first is withdrawn. I understand that this is starting to touch unsupported EVPN parts and BIRD doesn't do much with Type 1 and Type 4 routes apart of adding them to the evpn table, but it should at least handle multiple Type 2 routes for the same MAC.
...
Once one link from the LAG goes down and one of PE1 or PE2 withdraws its routes (does not matter which one) BIRD then receives withdraw for Type 2 route with MAC b8:69:f4:e0:4e:04 and removes it from ethernet table and from the bridge fdb without checking if any other route is still available in the evpntab to replace it with. As a result the traffic is flooded.
I am somewhat convinced that this is partially caused by the channel being RA_ANY rather than RA_OPTIMAL for the non-BUM entries and because multiple routes are not considered in the BIRD eth table.
I'm curious to hear your opinion how you feel about having multiple routes for same MAC in the eth bridge protocol. Would it be cleaner to do this between EVPN table and the eth table rather than eth table and kernel?
Hello Thank you for the bugreport. Thinking about it there are in fact two problems: 1) Using RA_ANY instead of RA_OPTIMAL for non-BUM entries without distinguishing them by different rte_src after translation to eth table. 2) Translation of EVPN network type to ethernet network type leads to different EVPN nets being translated to one eth net. That would be problem even if RA_OPTIMAL were used. Both leads to inconsistencies when EVPN route A appears, EVPN route B appears, overrides translated ether route, and then disappears. I think a solution would have to be something similar of your patch. I would prefer to do that between EVPN table and eth table, but that would work only for issue 1 and not for issue 2. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) "To err is human -- to blame it on a computer is even more so."