Cover do episódio 10: DHCP na prática: o conflito de IP que travou um andar inteiro
#01028 de julho, 20143 min leituraTecnologia sem HypeS1 · 2013–2016

DHCP na prática: o conflito de IP que travou um andar inteiro

Um dispositivo com IP estático dentro do range do DHCP. Parece pequeno. Travou um andar inteiro de máquinas por uma hora. O que isso ensina sobre como endereçamento de rede funciona de verdade.

RedesDHCPInfraestruturaDebugging

Um andar inteiro de máquinas parou de acessar a rede ao mesmo tempo.

Não foi gradual — foi de uma vez. Conexões caindo, máquinas perdendo endereço IP, usuários sem internet. Chamados chegando em série.

Causa: uma impressora nova que alguém configurou com IP estático. O IP escolhido estava dentro do range que o servidor DHCP usava para distribuir endereços. Quando o DHCP tentou atribuir aquele endereço para outra máquina, dois dispositivos ficaram com o mesmo IP na mesma rede.

Um conflito de IP pequeno o suficiente para parecer impossível. Grande o suficiente para derrubar um andar.


DHCP parece simples de fora: você liga o computador, ele recebe um IP, funciona.

O que está acontecendo por baixo é mais delicado. O servidor DHCP mantém um pool de endereços disponíveis e um lease — uma concessão temporária — para cada endereço distribuído. Quando o dispositivo se conecta, o servidor verifica quais endereços estão livres e atribui um.

O problema é que o servidor DHCP não tem visibilidade perfeita do que está acontecendo na rede. Ele sabe quais leases emitiu. Não sabe que alguém colocou um IP estático no mesmo range sem avisar. Quando tenta atribuir esse endereço, dois dispositivos respondem pelo mesmo IP — e nenhum dos dois consegue funcionar direito.

ARP conflict. Tráfego indo para o lugar errado. Máquinas saindo da rede.


O diagnóstico levou mais tempo do que deveria porque fui procurar no lugar errado.

Primeiro instinto: problema no switch, talvez porta com defeito. Verifiquei o switch — tudo normal. Segundo instinto: servidor DHCP com problema. Verifiquei o log do DHCP — nada de erro, apenas conflito registrado num endereço específico.

Quando vi o endereço em conflito no log, rodei arp -a na rede para ver quais dispositivos respondiam por aquele IP. Dois responderam. Um era uma máquina Windows normal. O outro tinha MAC address de impressora.

Impressora no andar, configurada com IP estático, sem ninguém ter avisado o time de TI.


A correção foi simples: mudar o IP da impressora para um fora do range DHCP, ou criar uma reserva DHCP para o MAC address dela. Dez minutos de trabalho. Uma hora de impacto.

O que isso ensina:

Ranges DHCP precisam ser documentados e respeitados. Se você tem um bloco reservado para dispositivos com IP estático (impressoras, servidores, equipamentos de rede), ele não pode se sobrepor ao pool DHCP. Isso parece óbvio — mas sem documentação, cada pessoa que configura um dispositivo manualmente decide por conta própria.

Conflito de IP em rede grande não é raro. É surpreendentemente fácil de criar por descuido.

A conexão com containers é direta: service discovery em Kubernetes tem o mesmo problema fundamental. Dois pods não podem ter o mesmo endereço no mesmo namespace. O control plane garante isso — mas quando a abstração falha, o debugging segue o mesmo caminho: quem está respondendo por esse endereço?

Rede plana sem governança de endereçamento é dívida técnica. Acumula silenciosamente até um dia causar impacto visível.

Essa semana: você sabe quais endereços IP estáticos existem na rede que você opera — e se algum está no range DHCP?