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
6 matches
Mail list logo
