Aggregated network interfaces (bond) aren't resolved

[GuidoWilden]

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

We have several machines (both Linux and Windows) that have LACP aggregated 10 Gbit/s network ports.
While they are recognised as such, no further information is collected, like which switch ports do they plug into etc..

Maybe not so much a bug but a feature request rather.

To reproduce

1. Create bonded/teamed port in either Windows or Linux
2. Run inventory

Expected behavior

I wish it was possible to interrogate the interfaces for switch port connections etc.

Operating system

Linux

GLPI Agent version

Nightly build (git version in additional context below)

GLPI version

Other (See additional context below)

GLPIInventory plugin or other plugin version

GLPI Inventory v1.3.5

Additional context

GLPI version 10.0.15, GLPI agent nightly build v1.8-git3ddbbd8e

[g-bougard]

Hi @GuidoWilden

can share the XML inventory and provide a snmpwalk output ?

The first question to answer will be to say if all required datas are provided or not by the agent.

[GuidoWilden]

Hi @g-bougard
Any specific syntax for the snmpwalk? The usual

snmpwalk -v 1 -c public -t 15 -Cc -On -Ox <IP_ADDRESS> .1

Does not gather a lot.

[g-bougard]

Don't you have any other access via SNMP v2c or SNMP v3 ?

[GuidoWilden]

When using v2c I get the following. (So really not much from a Linux host), using

snmpwalk -v 2c -c public -t 15 -Cc -On -Ox 10.120.10.113 .1

snmpwalk.txt.zip

[g-bougard]

To me, we can't extract ports from this snmpwalk. You should have some security on this device which limit reported oid via public community.

[GuidoWilden]

I managed to get the two for a Linux host. I am still battling Windows but will send them when I manage.
ldnaz-vfx3.xml.zip

snmpwalk_vfx3.txt.zip

[GuidoWilden]

Here the two files for a Windows host, however, the snmpwalk would not run without an error.
ldnaz-resolve2.xml.zip

snmpwalk_resolve2.txt.zip

[g-bougard]

Hello @GuidoWilden

sorry, was focused on the latest agent releases.

Indeed, my SNMP walk requests was for the switches computers are connected to. Indeed the connection information is retrieved from switches, not from computer inventory.

[GuidoWilden]

Hi @g-bougard,

No need to apologise. So is there anything else I can provide?

[g-bougard]

Yes,

you can provide the XML for the switches connected to that computers, and/or the related snmpwalk output to check if glpi-agent missed something to make the connection possible.

[GuidoWilden]

OK here the two files for one of the switches.
switch_snmpwalk.txt.zip
switch.xml.zip

[GuidoWilden]

What does not help with LACP on Linux: the two aggregated ports show only one of the two MAC addresses on the switch, as in both ports have the same MAC address as far as the switch is concerned. So I foresee a problem.

[g-bougard]

First of all, have you enabled the 161 port type import in GLPI ?

It seems on your switch the linux is connected to port-channel47 port which is of type 161, not imported by default:

        <PORT>
          <CONNECTIONS>
            <CONNECTION>
              <MAC>00:10:86:83:69:0c</MAC>
            </CONNECTION>
          </CONNECTIONS>
          <IFDESCR>port-channel47</IFDESCR>
          <IFINERRORS>0</IFINERRORS>
          <IFINOCTETS>3890404433</IFINOCTETS>
          <IFINTERNALSTATUS>1</IFINTERNALSTATUS>
          <IFLASTCHANGE>2 days, 02:53:32.51</IFLASTCHANGE>
          <IFMTU>1532</IFMTU>
          <IFNAME>port-channel47</IFNAME>
          <IFNUMBER>161</IFNUMBER>
          <IFOUTERRORS>0</IFOUTERRORS>
          <IFOUTOCTETS>3191139534</IFOUTOCTETS>
          <IFSPEED>10000000000</IFSPEED>
          <IFSTATUS>1</IFSTATUS>
          <IFTYPE>161</IFTYPE>
          <MAC>68:4f:64:fe:9c:be</MAC>
        </PORT>

I don't know if there's really a problem with the bond definition in linux. Is it possible the network port only takes the MAC of the active port and the other is just a backup ? Until the right mac is reported on a port connection, I don't see really a problem.

If you don't know how to enable 161 port type import, check #683.

[GuidoWilden]

Thank you I will try adding this port type definition but with regards to the MAC addresses we see the following on ifconfig

bond1: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        inet 10.120.10.113  netmask 255.255.254.0  broadcast 10.120.11.255
        ether 00:10:86:83:69:0c  txqueuelen 1000  (Ethernet)
        RX packets 160023710  bytes 14297602118 (13.3 GiB)
        RX errors 0  dropped 12  overruns 0  frame 0
        TX packets 1080237  bytes 216682782 (206.6 MiB)
        TX errors 0  dropped 34 overruns 0  carrier 0  collisions 0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 5c:60:ba:38:b6:4b  txqueuelen 1000  (Ethernet)
        RX packets 205802826  bytes 83262843121 (77.5 GiB)
        RX errors 0  dropped 12  overruns 0  frame 0
        TX packets 25278521  bytes 3127156046 (2.9 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xc4400000-c4420000  

enp9s0f2: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 5c:60:ba:38:b6:4e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens3f0np0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 00:10:86:83:69:0c  txqueuelen 1000  (Ethernet)
        RX packets 8217887  bytes 1958689841 (1.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1004500  bytes 198314232 (189.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ens3f1np1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 00:10:86:83:69:0c  txqueuelen 1000  (Ethernet)
        RX packets 151805823  bytes 12338912277 (11.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 75737  bytes 18368550 (17.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

However ethtool gives us:

ethtool -P ens3f0np0
Permanent address: 00:10:86:83:69:0c
ethtool -P ens3f1np1
Permanent address: 00:10:86:83:69:0d

I will run some more tests and report back.