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
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
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
[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
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
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,
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
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
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
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
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
11 matches
Mail list logo
