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, <[email protected]> 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. _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
