New DHCP leases not being obtained across WAN

Because requests are sent using broadcasts, so they cannot cross your WAN link. The solution is to have a DHCP helper/relay on the router (or other sort of device such as server) which serves that remote network. What kind of router do you have over there? Try to reboot it first and if it will not help examine its configuration.

As a good diagnostic option install ethereal (or sniffer of your choice) on the DHCP server and see if requests make their way to M$ box.

What was the patch installed for ?

Are there any changes on your router configuration stationed from those branch offices, like DHCP helper has been removed from the router ? Are you using DHCP relay agent in branch office? If so are there any changes on the server where the DHCP relay agent is installed ?

Thanks for your comments.

There is indeed a DHCP helper on the remote router. Networks team handles this so will contact them to ensure no changes have been made. We are also currently looking through each MS patch to see if any could potentially have impacted the DHCP server (as this is most likely avenue).

Will see what I can do regarding getting a packet sniffer going on the Network. Not too sure about installing it on a Prod DC but from memory think these can be run on any machine and told where to look and what for right?

Thanks again.
Matt

Thanks for the tips! I'm going to be busy seeing which one works...though the 2003 NetMon is a great idea. Thanks!

no problem, look for the below ports:

546      DHCP Client
547      DHCP Server

link: http://www.webopedia.com/quick_ref/portnumbers.asp

So, I'm struggling with this....

The network analyser showed me that the DHCP server is receiving broadcasts and answering requests. Now, a couple of things I need to get my head around:
1. does the DHCP server broadcast back for new requests
2. for renewals, how does the transaction take place in network terms (bcast or not?)

If the answer to 1. is Yes, then I think I have an issue with the router at the remote site either not accepting incoming broadcasts or not forwarding the DHCP correctly (DHCP helper issue). Am I on the right track?

Cheers,
Matt

1. The answer is no. It sending answers directly to specific MAC address in LAN environment and to IP address of remote DHCP helper/relay.
2. It's the same procedure as for obtaining an IP

Besides that, once again, broadcasts will not cross WAN link. The router breaks broadcast domain. So, you need to have a HDCP helper/relay, which will listen for broadcasts in remote network, convert them to unicast and send to the DHCP server. DHCP server in its turn will reply to the helper and it will forward replys to MAC address in remote LAN

So, what would you say the problem was then if renewals are being processed okay between existing clients and the DHCP server but new requests (e.g. for new hardware) aren't getting assigned? If the same process is used for both....if one works then so should the other?

I'm heading down to this remote site early next week, so hope to get more first-hand info rather than what I have at the moment which is all 2nd/3rd hand from previous engineers.

Help appreciated in the mean-time.
Matt

There is a chance, that it's not renewing and just maintaining it's old address...
So, when you will be there, bring a laptop with some sort of sniffer. That way you would be able to see the whole process and determine where it failes. Drop a message here before you go, I'll monitor my email.

Okay cool...though would the lease expiry change in that case?

Will keep you posted. I'm sure we'll get to the bottom of it. I'm convinced that it's not a patching issue as the other scopes are working fine on the local subnets.

Cheers,
Matt

Windows will try to maintain IP even if DHCP will not answer. Expiration time is more important for the server side, so it can release unused addresses and put them back to the pool.

The router restart may fix the issue if helper stuck for any reason. What kind of router do you have at remote location?

If your H/O DHCP is leasing correct IP address there is no reason it will not work in your branch office. Mostly like the issue which is the obvious one is DHCP helper in the router.

If rebooting the router doesn't still fix up the problem,  get a consultant to check the router configuration and ensure the dhcp helper is enable still or at least configure correctly.

Once you sort out your router from the branch office try the below:

start>run> type cmd
ipconfig /renew

Your pc will send a dhcp request broadcast across your WAN and hopefully your DHCP server will knowledge and both client and server will complete the 4 way handshakes.

Good luck and let us know the outcome irrespective.

Further, ensure your branch office clients their TC/IP properties are set to obtain ip address automatically and dns ip too.

So, I'm at the branch office right now. Brought down a laptop which had previously had an IP assigned by DHCP in the 172.16 scope for the head office. Plugged laptop into LAN at branch office and Windows immediately tried to get an IP address in the 172.17 scope. WireShark (running on laptop) showed the outbound DHCP discovery packets from 0.0.0.0 but the DHCP request timed out and no IP was leased. I tried assigning a manual IP on this scope and this worked fine. I then dropped the IP and again tried for a DHCP lease...no luck. I then tried with manually assigned DNS and Gateway IP's in the network config. Same deal -- no lease.

I then logged onto the DHCP server and removed the existing lease from the 172.16 scope in DHCP. Then tried a ipconfig /renew on the laptop and hey-presto, got an IP in seconds.

This seems to point to some configuration of the DHCP server which isn't allowing the host to get a new IP when it has moved scopes. Is this a config that can be changed or is it a 'feature'? All routing and DHCP helper/relays seem to be working at least, as I CAN get a DHCP address assigned.

Any help out there? ;)
Matt

Try releasing the ip first, then renew so it will ask the DHCP server for new ip.

Your problem is your DHCP has lease duration probably set to days or weeks hence your client still stuck with your head office subnet ip so when it tries to access the resource, it cannot because your branch office is in different subnet.

Workaround for traveling users: release then renew ip address:

ipconfig /release
ipconfig /renew

Or, change your lease duration in your DHCP server for one day but that  will flood your network of DHCP traffic which is BAD (i would not recommend it).

Yeah, sorry, should have mentioned that I tried a release/renew first. Nothing worked until removing the old entry. I can see the logic of the DHCP server not wanting to lease another address to a hostname with an un-expired lease, but thought it would be smart enough to realise that it's coming from a new subnet?

Is there any way around this? It used to work, that's the strange thing. Users from HO would come to the BO with a laptop for presentation etc and they would immediately get a new DHCP lease.

??

It seems that I'm back at the Windows patches again?

Try stop and restart the DHCP console.

Welcome to Microsoft world, nobody really knows what's going on, just guessing. Is there an option to run DHCP from the router at BO? What kind of functionality do you need from MS DHCP server?

You mention this was working before those Windows patches were applied, In that case can't you just rollback those patches that may have contributed to this problem. What were those patches exactly?

yeah tvman_od, if you read the original question , the DHCP server was working fine UNTIL some patches were applied ! Why would you want to make the router acting as DHCP when there is a clear sign that there is posibility that those patches have caused this issue, so basically you are moving away from solving the problem and what functionality your expect from MS DHCP server, what do you expect from DHCP server to be a radius server ?

That's my question. What's good to run a single DHCP server for entire company. If WAN is down, then BO can work locally with minor degradation of services. It may not be a case, but WAN links tend to be less reliable then LAN. As a telecom engineer I always think about "plan B" or even "plan C" for network services. Besides that telecom equipment has much more compehencive testing program then the general purpose Microsoft OS. So, running DHCP from the router would be a good alternative to MS DHCP with nobody knows what fixing patches.

Next step will be to identify the patches and then roll them back. Obviously this will take some time to execute, never mind the change controls required -- and we're in a change freeze until after Christmas!!

Think I'll close the question and you guys can share the points, otherwise it might get PAQ'd in the mean time.

Thanks for all your comments. Will add to the question if I get it resolved any time soon!

Matt

Didn't really resolve this issue due to change-control constraints. But the advice of the experts allowed me to track back and replicate the issue and eliminate other possible causes. This will allow me to focus resources on where we now believe the problem lies.

I've also found this: http://forums.techarena.in/showthread.php?t=866462

So before I try and roll back any patches I'm going to remove the Superscope container. I believe that this config has been used in error by a previous engineer as we are not mult-netting.

Regards,
Matt

your DHCP server should give you system event log as to why it disallow to lease an ip to your client.
Also, your client itself has the system event log will explain as to why it was denied obtaining ip from the DHCP server - check the system log from DHCP and your client, do this when you are in the B/O while requesting the DHCP to lease an ip, it has to be there man, got to be.

The event log will tell us why DHCP has refused to lease the ip and why your client was denied.