[j-nsp] NETCONF vs SNMP for monitoring

[Morgan McLean]

Hi all,

Just curious if anybody opts to use netconf instead of snmp for monitoring
purposes? Any known downsides?

SNMP seems to never really be up to date with everything that you might
want to have a peek at.

Thanks,
Morgan

[Tyler Christiansen]

SNMP is less resource-intensive and faster than NETCONF. I would use SNMP
for the things you can and NETCONF for the things you can't. If you
consider NETCONF, it would probably be best to do so in a threaded,
asynchronous, or multi-process fashion. I've seen a few SNMP pollers that
don't use threads or multiple processes or callbacks, and they can get away
with it. I don't think NETCONF can.

--tc

Post by Morgan McLean
Hi all,
Just curious if anybody opts to use netconf instead of snmp for monitoring
purposes? Any known downsides?
SNMP seems to never really be up to date with everything that you might
want to have a peek at.
Thanks,
Morgan
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Morgan McLean]

Yea multithreading would be the way to go, it's not very intensive, just
sits hanging out waiting for its response. I was reading a paper somebody
wrote on performance for SNMP vs NETCONF, which is here:
http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf . Seems to
suggest as workload increases, netconf becomes more favorable. I haven't
tested it in depth; in fact I'm having trouble finding documentation on the
different calls I can make.

Thanks,
Morgan

Post by Tyler Christiansen
SNMP is less resource-intensive and faster than NETCONF. I would use SNMP
for the things you can and NETCONF for the things you can't. If you
consider NETCONF, it would probably be best to do so in a threaded,
asynchronous, or multi-process fashion. I've seen a few SNMP pollers that
don't use threads or multiple processes or callbacks, and they can get away
with it. I don't think NETCONF can.
--tc

Post by Morgan McLean
Hi all,
Just curious if anybody opts to use netconf instead of snmp for monitoring
purposes? Any known downsides?
SNMP seems to never really be up to date with everything that you might
want to have a peek at.
Thanks,
Morgan
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Tyler Christiansen]

I consider wait time to be part of resources (and thus
resource-intensive). Especially if queries on your NMS start to build up
because you're waiting on responses.

I haven't read that paper thoroughly, but it looks like it's specifically
comparing SNMP and NETCONF for the purpose of configuration management--not
monitoring. For configuration management, NETCONF wins hands down.

If you're looking strictly for Juniper, there are a number of NETCONF
libraries that will give you easy access to the RPCs.

https://github.com/juniper?query=netconf

As far as which RPCs you can make, if there's something specific you want,
just log into the Juniper device and type the command, then:

| display xml rpc

If you need to know how to parse it, then leave off `rpc`.

For other vendors, someone else will have to pipe in as I haven't worked
with other vendors. Hypothetically, you should be able to use the same
RPCs and parsing for any vendor. In practice, though, this isn't the case
(just look at NETCONF on IOS for a perfect example).

--tc

Post by Morgan McLean
Yea multithreading would be the way to go, it's not very intensive, just
sits hanging out waiting for its response. I was reading a paper somebody
http://morse.colorado.edu/~tlen5710/11s/11NETCONFvsSNMP.pdf . Seems to
suggest as workload increases, netconf becomes more favorable. I haven't
tested it in depth; in fact I'm having trouble finding documentation on the
different calls I can make.
Thanks,
Morgan

Post by Tyler Christiansen
SNMP is less resource-intensive and faster than NETCONF. I would use
SNMP for the things you can and NETCONF for the things you can't. If you
consider NETCONF, it would probably be best to do so in a threaded,
asynchronous, or multi-process fashion. I've seen a few SNMP pollers that
don't use threads or multiple processes or callbacks, and they can get away
with it. I don't think NETCONF can.
--tc

Post by Morgan McLean
Hi all,
Just curious if anybody opts to use netconf instead of snmp for monitoring
purposes? Any known downsides?
SNMP seems to never really be up to date with everything that you might
want to have a peek at.
Thanks,
Morgan
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Phil Mayers]

Post by Tyler Christiansen
SNMP is less resource-intensive and faster than NETCONF. I would use SNMP
for the things you can and NETCONF for the things you can't. If you

I would agree with this, based on our extensive playing. We tend to
monitor with SNMP, configure with Netconf/Junoscript.

Couple of additional points:

1. Sometimes the SNMP MIB is really horribly organised either from a
performance point of view ("OIDs shall be ordered by prime factorial of
birth date" - hateful if you need to fetch a whole table of 10k rows to
get one item) or needing to fetch a jillion separate tables to get the
final result. In this case, Netconf *may* be faster but...

2. ...you need to account for the overhead of setup/teardown of the
Netconf session, particularly the SSH/HTTPS key exchange. On low-end
devices (EX3300) the CPU were sluggish enough that we opted for plain
TCP transport Junoscript, relying on the firewalled management VLAN for
security. Try to catch everything in one Netconf session - Tyler's point
about async/threading is very relevant here.

3. Occasionally you'll find things not exposed over SNMP; obviously
then Netconf

4. Finally, you may find that bulk data collection - e.g. all the
counters, all the ARP / ethernet switching table entries - is quicker
over Netconf. SNMP results need to be OID-sorted which can be slow, but
also the TCP transport can end up being faster than UDP. Test and see
which works, but also beware faster collection may mean higher CPU on
the monitored device.

[Phil Shafer]

Post by Phil Mayers
4. Finally, you may find that bulk data collection - e.g. all the
counters, all the ARP / ethernet switching table entries - is quicker
over Netconf. SNMP results need to be OID-sorted which can be slow, but
also the TCP transport can end up being faster than UDP. Test and see
which works, but also beware faster collection may mean higher CPU on
the monitored device.

SNMP is good for quick responses, but can be problematic for bulk
data collections. Take a look at the accounting profiles feature
in JUNOS, which can collect values locally on the RE and transfer
them on size or time thresholds via ftp, http, or scp. Profiles
can record interface states, RE states, MIB variables, or have
custom values supplied by on-box scripts.

The trade offs are delayed transfer, but less impact on the device,
and you get values even during networking issues/outages.

There's an NCE write-up at:

http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/nce/accounting-profiles-statistics-logging/accounting-profiles-statistics-logging.pdf

Thanks,
Phil