Juniper PTX with junos-evolution devices misidentified.

OS definition added, mostly same as junos. Rancid option different.

Fixed in r13176.

This is funny, but unusable compare..
because show Oids compare, but not MIB. (Each MIB can have 1000+ Oids).
I can't parse/get this lists.

Hi, sorry for delay.
I just looked into your snmpdump and there complete not exist Juniper Ent specific Oid tree.

I not sure - this is complete not exist for this os or just missed in dump.
Please make separate dump for this Oid tree:

snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1.3.6.1.4.1 > myagent-ent.snmpwalk

Junos evolve  vs  Junos  diffs:

https://apps.juniper.net/mib-explorer/compare?release1=Junos%20OS%7C23.2R1&release2=Junos%20OS%20Evolved%7C23.2R1

it is important to differentiate the OS like i said before... the config automation also breaks (rancid)

Hello

find attached a snmpwalk (trimmed, without routing info)

Routes not required of course, this is unuseful data, but it's very hard for create full snmpdump without it.
Probably you can create snmp view on hardware for exclude this Oids.

Currently you are first who requested support for this OS and I can ask this dump only from you..

As I see Juniper documentation Evolved have differences in supported MIBs, so access to snmp is highly desirable.

For you it might not make sense.

For people that use Juniper EVO devices it does.

You can see two screenshots attached one for a Juniper EVO device (PTX10001-36MR)  other for a Juniper "normal" device, an MX204.

There are some differences but this by example, impacts also on integrations, such as rancid.

This has been patched +2y ago by them, see:

https://shrubbery.net/pipermail/rancid-announce/2020-January/000037.html

"add device type junos-evo for JunOS EVO"

The difference is, by example when generating the router.db file via your integration we had to either manually fix it by adding junos-evo instead of junos to those devices (or fork and patch your code).

There are plenty other differences, if you search on at your Jira by PTX there were already some reported stuff, but i am sure there's more.

The dump you asked is simply DUMB, since this is an pure peering and transport device with millions of routes into it.  I processed it anyways, left if for over 1h and it generated 3GB data (without even completing).  I dont think you need the full data, as it contains millions of routing table entries.   I can process it and give it to you anyways if you feel necessary...   But in the end and for what we need sorted out is basically to parse correctly and add the info on observium that the host is junos-evo and not junos !!!

a JunOS device and a JunOS-EVO device on router.db should look like this:

xxx.xxx;junos;up
yyy.yyy;junos-evo;up

some more details about the junos vs junos-evo:

https://www.juniper.net/documentation/us/en/software/junos/overview-evo/topics/concept/evo-top-differences.html

https://www.juniper.net/documentation/us/en/software/junos/network-mgmt/topics/topic-map/snmp-mibs-and-traps-supported-by-junos-os.html

The ticket itself is +18 months old, i wasn't even expecting any interaction from Observium, but lets see how it goes.

Thank you !

Hello

I left the dump running (for more than 1h) and it was not ended.. the file was 3GB long so far and i've cancelled it.

There are some differences particularly on interfaces and subinterfaces (as others mentioned before on other OBS reports "search for ptx"), but also and not fixed on your code, with rancid integration.

On rancid Junos EVO should be tagged as junos-evo and not junos.  Due to this we have to change manually the router.db file or fork to fix your code

example for one junos and one junos-evo on rancid:

xx.xxxx.xxx;junos;up
yy.yyyy.yyy;junos-evo;up

from Jan 2020:

https://shrubbery.net/pipermail/rancid-announce/2020-January/000037.html

https://github.com/haussli/rancid/blob/master/CHANGES

-> "add device type junos-evo for JunOS EVO"

TLDR: JunOS is FreeBSD ; JunOS-EVO is Linux

Aside this, Observium is UNABLE to identify on its interface the versions of the EVO releases, by ommiting it at all.  This doesnt happen on JUNOS (see attached screenshots for both junos-evo and junos hosts)

There are also other differences, but nothing that really impacts us on day to day.  As a a paying user we would love to see this resolved. i am sure others have the same issue but probably took the same path as us to avoid dependence on the OBS vendor willingness to fix or not.

If you want the full dump we can send it (obviously not on the portal, the file is huge).

Some extra reading for you:

https://www.juniper.net/documentation/us/en/software/junos/overview-evo/topics/concept/evo-top-differences.html

https://www.juniper.net/documentation/us/en/software/junos/network-mgmt/topics/topic-map/snmp-mibs-and-traps-supported-by-junos-os.html

IMHO it would make sense for you to FIX this, since the user base of EVO equipment is uprising, but in the end, i opened this ticket 18 month ago... i wasnt even expecting a response... lets see how it goes...

JunOS-EVO device: (no version shown)

JunOS device: (version show, able to filter an see on observium)

just set os name doesn't make sense, because we not know what supported in snmp by this os.
If support same as in current JunOS definition, than split os definition not required.

But if something unsupported - snmpdump required.

hello

you can find it here (whatever has -EVO on the product info, is the JunOS evolve)

iso.0.8802.1.1.2.1.3.4.0 = STRING: "Juniper Networks, Inc. ptx10001-36mr internet router, JUNOS 22.4R1.11-EVO, Build date: 2022-12-20 08:56:54 UTC Copyright (c) 1996-2022 Juniper Networks, Inc."