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

I've noticed this several times: a switch starts to behave oddly. Usually if the switch doesn't fail outright, what tends to get noticed is that DHCP doesn't work.

We had a Linksys SRW-224P fail today. Systems which were still connected worked properly, until it came time to renew their DHCP lease. Once the lease expired, they stopped working, but up until then we couldn't detect a failure. This includes PoE VoIP phones -- they work fine until their lease is up, at which point they're done.

I've noticed this on the above-mentioned Linksys, three varieties of 3Com, and possibly half a dozen dumb switches.

What is it about DHCP that makes it sensitive to failing switches?

share|improve this question
    
You may want to consider smart switches that can be monitored... –  tegbains May 12 '10 at 0:46
    
I've noticed this on smart and dumb switches. –  David Mackintosh May 12 '10 at 1:22
    
It seems to me the problem is not with DHCP but with the switches. It's like saying "Why won't my car run when it's out of gas". The switches have some failure condition that prevents DHCP from operating properly, that's a switch problem not a DHCP problem. –  joeqwerty May 12 '10 at 2:33
1  
Did you happen to have internal DNS resolution problems at the same time? DNS uses UDP by default (continuing on the statement Zoredach made about UDP's unreliable nature being a symptom of a faulty network infrastructure)? That might be something to look at when this problem occurrs. –  joeqwerty May 12 '10 at 3:07

6 Answers 6

up vote 17 down vote accepted

Perhaps you are looking at this from the wrong direction instead of asking why does DHCP not work maybe you should be asking why does TCP-based communication working on a unreliable network where there is packet loss or corruption.

TCP based communication is meant to be reliable and the protocol is designed to retry communication other protocols like UDP are not reliable. DHCP just happens to be using UDP. On a typical network most of what you see these days is TCP-based. Its resilience properties may be what is be allowing you to continue to have communication over failing hardware.

share|improve this answer
    
Great observation. I had not thought of it that way. –  David Mackintosh May 12 '10 at 1:22

I would say that DHCP is a little more complex than say http requests, but I would debate myself trying to claim that a way to find out if your switch is breaking is to check if DHCP requests are successful through it. I'm pretty sure if you looked at your actual VOIP traffic, you'd notice packet loss. VOIP (UDP) packet loss might be noticeable in a call depending on the % being dropped. If a few get dropped it's no big deal, but with DHCP requests, these packets are actually important and since they don't get retransmitted it would break the request.

Might come in handy to understand all of the things DHCP does for you (via Cisco).

share|improve this answer

The ability to forward the bootp/dhcp helper request?

EDIT: Ok, since they are not layer 3 switches (probably should read this a bit more closely), they probably aren't involved in dhcp forwarding.

share|improve this answer
    
Switches don't forward DHCP packets (helper requests), DHCP is broadcast based, so DHCP packets should be flooded to all switch ports. Routers forward DHCP packets (helper requests), if configured to do so. –  joeqwerty May 12 '10 at 2:35
    
Yep, good point ;-) –  Greg Askew May 12 '10 at 2:44

I've seen this behavior on two Netgear Smart Switches. In both cases the switches were ignoring all broadcast traffic. So the DHCP requests and replies were not being passed along.

share|improve this answer

DHCP is not just broadcast based. It it "Request" based. There is a connection to the network, then a request for an address on that network, then a reply sent from the DHCP server that either holds an address lease or reports a failure. The request is repeated on the client internally, sending out the request every few seconds and waiting for a response.

However if that response is not recieved, if it is dropped, or if it simply isn't passed through the switching devices properly, you won't be able to get an address. Check to make sure that your subnets are properly configured. I've noticed that many like to use the x.0.x bits to hold only the static managed devices (switches and printers) while keeping computers and servers on the x.1.x or otherwise (this is just an example). If you don't include the x.0.x in your subnet masking properly, you can end up with bitmasks that drop your dhcp requests, or misroute them.

Remember to include this x.0.x as the primary starting address, and then move on to set the subnetting as wide as you need with a masking that matches your dhcp in full; note that sume will set the subnetting with respect to the actual dhcp server, this is not useful, it creates packet leaks. If you set your dhcp to not hand out the static portion, you still need to set it inside your subnet.

If you subnet your dhcp, you should reconfigure the masks, adding 1 to the bitmask alteration. If you subnet 255.255.252.0 for your mask on your dhcp, you need to subnet 255.255.251.0 on your switches, to allow the requests for x.0.x address masks (static routes entered at the client) to carry the dhcp signal the same as the rest of the network. Make sure your subnet masking allows the subnets that need to interact to see each other, even if only to pass the dhcp requests through.

You can separate network services on windows machines (and now macs) by setting workgroup or domain restrictions. Access to services should be handled by login, not by vlan. Login can control the address you receive if you know how to write the script into your servers, but that should only be done when absolutely necessary. VLAN should only function to help a network tech track, trace and fix a problem by following the address masking scheme to a physical location.

Remember, you can bridge vlans of completely different masks, but this only allows them to see each other from a networking standpoint, not an access level. If they need access to services, the vlans should all be bridged to a major interface and that interface should carry the full mask containing all vlans, while the vlan interfaces carry only primary mask 255.255.255.0 (or whatever vlan subnet you put accross it).

share|improve this answer

The only thing I can think of is that the switch might not be able to update its ARP cache correctly to reflect the newly-assigned IP.

share|improve this answer
    
That doesn't sound right to me as DHCP is broadcast based and as such, DHCP packets should be flooded to all switch ports and therefore shouldn't be affected by a faulty ARP cache on the switch. Also, a client renewing it's DHCP assigned address wouldn't be getting a new address, it would be renewing it's current address. –  joeqwerty May 12 '10 at 2:32

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.