Eis o que eu acho que está acontecendo: os clientes DHCP tentam renovar o contrato a meio da vida do contrato. Um DHCPREQUEST a renovar vai para o servidor DHCP que concedeu a concessão e, se a concessão for estendida, a hora de expiração da concessão é ajustada para refletir isso. Não há ipconfig /release , o que elimina o endereço IP atribuído, para que não haja interrupção na conectividade. Se, após algum intervalo, o servidor DHCP que concedeu a concessão não puder ser contatado, DHCPREQUESTs serão enviados sem nenhum servidor especificado e, se nenhuma resposta for recebida antes do término do período de concessão, a concessão expirará. No vencimento da concessão, ocorre um ipconfig /release , perdendo o IP atribuído e interrompendo a conectividade. Uma solicitação broadcast DHCPDISCOVER é feita para qualquer servidor DHCP de escuta e, quando um servidor responde, uma nova concessão é solicitada ( ipconfig /renew faz isso se nenhuma concessão estiver ativa). Quando uma nova concessão é concedida, a conectividade é restaurada.
Acho que sua máquina problemática, por algum motivo, não pode alcançar o servidor DHCP de atribuição e, portanto, não pode receber uma renovação. Por expiração de concessão, a conectividade cai e uma solicitação DHCPDISCOVER de difusão é emitida. O servidor DHCP ouve isso, responde e uma nova concessão é negociada. Espuma, enxaguar, repita.
Eu prevejo que a interrupção da conectividade mudou em sincronia com a alteração do intervalo de concessão. Se não, minha teoria está errada e você pode parar de ler.
Se a perda do evento de conectividade acontecer no final de um intervalo de concessão, temos que descobrir por que a renovação do DHCPREQUEST não está chegando ao servidor DHCP. Uma possibilidade é algo errado com a tabela de roteamento naquela máquina. Use route print quando a máquina estiver conectada e ipconfig /all para mostrar os detalhes da concessão.