Prezados, boa tarde.

Após diversas buscas e testes para a solução do problema de conflitos de endereçamento IP (BAD_ADDRESS) que
estavam ocorrendo em nosso servidor DHCP, aparentemente chegamos a uma solução.

Em uma postagem de um fórum da Microsoft do dia 16/10/2018 com o título “[Troubleshooting] DHCP Address
Conflict Issues “ onde a última dica (4) fala:
“4. Em muitos casos, um escopo preenchido com entradas BAD_ADDRESS é o resultado de um equipamento de rede
com defeito ou falha de configuração. Há um problema conhecido com o equipamento Cisco em que o Gratuitous
ARP recebe uma resposta, fazendo com que o cliente recuse a concessão do endereço IP e o servidor marque esse
endereço como BAD_ADDRESS.”

Link da postagem no fórum - https://social.technet.microsoft.com/Forums/en-US/9811a2b5-d8cc-4509-868e-

350b8e61b9f5/troubleshooting-dhcp-address-conflict-issues?forum=WPTGNET

Após analisar chegamos a conclusão de que está ocorrendo um conflito entre o Gratuitous ARP executado pelos
clientes/PCs e as consultas do IP Device Track realizadas pelos switches CISCO quando executados simultaneamente.

Conforme mostrado na documentação oficial da CISCO para esse caso (links abaixo), desde 2015 ou antes esse erro
já ocorria, fazendo inclusive parte dos “bugs” reconhecidos e com solução de contorno (BugId: CSCtr26069).
De 2015 até hoje já foram realizadas diversas atualizações e correções no sistema operacional CISCO IOS porém
conforme vimos não houve uma correção definitiva, no momento estamos usando a penúltima versão deste sistema
para o nosso modelo de equipamento (c2960x-universalk9-mz.152-7.E4.bin)

O recurso IPDT é padrão para o nosso modelo de switch (2960-X) mas a configuração não foi habilitada para uso,
parte do recurso foi ativado (automaticamente) nos switches que trabalham empilhados (stack), os demais que
funcionam de maneira unitária não apresentaram o mesmo comportamento.

No final do expediente de ontem (24/02/22), foi aplicada a solução de contorno sugerida pela CISCO em todos os
switches.
No dia (25/02/22) iniciamos o monitoramento às 09:00hr e até as 17:00hr tivemos apenas 02 (dois) casos de
BAD_ADDRESS registrado no servidor DHCP, o que contrasta bastante com os dias anteriores em que tínhamos uma
média de 100 por dia.

Funcionamento do DHCP – Dynamic Host Configuration Protocol (Protocolo de configuração dinâmica de host)
Definição: Configura o endereço IP e outras opções (Máscara de sub-rede, Gateway, DNS, TFTP, etc...) no dispositivo
final/cliente.
https://www.linkedin.com/pulse/entendendo-o-servi%C3%A7o-dhcp-andr%C3%A9-martins/

Processo de aquisição de endereço IP via DHCP:

Etapa 01 – DHCP Discover
O cliente/dispositivo final envia uma mensagem para toda a rede (broadcast) buscando por um servidor DHCP.
Etapa 02 – DHCP Offer
Um ou mais servidor(es) DHCP respondem diretamente ao host (unicast) informando “Eu sou um servidor DHCP, e
tenho este endereço IP para fornecer.
(O servidor somente oferece endereços que não estão em sua tabela, sejam eles concessões ativas, reservas e/ou
exclusões de endereços)
Etapa 03 – DHCP Request
O cliente recebe uma proposta de endereço IP e as configurações de rede de um dos servidores DHCP da rede (pode
haver mais de um – geralmente o servidor que respondeu mais rápido está mais próximo e é o escolhido) e testa
(Gratuitous ARP) se aquele endereço IP está realmente disponível, pois endereços IP fixados manualmente não
constam/aparecem na tabela do DHCP, o teste consiste em um PING para o próprio IP sugerido pelo servidor, caso
algum dispositivo responda ao PING é sinal de que o IP já está em uso então o PC/Host envia uma mensagem de
“DHCP Decline” negando aquela oferta e informando um conflito de IPs, caso esteja tudo OK o cliente envia uma
mensagem de “DHCP Request” ao servidor afirmando “Eu irei utilizar este endereço IP que você me informou e este
é o meu endereço de hardware/endereço MAC.
Etapa 04 – DHCPACK
O cliente recebeu, testou e aplicou o IP ofertado por este servidor DHCP, então ele retorna uma mensagem de
request para aquele servidor que por sua vez confirma ao seu cliente através de uma mensagem de “DHCP ACK”
informando que está tudo OK e grava/associa em sua tabela que o IP V.X.Y.Z. pertence ao Host/PC ABCD.
Obs: Caso a resposta do cliente demore muito, e por algum motivo o mesmo endereço IP tenha sido ofertado e
aceito por outro cliente, o Servidor DHCP irá encaminhar uma mensagem de DHCPNACK e o processo deve ser
reiniciado pelo cliente.

PT-BR - https://www.cisco.com/c/pt_br/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-
00.html
EN-US - https://www.cisco.com/c/en/us/support/docs/ip/address-resolution-protocol-arp/118630-technote-ipdt-
00.html

IPDT - IP Device Track (Atualizado:25 de Novembro de 2014 ID do documento:118630 )

Definição e uso:
A principal tarefa do IPDT é controlar os dispositivos conectados (associação de endereços MAC e IP). Para fazer isso
ele envia Pacotes do tipo ARP (sondas/sondagem/testadores/consulta) unicast com um intervalo de 30 segundos;
esses testadores são enviados pelo switch para o endereço físico da placa de rede (MAC Address) do dispositivo
conectado na outra ponta, porém o endereço lógico/IP de ORIGEM/REMETENTE do pacote é informado como
0.0.0.0 (para evitar poluir os caches ARP em outros hosts no mesmo link, caso o endereço já esteja em uso por outro
host).
O campo 'endereço lógico/IP de destino' DEVE ser definido como o endereço sendo testado. Uma sonda ARP
transmite uma pergunta ("Alguém está usando este endereço?") e uma declaração implícita ("Este é o endereço que
espero usar.").
A finalidade do IPDT é que o switch obtenha e mantenha uma lista de dispositivos conectados à ele por meio de um
endereço IP. (Mesmo tipo de associação que é feita nas tabelas ARP e MAC/CAM separadamente, porém a tabela
gerada pelo IPDT auxilia/colabora/integra com outras ferramentas como o “DAI - Dynamic ARP Inspection” e o
“DHCP Snooping”)

IPDT é um recurso que sempre esteve disponível. No entanto, em versões mais recentes do Cisco IOS®, suas
interdependências são ativadas por padrão (consulte o bug da Cisco ID CSCuj04986).

Problema conhecido:
O pacote enviado pelo switch é uma verificação de camada 2 (endereço MAC/ endereço de físico). Como tal, do
ponto de vista do switch, os endereços IP usados como origem nos ARPs não são importantes: esse recurso pode ser
usado em dispositivos sem nenhum endereço IP configurado, de modo que a origem IP 0.0.0.0 não é relevante (para
o switch de camada 2).

Quando o host recebe essas mensagens, ele responde e preenche o campo IP de destino com o único endereço IP
disponível no pacote recebido, que é seu próprio endereço IP. Isso pode causar falsos alertas de endereço IP
duplicados, pois o host que responde vê seu próprio endereço IP como a origem e o destino do pacote; consulte o
artigo “Endereço IP Duplicado 0.0.0.0” (Artigo de Troubleshooting de Mensagens de Erro) para obter mais
informações sobre o cenário de endereço IP duplicado.
PT-BR - https://www.cisco.com/c/pt_br/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-
00.html
EN-US - https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-
00.html

Pesquise defeitos do “Mensagens de Erro de 0.0.0.0 endereço de IP duplicado” (Atualizado:11 de Novembro de 2015 ID do
documento: 116529)

Introdução:
Este documento descreve um problema encontrado quando uma Mensagem de Erro “0.0.0.0 endereço de IP
duplicado” é recebida pelos clientes que executam de Microsoft Windows Vista e versões posteriores. Os métodos
que são usados a fim resolver e pesquisar o problema são descritos abaixo.
(Não recebemos ou fomos informados dessas mensagens aparecendo na tela dos usuários)

Problema
Com o Microsoft Windows Vista e versões posteriores, a Microsoft introduziu um recurso novo que fosse usado a
fim detectar endereços lógicos/IPs duplicados na rede quando o processo DHCP ocorre (Gratuitous ARP). Este fluxo
novo da detecção é descrito na RFC 5227.
Um dos gatilhos para este fluxo da detecção de conflitos é definido na seção 2.1.1
Se durante o período de aquisição de endereço IP o host recebe qualquer pacote ARP onde o endereço IP de destino
do pacote é o mesmo endereço que ele está requisitando ao servidor DHCP, e o endereço do hardware do
remetente do pacote não é o endereço de hardware dele, então o host DEVE tratar isso como um conflito de
endereço IP e sinalizar ao servidor DHCP (DHCP DECLINE).

Causa do endereço de IP duplicado

Se o switch manda uma Sondagem ARP para o cliente enquanto o PC usando Microsoft Windows está em sua fase
de detecção de endereço duplicado, então o Microsoft Windows detecta a sondagem como um endereço de IP
duplicado e apresenta uma mensagem que um endereço de IP duplicado foi encontrado na rede para o IP 0.0.0.0.
O PC não obtém um endereço, e o usuário deve manualmente forçar um “ipconfig /release ou /renew, desconectar
e reconecta-lo à rede, ou reiniciar o PC para conseguir o acesso de rede.

Solução:
Dentre as diversas sugeridas no documento oficial da CISCO, a solução que decidi utilizar e que parece se encaixar
melhor em nosso ambiente foi:
A alternativa NON-SVI preliminar que é usada a fim contornar a situação é atrasar o pacote ARP do switch de modo
que o Microsoft Windows tenha o tempo necessário para terminar a detecção do endereço de IP duplicado. Isto
somente é eficaz em portas de acesso e em up-links. Entre com este comando para “atrasar” o pacote ARP de teste:

ip device tracking probe delay 10

A RFC especifica uma janela de dez segundos para iniciar a detecção de endereço duplicado, portanto, se você
atrasar a sonda de rastreamento de dispositivo, ela resolverá o problema em quase todos os casos. Além do atraso
da sonda, o atraso também é redefinido quando o switch detecta uma testagem/consulta do PC. Por exemplo, se o
cronômetro da sonda tiver contado até cinco segundos e detectar uma sonda ARP do PC, o cronômetro será
redefinido para dez segundos. Esta janela pode ser ainda mais reduzida se você habilitar o DHCP Snooping também,
pois isso redefine o cronômetro da mesma forma. Em raras circunstâncias, o PC envia um ARP Probe milissegundos
antes que o switch envie seu probe, o que ainda gera uma mensagem de endereço duplicado para o usuário final.

At.te;
Evandro Nascimento
Analista de Redes