network interfaces not detected correctly, plus BMC/IPMI detection (bogus/ephemeral hubs) #640
Comments
In my opinion: IP addresses should be treated as "alias" devices so they can be dynamically shifted between physical/aggregate devices as required. If this is not done the database ends up with a LOT of needless duplicate IP entries over time |
|
See comments on the Netdisco importation and xml extension thread. It looks like part of the problem I'm seeing is due to the fact that some of the systems here have configured IP addresses on [eth0|bond0].vlan or [eth0|bond0]:alias without putting anything on the bare eth0 or bond0 entries - that utterly breaks the XML, but even when (mostly) sane XML is being sent from the computers, entries are wildly wrong in GLPI with ifindexes ignored and bonds not created properly even though they're sent in the right format.. The existing Network.pm can't cope with that scenario. Having said that, use of the "ip" command and (on linux) of /sys/class/net is suboptimal. To explain: ip "link" - shows the link devices rather than network addresses. Even better than that is the oneline format: Doesn't seem like much? Let's try it on another box: And where it really comes into its own is when you use it for address display: You can see that this does show the link devices in parseable format next to the L3 network addresses (and the ifindex that they're associated with) On to /sys/class/net - Linux/Network.pm has most of the right ideas, but then goes offcourse in a few others. First of all, this area only holds link(L2) devices, and you can tell real vs virtual ones apart pretty easily: For the most part you don't actually need "ip" or "ifconfig" to get the physical interfaces. It nicely gives you a list of bonding masters and each bond has a list of slaves. Each slave keeps its hwaddr on file (no need to mess with ethtool) And: this is where it gets to be fun: Each port has a ifindex AND an iflink: An ifindex is just like you'd expect on a switch - it enumerates the ports. The iflink matches the ifindexes for PHYSICAL devices (Bonds are counted as a physical device because they're enhancing bandwidth). What that means is that there's little need to call external programs, except to get the IP addresses (there's nothing for them in /sys/ or /proc/) If all L3 addresses are considered aliases, then all they need is for a pseudo-index to be created (incrementing from the top of the ifindex range would do fine) and be linked back to the parent ifindex. The current jumping around trying to find "." or ":" in an network name entry is unnecesary If you only want to do that for explicit ":" entries then you'll need to add extra logic - and I really don't recommend that as it's unnecessary extra complexity to make things "easier" in simple networks - at cost of making things MUCH harder to adjust mindsets as networks grow. It's better to treat all L3s as aliases and keep it consistent. It will make database relationships easier too - right now there are bogus network names for the same IP addresses popping up all over the place and it's hard to administer/track. In the same way, "aggregates" should be renamed to "virtual" and all virtual devices placed here - and these need to be able to linked to each other, which GLPI currently doesn't allow (ie: ip addresses linked to bond.vlan linked to bond, linked to multiple ethernets). NB: MAC addresses assigned to ethernet ports MUST NOT be changed by GLPI as seen in network scans and net-inventory (change the virtual, and if necessary, create a virtual interface) "Piggybacking"(*) BMCs are a pain. Whilst a physical device (and actually a separate physical computer even though on the same board as the server) i think the best way of handling them is to declare them as "virtual" for networking purposes (they're a "ghost in the machine" after all) and attach them to the ethernet devices that they piggyback on. Currently when GLPI encounters them it creates a "Ghost" unmanaged hub - which cannot be attached to the computer. If you do so, it will be depopulated and a new "Ghost" hub created on the next network scan. (*) These are separate ethernet devices which parasitically attach to the main computer's ethernet tranceivers to save a few cents in connection hardware. Whoever came up with THAT idea should be thoroughly scrubbed with a lemon zester and then dipped in Isopropanol. Until GLPI is updated to handle virtual device chaining properly, the only practical way of creating "Bond.vlan" entries safely is to treat each one as a separate aggregate attached to the same ethernet ports. If this is not done then links get smashed at every network scan. I'll try and dig up how best to approach network port scanning in Free/PCBSD too. |
Per IRC discussion:
On linux systems (at least):
A bond may have an explicitly defined mac address, or may pick up any one of the ethernet device's macs (first one to be detected wins the race)
Adding to the confusion, if the device is a server and has a BMC/IPMI, the ethernet and MAC address of that device is frequently "piggybacked" on one of the computer's physical interfaces via a "vampire tap"
This has the effect of making it look like there is a hub present that may appear/disappear frequently.
The text was updated successfully, but these errors were encountered: