O que um cliente DHCP considera ser a melhor resposta?

13

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"?

Nils
fonte
onde você está liberando o endereço IP? no cliente windows ou no agente de inicialização PXE?
longneck
@ longneck, tivemos que liberar o endereço no servidor DHCP do Windows para fazê-lo funcionar.
Nils
Maneira estranha de instância de uma nova pergunta, espero que você resolva isso embora
Daniel Li

Respostas:

4

É 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.

Tonny
fonte
Os OFFERpacotes são o que o sistema do cliente precisa decidir entre. ACKe os NACKpacotes são enviados apenas em resposta a a REQUEST, o que ocorre somente depois que o cliente "decide" qual oferta deve ser seguida. Esse é um bug muito legal com as impressoras!
Shane Madden
@ShaneMadden Isso está correto, mas já vi vários casos de clientes enviando uma solicitação em resposta a ambas as ofertas e, em seguida, agindo nas respostas, como descrevi. Já faz um tempo desde que eu olhei isso profundamente. Lembro-me claramente de que NT4, W2K e XP são culpados disso. Os Ricoh também. Eles executaram um kernel Linux 2.2 e uma pilha de rede.
Tonny
9

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!

ThatGraemeGuy
fonte
Após a inicialização a frio do PC, a conversa começa com "meu MAC é XYZ - por favor, me dê um IP". Então os dois servidores DHCP oferecem IPs ... a única diferença é que ele possui uma concessão ativa em um dos servidores - mas essa é apenas a perspectiva do servidor.
Nils
1
não se o PC já tiver um endereço IP. se ele já tinha um endereço IP atribuído por um servidor DHCP, ele pedia para usá-lo primeiro antes de pedir outro endereço.
longneck
@ longneck onde esse IP será armazenado no PC?
Nils
do alto da minha cabeça, eu não sei. mas a maneira correta de limpar é usar ipconfig / release
longneck
3
@longneck - o op está perguntando sobre em um ambiente PXE, onde estamos supondo que a inicialização do BIOS não tem lembrança sobre botas anteriores ou endereços IP
Mark Henderson
3

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 ...
Nils
fonte
3

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.

Shane Madden
fonte
Você acha que a oferta "aceitável" é específica do fornecedor no lado do dhcp-client? Como no nosso caso, não é a "primeira" oferta, deve ser outra coisa - o comportamento é bastante determinístico, então ainda acho que há um padrão comum por trás disso.
Nils
@ Nils Você tem certeza absoluta de que o servidor Windows não está recebendo sua resposta ao cliente antes do laptop na mesma sala? Parece intuitivamente que o laptop deveria vencer essa corrida, mas pode não ser o que está acontecendo.
Shane Madden
Acho que vou ter que rastrear isso no nível da rede (com o wireshark) para realmente ver o que está acontecendo lá. Provavelmente em um espelho-porto de que o cliente ...
Nils