Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have configured two VLANs [ 15 and 16 ] and a trunkport on a Cisco Catalyst 2960. The trunkport is connected to eth2 on a Linux server The server is configured to support VLAN's and the interfaces eth2.15 eth2.16 is configured with ip addresses on two different subnet. dhcp3-server is running on the same server and hands out IP-addresses to the VLANs.

When connecting a client to a port that is configured in ex. VLAN 15 and requesting a IP-address, i experience a long delay before recieving a DHCPOFFER, around 30 seconds or so, the client needs to send a DHCPDISCOVER about five times but will always recieve a DHCPOFFER.

Any suggestion why this delay is happening?

share|improve this question

maybe enabling port fast will solve your problem.

share|improve this answer
I have now checked and spanning-tree portfast is disabled on all VLANs but the delay is still present.. – john883 Apr 13 '10 at 12:53
you need to enable port fast!!!!!!!! – The Unix Janitor Apr 13 '10 at 13:04
Depending on the switch in some cases you really do need to enable portfast even though STP is disabled on the VLAN's in question. – LapTop006 Apr 13 '10 at 14:37
@john883: DONT EVER DISABLE STP. It is too easy to create a loop and then your network is down. STP in its basic default config should cause no problems. Enable port-fast on individual ports like they said. – einstiien Apr 13 '10 at 15:23
@einstien +1 , you should never disable STP unless you know what you are doing. Layer 2 loops are nasty and can cause your network to become useless. – The Unix Janitor Apr 13 '10 at 19:55

This may also be a DNS issue. Perform a tcpdump on the DHCP server to confirm.

tcpdump -i -lennvs0 port 53

As the DHCP server produces a lease it may be performing a DNS lookup for the IP address it's about to hand out, so that it can include a host name record in the DHCP offer.

share|improve this answer

So the first thing to do is use tcpdump/tshark to see where the delay is.

tshark -i eth2.15

Then connect a client and try to get a DHCP lease.

Another thing to do would be to plug a dumb switch in between, wait a minute or so and plug a client in to that, if it comes right up then STP related delays are almost certain.

On the client end running dhclient at a console (ideally without network-manager or similar so you can be sure that the system isn't doing it automatically) prints every packet it sends or receives, that's a great way to confirm if packets are getting dropped by the switch.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.