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