Hello, I am working on an SG300-28P that is doing dhcp for a vlan. The network pool is showing the number of leased addresses is equal to the size of the DHCP scope in the settings. But when I look at the address bindings, there are plenty of leases showing as in the expired state. New devices aren't able to get any ip addresses on the network. I had to manually delete the addresses from the address binding table.
I am missing something here? Shouldn't IP addresses showing as expired be available for assignment to a new device attaching to the network? Or is there some sort of grace period after an address lease is expired before it can be handed out again by the DHCP server and, if so, what is that grace period?
As an FYI, I am running the latest firmware 126.96.36.199.
Try to configure a lease time and see if this fixes it for you. This will configure the amount of time it is active in the DHCP database.
The lease time had been configured for one day so I don't believe that is the issue.
But when looking at the address bindings table, the table shows leases had expired and the date in the expired column was in the past for example:
192.168.1xx.xxx MAC Address 94:eb:xx:0x:xx:xx 2014-Aug-09 07:43:23 Dynamic Expired
The August 9 date shown above was a full 24 hours past. Yet the address was included in the count of addresses in the network pools menu option under the dhcp section.
So my question is: why does the table still show expired leases even a day after the expiring time and why aren't they available for new devices booting up in the vlan?
They are using concept of frozen IP addresses.
I hope it answers your question.
Thanks, I am not familiar with the concept of frozen IP addresses.
Are you suggesting that Cisco has design the dhcp server to work this way? And is this something that can be configured so that the dhcp server will reassign any available expired address?
If you see the same issue with 1.4 firmware and matching boot code which for 300 series is 1.3.5 than I would strongly recommend you to open ticket with Support Team:
As I mentioned above I also have this issue and it's only noticable of a well used guest network. Lease time is 90 minutes (restaurant) with a pool of 240 possible leases. Every couple of weeks I get a call that no one can connect and I have to remote in and manually remove all the leases. Typically there's a few active and over 230 expired and it appears the switch refuses to overwrite to oldest in the table. I can see the switch wanting to hold on to expired leases just so they can re-assign the same address to the same host expecting them to re-request but when they get a request and there's no slot left dump the oldest and write the new client to the array.
This and the convoluted MAC address vs Client-ID binding dilemma makes me think these switches are just too buggy for prime time. I can have less headaches spending less money.
I just found a newer firmware 14088.ros which uses boot 13506.rfb but no release notes, at least that I can find. Maybe these two extremely annoying issues have been resolved. I'll test on my office SG500 (if there's a new version for that) and see if it helps.
No I haven't bothered, I started another thread looking for the release notes and someone sent me a link to it and in reading that doc there was no mention of of this or the other issue that drives me nuts being addressed so I figure testing would be pointless not to mention a PITA to set up on a functioning system.
Anyone from Cisco care to weigh in on this one? Is this an actual bug with these switches? Is there some way to escalate this to Cisco support?
The best way to report such issues is by opening ticket with Cisco Small Business Support team:
Wouldn't that be easier for you? I've already waisted enough time dealing with these switches and their funky bugs. For no one from Cisco who monitors these forums to at least test to confirm or deny this issue which is a very basic requirement of a switch is just laziness.
Just like the issue of using a client id instead of a mac to create a static bind and the solution we get from Cisco is, well just connect the device first and see how it responds, if it uses a mac then use a mac but if it uses a client id then do the same. Every switch should be able to do either and either prepend or remove the leading byte or just ignore it in their string comparisons to see if a dhcp request matches an entry in the static bind table. Does SMB get the engineers straight out of bootcamp.?