O que um cliente DHCP considera ser a melhor resposta?

Question

Temos salas de treinamento onde normalmente o Windows XP é instalado (via PXE). A infra-estrutura DNS "normal" / DHCP é o Windows-Servers. A sala de treinamento tem sua própria VLAN (diferente dos servidores Windows), portanto, é mais provável que um ajudante de IP para solicitações DHCP esteja ativo no roteador Cisco, onde todos os PCs daquela sala estão conectados.

Agora queríamos converter alguns PCs para o Linux. A ideia era: Coloque o nosso próprio laptop com um servidor DHCP na VLAN da sala e substitua a resposta "normal" do DHCP. A ideia era que isso funcionasse, uma vez que um servidor DHCP conectado diretamente naquela VLAN deveria ter um tempo de resposta mais rápido do que o servidor DHCP "normal" localizado a alguns saltos daquela VLAN.

Descobrimos que isso não funcionou. Tivemos que liberar manualmente a concessão no servidor DHCP original para que funcionasse.

No laptop, vimos o cliente solicitando o IP e o "nosso" dhcp estava enviando NACKs para a solicitação de IP do Windows, antes de oferecermos nossa própria resposta.

Pergunta antiga: Por que isso não funcionou como esperado? O que está fazendo o PC recuperar seu antigo contrato?

Atualização 2012-08-08:

O problema de recuperação foi explicado no DHCP-RFC. Agora isso explica por que o PC recupera seu antigo contrato.

Agora, liberamos o IP do servidor DHCP do Windows antes de tentar novamente.

Novamente - o servidor DHCP do Windows vence.

Eu suspeito que existe algum algoritmo para o dhcp-client que determina a "melhor" resposta dhcp para o cliente. A nova questão é:

Como o cliente escolhe a "melhor" resposta?

    

Answer 1

É o fornecedor, até mesmo o firmware específico, como um cliente reage a várias respostas do DHCP.

Variantes que tenho visto ao longo dos anos são:

1) Aceite o primeiro, independentemente de ser um ACK ou NACK.

2) Pegue o primeiro ACK, ignore completamente o NACK.

3) Pegue o último ACK recebido dentro de um intervalo de tempo definido (normalmente 5-10 segundos).

Exemplo: alguns anos atrás, tivemos problemas com a Ricoh MFP.
Nós tivemos 2 servidores DHCP. Um forneceu os endereços, o outro apenas opções adicionais de DHCP. O segundo servidor sempre respondeu primeiro.
A variante usada da Ricoh 1), mesmo se a primeira oferta contivesse apenas opções DHCP. A Ricoh mudou para a variante 2) com uma atualização de firmware depois que explicamos o problema para eles.

    

Answer 2

Supondo que o roteador ainda esteja atuando como uma retransmissão DHCP e encaminhe a solicitação para o servidor original, o motivo foi simplesmente porque esse servidor DHCP do Windows disse para ele ir em frente e usar o IP. Neste exemplo, o DHCPNACK do novo servidor é irrelevante, já que um cliente DHCP considerará todas as respostas e, como recebeu uma oferta da caixa DHCP do Windows, fica perfeitamente feliz em usá-lo.

PC: Oh hi world, can I use 192.168.1.123?

New-DHCP: I say no.

Old-DHCP: I say yes.

PC: Someone said yes! Sweet, I'll use it!

    

Answer 3

Se nada mais ajudar - RTFM (leia o bom manual). Neste caso, o primeiro foi o hit.

A RFC 2131 descreve as operações do DHCP.

Seção 1.6 afirma que o DHCP deve :

Retain DHCP client configuration across server reboots, and, whenever possible, a DHCP client should be assigned the same configuration parameters despite restarts of the DHCP mechanism,

Agora, a questão interessante é como essa meta de design está sendo alcançada em um cliente que não tem conhecimento de seu passado. A seção 3.2 descreve:

3.2 Client-server interaction - reusing a previously allocated network address

If a client remembers and wishes to reuse a previously allocated
network address, a client may choose to omit some of the steps
described in the previous section. The timeline diagram in figure 4
shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address.

1. The client broadcasts a DHCPREQUEST message on its local subnet. The message includes the client's network address in the 'requested IP address' option. As the client has not received its network address, it MUST NOT fill in the 'ciaddr' field. BOOTP relay agents pass the message on to DHCP servers not on the same subnet. If the client used a 'client identifier' to obtain its address, the client MUST use the same 'client identifier' in the DHCPREQUEST message.

2. Servers with knowledge of the client's configuration parameters respond with a DHCPACK message to the client. Servers SHOULD NOT check that the client's network address is already in use; the client may respond to ICMP Echo Request messages at this point.

Assim, um servidor DHCP que mantém uma concessão ativa obtém precedência usando um atalho no protocolo.

1. Cliente: DHCREQUEST (Endereço MAC, transmissão, será transmitido no domínio de transmissão local - aqui a VLAN local e via auxiliar de IP para o servidor DHCP do Windows)
2. Laptop-DHCP-Server: DHCPOFFER
3. Windows-DHCP-Server: Ei - eu já conheço você - DHCPACK
4. Cliente: Oh - recebi duas respostas. Um que já me conhece. Legal eu vou levar isso

A partir de então, o Laptop-DHCP-Server está sendo ignorado pelo Cliente.

Assim, a solução em nosso caso provavelmente será (atualizarei isso quando realmente testá-lo):

1. Verifique se o cliente está desativado
2. Desativar servidor DHCP no laptop, cliente-MAC falso no laptop, solicitação DHCP
3. Liberar IP
4. Recupere o IP e o MAC originais, ative o servidor DHCP
5. Ative o cliente e faça um boot PXE ...

Answer 4

A nova pergunta provavelmente deveria estar em uma questão diferente - o título da pergunta não se encaixa na maior parte do corpo da questão.

Em qualquer caso, no que diz respeito a como um cliente escolhe qual oferta seguir, no caso em que ele não possui lease atual: depende do cliente, mas em cada implementação de cliente DHCP que eu conheço, é uma corrida simples.

RFC 2131 aborda isso:

DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message.

Existe um rascunho da IETF que parece morto e que teria adicionado configurabilidade para o processo de seleção, e também menciona as implementações do cliente sem brilho (de mais de uma década atrás, mas não muito mudou):

In practice, most vendor's implementation of policy here is very basic (e.g., first offer received or first acceptable offer received) and is "hard-coded" (i.e., non-configurable).

Ter dois servidores DHCP fornecendo serviço à mesma rede com configuração diferente resulta em raças, o que não é desejável de uma perspectiva de confiabilidade ou previsibilidade. Não há realmente nenhuma razão para você não conseguir que seu servidor DHCP único forneça o que você precisa.