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? :)