netinventory - tweaking XML definitions (import from netdisco)

[Stoatwblr]

Tie-in from FIA #641

The net-inventory XML needs some extensions to fill out all fields on network device entries.

Most importantly, vlans need to be able to indicate (T)agged/(U)ntagged/(P)rimaryVlanID - right now all vlans on any port are showing up "untagged" whether imported using FIA or my 3rd party import script.

ifMau port type (eg: rj45/multimode fibre/singlemode fibre) and Mau speed(vs negotiated speed) are also useful as this would populate 2 of the network port fields.

I'd like to add a couple of "nonstandard" fields (comments and location) which would also fill in those fields for the network port when using 3rd-party importers.

IP is already covered, but DNSname is not and this could be useful.

[Stoatwblr]

There are several issues raising their heads as I dig into this.

The actual sorting of Layer2 physical - aggregate - alias is relatively straightforward.

A MUCH bigger problem is a mixing of L2 and L3 devices in both FIA output, Fi4G input and GLPI device creation/maintenance

ie: physical(L2)+physical(L2) = Aggregate(L2) Vlan(L2) = alias, whether it's on a physical or aggregate device.

Eth0(L2) or Bond0(L2) or Eth2.3000(L2) is NOT the same device as Eth0(L3) or Bond0(L3) or Eth2.3000(L3) - however GLPI has habitually been writing them on the same line and this has caused the distinctions between them to become blurred in peoples' minds.

Equally importantly, GLPI will not allow chains such as

Eth0(L2) + Eth1(L2) ---> bond0(L2) (aggregate)

Bond0(L2) ---> Bond0.3000(L2) (alias)

Bond0.3000(L2) ---> Bond0.3000(L3-IP1) (alias) Bond0.3000(L2) --->Bond0.3000:20(L3-IP2) (alias) Bond0.3000(L2) ----> Bond0.3000:18(L3-IP3) (alias)

In the context of networking, a layer 3 address [ipv4 or ipv6 or ipx or decnet or any other kind of networking] is ALWAYS an alias, as it can be detached from a L2 interface and reattached to any other L2 interface at any moment. A layer2 aggregate(bond) or alias(vlan) is like a L2-1 and L2-.2 device.

This causes confusion and breakage. You can get away with this kind of stuff in a small/uncomplicated network but in one like ours with over 100 VLANs, IP addresses changing between interfaces.

The chain is something like (L2-{1+1}.{2}):L3 - where the ' - . : ' may be invisible but they're always there regardless

Real life examples at our university research site:

If someone here unplugs their laptop from a wall port, their IP address seamlessly transitions from ethernet to their Wifi interface. When they plug back into a wall port the IP will switch back to the ethernet.

This means GLPI sees the IP address change its mac address - but both mac addresses are known, so it should simply transition the mac address from one device to the other, not change the mac address of the device (for the purposes of networking - a MAC IS a device, IP addresses are not. MACs can be changed in software but unless this is expected (eg, a bonding slave, or a DEC/SUN workstation that changes MAC during the bootup process) then a new mac is probably a new device and MUST NOT overwrite an old mac)

Adding confusion: A user may log out of our network entirely and log into eduroam - getting a new IP.

This means GLPI now sees the wifi mac with an entirely different IP, probably on a different VLAN - which it needs to record for auditing purposes as a separate entry for the MAC.

All of this needs to be recorded to keep auditors happy.

In a High Availability setup, a failover IP may use the mac of the L2 device that it's on, and when it changes to a different device or host, send out gratuitous ARPs to ensure the changed mac is quickly detected

OR it may have its own mac address which is ARPed from the L2 device that it's on AS WELL as the mac address of the base IP of the system that's using the device - and GLPI MUST NOT record only one of those MACs on the physical switch port or decide that only one of those macs is valid for the computer.

This setup is also used for Ipmi/bmc ports which "piggyback" on a server (eg: Dell R320).

What GLPI does do right now is decide that there much be an unrecorded hub attached - but the "mystery hub" cannot be attached to the computer. If one tries that, another "mystery hub" will be created in "unmanaged devices" on the next network+switch scan.

(In other words: a port can have 2 active macs, but not be a hub - and equally confusing, one of those macs might switch to another port - possibly on another machine and THAT is not a hub either)

[Stoatwblr]

Linux defines L2 aggregates and L2 aliases as "virtual" devices - it might help to add more fine-grained distinction into the definitions.

[Stoatwblr]

Per discussions and after some thoughts on the matter.

• L3 "devices" (L3 is a networking thing bound to a device and not really a device at all) are covered by aliases (and it should be made clearer that "alias" devices are L3 things)

• L3 "devices" should not inherit MACs from L2 unless explicitly set (the mac is usually dependent on the L2 device and will usually change if rebound to another link device.

• Non-physical L2 devices (link devices) can be covered reasonably well by renaming "aggregate" to "virtual" and allowing virtual devices to be chained from virtual devices (Bonds, vlans, mppp, etc are all virtual devices) - this saves having to create N-classes of device

• Physical devices have a physical MAC. This MUST NOT be rewritten if they are linked to a virtual device, but any apparent MAC written to the virtual(aggregate) device.

• In the case of "piggyback" devices (bmc or similar), these should be created as a physical device and linked to a parent physical device. in the case of a failover connection, they should be linked to both parent physical devices. Possibly some logic added to automate this if a "BMC" device is detected on the same phyiscal port as a server, but otherwise the admin will have to manually set this in the networkports section of the server.

• in the case of a failover IP it should be setup as a L3 alias and be able to be linked to BOTH parents (right now an alias can only be linked to one parent physical or aggregate/virtual device)

I know this changes the relational structure of GLPI network inheritance, but it should be do-able in a logical way.

VRRP and other high availability failover come with their own sets of problems.

• Ideally the HA IPs should be able to be definable as a "virtual machine" which is then linkable to parent systems.
• Alternatively they would need to be explicitly configured on every system which may carry them
  • in some cases here that's 200 addresses multiplied by 5-6 servers... it starts becoming a n^2 problem.

[Stoatwblr]

While working on #2787 I finally found the known XMLs and realised there are a lot more already recognised than are documented. Will play a little more.