option dhcp-server-identifier

[John Ratliff]

I have a pair of isc dhcp servers, version 4.3.1 on Debian 8 Jessie.

I do not want to use the DHCP failover protocol. Instead, I want to use a
virtual IP on the primary active server, and have the backup server
shutdown. I have a cronjob to sync the lease file automatically, but
failover will be strictly a manual process.

It seems that the running server always sends packets from the primary IP
on the NIC, and sets the dhcp-server-identifier option to this IP. So when
a DHCP client tries to renew, if the server has changed, it takes quite a
while before the client realizes this. If I could change the packet and
the dhcp-server-identifier to be the virtual IP, the clients wouldn't have
this problem.

Is there a way to configure this in isc-dhcp?

Thanks.

--John


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

[Thomas Markwalder]

On 10/11/16 10:39 PM, John Ratliff wrote:

> I have a pair of isc dhcp servers, version 4.3.1 on Debian 8 Jessie.
>
> I do not want to use the DHCP failover protocol. Instead, I want to use a
> virtual IP on the primary active server, and have the backup server
> shutdown. I have a cronjob to sync the lease file automatically, but
> failover will be strictly a manual process.
>
> It seems that the running server always sends packets from the primary IP
> on the NIC, and sets the dhcp-server-identifier option to this IP. So when
> a DHCP client tries to renew, if the server has changed, it takes quite a
> while before the client realizes this. If I could change the packet and
> the dhcp-server-identifier to be the virtual IP, the clients wouldn't have
> this problem.
>
> Is there a way to configure this in isc-dhcp?
>
> Thanks.
>
> --John
>
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users

Hello John:


You should be able to use the "server-identifier" configuration
parameter to fix the value used to the desired IP address.  From
dhcpd.conf.5:

"The server-identifier statement

    server-identifier hostname;

    The  server-identifier  statement  can be used to define the value
    that is sent in the DHCP Server  Identifier  option  for  a  given
    scope.   The  value  specified  must be an IP address for the DHCP
    server, and must be reachable by all clients served by a  particu-
    lar scope.

    The  use  of  the server-identifier statement is not recommended -
    the only reason to use it is to  force  a  value  other  than  the
    default  value  to  be  sent  on occasions where the default value
    would be incorrect.  The default value is  the  first  IP  address
    associated  with  the  physical  network  interface  on  which the
    request arrived.

    The usual case where the server-identifier statement needs  to  be
    sent  is  when  a physical interface has more than one IP address,
    and the one being sent by default isn't appropriate  for  some  or
    all clients served by that interface.  Another common case is when
    an alias is defined for the purpose  of  having  a  consistent  IP
    address  for  the  DHCP server, and it is desired that the clients
    use this IP address when contacting the server.

    Supplying a value for the dhcp-server-identifier option is equiva-
    lent to using the server-identifier statement."


Regards,

Thomas Markwalder

ISC Software Engineering

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

[Simon Hobson]

John Ratliff <[hidden email]> wrote:

> It seems that the running server always sends packets from the primary IP
> on the NIC, and sets the dhcp-server-identifier option to this IP. So when
> a DHCP client tries to renew, if the server has changed, it takes quite a
> while before the client realizes this.

Thomas has already given the fix for the address used (and I always prefer a proper fix to a workaround), but without this there should be no impact whatsoever on the clients. They may take a while to find the other server, but they will not lose their current lease - if they do then you have other issues to investigate.

The default behaviour (at least for the ISC client, I think most are pretty similar) is to renew (by unicast to the server) the lease at half time. So if you use (say) 8 hours leases, the client will attempt to renew it when there's 4 hours left - at this point it will get no reply if the original server is down but that will not in any way affect client operation.
The client will continue at decreasing intervals until (by default) 7/8 of the lease is expired - so when there is still 1 hour of an 8 hours lease left. Then it will switch to broadcasting renewal requests - at which point, the other server will pick up the packet and renew the lease, and the client can then carry on as normal without any network interruption.

Any client that breaks network connections under this condition is broken.

Only if the lease completely expires should the client drop it's IP address and break any network connections that are open.

I hope that's clear.

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

[John Ratliff]

<quote who="Simon Hobson">

> John Ratliff <[hidden email]> wrote:
>
>> It seems that the running server always sends packets from the primary
>> IP
>> on the NIC, and sets the dhcp-server-identifier option to this IP. So
>> when
>> a DHCP client tries to renew, if the server has changed, it takes quite
>> a
>> while before the client realizes this.
>
> Thomas has already given the fix for the address used (and I always prefer
> a proper fix to a workaround), but without this there should be no impact
> whatsoever on the clients. They may take a while to find the other server,
> but they will not lose their current lease - if they do then you have
> other issues to investigate.
>
> The default behaviour (at least for the ISC client, I think most are
> pretty similar) is to renew (by unicast to the server) the lease at half
> time. So if you use (say) 8 hours leases, the client will attempt to renew
> it when there's 4 hours left - at this point it will get no reply if the
> original server is down but that will not in any way affect client
> operation.
> The client will continue at decreasing intervals until (by default) 7/8 of
> the lease is expired - so when there is still 1 hour of an 8 hours lease
> left. Then it will switch to broadcasting renewal requests - at which
> point, the other server will pick up the packet and renew the lease, and
> the client can then carry on as normal without any network interruption.
>
> Any client that breaks network connections under this condition is broken.
>
> Only if the lease completely expires should the client drop it's IP
> address and break any network connections that are open.
>
> I hope that's clear.

Thanks to the both of you. Yes, the configuration directive is working.
And yes, we didn't think it should actually be a problem, but you see a
lot of broken DHCP clients working for an ISP, so I prefer to guard
against them as much as possible.

--John

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

[Ilkka Virta]

On 12.10. 05:39, John Ratliff wrote:
> I have a pair of isc dhcp servers, version 4.3.1 on Debian 8 Jessie.
>
> I do not want to use the DHCP failover protocol. Instead, I want to use a
> virtual IP on the primary active server, and have the backup server
> shutdown. I have a cronjob to sync the lease file automatically, but
> failover will be strictly a manual process.

Just a thought:
I don't think you'll be able to sync new leases in real-time this way,
i.e. there's a window between the server giving out the lease and the
cron job running. (And with cron, you can't usually run more often than
once per minute.) If the primary server crashes with unsynced leases,
the client will still use the IP address, but the backup server will may
happily give it to someone else. I think the failover protocol tries to
work hard to prevent this.

Though of course the server tries to keep every client using the same IP
address, so this may not be much of a problem.

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