Anycast provider for SMTP?

Baldur Norddahl baldur.norddahl at gmail.com
Fri Jun 19 10:25:19 UTC 2015


On 19 June 2015 at 04:18, Larry Sheldon <larrysheldon at 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



More information about the NANOG mailing list