reminds me of the time we also tested it...
On April 18, 2019 17:35:45 Johannes Resch <j...@xor.at> wrote:
On Thu, 18 Apr 2019 at 14:25, Tobias Heister <li...@tobias-heister.de>
wrote:
Hi,
On 18.04.2019 10:13, Adam Chappell wrote:
But the abstraction seems to be incomplete. The method of copying routes
to
bgp.l3vpn.0 is similar if not identical, under-the-hood, to the initial
rib-group operation I am performing at route source to leak the original
inet.0 route and this route, as seen in the VRF.inet.0 table, becomes a
Secondary route.
As such, it apparently isn't candidate for further cloning/copying into
bgp.l3vpn.0, and as a consequence the "leaked" route doesn't actually
make
it into the VPN tables of other PEs.
Yes, L3VPN under the hood is more or less rib-groups in disguise. There is
actually a command i forgot which shows you the internal rib-groups it uses
to do the L3VPN magic.
My question to others is, is this a well-known man-trap that I am naively
unaware of? Is it simply the case that best practice to get reflection
off
of production VRF-hosting PEs is actually mandatory here, or are others
surprised by this apparent feature clash? Can I reasonably expect it to
be
addressed further down the software road? Or is there another, perhaps
better, way of achieving my objective?
This behavior is probably deeply rooted in the architecture, so i would
not expect it to change.
I faced the same issue when building a DDoS Mitigation ON/OFF Ramp setup.
My workaround was to bring up an lt-interface and run a routing protocol
between VRF and inet.0 announcing all the routes you need.
As i did not want to the actual traffic to forward over that lt interfaces
(and stealing BW from the PFE) i created a policy to change the next-hop to
a specific dummy next-hop IP.
That dummy-next-hop IP used next-table XYZ and pointed directly into the
table i wanted. Once the routes are learned and resolved the Forwarding
table points directly into the other VRF/Table and i could not see any
problems in terms of performance or similiar with this.
FWIW, I've also built a quite similar solution for this use case.
Best regards,
Johannes
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
