Re: Anycast provider for SMTP?
On 6/18/2015 16:40, Jonas Björk wrote:
On Jun 18, 2015, at 11:29 PM, Larry Sheldon <larrysheldon@cox.net> wrote:
On 6/18/2015 16:25, Jonas Björk wrote:
Because clients will switch to unicast for renewal. Also clients will stay with the current server forever, so you might have a bad distribution of load between the servers. If one server was down everyone will switch to the other and never go back until forced.
Why wouldn't they go back to the nearest server when it comes back online?
Been awhile, but it seems like they try to "renew" the lease they have, with the server that holds it.
The clients speak unicast with one single ip-helper which address is shared by all the servers. They can't choose which ever server to talk to.
One of us is confused (and it may well be me) but I thought the ip-helper address was only useful in the initial grope-in-the-dark for a server that is not on the local Ethernet broadcast domain. Thereafter the negotiations (I thought) are between the client and the responding server and forever after until a failure-to-renew occurred. -- sed quis custodiet ipsos custodes? (Juvenal)
On 19 June 2015 at 04:18, Larry Sheldon <larrysheldon@cox.net> wrote:
On 6/18/2015 16:40, Jonas Björk wrote:
The clients speak unicast with one single ip-helper which address is
shared by all the servers. They can't choose which ever server to talk to.
One of us is confused (and it may well be me) but I thought the ip-helper address was only useful in the initial grope-in-the-dark for a server that is not on the local Ethernet broadcast domain.
Thereafter the negotiations (I thought) are between the client and the responding server and forever after until a failure-to-renew occurred.
The clients will broadcast DISCOVER and this will be picked up by the DHCP relay. The relay will also broadcast replies from DHCP servers. There might be multiple servers and therefore multiple offers for leases. The client will select a server and broadcast a request for lease including the IP-address of the server in a DHCP option. The relay will pick that up and send it to all servers. The server which finds its own IP in the server id option will then send ACK. All other servers will notice they were not selected and withdraw their offer for a lease (sending nothing). But after this initial exchange, the clients will unicast renew requests directly to the DHCP server, bypassing the DHCP relay. So Jonas is wrong here. The client will at no point send unicast to the DHCP relay (although the relay might send unicast to the client). The DHCP relay exists only to transmit broadcast traffic - that is the purpose of the relay. Also it is the clients that select what server they want to use. That said, there exists non standard vendor solutions were the DHCP relay does more. In our routers it is called DHCP Proxy. The proxy will act as a DHCP server towards clients. Therefore all unicast will also be with the proxy. The proxy is itself a client towards the real DHCP server. This means a DHCP Proxy is stateful. A DHCP Relay is stateless. The fact that a DHCP relay is stateless also makes it impossible for a DHCP relay to pass on unicast to clients. The clients will only include the server id in the first request message. All renew messages are without that information, so the relay has no way to know which server to pass the message to. Everything above is for DHCPv4. Things are slightly different for DHCPv6. The most important difference is that the DHCP servers can request that renew is done by multicast instead of unicast and the server id is included in all messages. This way you can force all traffic to go via the relay including renew. Regards, Baldur
participants (2)
-
Baldur Norddahl -
Larry Sheldon