ip helper - dhcp

[Benjamin Waldon]

Hello Everyone,

I have a question about using IP Helper for DHCP. There are alot of other posts on this subject, so I tried to find somewhere that my question might already be answered but it wasn't there.

Allright, I have a 3750 switch doing ip routing. On vlan1, I have a dhcp server at 192.168.1.7. That DHCP Server is running two dhcp scopes. One for the 192.168.1.0/24 and one for 192.168.2.0/24. The switch is configured as such:

     !

     interface vlan 1

      ip address 192.168.1.1 255.255.255.0

     !

     interface vlan 2

      192.168.2.1 255.255.255.0

      ip helper 192.168.1.7

However, when I connect a dhcp client on vlan 2, it gets an address from the 192.168.1.0 subnet. we verified that both scopes are running and we verified that we are connecting to the right vlan. However, we still get the wrong address.

1. Any ideas on what could cause this? I know it might come down to the server and I am concurrently investigating the issue form the server side. But, any brainstorming on the switch side would be helpful.

2. How does the server know which scope to assign addresses out of? I have done this in other enviornments and didn't have to do anything in particular to the server. I assumed that the layer 3 switch is tagging the packet in some way that indicates to the server that it should belong to the 192.168.2.0 network.

3. What is the role of the dhcp smart-relay? that is not configured here, should we be looking at it?

4. does this configuration qualify as a relay agent that conforms to RFC 1542?

Thanks,

ben

[sachinraja]

Hi Ben

Can you please share the output of show ip route from the switch ? Have you enabled ip classless on the switch ? error messages from the DHCP server should be helpful here...

Regards

Raj

[Benjamin Waldon]

Hi Raj:

Here is my Sh IP route:

Core-3750-1#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is 10.0.14.215 to network 0.0.0.0

C    192.0.10.0/24 is directly connected, Vlan10

     172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks

S       172.16.191.0/24 [1/0] via 192.0.0.243

S       172.16.190.64/27 [1/0] via 192.0.0.59

C       172.16.194.0/24 is directly connected, Vlan194

C       172.16.76.0/24 is directly connected, Vlan76

     10.0.0.0/24 is subnetted, 5 subnets

C       10.0.14.0 is directly connected, Vlan14

C       10.0.15.0 is directly connected, Vlan15

C       10.0.18.0 is directly connected, Vlan18

C       10.0.16.0 is directly connected, Vlan16

C       10.0.17.0 is directly connected, Vlan17

C    192.168.1.0/24 is directly connected, Vlan1

C    192.168.2.0/24 is directly connected, Vlan2

S*   0.0.0.0/0 [1/0] via 10.0.14.215

!

!

and this shows that ip classless is enabled

sh run | in ip classless

ip classless

Thanks!

Ben

[sachinraja]

Thanks for the output Ben... Looks good..

Just a query.. have you configured the same DHCP server for all other VLANs ? VLAN 14, 15 etc ?? are they working well ??

Just curious to know if you have created seperate scopes for each subnet range on the DHCP server ? you dont have all both the pool in the same scope right ? DHCP server basically looks at the relay IP address field to give out IP addresses... when the switch sends a unicast frame, it sets its VLAN SVI as the source address, and hence it should give the IP on the correct VLAN.. which DHCP server are you using ?

Raj

[Benjamin Waldon]

Thanks Raj,

To Answer your questions, not we haven't configured the same DHCP server for other VLans. I personally have used ip helper before, but this is the first instance in this enviornmant.

Ultimatley, however, we hope to server dhcp for 5-8 subnets off of this server in this manner.

Thanks,

Ben

[sachinraja]

Thanks Ben

Did you check the scopes defined on the dhcp server for these pools ? what kind of dhcp server are you using ? microsoft ? if this is not in production, you can try disabling the 1.0 scope , just to check if your 2.0 works good.. did you notice any events on the dhcp server ? or the best thing is to run a sniffer to see the source address of the packets hitting the dhcp server...

Raj

[michaelgitonga]

hi Benjamin,

Try this...remove the "ip helper 192.168.1.7" command in vlan 2....then see if clients on vlan 2 ports get ip addresses in vlan 2

[Benjamin Waldon]

Thanks Michael,

Is there some configuration that may allow for the relay anyway?

It seems to me that they should get an ip address at all.

Or maybe you are thinking that if the they still get the 1 address, then it would indicate a problem with the VLan configuration?

[lamav · Accepted solution]

Benjamin:

As Raj rightly pointed out, the SVI interface will forward the broadcast DHCP request from the client as a unicast message directed at the helper address, using its own address as the source IP. This is is how the DHCP server knows from which subnet to issue an IP address. So, it seems as though there is a misconfiguration on your DHCP server.

Moreover, is this a prodcution switch or just a lab set up? Im asking because it is not a good practice to use VLAN 1 as a client VLAN because the switch forwards management frames over VLAN 1 - CDP, VTP, etc...You should keep all user traffic off of VLAN 1.

Lastly, the recomenndation that you remove the helper address configuration line from interface vlan 2  to test DHCP does not make sense. As you rightly pointed out, the router needs the correct configuration lines to forward the DHCP requests to the DHCP server, otherwise the client's broadcast will never be propagated passed the router interface..

HTH

Victor

[Benjamin Waldon]

Thanks Victor,

This information is very helpful.

As it turns out, once I got onsite, we plugged it in and it just worked. I think we had some vlan memberships wrong on the previous attemps.