Võrguseadmete ACL-e (Access Control List) saab rakendada nii riist- kui ka tarkvaras või üldisemalt riist- ja tarkvarapõhistes ACL-ides. Ja kui tarkvarapõhiste ACL-idega peaks kõik selge olema - need on reeglid, mida salvestatakse ja töödeldakse RAM-is (st juhtimistasandil) koos kõigi sellest tulenevate piirangutega, siis mõistame, kuidas riistvarapõhiseid ACL-e rakendatakse ja kuidas see toimib. artiklit. Näitena kasutame Extreme Networksi ExtremeSwitching seeria lüliteid.
Kuna oleme huvitatud riistvarapõhistest ACL-idest, on andmetasandi või tegelike kasutatavate kiibikomplektide (ASIC) sisemine rakendamine meie jaoks ülimalt oluline. Kõik Extreme Networksi kommutaatoriliinid on üles ehitatud Broadcomi ASIC-idele ja seetõttu kehtib suurem osa allolevast teabest ka muude turul olevate lülitite kohta, mis on rakendatud samadel ASIC-idel.
Nagu ülaltoodud jooniselt näha, vastutab "ContentAware Engine" otseselt ACL-ide toimimise eest kiibistikus, eraldi "sisenemise" ja "väljapääsu" eest. Arhitektuuriliselt on need samad, ainult "väljapääs" on vähem skaleeritav ja vähem funktsionaalne. Füüsiliselt on mõlemad "ContentAware mootorid" TCAM-mälu ja sellega kaasnev loogika ning iga kasutaja või süsteemi ACL-reegel on sellesse mällu kirjutatud lihtne bitimask. Seetõttu töötleb kiibistik liiklust paketthaaval ja ilma jõudluse halvenemiseta.
Füüsiliselt jaguneb seesama Ingress/Egress TCAM omakorda loogiliselt mitmeks segmendiks (olenevalt mälumahust endast ja platvormist), nn “ACL-i viiludeks”. Näiteks sama asi juhtub füüsiliselt sama kõvakettaga sülearvutis, kui loote sellele mitu loogilist draivi - C:>, D:>. Iga ACL-lõik koosneb omakorda mälurakkudest "stringide" kujul, kuhu on kirjutatud "reeglid" (reeglid/bitimaskid).
TCAM-i jagamisel ACL-lõikudeks on teatud loogika. Igasse üksikusse ACL-lõiku saab kirjutada ainult üksteisega ühilduvaid "reegleid". Kui mõni “reeglitest” ei ühildu eelmisega, siis kirjutatakse see järgmisse ACL-lõigu, olenemata sellest, mitu vaba rida “reeglite” jaoks on eelmises alles.
Kust siis see ACL-reeglite ühilduvus või mitteühilduvus tuleb? Fakt on see, et üks TCAM-i "rida", kuhu on kirjutatud "reeglid", on 232 bitti pikk ja jagatud mitmeks väljaks - Fixed, Field1, Field2, Field3. Konkreetse MAC- või IP-aadressi bitimaski salvestamiseks piisab 232-bitisest või 29-baidisest TCAM-mälust, kuid palju vähem kui täielik Etherneti paketi päis. Igas üksikus ACL-lõikes teostab ASIC sõltumatu otsingu vastavalt F1-F3 bitimaskile. Üldiselt saab seda otsingut teostada Etherneti päise esimese 128 baiti kasutades. Tegelikult, kuna otsingut saab teha üle 128 baiti, aga kirjutada saab ainult 29 baiti, tuleb õigeks otsinguks määrata nihe paketi alguse suhtes. Iga ACL-lõigu nihe määratakse, kui sellele kirjutatakse esimene reegel ja kui järgmise reegli kirjutamisel avastatakse vajadus uue nihke järele, loetakse selline reegel esimesega kokkusobimatuks ja kirjutatakse reeglisse. järgmine ACL-lõik.
Allolev tabel näitab ACL-is määratud tingimuste ühilduvuse järjekorda. Iga rida sisaldab genereeritud bitimaske, mis ühilduvad üksteisega ja ei ühildu teiste liinidega.
Iga ASIC-i poolt töödeldud üksikpakett käivitab paralleelse otsingu igas ACL-lõigul. Kontrollitakse kuni esimese vasteni ACL-lõigul, kuid sama paketi jaoks on erinevates ACL-lõikudes lubatud mitu vastet. Igal üksikul “reeglil” on vastav toiming, mis tuleb sooritada, kui tingimus (bitimask) on sobitatud. Kui kokkulangevus esineb korraga mitmes ACL-lõigul, siis “Action Conflict Resolution” plokis tehakse ACL-lõigu prioriteedi alusel otsus, millist toimingut teha. Kui ACL sisaldab nii “toimingut” (luba/keela) kui ka “action-modifier” (count/QoS/log/…), siis mitme vaste korral teostatakse ainult kõrgema prioriteediga “action”, samas kui “action” -modifier” on kõik valmis. Allolev näide näitab, et mõlemat loendurit suurendatakse ja täidetakse kõrgema prioriteediga "keelamine".
üksikasjalikuma teabega veebisaidil avalikus omandis oleva ACL-i toimimise kohta . Kõik küsimused, mis tekivad või jäävad, võib alati esitada meie kontori töötajatele - .
Allikas: www.habr.com