what about 48 bits?

Patrick W. Gilmore patrick at ianai.net
Mon Apr 5 21:26:53 UTC 2010


On Apr 5, 2010, at 5:08 PM, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 05 Apr 2010 16:36:26 EDT, Jon Lewis said:
> 
>> Since they only really need to be unique per broadcast domain, it doesn't 
>> really matter.  You can I could use the same MAC addresses on all our home 
>> gear, and never know it.  For manufacturers, it's probably reasonably safe 
>> to reuse MAC addresses they put on 10mbit ISA ethernet cards...if they 
>> were a manufacturer back then.
> 
> Until you buy 25 cards with the same MAC address and deploy them all across
> your enterprise

I don't think that's possible given that Jon was suggesting.

I'm 3COM, I made ISA 10Base2 / 10Base5 cards in the 90s.  I run out of MAC addresses.  Instead of going to get more - if I even can! - I recycle those MAC addresses, figuring the 10GE PCI-X cards I'm making now have 0.000% chance of being on the same b-cast domain as one of those old ISA cards.

Even if I am wrong, the max collision possibility is 2, not 25.

Seems reasonable.  If I am wrong, I'll apologize profusely, refund the price of the 10G card I gave the customer, ship him a new one free, so he gets two he can use (assuming he has more than one b-cast domain), which would probably make the customer happy.  Wanna bet how many times 3COM would have to ship free 10GE cards?

-- 
TTFN,
patrick


> - the problem can go un-noticed for *weeks* as long as two
> boxes aren't squawking on the same subnet at the same time(*).  Of course, you
> never stop to actually *check* that two cards in different machines have the
> same address, because That Never Happens, and you spin your wheels trying to
> figure out why your switching gear is confused about the MAC addresses it's
> seeing (and it always takes 3 or 4 tickets before one actually includes the
> message "Duplicate MAC address detected" in the problem report..)
> 
> (*) And as Murphy predicts, whenever it happens, one of the two offenders will
> give up in disgust, power off the machine, and go on coffee break so the arp
> cache has timed out by the time you start trying to work the trouble ticket. ;)
> 
> (Yes, we're mostly older and wiser now, and more willing to include "the damned
> hardware is posessed by an Imp of Perversity" in our troubleshooting analysis.
> Had an SL8500 tape library last week that reported 'Drive State: Unpowered' and
> 'Drive Status: Not Communicating' and still reported 'Drive Health: Good'.
> 





More information about the NANOG mailing list