Re: [j-nsp] Junos EVO RE Filters

On Wed, 19 Jun 2024 at 20:35, heasley wrote: > And enemy of security is lack of effort? Current BMCs would be > a step backward, imiho. I wish they were better; a lot of > potential.. What is the benchmark? Is benchmark NOS fate-sharing control-plane ethernet? Or RS232? How do they outperform

Re: [j-nsp] Junos EVO RE Filters

Wed, Jun 19, 2024 at 08:58:01AM +0300, Saku Ytti: > To me none of the above matters. I don't care how insecure the BMC is. > I just want a true OOB port that works when my router does not work. I > want an OOB port that won't break my router, when my OOB LAN has a > broadcast storm or some other un

Re: [j-nsp] Junos EVO RE Filters

On Tue, 18 Jun 2024 at 21:23, heasley wrote: > Yes, do that, please, but that does not really address the security > problems. BMCs typically are not updated by their owners, s/w updates > for them are rarely offered by the vendor, usually have limited filtering > & security capabilities, and ar

Re: [j-nsp] Junos EVO RE Filters

Tue, Jun 18, 2024 at 07:20:12PM +0300, Saku Ytti via juniper-nsp: > If you must use MGMT ETH, keep asking your vendors for true lights out > ethernet, with its own CPU, DRAM and storage. Yes, do that, please, but that does not really address the security problems. BMCs typically are not updated b

Re: [j-nsp] Junos EVO RE Filters

Can always count on you. Thanks. On Tue, Jun 18, 2024 at 12:20 PM Saku Ytti wrote: > On Tue, 18 Jun 2024 at 18:56, Jason Iannone via juniper-nsp > wrote: > > > I suppose the root question is do I have to apply a management filter on > my > > transit interfaces for in-band management traffic? Do

Re: [j-nsp] Junos EVO RE Filters

On Tue, 18 Jun 2024 at 18:56, Jason Iannone via juniper-nsp wrote: > I suppose the root question is do I have to apply a management filter on my > transit interfaces for in-band management traffic? Does ACX have a new (not > fxp1) relationship between the RE and the external re0:mgmt-0/em0/fxp0 i

[j-nsp] Junos EVO RE Filters

Hi all, I'm working on an ACX multiservice PE test plan and can't quite parse the difference between network control loopback filter for RE and the management filters. The EVO Overview says, "firewall filters applied to the loopback interface apply only to network control traffic. You must explici

Re: [j-nsp] JunOS forwarding IPv6 packets with link-local source

Hi On Fri 17. May 2024 at 13.05, Daniel Verlouw wrote: > Hi, > > On Thu, May 16, 2024 at 8:22 PM Antti Ristimäki via juniper-nsp > wrote: > > I thought this issue had been resolved already years ago, but I > > noticed that JunOS still happily forwards IPv6 packets with link-local > > source add

Re: [j-nsp] JunOS forwarding IPv6 packets with link-local source

Hi, On Thu, May 16, 2024 at 8:22 PM Antti Ristimäki via juniper-nsp wrote: > I thought this issue had been resolved already years ago, but I > noticed that JunOS still happily forwards IPv6 packets with link-local > source address towards remote destinations. This of course violates > RFC4291. Al

Re: [j-nsp] JunOS forwarding IPv6 packets with link-local source

On Fri, 17 May 2024 at 10:36, Antti Ristimäki wrote: > iACL design becomes a bit more challenging if you want to keep the > link-local things link local (e.g. there are legit ND packets with > link-local srcaddr and GUA dstaddr). It is doable, though. Not disagreeing, but what are these packets?

Re: [j-nsp] JunOS forwarding IPv6 packets with link-local source

Hi, On Fri, May 17, 2024 at 9:26 AM Saku Ytti wrote: > > On Thu, 16 May 2024 at 21:23, Antti Ristimäki via juniper-nsp > wrote: > > > Does anyone have any insight into this? This issue was discussed on > > this list already over 10 years ago, for example: > > https://puck.nether.net/pipermail/ju

Re: [j-nsp] JunOS forwarding IPv6 packets with link-local source

On Thu, 16 May 2024 at 21:23, Antti Ristimäki via juniper-nsp wrote: > Does anyone have any insight into this? This issue was discussed on > this list already over 10 years ago, for example: > https://puck.nether.net/pipermail/juniper-nsp/2012-April/023134.html Personally I'm not convinced I'd e

[j-nsp] JunOS forwarding IPv6 packets with link-local source

Hello, I thought this issue had been resolved already years ago, but I noticed that JunOS still happily forwards IPv6 packets with link-local source address towards remote destinations. This of course violates RFC4291. Also recent JunOS releases seem broken, tested with e.g. 21.4 and 23.2. Does a

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory - Resolved

And thank you all that responded to the request to open cases. Easy contributions to make the case, and far fewer meetings to resolve than it could have been. -- Jeff (who made noise, but did no source code commits) On 10/19/23, 12:48 AM, "juniper-nsp on behalf of Chris Kawchuk via juniper-

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory - Resolved

On 10/19/23 06:48, Chris Kawchuk wrote: Indeed. Apologies to all --- I too got an update from JNPR on the "show route" vs "show routing" CLI conflict a few weeks ago in early September -- but forgot to share it here. CASE; 2023-0719-733950 Synopsis: "show route" and "show routing" operati

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory - Resolved

Indeed. Apologies to all --- I too got an update from JNPR on the "show route" vs "show routing" CLI conflict a few weeks ago in early September -- but forgot to share it here. CASE; 2023-0719-733950 Synopsis: "show route" and "show routing" operational mode CLI conflict - JunOS 21+ Root Cau

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

for good news to pass along in the near future. -- Jeff Juniper Business Use Only From: Chris Lee Date: Wednesday, July 26, 2023 at 10:16 PM To: Jeff Haas , "juniper-nsp@puck.nether.net" Subject: Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory... [External Email. Be cautious

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On July 26, 2023 7:15:55 PM PDT, Chris Lee via juniper-nsp wrote: >Hi Jeff, > >Any chance the CLI could make use of repeated presses of the TAB key to >cycle through the completion options ? > >For instance in the newer 21.x release for EX switches I note a >"synchronous-ethernet" option under th

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/19/23 06:22, Mark Tinka wrote: I'm trying with my SE too. Let's stay in touch. Got a ticket opened with JTAC which my SE upstreamed, and it has been linked to an internal PR that was raised on the back of Chris' ticket. So all we can do now is wait. Thanks, all. Mark. ___

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

Hi Jeff, Any chance the CLI could make use of repeated presses of the TAB key to cycle through the completion options ? For instance in the newer 21.x release for EX switches I note a "synchronous-ethernet" option under the show level, and my muscle memory for "show system" was reduced down to "s

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/19/23 02:37, Chris Kawchuk wrote: Hi Jeff I'll open it with my SE here in Australia (Mark Barrett). Will advise once complete. I'm trying with my SE too. Let's stay in touch. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net h

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

Hi Jeff I'll open it with my SE here in Australia (Mark Barrett). Will advise once complete. - CK. > On Jul 19, 2023, at 01:24, Jeff Haas via juniper-nsp > wrote: > > > Juniper Business Use Only > On 7/12/23, 12:11 PM, "Jeff Haas" > wrote: >> On 7/12/23, 11:46 AM

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

Juniper Business Use Only On 7/12/23, 12:11 PM, "Jeff Haas" mailto:jh...@juniper.net>> wrote: > On 7/12/23, 11:46 AM, "Mark Tinka" mailto:m...@tinka.afri> > >ca> wrote: > > Will any of these issues register significantly on Juniper's roadmap of > >

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On Sun, 16 Jul 2023 at 19:47, Tim Franklin via juniper-nsp wrote: > You missed the fun part where you have to explain *again* every few > months to the CISO and their minions why you can't adhere to the > written-by/for-Windows-admins "Patching Policy" that says everything in > the company is up

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 16/07/2023 00:51, C K via juniper-nsp wrote: Indeed. And as you’re alluding to and most probably already know this — yeah most of us end up settling on “some release train” for a while, after we spend 3-4 months testing it thoroughly in the Lab... then spend 18 months getting everything in

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

Indeed. And as you’re alluding to and most probably already know this — yeah most of us end up settling on “some release train” for a while, after we spend 3-4 months testing it thoroughly in the Lab... then spend 18 months getting everything in the network “up to that release”. With hundreds of

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/15/23 20:54, Crist Clark wrote: I find it kind of telling that customers are just getting around to complaining about it two years after it was released. Not at all surprising, but illustrates how slow network operators update cycles can be compared to the pace of development. To the

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

I find it kind of telling that customers are just getting around to complaining about it two years after it was released. Not at all surprising, but illustrates how slow network operators update cycles can be compared to the pace of development. To the Junos developers, this is ancient news, long

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

Hi Mark, 100% agree if it could help. Very annoying. If UX designer touched it, he or she probably never actually worked with Junos. Kind regards, Andrey Mark Tinka via juniper-nsp писал(а) 2023-07-12 04:49: So, this is going to be a very priviledged post, and I have been spending the last se

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/12/23, 11:46 AM, "Mark Tinka" mailto:m...@tinka.afri>ca> wrote: > Will any of these issues register significantly on Juniper's roadmap of > how to make customers happier? Likely unlikely. Cynically, money moves things the best. But these comments don't fall on deaf ears. Occasionally, th

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/12/23 15:45, Jeff Haas wrote: You don't need to tell my fingers that. __ With the infrastructure as it is, the only "solution" is we stop adding things. Good luck with that. The general here is the explosion of keywords. I have about 15 features sitting in my backlog that are small

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/12/23 15:38, Chris Wopat wrote: Another offender in 21. `protocols bgp` doesn't autocomplete as it did since `bgpmcast` was added. me@r-mx304-lab-re1# set protocols bgp? Possible completions: > bgp                  BGP options > bgpmcast             BGP multicast options Yes, that has

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/12/23 15:08, Vladimir Blazhkun wrote: You can probably deny that command using the login class ACL. As I'd mentioned to someone else already, not looking to create custom hacks that would not survive staff movement. While it is an option, it would be one of extreme last resort. Mar

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

You don't need to tell my fingers that. __ With the infrastructure as it is, the only "solution" is we stop adding things. Good luck with that. The general here is the explosion of keywords. I have about 15 features sitting in my backlog that are small things to do to bgp policy. The policy

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

Another offender in 21. `protocols bgp` doesn't autocomplete as it did since `bgpmcast` was added. me@r-mx304-lab-re1# set protocols bgp? Possible completions: > bgp BGP options > bgpmcast BGP multicast options https://www.juniper.net/documentation/us/en/software/jun

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

You can probably deny that command using the login class ACL. -- Vladimir Blazhkun (via iPhone). > On 12 Jul 2023, at 11:49, Mark Tinka via juniper-nsp > wrote: > > So, this is going to be a very priviledged post, and I have been spending > the last several months mulling over even complain

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

On 7/12/23 11:12, Chris Kawchuk wrote: +1 Mark! For transparency, it was Chris who gave me the nudge, so thanks for that, mate :-). As any good problem begs for a solution, my suggestions to JNPR are as follows, as alternative places for this command: "show route transport-class ..."

Re: [j-nsp] Junos 21+ Killing Finger Muscle Memory...

+1 Mark! As any good problem begs for a solution, my suggestions to JNPR are as follows, as alternative places for this command: "show route transport-class ..." (or really, is it even a routing thing? might be better w/the segment-routing or spring commands)i.e.: "show segment-routing ..." "sh

[j-nsp] Junos 21+ Killing Finger Muscle Memory...

So, this is going to be a very priviledged post, and I have been spending the last several months mulling over even complaining about it either on here, or with my SE. But a community friend sent me the exact same annoyance he is having with Junos 21 or later, which has given me a final reason

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.

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 softwar

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.

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 w

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.

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

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.

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

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.

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

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.

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, Ch

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.

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 peeri

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.

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 (in

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.

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

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.

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 hav

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

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 defa

Re: [j-nsp] Junos 20 - slow RPD

I've been down the path of very slow RPD with JTAC recently. In our case it was due to some mildly complex BGP community stuff that we do which was exhausting memory limits. A good fix for us was to bump up the memory allocation using these hidden commands: set policy-options as-path-match memory

Re: [j-nsp] Junos 20 - slow RPD

On 3/25/22 11:21, Mihai via juniper-nsp wrote: In my case I just upgraded one MX204 in the lab to 21.2R2, enabled rib-sharding and increased the JunosVM memory to 24G and things look better now. Glad to hear! Mark. ___ juniper-nsp mailing list j

Re: [j-nsp] Junos 20 - slow RPD

In my case I just upgraded one MX204 in the lab to 21.2R2, enabled rib-sharding and increased the JunosVM memory to 24G and things look better now. On 25/03/2022 00:58, Gustavo Santos via juniper-nsp wrote: Hi, I think that I was the only one with this issue. Even with a RE-S-X6-64G. We ha

Re: [j-nsp] Junos 20 - slow RPD

On 3/25/22 02:58, Gustavo Santos via juniper-nsp wrote: Hi, I think that I was the only one with this issue. From their feedback, it seems the issue of scaling outbound updates of full tables to eBGP neighbors is known within Juniper, because they told us they have had to come up with all

Re: [j-nsp] Junos 20 - slow RPD

Hi, I think that I was the only one with this issue. Even with a RE-S-X6-64G. We have very slow outbound updates. sending a lot of fullrouting tables to customers may take upto 60 minutes or more when you have a lot of BGP groups , for instance, one group per customer ... and if the we have an

Re: [j-nsp] Junos 20 - slow RPD

On 3/22/22 22:42, Mihai via juniper-nsp wrote: Hi Saku, The routes are in VRF so no support for rib-sharding unfortunately. This MX204 is running 20.2R3-S3 so probably the only option is to try another version. We've had some terrible experiences with RPD due to NSR sync. to re1 for BGP

Re: [j-nsp] Junos 20 - slow RPD

Hi Saku, The routes are in VRF so no support for rib-sharding unfortunately. This MX204 is running 20.2R3-S3 so probably the only option is to try another version. Thank you for your time and info, very useful as always. On 22/03/2022 17:58, Saku Ytti wrote: Hey, On MX204 with ~4M routes

Re: [j-nsp] Junos 20 - slow RPD

Hey, > On MX204 with ~4M routes, after upgrading from 18.2 to 20.2 the RPD is > way slower in processing BGP policies and sending the routes to neighbors. > For example, on a BGP group with one neighbor and an export policy > containing 5 terms each matching a community it takes ~1min ( 100% RPD >

[j-nsp] Junos 20 - slow RPD

Hi, On MX204 with ~4M routes, after upgrading from 18.2 to 20.2 the RPD is way slower in processing BGP policies and sending the routes to neighbors. For example, on a BGP group with one neighbor and an export policy containing 5 terms each matching a community it takes ~1min ( 100% RPD utilis

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

Hi, actually Juniper published PR1568533 about this (as it should have worked like KB35261 says but it was not) – the PR says it's fixed in 19.4R3-S3 too, by the way. Olivier > Le 19 mai 2021 à 13:26, Antti Ristimäki a écrit : > > Hi list, > > Just as a follow-up and for possible future ref

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

Hi list, Just as a follow-up and for possible future reference, 18.4R3-S7 indeed sends the untagged customer frames with only SVLAN tag to QinQ uplink, but 18.4R3-S8 again reverts the behaviour such that those frames are sent double-tagged with both SVLAN and native-vlan. Tested with QFX5110-48

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

Hi Karsten, Thanks for the link, I wasn't aware of such KB article, although there are several other articles related to native-vlan handling. The QFX5110 in question was previously running 17.3R3-S3 and there the native-vlan was indeed double-tagged on the uplink, just like the table says. Bu

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

--- Begin Message --- Hi, I haven't tested the behvaior, but to avoid the big surprises you should at least check the tables in the kb: https://kb.juniper.net/InfoCenter/index?page=content&id=KB35261&actp=RSS As you're not writing the exact release, there was a change if you upgraded from R1 o

Re: [j-nsp] JunOS 18, ELS vs non-ELS QinQ native vlan handling.

Hi list, Returning to this old thread. It seems that the behaviour has again changed, because after upgrading QFX5110 to 18.4R3-S7 the switch does not add the native-vlan tag when forwarding the frame to QinQ uplink. Previously with version 17.3 the switch did add the native-vlan tag along with

Re: [j-nsp] Junos interface unit disable behavior

Hello Muruganandham, as long as the physical interface is up, R1 will have all units up because R1 is not aware that you shut some logical interface on R2. kind regards Rolf > Hi, > > R1 and R2 are connected directly over a xe interface with vlan tagging > enabled. Say there are 10 units in the

[j-nsp] Junos interface unit disable behavior

Hi, R1 and R2 are connected directly over a xe interface with vlan tagging enabled. Say there are 10 units in the interface. What will be the interface unit status in R1 if the corresponding interface unit is disabled in R2? Regards ___ juniper-nsp mai

Re: [j-nsp] Junos OS Evolved

Data Center use cases, except some PTX1 products... albeit the ones that are dual personality with their QFX alter ego :-) Sent from my iPhone > On Oct 13, 2020, at 3:30 PM, Richard McGovern wrote: > > I am thinking (guessing) you will not see EVO on MX for some time. EVO is > mainly t

Re: [j-nsp] Junos OS Evolved

--- Begin Message --- I am thinking (guessing) you will not see EVO on MX for some time. EVO is mainly targeted at Data Center use cases, for which MX is used for DC to DC connectivity, but not as a main stay within any DC. My 2 cents worth. Richard McGovern Sr Sales Engineer, Juniper Networks

Re: [j-nsp] Junos OS Evolved

Once upon a time, Alain Hebert said: >     I haven't unpackaged an Evolved distribution yet, but my > experience with WindRiver licensing back in early 2000, it would be > pricey. Heh, when you pay 6 figures for a router, two copies of Wind River Linux for the REs is probably barely a bump. Also

Re: [j-nsp] Junos OS Evolved

On Tue, Oct 13, 2020 at 01:51:59PM -0400, Alain Hebert wrote: >     As for FreeBSD, they could have gone the way of upgrading the >kernel (I saw some evidences about 10.x but no confirmation yet) but >depending of their initial work done during the 4.x days, switching >might have been a better

Re: [j-nsp] Junos OS Evolved

    I haven't unpackaged an Evolved distribution yet, but my experience with WindRiver licensing back in early 2000, it would be pricey.     As for FreeBSD, they could have gone the way of upgrading the kernel (I saw some evidences about 10.x but no confirmation yet) but depending of their ini

Re: [j-nsp] Junos OS Evolved

Once upon a time, Alain Hebert said: >     Since most of the reference implementation from their ASIC > provider with be Linux based ... the path of least resistance wins. This is on the RE, which is just standard Intel x86 stuff (or IIRC ARM for smaller stuff?). >     And, I think, the "prefere

Re: [j-nsp] Junos OS Evolved

    Since most of the reference implementation from their ASIC provider with be Linux based ... the path of least resistance wins.     And, I think, the "preference" of the majority of their own devs/mgmt which never knew nothing but Linux =D. - Alain Hebert

Re: [j-nsp] Junos OS Evolved

Whats its history? (will Google it too) I mean, from a software engineering point if view, it's a tough call to start again. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Junos OS Evolved

On Sun, 11 Oct 2020 at 00:24, Colton Conor wrote: > So is Junos OS Evolved available for the MX routers? How would you go from > regular Junos to Junos OS Evolved on a MX 240/480/960 for example? It is not, but expect to see it in future MX REs. -- ++ytti _

Re: [j-nsp] Junos OS Evolved

So is Junos OS Evolved available for the MX routers? How would you go from regular Junos to Junos OS Evolved on a MX 240/480/960 for example? On Fri, Oct 9, 2020 at 11:38 AM Saku Ytti wrote: > Hey Colton, > > > I was unaware of Junos OS Evolved until recently. At what version did > > regular Jun

Re: [j-nsp] Junos OS Evolved

    Well this is coming from my experience with QFX5100, less of an issue with MX platforms but still for the price tag it was kinda hellish.     Been stable after we worked some of the pitfalls... still got some chipset related issue when someone makes an error and mix L2 VLANs with VLAN-CCC

Re: [j-nsp] Junos OS Evolved

Like many things either it works or it doesn't. I'm not a fan of paying for software with bugs personally. We do have Evo in use. Sent from my iCar > On Oct 9, 2020, at 12:55 PM, Alain Hebert wrote: > > Nice another round of customers doing JNP QA :( > > - > Alain Hebert

Re: [j-nsp] Junos OS Evolved

    Nice another round of customers doing JNP QA :( - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 2020-10-09 12:38, Saku Ytt

Re: [j-nsp] Junos OS Evolved

--- Begin Message --- I think QFX5200-32C (and some PTX?) are only platforms that have support for both a Junos version and an EVO version. I think once [very hard if not impossible] to change. FYI only Richard McGovern Sr Sales Engineer, Juniper Networks 978-618-3342 I’d rather be lucky than

Re: [j-nsp] Junos OS Evolved

Hey Colton, > I was unaware of Junos OS Evolved until recently. At what version did > regular Junos evolve into Junos OS Evolved? Is there a certain version > where after that version, everything ongoing is Junos OS Evolved? I think EVO appeared in 19.1, but in most cases you don't have a choice,

[j-nsp] Junos OS Evolved

I was unaware of Junos OS Evolved until recently. At what version did regular Junos evolve into Junos OS Evolved? Is there a certain version where after that version, everything ongoing is Junos OS Evolved? ___ juniper-nsp mailing list juniper-nsp@puck.ne

Re: [j-nsp] Junos Telemetry Interface

--- Begin Message --- Note that I'm not speaking for my employer's implementation here. I don't know enough of the code in question to give a deep dive answer into the issue from top of my head. That said, I've spent a number of years working on data aggregation tools in a prior life. Getting

Re: [j-nsp] Junos Telemetry Interface

Hi Aaron, > I tried decimals and zero to see what would happen, seems that 1 is the lowest. Looks like it is possible to configure 0 as a reporting-rate using ephemeral database, but then the device simply does not send any telemetry data. I also did some further testing with Grafana and it loo

Re: [j-nsp] Junos Telemetry Interface

Here's my lab MX960 Mine is currently set at 1 second set services analytics export-profile my-exprt-prfl reporting-rate 1 I tried decimals and zero to see what would happen, seems that 1 is the lowest. {master}[edit] agould@lab-960# set services analytics export-profile my-exprt-prfl reportin

Re: [j-nsp] Junos Telemetry Interface

Hi Dario, > So I can get the correct values in Grafana in bps, what reporting-rate do you have configured on the Juniper? I configured 1 second interval, but I noticed that at least vMX sent data with 2 and occasionally 3 second intervals. I guess this is because according to https://www.juniper.

Re: [j-nsp] Junos Telemetry Interface

;>> have it running on MX960’s. >>>>>> >>>>>> >>>>>> >>>>>> I understand the grpc/openconfig method requires you to download some >>>>>> code/software to the network device. >>>>>> >>>>>> >

Re: [j-nsp] Junos Telemetry Interface

On Tue, Apr 14, 2020 at 2:01 PM Martin Tonusoo wrote: > > Hi Dario, > > > This looks really useful, thanks for sharing. Just checking, do I only need > > this script, InfluxDB and Grafana to get traffic graphs? > > That's correct. Thanks - it's working nicely. So I can get the correct values in

Re: [j-nsp] Junos Telemetry Interface

Hi Dario, > This looks really useful, thanks for sharing. Just checking, do I only need this script, InfluxDB and Grafana to get traffic graphs? That's correct. WBR, Martin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.n

Re: [j-nsp] Junos Telemetry Interface

On Mon, Apr 13, 2020 at 4:46 AM Aaron Gould wrote: > > You’re welcome Colton. I understand there are 2 different ways to do > telemetry on Juniper. One called Native and the other called > gRPC/openconfig. I’ve done the Native form. I think the native form is a > configured form where by wh

Re: [j-nsp] Junos Telemetry Interface

On Tue, Apr 14, 2020 at 12:13 AM Martin Tonusoo wrote: > > Telegraf has a built-in input plugin for Juniper Openconfig, so it takes > > like 5 minutes to enable. > > there also seems to be a patch for native sensors: > https://github.com/influxdata/telegraf/pull/6365. Unfortunately, it's not > yet

Re: [j-nsp] Junos Telemetry Interface

t;>>> known Cronograf, which I actually use and like), InfluxDB (TSDB), fluentd, >>>>> and other components. I must credit Dave, my coworker and resident Linux >>>>> genius in assisting my with the server side collector setup. Some >>>>> help

Re: [j-nsp] Junos Telemetry Interface

Hi, > Telegraf has a built-in input plugin for Juniper Openconfig, so it takes > like 5 minutes to enable. there also seems to be a patch for native sensors: https://github.com/influxdata/telegraf/pull/6365. Unfortunately, it's not yet merged. In addition, in order to better understand how the na

Re: [j-nsp] Junos Telemetry Interface

ector setup. Some >>>> helpful/related links below…. >>>> >>>> >>>> >>>> >>>> >>>> https://puck.nether.net/pipermail/juniper-nsp/2018-October/036602.html >>>> >>>> >>>> >>>&g

Re: [j-nsp] Junos Telemetry Interface

>> https://openeye.blog/2017/06/26/using-opennti-as-a-collector-for-streaming-telemetry-from-juniper-devices-part-1/ >>> >>> >>> >>> >>> >>> >>> https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-telemetry-interfac

Re: [j-nsp] Junos Telemetry Interface

t; >> >> >> >> https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-telemetry-interface-oveview.html >> >> look under “telemetry sensors and data models” >> >> >> >> >> >> >> https://community.grafana.co

Re: [j-nsp] Junos Telemetry Interface

https://www.juniper.net/documentation/en_US/junos/topics/concept/junos-telemetry-interface-oveview.html > > look under “telemetry sensors and data models” > > > > > > > https://community.grafana.com/t/how-to-send-juniper-router-telemetry-to-grafana/11071/9 > >

Re: [j-nsp] Junos Telemetry Interface

sensors and data models” https://community.grafana.com/t/how-to-send-juniper-router-telemetry-to-grafana/11071/9 -Aaron From: Colton Conor [mailto:colton.co...@gmail.com] Sent: Saturday, April 11, 2020 9:05 AM To: Aaron Gould Cc: Juniper List Subject: Re: [j-nsp] Junos Telemetry

Re: [j-nsp] Junos Telemetry Interface

From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > Of > Colton Conor > Sent: Thursday, April 9, 2020 3:25 PM > To: Juniper List > Subject: [j-nsp] Junos Telemetry Interface > > Instead of monitoring Juniper equipment by SNMP with 5 minute polling we &

Re: [j-nsp] Junos Telemetry Interface

List Subject: [j-nsp] Junos Telemetry Interface Instead of monitoring Juniper equipment by SNMP with 5 minute polling we would like to use streaming telemetry to monitor the devices in real-time. This requires the Junos Telemetry Interface. Looking in the Juniper Feature Explorer, Junos Telemetry Inte

  1   2   3   4   5   6   7   8   9   10   >