In mindestens einer Implementierung gibt es eine feste Grenze für die Kapazität der ARP-Tabelle. Was passiert, wenn der ARP-Cache voll ist und ein Paket mit einem Ziel (oder Next-Hop) angeboten wird, das nicht zwischengespeichert ist? Was passiert unter der Haube und wie wirkt sich das auf die Servicequalität aus?
Beispielsweise haben Brocade NetIron XMR- und Brocade MLX-Router ein konfigurierbares ip-arp
Systemmaximum . Der Standardwert ist in diesem Fall 8192; die Größe eines / 19-Subnetzes. Aus der Dokumentation geht nicht hervor, ob dies pro Schnittstelle oder für den gesamten Router gilt. Für den Zweck dieser Frage können wir jedoch davon ausgehen, dass es sich um eine Schnittstelle handelt.
Nur wenige Netzwerker würden absichtlich ein / 19-Subnetz auf einer Schnittstelle konfigurieren, aber das ist nicht der Fall. Wir haben einen Core-Router von einem Cisco-Modell auf einen Brocade migriert. Einer der vielen Unterschiede zwischen Cisco und Brocade besteht darin, dass Cisco statische Routen akzeptiert, die sowohl mit einer ausgehenden Schnittstelle als auch mit einer Next-Hop-Adresse definiert sind, Brocade jedoch auf der einen oder anderen besteht. Wir haben die Next-Hop-Adresse gelöscht und die Schnittstelle beibehalten. Später lernten wir den Fehler auf unseren Wegen und wechselten von der Schnittstelle zur Next-Hop-Adresse, aber anfangs schien alles zu funktionieren.
+----+ iface0 +----+
| R1 |-----------| R2 |---> (10.1.0.0/16 this way)
+----+.1 .2+----+
10.0.0.0/30
Vor der Migration war R1 ein Cisco und hatte die folgende Route.
ip route 10.1.0.0 255.255.0.0 iface0 10.0.0.2
Nach der Migration war R1 ein Brokat und hatte die folgende Route.
ip route 10.1.0.0 255.255.0.0 iface0
R2 ist ein Cisco-Router, und Cisco-Router führen standardmäßig Proxy-ARP durch. Dies ist die (falsche) Konfiguration in der Produktion, die die Bühne für einen ARP-Cache-Überlauf bereitet hat.
- R1 empfängt ein Paket für das 10.1.0.0/16 Netzwerk.
- Auf der Basis der statischen Schnittstellenroute werden R1 ARPs für das Ziel aktiviert
iface0
- R2 erkennt, dass es das Ziel erreichen kann, und antwortet dem ARP mit einem eigenen MAC.
- R1 speichert das ARP-Ergebnis zwischen, das eine IP in einem Remotenetzwerk mit dem MAC von R2 kombiniert.
Dies geschieht für jedes einzelne Ziel in 10.1.0.0/16. Folglich erleidet R1 eine ARP-Cache-Überlastung, obwohl das / 16 über R2 hinaus ordnungsgemäß untergeordnet ist und sich nur zwei Knoten auf der Verbindung befinden, die an R1 und R2 angrenzen, da R2 sich so verhält, als ob alle 65k-Adressen direkt verbunden wären.
Der Grund, warum ich diese Frage stelle, ist, dass ich hoffe, dass es mir helfen wird, die Netzwerkdienst-Fehlerberichte (Tage später) zu verstehen, die uns schließlich zum überfüllten ARP-Cache geführt haben. Im Geiste des StackExchange-Modells habe ich versucht, eine klare, spezifische Frage zu erstellen, die meines Erachtens objektiv beantwortet werden kann.
EDIT 1 Um klar zu sein, frage ich nach einem Teil der Klebeschicht zwischen Datenverbindung (Schicht 2) und Netzwerk (Schicht 3), nicht nach der MAC-Weiterleitungstabelle innerhalb der Datenverbindungsschicht. Ersteres wird von einem Host oder Router erstellt, um IP-Adressen MAC-Adressen zuzuordnen, während letzteres von einem Switch erstellt wird, um MAC-Adressen Ports zuzuordnen.
BEARBEITEN 2 Obwohl ich die Bemühungen der Responder zu schätzen weiß, um zu erklären, warum einige Implementierungen nicht vom ARP-Cache-Überlauf betroffen sind, halte ich es für wichtig, diese Frage zu beantworten. Die Frage ist "Was passiert, wenn", nicht "ist Hersteller X anfällig für". Ich habe jetzt meinen Teil getan, indem ich ein konkretes Beispiel beschrieben habe.
BEARBEITEN 3 Eine andere Frage ist nicht "Wie verhindere ich, dass der ARP-Cache überläuft?"
Antworten:
Bearbeiten 2 :
Wie du erwähnt hast...
Erzwingt, dass Brocade für jedes Ziel in 10.1.0.0/16 Proxy-Arp ausführt, als wäre es direkt mit diesem verbunden
iface0
.Ich kann nicht auf die ARP-Cache-Implementierung von Brocade antworten, möchte jedoch auf die einfache Lösung Ihres Problems hinweisen. Konfigurieren Sie Ihre Route anders:
Auf diese Weise verhindern Sie, dass Brocade für 10.1.0.0/16 ARP-fähig wird (beachten Sie, dass Sie die Verknüpfung zwischen R1 und R2 möglicherweise neu nummerieren müssen, damit sie außerhalb von 10.1.0.0/16 liegt, abhängig von der Implementierung von Brocade). .
Ursprüngliche Antwort :
Cisco IOS-CPU-Router sind nur durch die Menge an DRAM im Router begrenzt, dies ist jedoch in der Regel kein einschränkender Faktor. Einige Switches (wie Catalyst 6500) haben eine harte Einschränkung für die Adjazenztabelle (die mit der ARP-Tabelle korreliert ist). Sup2T hat 1 Million Nachbarschaften .
Cisco IOS-CPU-Router haben nicht genügend Speicherplatz in der ARP-Tabelle, da diese ARPs im DRAM gespeichert sind. Nehmen wir an, Sie sprechen von Sup2T. Stellen Sie sich das so vor, nehmen Sie an, Sie hatten einen Cat6500 + Sup2T und Sie haben technisch alle möglichen Vlans konfiguriert
Angenommen, Sie machen jedes Vlan zu einem V / 24 (das sind also 252 mögliche ARPs), und Sie packen jedes Vlan voll ... das sind 1 Million ARP-Einträge.
Jeder dieser ARPs würde eine bestimmte Menge an Speicher in der ARP-Tabelle selbst sowie in der IOS-Adjazenztabelle belegen. Ich weiß nicht, was es ist, aber sagen wir mal, der gesamte ARP-Overhead beträgt 10 Bytes ...
Das bedeutet, dass Sie jetzt 10 MB für ARP-Overhead verbraucht haben. es ist immer noch nicht sehr viel Platz ... wenn du so wenig Speicher hättest, würdest du so etwas sehen
%SYS-2-MALLOCFAIL
.Bei so vielen ARPs und einem ARP-Timeout von vier Stunden müssten Sie im Durchschnitt fast 70 ARPs pro Sekunde warten. Es ist wahrscheinlicher, dass die Wartung von 1 Million ARP-Einträgen die CPU des Routers belastet (möglicherweise CPUHOG-Nachrichten).
Zu diesem Zeitpunkt könnten Sie anfangen, Routing-Protokoll-Adjazenzen zu bouncen, und IP-Adressen haben, die einfach nicht erreichbar sind, weil die Router-CPU für die IP-Adresse zu stark mit ARP ausgelastet war.
quelle
Die einzige tatsächliche Erfahrung, die ich mit diesem Ereignis gemacht habe, war mit C3550-Switches (2-8 k MAC-Limit, abhängig von der SDM-Vorlage), und dort wurde der älteste Eintrag aus der Tabelle entfernt.
quelle
Für IOS und JunOS und andere kommerzielle Stacks muss man nur testen, es ist nicht sehr schwer zum Glück.
Aber für Linux , Freebsd, Netbsd, Openbsd, UIP, LwIP und wahrscheinlich viele andere Implementierungen können Sie einfach deren Quellcode auf das Verhalten überprüfen.
In Linux müssen Sie 'net / core / neighbour.c' (beginnen Sie mit der Zeile 'if (entries> = tbl-> gc_thresh3' || ') und' net / ipv4 / arp.c '.
In Linux scheinen Sie habe drei volle Ebenen
Wenn gc_thresh3 versucht zu überschreiten, wird versucht, die Ausführung der Speicherbereinigung zu erzwingen, es sei denn, sie wurde bereits kürzlich ausgeführt. Garbage Collect scheint Einträge zu löschen, auf die nicht mehr verwiesen wird. Dies bedeutet nicht, dass der älteste oder der neueste Eintrag vorhanden ist. Die Überschreitung der gc_staletime scheint jedoch eine Möglichkeit zu sein, den Eintrag zu dereferenzieren, was wiederum zum ältesten Eintrag führt.
Wenn Garbage Collect nicht ausgeführt werden kann, wird einfach kein neuer Eintrag hinzugefügt. Alle diese Intervalle gc_threshN und periodische Speicherbereinigung können optimiert werden.
Der Code ist adressfamilienunabhängig (ipv4, ipv6), sodass IPv6-ND- und IPv4-ARP-Tabellen über genau denselben Codepfad und nicht über doppelten Pfad verarbeitet werden.
quelle
Es würde für die IP-Adresse arp es in der Tabelle speichern und je nach Implementierung sollte der älteste Eintrag gelöscht werden. Die Auswirkung auf die Leistung hängt davon ab, ob dies ein ungewöhnliches Ereignis ist oder nicht. Dies ist jedoch ein Angriffsvektor, sodass jemand eine Menge Arps senden kann, die die Prozessorauslastung beeinflussen
quelle
Der Switch ruft ARP für diese Ziel-IP auf, um ihre MAC-Adresse abzurufen (die auch die CAM-Tabelle mit der Antwort füllen würde). Die ARP-Anfrage wird an alle Ports gesendet. Dies erfordert die CPU und beinhaltet den
ARP Input
Prozess. Wenn sich die ARP-Anforderungen auf dieselbe IP beziehen, sollte der Switch die ARP-Rate aufgrund des häufigen Überlaufs der ARP-Tabelle auf alle zwei Sekunden begrenzen. Wenn die Anfragen häufig genug an zufällige IPs gerichtet sind, kann die CPU ansteigen, da diese CPU sowohl an den ARP-Anfragen als auch an den Antworten beteiligt ist.quelle
Durch die Angriffe auf Cisco 3550, 3560 usw.-Switches können Sie diese in einen riesigen Hub verwandeln, sobald Sie das MAC-Adresslimit überschritten haben. Die Switches verfügen über ein festgelegtes Limit an MAC-Adressen (ca. 6000), das gespeichert werden kann. Sobald dieses Limit erreicht ist, werden alle Daten über die Schnittstellen übertragen. Ich kann mich nicht erinnern, ob das für 802.1q-Pakete gilt, weil ich das schon lange nicht mehr tun musste. Möglicherweise muss ich mein Netzwerklabor zu Hause starten, um das herauszufinden.
quelle