On Mon, 19 Aug 2019 20:47:29 +0200 Jean Benoit jean@unistra.fr wrote:

I tried to set a VLAN to a port on Juniper EX using NAV PortAdmin. It didn't work.

[snip]

Looking into Juniper documentation, where some writable SNMP mib variables are mentionned, it seems that SNMP is not intended to be the main tool to modify things.

Hi Jean,

You are indeed correct. Juniper is pushing NETCONF for all management/configuration needs, and so will not support SNMP write operations for most things.

I discovered there is a Netconf branch in the git repo. I couldn't find any information about it. How stable/mature is the Netconf branch ? Do you have any plan to integrate and release it ?

The netconf branch is an old snapshot of some experimental netconf work done by Sigmund. It will never be merged to the master branch as-is, but rather serve as inspiration for further work.

Part of the branch implements a model for configuration of management profiles. A reimplemented version of this has been merged to the master branch, so that NAV can be made to support other management protocols than SNMP v1 and v2c.

What is the strategy to bring more support for Juniper from a code perspective ?

There are basically two main deficiencies in NAV when it comes to Juniper:

1. NAV needs improved support for getting hardware information from Juniper. This can readily be achieved with SNMP - it's just that historically, Juniper doesn't support the ENTITY-MIB (except, more recently, on some platforms/OS combinations), so support for Juniper proprietary MIBs need to be added - and this needs to map into NAV's way of modelling the physical contents of a device, which again borrows heavily from the ENTITY-MIB.

2. Your issue: Juniper devices will not support SNMP writes for switch port configuration through PortAdmin.

To solve #2, one needs to decide which new management profile types are needed, since there are several, not-necessarily-compatible approaches to this brave new world of management protocols.

One route is to simply have a "NETCONF" profile type, but where the backend selects an implementation based on the type of device: E.g, it selects Junos PyEZ for juniper devices, getting the credentials from the device's NETCONF profile, whereas it selects `ncclient` or NAPALM for another device. Maybe NAPALM could be utilized for all those things, since it already features an abstraction layer over many device vendors.

Another route is to specifically have profile types for the various implementations (i.e. a PyEX profile type, a ncclient profile type and a NAPALM profile type). However, that would place the burden on the user to configure the "correct" type based on the device in question, so it might be a less user-friendly direction.

One more "complication": This is all fine and well when it comes to a synchronous mode of operation, which is the way PortAdmin (and Arnold) works. If NETCONF is to be used for inventory/data collection in ipdevpoll as well, then the selected backend library needs to support an asynchronous mode of operation, so as not to block the entire ipdevpoll process.

Since vendors cannot even agree on how to support switch configuration through standard SNMP MIBs, PortAdmin already features multiple vendor-based implementations in [3], mainly for Cisco, HP, H3C and Dell (which all build on a generic IETF RFC-based implementation, which is the default fallback for unknown vendors).

These implementations probably need to change somewhat to account for the fact that something *other* than SNMP can be used for some vendors.

[1] https://github.com/ncclient/ncclient [2] https://napalm-automation.net/ [3] https://github.com/Uninett/nav/blob/master/python/nav/portadmin/snmputils.py