Nexus TCAM: por que unha rexión de supresión de ARP necesita dúas fatías
As entradas lóxicas son só a metade do orzamento. Unha función tallada como dobre ancho necesita un par de fatías, e unha única fatía libre no lugar equivocado non serve.
Vostede dimensiona unha rexión de supresión de ARP, conta as entradas que necesita o deseño, atopa unha rexión con máis capacidade libre ca iso, e o cambio segue sen caber. Nada se contou mal. O orzamento que estaba lendo mídese en fatías, e unha función tallada como dobre ancho necesita dúas delas antes de considerar calquera entrada.
Trate a asignación como un problema de disposición cun número fixo de unidades, e a aritmética empezará a comportarse.
Unha rexión posúe fatías, non entradas
O TCAM nestas plataformas divídese en fatías, e cada fatía pertence exactamente a unha rexión. As rexións dimensiónanse en fatías, e o ancho da función determina cantas fatías consume como mínimo. Unha función de ancho simple pode vivir nunha fatía; unha función de dobre ancho necesita un par contiguo.
| Concept | What it means when you plan |
|---|---|
| Slice | The indivisible unit; it belongs to one region and cannot be shared |
| Feature width | Single or double; a double-width feature must have two slices available |
| Logical entries | What the feature wants to store, which only matters after the slices are allocated |
Así que unha fatía libre non é capacidade utilizábel automaticamente. Dúas rexións de ancho simple en fatías separadas non se combinan no par que require unha nova rexión de dobre ancho, e a táboa que mostra moito espazo sen usar en total fálalle dun fondo que non pode gastar.
Rexistre a liña base antes de tallar
Reúna o modelo exacto de hardware, a versión de NX-OS, os anchos e tamaños actuais das rexións e as funcións que consomen cada rexión. Faga isto antes de calquera cambio, porque tras unha recarga o estado anterior é un recordo, non un feito.
show version
show hardware capacity
show running-config | include hardware profileOs nomes das ordes varían segundo a plataforma e a versión, e a guía de tallado nomea as que se aplican ao seu propio hardware. Lea a saída que realmente obtén en lugar de supoñer que unha orde doutro modelo produce a mesma táboa.
Despois anote para que serve cada rexión. Unha rexión VACL é capacidade de filtrado por algunha razón, e unha rexión QoS existe porque alguén a dimensionou para unha política que segue vixente. Un plan que trata eses espazos como espazo recuperábel sen comprobalo é un plan para eliminar funcións en silencio. Nomee un propietario para cada rexión que pense reducir, e déalle a ese propietario o novo tamaño antes da ventá.
Teña en conta tamén a dirección. Onde a plataforma acopla a asignación de entrada e saída, un cambio nun lado pode consumir orzamento no outro, e un plan que só conta a táboa de entrada parecerá correcto e fallará ao recargar.
Que non fai liberar unha fatía grande
Reducir unha rexión grande de ancho simple libera unha fatía. Se a súa rexión obxectivo necesita un par, esa fatía única pode ser inútil a menos que sexa adxacente a outra fatía libre, e a adxacencia é unha propiedade da disposición, non do total.
Este é o punto no que a xente conclúe que a plataforma está rota ou que a documentación é incorrecta. Ningunha das dúas cousas é certa. O modelo de asignación fai exactamente o que di, e o erro foi contar espazo libre en lugar de contar fatías libres nas posicións correctas. Unha vez que debuxou a disposición no papel, o par dispoñible existe ou non existe, e esa é unha conversación moito máis doada co propietario da plataforma ca unha discusión sobre totais.
Tamén hai unha trampa de versión que paga a pena nomear. A guía de tallado de Cisco describe unha xeración concreta de hardware e afirma claramente que o seu modelo non é nin Cloud Scale nin Silicon One. Os nomes das rexións, os tamaños predeterminados e mesmo que funcións son de dobre ancho difiren noutros lugares, así que un aviso sobre unha rexión concreta nunha plataforma é evidencia sobre esa plataforma e versión, non unha receita universal.
Cambiar unha rexión é un cambio de función
Cada tallado é un intercambio de capacidade. Reducir unha rexión para facer sitio para a supresión de ARP reduce o que esa rexión protexía, e a consecuencia pode non aparecer ata que se volva aplicar a política que necesita o espazo.
Consiga que o propietario de cada función afectada estea de acordo por escrito antes da ventá. Iso non é burocracia: quen dimensionou orixinalmente a rexión VACL sabe que filtra, e quen fai sitio xeralmente non o sabe.
Espere unha recarga para os cambios que alteran a disposición do hardware. Algunhas plataformas exíxena e outras non, pero planificar sen unha ventá de mantemento cando unha recarga é posíbel é como un cambio de encamiñamento se converte nunha interrupción. Programe a ventá arredor da recarga e non arredor da orde, e garde o texto do perfil anterior nalgún lugar onde poida lelo desde unha consola que perdeu a súa sesión de xestión.
Aplique e verifique contra a liña base
Aplique o plan mediante o proceso compatible da plataforma, e despois verifique as funcións que conservou, non só a que engadiu. Unha rexión recentemente tallada que funciona mentres o filtrado deixou de coincidir en silencio é un resultado peor có fallo orixinal.
Volva ler a saída de capacidade e compáraa coa liña base que rexistrou, e despois probe a función que motivou o cambio. A guía de tallado de Nexus TCAM é a referencia para o modelo de ancho e fatías descrito aquí, incluída a xeración de hardware que cobre.