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

[Tobias Heister]

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