Em pelo menos uma implementação, há um limite rígido na capacidade da tabela ARP. O que acontece quando o cache do ARP está cheio e um pacote é oferecido com um destino (ou salto seguinte) que não é armazenado em cache? O que acontece sob o capô e qual é o efeito na qualidade do serviço?
Por exemplo, os roteadores Brocade NetIron XMR e Brocade MLX possuem um sistema máximo configurávelip-arp . O valor padrão nesse caso é 8192; o tamanho de uma sub-rede / 19. Não está claro na documentação se isso é por interface ou para todo o roteador, mas, para o propósito desta pergunta, podemos assumir que é por interface.
Poucos membros da rede configurariam uma sub-rede / 19 em uma interface de propósito, mas não foi o que aconteceu. Estávamos migrando um roteador principal de um modelo da Cisco para um Brocade. Uma das muitas diferenças entre Cisco e Brocade é que a Cisco aceita rotas estáticas definidas com uma interface de saída e um endereço de próximo salto, mas Brocade insiste em uma ou na outra. Largamos o endereço do próximo salto e mantivemos a interface. Mais tarde, aprendemos o erro de nossos caminhos e mudamos da interface para o endereço do próximo salto, mas tudo parecia estar funcionando inicialmente.
+----+ iface0 +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1 .2+----+
10.0.0.0/30
Antes da migração, o R1 era um Cisco e tinha a seguinte rota.
ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2
Após a migração, o R1 era um Brocade e tinha a seguinte rota.
ip route 10.1.0.0 255.255.0.0 iface0
R2 é um roteador Cisco e roteadores Cisco executam proxy ARP por padrão. Essa é a (mis) configuração da produção que define o cenário para o que acabou sendo um estouro de cache do ARP.
- R1 recebe um pacote destinado à rede 10.1.0.0/16.
- Com base na rota da interface estática, R1 ARPs para o destino em
iface0 - O R2 reconhece que pode chegar ao destino e responde ao ARP com seu próprio MAC.
- R1 armazena em cache o resultado do ARP que combina um IP em uma rede remota com o MAC do R2.
Isso acontece para todos os destinos distintos em 10.1.0.0/16. Conseqüentemente, mesmo que o / 16 esteja adequadamente sub-líquido além do R2 e haja apenas dois nós no link adjacente R1 e R2, o R1 sofre sobrecarga de cache do ARP porque induz o R2 a se comportar como se todos os endereços de 65k estivessem diretamente conectados.
O motivo pelo qual estou fazendo essa pergunta é porque espero que isso me ajude a entender os relatórios de problemas do serviço de rede (dias depois) que nos levaram, eventualmente, ao cache ARP que estava transbordando. No espírito do modelo StackExchange, tentei destilar isso para o que acredito ser uma pergunta específica e nítida que pode ser respondida objetivamente.
EDIT 1 Para ficar claro, estou perguntando sobre parte da camada de cola entre o link de dados (camada 2) e a rede (camada 3), não a tabela de encaminhamento de MAC dentro da camada de link de dados. Um host ou roteador cria o primeiro para mapear endereços IP para endereços MAC, enquanto um switch cria o último para mapear endereços MAC para portas.
EDIÇÃO 2 Embora eu aprecie o esforço que os respondentes fizeram para explicar por que algumas implementações não estão sujeitas ao estouro de cache do ARP, sinto que é importante para esta pergunta abordar as que são. A questão é "o que acontece quando", e não "o fornecedor X é suscetível a". Eu fiz minha parte agora descrevendo um exemplo concreto.
Edição 3 Outra pergunta que não é é "como impedir que o cache ARP transborda?"