Link to home
Start Free TrialLog in
Avatar of adrianjfx
adrianjfxFlag for Bahamas

asked on

DHCP Not Providing IP Addresses Quickly or At All

Currently trying to setup another DHCP relay in another Vlan but for some reason it takes a really long time to obtain an ip address in Vlan 2 if i set the 10.168.4.0 which was originally the primary address but only static servers exist in that network it works fine but changed to the 10.168.6.0 it fails out.
Created another network on the same vlan to be a dhcp network.
But it does not respond as our quickly as our vlan 3 client network almost like it is timing out.
VLAN IP configuration as below

interface Vlan2
 ip address 10.168.4.1 255.255.255.0 secondary
 ip address 10.168.6.1 255.255.255.0
 ip helper-address 10.168.4.19
 no ip redirects
!
interface Vlan3
 ip address 192.168.1.14 255.255.255.0 secondary
 ip address 10.168.0.1 255.255.252.0
 ip helper-address 10.168.4.19
 no ip redirects


any ideas of what is happening i felt DHCP was pretty srtaight forward.
maybe i have to do a shut down on the interfaces but i don't think so we moved to a virtual server and the client network has the same quick ip address respond on the virtual server.
Avatar of adrianjfx
adrianjfx
Flag of Bahamas image

ASKER

Also our core switch is a Cisco Catalyst 4507r
Dhcp Server is Server 2008
Avatar of Jimmy Larsson, CISSP, CEH
According to your configuration the DHCP-server is on the vlan2-segment. Why do you have an ip-helper on vlan2 if that is where your dhcp-server is? Your int vlan2-configuration looks quite weird with a secondary-address as well as a ip helper. The DHCP-clients should be able to reach the clients (or vice versa) without ip helper.

DHCP requests are local broadcasts. Even if I cant tell you the theory behind your problem I am sure that it has something to do with the secondaries. I would strongly recommend you to not use secondaries since this is not always fully supported in cisco-environments. Try to find a way to do this without secondaries.

/Kvistofta
interface Vlan2
 ip address 10.168.4.1 255.255.255.0 secondary
 ip address 10.168.6.1 255.255.255.0
 ip helper-address 10.168.4.19
 no ip redirects

****All of the addresses above overlap in 10.168.4.0

interface Vlan3
 ip address 192.168.1.14 255.255.255.0 secondary
 ip address 10.168.0.1 255.255.252.0
 ip helper-address 10.168.4.19
 no ip redirects

***None of the addresses above overlap in any subnet.  All are on different subnets.
Without routes, how might they communicate?
10.168.6.0 /24 valid ips 10.168.6.1 - 6.254
10.168.4.0 /24 valid ips 10.168.4.1 - 4.254
10.168.0.1 /22 valid ips 10.168.0.1 - 3.254

how do they overlap?
They dont. But you run both 4.0/24 and 6.0/24 on the same segment/vlan. Why?

/Kvistofta
10.168.4.0 is for our static servers and other implementations and 10.168.6.0 was supposed to be for some dhcp for citrix virtual desktop solution we are doing. that sit on the same vlan
If this is in a MS Active Directory environment, be sure to have those IPs listed in 'Sites and Services,' this will help the clients (and DHCP Server) know where to get the addresses from.  Without them listed in Sites and Services, you will rely more on broadcasting than a targeted response.

Also, too many DNS WAN hops can slow everything down.  Make sure your DHCP options have the least costly DNS servers configured to be assigned.
our network is pretty basic only 1-2 hops for the network
2 hops for client and 1 hop for servers
When it comes to PXE booting the machine gets the ip address desired but when windows boots it cannot get an ip address this leads me to believe since PXE starts at a lower level on the TCP/IP stack and windows i guess starts a lil higher there is an issue some where along that line. It gets an IP in PXE in seconds literally but fails out when windows loads the drivers and tries.
ASKER CERTIFIED SOLUTION
Avatar of Jimmy Larsson, CISSP, CEH
Jimmy Larsson, CISSP, CEH
Flag of Sweden image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of peterelvidge
peterelvidge




Your config   is asking for trouble really.


here  you have an ip helper address on the same svi on where the DHCP server lives

interface Vlan2
 ip address 10.168.4.1 255.255.255.0 secondary
 ip address 10.168.6.1 255.255.255.0
 ip helper-address 10.168.4.19
 no ip redirects


to sort out your dhcp problems, i agree with kvistofta , sort out a decent network design rather than look for workarounds.


Try enabling port fast on the cisco switches. It's often an issue with DHCP failing or not being allocated quickly enough.

http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800b1500.shtml
Also as the others have said it doesn't make sense to have two subnets on the same VLAN. All it does it increase router load and and very little to security.

They should be configured in a 1:1 ratio. 1 Subnet for each VLAN.

FYI. DHCP is a broadcast protocol. It makes no assumptions about the address space. Unless you have setup the server DHCP scope/subnet with static only assignments (no dynamic assignments) it will be a lottery to which subnet the PXE clients are assigned to.

The reason was the secondary IP that is almost a hidden network so clients broadcast would be coming from the primary address on VLAN but if that network is not present on the DHCP you will not get any IP Assignment
I don't think the diagnoses is correct. DHCP requests ignores subnets. The initial DHCP request has no subnet information, only a broadcast address, so to say it comes from a particular subnet isn't correct.

The DHCP sever at 10.168.4.19 should be serving the clients directly, but due to the presence of a helper on the same ethernet/vlan segment, the client would be receiving multiple replies from the help and DHCP server.

You are dealing with an obscure, uncommon configuration that probably isn't tested well under IOS. Removing the helper clears up the duplicate responses and probably the issue you are experiencing.

But regardless good to see it's now resolved.