Linux/Networking/VMware: Snmpwalk MAC Address Missing 0s

A few days ago I was looking for a quick way to retrieve MAC address information from servers to map ports in a switch cluster. I figured I would share a few gotchas that might not be well known to people that do not have a background working with SNMP. Snmpwalk is a command line open-source utility for Linux. I am sure there is a port for Windows, but for the scope of this writing I am sticking to the Linux version.

The following example will show how to query a standard Linux based server running SNMP with version 1 queries allowed. I am passing the “ifPhysAddress” parameter to return only the interface(s) MAC addresses.
snmpwalk basic usage

USAGE: snmpwalk [OPTIONS] AGENT [OID]

Below is specifying version 1, community string “PUBLIC”, server to query “dbserv01.testdomain.com”, and information to return “ifPhysAddress”

root@testbox01:~# snmpwalk -v 1 -c PUBLIC dbserv01.testdomain.com ifPhysAddress
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.2 = STRING: 0:12:39:65:36:28
IF-MIB::ifPhysAddress.3 = STRING: 0:12:39:65:36:28
IF-MIB::ifPhysAddress.4 = STRING: 0:12:39:65:36:28
IF-MIB::ifPhysAddress.5 = STRING: 0:0:0:0:36:28

Above shows all the listed MACs that can be referenced by SNMP. As you can see, the same MAC “0:12:39:65:36:28″ is listed 3 times. This typically means that the network interfaces are bonded.

Below shows the actual interface information on the queried Linux server. As noted, the interfaces are bonded (bond0), and the MAC address (HWaddr) listed is the same as what was retrieved by snmpwalk.

[root@dbserv01 ~]# ifconfig
bond0     Link encap:Ethernet  HWaddr 00:12:39:65:36:28
          inet addr:127.1.1.182  Bcast:127.1.1.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:1033814138 errors:0 dropped:0 overruns:0 frame:0
          TX packets:833777834 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1051206111974 (979.0 GiB)  TX bytes:602216674869 (560.8 GiB)

eth0      Link encap:Ethernet  HWaddr 00:12:39:65:36:28
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:1025047842 errors:0 dropped:0 overruns:0 frame:0
          TX packets:833777834 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1050502485293 (978.3 GiB)  TX bytes:602216674869 (560.8 GiB)
          Interrupt:193 Memory:e4000000-e4012100 

eth1      Link encap:Ethernet  HWaddr 00:12:39:65:36:28
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:8766296 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:703626681 (671.0 MiB)  TX bytes:0 (0.0 b)
          Interrupt:193 Memory:e2000000-e2012100

Here’s the main “gotcha”. Snmpwalk shows the MAC as “0:12:39:65:36:28″, but ifconfig on the local server shows “00:12:39:65:36:28″. For better comparison, both are listed again below:

0:12:39:65:36:28
00:12:39:65:36:28

As you will probably see, a “0″ is missing. This is not a true issue, but a design in SNMP. Most applications will auto correct/translate this. Of course, some do not.

Here are a few more examples

IF-MIB::ifPhysAddress.2 = STRING: 0:13:99:65:c:80
IF-MIB::ifPhysAddress.3 = STRING: 0:13:99:65:c:81

Each one of the above also has “0″s removed.

0:13:99:65:c:80
is really
00:13:99:65:0c:80

I think the point has been made. “0″s are removed from all fields (“:” separates the fields) if it is the first character. So “00″ is displayed as “0″, “0c” displayed as “c”, etc.

The best information that I have found on this is that each field represents a byte. Logically, 01 is the same as 1, 0d is the same as d, and so on. Also, remember that bonded interfaces will also list the same MAC on all interfaces.

This will be the same on most Linux/Unix based distributions. I was able to successfully retrive MAC information from Linux servers, DataDomain appliances(RedHat based), and NetApp NAS (BSD based).

Same results when running a check on a VMware ESX server

root@testbox01:~# snmpwalk -v 1 -c PUBLIC vmserv01.testdomain.com ifPhysAddress
IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.2 = STRING: 0:1a:54:eb:12:96
IF-MIB::ifPhysAddress.3 = STRING: 0:1a:54:eb:12:94
IF-MIB::ifPhysAddress.4 = STRING: 0:13:26:84:7a:26
IF-MIB::ifPhysAddress.5 = STRING: 0:13:26:84:7a:27
IF-MIB::ifPhysAddress.6 = STRING: 0:13:26:84:7a:24

Notes: This is not an issue/design on all SNMP clients or daemons. Just don’t be freaked out if you stumble across this. Most SNMP clients/MIB browsers automatically add in the 0s that are left out.

~ by Kevin Goodman on May 5, 2009.

3 Responses to “Linux/Networking/VMware: Snmpwalk MAC Address Missing 0s”

  1. Great post! Just wanted to let you know you have a new subscriber- me!

  2. Does my mac adresse change if I upgrade my computer with some other hardware? For example change the graphic card?

  3. Your network (ethernet) MAC address should only change if you replace the network interface with new ones. Your local ports on the motherboard will stay the same unless you replace your motherboard. Same with add on network cards. So if you did not replace/add the actual network adapters or motherboard, they would be the same.

Leave a Reply