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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp