unable to pull ip from new dhcp

[oddyager]

My company is in the process of migrating to a new domain (and also moving to a new IP subnet) and one of the things they wanted to do is make a new DHCP server. So currently right now we have 2 domains with a dhcp server in both. Both are authorized but only one is in use. Now what I want to do is begin segmenting my network so I have something like this setup:

VLAN1 Server Farm
VLAN300 Users

and etc. Both DHCP servers are on VLAN1 but on different domains. I added an ip helper-address command for interface Vlan300 to point to the DHCP server of my choosing. If I point it to our current DHCP server we are usng, it picks up an address fine. However if I change it to point to the new DHCP server in the new domain, it doesn't pick up an IP. I see the client make a request to the new dhcp server with an IP but the new DHCP just sends a ping and then gets reply saying destination host not found. If I add a static address to the client, he can ping both old and new DHCP server, and vice versa the DHCP servers (both) can ping it.

Anyone know what's up with that? The servers are both 2003 R2.

EDIT: Using these as examples:

Old subnet: 10.1.1.0/24
New subnet: 20.1.1.0/24
DHCP Relay agent: 20.1.1.1/24
DHCP server: 10.1.1.10/24 (with scopes servicing 20.1.1.0/24 addresses)

This is what I see when I run ethereal on the new DHCP server:

Source 20.1.1.1 Destination 10.1.1.10 DHCP DHCP Discover
Source 10.1.1.10 Destination 20.1.1.1 ICMP Destination unreachable (Port unreachable)
Source 20.1.1.1 Destination 10.1.1.10 DHCP DHCP Discover
Source 10.1.1.10 Destination 20.1.1.1 ICMP Destination unreachable (Port unreachable)
Source 20.1.1.1 Destination 10.1.1.10 DHCP DHCP Discover
Source 10.1.1.10 Destination 20.1.1.1 ICMP Destination unreachable (Port unreachable)
Source 20.1.1.1 Destination 10.1.1.10 DHCP DHCP Discover
Source 10.1.1.10 Destination 20.1.1.1 ICMP Destination unreachable (Port unreachable)

 

[bsobel]

Originally posted by: oddyager
My company is in the process of migrating to a new domain (and also moving to a new IP subnet) and one of the things they wanted to do is make a new DHCP server. So currently right now we have 2 domains with a dhcp server in both. Both are authorized but only one is in use. Now what I want to do is begin segmenting my network so I have something like this setup:

VLAN1 Server Farm
VLAN300 Users

and etc. Both DHCP servers are on VLAN1 but on different domains. I added an ip helper-address command for interface Vlan300 to point to the DHCP server of my choosing. If I point it to our current DHCP server we are usng, it picks up an address fine. However if I change it to point to the new DHCP server in the new domain, it doesn't pick up an IP. I see the client make a request to the new dhcp server with an IP but the new DHCP just sends a ping and then gets reply saying destination host not found. If I add a static address to the client, he can ping both old and new DHCP server, and vice versa the DHCP servers (both) can ping it.

Anyone know what's up with that? The servers are both 2003 R2.

Sounds like your not seeing broadcasts from the new dhcp server back to the old subnet... Are you correctly configured to forward broadcast messages back?

 

[oddyager]

Originally posted by: bsobel

Originally posted by: oddyager
*snip*
Anyone know what's up with that? The servers are both 2003 R2.

Sounds like your not seeing broadcasts from the new dhcp server back to the old subnet... Are you correctly configured to forward broadcast messages back?

Sorry, must be a long day for me here. I'm not sure what you mean by that. As far as routing goes, everytihng should be okay since I can ping. The new DHCP server doesn't even seem to broadcast back an offer as I expect it should after receiving a DHCP broadcast. It just does a Ping right after on the dhcp relay agent and always fails, though if I do the ping myself it works.

 

[bsobel]

Sorry, must be a long day for me here. I'm not sure what you mean by that. As far as routing goes, everytihng should be okay since I can ping. The new DHCP server doesn't even seem to broadcast back an offer as I expect it should after receiving a DHCP broadcast. It just does a Ping right after on the dhcp relay agent and always fails, though if I do the ping myself it works.

The fact that you can ping does NOT mean you have broadcast messages routed back. The ping it is doing is to see if the address is in use, it should be going to the target address, not the relay (unless I really dont understand your config). Have you confirmed that no broadcast occurs on the server side (vs not receiving it at the client?)

Bill

 

[ITJunkie]

I guess one question I would have is why are you using ipaddress-helper if you are using a relay-agent too? You should only need one or the other.

Also, and maybe I don't quite understand your current setup but you aren't running both those subnets under one VLAN are you?

 

[oddyager]

sorry, long day for me. They are one and the same. The vlan300 interface on my core switch is acting as a dhcp relay (hence the ip helper address command). So basically I have a floor switch that is all under vlan300 and by using ip helper address it forwards the dhcp broadcasts to the new dhcp server.

Also, I can confirm that I see no broadcasts (well, dhcp type broadcast) coming from the new dhcp server. I ran ethereal for a few minutes and every time it sees a broadcast from the client, immediately following is a ICMP response indicating port unreachable.

Originally posted by: ITJunkie
I guess one question I would have is why are you using ipaddress-helper if you are using a relay-agent too? You should only need one or the other.

Also, and maybe I don't quite understand your current setup but you aren't running both those subnets under one VLAN are you?

They are different vlans.

 

[spidey07]

Is the scope enabled?

If you're getting a destination unreachable then that means the DHCP server service isn't running or you have it disabeled.

Essentially it means that UDP port isn't open.

 

[oddyager]

Originally posted by: spidey07
Is the scope enabled?

If you're getting a destination unreachable then that means the DHCP server service isn't running or you have it disabeled.

Essentially it means that UDP port isn't open.

Yes, the scope is enabled. I double-checked the scope options as well and it is fully authorized.

 

[spidey07]

then the service isn't running or a firewall on the box is preventing communication.

Also, don't use 20. addresses. Those are public and could cause you problems.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

 

[bsobel]

Originally posted by: spidey07
Is the scope enabled?

If you're getting a destination unreachable then that means the DHCP server service isn't running or you have it disabeled.

Essentially it means that UDP port isn't open.

The destination unreachable is on the dhcp checking if the address is in use. The client isn't causing it (a broadcast isn't going to give him an unreachable message...)

 

[oddyager]

Originally posted by: spidey07
then the service isn't running or a firewall on the box is preventing communication.

Also, don't use 20. addresses. Those are public and could cause you problems.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

No firewall on the guy. And services are definitely up. I restaretd them just to make sure and the same results.

The above mentioned IPs were just examples and not actual addresses I'm using.



Do you think it's because I have both old and new dhcp servers on the same subnet (even though they are on different domains) is causing the issue?

 

[spidey07]

Originally posted by: bsobel

The destination unreachable is on the dhcp checking if the address is in use. The client isn't causing it (a broadcast isn't going to give him an unreachable message...)

Not really. The DHCP server doesn't send a broadcast for the offer, it sends it to the router's IP address (relay-agent).

The destination unreachable (port unreachible) means the port is closed.

 

[bsobel]

Originally posted by: spidey07

Originally posted by: bsobel

The destination unreachable is on the dhcp checking if the address is in use. The client isn't causing it (a broadcast isn't going to give him an unreachable message...)

Not really. The DHCP server doesn't send a broadcast for the offer, it sends it to the router's IP address (relay-agent).
The destination unreachable (port unreachible) means the port is closed.

Duh, I missed the whole relay agent discussion.

 

[oddyager]

Originally posted by: spidey07

Originally posted by: bsobel

The destination unreachable is on the dhcp checking if the address is in use. The client isn't causing it (a broadcast isn't going to give him an unreachable message...)

Not really. The DHCP server doesn't send a broadcast for the offer, it sends it to the router's IP address (relay-agent).

The destination unreachable (port unreachible) means the port is closed.

I don't know what I'm overlooking here. I can't think of any way how on the server itself that port is closed. No firewall. I disabled the virusscan for good measure. The services are definitely all up. It's authorized.

 

[spidey07]

dumb question - what UDP port is it coming in on? I think dhcp is 163.

Any "no forward protocol" commands on the router? But it sounds like the relay agent is doing it's job.

 

[oddyager]

Originally posted by: spidey07
dumb question - what UDP port is it coming in on? I think dhcp is 163.

Any "no forward protocol" commands on the router? But it sounds like the relay agent is doing it's job.

When I look at the ICMP packet it sends out after it sees the DHCP broadcast, it says UDP port 67.

No "no forward" rules either on the router. I'm pretty confident on the network side of things it should be okay because if I point it to our current DHCP server it works perfectly fine. The only difference between the two is that they are on different domains and ADs (same subnet and vlan).

 

[nweaver]

Are you sure both are authorized? I would think the server 2003 DHCP AD based one would deauth the 2000 AD based one.

I know that an AD authed server will deauth a non AD one (I have had several do that to my lab DHCP server).

I would guess it's an issue with scope and/or relay agent.

Here is what I would try...

1. Make sure you have a scope with the correct router statement for each VLAN on the new DHCP server
2. Turn off DHCP on old server
3. Reboot and make sure new server is authed and serving IP's on the local VLAN
4. Make sure the relay agent is correctly configured
5. Test on second VLAN

 

[oddyager]

Originally posted by: nweaver
Are you sure both are authorized? I would think the server 2003 DHCP AD based one would deauth the 2000 AD based one.

I know that an AD authed server will deauth a non AD one (I have had several do that to my lab DHCP server).

I would guess it's an issue with scope and/or relay agent.

Here is what I would try...

1. Make sure you have a scope with the correct router statement for each VLAN on the new DHCP server
2. Turn off DHCP on old server
3. Reboot and make sure new server is authed and serving IP's on the local VLAN
4. Make sure the relay agent is correctly configured
5. Test on second VLAN

Yes, both are authorized and both are on 2003 Server R2. Both are on separate domains. The tricky thing is I can't turn off DHCP on the older server since its currently servicing our users (users on both domains too). I need to be able to test the new DHCP in parallel in some way.

 

[bwatson283]

If on diff segements make sure your router can allow the dhcp pass through.

I have had issues that you have to be logged onto the parent and auth the box instead on doing it locally.

 

[nweaver]

ip-helper only allows one IP per VLAN iirc...are you trying to put 2 in there?

 

[bwatson283]

to update my post above, locally it may appear activated. But log onto parent and double check. It has happened to me once.

 

[oddyager]

Originally posted by: nweaver
ip-helper only allows one IP per VLAN iirc...are you trying to put 2 in there?

No. Both servers are on VLAN1 so basically anything on our current network now will grab IP from them (though right now only one server has their scopes activated to service dhcp requests). I created a new VLAN and that new VLAN's ip-helper is pointing to the new DHCP.

 

[nweaver]

so VLAN1 is where the 2 DHCP servers are located
Scope has the router listed as gateway for a segment

Vlan2 is live, ip-helper address is Oldserver
Vlan3 is testing, ip-helper address is Newserver

putting a dhcp client on Vlan3 results in an address from Oldserver?

 

[oddyager]

Originally posted by: nweaver
so VLAN1 is where the 2 DHCP servers are located
Scope has the router listed as gateway for a segment

Vlan2 is live, ip-helper address is Oldserver
Vlan3 is testing, ip-helper address is Newserver

putting a dhcp client on Vlan3 results in an address from Oldserver?

Vlan3 is getting no address. Newserver sees dhcp broadcast from vlan3 but instead of dhcp offer rpely it does ping to port 67 on the gateway (which i thought was odd). If Vlan3 ip-helper is oldserver, it works fine.

 

[Smilin]

Ok, that network trace isn't making a lot of sense to me. Any chance you could paste the full frames in here? If you are immediately getting an error just a couple would do.

In your "trace" we're seeing a unicast discover come in meaning it was indeed sent from your relay.
Then it appears there is an ICMP destination unreachable sent back to the relay?? That makes no sense.

If a discover is arriving the server will respond. If it does not, check to be sure the DHCP server is actually listening and the service is running. (you activated it in AD right?)

Also what happens when a local machine (10.x) tries to get an addy?


Stuff I need:
Some real full frames from ethereal (don't be scared..spew it out, electrons are free )
Ipconfig /all output from the new server.
Answers I need:
Is it activated in AD?
What happens when local machine gets an addy?


As a shot way in the dark with no other info: A common misconfig I see when folks are doing Vlans is letting broadcast info leak from one lan to another. In that case DHCP will try to issue a local address to a host on a different subnet. No idea if that's happening here based on info seen so far. It's just a common one (as is failing to activate).