diff options
author | Marcin Siodelski <marcin@isc.org> | 2018-05-10 13:08:03 +0200 |
---|---|---|
committer | Marcin Siodelski <marcin@isc.org> | 2018-05-10 18:05:39 +0200 |
commit | e898172a7eeee69231186b1230e96a6bba54891c (patch) | |
tree | d8dffdc209e221e9be6d413ee37efa7579651280 /doc | |
parent | [5478] Addressed most of the review comments. (diff) | |
download | kea-e898172a7eeee69231186b1230e96a6bba54891c.tar.xz kea-e898172a7eeee69231186b1230e96a6bba54891c.zip |
[5478] Added a section about transitioning between the servers.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/guide/hooks-ha.xml | 32 |
1 files changed, 32 insertions, 0 deletions
diff --git a/doc/guide/hooks-ha.xml b/doc/guide/hooks-ha.xml index 7d02d4e047..41b712e62e 100644 --- a/doc/guide/hooks-ha.xml +++ b/doc/guide/hooks-ha.xml @@ -292,6 +292,38 @@ (see below).</para> </section> + <section xml:id="ha-scope-transition"> + <title>Scope Transition in Partner Down Case</title> + <para>When one of the servers finds that its partner is unavailble, + it will start serving clients from its own scope and the scope of the + partner which is considered unavailable. This is straight forward + for the new clients, i.e. sending DHCPDISCOVER (DHCPv4) or Solicit + (DHCPv6), because those requests are not sent to any particular server. + The available server will respond to all such queries when it is + in the <command>partner-down</command> state.</para> + + <para>When the client is renewing a lease, it will send its + DHCPREQUEST (DHCPv4) or Renew (DHCPv6) message directly to the + server which has allocated the lease being renewed. Because this + server is unavailable, the client will not get any response. In + that case, the client continues to use its lease and re-tries to + renew until the rebind timer (T2) elapses. The client will now enter + the rebinding phase, in which it will send DHCPREQUEST (DHCPv4) or + Rebind (DHCPv6) message to any available server. The surviving + server will receive the rebinding request and will (typically) + extend the lifetime of the lease. The client will continue to + contact that new server to renew its lease as appropriate.</para> + + <para>When the other server becomes available, both active servers + will eventually transition to the <command>load-balancing</command> + or <command>hot-standby</command> state, in which they will be + responsible for their own scopes. Some clients belonging to the + scope of the started server will be trying to renew their leases + via the surviving server. This server will not respond to them + anymore and the client will eventually transition back to the + right server via rebinding mechanism again.</para> + </section> + <section xml:id="ha-load-balancing-config"> <title>Load Balancing Configuration</title> <para>The following is the configuration snippet which enables |