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