<div dir="ltr">Hi Donald,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br><br><br>Best regards,</div><div>Anton</div><div><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 12 Dec 2018 at 17:30, Donald Sharp <<a href="mailto:sharpd@cumulusnetworks.com" target="_blank">sharpd@cumulusnetworks.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Anton -<br>
<br>
Recently you had e23b9ef6d2 committed into FRR.  During subsuquent<br>
testing it was noticed that this change broke various forms of<br>
route-leaking.  In order to preserve current functionality, we have<br>
backed this commit out.  My apologies for not catching these issues<br>
earlier on initial submission.  In the meantime, we've added new tests<br>
to the topotests to catch this problem from happening in the future(<br>
see tests/topotests/ bgp-vrf-route-leak-basic and bgp_l3vpn_to_bgp_vrf<br>
).<br>
<br>
Lou and I believe that your initial approach was probably the right<br>
thing to do but it needs to not break existing functionality.  What<br>
was the use case you were needing this change for?<br>
<br>
donald<br>
</blockquote></div></div></div>