ACL:er (Access Control List) på nätverksenheter kan implementeras både i hårdvara och mjukvara, eller vanligare sagt, hårdvaru- och mjukvarubaserade ACL:er. Och om allt skulle vara klart med mjukvarubaserade ACL:er - det här är regler som lagras och bearbetas i RAM (dvs på kontrollplanet), med alla efterföljande restriktioner, då kommer vi att förstå hur hårdvarubaserade ACL:er implementeras och fungerar vår artikel. Som exempel kommer vi att använda switchar från ExtremeSwitching-serien från Extreme Networks.
Eftersom vi är intresserade av hårdvarubaserade ACL:er är den interna implementeringen av Data Plane, eller de faktiska chipset (ASIC) som används, av största vikt för oss. Alla Extreme Networks switchlinjer är byggda på Broadcom ASICs, och därför kommer det mesta av informationen nedan också att gälla för andra switchar på marknaden som är implementerade på samma ASICs.
Som framgår av figuren ovan är "ContentAware Engine" direkt ansvarig för driften av ACLs i chipsetet, separat för "ingress" och "egress". Arkitektoniskt är de samma, bara "egress" är mindre skalbar och mindre funktionell. Rent fysiskt är båda "ContentAware-motorerna" TCAM-minne plus tillhörande logik, och varje användares eller system-ACL-regel är en enkel bitmask skriven till detta minne. Det är därför som chipset bearbetar trafik paket för paket och utan prestandaförsämring.
Fysiskt är samma Ingress/Egress TCAM i sin tur uppdelad logiskt i flera segment (beroende på mängden minne i sig och plattformen), de så kallade "ACL-skivorna". Till exempel händer samma sak med fysiskt samma hårddisk på din bärbara dator när du skapar flera logiska enheter på den - C:>, D:>. Varje ACL-slice består i sin tur av minnesceller i form av "strängar" där "regler" (regler/bitmasker) skrivs.
Uppdelningen av TCAM i ACL-skivor har en viss logik bakom sig. I var och en av de individuella ACL-snitten kan endast "regler" som är kompatibla med varandra skrivas. Om någon av "reglerna" inte är kompatibel med den föregående, kommer den att skrivas till nästa ACL-del, oavsett hur många lediga rader för "regler" som finns kvar i den föregående.
Var kommer då denna kompatibilitet eller inkompatibilitet av ACL-regler ifrån? Faktum är att en TCAM "linje", där "regler" skrivs, har en längd på 232 bitar och är uppdelad i flera fält - Fixed, Field1, Field2, Field3. 232 bitar eller 29 byte TCAM-minne är tillräckligt för att spela in bitmasken för en specifik MAC- eller IP-adress, men mycket mindre än hela Ethernet-pakethuvudet. I varje enskild ACL-slice utför ASIC:en en oberoende uppslagning enligt bitmasken i F1-F3. I allmänhet kan denna uppslagning utföras med de första 128 byten i Ethernet-huvudet. I själva verket, just för att sökningen kan utföras över 128 byte, men bara 29 byte kan skrivas, för en korrekt uppslag måste en offset ställas in i förhållande till början av paketet. Förskjutningen för varje ACL-del ställs in när den första regeln skrivs till den, och om behovet av en annan offset upptäcks när den efterföljande regeln skrivs, anses en sådan regel vara inkompatibel med den första och skrivs till nästa ACL-skiva.
Tabellen nedan visar kompatibilitetsordningen för de villkor som anges i ACL. Varje enskild rad innehåller genererade bitmasker som är kompatibla med varandra och inkompatibla med andra linjer.
Varje enskilt paket som bearbetas av ASIC kör en parallell uppslagning i varje ACL-segment. Kontrollen utförs fram till den första matchningen i ACL-slicen, men flera matchningar är tillåtna för samma paket i olika ACL-slices. Varje enskild "regel" har en motsvarande åtgärd som måste utföras om villkoret (bitmask) matchas. Om en matchning inträffar i flera ACL-skivor samtidigt, i "Action Conflict Resolution"-blocket, baserat på prioritet för ACL-slicen, fattas ett beslut vilken åtgärd som ska utföras. Om ACL innehåller både "action" (permit/deny) och "action-modifier" (count/QoS/log/...), så kommer endast den högre prioriterade "action" att utföras vid flera matcher, medan "action" -modifier” kommer att slutföras. Exemplet nedan visar att båda räknarna kommer att ökas och "neka" med högre prioritet kommer att exekveras.
med mer detaljerad information om driften av ACL i det offentliga området på webbplatsen . Eventuella frågor som uppstår eller kvarstår kan alltid ställas till vår kontorspersonal - .
Källa: will.com