"Invalid network mask /3" being reported incorrectly for VMWare vCenter

[ChrisC]

I keep getting the following warning:
"Invalid network mask /3 on interface "Device eth0 at 03:00.0 VMware - VMXNET3 Ethernet Controller", should be /24".

This is a VMWare vCenter VM on a VMWare host. I have checked it's network config via the vCenter interface, and the mask is definitely /24 and not /3 (and never has been!).

The invalid netmask rule could be useful, so I don't want to delete it.
I know I could try and filter it so it ignores the specific object, but other people might be having the same problem.
Any ideas why this might be happening? I guess it could be due to a regular expressing failing or is it a buggy SNMP implementation on the device itself?
The discovery is only happening via SNMP, I don't have an agent running on there.

Both Management Console and Server are Version 3.9.235, but this also happened on Version 3.9.178.

Thanks,

[Filipp Sudanov]

can you show snmpwalk for the following OIDs:

.1.3.6.1.2.1.4.20

.1.3.6.1.2.1.4.34

.1.3.6.1.2.1.4.32

[ChrisC]

Hi Filipp,
Thank you for the reply.

.1.3.6.1.2.1.4.20 returns nothing.

.1.3.6.1.2.1.4.34 returns the following:

.1.3.6.1.2.1.4.34.1.3.1.4.172.17.128.20 [INTEGER] = 2
.1.3.6.1.2.1.4.34.1.4.1.4.172.17.128.20 [INTEGER] = 1
.1.3.6.1.2.1.4.34.1.5.1.4.172.17.128.20 [OBJECT IDENTIFIER] = .1.3
.1.3.6.1.2.1.4.34.1.6.1.4.172.17.128.20 [INTEGER] = 1
.1.3.6.1.2.1.4.34.1.7.1.4.172.17.128.20 [INTEGER] = 1
.1.3.6.1.2.1.4.34.1.8.1.4.172.17.128.20 [TIMETICKS] = 0
.1.3.6.1.2.1.4.34.1.9.1.4.172.17.128.20 [TIMETICKS] = 0
.1.3.6.1.2.1.4.34.1.10.1.4.172.17.128.20 [INTEGER] = 1
.1.3.6.1.2.1.4.34.1.11.1.4.172.17.128.20 [INTEGER] = 5

.1.3.6.1.2.1.4.32 returns the following:

.1.3.6.1.2.1.4.32.1.5.1.1.4.127.0.0.0.8 [INTEGER] = 1
.1.3.6.1.2.1.4.32.1.5.2.1.4.255.255.127.0.24 [INTEGER] = 1
.1.3.6.1.2.1.4.32.1.6.1.1.4.127.0.0.0.8 [INTEGER] = 2
.1.3.6.1.2.1.4.32.1.6.2.1.4.255.255.127.0.24 [INTEGER] = 2
.1.3.6.1.2.1.4.32.1.7.1.1.4.127.0.0.0.8 [INTEGER] = 2
.1.3.6.1.2.1.4.32.1.7.2.1.4.255.255.127.0.24 [INTEGER] = 2
.1.3.6.1.2.1.4.32.1.8.1.1.4.127.0.0.0.8 [GAUGE32] = 4294967295
.1.3.6.1.2.1.4.32.1.8.2.1.4.255.255.127.0.24 [GAUGE32] = 4294967295
.1.3.6.1.2.1.4.32.1.9.1.1.4.127.0.0.0.8 [GAUGE32] = 4294967295
.1.3.6.1.2.1.4.32.1.9.2.1.4.255.255.127.0.24 [GAUGE32] = 4294967295

Hope that helps.
Not sure where 255.255.127.0 is coming from.... but that's not /3 either.
The attached picture is what I've set for the IP address details

---

[victor]

Hi!

There are few bugs that contribute to this problem. First is incorrect data reported by vCenter in ipAddressTable:

.1.3.6.1.2.1.4.34.1.5.1.4.172.17.128.20 [OBJECT IDENTIFIER] = .1.3

It should be either .0.0 or valid OID from ipAddressPrefixTable (.1.3.6.1.2.1.4.32). Combined with bug in NetXMS server that does not check for validity of this OID and just using last element (it should have done scan of ipAddressPrefixTable instead, as in .0.0 OID case) it produced /3 network mask (because in valid OID from ipAddressPrefixTable last element is prefix length).

Unfortunately just fixing this issue in NetXMS server is not enough, because ipAddressPrefixTable reported by vCenter is incorrect as well. OID

.1.3.6.1.2.1.4.32.1.6.2.1.4.255.255.127.0.24 [INTEGER] = 2

should have been

.1.3.6.1.2.1.4.32.1.6.2.1.4.172.17.128.0.24 [INTEGER] = 2

(with correct prefix as part of OID). I've checked on my vCenter - it returns exactly this incorrect value (255.255.127.0) no matter what actual subnet is.

I was able to add a workaround in server code for such situation - now server also attempts to scan inetCidrRouteTable for local routes and deduce correct prefix from there. It seems to work on my vCenter. This change will be included into next patch release.

Best regards,
Victor

[ChrisC]

That's great news Victor!
Thank you for the detailled explanation and the quick reply.

Hopefully you will be happy to know we are in the process of buying support from you

[ChrisC]

I've logged a support request with VMware, so I'll see what they say from their side