ACLs (Access Control List) auf Netzwerkgeräten können sowohl in Hardware als auch in Software implementiert werden, oder allgemeiner gesagt, in Hardware- und Software-basierten ACLs. Und wenn bei softwarebasierten ACLs alles klar sein sollte – das sind Regeln, die im RAM (also auf der Control Plane) gespeichert und verarbeitet werden, mit allen daraus resultierenden Einschränkungen – dann werden wir verstehen, wie hardwarebasierte ACLs implementiert werden und funktionieren Artikel. Als Beispiel verwenden wir Switches der ExtremeSwitching-Serie von Extreme Networks.
Da wir an hardwarebasierten ACLs interessiert sind, ist für uns die interne Implementierung der Datenebene bzw. der tatsächlich verwendeten Chipsätze (ASICs) von größter Bedeutung. Alle Switch-Linien von Extreme Networks basieren auf Broadcom-ASICs. Daher gelten die meisten der folgenden Informationen auch für andere Switches auf dem Markt, die auf denselben ASICs implementiert sind.
Wie aus der obigen Abbildung ersichtlich ist, ist die „ContentAware Engine“ direkt für den Betrieb der ACLs im Chipsatz verantwortlich, getrennt für „Ingress“ und „Egress“. Architektonisch sind sie gleich, nur „Egress“ ist weniger skalierbar und weniger funktional. Physikalisch gesehen handelt es sich bei beiden „ContentAware Engines“ um TCAM-Speicher plus zugehöriger Logik, und jede Benutzer- oder System-ACL-Regel ist eine einfache Bitmaske, die in diesen Speicher geschrieben wird. Aus diesem Grund verarbeitet der Chipsatz den Datenverkehr Paket für Paket und ohne Leistungseinbußen.
Physisch ist derselbe Ingress/Egress-TCAM wiederum logisch in mehrere Segmente unterteilt (abhängig von der Speichermenge selbst und der Plattform), den sogenannten „ACL-Slices“. Das Gleiche passiert beispielsweise mit der physikalisch gleichen Festplatte Ihres Laptops, wenn Sie darauf mehrere logische Laufwerke erstellen – C:>, D:>. Jeder ACL-Slice wiederum besteht aus Speicherzellen in Form von „Strings“, in die „Regeln“ (Regeln/Bitmasken) geschrieben werden.
Der Aufteilung von TCAM in ACL-Slices liegt eine gewisse Logik zugrunde. In jedem der einzelnen ACL-Slices können nur „Regeln“ geschrieben werden, die miteinander kompatibel sind. Wenn eine der „Regeln“ nicht mit der vorherigen kompatibel ist, wird sie in das nächste ACL-Slice geschrieben, unabhängig davon, wie viele freie Zeilen für „Regeln“ im vorherigen verbleiben.
Woher kommt dann diese Kompatibilität oder Inkompatibilität der ACL-Regeln? Tatsache ist, dass eine TCAM-„Zeile“, in die „Regeln“ geschrieben werden, eine Länge von 232 Bit hat und in mehrere Felder unterteilt ist – Fest, Feld1, Feld2, Feld3. 232 Bit oder 29 Byte TCAM-Speicher reichen aus, um die Bitmaske einer bestimmten MAC- oder IP-Adresse aufzuzeichnen, aber viel weniger als der vollständige Ethernet-Paket-Header. In jedem einzelnen ACL-Slice führt der ASIC eine unabhängige Suche gemäß der in F1–F3 festgelegten Bitmaske durch. Im Allgemeinen kann diese Suche mithilfe der ersten 128 Bytes des Ethernet-Headers durchgeführt werden. Gerade weil die Suche über 128 Bytes durchgeführt werden kann, aber nur 29 Bytes geschrieben werden können, muss für eine korrekte Suche ein Offset relativ zum Paketanfang festgelegt werden. Der Offset für jedes ACL-Slice wird festgelegt, wenn die erste Regel darauf geschrieben wird. Wenn beim Schreiben einer nachfolgenden Regel festgestellt wird, dass ein weiterer Offset erforderlich ist, gilt eine solche Regel als mit der ersten inkompatibel und wird in das geschrieben nächstes ACL-Slice.
Die folgende Tabelle zeigt die Kompatibilitätsreihenfolge der in der ACL angegebenen Bedingungen. Jede einzelne Zeile enthält generierte Bitmasken, die miteinander kompatibel und mit anderen Zeilen inkompatibel sind.
Jedes einzelne vom ASIC verarbeitete Paket führt in jedem ACL-Slice eine parallele Suche durch. Die Prüfung wird bis zur ersten Übereinstimmung im ACL-Slice durchgeführt, es sind jedoch mehrere Übereinstimmungen für dasselbe Paket in verschiedenen ACL-Slices zulässig. Für jede einzelne „Regel“ gibt es eine entsprechende Aktion, die ausgeführt werden muss, wenn die Bedingung (Bitmaske) erfüllt ist. Wenn eine Übereinstimmung in mehreren ACL-Slices gleichzeitig auftritt, wird im Block „Action Conflict Resolution“ basierend auf der Priorität des ACL-Slices entschieden, welche Aktion ausgeführt werden soll. Wenn die ACL sowohl „action“ (permit/deny) als auch „action-modifier“ (count/QoS/log/…) enthält, wird bei mehreren Übereinstimmungen nur die „action“ mit der höheren Priorität ausgeführt, während „action -modifier“ wird vollständig abgeschlossen sein. Das folgende Beispiel zeigt, dass beide Zähler erhöht werden und die höhere Priorität „deny“ ausgeführt wird.
mit detaillierteren Informationen über den Betrieb von ACL im öffentlichen Bereich auf der Website . Alle offenen oder offenen Fragen können Sie jederzeit an unsere Mitarbeiter im Büro richten - .
Source: habr.com