Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Server needs too long to provide DHCP leases

Hello,


we have installed Mac OS X 10.8 Server on an existing XServe.


Everything works as intended but it takes a long time for the clients to get the DHCP leases. It doesn't matter if the clients are connected through an unmanaged switch, an managed switch or directly (cross linked).


The clients start up and point out that there is no Open Directory Server available. If you disconnect and reconnect the Ethernet cable it takes a long time, too. Sometimes the DHCP request even times out and an internal IP is provided until you manually renew the DHCP lease on the client.


Server and client are Mac OS X 10.8.3, Server Version is 2.2.1, XServe model is "XServe3,1" (Early 2009).


All I found about the problem is about spanning tree on a managed switch and fastport support. But my problem persists even when direct connected to the XServe.


We have the same problem on a Mac OS X 10.6.8 Installation on another XServe (same model).


I really appreciate any help!


Thanks a lot!


Kind regards,


ragob66

Posted on Jun 5, 2013 2:38 AM

Reply
4 replies

Jun 5, 2013 4:49 AM in response to ragob66

I'll presume you've checked the DHCP server logs and the DHCP client logs for any relevant information. You'll want to load and launch Wiresharkor an analogous network-monitoring tool, and see what's actually going on with your network around the DHCP traffic.


And a couple of questions...


Is your Xserve configured for link aggregation?


Your references to spanning trees would apply to non-trivial network with multiple (typically) managed switches, and with loops intentionally configured in the networking wiring for redundancy. Is that the case with your network? If you have multiple switches and the switches are not capable of or not configured for spanning tree, then keep a tree configuration and avoid any loops among the switches.

Jun 5, 2013 5:38 AM in response to MrHoffman

Hello MrHoffman,


thanks for your answer!


Following the logs everything works fine and it needs only about 3 seconds for the dhcp "handshake"to complete. Unfortunately the experience is another when you sit in front of the client and look at the Network Pane in System Preferences. About 1 minute the state of the network interface is undefined.


The XServe is not configured for link aggregation.


It is no complex network and we don't configure the switch to use a spanning tree protocol. I just mentioned it to show that I searched online for a solution but only found references to this problem in relation to spanning tree misconfigurations. That is no hint for me because we have these issues even using an unmanaged switch or a direct connection.


By default the server is connected to a managed Cisco Small Business 24-Port Switch, which isn't configured for spanning tree. The network ports to which the clients are connected are patched directly on this switch either.


The idea to use wireshark to analyze the problem is a good one. Perhaps I'll give it a try. Just thought maybe this is a known problem in some environments and therefor there would be a known solution for this environment.


Thanks a lot!


Kind regards,


ragob66

Jun 5, 2013 6:17 AM in response to ragob66

It used to be possible for client Macs to 'find' the Open Directory server purely via DHCP. With this configuration a client Mac would boot, do a DHCP request to get an IP address, and then would ask the DHCP server for DHCP option code 95 and then use that information to be able to login to network accounts. If you are still trying to use this approach it now works apprently by booting, then using Bonjour to find the Open Directory server, and then adding it to the list. This will take longer.


Even back in the day this was the 'standard' configuration, a client Mac would often not immediately be able to connect to Open Directory and network accounts. These days it is far more common for a Mac to be initially setup with an entry for the Open Directory server which no longer requires using DHCP option code 95. This is done either in System Preferences - Users & Groups, or Directory Utility, or via the command line using dsconfigldap, or as part of a Mac image deployment system like DeployStudio.


With pre-defined entries for the Open Directory server, the client Mac boots, again asks via DHCP for an IP address but is then able to continue its startup and use the previously entered Open Directory server details making the process in theory quicker.


My own experience is that an initial boot of a Mac after its previous DHCP lease has expired will result in the Mac booting, getting an IP address but perhaps for a few seconds not recognising the availability of network accounts. If the only local account is a single admin account then it used to be that it would then go straight to asking for the password for that local account, now in Lion/Mountain Lion it merely highlights that account and when the network accounts are detected you see an arrow pointing left. If there is more than one account available you will initially see a list of local (including mobile) accounts, and after a short delay the 'other' account for logging in as a network user.


Doing a reboot, it usually shows the network accounts straight away as the previous DHCP lease is still valid.


Note: Yes, if your managed network switch has SPF turned on this will typically cause a delay in clients getting DHCP assigned IP addresses, in the case of NetGear up to 30 seconds. As long as your network is properly setup to avoid loops then it should be safe to turn SPF off.

Jun 5, 2013 7:30 AM in response to ragob66

I'd also remove the Cisco switch from the configuration as a test, replacing that with an unmanaged switch just for some testing. I've had issues with various switches including Cisco over the years around incorrect duplex and even speed negotiation, and I've found it's usually worthwhile to test with some other gear and/or to lock the port settings on both ends of the connection, this in order to isolate the issue to the hosts or to the switch. If the Cisco is pre-Gigabit, many of those — from Cisco and others — can have negotiation issues.


Do you have both NICs on the Xserve connected to the Cisco? If so, reduce to one, get that working, and try the tests again.


If you have both NICs active, then test with the NICs configured in different subnets on different vLANs on the Cisco; don't connect two NICs in the same subnet to the same vLAN.


Do you have any port security enabled on the Cisco? If so, disable it. Particularly if you're using the Xserve LOM.


Yeah; you're in Wireshark territory with this one...


————


FWIW, a spanning tree involves network traffic among the switches seeking to map the network topology when multiple switches are connected together, and it doesn't apply and shouldn't be running when you have one switch with no inter-switch interconnects. It can cause the network to be slow when it is triggered, which is what those discussions are pointing to. It shouldn't be triggered here, and I wouldn't expect a spanning tree to be running here.

Server needs too long to provide DHCP leases

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.