IP Helper still no DHCP address

[Live2 Bicycle]

I have a Cisco 3560 switch with the DHCP server and all workstations plugged in to it. Currently all workstations and servers are on the 10.1.35.0 subnet. I created a new DHCP scope for 10.1.36.0 I want to seperate the servers and workstations. On the rtr I added a secondary Ip address of 10.1.36.2

interface FastEthernet0/0

description connected to 10.1.35.0

ip address 10.1.36.2 255.255.255.0 secondary

ip address 10.1.35.2 255.255.255.0

ip helper-address 10.1.35.52

ip helper-address 10.1.34.55

no ip redirects

duplex auto

speed auto

If I manually assign a 10.1.36 address toa workstation I can access all network resources just fine. If I try to get an address via DHCP I never get an address. My question is why is the DHCP not working? I know the scope is setup correctly. Is there something I need to do on the switch? Below is the switch config. I do not think I even need the IP helper statements since the DHCP server is on the same switch and not across the WAN link.

GWD-3560-48-1#sh run

Building configuration...

Current configuration : 3437 bytes

!

version 12.2

no service pad

service timestamps debug datetime localtime show-timezone

service timestamps log datetime localtime show-timezone

service password-encryption

!

hostname GWD-3560-48-1

!

logging buffered 16000 debugging

enable password 7 073C354D5E054A2844

!

no aaa new-model

ip subnet-zero

!

no file verify auto

spanning-tree mode pvst

spanning-tree extend system-id

!

vlan internal allocation policy ascending

!

interface FastEthernet0/1

description Link to Router

!

interface FastEthernet0/2

spanning-tree portfast

!

interface FastEthernet0/3

spanning-tree portfast

!

interface GigabitEthernet0/1

!

interface GigabitEthernet0/2

!

!

interface Vlan1

ip address 10.1.35.6 255.255.255.0

!

ip default-gateway 10.1.35.2

ip classless

[Richard Burts]

Del

Your description seems to be talking about 10.1.35.0 and 10.1.36.0 and those are the address and secondary address. But the helper addresses in the config are 10.1.35.52 and 10.1.34.55. I do not understand why you have a helper address for 10.1.35.52 since that address is already within the subnet. You only need helper address to forward to something outside of the subnet (or since we are now dealing with secondary addresses it would be more accurate to say forwarding outside the broadcast domain).

Is the DHCP server at 10.1.35.52 or at 10.1.34.55? Or are there two servers?

I also wonder why you are attempting to define a second subnet on the interface. If the servers and clients are still in the same VLAN (and therefore in the same broadcast domain) what is the benefit of having a separate subnet? A second subnet will not prevent the devices from direct communication. If you could help us understand what you are trying to resolve or what you are trying to accomplish with this we might be able to help you better.

Here are a couple of ideas that might be helpful:

It is my understanding that if two scopes are defined for the same broadcast domain and are reached by ip helper-address that the server will assign addresses from the first pool till it is used up before it will assign addresses from the second pool.

There was a discussion on one of the forums recently about specifying a dhcp smart-relay parameter which was stated was helpful in assigning addresses from two pools. I have not used that and do not know if it will really help with your problem, but you might waqnt to check it out.

HTH

Rick

[thisisshanky]

Like Rick suggested, it doesnt make sense to add a second subnet on this vlan. You could keep them in two vlans and have the clients also get DHCP from the DHCP server in Vlan 1.

I doubt if smart dhcp relay agent feature will work, as the router (l3 switch) will send 3 requests using the primary default gateway on that vlan, on the GIADDR field and if there is no response from the DHCP server, it will use the next secondary address configured on the vlan. Which means, if there are lease'able addresses in the DHCP server from the primary subnet, the clients will get an ip address from the primary subnet and not the secondary subnet.

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a00804412bf.html#wp1090022

[Live2 Bicycle]

I put the helper addresses on the router as a test becasue the computers were not getting addresses from the DHCP servers and of course it did not help.

Both 10.1.35.52 & 10.1.34.55 are my DHCP servers. 10.1.35 is local to me and 10.1.34 is across the WAN link.

I guess what I am trying to accomplish is for all my worksations to get a 10.1.36.x ip address from the local DHCP server 10.1.35.52. Once they get a 10.1.36.x ip then I will shut off the DHCP scope for 10.1.35.x and make that my static address range for servers and networking equipment.

Both 10.1.35.x & 10.1.36.x will be on the same switch. So I guess I should create a second VLAN for the 10.1.36.x subnet and assign ports to that vlan to get DHCP addresses from the 10.1.35.52 server?

[Richard Burts · Accepted solution]

Del

Yes it will make much more sense to create a separate VLAN for workstations. If you create the workstation VLAN then you can create the layer 3 interface for that VLAN and if the DHCP server will be in a different VLAN then you can configure ip helper-address on the new layer 3 interface so that DHCP requests get forwarded to the server. It sounds like the server already has the appropriate scope defined. If you do these things then when you start moving workstation ports into the new VLAN they should automatically start getting the new addresses.

That would make a lot more sense.

HTH

Rick

[andrew.butterworth]

This is a pretty pointless way of 'separating' the clients and servers as physically they are still on the same broadcast domain. It would be better to spearate them into 2 distinct VLAN's and route between them with a router or Layer-3 switch. Secondary addressing is generally used to get around problems and is not something that should be introduced into a network unless it can be avoided.

Still, to get this working simply place both DHCP scopes into a SuperScope and it should work as this is what SuperScopes are designed for.

Andy