ACL (Access Control List) suudavad võrgu seadmetes olla realiseeritud nii riistvara kui ka tarkvara kaudu, või nagu tavatsetud öelda, hardware ja software-based ACL. Ja kui tarkvara-põhiste ACL-ide puhul peaks kõik selge olema — need on reeglid, mis salvestatakse ja töödeldakse muutmääras (st Control Plane'is), koos kõigi sellega kaasnevate piirangutega, siis uurime, kuidas riistvara-põhised ACL-id on realiseeritud ja toimivad meie artiklis. Näiteks kasutatakse Extreme Networks'i ExtremeSwitching seeria lüliteid.

Kuna meid huvitavad eelkõige riistvara-põhised ACL-id, on meie jaoks äärmiselt oluline just Data Plane'i sisemine rakendus või kasutatavad kiibid (ASIC). Kõik Extreme Networks'i lülitusliinid põhinevad Broadcom'i ASIC-del, seetõttu kehtib enamik alltoodud teabest ka teiste turul esindatud, samade ASIC-dega realiseeritud lülitite kohta.
Как видно из рисунка выше непосредственно за работу ACL в чипсете отвечают “ContentAware Engine”, отдельно на “ingress” и “egress”. Архитектурно они одинаковы, только “egress” менее масштабируемый, и менее функциональный. Физически же оба “ContentAware Engine” это TCAM память плюс сопутствующая логика, а каждое пользовательское или системное правило ACL это простая бит маска (bit-mask) записанная в эту память. Именно поэтому обработка чипсетом трафика осуществляется попакетно и без деградации производительности.
Физически одна и та же Ingress/Egress TCAM в свою очередь делится логически на несколько сегментов (зависит от количества самой памяти и платформы), так называемые “ACL slices”. К примеру, тоже самое происходит с физически одним и тем же HDD на вашем ноутбуке, когда вы создаете на нём несколько логических дисков – С:>, D:>. Каждый ACL-slice в свою очередь состоит из ячеек памяти, в виде “строк” куда и записываються “rules” (правила/бит-маски).

TCAM-i jagamine ACL-slice'ideks järgib kindlat loogikat. Igas eraldi ACL-slice'is võivad olla kirjutatud ainult omavahel ühilduvad "reeglid". Kui mõni "reegel" ei ole eelneva reegliga ühilduv, kirjutatakse see järgmisse ACL-slice'i, sõltumata sellest, mitu vabade rida eelnevas "reeglite" osas veel on.
Kust aga tuleneb see ACL reeglite ühilduvus või ühilduvus? Asi on selles, et ühes "rea" TCAM-is, kuhu salvestatakse "reeglid", on pikkus 232 bitti ja see jaguneb mitmeks väljadeks – Fixed, Field1, Field2, Field3. 232 bitti ehk 29 baiti TCAM-mälust on täiesti piisav, et salvestada teatud MAC või IP-aadressi bitmask, kuid see on oluliselt väiksem kui täielik Etherneti paketi pealkiri. Igas eraldi ACL-slices toodab ASIC sõltumatut otsingut F1-F3 bitmaskidesse seadistatud seadistuste põhjal. Üldiselt võib see otsing toimuda esialgsete 128 baiti Etherneti pealkirja järgi. Tegelikult ongi probleem selles, et otsing võib toimuda 128 baitide ulatuses, samas kui salvestatud võib olla vaid 29 baiti, seetõttu peab õigeks otsinguks olema seadistatud nihke (offset) asukoht paketi algusest. Iga ACL-slice jaoks seadistatakse offset esimeses reeglis salvestamise ajal, ja kui järgmise reegli salvestamise ajal avastatakse vajadus teise offseti järele, siis loetakse selline reegel esimesele mitteühilduvaks ja salvestatakse järgmisse ACL-slice'i.
Allpool on toodud ACL-i tingimuste ühilduvuse tabel. Iga rida sisaldab omavahel ühilduvaid ja teiste ridadega ühildumatuid bit-mask'e.

Iga eraldi pakett, mida ASIC töödelda, käivitab iga ACL-slice'i jaoks paralleelse otsingu. Kontrollimine toimub kuni esimese vastavuseni ACL-slice'is, kuid sama paketi puhul on lubatud mitmekordne vastavus erinevates ACL-slice'ides. Iga eraldi 'reegel' sisaldab vastavat toimingut, mida tuleb täita, kui tingimus (bit-mask) on täidetud. Kui vastavus toimub mitmes ACL-slice'is, siis 'Action Conflict Resolution' plokis, ACL-slice'i prioriteedi põhjal, otsustatakse, millist tegevust teostada. Kui ACL-is on määratud nii 'action' (lubamine/keelamine) kui ka 'action-modifier' (arvuta/QoS/logi/...), siis mitmekordsete vastavuste korral täidetakse ainult kõrgema prioriteediga 'action', samas kõik 'action-modifier'id täidetakse. Allolev näide näitab, et mõlemad loendurid suurenevad ja toimub kõrgema prioriteediga 'keelamine'.

detsember 2023 kohta täiendava teabega ACL-i toimimise kohta on avalikult saadaval veebis . Kui teil on küsimusi või muresid, võite alati meie kontori töötajatele pöörduda – .
Allikas: habr.com
