ACLs (Access Control Lists) auf Netzwerktechnologien können sowohl hardware- als auch softwarebasiert реализiert werden. Während softwarebasierte ACLs relativ klar sind – es handelt sich um Regeln, die im RAM (d.h. im Control Plane) gespeichert und verarbeitet werden, was bestimmte Einschränkungen mit sich bringt, werden wir in diesem Artikel die Funktionsweise von hardwarebasierten ACLs näher untersuchen. Als Beispiel verwenden wir die Switches der ExtremeSwitching-Serie von Extreme Networks.
Da wir uns für hardwarebasierte ACLs interessieren, ist die interne Implementierung des Data Plane, insbesondere der verwendeten Chipsätze (ASICs), von höchster Bedeutung. Die Switches aller Serien von Extreme Networks basieren auf ASICs von Broadcom; daher gelten die meisten nachfolgenden Informationen ebenso für andere Switches auf dem Markt, die auf ähnlichen ASICs basieren.
Wie aus der obigen Abbildung ersichtlich ist, sind die "Content-Aware Engines" im Chipsatz direkt für die Funktion der ACL verantwortlich, sowohl für "Ingress" als auch für "Egress". Architektonisch sind sie identisch, wobei "Egress" weniger skalierbar und weniger funktional ist. Physikalisch handelt es sich bei beiden "Content-Aware Engines" um TCAM-Speicher sowie zugehörige Logik, wobei jede Benutzer- oder Systemregel der ACL eine einfache Bitmaske ist, die in diesem Speicher abgelegt wird. Aus diesem Grund erfolgt die Verarbeitung des Datenverkehrs durch den Chipsatz paketweise und ohne Leistungsverlust.
Physikalisch wird dasselbe Ingress/Egress TCAM logisch in mehrere Segmente unterteilt (abhängig von der Speichermenge und der Plattform), die sogenannten "ACL Slices". Zum Beispiel geschieht das Gleiche mit einer physikalisch identischen HDD in Ihrem Laptop, wenn Sie mehrere logische Laufwerke darauf erstellen – C:>, D:>. Jeder ACL-Slice besteht wiederum aus Speichereinheiten in Form von "Zeilen", in die die "Regeln" (Regeln/Bitmasken) geschrieben werden.
Die Aufteilung von TCAM in ACL-Slices folgt einer bestimmten Logik. In jedem einzelnen ACL-Slice dürfen nur miteinander kompatible „Regeln“ gespeichert werden. Wenn eine der „Regeln“ nicht mit der vorhergehenden kompatibel ist, wird sie im nachfolgenden ACL-Slice gespeichert, unabhängig davon, wie viele freie Zeilen für „Regeln“ im vorherigen Slice noch verfügbar sind.
Woher kommt also die Kompatibilität oder Inkompatibilität von ACL-Regeln? Der Grund ist, dass eine "Zeile" des TCAM, in der die "Regeln" gespeichert werden, eine Länge von 232 Bit hat und in mehrere Felder unterteilt ist – Fixed, Field1, Field2, Field3. 232 Bit oder 29 Byte TCAM-Speicher reicht durchaus aus, um die Bitmaske einer bestimmten MAC- oder IP-Adresse zu speichern, ist jedoch wesentlich weniger als der vollständige Header eines Ethernet-Pakets. In jedem einzelnen ACL-Slice führt der ASIC eine unabhängige Suche nach den in F1-F3 festgelegten Bitmasken durch. Im Allgemeinen kann diese Suche über die ersten 128 Byte des Ethernet-Headers erfolgen. Gerade weil die Suche über 128 Byte erfolgen kann, aber nur 29 Byte gespeichert werden können, muss für die korrekte Suche ein Offset relativ zum Beginn des Pakets festgelegt werden. Der Offset für jedes ACL-Slice wird beim Speichern der ersten Regel festgelegt. Wenn beim Speichern einer nachfolgenden Regel festgestellt wird, dass ein anderer Offset erforderlich ist, wird diese Regel als inkompatibel mit der ersten angesehen und in das nächste ACL-Slice geschrieben.
In der folgenden Tabelle finden Sie die Kompatibilitätsordnung der in ACL definierten Bedingungen. Jede einzelne Zeile enthält Kombinationen, die miteinander kompatibel sind, sowie solche, die nicht kompatibel sind und die durch einen Bitmasken definiert werden.
Jedes einzelne Paket, das vom ASIC verarbeitet wird, startet einen parallelen Lookup in jedem ACL-Slice. Die Überprüfung erfolgt bis zur ersten Übereinstimmung im ACL-Slice, wobei jedoch mehrere Übereinstimmungen für dasselbe Paket in verschiedenen ACL-Slices zulässig sind. Jede einzelne "Regel" hat eine entsprechende Aktion, die im Falle einer Übereinstimmung der Bedingung (Bitmasken) ausgeführt werden muss. Wenn eine Übereinstimmung gleichzeitig in mehreren ACL-Slices auftritt, wird im Block "Action Conflict Resolution" auf Basis der Priorität des ACL-Slice entschieden, welche Aktion ausgeführt werden soll. Wenn in der ACL sowohl eine "Aktion" (erlauben/ablehnen) als auch ein "Aktionsmodifikator" (zählen/QoS/protokollieren/…) definiert sind, wird bei mehreren Übereinstimmungen nur die prioritärere "Aktion" ausgeführt, während alle "Aktionsmodifikatoren" ausgeführt werden. Im folgenden Beispiel wird dargestellt, dass beide Zähler erhöht werden und die prioritärere "ablehnen"-Aktion ausgeführt wird.
mit detaillierteren Informationen zur Funktionsweise von ACL öffentlich auf der Website verfügbar . Bei Fragen oder Anliegen können Sie sich jederzeit an unsere Mitarbeiter im Büro wenden – .
Quelle: habr.com
