[dev] bgpd/bgp_mplsvpn.c change
Anton Degtyarev
adeg47 at gmail.com
Wed Dec 12 10:02:41 EST 2018
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>
More information about the dev
mailing list