O que um cliente DHCP considera ser a melhor resposta?

Temos salas de treinamento em que normalmente o Windows XP está instalado (via PXE). A infraestrutura DNS / DHCP "normal" é Windows-Servers. A sala de treinamento possui sua própria VLAN (diferente dos servidores Windows), portanto, é mais provável que haja um auxiliar de IP para solicitações DHCP ativas no roteador Cisco em que todos os PCs dessa sala estejam conectados.

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

Acabou que isso não funcionou. Tivemos que liberar manualmente a concessão no servidor DHCP original para fazê-lo funcionar.

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

Pergunta antiga: Por que isso não funcionou como esperado? O que está fazendo com que o PC recupere 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 sua antiga concessão.

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

Mais uma vez - o Windows-DHCP-server vence.

Suspeito que exista algum algoritmo para o dhcp-client que determine a "melhor" resposta dhcp para o cliente. A nova pergunta é:

Como o cliente escolhe a resposta "melhor"?

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

As variantes que eu vi 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) Faça o último ACK recebido dentro de um intervalo de tempo definido (geralmente de 5 a 10 segundos).

Exemplo: Alguns anos atrás, tivemos problemas com as MFPs da Ricoh.
Nós tínhamos 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 1 da Ricoh) mesmo que a primeira oferta contenha apenas opções DHCP. A Ricoh mudou para a variante 2) com uma atualização de firmware depois de explicarmos o problema.

Supondo que o roteador ainda esteja atuando como uma retransmissão DHCP e encaminhando a solicitação para o servidor original, a razão pela qual ele fez isso é simplesmente porque o servidor DHCP do Windows disse para ele prosseguir e usar o IP. Nesse caso, o DHCPNACK do novo servidor é irrelevante, pois um cliente DHCP considerará todas as respostas e, como recebeu uma oferta da caixa DHCP do Windows, é perfeitamente prazer em usá-lo.

PC: Oh, oi mundo, posso usar 192.168.1.123?

Novo DHCP: eu digo não.

Old-DHCP: Eu digo que sim.

PC: Alguém disse que sim! Doce, eu vou usá-lo!

Se nada mais ajudar - RTFM (leia o manual). Nesse caso, o primeiro foi o sucesso.

O RFC 2131 descreve as operações de DHCP.

A seção 1.6 declara que o DHCP deve :

Reter a configuração do cliente DHCP nas reinicializações do servidor e, sempre que possível, um cliente DHCP deve receber os mesmos parâmetros de configuração, apesar de reiniciar o mecanismo DHCP,

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

3.2 Interação cliente-servidor - reutilizando um endereço de rede alocado anteriormente

Se um cliente se lembrar e desejar reutilizar um
endereço de rede alocado anteriormente , ele poderá optar por omitir algumas das etapas
descritas na seção anterior. O diagrama da linha do tempo na figura 4
mostra os relacionamentos de tempo em uma interação cliente-servidor típica para um cliente reutilizar um endereço de rede alocado anteriormente.

1. O cliente transmite uma mensagem DHCPREQUEST em sua sub-rede local. A mensagem inclui o endereço de rede do cliente na opção 'endereço IP solicitado'. Como o cliente não recebeu seu endereço de rede, NÃO DEVE preencher o campo 'ciaddr'. Os agentes de retransmissão BOOTP transmitem a mensagem para servidores DHCP que não estão na mesma sub-rede. Se o cliente usou um 'identificador de cliente' para obter seu endereço, o cliente DEVE usar o mesmo 'identificador de cliente' na mensagem DHCPREQUEST.

2. Servidores com conhecimento dos parâmetros de configuração do cliente respondem com uma mensagem DHCPACK ao cliente. Servidores não devem verificar se o endereço de rede do cliente já está em uso; o cliente pode responder às mensagens de solicitação de eco ICMP neste momento.

Portanto, um servidor DHCP com concessão ativa obtém precedência usando um atalho no protocolo.

1. Cliente: DHCREQUEST (o 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. Servidor DHCP do laptop: DHCPOFFER
3. Windows-DHCP-Server: Ei - eu já te conheço - DHCPACK
4. Cliente: Ah - 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.

Portanto, a solução em nosso caso provavelmente será (atualizarei isso quando realmente a testarmos):

1. Verifique se o cliente está desativado
2. Desative o servidor DHCP no laptop, cliente-MAC falso no laptop, solicitação de DHCP
3. Liberar IP
4. Recupere o IP e o MAC originais, ative o Servidor DHCP
5. Ligue o cliente e faça uma inicialização PXE ...

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

De qualquer forma, no que diz respeito à maneira como um cliente escolhe qual oferta seguir, no caso em que não há concessão atual: depende do cliente, mas em toda implementação de cliente DHCP que eu conheço, é uma corrida simples .

A RFC 2131 cobre isso:

Os clientes DHCP são livres para usar qualquer estratégia na seleção de um servidor DHCP entre os quais o cliente recebe uma mensagem DHCPOFFER.

Existe um rascunho da IETF por aí que parece morto, o que teria acrescentado configurabilidade ao processo de seleção e também menciona as implementações de clientes sem brilho (de mais de uma década atrás, mas pouco mudou):

Na prática, a implementação da política da maioria dos fornecedores aqui é muito básica (por exemplo, primeira oferta recebida ou primeira oferta aceitável recebida) e é "codificada" (ou seja, não configurável).

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