AggregateLink vs NetworkDeviceVirtualInterface

[eric24V]

Hello,

first of all, thanks to Christophe for these great extensions!

I just wonder why AggregateLink is a separate class. In my current understanding a bond (or link aggregation or port channel) is a virtual interface. I’d add the ability to aggregate physical links to the NetworkDeviceVirtualInterface class and drop the AggregateLink class instead. Using NetworkDeviceVirtualInterface would also bring the ability to add VLANs and VRFs to aggregations.

As its name says NetworkDeviceVirtualInterface is meant for NetworkDevice only. Why isn’t it a more general VirtualInterface class? I currently experiment with extending NetworkDeviceVirtualInterface to use ConnectableCI as target class to use it on Servers and NAS too.

[Xtophe38]

Hi,

The idea of Aggregate links is to document suche links without having to create individual ones and grouping them together. True that I could add VRFs and VLANs to them.

True that there is no generic virtual interface class for physical devices beside the one dedicated to network devices. Do you see a need for such interfaces on physical servers and other physical devices ?

[eric24V]

Hello Christophe,

I don’t understand what you mean by „without having to create individual ones and grouping them together.“. As far as I know the individual physical interface objects need to be created and the aggregate link object has to be created too. Then the physical interfaces can be added underneath the aggregate link.

One main data source in my environment is the monitoring system checkmk. It gathers lots of inventory information via snmp and other protocols. A bond (port channel, lag) of a swich for example has the snmp interface type (https://www.net-snmp.org/docs/mibs/interfaces.html) 53 propVirtual. I regard this as a fortification of my understanding that a link aggregation is always virtual. One can’t put a physical cable in a bond, only in its physical members. This interpretation/understanding creates my need for having virtual interfaces on servers, NAS and other systems because they have several physical interfaces aggregated to virtual bonds/port channels/lags.

My data synchronisation script separates physical and virtual interfaces by snmp interface type and other criteria and creates both in iTop. A separate class for aggregation would make this more complicated. I’d even go further and drop LogicalInterface class too because I see no difference to VirtualInterface. Having only two classes to represent interfaces makes it also easier and clearer to display them in objects.

[Xtophe38]

Hello,

"without having to create individual ones and grouping them together" because you can create an Aggregate Link" between devices without having any interface created on these devices.

So, I understand that you'd rather see only 2 types of interfaces: Physical and Virtual and consider aggregate links as just a type of virtual interface. Am I correct ?

I agree that only 2 types of interfaces would simplify things. I'm not too sure about Aggregate Links. This being said, going that way would imply quite a few significant changes in the datamodel and a not less complicated migration process !

[eric24V]

Hello Christophe,

yes, I’d prefer to only have two child classes of IPInterface: PhysicalInterface and LogicalInterface. Which are those two that come shipped with iTop.

And yes, I barely dare to imagine the high amount of effort needed to make this change and a somehow bearable migration procedure. But I’m sure it would pay out in the future if there were less classes. Presentation, data synchronization, making queries and interaction with other extensions would be simplified.

[Hipska]

Hi @eric3000, I kinda agree with you, but there are some implementation details that might be important/relevant:

The LogicalInterface is tightly coupled to VirtualMachine the same whereas NetworkDeviceVirtualInterface is coupled to NetworkDevice. Combining these into 1 is therefore not possible. However, it should be possible to have this virtual interface be linked to ConnectableCI instead, as you have indeed also virtual interfaces on regular servers (lo for example)

About the SNMP ifType, I will need to correct you that the propVirtual(53) is sadly a wrong implementation on that switch, as a better suitable is ieee8023adLag(161). Therefore I would keep AggregateLink as a separate class, but maybe make it a child class of the virtual interface, as indeed, they are always virtual indeed.