Eu realmente apreciaria pensamentos e opiniões sobre este estranho problema ocorrido recentemente.
Comportamento consistente observado em clientes problemáticos:
- Até um determinado horário da manhã, os PCs dos usuários solicitavam o uso de endereços APIPA 169.254.x
- Não aceitar os endereços legítimos oferecidos pelo servidor DHCP dentro deste prazo
- Após um segundo DHCPDISCOVER após o período de tempo, os clientes aceitariam o endereço IP oferecido pelo DHCP
Resumo
- Impactou uma única rede de edifícios após um fim de semana
- Usuários que deixaram suas máquinas ligadas no fim de semana, sem problemas - renovações de DHCP, etc., operando normalmente
- Usuários que desligaram diligentemente seus PCs, mas tiveram problemas de DHCP após ligá-los
- Isso afetou o prédio por duas horas, nenhuma falha foi encontrada e resolvida sozinha.
- A rede é monitorada e uma extensa investigação concluída – sem problemas de rede durante o período
- Os servidores DHCP emitem endereços em todo o site, isso foi isolado apenas em um prédio
- Máquinas clientes predominantemente Windows 7, vários fornecedores de hardware e NIC afetados - nenhum padrão encontrado.
- Mistura de desktops e laptops estáticos
- Conectividade com fio
- Afetou uma vlan, embora nem todos os clientes tenham sido afetados na vlan.
Sequência de eventos capturados no log do servidor DHCP
- DHCPDISCOVER - PC cliente - Primeira ação de descoberta por cliente
- DHCPOFFER Servidor DHCP - Endereço IP legítimo oferecido pelo servidor DHCP
- DHCPREQUEST - PC cliente - Solicitação de 169.254x do cliente: mensagem de 'rede errada'
- DHCPNAK - Servidor DHCP - O servidor reconhece negativamente via NAK. O cliente deve iniciar o processo novamente
- DHCPDISCOVER -Client PC - Segunda ação de descoberta por cliente
- DHCPOFFER - Servidor DHCP - Endereço IP legítimo oferecido
- DHCPREQUEST - PC cliente - O cliente solicita o uso do endereço IP legítimo
- DHCPACK - Servidor DHCP - Servidor reconhece positivamente
Pseudo resumo dos pontos RFC3927:
Uma 'breve' leitura da configuração dinâmica da RFC 3927 de endereços locais de link IPv4 - fornece mais perguntas do que respostas!
Quando endereços link-local 169.254.x são usados
- 169.254. /16 endereçamento link-local usado quando endereços ou configuração de endereço não estão disponíveis
- Normalmente executado na inicialização
Se o host estiver usando o endereço 169.254.x e o endereço roteável agora disponível, o host deverá
- Usar endereço roteável
- Cessar publicidade 169.254.x
O endereço roteável dos métodos pode deixar de estar disponível
- Expiração da concessão de DHCP
- Remoção de endereço via configuração manual
- Host em roaming para nova rede onde o endereço não é mais operável
Seleção de endereço 169.254.x
- Hosts Windows e MAC implementam configuração automática local de link
- Nota do Windows:
- Assim que a conectividade de rede detectou DHCPREQUEST ou DHCPDISCOVER enviado na interface
- Os sistemas passam imediatamente para a configuração automática assim que a conectividade estiver disponível
- geração de números pseudo-aleatórios propagados contra o host, ou seja, MAC
- Ocorre na inicialização
Reivindicando endereço 169.254.x
- O host deve testar para ver se o endereço local do link 169.254.x não está em uso na rede
- Concluído por meio de solicitação ARP transmitida (endereço IP de destino incluído - a ser investigado)
Anunciando o endereço 169.254.x
- Segunda transmissão ARP, mas desta vez incluindo endereços IP de remetente e destino agora são os IPs 169.254.x selecionados
Resumo final
- O cliente DHCPDISCOVERs e o servidor DHCP respondem com um DHCPOFFER
- O cliente deve aceitar esta oferta de endereço roteável e deixar de usar o link local 169.254.x. Por algum motivo isso não acontece..
- O DHCPREQUEST subsequente do cliente parece ser a investigação ARP ou a transmissão do anúncio ARP? Que o cliente está usando 169.254.xx e pode não estar correlacionado com as respostas do servidor DHCP?
- Segundo DHCPDISCOVER - não está claro o que solicita isso, pois os PCs foram ligados inicialmente.
Obrigado pela sua paciência se você chegou até aqui!
Eu realmente apreciaria alguma ajuda para entender isso.
Obrigado,
Responder1
Você está sem endereços no pool de locação? Talvez seja por isso que não é mais possível distribuir endereços IP adicionais.
Você consegue executar ping no servidor DHCP das máquinas afetadas quando estiver no Windows? Você pode codificar a NIC para um IP não utilizado do intervalo DHCP e isso leva você à rede para teste? Se necessário também, teste um dos PCs em funcionamento na mesma porta de rede que uma máquina que não funciona.