ACL (Access Control List) na urządzeniach sieciowych mogą być wdrażane zarówno sprzętowo, jak i programowo, znane jako ACL oparte na sprzęcie i oparte na oprogramowaniu. I jeśli chodzi o ACL oparte na oprogramowaniu, to są to zasady przechowywane i przetwarzane w pamięci RAM (tzn. na Control Plane), z wszelkimi wynikającymi stąd ograniczeniami, to jak działają i są wdrażane hardware-based ACL, omówimy w naszym artykule. Jako przykład użyjemy przełączników serii ExtremeSwitching firmy Extreme Networks.
Ponieważ interesują nas hardware-based ACL, kluczowe znaczenie ma wewnętrzna realizacja Data Plane, czy właściwie wykorzystywanych chipów (ASIC). Przełączniki wszystkich linii firmy Extreme Networks są zbudowane na ASIC od Broadcom, dlatego większość poniższych informacji będzie również prawdziwa dla innych przełączników dostępnych na rynku, wdrożonych na takich samych ASIC.
Jak widać na powyższym rysunku, za działanie ACL w chipsecie odpowiadają "ContentAware Engine", osobno dla "ingress" i "egress". Architektonicznie są one identyczne, z tym, że "egress" jest mniej skalowalny i mniej funkcjonalny. Fizycznie obie jednostki "ContentAware Engine" to pamięć TCAM plus towarzysząca logika, a każda reguła ACL użytkownika lub systemowa to prosta maska bitowa (bit-mask) zapisana w tej pamięci. Dlatego przetwarzanie ruchu przez chipset odbywa się pakietowo i bez degradacji wydajności.
Fizycznie ta sama pamięć Ingress/Egress TCAM jest logcznie podzielona na kilka segmentów (zależy od ilości samej pamięci i platformy), tzw. "ACL slices". Na przykład, to samo dzieje się z fizycznie jednym i tym samym HDD w twoim laptopie, gdy tworzysz na nim kilka logicznych dysków – C:>, D:>. Każdy ACL-slice w swoją kolej składa się z komórek pamięci, w formie "wierszy", w których zapisywane są "rules" (reguły/maski bitowe).
Podział TCAM na ACL-slices ma swoją logikę. W każdym z osobnych ACL-slice mogą być zapisane tylko współkompatybilne "rules". Jeśli jakiś "rule" nie jest zgodny z poprzednim, to zostanie zapisany w następnym w kolejności ACL-slice, niezależnie od tego, ile wolnych wierszy dla "rules" pozostało w poprzednim.
Skąd więc bierze się ta zgodność lub niezgodność reguł ACL? Chodzi o to, że jeden „wiersz” TCAM, w którym zapisywane są „reguły”, ma długość 232 bitów i jest podzielony na kilka pól – Fixed, Field1, Field2, Field3. 232 bity lub 29 bajtów pamięci TCAM są wystarczające, aby zapisać maskę bitową określonego adresu MAC lub IP, ale znacznie mniej niż pełny nagłówek pakietu Ethernet. W każdym pojedynczym ACL-slice ASIC wykonuje niezależne wyszukiwanie według ustawionych w F1-F3 masek bitowych. Ogólnie rzecz biorąc, to wyszukiwanie może być przeprowadzane na pierwszych 128 bajtach nagłówka Ethernet. Właściwie to z powodu faktu, że wyszukiwanie może być przeprowadzane na 128 bajtach, a zapisane może być tylko 29 bajtów, dla poprawnego wyszukiwania powinno być ustawione przesunięcie (offset) względem początku pakietu. Offset dla każdego ACL-slice jest ustawiany podczas zapisywania pierwszej reguły, i jeśli przy zapisywaniu kolejnej reguły stwierdzono potrzebę innego offsetu, wówczas taka reguła uznawana jest za niezgodną z pierwszą i zapisywana w następnym ACL-slice.
W poniższej tabeli przedstawiony jest porządek zgodności warunków zapisywanych w ACL. Każdy pojedynczy wiersz zawiera warunki, które są zgodne między sobą, oraz warunki, które są niezgodne z innymi wierszami, tworzące maskę bitową.
Każdy pojedynczy pakiet przetwarzany przez ASIC uruchamia równoległe wyszukiwanie w każdym ACL-slice. Sprawdzanie odbywa się do pierwszego dopasowania w ACL-slice, ale jednocześnie dopuszczane jest wielokrotne dopasowanie dla tego samego pakietu w różnych ACL-slice. Każda pojedyncza „reguła” ma odpowiadającą akcję, którą należy wykonać w przypadku dopasowania warunku (maski bitowej). Jeśli dopasowanie wystąpiło jednocześnie w kilku ACL-slice, to w bloku „Rozwiązywanie konfliktów akcji” na podstawie priorytetu ACL-slice podejmowana jest decyzja, która z działań wykonać. Jeśli w ACL zapisano zarówno „action” (zezwól/odmów), jak i „action-modifier” (licznik/QoS/log/…), to przy wielokrotnych dopasowaniach zostanie wykonana tylko bardziej priorytetowa „action”, podczas gdy wszystkie „action-modifier” będą realizowane. Na poniższym przykładzie pokazano, że oba liczniki zostaną zwiększone, a bardziej priorytetowa „deny” zostanie wykonana.
z bardziej szczegółowymi informacjami na temat działania ACL ogólnie dostępnymi na stronie . Jakiekolwiek pytania, które się pojawiły lub pozostały, zawsze można zadać pracownikom naszego biura – .
Źródło: habr.com
