On Thu, 18 Apr 2019 at 14:25, Tobias Heister <[email protected]> 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
