ACL's (Access Control List) op netwerkapparaten kunnen zowel in hardware als in software worden geïmplementeerd, of, meer algemeen gesproken, op hardware en software gebaseerde ACL's. En als alles duidelijk zou moeten zijn met op software gebaseerde ACL's - dit zijn regels die worden opgeslagen en verwerkt in RAM (dat wil zeggen op het besturingsvlak), met alle daaruit voortvloeiende beperkingen, dan zullen we begrijpen hoe op hardware gebaseerde ACL's worden geïmplementeerd en hoe ze werken. artikel. Als voorbeeld gebruiken we switches uit de ExtremeSwitching-serie van Extreme Networks.
Omdat we geïnteresseerd zijn in op hardware gebaseerde ACL's, is de interne implementatie van Data Plane, of de feitelijk gebruikte chipsets (ASIC's), voor ons van het allergrootste belang. Alle switchlijnen van Extreme Networks zijn gebouwd op Broadcom ASIC's, en daarom geldt de meeste informatie hieronder ook voor andere switches op de markt die op dezelfde ASIC's zijn geïmplementeerd.
Zoals uit de bovenstaande afbeelding blijkt, is de “ContentAware Engine” direct verantwoordelijk voor de werking van ACL’s in de chipset, afzonderlijk voor “ingress” en “egress”. Architectonisch gezien zijn ze hetzelfde, alleen ‘uitgang’ is minder schaalbaar en minder functioneel. Fysiek gezien zijn beide “ContentAware Engines” TCAM-geheugen plus bijbehorende logica, en elke gebruiker of systeem-ACL-regel is een eenvoudig bitmasker dat naar dit geheugen wordt geschreven. Daarom verwerkt de chipset het verkeer pakket voor pakket en zonder prestatieverlies.
Fysiek is dezelfde Ingress/Egress TCAM op zijn beurt logisch verdeeld in verschillende segmenten (afhankelijk van de hoeveelheid geheugen zelf en het platform), de zogenaamde “ACL-plakken”. Hetzelfde gebeurt bijvoorbeeld met fysiek dezelfde HDD op uw laptop wanneer u er meerdere logische schijven op aanmaakt - C:>, D:>. Elke ACL-slice bestaat op zijn beurt uit geheugencellen in de vorm van “strings” waarin “regels” (regels/bitmaskers) worden geschreven.
Er zit een bepaalde logica achter de verdeling van TCAM in ACL-segmenten. In elk van de individuele ACL-slices kunnen alleen “regels” worden geschreven die compatibel zijn met elkaar. Als een van de “regels” niet compatibel is met de vorige, dan wordt deze naar het volgende ACL-segment geschreven, ongeacht hoeveel vrije regels voor “regels” er nog over zijn in de vorige.
Waar komt deze compatibiliteit of incompatibiliteit van ACL-regels dan vandaan? Feit is dat één TCAM-"regel", waar "regels" zijn geschreven, een lengte heeft van 232 bits en is verdeeld in verschillende velden: Vast, Veld1, Veld2, Veld3. 232 bit of 29 byte TCAM-geheugen is voldoende om het bitmasker van een specifiek MAC- of IP-adres op te slaan, maar veel minder dan de volledige Ethernet-pakketheader. In elk afzonderlijk ACL-segment voert de ASIC een onafhankelijke zoekopdracht uit volgens het bitmasker dat is ingesteld in F1-F3. Over het algemeen kan deze zoekopdracht worden uitgevoerd met behulp van de eerste 128 bytes van de Ethernet-header. Juist omdat de zoekopdracht kan worden uitgevoerd over 128 bytes, maar er slechts 29 bytes kunnen worden geschreven, moet voor een correcte opzoeking een offset worden ingesteld ten opzichte van het begin van het pakket. De offset voor elke ACL-slice wordt ingesteld wanneer de eerste regel ernaar wordt geschreven, en als bij het schrijven van een volgende regel de behoefte aan een nieuwe offset wordt ontdekt, wordt een dergelijke regel als incompatibel met de eerste beschouwd en naar de eerste regel geschreven. volgende ACL-segment.
De onderstaande tabel toont de volgorde van compatibiliteit van de voorwaarden die zijn gespecificeerd in de ACL. Elke individuele lijn bevat gegenereerde bitmaskers die compatibel zijn met elkaar en incompatibel met andere lijnen.
Elk individueel pakket dat door de ASIC wordt verwerkt, voert een parallelle zoekopdracht uit in elk ACL-segment. De controle wordt uitgevoerd tot de eerste match in het ACL-segment, maar meerdere matches zijn toegestaan voor hetzelfde pakket in verschillende ACL-segmenten. Elke individuele “regel” heeft een corresponderende actie die moet worden uitgevoerd als aan de voorwaarde (bitmasker) wordt voldaan. Als een match in meerdere ACL-slices tegelijk voorkomt, wordt in het blok “Action Conflict Resolution” op basis van de prioriteit van het ACL-slice besloten welke actie moet worden uitgevoerd. Als de ACL zowel “action” (permit/deny) als “action-modifier” (count/QoS/log/…) bevat, dan zal bij meerdere matches alleen de “action” met hogere prioriteit worden uitgevoerd, terwijl “action -modifier” zal allemaal voltooid zijn. Het onderstaande voorbeeld laat zien dat beide tellers worden verhoogd en dat de hogere prioriteit “deny” wordt uitgevoerd.
met meer gedetailleerde informatie over de werking van ACL in het publieke domein op de website . Eventuele vragen die ontstaan of blijven kunt u altijd stellen aan onze binnendienst - .
Bron: www.habr.com