Hi

That's interesting about binding outside the pool. I didn't realize that the act of binding would trigger a DHCP settings request for that address even though the bound address is outside the pool; I'll go and experiment with that one now

As to the main issue, from what I've observed, the DHCP is predictable in that it issues addresses sequentially from the bottom of the pool up. It is still doing that, but that it is doing it to the same client makes me think it has to be a bug (as you say).

I think the next step is an email to support to see if they are aware of it.

Bri

Hi Rothers and NJH

Time to consider eating my hat! Being Scottish, I’ll add salt and sauce then put it on a roll first (no added salad, of course; that'd be far too healthy).

I’ve just tried your suggestion and moved the DHCP pool well away from my MAC-IP bound range, and yes, the bound ones are still all configured correctly even though they are now outside the DHCP pool. I didn’t realize that as long as the DHCP server was enabled, bound addresses outside the pool would be allocated the network info. Is this the politically correct procedure for binding, or is it a feature specific to Draytek? I’ll do some research tomorrow and also consult my friends (IT guru’s) at the weekend to see what the consensus is; thank you both for the heads up on this as I was totally unaware of it.

As to the main issue - DHCP re-allocation incrementing the address by one at every reboot - I’ve just had a response from Draytek support suggesting I telnet in and experiment with different setCacheLife settings, so I’ll check that out in a day or so to see if I can tweak it to a more suitable timescale. I’ll first check to see if separating the DHCP pool and bound addresses has made any difference so that we know if that was somehow causing the problem. I’ve also asked what the default cache life is set to (or if there’s a command to display it) so I can check it first (as opposed to just steaming in and changing it). I'll post the results as soon as I've had a chance to fully test everything.

Bri

Briain wrote: Is this the politically correct procedure for binding, or is it a feature specific to Draytek?

TBH, I've no idea. I think I read it somewhere but cannot be sure. To me it just makes sense to keep one set of IP's outside the range of the other.

Briain wrote: As to the main issue - DHCP re-allocation incrementing the address by one at every reboot - I’ve just had a response from Draytek support suggesting I telnet in and experiment with different setCacheLife settings, so I’ll check that out in a day or so to see if I can tweak it to a more suitable timescale. I’ll first check to see if separating the DHCP pool and bound addresses has made any difference so that we know if that was somehow causing the problem. I’ve also asked what the default cache life is set to (or if there’s a command to display it) so I can check it first (as opposed to just steaming in and changing it). I'll post the results as soon as I've had a chance to fully test everything.

I'd be disappointed if this made any difference. Rebooting the Draytek should clear the cache, so what is the point of changing the default life?

With the telnet commands, if you issue a command followed by " ?", the Draytek will give you the next level of commands. If you a issue command which usually sets a parameter but without a parameter value, it normally gives you the current value of the parameter.

I have my bound IPs in a diferent range to the rest and it works perfectly. The non bound PCs get the same IP if the lease has not expired when they reconnect the next day. If a new IP is required as far as I can see the first available IP from the pool is allocated.

Hi Folks

Thank you both for your comments.

Howard
You mention the next day, but the problem manifests itself only with shorter timescales (<15 minutes).

The issue seems to be when rebooting a client. In the case of the Cisco 1252 WAP this process takes about 100 seconds. I think it's quite long into that 100 seconds when it requests an address, but even if it isn't, second and third reboots still result in different addresses being allocated. I've not timed it exactly, but it seems to need about 15 minutes to clear the cache and thus enable the initial address to be reallocated.

NJH
I have had a look and you can show the cache life by simply typing 'ip arp setCacheLife' without any arguments. As can be seen below, the current cache life is 60 seconds. Whilst this could be too long to cause issues with a single client reboot (which could be under 60s for request of IP) I'd expect the initial IP address to be issued at second reboot (i.e. way over 60s). That it seems more like several minutes seems to indicate a different problem.

I've moved the DHCP pool away from the bindings and will see if that has made any difference (it could just be that this was upsetting things). If not, I'll then try (as Draytek suggest) dropping the cache life to 10 seconds then see if that changes anything. I'll hopefully post back an update later today.

FYI below is a screen dump of my telnet response



Password: **********

Type ? for command help

> ip arp setCacheLife
The current arp cache life is: 60 seconds

Usage:
ip arp setCacheLife <time>
where time = 10, 20, 30,....2550, base unit is 10 secs
e.g. ip arp setCacheLife 10, sets the cache life to 10 seconds

>

Bri

Hi

In theory a client should check in with the DHCP server at 50% of the lease time. You might want to check out DHCP lease periods are correct/default.

http://www.forum.draytek.co.uk/viewtopic.php?t=11683&highlight=dhcp+lease

All clients on my 2820 seem to always get the same IP unless I change their settings to a manual IP - then next time they change to auto they get a new IP.

See also: http://technet.microsoft.com/en-us/library/cc958935.aspx

Does this problem appear with a computer connected? Just wondering if your "updating" of the WAP (firmware?) is causing it to not actually request a renewal? (Not 100% sure but I think its partly up to the client to make the correct request in the first place?)