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