What's a good way to handle multiple devices with the same MAC address on one network?

Question

The devices I'm working with come off the production line all set to the same MAC address. I can set each one to have their own static IP, and I'm wondering if there would be a way to connect them to the network at the same time in order to transmit configuration data (including a new MAC address) to them?

I've got a Cisco SF 200-24 "Smart Switch", and so far I've tried setting each port on the switch to its own VLAN (mode: access), with another port set to be on all of the VLANs as a trunk line to an upstream server I'd like the units to talk to.

Right now I've set each device to have a static IP on their side, but I seem to be having trouble getting them to talk to the upstream computer through the trunk line. I don't expect (or want) the devices to be able to talk to each other, just the server connected to the trunk port.

Is what I'm doing feasible with the equipment I have, or am I going to be stuck configuring each one individually?

"You're an idiot, don't connect things with the same MAC to the same network" may also be an acceptable answer here, but I'm hoping there might be a more interesting one.

EDIT: Hah, people are passionate about their networking hardware on here. I suppose I shouldn't be surprised. I've inherited this lovely legacy design, and I get to put up with this until I can get a new firmware rev to our manufacturer. Thanks for participating, folks.

Answer 1

I had to "fix" the same situation in one of our production plants about 6 years ago.

I got to tell the production engineers that they were idiots :-).
In their defense: This was the first networking product ever and R&D hadn't exactly thought the production ramifications through.

There was no way around it then (and still isn't now).
Each device had to be hooked up individually to a PC to reconfigure the MAC. (Later it turned out we needed to do this anyway because after some bugfixes had been done by R&D each device needed new firmware to be flashed as well.)

On later series the dev's made the process as painless as possible: The standard firmware got a very basic minimal boot-loader that would boot a TCP/IP stack with a hardcoded fixed ip-address. This would startup and attempt to TFTP the full firmware image from another hardcoded ip-address. When done a second file containing the unique MAC would be pulled from the TFTP server and flashed in the device.
After that the device reboot, comes up with the full flash-image which does DHCP for it's ip-address. When the dhcp address is acquired it uploads a small file with it's own mac-addres to the TFTP server as confirmation that it is done.

The PC controlling this runs a DHCP server and a TFTP server. And a control application that prepares the file with the mac-address.
After the device has successfully uploaded it's confirmation file the control-application gives the operator the thumbs up to plug in the next device and it writes the next mac-address to the file.
(The application knows how long it normally takes to download and flash. It there is too much time between the first TFTP transfer and the upload of the confirmation file the operator is notified hat the device is probably faulty. Build-in quality test for the network stack.)
The Flash over LAN option is also a feature which the customer can use to upgrade firmware.
It had to be implemented anyway so we might as well use it to deal with the "how to get the initial config in there" issue.

PS. The DHCP server provides a custom DHCP option to identify itself to the device. In a customer LAN the DHCP will obviously NOT do that so when our devices see a "normal" DHCP server they just continue booting without attempting to upload the confirmation file.

Answer 2

You're an idiot, don't connect things with the same MAC to the same network.

;-)

Seriously, a MAC address is absolutely fundamental to the way that the IEEE 802.3 networks work. With multiple devices on the same physical bit of Ethernet cable with the same MAC, each receiver will respond with a "that's me" when an ARP packet flies by.

So, you have to maintain separate physical bits of wire. You mention VLANs. These operate in layer 2, which is the same place as Ethernet MAC addresses (albeit in the Logical Link Control, or LLC, sub-layer).

So, yes, VLANs will do the trick. However, you do need to grant unique layer 3 (IP) addresses to your devices, and this may be a challenge, as you won't be able to use DHCP.

In short, back to my (your) first line.

Answer 3

"You're an idiot, don't connect things with the same MAC to the same network"

(you said that'd be ok) :)

The correct answer to your problem is to fix the manufacturing process to assign different MAC addresses on the devices, either sequentially or however (date mfg'd then a unique #, etc.)

Answer 4

Fire your manufacturer.

I'm serious. This isn't even an amateur hour mistake, this is dangerous levels of utter incompetence.

It's like a bank discovering that the company that prints the physical bills delivered several million bills all with the same sequence number, or a car manufacturer learning that the latest batch of license plates all had the same plate number on them.

It's that basic a mistake; you do not want to be responsible for finding out how else they turn out to have screwed up.

Return the entire batch, demand your money back, and find someone competent to supply your networking hardware.

Answer 5

Rather than tell you you're an idiot--even though you said it's okay--I'd rather tell you why you shouldn't put things with the same MAC on the same network.

SystemA wants to talk to SystemB. SystemA gets SystemB's IP address and tries to determine a route between the two of them. If SystemA and SystemB are on the same network, SystemA needs SystemB's MAC address to send SystemB the packet. SystemA gets this information with a broadcast ARP message and caches this information in the ARP table.

(If SystemA is in California and SystemB is in New York, it finds a route that sends the packet over to New York, and the router/switch connected to SystemB needs to know SystemB's MAC address so it can send the packet over. So the MAC address is still being used, but SystemA doesn't need to know about that. SystemA just needs to know the MAC address of its own router.)

So, basically: when you put your devices with the same MAC address on the network, anything trying to talk to those devices is going to get confused when multiple devices say, "That's me!" It sounds like you're trying to get around this with the VLANs, but...

I would recommend against it. I'm just saying.

Answer 6

This may be the only time I'll ever say this.

You want to replace your switch with a hub.

This should allow you to talk to each device without the packets getting filtered by the CAM table on the switch.

Answer 7

"A media access control address (MAC address) is a unique identifier assigned to network interfaces for communications on the physical network segment."

Politely suggest to the production line manager that he looks up the definition of a "MAC address" -perhaps before making some adjustments to the manufacturing process.

For all we know, it could be a defect in the process that they are not aware of (rather than by design), but something needs to be done as this basic mistake will undermine confidence in the product and lead to avoidable complications.

This problem will be much easier to fix at the manufacturing end, rather than struggling to work around after deployment of the problematic devices.

Every once in a while devices sometimes appear on a network with identical MACs, but this is a rarity (and often easily solved by swapping out a cheap NIC.) For an entire batch to have the same MAC would pretty much put them in the "defective" category (as far as some people are concerned) even though, considered individually, they would not appear to be defective at all.