Nexus TCAM: hvorfor en ARP-suppresjonsregion trenger to slices

Du dimensjonerer en ARP-suppresjonsregion, teller oppføringene designet trenger, finner en region med mer ledig kapasitet enn det, og endringen passer fortsatt ikke. Ingenting ble talt feil. Budsjettet du leste, måles i slices, og en funksjon skåret som dobbeltbred trenger to av dem før noen oppføring vurderes.

Behandle tildelingen som et layoutproblem med et fast antall enheter, og aritmetikken begynner å oppføre seg.

En region eier slices, ikke oppføringer

TCAM på disse plattformene er delt inn i slices, og hver slice tilhører nøyaktig én region. Regioner dimensjoneres i slices, og funksjonens bredde avgjør hvor mange slices den bruker som minimum. En enkeltbred funksjon kan ligge i én slice; en dobbeltbred funksjon trenger et sammenhengende par.

Så en ledig slice er ikke automatisk brukbar kapasitet. To enkeltbrede regioner på separate slices kombineres ikke til paret en ny dobbeltbred region krever, og tabellen som viser rikelig med ubrukt plass totalt, forteller deg om en pool du ikke kan bruke.

Registrer baseline før du skjærer

Samle inn den nøyaktige maskinvarenmodellen, NX-OS-versjonen, gjeldende regionbredder og -størrelser og funksjonene som bruker hver region. Gjør dette før enhver endring, fordi etter en omstart er den forrige tilstanden et minne, ikke et faktum.

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

Kommandonavn varierer etter plattform og versjon, og skjæreveiledningen nevner de som gjelder for dens egen maskinvare. Les utdataene du faktisk får i stedet for å anta at en kommando fra en annen modell gir samme tabell.

Skriv deretter ned hva hver region er til. En VACL-region er filterkapasitet av en grunn, og en QoS-region finnes fordi noen dimensjonerte den for en policy som fortsatt gjelder. En plan som behandler disse områdene som gjenvinningbart plass uten å sjekke, er en plan for å fjerne funksjoner stille. Utpek en eier for hver region du har tenkt å krympe, og gi den eieren den nye størrelsen før vinduet.

Ta hensyn til retning også. Der plattformen kobler tildeling av inngående og utgående trafikk, kan en endring på den ene siden bruke budsjett på den andre, og en plan som bare teller inngående tabell vil se riktig ut og feile ved omstart.

Hva det å frigjøre én stor slice ikke gjør

Å krympe en stor enkeltbred region frigjør én slice. Hvis målregionen din trenger et par, kan den ene slicen være ubrukelig med mindre den er ved siden av en annen ledig slice, og naboskap er en egenskap ved layouten, ikke ved totalen.

Dette er punktet der folk konkluderer med at plattformen er ødelagt eller at dokumentasjonen er feil. Ingen av delene er sant. Tildelingsmodellen gjør nøyaktig det den sier, og feilen var å telle ledig plass i stedet for ledige slices på de riktige plassene. Når du først har tegnet layouten på papir, finnes det tilgjengelige paret enten eller ikke, og det er en mye lettere samtale med plattformeieren enn en krangel om totaler.

Det finnes også en versjonsfelle som er verdt å nevne. Ciscos skjæreveiledning beskriver en bestemt maskinvargenerasjon og sier klart at modellen dens verken er Cloud Scale eller Silicon One. Regionnavn, standardstørrelser og til og med hvilke funksjoner som er dobbeltbrede varierer andre steder, så en advarsel om en bestemt region på én plattform er bevis om den plattformen og versjonen, ikke en universell oppskrift.

Å endre en region er en funksjonsendring

Hvert snitt er en kapasitetshandel. Å krympe en region for å gjøre plass til ARP-suppresjon reduserer det regionen beskyttet, og konsekvensen viser seg kanskje først når policyen som trenger plassen, brukes på nytt.

Få eieren av hver berørt funksjon til å godta skriftlig før vinduet. Det er ikke byråkrati: personen som opprinnelig dimensjonerte VACL-regionen, vet hva den filtrerer, og personen som lager plass, vet det vanligvis ikke.

Forvent en omstart for endringer som endrer maskinvarelayouten. Noen plattformer krever det, andre ikke, men å planlegge uten et vedlikeholdsvindu når en omstart er mulig, er måten en rutingendring blir et avbrudd. Planlegg vinduet rundt omstarten og ikke rundt kommandoen, og oppbevar den forrige profilteksten et sted der du kan lese den fra en konsoll som har mistet administrasjonsøkten sin.

Bruk og verifiser mot baseline

Bruk planen gjennom plattformens støttede prosess, og verifiser deretter funksjonene du bevarte, ikke bare den du la til. En nyskåret region som fungerer mens filtreringen stille har sluttet å samsvare, er et verre utfall enn den opprinnelige feilen.

Les kapasitetsutdataene på nytt og sammenlign dem med baseline du registrerte, og test deretter funksjonen som motiverte endringen. Nexus TCAM-skjæreveiledningen er referansen for bredde- og slicemodellen som beskrives her, inkludert hvilken maskinvargenerasjon den dekker.