Dans au moins une implémentation, la capacité de la table ARP est strictement limitée. Que se passe-t-il lorsque le cache ARP est plein et qu'un paquet est proposé avec une destination (ou saut suivant) qui n'est pas mise en cache? Que se passe-t-il sous le capot et quel est l'effet sur la qualité du service?
Par exemple, les routeurs Brocade NetIron XMR et Brocade MLX ont un maximum de système configurableip-arp . La valeur par défaut dans ce cas est 8192; la taille d'un sous-réseau / 19. La documentation ne précise pas si c'est par interface ou pour tout le routeur, mais pour les besoins de cette question, nous pouvons supposer que c'est par interface.
Peu de networkers configureraient volontairement un sous-réseau / 19 sur une interface, mais ce n'est pas ce qui s'est passé. Nous migrions un routeur principal d'un modèle Cisco vers un Brocade. L'une des nombreuses différences entre Cisco et Brocade est que Cisco accepte les routes statiques qui sont définies à la fois avec une interface sortante et une adresse de saut suivant, mais Brocade insiste sur l'une ou l'autre. Nous avons supprimé l'adresse du saut suivant et conservé l'interface. Plus tard, nous avons appris l'erreur de nos façons de faire et sommes passés de l'interface à l'adresse du saut suivant, mais tout semblait fonctionner au départ.
+----+ iface0 +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1 .2+----+
10.0.0.0/30
Avant la migration, R1 était un Cisco et avait l'itinéraire suivant.
ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2
Après la migration, R1 était un brocart et avait la route suivante.
ip route 10.1.0.0 255.255.0.0 iface0
R2 est un routeur Cisco et les routeurs Cisco exécutent l' ARP proxy par défaut. C'est la (mauvaise) configuration en production qui a préparé le terrain pour ce qui s'est avéré être un débordement de cache ARP.
- R1 reçoit un paquet destiné au réseau 10.1.0.0/16.
- Sur la base de la route d'interface statique, les ARP R1 pour la destination sur
iface0 - R2 reconnaît qu'il peut atteindre la destination et répond à l'ARP avec son propre MAC.
- R1 met en cache le résultat ARP qui combine une adresse IP dans un réseau distant avec le MAC de R2.
Cela se produit pour chaque destination distincte dans 10.1.0.0/16. Par conséquent, même si le / 16 est correctement sous-connecté au-delà de R2, et qu'il n'y a que deux nœuds sur le lien contigu à R1 et R2, R1 souffre d'une surcharge de cache ARP car il induit R2 à se comporter comme si toutes les adresses 65k étaient directement connectées.
La raison pour laquelle je pose cette question est parce que j'espère que cela m'aidera à comprendre les rapports de problèmes du service réseau (quelques jours plus tard) qui nous ont finalement menés vers le cache ARP débordant. Dans l'esprit du modèle StackExchange, j'ai essayé de distiller cela en ce que je crois être une question précise et précise à laquelle on peut répondre objectivement.
EDIT 1 Pour être clair, je demande une partie de la couche de colle entre la liaison de données (couche 2) et le réseau (couche 3), pas la table de transfert MAC dans la couche de liaison de données. Un hôte ou un routeur construit le premier pour mapper les adresses IP aux adresses MAC, tandis qu'un commutateur construit le dernier pour mapper les adresses MAC aux ports.
EDIT 2 Bien que j'apprécie l'effort auquel les répondants sont allés pour expliquer pourquoi certaines implémentations ne sont pas sujettes à un débordement de cache ARP, je pense qu'il est important que cette question aborde celles qui le sont. La question est "ce qui se passe quand", et non "le vendeur X est-il susceptible de". J'ai fait ma part maintenant en décrivant un exemple concret.
EDIT 3 Une autre question que ce n'est pas est "comment puis-je empêcher le cache ARP de déborder?"