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?


maybe enabling port fast will solve your problem.


  • 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
  • 2
    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
  • 1
    @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.


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.

Your Answer

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