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