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?"
Réponses:
Modifier 2 :
Comme vous l'avez mentionné...
Force le Brocade à proxy-arp pour chaque destination dans 10.1.0.0/16 comme s'il était directement connecté à
iface0.Je ne peux pas répondre à propos de l'implémentation du cache ARP de Brocade, mais je voudrais simplement souligner la solution facile à votre problème ... configurez votre itinéraire différemment:
En faisant cela, vous empêchez le Brocade d'ARP-ing pour l'ensemble de 10.1.0.0/16 (remarque, vous devrez peut-être renuméroter le lien entre R1 et R2 pour qu'il soit en dehors de 10.1.0.0/16, selon la mise en œuvre de Brocade) .
Réponse originale :
Les routeurs CPU Cisco IOS ne sont limités que par la quantité de DRAM dans le routeur, mais cela ne sera généralement pas un facteur limitant. Certains commutateurs (comme Catalyst 6500) ont une limitation stricte sur la table de contiguïté (qui est corrélée à la table ARP); Sup2T a 1 million d'adjacences .
Les routeurs CPU Cisco IOS ne manquent pas d'espace dans la table ARP, car ces ARP sont stockés dans la DRAM. Supposons que vous parliez de Sup2T. Pensez-y comme ceci, supposons que vous possédiez un Cat6500 + Sup2T et que vous ayez configuré tous les VLAN possibles, techniquement
Supposons que vous effectuez chaque Vlan a / 24 (ce qui fait 252 ARP possibles), et que vous emballez chaque Vlan complet ... soit 1 million d'entrées ARP.
Chacun de ces ARP consommerait une certaine quantité de mémoire dans la table ARP elle-même, plus la table de contiguïté IOS. Je ne sais pas ce que c'est, mais disons que la surcharge totale ARP est de 10 octets ...
Cela signifie que vous avez maintenant consommé 10 Mo pour les frais généraux ARP; ce n'est toujours pas beaucoup d'espace ... si vous aviez si peu de mémoire, vous verriez quelque chose comme
%SYS-2-MALLOCFAIL.Avec autant d'ARP et un délai d'ARP de quatre heures, vous devriez entretenir près de 70 ARP par seconde en moyenne; il est plus probable que la maintenance d'un million d'entrées ARP viderait le processeur du routeur (potentiellement des messages CPUHOG).
À ce stade, vous pouvez commencer à rebondir les contiguïtés du protocole de routage et avoir des adresses IP qui sont tout simplement inaccessibles car le processeur du routeur était trop occupé pour ARP pour l'IP.
la source
La seule expérience réelle que j'ai eue avec ce qui se passait était sur les commutateurs C3550 (limite MAC 2-8k, selon le modèle sdm) et là, il a supprimé l'entrée la plus ancienne du tableau.
la source
Pour IOS et JunOS et d'autres piles commerciales que vous n'avez qu'à tester, ce n'est pas très difficile par chance.
Mais pour linux , freebsd, netbsd, openbsd, uIP, lwIP et probablement de nombreuses autres implémentations, vous pouvez simplement vérifier leur code source pour le comportement.
Sous Linux, vous devez vérifier 'net / core / neighbour.c' (commencez par la ligne 'if (entries> = tbl-> gc_thresh3' || ') et' net / ipv4 / arp.c '.
Sous Linux, vous semblez avoir trois niveaux complets
Lorsque gc_thresh3 essaie de dépasser, il essaie de forcer l'exécution de la récupération de place, à moins qu'il n'ait déjà été exécuté récemment. Le ramasse-miettes semble supprimer les entrées auxquelles il n'est plus fait référence, donc cela ne signifie pas les plus anciennes ou les plus récentes, mais le dépassement de gc_staletime semble être un moyen de déréférencer l'entrée, ce qui se traduit à nouveau par l'entrée la plus ancienne.
Si la récupération de place ne peut pas être exécutée, la nouvelle entrée n'est tout simplement pas ajoutée. Tous ces intervalles gc_threshN et garbage collection périodiques peuvent être réglés.
Le code est indépendant de la famille d'adresses (ipv4, ipv6), donc les tables IPv6 ND et IPv4 ARP sont gérées par exactement le même chemin de code, et non par un chemin en double.
la source
Il serait arp pour l'adresse IP de le stocker dans la table et selon l'implémentation devrait supprimer l'entrée la plus ancienne. L'impact sur les performances dépend, s'il s'agit d'une occurrence rare, peu d'impact, mais il s'agit d'un vecteur d'attaque afin que quelqu'un puisse envoyer beaucoup d'arcs affectant l'utilisation du processeur
la source
Le commutateur va à ARP pour cette IP de destination pour obtenir son adresse MAC (qui remplirait également la table CAM avec la réponse). La demande ARP est diffusée sur tous les ports. Cela nécessite le CPU et implique le
ARP Inputprocessus. Si les demandes ARP sont pour la même IP, en raison du débordement fréquent de la table ARP, le commutateur doit limiter la fréquence ARP à une fois toutes les deux secondes. Si les demandes sont adressées à des adresses IP aléatoires assez fréquemment, le processeur peut augmenter car ce processeur est impliqué à la fois dans les demandes et les réponses ARP.la source
Des attaques que j'ai apprises sur les commutateurs Cisco 3550, 3560, etc., vous pouvez les transformer en hub géant une fois que vous avez surchargé la limite d'adresse MAC. Les commutateurs ont une limite définie d'adresse MAC (environ 6000) qui peut être stockée, et une fois cette limite atteinte, elle inondera toutes les données de ses interfaces. Je ne me souviens pas si cela vaut pour les paquets 802.1q car je n'ai pas eu à le faire depuis longtemps. Je devrai peut-être mettre le feu à mon laboratoire réseau à la maison pour le savoir.
la source