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.

  • Your description of the problem is limited to the phrase "seem to be having trouble". It would help a lot to have a more detailed description of what goes wrong when you try to do this. Jul 26 '13 at 21:13
  • 13
    I would return these useless devices to "the production line" with a suggestion to stick to making... well... anything else except network devices, while you take your business elsewhere. A company stupid enough to do this has probably done lots of other dumb things with/to these devices too.
    – Rob Moir
    Jul 26 '13 at 21:36
  • 2
    What @RobM said. The proper thing to do was to return the entire batch as defective. Jul 26 '13 at 21:44
  • 2
    Take a wrench to the kneecaps of the idiot who deliberately caused the MAC collision (chances of it having happened by accident are ludicrously low).
    – Shadur
    Jul 27 '13 at 8:56
  • 2
    Also, concur with @RobM. The manufacturers are clearly idiots. Take your business elsewhere -- there is NO excuse for people who make networking hardware to screw up like this.
    – Shadur
    Jul 27 '13 at 8:58

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.

  • That TFTP bit sounds like it will solve this problem quite nicely. I forgot that TFTP can put files too!
    – Anthony A.
    Jul 29 '13 at 12:44

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.


"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.)


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.


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.

  • 2
    In keeping with the spirit of the other answers and comments I think you ought to call the OP an idiot. "When in Rome" as they say... :)
    – joeqwerty
    Jul 26 '13 at 22:03
  • LOL! I'm breaking the bad news that he probably really IS going to have to set them all up one by one (if he doesn't return them, which might not be an option--my suspicion is that someone higher up has foisted these devices on him). So, you know. Sympathy points. :) Jul 26 '13 at 22:08

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.

  • ... but you have to manualy configure each host's IP!?
    – F. Hauri
    Jul 27 '13 at 6:33
  • 2
    Can you even buy a hub anymore? Jul 27 '13 at 8:40
  • @JonRhoades No you can't. They are all dumb, unmanaged switches these days. Have to be in order to properly support 100 Mb/s and 1 Gb/s. Ethernet specs make it mandatory to be able to switch back to lower speeds (10 Mb/s and/or 100 Mb/s in case of Gb/s switches). This requires the ability to buffer 1 full packet, hence has to be technically at least a bridge.
    – Tonny
    Aug 19 '13 at 20:26
  • … which is exactly why I keep a 100Mbps hubs around - very useful for easily watching traffic :D
    – MikeyB
    Aug 19 '13 at 20:36

"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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.