Verkkolaitteiden ACL:t (Access Control List) voidaan toteuttaa sekä laitteistossa että ohjelmistossa, tai yleisemmin sanottuna laitteisto- ja ohjelmistopohjaisissa ACL-luetteloissa. Ja jos kaiken pitäisi olla selvää ohjelmistopohjaisten ACL-luetteloiden kanssa - nämä ovat sääntöjä, jotka tallennetaan ja käsitellään RAM-muistissa (eli ohjaustasolla) ja kaikki niistä johtuvat rajoitukset, niin ymmärrämme, kuinka laitteistopohjaiset ACL-luettelot toteutetaan ja toimivat. artikla. Esimerkkinä käytämme Extreme Networksin ExtremeSwitching-sarjan kytkimiä.
Koska olemme kiinnostuneita laitteistopohjaisista ACL-luetteloista, Data Planen sisäinen toteutus tai käytetyt varsinaiset piirisarjat (ASIC) ovat meille ensiarvoisen tärkeitä. Kaikki Extreme Networks -kytkinlinjat on rakennettu Broadcom ASIC:ille, ja siksi suurin osa alla olevista tiedoista pätee myös muihin markkinoilla oleviin kytkimiin, jotka on toteutettu samoilla ASIC-korteilla.
Kuten yllä olevasta kuvasta voidaan nähdä, "ContentAware Engine" on suoraan vastuussa piirisarjan ACL-luetteloiden toiminnasta, erikseen "sisääntulosta" ja "poistumisesta". Arkkitehtonisesti ne ovat samat, vain "ulostulo" on vähemmän skaalautuva ja vähemmän toimiva. Fyysisesti molemmat "ContentAware Enginet" ovat TCAM-muistia ja siihen liittyvää logiikkaa, ja jokainen käyttäjän tai järjestelmän ACL-sääntö on tähän muistiin kirjoitettu yksinkertainen bittimaski. Tästä syystä piirisarja käsittelee liikennettä paketti kerrallaan ilman suorituskyvyn heikkenemistä.
Fyysisesti sama Ingress/Egress TCAM puolestaan on jaettu loogisesti useisiin segmentteihin (itse muistin määrästä ja alustasta riippuen), ns. "ACL-lohkoiksi". Esimerkiksi sama asia tapahtuu fyysisesti samalla kiintolevyllä kannettavassa tietokoneessa, kun luot sille useita loogisia asemia - C:>, D:>. Jokainen ACL-lohko puolestaan koostuu muistisoluista "merkkijonojen" muodossa, joihin "säännöt" (säännöt/bitimaskit) kirjoitetaan.
TCAM:n jakamisessa ACL-viipaleiksi on taustalla tietty logiikka. Jokaiseen yksittäiseen ACL-lohkoon voidaan kirjoittaa vain keskenään yhteensopivia "sääntöjä". Jos jokin "säännöistä" ei ole yhteensopiva edellisen kanssa, se kirjoitetaan seuraavaan ACL-viipaleeseen riippumatta siitä, kuinka monta vapaata riviä "säännöille" on jäljellä edellisessä.
Mistä tämä ACL-sääntöjen yhteensopivuus tai yhteensopimattomuus sitten tulee? Tosiasia on, että yksi TCAM-rivi, jolle "säännöt" on kirjoitettu, on 232 bitin pituus ja jaettu useisiin kenttiin - Kiinteä, Kenttä1, Kenttä2, Kenttä3. 232-bittinen tai 29-tavuinen TCAM-muisti riittää tallentamaan tietyn MAC- tai IP-osoitteen bittimaskin, mutta paljon vähemmän kuin koko Ethernet-paketin otsikko. Jokaisessa yksittäisessä ACL-lohkossa ASIC suorittaa itsenäisen haun F1-F3:ssa asetetun bittimaskin mukaisesti. Yleensä tämä haku voidaan suorittaa käyttämällä Ethernet-otsikon ensimmäistä 128 tavua. Itse asiassa juuri siksi, että haku voidaan suorittaa yli 128 tavua, mutta vain 29 tavua voidaan kirjoittaa, oikeaa hakua varten on asetettava siirtymä suhteessa paketin alkuun. Kunkin ACL-lohkon siirtymä asetetaan, kun ensimmäinen sääntö kirjoitetaan siihen, ja jos myöhempää sääntöä kirjoitettaessa havaitaan tarve toiselle siirtymälle, tällainen sääntö katsotaan yhteensopimattomaksi ensimmäisen kanssa ja kirjoitetaan seuraava ACL-lohko.
Alla oleva taulukko näyttää ACL:ssä määritettyjen ehtojen yhteensopivuusjärjestyksen. Jokainen yksittäinen rivi sisältää generoituja bitimaskeja, jotka ovat yhteensopivia keskenään ja yhteensopimattomia muiden linjojen kanssa.
Jokainen ASIC:n käsittelemä yksittäinen paketti suorittaa rinnakkaishaun kussakin ACL-lohkossa. Tarkastus suoritetaan ACL-lohkon ensimmäiseen yhteensopivuuteen asti, mutta samalle paketille sallitaan useita osumia eri ACL-lohkoissa. Jokaisella yksittäisellä "säännöllä" on vastaava toiminto, joka on suoritettava, jos ehto (bittimaski) osuu. Jos yhteensopivuus esiintyy useissa ACL-lohkoissa kerralla, niin "Toimintoristiriitojen ratkaisu" -lohkossa tehdään ACL-lohkon prioriteetin perusteella päätös, mikä toiminto suoritetaan. Jos ACL sisältää sekä "action" (salli/kieltä) ja "action-modifier" (count/QoS/log/…), useiden osumien tapauksessa suoritetaan vain korkeamman prioriteetin "toiminto" kun taas "toiminta" -modifier” on kaikki valmis. Alla oleva esimerkki osoittaa, että molempia laskureita kasvatetaan ja korkeamman prioriteetin "deny" suoritetaan.
tarkempia tietoja ACL:n toiminnasta julkisesti verkkosivustolla . Kaikki heräävät tai jäävät kysymykset voidaan aina esittää toimistomme henkilökunnalle - .
Lähde: will.com