Como os clientes DHCP sabem qual dos vários DHCPOFFERS aceitar?

Imagine que temos uma rede como na foto. Seis hosts em uma rede de camada 2, sem VLANs. A rede deve ser segmentada em duas sub-redes, com um servidor DHCP cada. Os servidores DHCP têm endereços IP fixos, portanto, eles sabem em qual sub-rede eles pertencem, obviamente.

Em seguida, os novos clientes são conectados. Eles não sabem nada sobre qual sub-rede eles deveriam estar e enviam seu DHCPDISCOVER para a transmissão Ethernet 255.255.255.255, para os dois servidores DHCP. Ambos os servidores respondem com uma oferta. Agora, aqui está minha pergunta: como o cliente sabe qual DHCPOFFER ele deve aceitar?

networking dhcp

— Michael Niemand
fonte

Compare esta pergunta e respostas lá.

— Kamil Maciorowski 26/10

Aqui é outra questão relacionada .

— kasperd

"the ethernet broadcast 255.255.255.255" - Esse é o endereço de broadcast IP da rede local, não um endereço Ethernet. As mensagens DHCP DISCOVER iniciais também costumam usar o endereço de broadcast Ethernet ff: ff: ff: ff: ff: ff, mas essas realmente não são a mesma coisa.

— Ilkkachu 26/10/19

Respostas:

Resposta mais simples - primeiro a chegar, primeiro a ser servido.

Se você tivesse várias VLANs e 10.10.10.0/24 estivesse em uma VLAN diferente de 10.10.20.0/24 - a transmissão não cruzaria as VLANs.

Se o servidor DHCP estivesse em uma VLAN separada para os clientes, um iphelper na interface de roteamento entre vlans direcionaria a transmissão para o local correto.

No seu cenário, em que você tem 2 redes separadas na mesma VLAN (ou na falta dela) atendendo sub-redes diferentes - é uma corrida.

DHCP Serve usando as seguintes transações:

Descoberta DHCP (DHCPDISCOVER) - Transmissão do cliente - "Existe um servidor DHCP lá fora?"
Oferta DHCP (DHCPOFFER) - Servidor para Cliente - "Sim, estou aqui e disponível!"
Solicitação de DHCP (DHCPREQUEST) - cliente para servidor "Impressionante, posso ter um endereço, por favor?"
Reconhecimento de DHCP (DHCPACK) - servidor para cliente "Claro, aqui está um IP, uma máscara, um gateway, alguns servidores DNS / WINS, um servidor de horário e todos os outros itens configurados para o seu escopo"

Tudo isso acontece nas portas UDP 67 para o servidor e 68 no cliente.

Assim que a Etapa 2 for atingida - o cliente deixará de "ouvir" as respostas de outros servidores DHCP - ficará feliz em lidar com o primeiro servidor para prestar atenção.

Como observação lateral - na verdade, há uma série bem conhecida de ataques de negação de serviço (DoS) que abusam desse direito. Um invasor se conecta a um dispositivo que responde e envia pacotes DHCPOFFER e não envia o DHCPACK quando solicitado ... repetidamente. Há também outro ataque de DoS em que os servidores DHCP "falsos" oferecem endereços que não podem ser roteados ou que entram em conflito com outros IPs que são detectados para mexer nas redes.

— Fazer87
fonte

E, portanto, a resposta curta para "Mas como executar várias sub-redes em um único segmento da Camada 2?" é " Você não. " (Sim, existem maneiras, mas não é algo que você deve geralmente fazem Uma camada 2 domínio = uma sub-rede..)

— user1686

Obrigado pessoal, isso realmente me chamou a atenção. Eu sempre me perguntei como isso seria possível, mas simplesmente não é. Portanto, a questão é: o roteador / camada 3 alterna entre sub-redes ou segmento com VLANs, estou certo?

— Michael Niemand 26/10

Em geral, sim, você precisa de VLANs ou segmentação física. Compartilhando um domínio L2 seria factível única , se ambos os servidores DHCP foram restritos a manipulação clientes "conhecidos" (por exemplo, pela lista de 'arrendamento estáticos' com endereços MAC permitidos).

— user1686

Eu acho que você poderia dar a cada servidor DHCP uma lista de endereços MAC e controlar qual cliente obtém um endereço de qual servidor dessa maneira.

— Darren

@rawity, você pode executar facilmente várias sub-redes IP no mesmo segmento da camada 2, se as sub-redes forem iguais e você não se importa com qual cliente obtém um endereço de qual sub-rede. Você só tem um servidor DHCP que fornece endereços de ambos os blocos e um roteador que atua como um gateway para os dois blocos (com um endereço em cada um). Feito. Dizer apenas "você não" está completamente errado.

— 22618 ilkkachu

A resposta existente do @ Fazer87 é amplamente correta na prática e eu recomendo a votação e a aceitação. Esta resposta explora um detalhe menor um pouco mais precisamente.

Ambos os servidores DHCP podem responder com uma mensagem DHCPOffer.

Um cliente DHCP pode aceitá-los com base no "primeiro a chegar, primeiro a ser servido". No entanto, não é necessário adotar essa abordagem.

RFC2131 especifica:

O cliente recebe uma ou mais mensagens DHCPOFFER de um ou mais servidores. O cliente pode optar por esperar por várias respostas. O cliente escolhe um servidor do qual solicitar parâmetros de configuração, com base nos parâmetros de configuração oferecidos nas mensagens DHCPOFFER.

Portanto, se o segundo servidor DHCP oferecer uma reserva de endereço IP mais longa, ou oferecer um servidor de horário em que o outro não, ou talvez tenha um campo personalizado que o cliente tenha sido programado para preferir, ele poderá aceitar a segunda oferta.

Normalmente, uma abordagem de "primeiro a chegar, primeiro a ser servido" oferece a você a oferta que ainda não passou por vários saltos entre dispositivos (retransmissões BOOTP), por isso é um bom protocolo a seguir se você não tiver motivos para se preocupar.

Eu estava em um projeto em que um dispositivo personalizado preferiria um DHCPOffer que incluía um servidor TFTP em que o firmware atualizado pudesse ser encontrado.

— Oddthinking
fonte

... ou se um servidor oferecido um endereço que o cliente já tinha usado antes e queria manter

— ilkkachu

@ilkkachu: Sim, em teoria, mas existem mecanismos melhores para isso (renovar uma reserva antes que ela expire com o antigo servidor DHCP ou enviar uma DHCPDiscovery solicitando o antigo endereço IP), por isso é improvável que seja útil na prática.

— Oddthinking 27/10/18