ipdiscover and hosts with bonded interfaces issue

[Daniel Rich]

(originally posted in the forums: http://forums.ocsinventory-ng.org/viewtopic.php?id=13196)

The OCS Inventory ipdiscover code seems to have issues with hosts that have bonded interfaces. For almost all of my servers with bonds, I'm seeing them both in the inventory *and* in ipdiscover, with the same MAC address in both. For example, one of my LDAP servers has the following in the interface inventory:

  Description Type Speed MAC address Status IP address Netmask Gateway Network number DHCP IP
  bond0 Ethernet F4:CE:46:B9:3B:F4 Up 10.110.10.203 255.255.255.0 10.110.10.1 10.110.10.0
  eth0 Ethernet F4:CE:46:B9:3B:F4 Up 10.110.10.1 0.0.0.0 10.110.10.149
  eth1 Ethernet F4:CE:46:B9:3B:F4 Up 10.110.10.1 0.0.0.0

yet also shows up in ipdiscover for the 10.110.10 subnet with a duplicated entry (with the hostname replaced):

  IP address MAC address Netmask Date DNS name Delete Register
  10.110.10.203 f4:ce:46:b9:3b:f4 (Hewlett Packard) 255.255.255.0 2013-08-14 14:03:27 hostname.example.com
  10.110.10.203 f4:ce:46:b9:3b:f4 (Hewlett Packard) 255.255.255.0 2013-08-14 14:03:27 hostname.example.com

Since I see this on most of my hosts with bonds, I'm assuming it's happening because it finds the same MAC on multiple interfaces and doesn't know how to handle it.

Here is the ipconfig output from this host for the affected interfaces:
bond0 Link encap:Ethernet HWaddr F4:CE:46:B9:3B:F4
          inet addr:10.110.10.203 Bcast:10.110.10.255 Mask:255.255.255.0
          inet6 addr: fe80::f6ce:46ff:feb9:3bf4/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
          RX packets:3929803787 errors:1 dropped:0 overruns:0 frame:1
          TX packets:4294474859 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2259212304130 (2.0 TiB) TX bytes:3370758106988 (3.0 TiB)

eth0 Link encap:Ethernet HWaddr F4:CE:46:B9:3B:F4
          UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
          RX packets:2355909712 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4293162724 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1403107466117 (1.2 TiB) TX bytes:3370593081217 (3.0 TiB)
          Interrupt:138 Memory:f8000000-f8012800

eth1 Link encap:Ethernet HWaddr F4:CE:46:B9:3B:F4
          UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
          RX packets:1573894075 errors:1 dropped:0 overruns:0 frame:1
          TX packets:1312135 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:856104838013 (797.3 GiB) TX bytes:165025771 (157.3 MiB)
          Interrupt:146 Memory:f6000000-f6012800

I was seeing this on 2.0.5 and I'm still seeing it in 2.1RC1. The host is still running the 2.0.5 agent as I haven't had a chance to upgrade all of my agents yet, but since this is an ipdiscover issue I wouldn't expect the agent to have any effect on it.

[Daniel Rich (drich-u)]

This is still present in 2.1.1.

IP discover shows:
IP address MAC address Netmask Date DNS name Delete Register
10.110.48.100 D4:85:64:4E:17:E0 (Hewlett Packard) 255.255.240.0 2014-07-09 01:27:42 warkworth.xxx.com
10.110.48.100 D4:85:64:4E:17:E0 (Hewlett Packard) 255.255.240.0 2014-07-09 01:27:42 warkworth.xxx.com

Yet warkworth is a in OCS, it shouldn't be a non-identified host.

In the DB:
mysql> select * from networks where macaddr='D4:85:64:4E:17:E0';
+--------+-------------+-------------+----------+---------+-------+-------------------+--------+---------------+---------------+-------------+-------------+---------------+------------+
| ID | HARDWARE_ID | DESCRIPTION | TYPE | TYPEMIB | SPEED | MACADDR | STATUS | IPADDRESS | IPMASK | IPGATEWAY | IPSUBNET | IPDHCP | VIRTUALDEV |
+--------+-------------+-------------+----------+---------+-------+-------------------+--------+---------------+---------------+-------------+-------------+---------------+------------+
| 372661 | 4750 | bond0 | Ethernet | | | D4:85:64:4E:17:E0 | Up | 10.110.48.100 | 255.255.240.0 | 10.110.48.1 | 10.110.48.0 | | 0 |
| 372668 | 4750 | eth0 | Ethernet | | | D4:85:64:4E:17:E0 | Up | | | | | 10.110.10.149 | 0 |
| 372669 | 4750 | eth1 | Ethernet | | | D4:85:64:4E:17:E0 | Up | | | | | | 0 |
+--------+-------------+-------------+----------+---------+-------+-------------------+--------+---------------+---------------+-------------+-------------+---------------+------------+
3 rows in set (0.00 sec)
mysql> select * from netmap where mac='D4:85:64:4E:17:E0';
+---------------+-------------------+---------------+-------------+---------------------+-------------------+
| IP | MAC | MASK | NETID | DATE | NAME |
+---------------+-------------------+---------------+-------------+---------------------+-------------------+
| 10.110.48.100 | D4:85:64:4E:17:E0 | 255.255.240.0 | 10.110.48.0 | 2014-07-09 01:27:42 | warkworth.pdi.com |
+---------------+-------------------+---------------+-------------+---------------------+-------------------+
1 row in set (0.00 sec)

[Daniel Rich (drich-u)]

I think this is an ocsreports issue, not the agent. It looks like the correct data is in the database, just not being presented properly by ocsreports.

[Arthur Jaouen (arthur-z)]

Fixed with commit #885 (OCSReports candidate for 2.1.2), could you confirm this bug is not present anymore ?

[Daniel Rich (drich-u)]

Arthur, is 885 really the correct commit? I'm only seeing a fix for console links opening in the right window: http://bazaar.launchpad.net/~ocsinventory-core/ocsinventory-ocsreports/trunk/revision/885

That's assuming I'm looking at the right thing. It's 0645 and I'm only half awake (and learning to hate browsing code in launchpad)

[Daniel Rich (drich-u)]

aha, found it: http://bazaar.launchpad.net/~ocsinventory-dev/ocsinventory-ocsreports/stable-2.1/revision/885

[Daniel Rich (drich-u)]

I just applied the patch and it looks great! Thanks for the quick fix.

I am now only seeing devices that aren't in the hardware table.

[Arthur Jaouen (arthur-z)]

OK, nice ! We'll publish the 2.1.2 right away then !