Bug: Linux bond handling is broken

[Stoatwblr]

If fusioninventory-agent runs a local inventory on a linux system, then bonds and bondx.n (vlans) or bondx.n:Z (ipaliases on vlans) are counted as physical ethernet devices when they are not.

Bonds are aggregate devices, (usually) composed of several ethernet devices.

The same problem happens for ethN.Y or ethN:Z virtual devices.

any device with a "." in the name (eg eth0.500) is a tagged vlan and needs to be treated as a an alias port linked from the parent device.

In the same way anything with ":" in it is an ipalias and should be an alias port too.

Yes, this really does mean that bond0.500:50 is an alias device, running on top of an alias device on top of an aggregate device

It also appears that this is breaking network mapping.

Because all ports of a bond/ethernet trunk have the same MAC, and are on different ports of the same switch (which will also be bonded/trunked), this seems to confuse the logic used for mapping and results in bogus "hub" devices appearing randomly across the network.

[Stoatwblr]

Some data for ddurieux

there is useful stuff in /sys/class/net , /proc/net/bonding, /sys/devices/virtual/net/ (where bonding. vlan ipaaliases and loopback interfaces live) /sys/devices/*/net/ (where the physical devices are found) and /proc/net/vlan

1: Ethernet devices can have any name. Whilst they have traditionally been "eth{0-N}", new names are showing up in newer distros. (eg "eno{1-N}" and naming based on the NIC's PCIe channel/port)

They can also be renamed dynamically.

• [devicename] - implies an untagged vlan

For GLPI purposes, this could be an ethernet device...... but it would be safer to make it an aggregate device on top of the physical ethernet device. (ie, the configured IP address being an aggregate interface on top of the physical ethernet one)

• [devicename].[number] - is a tagged vlan where the number is the vlan number.

For GLPI purposes, this is an alias device on top of the parent aggregate device. If there is no [devicename] then one should be created in GLPI as a placeholder with no IP/mac details.

• [devicename]: {alphanumeric} is a secondary IP address (ipalias).

This is also an alias device. f there is no parent entity then it should be treated as above.

It might sit on top of a Vlan interface such as eth0.505:foo

Effectively, there are implied . and : characters on every configured network device. - eth0 with IP 1.2.3.4 could be thought of as "eth0.: IP 1.2.3.4 on top of physical device eth0"

2: Bonds (see /sys/devices/virtual/net and /proc/net/bonding/)

Bonds are composed of one or more physical devices. They can have various operating modes but in general all slave physical interfaces are assigned the same MAC address

A bond can have an explicitly set MAC address, but if this is not defined, then it will take the MAC of the first interface it enslaves and assign that to the other interfaces. The order of interface discovery cannot be guaranteed, so the effect is that the bond may take any MAC belonging to one of the slaves.

Bonds are (for obvious reasons) an aggregate device.

as an example of how complex it can get, on one of my systems, I have the following setup.

eth0 } eth1 } 10GE0 } 10GE1 } --- Bond0

bond0 - 1 ip address defined, with 4 secondary addresses (bond0 , bond0:1 , bond0:2 , bond0:3 , bond0:4) bond0.3000 - 1 ip address bond0.3001 - 1 ip address bond0.3002 - 1 ip address bond0.3003 - 1 ip address bond0.3004 - 1 ip address

bond0.500 - 3 IP addresses defined (bond0.500:2 , bond0:500:3 , bond0.500:10.0.0.0_24)

Adding to the confusion: Whilst a bond has a single MAC address and will (usually(*)) connect to a bond on the switch, some NICs will identify themselves at hardware level to the switches using their original MAC address. I see this with things like Intel and Emulux converged protocol adaptors. The switch therefore sees 2 macs attached to the port

(*) Most bonding is LACP. Linux supports failover and round robin types which may or may not connect to bonded switch interfaces.

See https://www.kernel.org/doc/Documentation/networking/bonding.txt (the section starting "mode")

When looking at bonds, the list of slaves and their hardware MACs is listed in /proc/net/bonding/[devicename], and you can also get the hardware MAC using "ethtool -P [slave-devicename]" (older versions of ethtool do not support this switch)

Using ifconfig and related tools on a bond slave will give the MAC address of the bond, not of the slave device.

[mathieumd]

This bug is still present with FI-agent 2.6 on Ubuntu Jammy 22.04 LTS with a bond interface in active-backup. It's a shame, because of this, we cannot use GLPI to connect interfaces to their corresponding switches :disappointed:

2: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:75:35 brd ff:ff:ff:ff:ff:ff permaddr yy:yy:yy:yy:32:10
    altname enp2s0f0
8: ens3f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:75:35 brd ff:ff:ff:ff:ff:ff permaddr zz:zz:zz:zz:ff:98
    altname enp8s0f0
12: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:75:35 brd ff:ff:ff:ff:ff:ff
    inet 10.2.0.2/24 brd 10.2.0.255 scope global bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::wwww:xxxx:xxxx:7535/64 scope link 
       valid_lft forever preferred_lft forever

# /etc/netplan/00-installer-config.yaml
network:
  bonds:
    bond0:
      addresses:
      - 10.2.0.2/24
      gateway4: 10.2.0.1
      interfaces:
      - eno1
      - ens3f0
      nameservers:
        addresses:
        - 10.1.0.1
        - 10.1.0.2
        search:
        - example.com
      parameters:
        mode: active-backup
  ethernets:
    eno1: {}
    eno2:
      dhcp4: true
    ens3f0: {}
    ens3f1:
      dhcp4: true
  version: 2