Nexus TCAM: hvorfor en ARP-suppressionsregion kræver to slices

Du dimensionerer en ARP-suppressionsregion, tæller de poster, designet kræver, finder en region med mere ledig kapacitet end det, og ændringen passer stadig ikke. Intet var talt forkert. Budgettet, du læste, måles i slices, og en funktion, der skæres som dobbeltbred, kræver to af dem, før nogen post overhovedet overvejes.

Betragt tildelingen som et layoutproblem med et fast antal enheder, og regnestykket begynder at opføre sig.

En region ejer slices, ikke poster

TCAM på disse platforme er opdelt i slices, og hver slice tilhører præcis én region. Regioner dimensionseres i slices, og funktionens bredde bestemmer, hvor mange slices den som minimum bruger. En enkeltbred funktion kan ligge i én slice; en dobbeltbred funktion kræver et sammenhængende par.

Så en ledig slice er ikke automatisk brugbar kapacitet. To enkeltbrede regioner på adskilte slices kombineres ikke til det par, en ny dobbeltbred region kræver, og tabellen, der viser rigeligt med ubrugt plads i alt, fortæller dig om en pulje, du ikke kan bruge.

Registrer baseline, før du skærer

Indsaml den præcise hardwaremodel, NX-OS-versionen, de nuværende regionsbredder og -størrelser og de funktioner, der bruger hver region. Gør det før enhver ændring, for efter en genindlæsning er den tidligere tilstand en erindring, ikke en kendsgerning.

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

Kommandonavne varierer efter platform og version, og skæringsvejledningen nævner dem, der gælder for dens egen hardware. Læs det output, du faktisk får, i stedet for at antage, at en kommando fra en anden model giver samme tabel.

Skriv derefter ned, hvad hver region er til. En VACL-region er filterkapacitet af en grund, og en QoS-region findes, fordi nogen dimensionerede den til en politik, der stadig gælder. En plan, der behandler dem som genvindeligt plads uden at kontrollere, er en plan om stille at fjerne funktioner. Udpeg en ejer for hver region, du agter at skrumpe, og giv den ejer den nye størrelse før vinduet.

Tag også højde for retning. Hvor platformen kobler tildeling af indgående og udgående trafik, kan en ændring på den ene side bruge budget på den anden, og en plan, der kun tæller den indgående tabel, vil se korrekt ud og fejle ved genindlæsning.

Hvad frigivelsen af én stor slice ikke gør

At skrumpe en stor enkeltbred region frigiver én slice. Hvis din målregion kræver et par, kan den ene slice være ubrugelig, medmindre den støder op til en anden ledig slice, og naboskab er en egenskab ved layoutet, ikke ved totalen.

Det er her, folk konkluderer, at platformen er i stykker, eller at dokumentationen er forkert. Ingen af delene er sandt. Tildelingsmodellen gør præcis, hvad den siger, og fejlen var at tælle ledig plads i stedet for ledige slices de rigtige steder. Når du først har tegnet layoutet på papir, findes det tilgængelige par enten eller ej, og det er en meget lettere samtale med platformsejeren end en diskussion om totaler.

Der er også en versionfælde, der er værd at nævne. Ciscos skæringsvejledning beskriver en bestemt hardwaregeneration og siger rent ud, at dens model hverken er Cloud Scale eller Silicon One. Regionsnavne, standardstørrelser og endda hvilke funktioner der er dobbeltbrede, er anderledes andre steder, så en advarsel om en bestemt region på én platform er evidens om den platform og version, ikke en universel opskrift.

At ændre en region er en funktionsændring

Hvert snit er en kapacitetshandel. At skrumpe en region for at gøre plads til ARP-suppression reducerer det, regionen beskyttede, og konsekvensen viser sig måske først, når politikken, der har brug for pladsen, anvendes igen.

Få ejeren af hver berørt funktion til at acceptere skriftligt før vinduet. Det er ikke bureaukrati: personen, der oprindeligt dimensionerede VACL-regionen, ved, hvad den filtrerer, og personen, der skaber plads, ved det generelt ikke.

Forvent en genindlæsning for ændringer, der ændrer hardwarelayoutet. Nogle platforme kræver det, andre ikke, men at planlægge uden et vedligeholdelsesvindue, når en genindlæsning er mulig, er måden, en routingændring bliver et afbrud. Planlæg vinduet omkring genindlæsningen snarere end omkring kommandoen, og opbevar den tidligere profiltekst et sted, hvor du kan læse den fra en konsol, der har mistet sin administrationssession.

Anvend og verificer mod baseline

Anvend planen gennem platformens understøttede proces, og verificer derefter de funktioner, du bevarede, ikke kun den, du tilføjede. En nyskåret region, der virker, mens filtreringen stille er holdt op med at matche, er et værre udfald end den oprindelige fejl.

Læs kapacitetsoutputtet igen, og sammenlign det med den baseline, du registrerede, og test derefter den funktion, der motiverede ændringen. Nexus TCAM-skæringsvejledningen er referencen for bredde- og slicemodellen, der beskrives her, inklusive hvilken hardwaregeneration den dækker.