Send dhcp-users mailing list submissions to
[email protected]
Advertising
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Fail over serves on different VLANS (Simon Hobson)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Jan 2016 14:46:56 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Fail over serves on different VLANS
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Klaus Vink Slott <[email protected]> wrote:
> We have been running 2 dhcp servers in fail over configuration for quite a
> while. Now we consider moving one server to a host in another building. This
> will also place the host on another VLAN.
> ...
> How does the server "see if the other server makes an offer".
It doesn't !
> Do they need to bee on the same VLAN or is it communicated directly between
> the servers?
It's direct.
OK, a bit of background.
If a client does not have a valid lease, or it knows the lease is not valid for
the current network, it broadcasts a DHCP_discover packet. This should reach
all DHCP servers servicing the network - either direct or via relay agents
(helpers). All DHCP servers configured to service this client will respond with
an offer, and the client will pick an offer - technically the client should
pick the "best"* offer, in practice I think most clients just take the first
that has everything they need.
For servers that made offers not taken up, they will simply cancel the offer
once they time out and don't get a request from the client.
When a client already has a lease, it will renew (extend) it by unicasting a
request to the server that gave it the lease. No other server will see this,
and it doesn't need the help of any relay agents.
* For whatever definition of best it is using.
Note that I've specifically catered for an arbitrary number of servers - that's
because you can have multiple servers servicing a network, with some
restrictions to avoid problems. For example, you could run multiple servers
with non-overlapping pools and that will work just fine.
With failover, the requirements are :
The two servers can communicate via unicast packets between them - to run the
failover protocol.
The two servers can both service the network for DHCP - that means being able
to receive (and reply to) broadcast packets either directly or via a helper,
and to communicate via unicast packets with clients.
There's no requirement to be on the same network, or VLAN, or even the same
site - as long as the connectivity requirements are met, location doesn't
matter (though if on different continents, latency may have an effect !).
As an aside, the reason the servers will not automatically go into partner down
state when communication with the partner is lost, is because the traffic may
take different routes. Eg, servers at sites A and B may both be able to
communicate with a client at site C - but not communicate with each other due
to a network problem. An example might be if there are three leased lines, one
is down, but there is no redundant routing via the third site. There are also
more mundane causes - such as the servers using different interfaces for
different traffic and a cable is unplugged, or a switch has failed, or ...
------------------------------
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
End of dhcp-users Digest, Vol 87, Issue 8
*****************************************
