ACL von Switches im Detail

ACL (Access Control List) auf Netzwerkgeräten können sowohl hardware- als auch softwarebasiert implementiert werden, oder um es einfacher zu sagen hardware- und softwarebasiert. Während softwarebasierte ACLs klar sind – das sind Regeln, die im Arbeitsspeicher (d. h. auf dem Control Plane) gespeichert und verarbeitet werden, mit allen damit verbundenen Einschränkungen – werden wir in unserem Artikel untersuchen, wie hardwarebasierte ACLs implementiert sind und funktionieren. Als Beispiel verwenden wir die Switches der ExtremeSwitching-Serie von Extreme Networks.

Da uns speziell hardwarebasierte ACLs interessieren, ist die interne Implementierung des Data Plane, also die verwendeten Chipsets (ASICs), von größter Bedeutung für uns. Die Switches aller Produktlinien von Extreme Networks basieren auf ASICs von Broadcom, weshalb die meisten der nachfolgenden Informationen auch für andere auf dem Markt befindliche Switches, die auf ähnlichen ASICs basieren, zutreffen werden.

Wie aus der obigen Abbildung ersichtlich ist, sind die „Content-Aware Engines“ direkt für die Arbeit der ACL im Chipset zuständig, sowohl für „ingress“ als auch für „egress“. Architektonisch sind sie identisch, nur dass „egress“ weniger skalierbar und weniger funktional ist. Physisch sind beide „Content-Aware Engines“ TCAM-Speicher plus zugehörige Logik, und jede benutzerdefinierte oder systemmäßige ACL-Regel ist eine einfache Bitmaske, die in diesem Speicher geschrieben wird. Deshalb wird der Datenverkehr vom Chipset paketweise und ohne Leistungseinbußen verarbeitet.

Physisch wird dieselbe Ingress/Egress TCAM logisch in mehrere Segmente unterteilt (abhängig von der verfügbaren Speichermenge und der Plattform), die sogenannten „ACL Slices“. Das gleiche geschieht beispielsweise mit einer physisch identischen HDD in Ihrem Laptop, wenn Sie mehrere logische Laufwerke darauf erstellen – C:>, D:>. Jeder ACL-Slice besteht seinerseits aus Speichereinheiten in Form von „Zeilen“, in die die „rules“ (Regeln/Bitmasken) geschrieben werden.

Die Aufteilung der TCAM in ACL-Slices basiert auf einer bestimmten Logik. In jedem einzelnen ACL-Slice können nur kompatible „rules“ gespeichert werden. Wenn eine der „rules“ nicht mit der vorherigen kompatibel ist, wird sie in den nächsten ACL-Slice gespeichert, unabhängig davon, wie viele freie Zeilen für „rules“ im vorherigen Slice noch verfügbar sind.

Woher kommt also diese Verträglichkeit oder Unverträglichkeit von ACL-Regeln? Das liegt daran, dass eine "Zeile" im 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 reichen aus, um eine Bitmaske einer bestimmten MAC- oder IP-Adresse zu speichern, sind aber erheblich kleiner als der komplette Ethernet-Paketkopf. In jedem einzelnen ACL-Slice führt der ASIC eine unabhängige Suche anhand der in F1-F3 gespeicherten Bitmasken durch. Diese Suche kann insgesamt auf den ersten 128 Bytes des Ethernet-Paketheads durchgeführt werden. Gerade weil die Suche über 128 Bytes erfolgen kann, während nur 29 Bytes gespeichert werden können, muss für eine korrekte Suche eine Verschiebung (Offset) relativ zum Beginn des Pakets eingestellt werden. Der Offset für jedes ACL-Slice wird während der Aufnahme der ersten Regel festgelegt, und wenn beim Hinzufügen der nächsten Regel ein anderer Offset benötigt wird, wird diese Regel als inkompatibel zur ersten betrachtet und in das nächste ACL-Slice geschrieben.

In der nachstehenden Tabelle wird die Verträglichkeitsordnung der Bedingungen dargestellt, die in ACL geschrieben werden. Jede einzelne Zeile enthält die untereinander verträglichen und nicht verträglichen, gebildeten Bitmasken.

Jedes einzelne Paket, das vom ASIC verarbeitet wird, startet eine parallele Suche 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 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 in der ACL sowohl eine "Aktion" (zulassen/ablehnen) als auch ein "Aktion-Modifikator" (zählen/QoS/protokollieren/…) festgelegt sind, wird bei mehrfachen Übereinstimmungen nur die priorisierte "Aktion" ausgeführt, während alle "Aktion-Modifikatoren" ausgeführt werden. Das folgende Beispiel zeigt, dass beide Zähler erhöht werden und die priorisierte "Ablehnen"-Aktion ausgeführt wird.

"ACL Solutions Guide" mit detaillierteren Informationen über die Funktionsweise von ACL, öffentlich zugänglich auf der Website extremenetworks.com. Alle aufgetretenen oder verbleibenden Fragen können jederzeit an die Mitarbeiter unseres Büros gerichtet werden – cis@extremenetworks.com.

Quelle: habr.com