Re: [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.

[Mark Tinka via juniper-nsp]

On 6/6/23 09:27, Saku Ytti wrote:


I am not implying it is pragmatic or possible, just correct from a
design point of view.

Commercial software deals with competing requirements, and these
requirements are not constructive towards producing maintainable clean
code. Over time commercial software becomes illiquid with its
technical debt.

There is no real personal reward for paying technical debt, because
almost invariably it takes a lot of time, brings no new revenue and
non-coder observing your work only sees the outages the debt repayment
caused. While another person who creates this debt creating new
invoiceable features and bug fixes in ra[pb]id manner is a star to the
non-coder observers.

Not to say our open source networking is always great either, Linux
developers are notorious about not asking SMEs 'how has this problem
been solved in other software'. There are plenty of anecdotes to
choose from, but I'll give one.

- In 3.6 kernel, FIB was introduced to replace flow-cache, of course
anyone dealing with networking could have told kernel developers day1
why flow-cache was a poor idea, and what FIB is, how it is done, and
why it is a better idea.
- In 3.6 FIB implementation, ECMP was solved by essentially randomly
choosing 1 option of many, per-packet. Again they could have asked
even junior network engineers 'how does ECMP work, how should it be
done, I'm thinking of doing like this, why do you think they've not
done this in other software?' But they didn't.
- in 4.4 Random ECMP was changed to do hashed ECMP

I still continue to catch discussions about poor TCP performance on
Linux ECMP environment, then I first ask what kernel do you have, then
I explain to them why per-packet + cubic will never ever perform. So
for 4 years ECMP was completely broke, and reading ECMP release notes
in 4.4 not even developers had completely understood just how bad the
problem one, so we can safely assume people were not running ECMP.

Another example was when I tried to explain to the OpenSSH mailing
list, that ''TOS' isn't a thing, and got a confident reply that TOS
absolutely is a thing, prec/DSCP are not. Luckily a few years later
Job fixed OpenSSH packet classification.

But these examples are everywhere, so it seems you either choose
software written by people who understand the problem but are forced
to write unmaintainable code, or you choose software by people who are
just now learning about the problem and then solve it without
discovering prior art, usually wrong.


I think being able to write code is one thing. Being able to write code 
to build and run an IP/MPLS network is - not a-whole-other - but another 
thing. I say this because people that know how to write code do not 
always understand how IP/MPLS networks work. And for better or worse, we 
need code to run the routers and switches that deliver IP/MPLS 
capability to network operators.


The reason traditional networking OEM's build usable code that allows us 
to run IP/MPLS networks is that their raison d'être is, well, shifting 
packets around the world as quickly as possible. General-purpose OS 
developers optimize for service/app performance, leaving the problem of 
network performance to the networking folk, for the most part. So it 
does not surprise me that developers who code for a general-purpose OS 
would think RIP is better than IS-IS, for example, just because it has 
the word "Routing" in it and they can write code for it. It's not 
because they don't know how to write code for IS-IS... they just don't 
have the organizational structure setup to care about why IS-IS is a 
better idea than RIP. Their organization setup is app, app, app.


Unfortunately, not everybody can be a Cisco, Juniper, Google or AWS, who 
have the benefit of plenty of people that can more easily integrate 
writing code for its down sake with writing code for networking.


It is the reason most large scale network operators will still continue 
to find value in IOS XR, Junos, EOS, ArcOS, e.t.c., than, say, a NOS 
that was put together by someone that knows how to interpret an RFC and 
spit out an implementation on Linux, with zero understanding of the 
overall TCP/UDP/IP/MPLS/Ethernet stack and how it all ties in together 
at scale.


I like what folk like pfSense (Netgate) are doing with FRR, and also 
what folk like Mikrotik can pack in 13MB of software... but at a certain 
scale, you simply can't ignore traditional networking OEM, try as we might.


Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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 via juniper-nsp]

On Tue, 6 Jun 2023 at 06:54, Mark Tinka via juniper-nsp
 wrote:

> > While I have a lot of sympathy for Saku's pragmatism, I prefer to file off 
> > the ugly edges of old justifications when I can... but it's done one commit 
> > at a time.
>>
> Going back to re-do the implementation from scratch would be a
> non-starter. There is simply too much water under this bridge.

I am not implying it is pragmatic or possible, just correct from a
design point of view.

Commercial software deals with competing requirements, and these
requirements are not constructive towards producing maintainable clean
code. Over time commercial software becomes illiquid with its
technical debt.

There is no real personal reward for paying technical debt, because
almost invariably it takes a lot of time, brings no new revenue and
non-coder observing your work only sees the outages the debt repayment
caused. While another person who creates this debt creating new
invoiceable features and bug fixes in ra[pb]id manner is a star to the
non-coder observers.

Not to say our open source networking is always great either, Linux
developers are notorious about not asking SMEs 'how has this problem
been solved in other software'. There are plenty of anecdotes to
choose from, but I'll give one.

- In 3.6 kernel, FIB was introduced to replace flow-cache, of course
anyone dealing with networking could have told kernel developers day1
why flow-cache was a poor idea, and what FIB is, how it is done, and
why it is a better idea.
- In 3.6 FIB implementation, ECMP was solved by essentially randomly
choosing 1 option of many, per-packet. Again they could have asked
even junior network engineers 'how does ECMP work, how should it be
done, I'm thinking of doing like this, why do you think they've not
done this in other software?' But they didn't.
- in 4.4 Random ECMP was changed to do hashed ECMP

I still continue to catch discussions about poor TCP performance on
Linux ECMP environment, then I first ask what kernel do you have, then
I explain to them why per-packet + cubic will never ever perform. So
for 4 years ECMP was completely broke, and reading ECMP release notes
in 4.4 not even developers had completely understood just how bad the
problem one, so we can safely assume people were not running ECMP.

Another example was when I tried to explain to the OpenSSH mailing
list, that ''TOS' isn't a thing, and got a confident reply that TOS
absolutely is a thing, prec/DSCP are not. Luckily a few years later
Job fixed OpenSSH packet classification.

But these examples are everywhere, so it seems you either choose
software written by people who understand the problem but are forced
to write unmaintainable code, or you choose software by people who are
just now learning about the problem and then solve it without
discovering prior art, usually wrong.


-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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.

[Mark Tinka via juniper-nsp]

On 6/5/23 23:26, Jeff Haas via juniper-nsp wrote:


[Note that I've already inquired internally about the original problem.  I 
don't recall the answer from top of head and don't have time for code 
spelunking...]

As to the point below, we get to these headaches one commit at a time.  Junos 
is long-lived enough that VRFs started as a hack on a system that didn't have 
them.  A completely new system written from scratch likely would just assume 
arbitrary tables that can be spaghetti configured into whatever you want to do 
with them.

When I was first studying the Juniper implementation of L3VPN VRFs, some of the 
rib-group constructs didn’t make a lot of sense to me.  It was rather clearer 
after discovering that when the features were released in the 9.x (?) releases 
that all of the niceties we have today used to be completely done at a manual 
level with those same rib-groups. __

While I have a lot of sympathy for Saku's pragmatism, I prefer to file off the 
ugly edges of old justifications when I can... but it's done one commit at a 
time.


I think Junos' VRF implementation is so far down the line, it makes more 
sense to just carry on with the architecture and add knobs, support and 
fixes as issues are either discovered or as customers ask for them. As 
you say, "One commit at a time".


Going back to re-do the implementation from scratch would be a 
non-starter. There is simply too much water under this bridge.


It is not unlike all the stuff you get in IOS (and IOS XE) after so many 
years of assuming so many things in the 90's and early 2000's, not least 
of which that IP is not the only protocol routers will ever run. It is 
so hard for Cisco to remove or re-do those assumptions. At some point, 
you just have to accept that picking up an OS-specific book that 
eloquently describes its eccentricities is part of the process of 
raising a network engineer.


Newer OS's like EOS, ArcOS have a cleaner, simpler and more sensible 
approach to this sort of thing because they are benefiting from all the 
good things IOS/IOS XE/IOS XR and Junos have done in the past 25+ years, 
while dropping all the bad things those OS's have also done. Where the 
older OS's still display their strength is in their maturity, especially 
of routing protocols.


In the end, pick your poison, buy the book, and be happy.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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.

[Jeff Haas via juniper-nsp]

[Note that I've already inquired internally about the original problem.  I 
don't recall the answer from top of head and don't have time for code 
spelunking...]

As to the point below, we get to these headaches one commit at a time.  Junos 
is long-lived enough that VRFs started as a hack on a system that didn't have 
them.  A completely new system written from scratch likely would just assume 
arbitrary tables that can be spaghetti configured into whatever you want to do 
with them.

When I was first studying the Juniper implementation of L3VPN VRFs, some of the 
rib-group constructs didn’t make a lot of sense to me.  It was rather clearer 
after discovering that when the features were released in the 9.x (?) releases 
that all of the niceties we have today used to be completely done at a manual 
level with those same rib-groups. __

While I have a lot of sympathy for Saku's pragmatism, I prefer to file off the 
ugly edges of old justifications when I can... but it's done one commit at a 
time.

-- Jeff



On 6/5/23, 3:47 AM, "juniper-nsp on behalf of Saku Ytti via juniper-nsp" 
mailto:juniper-nsp-boun...@puck.nether.net> on behalf of 
juniper-nsp@puck.nether.net > wrote:
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.


Juniper Business Use Only
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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 via juniper-nsp]

On Mon, 5 Jun 2023 at 11:13, Lukas Tribus via juniper-nsp
 wrote:

> in Cisco land I worked around VRF or source interface selection
> limitations for RTR by using SSH as a transport method, which then
> used SSH client source-vrf/source-interface configurations.
>
> I don't know if JunOS supports SSH transported RTR though.

It is immaterial, it wouldn't work.

If someone would actually need to make it work, they'd leak between
VRF/Internet, so that RTR configured on the Internet actually goes via
the NMS VRF. This could be accomplished in a multitude of poor ways.
Egress could be next-table static route, ingress could be firewall
filter with from source-address rtr then routing-instance default. Or
it could be LT between VRF and default instance.


-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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.

[Lukas Tribus via juniper-nsp]

Hello,

in Cisco land I worked around VRF or source interface selection
limitations for RTR by using SSH as a transport method, which then
used SSH client source-vrf/source-interface configurations.

I don't know if JunOS supports SSH transported RTR though.


Lukas

On Mon, 5 Jun 2023 at 04:52, Chris Kawchuk via juniper-nsp
 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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.

[Mark Tinka via juniper-nsp]

On 6/5/23 09:46, Saku Ytti via juniper-nsp wrote:


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.


I'm still in awe of operators who run their Internet and/or core network 
inside a VRF :-).


In all my years in the game, that is the one thing I have never been 
brave about. I find it cheaper and simpler to just separate functions 
with physical hardware.




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.


I can see reasons for and against it, but no doubt, it does add 
complexity into the code base, even though it may "simplify" network 
operations to have the distinction.


Cisco's approach is less onerous, with simply applying the VRF wherever 
it is needed inside the global configuration. I'd imagine that is 
simpler to code for, and operationally, it is reasonably simple as well.




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.


I, most likely, do not speak for the majority when I say we are a 
dual-stack house and signal both on IPv4 and IPv6 for just about 
everything... SSH, TACACS+, RADIUS, SNMP, NTP, ROV, DNS, Syslog, LDP, 
Netflow, e.t.c. I do remember a time when vendors did not have parity 
for this, but that was, at worst, 9 years ago.


It does take some effort to have signaling parity between IPv4 and IPv6, 
and I think that is the biggest hurdle for network operators... that 
boring is so good, it's a mission thinking about bringing some 
excitement into your life :-). It has been easier for us because we got 
the chance to greenfield our network revamp 11 years ago, so we got 
dual-stack done at the same time. I can see a complication where 
longstanding deployments are very IPv4-centric, that going back to work 
IPv6 natively in is insurmountable.


DNSSEC, RPKI, DMARC, DANE and DKIM suffer from the same inattention as IPv6.

Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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 via juniper-nsp]

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
 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::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  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 
> >>  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 

Re: [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.

[Chris Kawchuk via juniper-nsp]

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

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [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.

[David Sinn via juniper-nsp]

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

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[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.

[Chris Kawchuk via juniper-nsp]

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