Az ACL-ek (Access Control List) a hálózati eszközökön megvalósíthatók mind hardverben, mind szoftverben, vagy általánosabban mondva, hardver- és szoftveralapú ACL-ekben. És ha mindennek egyértelműnek kell lennie a szoftver alapú ACL-ekkel - ezek a szabályok, amelyeket a RAM-ban tárolnak és dolgoznak fel (azaz a vezérlősíkon), az ebből következő korlátozásokkal együtt, akkor megértjük, hogyan valósulnak meg a hardveralapú ACL-ek, és hogyan működnek. cikk. Példaként az Extreme Networks ExtremeSwitching sorozatának kapcsolóit fogjuk használni.
Mivel minket a hardver alapú ACL-ek érdekelnek, a Data Plane belső megvalósítása, vagy a ténylegesen használt lapkakészletek (ASIC-ek) kiemelten fontos számunkra. Az Extreme Networks összes kapcsolóvonala Broadcom ASIC-re épül, ezért az alábbi információk többsége igaz lesz a piacon lévő többi, ugyanazon ASIC-en megvalósított switchre is.
Amint az a fenti ábrán látható, a „ContentAware Engine” közvetlenül felelős a lapkakészletben található ACL-ek működéséért, külön a „belépésért” és a „kilépésért”. Építészetileg ugyanazok, csak a „kilépés” kevésbé skálázható és kevésbé funkcionális. Fizikailag mindkét „ContentAware Engine” TCAM memória és a hozzá tartozó logika, és minden egyes felhasználói vagy rendszer ACL-szabály egy egyszerű bitmaszk, amelyet ebbe a memóriába írnak. Ez az oka annak, hogy a lapkakészlet a forgalmat csomagonként és teljesítményromlás nélkül dolgozza fel.
Fizikailag ugyanaz az Ingress/Egress TCAM logikailag több szegmensre oszlik (magától és a platformtól függően), az úgynevezett „ACL szeletekre”. Ugyanez történik például fizikailag ugyanazzal a HDD-vel a laptopon, ha több logikai meghajtót hoz létre rajta - C:>, D:>. Minden ACL-szelet viszont memóriacellákból áll „karakterláncok” formájában, ahol „szabályok” (szabályok/bitmaszkok) vannak írva.
A TCAM ACL-szeletekre való felosztása egy bizonyos logikát rejt magában. Az egyes ACL-szeletek mindegyikébe csak egymással kompatibilis „szabályok” írhatók. Ha valamelyik „szabály” nem kompatibilis az előzővel, akkor az a következő ACL-szeletbe kerül, függetlenül attól, hogy az előzőben hány szabad sor maradt a „szabályokhoz”.
Akkor honnan ered az ACL-szabályok kompatibilitása vagy inkompatibilitása? A tény az, hogy egy TCAM „sor”, ahol a „szabályok” vannak írva, 232 bit hosszúságú, és több mezőre van osztva - Fixed, Field1, Field2, Field3. A 232 bites vagy 29 bájtos TCAM memória elegendő egy adott MAC vagy IP cím bitmaszkjának rögzítéséhez, de sokkal kevesebb, mint a teljes Ethernet csomagfejléc. Minden egyes ACL-szeletben az ASIC független keresést hajt végre az F1-F3-ban beállított bitmaszk szerint. Általában ezt a keresést az Ethernet fejléc első 128 bájtjával lehet végrehajtani. Valójában éppen azért, mert a keresés 128 bájton keresztül is végrehajtható, de csak 29 bájt írható, a helyes kereséshez a csomag elejéhez képest eltolást kell beállítani. Az eltolás minden ACL-szelethez az első szabály írásakor kerül beállításra, és ha egy következő szabály írásakor újabb eltolás szükségességét fedezik fel, akkor az ilyen szabályt összeegyeztethetetlennek tekintik az elsővel, és a szabályba írják. következő ACL-szelet.
Az alábbi táblázat az ACL-ben meghatározott feltételek kompatibilitási sorrendjét mutatja. Minden egyes sor generált bitmaszkokat tartalmaz, amelyek kompatibilisek egymással és nem kompatibilisek más vonalakkal.
Az ASIC által feldolgozott minden egyes csomag párhuzamos keresést hajt végre minden ACL-szeletben. Az ellenőrzést az ACL-szelet első egyezéséig hajtják végre, de több egyezés is megengedett ugyanahhoz a csomaghoz a különböző ACL-szeletekben. Minden egyes „szabályhoz” tartozik egy megfelelő művelet, amelyet végre kell hajtani, ha a feltétel (bitmaszk) illeszkedik. Ha egyezés több ACL-szeletben történik egyszerre, akkor a „Műveletkonfliktus-feloldás” blokkban az ACL-szelet prioritása alapján döntés születik, hogy melyik műveletet kell végrehajtani. Ha az ACL „action” (engedély/megtagadás) és „action-modifier” (count/QoS/log/…) is tartalmaz, akkor többszörös egyezés esetén csak a magasabb prioritású „action” kerül végrehajtásra, míg az „action” -módosító” befejeződik. Az alábbi példa azt mutatja, hogy mindkét számláló növekszik, és a magasabb prioritású „megtagadás” kerül végrehajtásra.
részletesebb információkkal az ACL működéséről nyilvánosan a weboldalon . Bármilyen felmerülő vagy továbbra is felmerülő kérdéssel fordulhat az iroda munkatársaihoz - .
Forrás: will.com