So, this one time, I discovered two network cards with identical MAC addresses.
During 1993, and a network transition from Token-Ring to 10-BaseT Ethernet, I had to deal with a rather unusual issue. The batch of network cards supplied contained two with duplicate MAC addresses burnt into them. Problems occurred with the two PC’s, but only once we’d finished the work.
How did I recover from this usually critical (and theoretically impossible) situation?
The situation
After a flood wiring of an office block to support a new AT&T Definity PABX, and to transition from Token-Ring to 10Base-T for reasons of cost, I led a team to replace the network cards during an evening in 100+ PCs.
We had a boot disk that would update the drivers and the various startup files on the clients. A previous downtime had prepared the three Novell Netware Servers for this changeover. (We’d need another downtime to recover the Token-Ring cards from them later.)
We had a batch of SMC EtherCard Plus 8013EWC cards which supported all the various combinations of Ethernet connection (AUI, BNC and RJ-45). I chose the adaptor on the basis that it had support for both 8 and 16-bit ISA interfaces, and that the MCA adaptor for the PS/2 architecture used the same driver software. (We had some PS/2 systems from an earlier acquisition.) The adaptors were initially designed and manufactured by Western Digital, but had been sold to SMC as part of WD’s restructuring during that time.
The process
I’d performed an analysis of the various devices in our estate and had determined that there would be no conflicts with the default configuration of the adaptors in our PCs. We made a change to the memory management pages to free the memory space needed for the network card, standardising this from the various Token-Ring configurations we had. So the process was simple.
- Card Preparation
- Remove card, and it’s plastic bubble case, from the extraneous packaging
- Attach RJ-45 patch cable to bubble container with tape
- Place card into a crate for each team member
- Before the card installation
- Setup three 3.5″ floppy disks with drivers and startup files (
AUTOEXEC.BATandCONFIG.SYS) with a batch file to install them. - Patch new Ethernet ports from panel to hubs
- Setup a diagnostic receiver for testing cards once installed
- Setup three 3.5″ floppy disks with drivers and startup files (
- Replacing the network cards (for each PC)
- Remove the monitor
- Unscrew the case screws
- Remove the lid
- Unscrew the Token-Ring DB-9 cable from the card
- Unscrew and remove the Token Ring card
- Note MAC address from the sticker on the card and PC Serial number on a sheet
- Install the new Ethernet card
- Replace the lid
- Connect RJ-45 cable from Ethernet card to desk socket
- Place monitor in its original position. (these were big CRT screens, so we all got a workout that evening)
- Power on the PC
- Insert the floppy disk
- Wait for the files to copy over
- Test the connection to the diagnostic responder
- Remove the floppy disk
- Reboot the machine
- Login to Netware
- Logout
- Power off the PC
- Signoff the PC
The problem
The ethernet cards are identified on the network by a MAC address. This uses an OUI identifier (00:00:C0 in the case of SMC), and a unique six-digit suffix (coded in hexadecimal and held on a PROM on the card.) These ensure that traffic sent to and from the network will only go to the device with that address.
When two devices have the same MAC address, communications between the devices are confused, as both devices will receive the data destined for each. In theory, there will never be two devices with the same MAC address, as processes during manufacture should prevent the issuing of duplicate addresses.
This didn’t happen with the batch of cards that we received. The two PC’s with the duplicate addresses if powered on and active together would not successfully log into the network. Tracking down the issue was a bit of a pain. But by taking special notice of the network card information as the NetWare ODI driver loaded I spotted that both devices were reporting the same MAC address. Cracking the lids on the PC’s and checking the stickers on the cards showed separate MAC addresses, so that part of the process worked.
There are two points in the list above I might have avoided this impossible issue. Did you spot the two locations where I could intercept the problem? I didn’t at the time.
Could I have discovered the problem beforehand?
Of course! As the problem occurred, we only needed to have created or simulated the problem beforehand.
I could have tested each possible pair of cards against each other using a cross-over cable (or a short segment of 10Base-2 cable).
I could have allocated cards in sequence in each box. Both cards would heve been assigned to the same engineer.
I could also have made sure that we noted the MAC address from an electronically derived version, rather than the one printed on the sticker on the back of the card.
Keeping the PC’s on until the end of the change would have meant that the second card would have been detected as soon as the login process would be attempted. (The diagnostics process would only send response packets to both cards. The one running the diagnostic test would correctly receive the packets. The other card would also receive them, but discard them as they would not make sense to it.
But as this is supposed to be an impossible situation, spending time doing the testing would not necessarily be the best use of time and resources.
Possible fixes that might be applied
We could have split the cards onto different routed segments, as the MAC address is significant only on the local Layer 2 segment. So the other side of a router, it wouldn’t matter if there was the same MAC address. However, we moved folks around the office, so it would always be possible to move them to the wrong side of the router and re-introduce the problem.
If the network card supported it, it could have been possible to change the MAC address in software. This facility was available with the Token-Ring network, and a locally-administered address could have been configured to overcome the problem. Unfortunately, the SMC EtherCard Elite didn’t support that capability.
And the best fix?
The best fix? The one I settled on was to replace the faulty cards with some from our spare stock. Then return the twin cards as faulty and get two unique cards as replacements.
It did take a bit of explaining to the tech support guy who was adamant that the situation we had was ‘impossible.’
