Nexus TCAM: perché una regione di soppressione ARP richiede due slice

Si dimensiona una regione di soppressione ARP, si contano le voci che il progetto richiede, si trova una regione con più capacità libera di così, e la modifica continua a non entrare. Nulla è stato contato male. Il budget che si stava leggendo è misurato in slice, e una funzionalità ritagliata a doppia larghezza ne richiede due prima che qualsiasi voce venga considerata.

Trattate l'allocazione come un problema di disposizione con un numero fisso di unità, e l'aritmetica inizia a comportarsi.

Una regione possiede slice, non voci

Il TCAM su queste piattaforme è diviso in slice, e ogni slice appartiene esattamente a una regione. Le regioni sono dimensionate in slice, e la larghezza della funzionalità determina quante slice consuma come minimo. Una funzionalità a larghezza singola può vivere in una slice; una funzionalità a doppia larghezza richiede una coppia contigua.

Quindi uno slice libero non è automaticamente capacità utilizzabile. Due regioni a larghezza singola su slice separate non si combinano nella coppia richiesta da una nuova regione a doppia larghezza, e la tabella che mostra molto spazio inutilizzato in totale vi parla di una riserva che non potete spendere.

Registrate la linea di base prima di ritagliare

Raccogliete il modello hardware esatto, la versione di NX-OS, le larghezze e le dimensioni attuali delle regioni e le funzionalità che consumano ogni regione. Fatelo prima di qualsiasi modifica, perché dopo un ricaricamento lo stato precedente è un ricordo, non un fatto.

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

I nomi dei comandi variano per piattaforma e versione, e la guida al ritaglio indica quelli validi per il proprio hardware. Leggete l'output che ottenete davvero invece di supporre che un comando di un altro modello produca la stessa tabella.

Poi annotate a cosa serve ogni regione. Una regione VACL è capacità di filtraggio per una ragione, e una regione QoS esiste perché qualcuno l'ha dimensionata per una policy ancora in vigore. Un piano che tratta quegli spazi come spazio recuperabile senza verifica è un piano per rimuovere funzionalità in silenzio. Nominate un proprietario per ogni regione che intendete ridurre, e date a quel proprietario la nuova dimensione prima della finestra.

Considerate anche la direzione. Dove la piattaforma accoppia l'allocazione in ingresso e in uscita, una modifica su un lato può consumare budget sull'altro, e un piano che conta solo la tabella in ingresso sembrerà corretto e fallirà al ricaricamento.

Cosa non fa liberare una grande slice

Ridurre una grande regione a larghezza singola libera una slice. Se la regione di destinazione richiede una coppia, quella singola slice può essere inutile a meno che sia adiacente a un'altra slice libera, e l'adiacenza è una proprietà della disposizione, non del totale.

Questo è il punto in cui le persone concludono che la piattaforma è rotta o che la documentazione è sbagliata. Nessuna delle due cose è vera. Il modello di allocazione fa esattamente ciò che dice, e l'errore era contare lo spazio libero invece di contare le slice libere nelle posizioni giuste. Una volta disegnata la disposizione su carta, la coppia disponibile esiste o non esiste, e questa è una conversazione molto più facile con il proprietario della piattaforma che una discussione sui totali.

C'è anche una trappola di versione che vale la pena nominare. La guida al ritaglio di Cisco descrive una generazione hardware specifica e afferma chiaramente che il suo modello non è né Cloud Scale né Silicon One. I nomi delle regioni, le dimensioni predefinite e persino quali funzionalità sono a doppia larghezza differiscono altrove, quindi un avviso su una regione specifica su una piattaforma è una prova su quella piattaforma e versione, non una ricetta universale.

Cambiare una regione è un cambio di funzionalità

Ogni ritaglio è uno scambio di capacità. Ridurre una regione per fare spazio alla soppressione ARP riduce ciò che quella regione proteggeva, e la conseguenza potrebbe non comparire finché la policy che ha bisogno dello spazio non viene riapplicata.

Ottenete l'accordo scritto del proprietario di ogni funzionalità interessata prima della finestra. Non è burocrazia: chi ha dimensionato originariamente la regione VACL sa cosa filtra, e chi fa spazio di solito non lo sa.

Aspettatevi un ricaricamento per le modifiche che alterano la disposizione hardware. Alcune piattaforme lo richiedono e altre no, ma pianificare senza una finestra di manutenzione quando un ricaricamento è possibile è il modo in cui una modifica di routing diventa un'interruzione. Programmate la finestra attorno al ricaricamento e non attorno al comando, e conservate il testo del profilo precedente da qualche parte dove potete leggerlo da una console che ha perso la sua sessione di gestione.

Applicate e verificate rispetto alla linea di base

Applicate il piano tramite il processo supportato della piattaforma, poi verificate le funzioni che avete conservato, non solo quella che avete aggiunto. Una regione appena ritagliata che funziona mentre il filtraggio ha smesso silenziosamente di corrispondere è un risultato peggiore del guasto originale.

Rileggete l'output della capacità e confrontatelo con la linea di base che avete registrato, poi testate la funzionalità che ha motivato la modifica. La guida al ritaglio di Nexus TCAM è il riferimento per il modello di larghezza e slice descritto qui, inclusa la generazione hardware che copre.