DrayTek UK Users' Community Forum
Help, Advice and Solutions from DrayTek Users
2820 3.3.3 DHCP: Non-bound clients change IP every reboot
- briain
- Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 80
- Thank you received: 0
09 Mar 2010 13:44 #1
by briain
2820 3.3.3 DHCP: Non-bound clients change IP every reboot was created by briain
Hi
This is odd...
I'm running 2820Vn with everything on my network DHCP (and IP's bound to MAC addreses). I've a DHCP pool set to start at 10 (pool count 50) and bound everything to an even address (10, 12, 14 etc)*. The 2820 works well like this, but one thing that's driving me nuts is that when I'm working on anything which is temporarily connected to my network, whenever I reboot it, the issued address changes to the next free one up the list. It's almost like the 2820 thinks the other address is still in use and is thus forced to ignore the lease time and issue a new one.
By example, inserting an alien client will obviously appear on .11, but after rebooting, it'll appear on .13, then rebooting again it will appear on 15. I've been updating Cisco WAP's and the're hopping about all over the place whenever I reboot them. It's enough to drive you to drink (too late in my case).
Incidentally, refreshing the MAC-IP binding table in the web based 2820 config page still shows the previous address for ages and ages. It also takes ages to show the re-issued new one. The result of this is that I have to use a command prompt and manually ping all the free addresses until I chance upon the client's new one.
Has anyone else come across this issue (or anything similar)? If so, has anyone else found a fix for it? I wonder if it's it a flaw in the firmware (I'm on 3.3.3_232201).
Bri
* FYI My DHCP bindings are set like the above to help me remember what's what when I look at the list. I have PC's/PDA's on 10, 12, 14, 16 etc; I have media devices (Linn DS's/Sonos) on 20, 22, 24, 26; I then have my WAP on 50. I'll maybe change things to leave 10 consecutive free addresses below my first bound one, but I still think this shouldn't happen even with my current address scheme.
This is odd...
I'm running 2820Vn with everything on my network DHCP (and IP's bound to MAC addreses). I've a DHCP pool set to start at 10 (pool count 50) and bound everything to an even address (10, 12, 14 etc)*. The 2820 works well like this, but one thing that's driving me nuts is that when I'm working on anything which is temporarily connected to my network, whenever I reboot it, the issued address changes to the next free one up the list. It's almost like the 2820 thinks the other address is still in use and is thus forced to ignore the lease time and issue a new one.
By example, inserting an alien client will obviously appear on .11, but after rebooting, it'll appear on .13, then rebooting again it will appear on 15. I've been updating Cisco WAP's and the're hopping about all over the place whenever I reboot them. It's enough to drive you to drink (too late in my case).
Incidentally, refreshing the MAC-IP binding table in the web based 2820 config page still shows the previous address for ages and ages. It also takes ages to show the re-issued new one. The result of this is that I have to use a command prompt and manually ping all the free addresses until I chance upon the client's new one.
Has anyone else come across this issue (or anything similar)? If so, has anyone else found a fix for it? I wonder if it's it a flaw in the firmware (I'm on 3.3.3_232201).
Bri
* FYI My DHCP bindings are set like the above to help me remember what's what when I look at the list. I have PC's/PDA's on 10, 12, 14, 16 etc; I have media devices (Linn DS's/Sonos) on 20, 22, 24, 26; I then have my WAP on 50. I'll maybe change things to leave 10 consecutive free addresses below my first bound one, but I still think this shouldn't happen even with my current address scheme.
Please Log in or Create an account to join the conversation.
- njh
- Offline
- Member
-
Less
More
- Posts: 306
- Thank you received: 0
09 Mar 2010 17:32 #2
by njh
2900Gi/v2.5.6; 2900/v2.5.6
Replied by njh on topic 2820 3.3.3 DHCP: Non-bound clients change IP every reboot
I do not have the answer as the connecting device should request its previously known IP and, if available, the router should give it. Obviously it is not working for some reason.
Why do you have your bound IP's in your DHCP range? This is courting disaster. If one of your bound machines is not on when the router reboots, it is conceivable that the router will hand out that IP to another device requesting an IP by DHCP. You could then end up with 2 devices on the same IP address. You should really have your bound IP's outside your IP pool range. Rather than re-bind your IP's, the easy thing to do is change the DHCP range.
To find the IP of the new device, can you look at the ARP cache (in Management Diagnostics) on the 2820? You can on the 2600 and 2900 series but they have a different interface.
Why do you have your bound IP's in your DHCP range? This is courting disaster. If one of your bound machines is not on when the router reboots, it is conceivable that the router will hand out that IP to another device requesting an IP by DHCP. You could then end up with 2 devices on the same IP address. You should really have your bound IP's outside your IP pool range. Rather than re-bind your IP's, the easy thing to do is change the DHCP range.
To find the IP of the new device, can you look at the ARP cache (in Management Diagnostics) on the 2820? You can on the 2600 and 2900 series but they have a different interface.
2900Gi/v2.5.6; 2900/v2.5.6
Please Log in or Create an account to join the conversation.
- njh
- Offline
- Member
-
Less
More
- Posts: 306
- Thank you received: 0
09 Mar 2010 18:08 #3
by njh
2900Gi/v2.5.6; 2900/v2.5.6
Replied by njh on topic 2820 3.3.3 DHCP: Non-bound clients change IP every reboot
Total brain fart here. :oops: You should be able to bind addresses in your DHCP pool. It is just that I would not. It is fixed IP's that you should never allocate in your DHCP pool, but you have not.
2900Gi/v2.5.6; 2900/v2.5.6
Please Log in or Create an account to join the conversation.
- rothers
- Offline
- Member
-
Less
More
- Posts: 143
- Thank you received: 0
09 Mar 2010 18:57 #4
by rothers
Replied by rothers on topic 2820 3.3.3 DHCP: Non-bound clients change IP every reboot
Nevertheless I would not do this either, I have all my static/bound addresses in the 2-199 range and 200+ allocated to DHCP dynamic, all works fine.
Please Log in or Create an account to join the conversation.
- briain
- Topic Author
- Offline
- Junior Member
-
Less
More
- Posts: 80
- Thank you received: 0
21 Mar 2010 12:30 #5
by briain
Replied by briain on topic 2820 3.3.3 DHCP: Non-bound clients change IP every reboot
Hi Folks
Thanks very much for your replies. Unless I am misinterpreting both of your posts, I see the entire point of binding as being a way to deliver the benefits of a fixed address scheme whilst maintaining the convenience of DHCP, and that your comments about binding outside the pool could indicate that you're maybe considering a slightly different network strategy to the one I've deployed; is that maybe the case?
As you have noted, I have no static addresses in use; my entire setup relies on the DHCP server issuing DHCP addresses to the clients and the entire point of binding them is to ensure that the same DHCP address is issued should a 'bound client' be switched off for longer than the DHCP lease time. To me, this is the whole point of binding; it is to give the benefits of a static scheme (i.e. to have a virtual fixed IP address for the clients) but to have the benefits of DHCP (central management); is this not the main reason why this feature exists? Surely binding them to addresses outside the DHCP pool would not work unless you also configured clients with static addresses (and network settings) then bound them, but surely there's no point in binding MAC's to the static addressed clients as they're not in any danger of changing anyway; maybe I'm missing the point and this feature is of use in other ways that I'm not considering. Conversely, binding a DHCP pool address should cause no conflicts since it will never be issued to another client even if the bound client is not present; the bound address is effectively 'reserved' for issue only to the bound MAC address.
To me, the best DHCP network setup would be to allocate a pool of say, 40 addresses, then bind the highest 10 to things that you wish to 'pin down' and that leaves first 30 free for issue to visiting clients. The problem with my system is not that there are conflicts with the bound ones, it's that any visiting client isn't issued the same address (from the unbound range) whenever it's rebooted. It looks like the Draytek isn't releasing the address when the visiting client shuts down (which would make sense as there is a fixed lease time; I think it's 24 hours) but that it either isn't 'recognizing' that it is the same client after the client's re-boot, or more likely, that it thinks the previous address is simply not available (see below).
I've rebooted a WAP (unbound DHCP) 5 times and each time I do so, it is issued its previous address +1. Curiously, it does revert to the initial address at about the 5th or 6th reboot (about 15 minutes after the initial reboot), so to me, it looks more like it’s assuming the previously issued addresses are still in use for up to 15 minutes after the client has actually been disconnected from the network, and that even though the re-connected client obviously has the same MAC address (and it’s obviously well within the 24h DHCP lease time), it simply can't re-issue the previous address as it thinks it's still in use for something else, and it is thus forced to override the 24h DHCP lease 'rule' and issue a new one. To me, that feels like a bug in the firmware.
Interesting eh? It'd be interesting to hear what Draytek think about all this; I'll maybe call them next week to see if they can shed any new light on things![:) :)](/media/kunena/emoticons/3.png)
Bri
Thanks very much for your replies. Unless I am misinterpreting both of your posts, I see the entire point of binding as being a way to deliver the benefits of a fixed address scheme whilst maintaining the convenience of DHCP, and that your comments about binding outside the pool could indicate that you're maybe considering a slightly different network strategy to the one I've deployed; is that maybe the case?
As you have noted, I have no static addresses in use; my entire setup relies on the DHCP server issuing DHCP addresses to the clients and the entire point of binding them is to ensure that the same DHCP address is issued should a 'bound client' be switched off for longer than the DHCP lease time. To me, this is the whole point of binding; it is to give the benefits of a static scheme (i.e. to have a virtual fixed IP address for the clients) but to have the benefits of DHCP (central management); is this not the main reason why this feature exists? Surely binding them to addresses outside the DHCP pool would not work unless you also configured clients with static addresses (and network settings) then bound them, but surely there's no point in binding MAC's to the static addressed clients as they're not in any danger of changing anyway; maybe I'm missing the point and this feature is of use in other ways that I'm not considering. Conversely, binding a DHCP pool address should cause no conflicts since it will never be issued to another client even if the bound client is not present; the bound address is effectively 'reserved' for issue only to the bound MAC address.
To me, the best DHCP network setup would be to allocate a pool of say, 40 addresses, then bind the highest 10 to things that you wish to 'pin down' and that leaves first 30 free for issue to visiting clients. The problem with my system is not that there are conflicts with the bound ones, it's that any visiting client isn't issued the same address (from the unbound range) whenever it's rebooted. It looks like the Draytek isn't releasing the address when the visiting client shuts down (which would make sense as there is a fixed lease time; I think it's 24 hours) but that it either isn't 'recognizing' that it is the same client after the client's re-boot, or more likely, that it thinks the previous address is simply not available (see below).
I've rebooted a WAP (unbound DHCP) 5 times and each time I do so, it is issued its previous address +1. Curiously, it does revert to the initial address at about the 5th or 6th reboot (about 15 minutes after the initial reboot), so to me, it looks more like it’s assuming the previously issued addresses are still in use for up to 15 minutes after the client has actually been disconnected from the network, and that even though the re-connected client obviously has the same MAC address (and it’s obviously well within the 24h DHCP lease time), it simply can't re-issue the previous address as it thinks it's still in use for something else, and it is thus forced to override the 24h DHCP lease 'rule' and issue a new one. To me, that feels like a bug in the firmware.
Interesting eh? It'd be interesting to hear what Draytek think about all this; I'll maybe call them next week to see if they can shed any new light on things
![:) :)](/media/kunena/emoticons/3.png)
Bri
Please Log in or Create an account to join the conversation.
- njh
- Offline
- Member
-
Less
More
- Posts: 306
- Thank you received: 0
21 Mar 2010 14:19 #6
by njh
2900Gi/v2.5.6; 2900/v2.5.6
Replied by njh on topic 2820 3.3.3 DHCP: Non-bound clients change IP every reboot
There is no problem binding MAC addresses to IP addresses outside the range of the DHCP pool. I do it on my Draytek routers and the equivalent my Linux box and it works fine where the clients request addresses by DHCP. The clients do not need a fixed IP but they always get the same address.
It does, however, seem like you have found a bug as a client normally asks for its last known address. If you've just rebooted the router, its DHCP lease table and ARP cache should be clear at that point, and that address should be free and the router should hand it out.
I remember seeing something about security where the next address DHCP should not be predictable. My Linux box is not. I wonder if it has something to do with that?
It does, however, seem like you have found a bug as a client normally asks for its last known address. If you've just rebooted the router, its DHCP lease table and ARP cache should be clear at that point, and that address should be free and the router should hand it out.
I remember seeing something about security where the next address DHCP should not be predictable. My Linux box is not. I wonder if it has something to do with that?
2900Gi/v2.5.6; 2900/v2.5.6
Please Log in or Create an account to join the conversation.
Moderators: Sami
Copyright © 2024 DrayTek