DHCP Server not assigning addresses correctly

What is the setup on switch? Do you have ability to configure ip helper address on switch?

Do yo have vlan setup for these subnets and both dhcp servers are in 2 different VLAN's?

Did you do any kind of packet captures to see what is happening

We do have that ability and have set it up on many of them (first thing we do if we have a problem with DHCP as well).

The servers themselves are sitting on the same VLAN but are administering different VLAN ranges (one covers 172.16.30.x to 172.16.70.x and the other covers 172.16.128.0/19).

No I haven't.  I can set up Wireshark to see what's happening.  Is there anything in particular that I should keep an eye out for?

I take it that your vlan setting have a superscope with a couple of scope inside it?

SuperScope 1
Scope 1 : 172.16.30.x/xx
Scope 2 : 172.16.70.x/xx
Scope 3: 172.16.128.0/19

then the problem is the SuperScope, just take out all the scope out of Superscope 1 (meaning don't use a Superscope at all) and your DHCP should working fine.

--
rumy

Connect a machine to switch and not sure if you have any ability to span port, if so span port. Start a machine and capture packets and in filter you can have udp port 67 or 68

Why you have 2 dhcp servers? Can't you have one to support all subnets?

172.16.30.x - Can you confirm what vlan is this?
172.16.70.x - Can you confirm what vlan is this?
172.16.128.0/19 - Can you confirm what vlan is this?

Which VLAN server  is conncetd? Can you please clarify all these information?

Config of switch would also help to further analyse this issue

We have no superscopes.

We have 2 DHCP servers for redundancy.  As they service different campuses it's quite possible for one to go down and the other to remain functional (albeit, not fully functional, but enough to get by).

I said in my original post what's connected to what.  The range 172.16.30.0, right through to 172.16.70.255 is handled by one server, the other handles the 172.16.128.0/19 range.

Switch Configuration (We have had this problem on multiple switches but all have similar config to this one):

Running configuration:

; J9624A Configuration Editor; Created on release #RA.15.06.0009
; Ver #01:0d:0c

hostname "IT Office" 
time timezone 600 
time daylight-time-rule Southern-Hemisphere 
no stack 
ip routing 
vlan 1 
   name "DEFAULT_VLAN" 
   untagged 2-3,27-28 
   ip address 172.16.254.3 255.255.255.0 
   no untagged 1,4-26 
   exit 
vlan 1032 
   name "servers" 
   ip address 172.16.32.3 255.255.255.0 
   tagged 27-28 
   exit 
vlan 1033 
   name "wireless" 
   untagged 1 
   ip helper-address 172.16.32.160 
   ip address 172.16.33.3 255.255.255.0 
   tagged 27-28 
   exit 
vlan 1046 
   name "finance" 
   ip address 172.16.46.3 255.255.255.0 
   tagged 27-28 
   exit 
vlan 1047 
   name "hredu" 
   untagged 5-9 
   ip address 172.16.47.3 255.255.255.0 
   tagged 27-28 
   exit 
vlan 1048 
   name "IT" 
   untagged 10-26 
   ip helper-address 172.16.32.160 
   ip address 172.16.48.3 255.255.255.0 
   tagged 27-28 
   exit 
vlan 1056 
   name "AirCon" 
   untagged 4 
   ip helper-address 172.16.32.160 
   ip address 172.16.56.3 255.255.255.0 
   tagged 27-28 
   exit 
vlan 1049 
   name "hiscoding" 
   ip helper-address 172.16.32.160 
   ip address 172.16.49.3 255.255.255.0 
   tagged 14,27-28 
   exit 
ip route 0.0.0.0 0.0.0.0 172.16.32.1
snmp-server community "public" unrestricted
no dhcp config-file-update
password manager

Select allOpen in new window

Note: At least one of the laptops we had went from a 172.16.48.x address to a 172.16.46.x and then when coming back onto the original port they couldn't get their IP back on the 172.16.48.x network.  The port wasn't changed though, the laptop was physically moved to another switch (that was connected to this one) and then back again.

How many of these switches do you have with the same config?
Do your servers/clients all use the same switch as their gateway?

We have probably between 30 and 40 that are configured similarly (obviously different ports tagged and different vlans as required).

Here is another one for comparison (The computer was moved from the other switch to this one and then back again):

Running configuration:

; J8697A Configuration Editor; Created on release #K.15.06.0008
; Ver #01:0d:0c

hostname "Finance" 
time timezone 600 
module 1 type J9534A 
module 2 type J9536A 
module 3 type J9534A 
module 4 type J9534A 
module 5 type J9534A 
ip routing 
vlan 1 
   name "DEFAULT_VLAN" 
   untagged B21-B22,E1-E24 
   ip address 172.16.254.9 255.255.255.0 
   no untagged A1-A24,B1-B20,C1-C24,D1-D24 
   exit 
vlan 1032 
   name "servers" 
   ip address 172.16.32.9 255.255.255.0 
   tagged B21 
   exit 
vlan 1046 
   name "finance" 
   untagged A1-A24,B1-B20,C7-C24 
   ip helper-address 172.16.32.160 
   ip address 172.16.46.9 255.255.255.0 
   tagged B21 
   exit 
vlan 1047 
   name "hiscoding" 
   untagged D1-D24 
   ip helper-address 172.16.32.160 
   ip address 172.16.47.9 255.255.255.0 
   tagged B21 
   exit 
vlan 1048 
   name "IT" 
   ip helper-address 172.16.32.160 
   ip address 172.16.48.9 255.255.255.0 
   tagged B21 
   exit 
vlan 1049 
   name "hredu" 
   ip helper-address 172.16.32.160 
   ip address 172.16.49.9 255.255.255.0 
   tagged B21 
   exit 
vlan 1033 
   name "wireless" 
   untagged C1-C6 
   ip helper-address 172.16.32.160 
   ip address 172.16.33.9 255.255.255.0 
   tagged B21 
   exit 
ip route 0.0.0.0 0.0.0.0 172.16.32.1
snmp-server community "public" unrestricted
snmp-server contact "IT department" location "Finance 2nd Floor"
no autorun
no dhcp config-file-update
no dhcp image-file-update
password manager

Select allOpen in new window

The client is the one that initiates the DHCPREQ. Once the request is sent, the server seems to offer it. So, the client is having problems. The client send out the request upon logon, not connection. So, if the computer moves, it has to reboot, or a manual IPconfig /release and IPconfig /renew.

Another Thought on my mind:
On the domain servers, at the command prompt:

Type DHCPloc.exe

See if there is a rogue DHCP server providing DHCPOFF (offers from DHCP). Rogue servers can Knock a DHCP server down. I also see that you have two servers in case one fails. They can be on the same scope, but the address pools must be different (as in your case).

If a server receives a request, but it doesn't know how to get to the subnet which the request originated from the client would not receive the IP address - so therefore it's not fair to assume it is definitely a client problem.

A client ALWAYS sends a DHCP request when the NIC driver is loaded (unless it's set to static).  If this wasn't the case client PCs would never process Computer Group Policies (on a Windows network for example).  If your client disconnects from the network then reconnects to a different VLAN it doesn't have to reboot or do a manual IPCONFIG /RENEW to obtain an IP address.  The simple fact that the medium went down then up will be enough to cause the client to send a DHCP request.

The problem does not seem to be appearing anymore, other than a small time delay.  Usually disabling and reenabling the network adapter or using ipconfig /renew will fix the problem.

This problem started to reoccur and we've been struggling with it for a year.  I'm pretty sure we've finally found the cause.

DHCP-Snooping was enabled for a small number of the VLANs and they were the ones that were causing the problem!  This may be useful for other people that come across a similar problem in the future.

DHCP snooping isn't configured on the switch you provided a config for so we wouldn't have known it was being used!