Introducing SOC Insights for BloxOne Threat Defense: Boost your SOC efficiency with AI-driven insights to eliminate manual work and accelerate investigation and response times. Read the blog announcement here.

NIOS DNS DHCP IPAM

Reply

DHCP: no permitted ranges with available leases

Techie
Posts: 9
5269     0

Hi there

 

So I'm getting DHCPDISCOVER - "no permitted ranges with available leases" errors in one of my member logs (member A) when there are at least 30% of the IPs marked as free in that particular DHCP range.

 

I am running DHCP failover between this primary member (A) and another member (B) with load balancing set all the way to Primary (A) since it is a remote site. All the errors are reported by member A.

 

My understanding is that most of the leases will live with member A (the primary) and only some will live with member B (the secondary) and that member B will only issue leases it holds when member A appears not to respond. Member B will only take over all leases if "partner down" is set is also how I understand the failover procedure. Would member B hold almost 30% of the leases?

 

It does appear that only 4 or 5 unique MAC addresses are generating this error. Other clients on the same network have received IP addresses.

 

So why am I getting this error? I don't see any "peer holds all free leases" errors - which is what I would expect if member B was the only one left with free leases. Is there any way to see which leases are held by which member? Any ideas?

 

I'm running appliances all round on NIOS 8.2, NTP is configured and working, all members involved can communicate with each other with no problems. Both members are configured as members servers for that particular network. If I look at current leases I can see two entries for each lease, one on member A and one on member B.

 

Thanks for any advice (even if it entails packing up and going for some beer Smiley Tongue )

Re: DHCP: no permitted ranges with available leases

Techie
Posts: 9
5270     0

Just for record purposes - I found the problem to be poorly configured switches and IP telephones that were not moving to the correct VLAN and seem to have been requesting IPs for a different VLAN and the caused the error.

Showing results for 
Search instead for 
Did you mean: 

Recommended for You