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