Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

sg300-28P dhcp server not using expired address

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




Everyone's tags (2)

Hi ifrad, Try to configure a

Hi ifrad,


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.

-Tom Please mark answered for helpful posts
New Member

The lease time had been

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:     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?



Cisco Employee

Hi ifradsham,They are using

Hi ifradsham,

They are using concept of frozen IP addresses. 

1. When a DHCP client request an IP Address which is Allocated or Frozen, the same address this DHCP client received in the past will be allocated to it.
2. Frozen addresses are released and can be given to other DHCP clients only when the DHCP pool is empty.


I hope it answers your question.


New Member

Thanks, I am not familiar

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?

New Member

All she said was something

All she said was something that's already been said and nothing regarding the problem. Leases stay in the table in the expectation that expired hosts will return in which case the switch will hand out the same address. Once all available ip's are issued upon the next request the switch is supposed to hand a previously assigned expired address and this is where we're seeing the problem because it's not assigning previously assigned expired addresses.
Cisco Employee

Hi All,If you see the same

Hi All,

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:




New Member

As I mentioned above I also

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.


New Member

Yeah this is a very annoying

Yeah this is a very annoying problem and has been discussed months a ago. I had to remote into a switch last night and manually delete all expired dynamic leases out of the binding table so new host can connect, this is a guest vlan with a scope of 240 ips and a 90 minute lease time. This really needs to be fix as does the the issue with Mac vs client I'd use in static binds. You should not have to first connect a device to how it responds before being able to make a static bind that will work. Long standing unresolved issues like these make me think it's time to find another brand or model.
New Member

Thanks.  Does anyone know if

Thanks.  Does anyone know if there is a Cisco bug raised on this issue? 

New Member

I just found a newer firmware

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.

New Member

Did you have any luck with

Did you have any luck with your testing?

New Member

No I haven't bothered, I

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.  

New Member

Anyone from Cisco care to

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?

Cisco Employee

Hi Ifradsam,The best way to

Hi Ifradsam,

The best way to report such issues is by opening ticket with Cisco Small Business Support team:

Kind regards,


New Member

Wouldn't that be easier for

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.?

CreatePlease to create content