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

[Mihai Tanasescu]

reminds me of the time we also tested it...

On April 18, 2019 17:35:45 Johannes Resch <jr at xor.at> wrote:

> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp