Nexus TCAM: pse një rajon shtypjeje ARP kërkon dy feta

Ju përcaktoni madhësinë e një rajoni shtypjeje ARP, numëroni regjistrimet që kërkon dizajni, gjeni një rajon me më shumë kapacitet të lirë se kaq, dhe ndryshimi prapë nuk futet. Asgjë nuk u numërua gabim. Buxheti që po lexonit matet në feta, dhe një veçori e prerë si dyfish i gjerë kërkon dy prej tyre para se të merret parasysh çdo regjistrim.

Trajtojeni alokimin si një problem planimetrie me një numër fiks njësish, dhe aritmetika fillon të sillet si duhet.

Një rajon zotëron feta, jo regjistrime

TCAM në këto platforma ndahet në feta, dhe çdo fetë i përket saktësisht një rajoni. Rajonet maten në feta, dhe gjerësia e veçorisë përcakton sa feta konsumon si minimum. Një veçori me gjerësi të vetme mund të jetojë në një fetë; një veçori me gjerësi të dyfishtë kërkon një palë ngjitur.

Pra, një fetë e lirë nuk është automatikisht kapacitet i përdorshëm. Dy rajone me gjerësi të vetme në feta të ndara nuk bashkohen në palën që kërkon një rajon i ri me gjerësi të dyfishtë, dhe tabela që tregon shumë hapësirë të papërdorur në total ju flet për një fond që nuk mund ta shpenzoni.

Regjistroni vijën bazë përpara se të prisni

Mblidhni modelin e saktë të harduerit, versionin e NX-OS, gjerësitë dhe madhësitë aktuale të rajoneve, dhe veçoritë që konsumojnë çdo rajon. Bëjeni këtë përpara çdo ndryshimi, sepse pas një ringarkimi gjendja e mëparshme është kujtim, jo fakt.

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

Emrat e komandave ndryshojnë sipas platformës dhe versionit, dhe udhëzuesi i prerjes emërton ato që vlejnë për harduerin e vet. Lexoni daljen që merrni në të vërtetë në vend që të supozoni se një komandë nga një model tjetër prodhon të njëjtën tabelë.

Pastaj shkruani për çfarë shërben çdo rajon. Një rajon VACL është kapacitet filtrimi për një arsye, dhe një rajon QoS ekziston sepse dikush e mati atë për një politikë që është ende në fuqi. Një plan që i trajton ato hapësira si hapësirë e rikuperueshme pa verifikim është një plan për të hequr veçoritë në heshtje. Emërtoni një pronar për çdo rajon që keni ndërmend të zvogëloni, dhe jepini atij pronari madhësinë e re përpara dritares.

Merrni parasysh edhe drejtimin. Aty ku platforma lidh alokimin e hyrjes dhe daljes, një ndryshim në njërën anë mund të konsumojë buxhet në anën tjetër, dhe një plan që numëron vetëm tabelën e hyrjes do të duket i saktë dhe do të dështojë në ringarkim.

Çfarë nuk bën lirimi i një fete të madhe

Zvogëlimi i një rajoni të madh me gjerësi të vetme liron një fetë. Nëse rajoni tuaj objektiv kërkon një palë, ajo fetë e vetme mund të jetë e padobishme nëse nuk është ngjitur me një fetë tjetër të lirë, dhe afërsia është veti e planimetrisë, jo e totalit.

Ky është pika ku njerëzit konkludojnë se platforma është prishur ose se dokumentacioni është i gabuar. Asnjëra nuk është e vërtetë. Modeli i alokimit bën saktësisht atë që thotë, dhe gabimi ishte numërimi i hapësirës së lirë në vend të numërimit të fetave të lira në pozicionet e duhura. Pasi të keni vizatuar planimetrinë në letër, pala e disponueshme ose ekziston ose nuk ekziston, dhe kjo është një bisedë shumë më e lehtë me pronarin e platformës sesa një sherr për totalet.

Ekziston edhe një kurth versioni që ia vlen të përmendet. Udhëzuesi i prerjes së Cisco përshkruan një gjeneratë specifike hardueri dhe deklaron qartë se modeli i tij nuk është as Cloud Scale as Silicon One. Emrat e rajoneve, madhësitë e paracaktuara dhe madje cilat veçori janë me gjerësi të dyfishtë ndryshojnë diku tjetër, kështu që një paralajmërim për një rajon të caktuar në një platformë është provë për atë platformë dhe version, jo një recetë universale.

Ndryshimi i një rajoni është një ndryshim veçorie

Çdo prerje është një shkëmbim kapaciteti. Të zvogëlosh një rajon për të krijuar hapësirë për shtypjen e ARP zvogëlon atë që mbronte ai rajon, dhe pasoja mund të mos shfaqet derisa politika që ka nevojë për hapësirën të zbatohet përsëri.

Përpara dritares merrni pëlqimin me shkrim të pronarit të çdo veçorie të prekur. Kjo nuk është burokraci: personi që mati fillimisht rajonin VACL e di çfarë filtron, dhe personi që krijon hapësirë zakonisht nuk e di.

Prisni një ringarkim për ndryshimet që ndryshojnë planimetrinë e harduerit. Disa platforma e kërkojnë dhe disa jo, por planifikimi pa një dritare mirëmbajtjeje kur ringarkimi është i mundur është mënyra se si një ndryshim rrugëtimi bëhet ndërprerje. Planifikoni dritaren rreth ringarkimit dhe jo rreth komandës, dhe mbani tekstin e profilit të mëparshëm diku ku mund ta lexoni nga një konsolë që ka humbur sesionin e saj të menaxhimit.

Aplikoni dhe verifikoni kundrejt vijës bazë

Aplikoni planin përmes procesit të mbështetur të platformës, pastaj verifikoni funksionet që ruajtët, jo vetëm atë që shtuat. Një rajon i prerë së fundmi që funksionon ndërsa filtrimi ka ndaluar në heshtje të përputhet është një rezultat më i keq se dështimi fillestar.

Lexoni përsëri daljen e kapacitetit dhe krahasojeni me vijën bazë që regjistruat, pastaj provoni veçorinë që motivoi ndryshimin. Udhëzuesi i prerjes së Nexus TCAM është referenca për modelin e gjerësisë dhe fetave të përshkruar këtu, duke përfshirë gjeneratën e harduerit që mbulon.