Nexus TCAM: kvifor ein ARP-suppresjonsregion treng to slices

Du dimensjonerer ein ARP-suppresjonsregion, tel oppføringane designet treng, finn ein region med meir ledig kapasitet enn det, og endringa passar framleis ikkje. Ingenting vart talt feil. Budsjettet du las, vert målt i slices, og ein funksjon skoren som dobbeltbrei treng to av dei før noka oppføring vert vurdert.

Behandle tildelinga som eit layoutproblem med eit fast tal einingar, og aritmetikken byrjar å oppføre seg.

Ein region eig slices, ikkje oppføringar

TCAM på desse plattformene er delt inn i slices, og kvar slice høyrer til nøyaktig ein region. Regionar vert dimensjonerte i slices, og breidda til funksjonen avgjer kor mange slices han brukar som minimum. Ein enkeltbrei funksjon kan ligge i éin slice; ein dobbeltbrei funksjon treng eit samanhengande par.

Så ein ledig slice er ikkje automatisk brukbar kapasitet. To enkeltbreie regionar på separate slices kombinerast ikkje til paret ein ny dobbeltbrei region krev, og tabellen som viser rikeleg med ubrukt plass totalt, fortel deg om ein pool du ikkje kan bruke.

Registrer baseline før du skjer

Samle inn den nøyaktige maskinvaremodellen, NX-OS-versjonen, gjeldande regionbreidder og -storleikar og funksjonane som brukar kvar region. Gjer dette før kvar endring, fordi etter ein omstart er den førre tilstanden eit minne, ikkje eit faktum.

show version
show hardware capacity
show running-config | include hardware profile

Kommandonamn varierer etter plattform og versjon, og skjerettleiinga nemner dei som gjeld for hennar eigen maskinvare. Les utdataa du faktisk får i staden for å anta at ein kommando frå ein annan modell gir same tabell.

Skriv deretter ned kva kvar region er til. Ein VACL-region er filterkapasitet av ein grunn, og ein QoS-region finst fordi nokon dimensjonerte han for ein policy som framleis gjeld. Ein plan som behandlar desse områda som gjenvinningbart plass utan å sjekke, er ein plan for å fjerne funksjonar stille. Peik ut ein eigar for kvar region du har tenkt å krympe, og gi den eigaren den nye storleiken før vindauget.

Ta omsyn til retning òg. Der plattforma koplar tildeling av inngåande og utgåande trafikk, kan ei endring på den eine sida bruke budsjett på den andre, og ein plan som berre tel inngåande tabell vil sjå riktig ut og feile ved omstart.

Kva det å frigjere éin stor slice ikkje gjer

Å krympe ein stor enkeltbrei region frigjer éin slice. Viss målregionen din treng eit par, kan den eine slicen vere ubrukeleg med mindre han er ved sida av ein annan ledig slice, og naboskap er ein eigenskap ved layouten, ikkje ved totalen.

Dette er punktet der folk konkluderer med at plattforma er øydelagd eller at dokumentasjonen er feil. Ingen av delane er sanne. Tildelingsmodellen gjer nøyaktig det han seier, og feilen var å telje ledig plass i staden for ledige slices på dei riktige stadene. Når du først har teikna layouten på papir, finst det tilgjengelege paret anten eller ikkje, og det er ein mykje lettare samtale med plattformeigaren enn ein krangel om totalar.

Det finst òg ei versjonsfelle som er verdt å nemne. Skjerettleiinga til Cisco skildrar ein bestemt maskinvaregenerasjon og seier klart at modellen hennar verken er Cloud Scale eller Silicon One. Regionnamn, standardstorleikar og til og med kva funksjonar som er dobbeltbreie varierer andre stader, så ei åtvaring om ein bestemt region på éi plattform er bevis om den plattforma og versjonen, ikkje ein universell oppskrift.

Å endre ein region er ei funksjonsendring

Kvart snitt er ein kapasitetshandel. Å krympe ein region for å gjere plass til ARP-suppresjon reduserer det regionen verna, og konsekvensen viser seg kanskje først når policyen som treng plassen, vert brukt på nytt.

Få eigaren av kvar råka funksjon til å godta skriftleg før vindauget. Det er ikkje byråkrati: personen som opphavleg dimensjonerte VACL-regionen, veit kva han filtrerer, og personen som lagar plass, veit det vanlegvis ikkje.

Vent ein omstart for endringar som endrar maskinvarelayouten. Nokre plattformer krev det, andre ikkje, men å planleggje utan eit vedlikehaldsvindauge når ein omstart er mogleg, er måten ei rutingendring vert eit avbrot. Planlegg vindauget rundt omstarten og ikkje rundt kommandoen, og oppbevar den førre profilteksten ein stad der du kan lese han frå ein konsoll som har mista administrasjonsøkta si.

Bruk og verifiser mot baseline

Bruk planen gjennom den støtta prosessen til plattforma, og verifiser deretter funksjonane du bevarte, ikkje berre den du la til. Ein nyskoren region som fungerer medan filtreringa stille har slutta å samsvare, er eit verre utfall enn den opphavlege feilen.

Les kapasitetsutdataa på nytt og samanlikn dei med baseline du registrerte, og test deretter funksjonen som motiverte endringa. Nexus TCAM-skjerettleiinga er referansen for breidd- og slicemodellen som er skildra her, inkludert kva maskinvaregenerasjon han dekkjer.