[134256] in North American Network Operators' Group
The tale of a single MAC
daemon@ATHENA.MIT.EDU (Graham Wooden)
Sat Jan 1 22:34:52 2011
Date: Sat, 01 Jan 2011 21:33:46 -0600
From: Graham Wooden <graham@g-rock.net>
To: <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi there,
I encountered an interesting issue today and I found it so bizarre =AD so I
thought I would share it.
I brought online a spare server to help offload some of the recent VMs that
I have been deploying. Around the same time this new machine (we=B9ll call i=
t
Server-B) came online, another machine which has been online for about a
year now stopped responding to our monitoring (and we=B9ll name this
Server-A). I logged into the switch and saw that the machine that stopped
responding was in the same VLAN as this newly deployed, and then quickly
noticed that Server-A=B9s MAC address was now on Server-B=B9s switch port.
=B3What the ...=B2 was my initial response.
I went ahead and moved Server-B=B9s to another VLAN, updated the switchport,
cleared the ARP, and Server-A came back to life. Happy new year to me.
So =AD here is the interesting part... Both servers are HP Proliant DL380 G4s=
,
and both of their NIC1 and NIC2 MACs addresses are exactly the same. Not
spoofd and the OS drivers are not mucking with them ... They=B9re burned-in =AD
I triple checked them in their respective BIOS screen. I acquired these tw=
o
machines at different times and both were from the grey market. The =B3What
the ...=B2 is sitting fresh in my mind ... How can this be?
In the last 15 years of being in IT, I have never encountered a =B3burned-in=B2
duplicated MACs across two physically different machines. What are the
odds, that HP would dup=B9d them and that both would eventually end up at my
shop? Or maybe this type of thing isn=B9t big of deal... ?
-graham
