ISC DHCP Users

Using OMAPI to release a DHCP lease on a failover pair

Classic

List

Threaded

7 messages Options

Isaiah Olson

Using OMAPI to release a DHCP lease on a failover pair

Hello,

I am having some issues getting the OMAPI method for setting a lease to the
released state to work, in order to allow a new client to get the lease. The
servers in question are in a failover pair. The guidance that I have seen
recommends to do the following to manually release a lease on the server
side via OMAPI:

server x.x.x.x
port 7911
key omapi_key (key)
connect
new lease
set ip-address = 1.1.1.1
open
set state = 4
update

In this case, the pool contains only a single address, and it doesn't seem
to work whether I make the change on the just the primary or both the
primary and secondary. In either case, I get the following logs (with the
exception of the state change on the secondary when I have tried not making
any change there):

Primary:
Jul 30 14:02:54 loc3 dhcpd[25263]: lease 1.1.1.1 state changed from active
to released
Jul 30 14:02:58 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: network 1.1.1.0/31: no free leases
Jul 30 14:03:01 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: network 1.1.1.0/31: no free leases
Jul 30 14:03:04 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: network 1.1.1.0/31: no free leases
Jul 30 14:03:07 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: network 1.1.1.0/31: no free leases

Secondary:
Jul 30 14:02:55 loc36 dhcpd[19842]: lease 1.1.1.1 state changed from free to
released
Jul 30 14:02:58 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: peer holds all free leases
Jul 30 14:03:01 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: peer holds all free leases
Jul 30 14:03:04 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: peer holds all free leases
Jul 30 14:03:07 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
1.1.1.0: peer holds all free leases

The pre-existing lease was for a different MAC address than
aa:bb:cc:dd:ee:ff. The device with the old MAC address is still the only one
that is able to get a new lease, even after releasing that lease via OMAPI.
Any guidance on how to get this to work in this case would be appreciated. I
am not sure if the existence of the failover configuration is the cause of
the issue, or if there is another reason for this behavior, but there don't
seem to be any errors or any other info returned by OMAPI which indicate why
this might be happening.

Thanks,
Isaiah

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Gregory Sloop

Re: Using OMAPI to release a DHCP lease on a failover pair

Re: Using OMAPI to release a DHCP lease on a failover pair I've been messing with this recently - OMSHell, not releasing leases - and IIRC [and I may well not, but take it for what it's worth]...
you have to expire the lease and then release it.

You can't go from an active lease to released in one step.

I think there are some details in the list that I recall reading recently - which is why I *vaguely* know. :)

HTH
-Greg

IO> Hello,

IO> I am having some issues getting the OMAPI method for setting a lease to the
IO> released state to work, in order to allow a new client to get the lease. The
IO> servers in question are in a failover pair. The guidance that I have seen
IO> recommends to do the following to manually release a lease on the server
IO> side via OMAPI:

IO> server x.x.x.x
IO> port 7911
IO> key omapi_key (key)
IO> connect
IO> new lease
IO> set ip-address = 1.1.1.1
IO> open
IO> set state = 4
IO> update

IO> In this case, the pool contains only a single address, and it doesn't seem
IO> to work whether I make the change on the just the primary or both the
IO> primary and secondary. In either case, I get the following logs (with the
IO> exception of the state change on the secondary when I have tried not making
IO> any change there):

IO> Primary:
IO> Jul 30 14:02:54 loc3 dhcpd[25263]: lease 1.1.1.1 state changed from active
IO> to released
IO> Jul 30 14:02:58 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: network 1.1.1.0/31: no free leases
IO> Jul 30 14:03:01 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: network 1.1.1.0/31: no free leases
IO> Jul 30 14:03:04 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: network 1.1.1.0/31: no free leases
IO> Jul 30 14:03:07 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: network 1.1.1.0/31: no free leases

IO> Secondary:
IO> Jul 30 14:02:55 loc36 dhcpd[19842]: lease 1.1.1.1 state changed from free to
IO> released
IO> Jul 30 14:02:58 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: peer holds all free leases
IO> Jul 30 14:03:01 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: peer holds all free leases
IO> Jul 30 14:03:04 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: peer holds all free leases
IO> Jul 30 14:03:07 loc36 dhcpd[19842]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
IO> 1.1.1.0: peer holds all free leases

IO> The pre-existing lease was for a different MAC address than
IO> aa:bb:cc:dd:ee:ff. The device with the old MAC address is still the only one
IO> that is able to get a new lease, even after releasing that lease via OMAPI.
IO> Any guidance on how to get this to work in this case would be appreciated. I
IO> am not sure if the existence of the failover configuration is the cause of
IO> the issue, or if there is another reason for this behavior, but there don't
IO> seem to be any errors or any other info returned by OMAPI which indicate why
IO> this might be happening.

IO> Thanks,
IO> Isaiah

IO> _______________________________________________
IO> ISC funds the development of this software with paid support
IO> subscriptions. Contact us at https://www.isc.org/contact/ for more information.

IO> dhcp-users mailing list
[hidden email]
IO> https://lists.isc.org/mailman/listinfo/dhcp-users

--
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x121
EMail: [hidden email]
http://www.sloop.net
---
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Bill Shirley-2

Re: Using OMAPI to release a DHCP lease on a failover pair

In reply to this post by Isaiah Olson

I don't know what your conf or your network looks like, but an IPv4 subnet requires
at lease four addresses:
1.1.1.0/30 network address - unusable
1.1.1.1/30 available
1.1.1.2/30 available
1.1.1.3/30 broadcast address
This may be the problem. Make the pool larger.

Bill

On 7/30/2020 3:22 PM, Isaiah Olson wrote:
> Jul 30 14:02:58 loc3 dhcpd[25263]: DHCPDISCOVER from aa:bb:cc:dd:ee:ff via
> 1.1.1.0: network 1.1.1.0/31: no free leases
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

sthaug

Re: Using OMAPI to release a DHCP lease on a failover pair

> I don't know what your conf or your network looks like, but an IPv4
> subnet requires
> at lease four addresses:
> 1.1.1.0/30 network address - unusable
> 1.1.1.1/30 available
> 1.1.1.2/30 available
> 1.1.1.3/30 broadcast address
> This may be the problem. Make the pool larger.

We have used ISC DHCP with /31 networks for quite a while. Works fine.
Only one address available for the DHCP client, obviously.

Steinar Haug, Nethelp consulting, [hidden email]
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Patrick Trapp

Re: Using OMAPI to release a DHCP lease on a failover pair

Interesting. You would only have two available addresses, right? The network address and the broadcast address? Which one does the device answer to?

From: dhcp-users <[hidden email]> on behalf of [hidden email] <[hidden email]>
Sent: Thursday, July 30, 2020 2:53 PM
To: [hidden email] <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: Using OMAPI to release a DHCP lease on a failover pair

CAUTION: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and know the content is safe.

> I don't know what your conf or your network looks like, but an IPv4
> subnet requires
> at lease four addresses:
> 1.1.1.0/30 network address - unusable
> 1.1.1.1/30 available
> 1.1.1.2/30 available
> 1.1.1.3/30 broadcast address
> This may be the problem. Make the pool larger.

We have used ISC DHCP with /31 networks for quite a while. Works fine.
Only one address available for the DHCP client, obviously.

Steinar Haug, Nethelp consulting, [hidden email]
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

sthaug

Re: Using OMAPI to release a DHCP lease on a failover pair

> Interesting. You would only have two available addresses, right? The network address and the broadcast address? Which one does the device answer to?

When using IPv4 /31 there's really no "network address" or "broadcast
address". There are simply two IP addresses. One is the router and the
other is the client. Supported by lots of equipment, and also ISC
DHCP.

Example:

# Router is at lowest address of the /31
subnet 172.16.1.10 netmask 255.255.255.254
{
option routers 172.16.1.10;
range 172.16.1.11 172.16.1.11;
}

but you could also do

# Router is at highest address of the /31
subnet 172.16.1.10 netmask 255.255.255.254
{
option routers 172.16.1.11;
range 172.16.1.10 172.16.1.10;
}

There is no magic here.

Steinar Haug, Nethelp consulting, [hidden email]
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Bill Shirley-2

Re: Using OMAPI to release a DHCP lease on a failover pair

https://en.wikipedia.org/wiki/IPv4#First_and_last_subnet_addresses

I'm speaking about the subnet assigned to the NIC.

Bill

On 7/30/2020 4:20 PM, [hidden email] wrote:

>> Interesting. You would only have two available addresses, right? The network address and the broadcast address? Which one does the device answer to?
> When using IPv4 /31 there's really no "network address" or "broadcast
> address". There are simply two IP addresses. One is the router and the
> other is the client. Supported by lots of equipment, and also ISC
> DHCP.
>
> Example:
>
> # Router is at lowest address of the /31
> subnet 172.16.1.10 netmask 255.255.255.254
> {
> option routers 172.16.1.10;
> range 172.16.1.11 172.16.1.11;
> }
>
> but you could also do
>
> # Router is at highest address of the /31
> subnet 172.16.1.10 netmask 255.255.255.254
> {
> option routers 172.16.1.11;
> range 172.16.1.10 172.16.1.10;
> }
>
> There is no magic here.
>
> Steinar Haug, Nethelp consulting, [hidden email]
> _______________________________________________
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users