I use bound IP's within my DHCP pool and I have no problems at all. In my setup the DHCP server does not allocate the next IP address in the range to a requesting device if that IP address has been reserved in the bound MAC address pool.

Jon

Hi

> ip arp setCacheLife 10
The arp cache life is set to: 10 seconds

> srv dhcp leasetime ?
% srv dhcp leasetime <Lease Time (sec.)>
% Now: 259200

> ip arp setCacheLife ?
The current arp cache life is: 10 seconds

(The last bit was just to check it had accepted the change)

Looks like DHCP lease time is 72 hours which seems pretty fair.

As to the reboot issue, it seems that setting the cache life to 10 seconds doesn't resolve the reboot issue; it still has a different IP address after a reboot. The total reboot process takes over a minute, but the IP address will be no doubt be requested way before 60+ seconds it takes to settle down. That said; it must surely be a lot more than 10 seconds.

My next test was to initiate a reboot (via the 1200's web config page) then physically removed the Ethernet cable for 40+ seconds (just after sending the reboot request). I connected it back up (whilst the 1200 was still booting) again, the IP address had changed.

My next test was to completely remove the power from the 1200 (for 15 seconds) and that was okay; the IP address did not change. It looks like a system reboot on a Cisco 1200 or 1250 series WAP somehow causes the problem (even with the network cable removed fro longer than the ARP cache flush time) so it seems they need the power physically removed as opposed to just being warm rebooted.

It would still be nice to figure out whether this is a global issue with Cisco WAP's, or whether it's something to do with the Draytek. I'll go try this on some friends’ installations to see if it happens with other brands of router/switch combinations.

Bri

jon3905 wrote: I use bound IP's within my DHCP pool and I have no problems at all. In my setup the DHCP server does not allocate the next IP address in the range to a requesting device if that IP address has been reserved in the bound MAC address pool.

Jon

Hi Jon

Yes, it didn't appear to be related to the problem, but I must find out what the 'official' method actually is. With the Draytek, you can certainly move the pool and the bound ones still work fine. I’ve heard of both schemes being used (in various systems) but I assume one is correct and the other is wrong. Maybe not; maybe they’re both acceptable.

I'm about to set up the DHCP server in my Cisco 1252 WAP, then turn of the Draytek DHCP server to see what happens with it set to have bound addresses within and outside the pool (i.e. see if it works both ways even with an external DHCP server). I'll also try the same two experiments using only the DHCP server in a Netgear ReadyNAS.

Be fun to see what breaks, when it breaks, why it breaks and if anything voilently explodes for no apparently good reason

Bri

If you turn the DHCP server off in the Draytek, your bound addresses will not be used as your WAP will handle all the DHCP requests. You should only ever have a single DHCP server on a network.

If you are *really* that curious then you might want to read this http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol then install this http://www.wireshark.org/ to see what is really going on.

From my experience and from what others are saying (and your last test) it sounds like an issue with your Cisco WAP. Maybe there is a software update for it?

Regarding DHCP reservations in/outside of scopes - I have done both on Windows servers without any apparent issues.

Hi

Bindings: in DHCP or not in DHCP; that is the question

Sorry, I worded that somewhat poorly; high speed typing + low speed thinking = severe ambiguity. I meant to indicate that I was planning to bind them using the Cisco IOS (and disable the Draytek DHCP/binding functions) then see if it mattered whether they were inside the Cisco DHCP pool or not. I did set it up (and got it allocating addresses) but before I tried the above test, I got myself distracted by reading more documentation:

I noted that one piece of Cisco documentation states ‘Manual bindings are just special address pools’ That’s quite interesting and implies to me that each bound address is effectively an address pool of one. That would point me to thinking that they should maybe be outside the DHCP pool. Other comments (in other Cisco DHCP documentation) are worded in a way which almost subconsciously imply that the DHCP pool and other pools should be separate entities; they don't seem to openly say 'do not do it', but neither do they indicate that one can be a with a subset of the other (as though it's a given that you should know not to).

To make matters even more confusing, the instructions for setting a WAP to DHCP in the Cisco IOS documentation state that 'You can not configure manual bindings within the same pool that is configured with the network command'. On first reading, that would imply the DHCP pool, but in reality the network command is the line used to define the subnet (and optionally also the subnet mask) for the pool, so that doesn’t really make sense; I assume that they are presuming knowledge of a 'well known assumption' that I'm as yet unaware of.

Other (non-Cisco) documentation implies that you can bind address from within a DHCP pool, but despite the fact that I’ve run that scheme here for 2 years (without problem), I'm becoming more and more inclined to think that this is not the correct way forward.

As you say, it seems to work fine either way, so it's all a bit academic, but it would be interesting to know if there's a definite ruling as to what's the right or wrong way to do things. I’ll read it more carefully after a glass of nice red wine and I’m sure it’ll all suddenly fall into place.

WAP address changes after reboot (the original post item)

On the apparent ARP cache issue, it does look like it's a peculiarity of the Cisco WAP's rebooting process. It happens with 1200 and 1250 and with different firmware versions. All the ones I have are now equipped with the latest firmware and still perform this odd trick. I'll definitely try them on other folks networks as that would build up more evidence one way or another. It's not important as you can easily bind any WAP before you start working on it (that's what I've been doing to keep me sane) but it would be cool to find out what's happening as it surprises me that they've not addressed it (no pun intended).

Bri