[dev] bgpd/bgp_mplsvpn.c change

[Anton Degtyarev]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20181212/7d7cceb5/attachment.html>