cafasdon
asked on
DHCP reservation problems
My DHCP server reservations sometimes fail out of the blue. I had one Vista machine that didn't get its reserved IP. The MAC was right, there was only one DHCP server running in the entire network and plus, a brand new machine, just plugged into the network, got the reservation IP, despite the MAC address being completely different.
I don't have a clue about what's going on. Need professional help with the issue.
Thanks.
I don't have a clue about what's going on. Need professional help with the issue.
Thanks.
miqrogroove
Call me a pessimist, but if you've done all the math and arrived at a single point of failure, then it's time to overhaul. Get a newer/alternative DHCP server.
ASKER
I'm working on that already. Just wanted to give my manager a proper answer to what happened to the reservation. I've checked the MAC on the computer that stole the reserved IP, and it's by far different from the proper one. I just want to be 100% that without a secondary DHCP server, this won't happen again. Are there any known flaws in linux DHCPD related with Red Hat EL5 servers? Sorry to be repetitive, just want to cover every minimal gap.
If you're 100% sure the address was available when you reserved it, then I'd say you just found one (a flaw). The only other thing to check is the DHCP address reported by the client.
ASKER
I found out one more variable to add to the equation:
Using a neat program called DHCP-Find, I found the following DHCP offer:
8.255.0.0
So far, seems it was offering the reserved addresses on the network.
Example:
Packet from 8.255.0.0
Offered IP 172.16.5.234
Lease Length 86400 Seconds
Subnet Mask 255.255.252.0
where .5.234 is a reserved address to a specific MAC.
Strangest thing is, when I try to see if it is alive, it translates to 4.68.16.8.
Just adding up to possible causes. I wanna solve this mystery no matter what.
Using a neat program called DHCP-Find, I found the following DHCP offer:
8.255.0.0
So far, seems it was offering the reserved addresses on the network.
Example:
Packet from 8.255.0.0
Offered IP 172.16.5.234
Lease Length 86400 Seconds
Subnet Mask 255.255.252.0
where .5.234 is a reserved address to a specific MAC.
Strangest thing is, when I try to see if it is alive, it translates to 4.68.16.8.
Just adding up to possible causes. I wanna solve this mystery no matter what.
ASKER
Let me add a doubt:
Is it possible to make a reservation like: 10.10.10.10 on a dhcpd configured for 172.16.4.0/22 for an example?
I've been digging through the net and found out that my issue could be 'cause I'm assigning a reservation inside the offer range. Doesn't make much sense to me, so I'm looking for a second opinion.
I'm experimenting a little with the DHCP server right now, and will keep so during the day. If anyone have any ideas for possible test solutions, I'm all ears.
Is it possible to make a reservation like: 10.10.10.10 on a dhcpd configured for 172.16.4.0/22 for an example?
I've been digging through the net and found out that my issue could be 'cause I'm assigning a reservation inside the offer range. Doesn't make much sense to me, so I'm looking for a second opinion.
I'm experimenting a little with the DHCP server right now, and will keep so during the day. If anyone have any ideas for possible test solutions, I'm all ears.
ASKER
BTW:
DHCP reported by client matches the main server. No problems with that.
DHCP reported by client matches the main server. No problems with that.
Packet from 8.255.0.0
Offered IP 172.16.5.234
That's a little bizarre. Is 8.255.0.0 the normal address for your DHCP server?
Offered IP 172.16.5.234
That's a little bizarre. Is 8.255.0.0 the normal address for your DHCP server?
ASKER
Nope. The network is 172.16.4.0/22.
That IP seems to have something to do with reservations, since the reservations that I have in dhcpd.conf appear with this IP as the dhcpoffer sometimes.
I've recently read about some problems with Microsoft clients not working properly with MAC reservations. Something called "DHCP RELEASE while SELETCINTG" bug. Seems to be the closest I got to my case, but not sure if it is the exact same problem.
Another thing to consider is: Every computer that lost its address, were laptops. Although the ones who stole it were usually desktops. Read about something related to that as well, about lease times needing to be shorter for mobile devices (with Windows, as usual).
So far, this hasn't happened to any Linux machines.
That IP seems to have something to do with reservations, since the reservations that I have in dhcpd.conf appear with this IP as the dhcpoffer sometimes.
I've recently read about some problems with Microsoft clients not working properly with MAC reservations. Something called "DHCP RELEASE while SELETCINTG" bug. Seems to be the closest I got to my case, but not sure if it is the exact same problem.
Another thing to consider is: Every computer that lost its address, were laptops. Although the ones who stole it were usually desktops. Read about something related to that as well, about lease times needing to be shorter for mobile devices (with Windows, as usual).
So far, this hasn't happened to any Linux machines.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Checked wireless routers. All in access point mode, not serving DHCP.
I had the rogue DHCP issue once, but solved it with Cisco's DHCP Snooping, setting only the port for the main server as trusted for DHCPOFFER packets.
I don't know how to replicate the problem so far, but I'll keep in mind to get as many info from a computer as I can when it happens. My company is huge, so I'll have to really quick to find out whoever is having the problem (physically I mean). So far, the problem was solved by changing the reservation IP to a range outside the preset pool, but inside main mask. But it's quite a pain to have to be editting the dhcpd.conf every time this happens, since there's a LOT of reservations.
Oh, and one more thing: whenever this happened, the original reservation machine would just not get any IP, EVER, until the new reservation is set. However it would still show on the rogue computer that there is an IP conflict.
I had the rogue DHCP issue once, but solved it with Cisco's DHCP Snooping, setting only the port for the main server as trusted for DHCPOFFER packets.
I don't know how to replicate the problem so far, but I'll keep in mind to get as many info from a computer as I can when it happens. My company is huge, so I'll have to really quick to find out whoever is having the problem (physically I mean). So far, the problem was solved by changing the reservation IP to a range outside the preset pool, but inside main mask. But it's quite a pain to have to be editting the dhcpd.conf every time this happens, since there's a LOT of reservations.
Oh, and one more thing: whenever this happened, the original reservation machine would just not get any IP, EVER, until the new reservation is set. However it would still show on the rogue computer that there is an IP conflict.
ASKER
Found some errors in dhcpd.conf, like duplicated MACs, so it was pretty much stress + tons of work. But thanks for trying to help anyway, the DHCP server is now in a Windows 2k server, so it's not my problem anymore :P