Windows 7 Cliente inundando rede com solicitações DHCP. Não definindo IP

7

Eu tenho uma rede pequena, com 15 estações de trabalho, SAMBA AD e vários servidores Linux virtualizados. Todas as estações de trabalho e servidores estão na mesma sub-rede.

Todas as estações de trabalho estão executando o Windows 7 Pro

Meu Samba 4 DC e ISC-DHCP-SERVER estão sendo executados no mesmo host virtualizado.

A maioria, se nem todas as estações de trabalho tiverem reservas DHCP configuradas.

Uma das minhas estações de trabalho não adquirirá um endereço dhcp. Quando eu habilito o adaptador, o syslog do meu Servidor DHCP relata o seguinte: (Eu tentei remover os scripts do dydns, e isso não fez nenhuma diferença, então desconsidere essas mensagens.)

Jan  6 03:47:21 frfdc dhcpd[984]: DHCPREQUEST for 192.168.1.249         (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPACK on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPOFFER on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: Commit: IP: 192.168.1.249 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[1] = add
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[2] = 192.168.1.249
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[4] = FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : Getting new ticket, old one has expired
Jan  6 03:47:21 frfdc sh[984]: kinit: Permission denied while getting initial credentials
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  6 03:47:21 frfdc dhcpd[984]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPREQUEST for 192.168.1.249 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPACK on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPOFFER on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: Commit: IP: 192.168.1.249 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[1] = add
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[2] = 192.168.1.249
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[4] = FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : Getting new ticket, old one has expired
Jan  6 03:47:21 frfdc sh[984]: kinit: Permission denied while getting initial credentials
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  6 03:47:21 frfdc dhcpd[984]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256

Parece que estou sendo inundado com 10 solicitações por segundo para esta estação de trabalho. Eventualmente, o Windows atinge o tempo limite, atribui a si mesmo um endereço 169.x.x.x e sai.

Qualquer informação / sugestão seria muito bem-vinda.

Na estação de trabalho, tentei: Atualizar drivers. Instalando o sistema operacional Desativando o NIC sem fio. Aplicando uma configuração de registro "DhcpConnEnableBcastFlagToggle to 1" em HKLM-System-Current Control Set-Services-TCPIP-Parâmetros-interfaces-GUID.

No servidor, tentei atualizar o servidor DHCP. Eu estou agora em 3.3-5ubuntu12.7 Eu investiguei diferentes configurações de atraso, mas elas não parecem ajudar.

dhcpd.conf abaixo: (Outras reservas removidas)

default-lease-time 600;
max-lease-time 7200;

authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.1.255;
  option time-offset 0;
  option routers 192.168.1.1;
  option domain-name "CHANGED.local";
  option domain-name-servers 192.168.1.19;
  option netbios-name-servers 192.168.1.19;
  option ntp-servers 192.168.1.19, 192.168.1.250;


host FRF-M014-PC.FRFCanada.local{
  hardware ethernet 00:23:24:a1:cd:80; 
  fixed-address 192.168.1.249; 
}

pool {
  max-lease-time 1800; # 30 minutes
  range 192.168.1.150 192.168.1.199;
  }
}

Atualização: 7 de janeiro de 2018 12:40 Eu não vejo nada do log de eventos no cliente que parece relevante. Eu tentei mudar o IP da reserva para 192.168.1.6 - O cliente ainda inunda o servidor dhcp por cerca de 30 segundos, mas eventualmente aceita o IP. Eu estou procurando por uma possível duplicata de 192.168.1.249 - mas não foi capaz de encontrar um como ainda. É domingo e ninguém mais está no escritório, então isso pode ser parte do motivo. Eu também adicionei a chave de registro sugerida.

Atualização: 7 de janeiro de 2018 12:40 Eu celebrei muito cedo. Eu reiniciei o cliente e ele não está mais aceitando o IP

Atualização 7 de janeiro de 2018 13:45 Após 15 minutos de solicitação de um IP, o cliente acabou aceitando o IP. Log capturado abaixo:

Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPREQUEST for 192.168.1.6 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPACK on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPOFFER on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: Commit: IP: 192.168.1.6 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[1] = add
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[2] = 192.168.1.6
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[4] = FRF-M014-PC
Jan  7 13:42:05 frfdc dhcpd: 07-01-18 13:42:05 [dyndns] : Getting new ticket, old one has expired
Jan  7 13:42:05 frfdc sh[1693]: kinit: Permission denied while getting initial credentials
Jan  7 13:42:05 frfdc dhcpd: 07-01-18 13:42:05 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  7 13:42:05 frfdc dhcpd[1693]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPREQUEST for 192.168.1.6 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPACK on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:08 frfdc dhcpd[1693]: DHCPINFORM from 192.168.1.6 via eth0
Jan  7 13:42:08 frfdc dhcpd[1693]: DHCPACK to 192.168.1.6 (00:23:24:a1:cd:80) via eth0

Atualização 7 de janeiro de 2018 14:45

NIC alterada, reserva atualizada com o novo MAC da NIC. O mesmo resultado.

Atualização 8 de janeiro de 2018 9:45

Atualização de 9 de janeiro de 2018

Adquiri uma janela de inatividade para 13 de janeiro de 2014. Não há mais atualizações até o 15'th

Atualizar 14 de janeiro de 2018 Eu tentei reiniciar o switch e servidor físico. Ainda sem mudança. Em seguida, atribui ao servidor sua própria porta física NIC / Switch. Ainda sem mudança. Em seguida, revisei a configuração do switch e reapliquei as configurações da porta à porta que está sendo usada, e a sobrecarga parece ter parado. Ainda não estou convencido e vou acompanhar por alguns dias.

    
por Skye Bowen 06.01.2018 / 18:41

4 respostas

3

Parece-me uma placa de rede ruim na estação de trabalho.

Tente uma atualização de firmware e, se ainda assim não funcionar, altere a NIC.

    
por 07.01.2018 / 02:39
2

Com base na oferta - > commit parece que o servidor DHCP está funcionando; então, por algum motivo, o cliente não está aceitando o IP emitido.

Existe algo mais usando esse IP; O Windows usará o ARP para identificar qualquer ligação mac / IP conflitante para um endereço IP antes de vinculá-lo à sua própria interface.

O teste mais fácil é tentar outro IP; Como alternativa, você pode matar a detecção de endereço duplicado por meio do registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

DWORD  ArpRetryCount = 0
    
por 06.01.2018 / 21:13
1

Você verificou os eventos do Windows em busca de algum problema da NIC? Encontrei o link abaixo no site de suporte da MS.

link

    
por 07.01.2018 / 06:46
0

Você tentou usar um cabo / conexão Ethernet diferente? Você já tentou desabilitar o ipv6 no nic? Você desligou o firewall da máquina e verificou novamente?

    
por 08.01.2018 / 17:46