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-arpSystemmaximum . 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?"