Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
add comment

3 Answers

maybe enabling port fast will solve your problem.

http://tips-made-easy.info/computer/tips52/Cisco_CCNP_Certification__BCMSN_Exam_Tutorial__Uplinkfast.html

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
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
add comment

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
add comment

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
add comment

Your Answer

 
discard

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