[j-nsp] JunOS RPKI/ROA database in non-default routing instance, but require an eBGP import policy in inet.0 (default:default LI:RI) to reference it.
Saku Ytti
saku at ytti.fi
Mon Jun 5 03:46:37 EDT 2023
I totally agree this should work, and it is unfortunate that you are
struggling to make it work.
Having said that, it is asking for trouble managing your devices in a
VRF, you will continue to find issues and spend time/money working
with vendors to solve those.
It is safer to put the service (internet) in VRF, and leave the main
table for signalling and NMS, if you want to create this distinction.
It will also make it a lot more convenient to leak between instances
and create subInternets, like peeringInternet, to avoid peers from
default routing to you.
https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp_origin_validation.html
NOTE: RPKI validation is available only in the primary instance. If
you configure RPKI validation for a routing instance, then the RPKI
validation fails with the following error message RV instance is not
running.
I consider it a design error that NOS conceptually has two types of
instances, main instance and VRF instance. This distinction makes it
more expensive to write and maintain the NOS and it makes it more
fragile.
General principle applies, do boring things, get boring results. Same
reason why IPv6 continues to be 2nd class citizen and is a bad
candidate for your NMS/signalling AFI, people don't use it, so if you
do, you will be responsible for driving vendors to fix it. Time which
you likely should be spending doing something else.
On Mon, 5 Jun 2023 at 06:52, Chris Kawchuk via juniper-nsp
<juniper-nsp at puck.nether.net> wrote:
>
> Great idea!.... but no dice. :( didn't work.
>
> Seems the whole "VRF -> back to base table" operations that we'd all love to do easily in JunOS rears its ugly head yet again ;)
>
> FWIW - Some friends in the industry *do* use that knob, but they're "going the other way". i.e. The RPKI RV Database is in inet.0 && Internet is in a VRF. Apparently that does work AOK for them; however it's "fiddly" as you say.
>
> FWIW - here's the VRF's config... pretty darned basic.
>
> routing-instances {
> admin {
> routing-options {
> validation {
> notification-rib [ inet.0 inet6.0 ]; ## << No impact on the default:default LI:RI RV database
> group routinator {
> session 10.x.x.x {
> refresh-time 120;
> port 3323;
> }
> }
> }
> }
> description "Dummy admin vrf - to test RPKI inside a routing-instance";
> instance-type vrf;
> interface xe-0/0/3.0; ## << the RPKI server is setting on the other end of this /30
> vrf-target target:xxxx:xxx;
> }
> }
>
> FWIW using a vMX for testing - running JunOS 20.4R3-S4.8.
>
> Basically i'm asking "is there a way to do this without having to stick the validator DB config into the basec onfig [routing-options validation {}] stanza?
>
> .....If it must, then yeah, it's easy enough to do a rib group, a static /32 next-table/no-readvertise/no-install, lt-x/x/x stitch, route leak, etc...to get the default:default instance to "use the VRF" to reach the RPKI server. I just don't want to go down that road (yet) if I don't have to; as the 'technical elegance' (read: OCD) portion of my brain wants to avoid that if it can.
>
> - CK.
>
>
>
>
> > On Jun 5, 2023, at 13:12, David Sinn <dsinn at dsinn.com> wrote:
> >
> > I'd try the 'notification-rib' chunk in the 'validation' stanza of the routing-instance and see if setting inet.0 there pushes the DB the way you need. Certain versions of JunOS are quite broken going the other way, so I've had to enumerate all of the routing-instances that I want to be sure have a copy of the validation DB to get them to work correctly. Maybe the other way will work in your case.
> >
> > David
> >
> >> On Jun 4, 2023, at 7:52 PM, Chris Kawchuk via juniper-nsp <juniper-nsp at puck.nether.net> wrote:
> >>
> >> Hi All
> >>
> >> Been scratching my head today. As per Juniper's documentation, you can indeed setup RPKI/ROA validation session inside a routing-instance. You can also have it query against that instance on an import policy for that VRF specifically, and if there's no session, it will revert to the default RPKI RV database (if configured) under the main routing-options {} stanza to check for valid/invalid, etc...
> >>
> >> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp_origin_validation.html
> >>
> >> Thats all fine and dandy, but it seems that JNPR's implementation of RPKI/ROA *assumes* that your RV database is always configured in the main routing instance (i.e. the main routing-options validation {} stanza, thus your RPKI server MUST be available via inet.0 ).
> >>
> >> Unfortunately, the situation I am faced with is the opposite.
> >>
> >> My RPKI/ROA server is only available via our "admin" VRF (which is how we manage the device) - Our inet.0 contains the global internet/IGP and links and loopbacks/Labels/etc. all "admin" related functions RADIUS/TACACS, SNMP, RPKI, Syslog, ssh, you-name-it, etc. are all "nailed" to our admin VRF. Hence when I try to do ROA validation of an eBGP peer in inet.0 via a standard import policy, the RV "validation-database" is unfortunately locked inside the admin-vrf, and thus isn't queried for valid/invalid/unknown etc.
> >>
> >> Hence, nothing on the eBGP session in inet.0 is being validated.
> >>
> >> Is there some KNOB I'm missing, to allow a policy, executed upon routes in inet.0, to use the RV database in a non-default VRF? Or copy the VRF's RV to the default's RV? or is this some oversight of JNPR's RPKI implementation, that it must be inside the default:default LI:RI?
> >>
> >> - CK.
> >>
> >>
> >> NOTE: my Google-fu and/or "set ?" skills aren't yielding any useful results. Apologies if there's "a simple fix" for this, or an example of this situation I haven't found.
> >> _______________________________________________
> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
--
++ytti
More information about the juniper-nsp
mailing list