Hi Donald, Yes, Renato had contacted me about this as well. Thank you for adding the needed tests. I will redo my tests in the lab I had prepared for a customer use case. The fix I had submitted was needed for locally defined subnets in a VRF which needed to be leaked into L3VPN. The issue I had observed was that they weren't -- because zebra thought that these subnets were not reachable. My theory (which worked for me and the customer) was that zebra was treating these prefixes wrong what, I thought, the patch corrected. Apologies for a high-level response -- I do not remember all details as this was a month ago. I will recreate the design I was testing again with the recent FRR master code and will give the new topotests a try as well. Best regards, Anton On Wed, 12 Dec 2018 at 17:30, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Anton -
Recently you had e23b9ef6d2 committed into FRR. During subsuquent testing it was noticed that this change broke various forms of route-leaking. In order to preserve current functionality, we have backed this commit out. My apologies for not catching these issues earlier on initial submission. In the meantime, we've added new tests to the topotests to catch this problem from happening in the future( see tests/topotests/ bgp-vrf-route-leak-basic and bgp_l3vpn_to_bgp_vrf ).
Lou and I believe that your initial approach was probably the right thing to do but it needs to not break existing functionality. What was the use case you were needing this change for?
donald