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.
The setup is running in production for a couple of years now. It is a bit ugly and
violates the "4am Rule" where any on Call Engineer woken at 4am should
immediately understand what is going on, but well it is what it is ;)
--
Kind Regards
Tobias Heister
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
