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.
Best Answer
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.