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

[Adam Chappell]

I think you've got it clear, Adam. Take routes that are originally destined
for inet.0, create a rib-group in order to leak them into a secondary
routing instance, and then expect normal L3VPN behaviour for those
route-instance routes. (The idea is to drop the routes into an overlay
topology, which includes a multi-homed network element, with an interface
and BGP relationship to inet.0 in order to influence it and "override"
based on original route properties.).

Yes, of course, loops are possible, but this is perfectly possible, and
policed by all the usual routing protocol mechanisms, IFF the route table
advertisement mode is non-reflector mode (meaning that routes are exported
directly from the VRFs and not from the bgp.l3vpn.0 holding table).

It's this change in functionality and behaviour based on other features
that disappoints me most here. KB32423 describes the situation, I've since
found, and it advises me to off the reflection. Off-box reflection, for
VPN, is probably the best idea anyway, but it's a shame that it isn't
clearer in the feature documentation that this road has serious pitfalls.

I do understand your point on using RTs to determine remote PE table
destination. But there's no easy way to take undecorated inet.0 routes and
annotate with RTs, is there?  Even if there was, I have to assume that the
original route in inet.0 can/will be displaced. That was actually the very
nice thing about rib-groups: the two copies of the route do not share any
route selection fate.

Appreciate the feedback from all. Haven't quite given up yet.

-- Adam.

On Sun, 21 Apr 2019 at 11:22, <adamv0025 at netconsultings.com> wrote:

>
> I'm not sure I understand your objective, so just to confirm.
> Is your objective to leak route from routing table A to routing table B
> while being able to advertise the leaked route from table B to other PEs
> (where the route is expected to land in table B).
> If that's the case then this is not allowed as it can form routing loops.
> Instead one is expected to set the RTs on export from table A so that other
> PEs can import these in the desired table.
> This is where the use of inet.0 is troublesome -so in that case one is
> expected to do the route leaking on all remote ends.
> But you can see the pattern here, advertising is done from the originating
> table and then the "leaking" is supposed to be done on/by the remote end.
>
> adam
>
>
>
>

-- 

-- Adam.