ARP e Neighbor Discovery: como IP vira entrega na rede local

Por que existe ARP (IPv4) e Neighbor Discovery (IPv6)

Em uma rede local (mesmo segmento/VLAN), quadros Ethernet são entregues usando endereços MAC, não endereços IP. Quando um host precisa enviar um pacote IP para um destino na mesma rede local (ou para o gateway, quando o destino está fora), ele precisa descobrir qual MAC corresponde àquele IP. Essa “tradução” é feita por:

• ARP (Address Resolution Protocol) no IPv4
• Neighbor Discovery (ND) no IPv6 (parte do ICMPv6)

O resultado fica guardado em uma tabela de vizinhança (cache), para evitar repetir a descoberta a cada pacote.

ARP no IPv4: resolução de IP → MAC na prática

Como o ARP funciona (fluxo essencial)

Quando o host A (IPv4 A) quer falar com o IPv4 B no mesmo segmento e não sabe o MAC de B:

• 1) ARP Request (broadcast): A envia um quadro Ethernet para ff:ff:ff:ff:ff:ff perguntando “Quem tem o IP B? Responda para A”.
• 2) ARP Reply (unicast): B responde diretamente para o MAC de A informando “IP B é o MAC BB:BB:...”.
• 3) Cache ARP: A grava a associação IP B → MAC de B por um tempo (timeout). B também pode aprender IP A → MAC de A ao ver o request.

Para destinos fora da rede local, o host não resolve o MAC do destino final: ele resolve o MAC do gateway e entrega o pacote IP ao roteador.

Tabela ARP, cache e timeouts

A tabela ARP é dinâmica: entradas surgem quando há tráfego e expiram após um período. Em geral:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Entradas podem ser dinâmicas (aprendidas automaticamente) ou estáticas (fixadas manualmente).
• O tempo de expiração varia por sistema operacional e pode ser renovado quando há uso.
• Uma entrada “errada” pode persistir até expirar, causando falhas intermitentes.

Em troubleshooting, o ponto-chave é: se o IP está correto mas o MAC associado está errado, o host enviará quadros para o dispositivo errado.

Comandos úteis (Linux/Windows) para ver ARP

No Linux, a forma moderna é via ip:

ip neigh show

Você verá algo como:

192.168.10.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE

No Windows:

arp -a

Você verá uma lista de IPs e MACs por interface.

Neighbor Discovery no IPv6: o “ARP do IPv6” (e mais)

O que o ND substitui e o que ele adiciona

No IPv6 não existe ARP. A resolução e a manutenção de vizinhos é feita pelo Neighbor Discovery, usando mensagens ICMPv6 e multicast (em vez de broadcast). O ND cobre:

• Resolução de endereço (IPv6 → MAC) via Neighbor Solicitation (NS) e Neighbor Advertisement (NA)
• Detecção de vizinho inalcançável (Neighbor Unreachability Detection)
• Descoberta de roteador (Router Solicitation/Advertisement), que influencia gateway padrão e parâmetros de rede
• Detecção de endereço duplicado (DAD) ao configurar endereços IPv6

Como a resolução funciona (NS/NA)

Quando o host A quer falar com o IPv6 B no mesmo link e não sabe o MAC:

• 1) NS (multicast): A envia um Neighbor Solicitation para o solicited-node multicast do endereço de B (um multicast derivado do IPv6 de B).
• 2) NA (unicast ou multicast): B responde com Neighbor Advertisement informando seu MAC.
• 3) Cache ND: A registra a associação e um estado (ex.: REACHABLE, STALE, DELAY, PROBE, FAILED).

Isso reduz ruído na rede: apenas quem “pode ser” o destino recebe o multicast, em vez de todos receberem broadcast.

Tabela de vizinhança no IPv6: estados importam

Diferente do ARP, o ND mantém um “ciclo de vida” mais explícito. Em Linux, você verá estados como:

• REACHABLE: vizinho confirmado recentemente
• STALE: entrada existe, mas precisa ser revalidada quando houver tráfego
• DELAY/PROBE: tentando confirmar reachability
• FAILED: tentativas falharam

Esses estados ajudam a diferenciar “MAC conhecido, mas vizinho não responde” de “ainda não resolvido”.

Comandos úteis para ND (Linux)

ip -6 neigh show

Exemplo:

fe80::1 dev eth0 lladdr 00:11:22:33:44:55 router REACHABLE

Em ambientes com firewall, lembre que ND depende de ICMPv6; bloquear ICMPv6 indiscriminadamente costuma quebrar IPv6 no link local.

Passo a passo prático: diagnosticar “IP não comunica” usando ARP/ND

Cenário 1: não consigo pingar o gateway (problema local vs roteamento)

Se você não alcança o gateway, a primeira pergunta é: o host consegue resolver o MAC do gateway? Se não resolve, o problema é local (L2/L3 no link). Se resolve e mesmo assim não responde, pode ser gateway, ACL, VLAN errada, ou filtragem.

Passo a passo (IPv4):

• 1) Gere tráfego: tente ping no IP do gateway.
• 2) Verifique a tabela ARP:

  ip neigh show | grep 192.168.10.1

• 3) Interprete o resultado:
  • Sem entrada ou estado indicando falha (ex.: INCOMPLETE): o ARP request não obteve reply. Suspeite de VLAN/porta errada, cabo, switch, gateway fora do ar, ou filtragem L2.
  • Entrada com MAC: compare com o MAC esperado do gateway (se você tiver inventário/etiqueta/LLDP). MAC inesperado é sinal de inconsistência (pode ser IP duplicado, ARP spoofing, ou gateway em HA/VRRP mudando MAC virtual).
• 4) Capture para confirmar (Linux):

  tcpdump -ni eth0 arp

  Você quer ver ARP requests saindo e replies voltando. Se só há requests, algo impede o reply.

Passo a passo (IPv6):

• 1) Gere tráfego: pingue o endereço link-local do roteador (se conhecido) ou o global do gateway.
• 2) Verifique vizinhos:

  ip -6 neigh show | grep -i 'router\|fe80'

• 3) Capture NS/NA:

  tcpdump -ni eth0 icmp6 and '(ip6[40] == 135 or ip6[40] == 136)'

  135 = NS, 136 = NA. Se há NS e não há NA, o vizinho não responde ou o tráfego está sendo bloqueado.

Cenário 2: consigo pingar o gateway, mas não consigo acessar um IP fora da rede

Quando o gateway responde, a resolução local (para o gateway) está funcionando. Se o acesso externo falha, a suspeita muda para roteamento, NAT (se aplicável), ACLs, ou rota padrão. Ainda assim, ARP/ND pode ajudar a confirmar que o host está entregando os pacotes ao dispositivo correto.

Checklist rápido:

• Verifique se o MAC do gateway na tabela ARP/ND é consistente e estável.
• Observe se o estado ND do gateway fica alternando para PROBE/FAILED (pode indicar perda L2 intermitente).
• Se o gateway é alcançável, mas tráfego externo não, foque em rotas e políticas no roteador/firewall (não é um problema de “IP virar entrega” no link).

Cenário 3: sintomas de IP duplicado (IPv4) e como aparece no ARP

Um IP duplicado ocorre quando dois dispositivos usam o mesmo IPv4. Sintomas comuns:

• Conectividade intermitente para aquele IP
• ping alternando tempos de resposta muito diferentes ou perdas
• Serviço “muda” (às vezes abre um host, às vezes outro)

Como identificar pela tabela ARP:

• O MAC associado ao mesmo IP muda ao longo do tempo.
• Ao limpar o cache e pingar novamente, o IP “resolve” para outro MAC.

Passo a passo (Linux):

• 1) Observe o MAC atual:

  ip neigh show 192.168.10.50

• 2) Gere tráfego e observe mudanças:

  ping -c 5 192.168.10.50

• 3) Verifique novamente:

  ip neigh show 192.168.10.50

• 4) Confirme via captura:

  tcpdump -ni eth0 arp and host 192.168.10.50

  Se você vir replies ARP para o mesmo IP vindos de MACs diferentes, há forte evidência de duplicidade (ou de spoofing).

Cenário 4: DAD no IPv6 (detecção de endereço duplicado) e sintomas

No IPv6, ao configurar um endereço, o host geralmente executa DAD (Duplicate Address Detection): ele envia NS perguntando se alguém já usa aquele endereço. Se alguém responder, o endereço é marcado como duplicado e pode não ser usado.

Sintomas típicos:

• O endereço IPv6 aparece como “tentative”/“duplicated” (dependendo do sistema)
• O host não consegue usar o endereço recém-configurado

Como investigar (Linux):

• Ver endereços e flags:

  ip -6 addr show dev eth0

• Capturar NS/NA durante a configuração:

  tcpdump -ni eth0 icmp6

Problemas típicos e como reconhecer inconsistências em ARP/ND

ARP spoofing (conceitual): o que é e quais sinais aparecem

ARP spoofing (ou ARP poisoning) é quando um dispositivo envia respostas ARP falsas para associar um IP (frequentemente o gateway) ao seu próprio MAC, desviando tráfego. Conceitualmente, isso explora o fato de que ARP não tem autenticação.

Sinais práticos comuns:

• O IP do gateway passa a apontar para um MAC “desconhecido”
• O MAC do gateway muda com frequência sem motivo (fora de cenários de HA com MAC virtual)
• Conexões ficam lentas/intermitentes, especialmente para fora da rede

Como checar inconsistência:

• Compare o MAC do gateway na tabela ARP com o MAC real do roteador/switch L3 (inventário, etiqueta, console, ou LLDP).
• Monitore mudanças na entrada ARP ao longo do tempo.
• Capture ARP replies “gratuitos” (gratuitous ARP) em excesso:

  tcpdump -ni eth0 arp

Observação: ambientes com redundância (ex.: VRRP/HSRP) podem usar MAC virtual e gerar mudanças durante failover. A diferença é que a mudança costuma ser rara e correlacionada com evento de failover, não contínua.

Falha ao alcançar o gateway: matriz de sintomas

Como decidir: problema local (L2/L3 no link) ou de roteamento

Use ARP/ND como “divisor de águas”:

• Se não há resolução (sem MAC): o problema está no link local (camada 2, VLAN, reachability no segmento, bloqueio de ARP/ICMPv6).
• Se há resolução correta (MAC esperado) e o gateway responde: o link local está funcional; o problema tende a ser roteamento/políticas além do gateway.
• Se há resolução, mas para MAC inesperado: investigue IP duplicado, spoofing ou inconsistência de inventário/HA.

Procedimentos rápidos de “higiene” do cache (com cuidado)

Quando faz sentido limpar cache ARP/ND

Limpar cache pode ajudar quando você suspeita que a associação IP→MAC ficou “presa” em um valor antigo (por exemplo, após troca de equipamento, mudança de NIC, failover, ou correção de IP duplicado). Isso não corrige a causa, mas ajuda a confirmar o diagnóstico.

Linux (por entrada):

sudo ip neigh del 192.168.10.1 dev eth0

Linux (IPv6 por entrada):

sudo ip -6 neigh del fe80::1 dev eth0

Windows (limpar ARP):

arp -d *

Após limpar, gere tráfego (ping) e observe se a nova resolução volta com o MAC esperado.