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

[adamv0025 at netconsultings.com]

> Adam Chappell
> Sent: Thursday, April 18, 2019 9:13 AM
> 
> Hello all.
> 
> I figure this topic is a fundamental and probably frequently
asked/answered
> although it's new problem space for me. I thought I'd consult the font of
> knowledge here to seek any advice.
> 
> Environment: MX, JUNOS 15.1F6
> Headline requirement: Leak EBGP routes from global inet.0 into a VPN (in
> order to implement off-ramp/on-ramp for DDoS protection traffic
> conditioning).
> 
> Experience:
> The challenge is quite simple on the surface. Use a rib-group directive on
the
> EBGP peer to group together inet.0 and the VRF.inet.0 together as import-
> rib/Adj-Rib-In for the peer. Indeed this works as you would expect, and
> received routes appear in both inet.0 and VRF.inet.0
> 
> But the problem is that if rpd is also configured with any of:
> - IBGP reflection for inetvpn family
> - EBGP for inetvpn
> - advertise-from-main-vpn-table,
> 
> then any leaked routes, while being present in the VRF, do not get
> advertised internally to other PE VPN routing tables.
> 
> The cause seems to be that these features cause the mechanics of
> advertising VPN routes internally to change.  These features bring in a
> requirement for rpd to retain VPN routes in their "native" inet-vpn form,
> rather than simply consult the origin routing-instsances and synthesise on
> demand so that the interaction with reflection clients or EBGP peers can
be
> handled.
> 
> So when these features are enabled, rpd opportunistically switches to a
> mode where it goes to the trouble of cloning the instance-based vanilla
> routes as inetvpn within bgp.l3vpn.0 or equiv.
> 
> Indeed battle-scarred Juniper engineers are probably familiar with this
> document that offers counsel for how to maintain uptime in the face of
this
> optimisation gear-shift:
> https://www.juniper.net/documentation/en_US/junos/topics/example/bg
> p-vpn-session-flap-prevention.html
> 
> I can understand and appreciate this, even if I might not like it.
> 
> 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.
> 
> The document suggests a workaround of maintaining the original route in
> inet.0, but sadly for my use case, the whole premise of the leak operation
is
> to ultimately result in a global table inet.0 redirect elsewhere, so
depending
> on inet.0 route selection is a bit fragile for this.
> 
> 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?
> 
> Any thoughts appreciated.
> 
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