ACLer (Access Control List) på nettverksenheter kan implementeres både i maskinvare og programvare, eller mer vanlig sagt, maskinvare- og programvarebaserte ACLer. Og hvis alt skulle være klart med programvarebaserte ACL-er - dette er regler som lagres og behandles i RAM (dvs. på kontrollplanet), med alle påfølgende restriksjoner, så vil vi forstå hvordan maskinvarebaserte ACL-er implementeres og fungerer våre artikkel. Som eksempel vil vi bruke brytere fra ExtremeSwitching-serien fra Extreme Networks.
Siden vi er interessert i maskinvarebaserte ACL-er, er den interne implementeringen av Dataplanet, eller de faktiske brikkesettene (ASIC-ene) som brukes, av største betydning for oss. Alle Extreme Networks-svitsjlinjer er bygget på Broadcom ASIC-er, og derfor vil det meste av informasjonen nedenfor også gjelde for andre svitsjer på markedet som er implementert på samme ASIC-er.
Som det fremgår av figuren ovenfor, er "ContentAware Engine" direkte ansvarlig for driften av ACL-er i brikkesettet, separat for "ingress" og "egress". Arkitektonisk er de de samme, bare "utgang" er mindre skalerbar og mindre funksjonell. Fysisk er begge "ContentAware Engines" TCAM-minne pluss tilhørende logikk, og hver bruker- eller system-ACL-regel er en enkel bitmaske skrevet til dette minnet. Det er derfor brikkesettet behandler trafikk pakke for pakke og uten ytelsesforringelse.
Fysisk er den samme Ingress/Egress TCAM på sin side logisk delt inn i flere segmenter (avhengig av selve minnemengden og plattformen), de såkalte "ACL-skivene". For eksempel skjer det samme med fysisk samme HDD på den bærbare datamaskinen når du oppretter flere logiske stasjoner på den - C:>, D:>. Hver ACL-slice består på sin side av minneceller i form av "strenger" hvor "regler" (regler/bitmasker) er skrevet.
Inndelingen av TCAM i ACL-skiver har en viss logikk bak seg. I hver av de individuelle ACL-skivene kan bare "regler" som er kompatible med hverandre skrives. Hvis noen av "reglene" ikke er kompatible med den forrige, vil den bli skrevet til neste ACL-slice, uavhengig av hvor mange ledige linjer for "regler" som er igjen i den forrige.
Hvor kommer så denne kompatibiliteten eller inkompatibiliteten til ACL-reglene fra? Faktum er at en TCAM "linje", der "regler" er skrevet, har en lengde på 232 biter og er delt inn i flere felt - Fixed, Field1, Field2, Field3. 232 bit eller 29 byte TCAM-minne er nok til å registrere bitmasken til en spesifikk MAC- eller IP-adresse, men mye mindre enn hele Ethernet-pakkeoverskriften. I hver individuelle ACL-slice utfører ASIC et uavhengig oppslag i henhold til bitmasken satt i F1-F3. Generelt kan dette oppslaget utføres ved å bruke de første 128 bytene i Ethernet-overskriften. Faktisk, nettopp fordi søket kan utføres over 128 byte, men bare 29 byte kan skrives, for et korrekt oppslag må en offset settes i forhold til begynnelsen av pakken. Forskyvningen for hver ACL-slice settes når den første regelen skrives til den, og hvis behovet for en annen forskyvning oppdages ved skriving av en påfølgende regel, anses en slik regel som uforenlig med den første og skrives til neste ACL-skive.
Tabellen nedenfor viser kompatibilitetsrekkefølgen til betingelsene spesifisert i ACL. Hver enkelt linje inneholder genererte bitmasker som er kompatible med hverandre og inkompatible med andre linjer.
Hver enkelt pakke behandlet av ASIC kjører et parallelt oppslag i hver ACL-slice. Kontrollen utføres til den første matchen i ACL-slicen, men flere matcher er tillatt for samme pakke i forskjellige ACL-slices. Hver enkelt "regel" har en tilsvarende handling som må utføres hvis betingelsen (bitmaske) matches. Hvis en match oppstår i flere ACL-stykker på en gang, blir det tatt en avgjørelse i "Action Conflict Resolution"-blokken, basert på prioriteten til ACL-slicen, hvilken handling som skal utføres. Hvis tilgangskontrollisten inneholder både "handling" (permit/deny) og "action-modifier" (count/QoS/log/...), vil kun den høyere prioriterte "handlingen" bli utført i tilfelle av flere treff, mens "action" -modifier" vil bli fullført. Eksemplet nedenfor viser at begge tellerne vil økes og "avslå" med høyere prioritet vil bli utført.
med mer detaljert informasjon om driften av ACL i det offentlige domene på nettstedet . Eventuelle spørsmål som dukker opp eller gjenstår kan alltid stilles til vårt kontorpersonale - .
Kilde: www.habr.com