Invalid Serial Number

i can confirm this issue also occurs when using Link Aggregate, workaround is to destroy the aggregate and just use one ethernet port thereby cutting the throughput from 2GB to 1 GB...

Has anyone found a work around that allows both NICs to be active?
Classes start in two weeks and I have a VM running win 2003 AD on the second NIC that I'll need to run for some labs.

I have found the opposite to be true: So long as there aren't two or more IPs in the same subnet, it doesn't matter if a LACP bond is used and how many NICs comprise any one particular IP (so long as only one IP is used). A client has a PCI-e board with 6 NICs which we bonded into a single 6-NIC pipe via LACP. We used that 6-NIC pipe with one IP address and turned off our two MLB NICs as a workaround for this issue. Interestingly enough, this new Xserve was running fine with 3 unique IPs on the same subnet (2 x single NICs and 1 x 6-NIC LACP-bonded-pipe) until we had to reinstall Leopard due to badly corrupted web services. I think my "mistake" was to have tried to configure all the interfaces at the initial setup after reinstallation of Leopard Server (we had initially activated only one NIC to begin with). Once we get a chance, we are going to try setting up all services and installing all upgrades first before creating the virtual LACP interface and activating the 2nd MLB NIC to see if this will work.

Hi

How odd? I can confirm the issue does not occur when using Port Trunking. Updated to 10.5.8 from 10.5.4. Never saw a problem.

Perhaps there's something else going on?

Tony

How many IPs did you have active when you upgraded? I vaguely recall that I originally only had one NIC activated with an IP address when my Xserve got upgraded to 10.5.8. It was ony after that it was already at 10.5.8 that we began activating the 2nd MLB NIC and crafting and activating he 6-NIC LACP fat pipe (all with IPs in the same subnet). It seemed to work with the 3 IPs on the same subnet without complaining about a duplicate serial number for over a week. It's only after we had to reinstall Leopard Server from scratch (erase and install from DVD) and activated all NICs BEFORE upgrading to 10.5.8 that our problems started.

Hi

If it's a bonded port you can't have more than one.

Tony

For what its worth. I've found a kludgie (Hopefully temporary) fix that works with our VM (VMWare running win2003 AD ).
Configuring the second NIC to only use IPv6 (with random manual settings) and turning IPv4 off allows the second NIC to be active for the VM to use, but stops the MulticastListener service on the OS X NIC from picking up on Serial number broadcasts. Not Perrrty, but it works.

Thanks for posting a temporary fix.

Our Server2k3 runs security for the building & won't work with IPv6. 😟

This is a frustrating occurrence as we launched our first Xserve last week, installed Parallels Server, & ran into this problem right out of the gate.

Hope Apple nips this one quickly.

Our VM does not use IPv6 either.
The VM has its own drivers and is configured separately from the host NIC IP. The VM just requires that the host NIC be active.

Does anyone know if this problem is corrected with Snow Leopard Server? Or still exists?

We got the Spinning Gear after updating to OS X 10.5.8. Just when I was about to restore or install a new OS again, I decided to restart holding down the SHIFT key (safe boot). This allowed whatever needed to finish to actually work and then the Xserve restarted by itself and all was well again. Just thought I post this as another thing to try before you wipe out and start over.

I found out about a customer of Small Tree's having a problem like this last week. They had several ports on one subnet.
I always warn people not to do this because the way BSD routing works, there will only be one route to all of the subnets. So outbound traffic will all be flowing out of one port. (You could verify this by running "sar -n DEV 2 100" in a terminal)
If you must have more bandwidth on one network, use link aggregation. That will give you the bandwidth and a single IP address on the subnet.
If you have some kind of broadcast/redundant internet broadband thing going on, then use a private vlan giving each port access to the world in such a way that they can't hear each other. (Classrooms do this sort of thing for guest networks). It doesn't solve the single route issue, but it could work for outbound stuff.
Apple must have changed something in their OS X piracy checking that causes problems when the other ports "hear" the server coming from the one port broadcasting.
If you absolutely have to do something like this, then talk to Peter Sichel over at Sustainable Softworks. He's got an inexpensive routing package that can "source route". This forces responses to go back over the same port the original socket came in on. I don't know if it'll solve the OS X licensing issue, but it can make sure you see outbound traffic on all ports as is supposed to happen.

We've had this trouble with one of our two XServe's at our school campus. Our high school one has an internal IP on one port, external on the other. After updating to 10.5.8 we began to get the license error. Luckily, our routing makes it so that we can use all the services we need on the external, so we disabled the second port and everything seems to be back to normal. The one we have at our Junior High campus is only connected with one Ethernet port. It has not had any trouble, but I'm not certain if I ever got around to installing 10.5.8 on it or not. Sufficed to say I will not for the time being.

Hope this is resolved sometime soon, we're deploying two more XServes in the coming weeks!

The fix was just posted.

http://support.apple.com/downloads/MacOS_X_Server_10_5_8_Update_v_11

Just for completeness (and because blogs including my own point to this article)

Apple fixed this problem in the "Mac OS X Server 10.5.8 Update v.1.1".
<http://support.apple.com/downloads/Mac OS_X_Server_10_5_8_Update_v_11>

The "Network Registration Update" for 10.6 fixes it.
<http://www.apple.com/downloads/macosx/apple/macosx_updates/networkregistrationu pdate10.html>

The 10.6.1 update contains the fix as well.
details here: <http://www.apple.com/downloads/macosx/apple/macosx_updates/macosxserverv1061up date.html>