[j-nsp] rib-groups && VPN reflection

[Johannes Resch]

On Thu, 18 Apr 2019 at 14:25, Tobias Heister <lists at 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