Nexus TCAM: varför en ARP-suppressionsregion behöver två slices

Du dimensionerar en ARP-suppressionsregion, räknar posterna som designen behöver, hittar en region med mer ledig kapacitet än så, och ändringen får fortfarande inte plats. Ingenting räknades fel. Budgeten du läste mäts i slices, och en funktion som skärs som dubbelbred behöver två av dem innan någon post beaktas.

Behandla tilldelningen som ett layoutproblem med ett fast antal enheter, och aritmetiken börjar bete sig.

En region äger slices, inte poster

TCAM på dessa plattformar är uppdelat i slices, och varje slice tillhör exakt en region. Regioner dimensioneras i slices, och funktionens bredd avgör hur många slices den förbrukar som minst. En enkelbred funktion kan leva i en slice; en dubbelbred funktion behöver ett sammanhängande par.

Så en ledig slice är inte automatiskt användbar kapacitet. Två enkelbreda regioner på separata slices kombineras inte till det par en ny dubbelbred region kräver, och tabellen som visar gott om oanvänt utrymme totalt berättar om en pool du inte kan spendera.

Registrera baslinjen innan du skär

Samla in den exakta hårdvarumodellen, NX-OS-versionen, regionernas nuvarande bredder och storlekar samt funktionerna som förbrukar varje region. Gör detta före varje ändring, för efter en omstart är det tidigare tillståndet ett minne, inte ett faktum.

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

Kommandonamn varierar efter plattform och version, och skärningsguiden anger de som gäller för dess egen hårdvara. Läs den utdata du faktiskt får i stället för att anta att ett kommando från en annan modell ger samma tabell.

Skriv sedan ned vad varje region är till för. En VACL-region är filterkapacitet av en anledning, och en QoS-region finns eftersom någon dimensionerade den för en policy som fortfarande gäller. En plan som behandlar dessa ytor som återvinningsbart utrymme utan kontroll är en plan för att tyst ta bort funktioner. Utse en ägare för varje region du tänker krympa, och ge den ägaren den nya storleken före fönstret.

Ta hänsyn till riktning också. Där plattformen kopplar ihop tilldelningen av inkommande och utgående trafik kan en ändring på ena sidan förbruka budget på den andra, och en plan som bara räknar den inkommande tabellen ser korrekt ut och misslyckas vid omstart.

Vad frigörandet av en stor slice inte gör

Att krympa en stor enkelbred region frigör en slice. Om din målregion behöver ett par kan den enda slicen vara värdelös om den inte ligger intill en annan ledig slice, och närhet är en egenskap hos layouten, inte hos totalen.

Det här är punkten där folk drar slutsatsen att plattformen är trasig eller att dokumentationen är fel. Ingen av delarna är sann. Tilldelningsmodellen gör exakt vad den säger, och felet var att räkna ledigt utrymme i stället för lediga slices på rätt positioner. När du väl har ritat layouten på papper finns det tillgängliga paret antingen eller inte, och det är ett mycket lättare samtal med plattformsägaren än ett gräl om totaler.

Det finns också en versionsfälla som är värd att nämna. Ciscos skärningsguide beskriver en specifik hårdvarugeneration och säger klart att dess modell varken är Cloud Scale eller Silicon One. Regionnamn, standardstorlekar och till och med vilka funktioner som är dubbelbreda skiljer sig någon annanstans, så en varning om en specifik region på en plattform är bevis om den plattformen och versionen, inte ett universellt recept.

Att ändra en region är en funktionsändring

Varje snitt är en kapacitetshandel. Att krympa en region för att göra plats för ARP-suppression minskar det regionen skyddade, och konsekvensen kanske inte syns förrän policyn som behöver utrymmet tillämpas igen.

Få ägaren till varje berörd funktion att godkänna skriftligt före fönstret. Det är inte byråkrati: personen som ursprungligen dimensionerade VACL-regionen vet vad den filtrerar, och personen som skapar utrymme vet det vanligtvis inte.

Räkna med en omstart för ändringar som ändrar hårdvarulayouten. Vissa plattformar kräver det och andra inte, men att planera utan ett underhållsfönster när en omstart är möjlig är hur en routingändring blir ett avbrott. Schemalägg fönstret kring omstarten och inte kring kommandot, och förvara den tidigare profilteksten någonstans där du kan läsa den från en konsol som har förlorat sin hanteringssession.

Tillämpa och verifiera mot baslinjen

Tillämpa planen via plattformens stödda process och verifiera sedan de funktioner du bevarade, inte bara den du lade till. En nyskuren region som fungerar medan filtreringen tyst har slutat matcha är ett sämre utfall än det ursprungliga felet.

Läs kapacitetsutdata igen och jämför med den baslinje du registrerade, och testa sedan funktionen som motiverade ändringen. Nexus TCAM-skärningsguiden är referensen för bredd- och slicemodellen som beskrivs här, inklusive vilken hårdvarugeneration den täcker.