The initial feature release of the 5.1 series of NAV is now out!
The source code is available for download at GitHub [1].
A new package for Debian 10 (Buster) is available in our APT repository [2] as usual. Packages for Debian 9 (Stretch) have been discontinued.
Please be extra aware of config file changes. Look out for `*.dpkg-dist` files in /etc/nav and make sure to update your running config.
The virtual appliance will be updated shortly.
Changes =======
User-visible features and improvements:
* #2021 (Add SeedDB action to clone netboxes and rooms) * #2051 (Link to affected devices in Management profile) * #2128 (Add device filtering options to ipdevpoll and pping, to enable support for horizontal scaling and distributed monitoring) * #2175 (Implement NAPALM management profiles and connectivity) * #2185 (Modernize the type dumping script and make it available as an installable script for end user use) * #2204 (Add support for configuring Juniper switch ports in PortAdmin) - #2173 (Clean up PortAdmin ManagementHandler interface) - #2112 (Refactor PortAdmin's SNMP back-end classes and factories) - #2115 (Refactor portadmin configuration parsing bits) - #2121 (Use nav.config.NAVConfigParser for PortAdmin configuration) - #2205 (Adapt Portadmin UI workflow to meet needs of multiple backend protocols)
Fixed GitHub issues in this release:
* #2078 ([BUG] NAV daemons are unnecessarily run as root) * #2103 (Support Django 2.2) * #2139 ([BUG] fanState and psuState e-mail alerts say "no message template is defined") * #2141 (Work around lack of entity names when collecting sensors from Arista devices) * #2174 ([BUG] PortAdmin never issues a "write mem" operation when editing trunks) * #2190 ([BUG] Regression - mysql service check does not work) * #2197 ([BUG] Bottom part of room images are obscured by image caption) * #2198 ([BUG] CSV export from Netbox interfaces in Room view produce wrong filename and content.) * #2199 (Make servicemon HttpChecker use the port number from the URL, if present) * #2207 (Netbox reference is not passed to customization template for the ipdevinfo "What if" tab) * #2213 ([BUG] NAV does not import room position)
Please see the release notes [3] for more details. Happy NAVing everyone!
Links =====
[1] https://github.com/UNINETT/nav/releases [2] https://nav.uninett.no/install-instructions/#debian [3] https://nav.uninett.no/doc/latest/release-notes.html#nav-5.1
On 26/11/2020 15.51, Morten Brekkevold wrote:
The initial feature release of the 5.1 series of NAV is now out!
Cool!
- #2204 (Add support for configuring Juniper switch ports in PortAdmin)
This one is really of great value for us being a mostly Juniper shop.
From what I can gather now it's implemented quite "cisco-ish", putting a vlan on a port and that's mostly it.
I would really like to see usage of membership in an interface-range as a way of changing the entire port profile - we typically have quite different configurations on a normal client-port, access point or a CCTV camera.
Is this something you would consider?
Cheers and thanks for all the good work on NAV!
-Sigurd
On Tue, 1 Dec 2020 15:40:18 +0100 Sigurd Mytting sigurd@mytting.no wrote:
This one is really of great value for us being a mostly Juniper shop.
From what I can gather now it's implemented quite "cisco-ish", putting a vlan on a port and that's mostly it.
I would really like to see usage of membership in an interface-range as a way of changing the entire port profile - we typically have quite different configurations on a normal client-port, access point or a CCTV camera.
Is this something you would consider?
I'm not sure I understand what you mean by "membership in an interface-range", but then again, I'm not a network engineer and I don't have any experience with real world Juniper configs.
What we have been discussing in both the NAV reference committee and in the CNaaS team is the concept of "port profiles". In this concept, there is a limited range of (named) interface configuration templates. Every access port needs to have exactly one of these profiles, and PortAdmin should have a mode where you don't configure options individually per port, but can only select a preset profile from a list of available (named) profiles.
Might that perhaps overlap with what you are attempting to describe?
On 09/12/2020 14.17, Morten Brekkevold wrote:
Might that perhaps overlap with what you are attempting to describe?
Sort of, most of this is already something you have available in JunOS:
Let me elaborate briefly on how we configure our equipment:
Under interfaces, instead of applying configuration on a interface directly, you have something called "interface-range NAME". In this interface-range you configure everything as you would on a normal interface, but you add "member INTERFACE" to apply the configuration.
You can also have configuration on each interface directly, and one interface can be a member of several interface-ranges.
Everything is so merged together as a functioning configuration on each interface magically behind the scenes (you can see the expanded configuration using the "display inheritance"-pipe-command).
It's normally recommended to use just one way of configuring your specific options since it's quite easy to create an invalid configuration doing this...
Then you can use NAME as an interface elsewhere in your configuration, on a switch you can let the interface-range ACCESSPOINT have poe enabled and interface-range CLIENT have poe disabled. (Just FYI, it's quite common to use capital letters on self defined variables when configuring JunOS to strongly distinguish local configuration from inherited and default configuration).
real world example (this is quite verbose as JunOS normally is): sm@sw-1> show configuration ... interfaces { interface-range A1APORTS { member ge-0/0/0; member ge-0/0/2; unit 0 { family ethernet-switching { interface-mode access; vlan { members A1A; } recovery-timeout 60; } } } interface-range WIFIPORT { member ge-0/0/9; member ge-0/0/8; member ge-0/0/1; description WIFIPORT; native-vlan-id 254; unit 0 { family ethernet-switching { interface-mode trunk; vlan { members [ A1A GUEST APMGMT ]; } } } } ...omitting a lot of other interfaces... ge-0/0/2 { description CLIENT-1; } ge-0/0/9 { description WLAN; } } ... protocols { rstp { interface A1APORTS { edge; no-root-port; } ... } } ... poe { interface WIFIPORT; interface A1APORTS { disable; } }
And with display inheritance on just ge-0/0/2:
sm@sw-1> show configuration interfaces ge-0/0/2 | display inheritance description CLIENT-1; ## ## '0' was expanded from interface-range 'A1APORTS' ## unit 0 { ## ## 'ethernet-switching' was expanded from interface-range 'A1APORTS' ## family ethernet-switching { ## ## 'access' was expanded from interface-range 'A1APORTS' ## interface-mode access; ## ## 'vlan' was expanded from interface-range 'A1APORTS' ## vlan { ## ## 'A1A' was expanded from interface-range 'A1APORTS' ## members A1A; } ## ## 'recovery-timeout' was expanded from interface-range 'A1APORTS' ## '60' was expanded from interface-range 'A1APORTS' ## recovery-timeout 60; } }
Configuration closer to the interface wins, as you can see on "description". However vlan members would be added together and with a vlan directly on ge-0/0/2 you would get an error on commit since "interface-mode" is set to "access" and there can be only one.
We preload the interface-ranges mostly on the equipment and then just remove and add members to each range depending on usage. Preferably NAV should just list interface-ranges as an option on a port and if chosen remove and add to the interface-ranges accordingly. It might make sense to be able to delete the entire interface in such a scenario to clean up inherited configurations. To make it easier I would just ignore the possibility to use overlapping interface-ranges and leave it up to the network admin to not go down that route.
And there is of course one issue with this; interface-range needs at least one member. We solve this by adding a member that would likely never exist on the platform, but from NAVs point of view I'd just ignore it and let the network admin fix this.
Hopefully this made my request a bit more understandable :-)
Cheers and keep up the good work! -Sigurd
On Wed, 9 Dec 2020 17:14:05 +0100 Sigurd Mytting sigurd@mytting.no wrote:
On 09/12/2020 14.17, Morten Brekkevold wrote:
Might that perhaps overlap with what you are attempting to describe?
Sort of, most of this is already something you have available in JunOS:
Let me elaborate briefly on how we configure our equipment:
Under interfaces, instead of applying configuration on a interface directly, you have something called "interface-range NAME". In this interface-range you configure everything as you would on a normal interface, but you add "member INTERFACE" to apply the configuration.
Hi Sigurd,
My apologies for the extremely delayed feedback. We discussed the issue of "port profiles" in PortAdmin in last week's NAV reference committee meeting.
Much of the discussion owes to UiA's recent move to Juniper, and their need for more automation of network config. Maybe OsloMet should consider asking for a seat in the committe; just saying.
I find Juniper's "interface range" concept fascinating, and I definitely see how it could be useful. The only issue for NAV is that Juniper seems to be the only vendor that has this concept, out of all the common vendors we see in the Norwegan HE sector as of today.
A port profile concept in PortAdmin would need to be generic enough that specialized implementations for each vendor could be applied on top of it.
As it stands, PortAdmin has two ways to configure ports:
* Through config modification snippets uploaded to Juniper via NETCONF. * Through individual SNMP write commands for everything else.
One suggestion for a future profile concept could be:
* For each vendor, a list of named profiles to choose between must be defined in Portadmin. * A profile could consist of either * A set of values of attributes supported by PortAdmin, which PortAdmin would translate into the necessary config commands * Either into individual SNMP write operations * Or as a set of config commands uploaded to the switch. * Or, just a config template that would be filled in and sent to the device for merging into the running config.
However, this does not take into account the possibility to fetch a list of selectable "profiles" from the device itself.
Although, for Juniper, a PortAdmin profile named "Foobar" could simply be defined as a config snippet like "interface-range Foobar { member $portname }", to keep the actual port config definitions in the device config itself, that just means you need to define all your profiles in two places.
For vendors like Juniper, we could of course support the concept of fetching the available profiles from the device itself, rather than from the PortAdmin config.
A major difference between Juniper and other vendors in such a scenario would also be whether PortAdmin can detect a port's "current profile". If the profile is not a concept in the device itself, PortAdmin may only be able to display the current running config values. On Juniper, the current profile could be deduced from the interface-range memberships.
Question 1: Can a Juniper port be a member of multiple ranges? Question 2: Any thoughts on my jumbled notes above? :)
-
Morten Brekkevold -
Sigurd Mytting