On Apr 5, 2010, at 5:08 PM, [email protected] 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'. >
