Nexus TCAM: Warum eine ARP-Suppression-Region zwei Slices braucht

Sie dimensionieren eine ARP-Suppression-Region, zählen die Einträge, die das Design braucht, finden eine Region mit mehr freier Kapazität als das, und die Änderung passt trotzdem nicht. Es wurde nichts falsch gezählt. Das Budget, das Sie gelesen haben, wird in Slices gemessen, und ein Feature, das als doppelt breit geschnitten wird, braucht zwei davon, bevor irgendein Eintrag betrachtet wird.

Behandeln Sie die Zuordnung als Layoutproblem mit einer festen Anzahl von Einheiten, und die Arithmetik beginnt, sich zu benehmen.

Eine Region besitzt Slices, nicht Einträge

TCAM ist auf diesen Plattformen in Slices unterteilt, und jeder Slice gehört genau zu einer Region. Regionen werden in Slices dimensioniert, und die Breite des Features bestimmt, wie viele Slices es mindestens verbraucht. Ein einfach breites Feature kann in einem Slice leben; ein doppelt breites Feature braucht ein zusammenhängendes Paar.

Ein freier Slice ist also nicht automatisch nutzbare Kapazität. Zwei einfach breite Regionen auf getrennten Slices verbinden sich nicht zu dem Paar, das eine neue doppelt breite Region benötigt, und die Tabelle, die insgesamt reichlich ungenutzten Platz zeigt, erzählt Ihnen von einem Pool, den Sie nicht ausgeben können.

Halten Sie die Baseline fest, bevor Sie schneiden

Sammeln Sie das genaue Hardwaremodell, die NX-OS-Version, die aktuellen Regionsbreiten und -größen und die Features, die jede Region verbrauchen. Tun Sie das vor jeder Änderung, denn nach einem Reload ist der frühere Zustand eine Erinnerung und keine Tatsache.

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

Befehlsnamen variieren je nach Plattform und Version, und der Carving-Leitfaden nennt diejenigen, die für seine eigene Hardware gelten. Lesen Sie die Ausgabe, die Sie tatsächlich erhalten, statt anzunehmen, dass ein Befehl von einem anderen Modell dieselbe Tabelle erzeugt.

Schreiben Sie dann auf, wofür jede Region da ist. Eine VACL-Region ist aus einem Grund Filterkapazität, und eine QoS-Region existiert, weil jemand sie für eine Richtlinie dimensioniert hat, die noch gilt. Ein Plan, der diese Flächen ohne Prüfung als rückgewinnbaren Platz behandelt, ist ein Plan, Features still zu entfernen. Benennen Sie einen Eigentümer für jede Region, die Sie verkleinern wollen, und geben Sie diesem Eigentümer die neue Größe vor dem Wartungsfenster.

Berücksichtigen Sie auch die Richtung. Wo die Plattform die Zuweisung von Ingress und Egress koppelt, kann eine Änderung auf der einen Seite Budget auf der anderen verbrauchen, und ein Plan, der nur die Ingress-Tabelle zählt, sieht korrekt aus und scheitert beim Reload.

Was das Freigeben eines großen Slices nicht leistet

Das Verkleinern einer großen einfach breiten Region gibt einen Slice frei. Wenn Ihre Zielregion ein Paar braucht, kann dieser einzelne Slice nutzlos sein, es sei denn, er grenzt an einen anderen freien Slice, und Nachbarschaft ist eine Eigenschaft des Layouts und nicht der Summe.

Das ist der Punkt, an dem Leute zu dem Schluss kommen, die Plattform sei defekt oder die Dokumentation falsch. Beides stimmt nicht. Das Zuordnungsmodell tut genau das, was es sagt, und der Fehler bestand darin, freien Platz zu zählen statt freie Slices an den richtigen Positionen. Sobald Sie das Layout auf Papier gezeichnet haben, existiert das verfügbare Paar entweder oder nicht, und das ist ein viel leichteres Gespräch mit dem Plattformbesitzer als ein Streit über Summen.

Es gibt auch eine Versionsfalle, die es wert ist, benannt zu werden. Der Carving-Leitfaden von Cisco beschreibt eine bestimmte Hardwaregeneration und stellt klar fest, dass sein Modell weder Cloud Scale noch Silicon One ist. Regionsnamen, Standardgrößen und sogar welche Features doppelt breit sind, unterscheiden sich anderswo, sodass eine Warnung zu einer bestimmten Region auf einer Plattform ein Beleg über diese Plattform und Version ist, kein universelles Rezept.

Eine Region zu ändern ist eine Feature-Änderung

Jedes Carving ist ein Kapazitätstausch. Eine Region zu verkleinern, um Platz für ARP-Suppression zu schaffen reduziert das, was diese Region geschützt hat, und die Folge zeigt sich vielleicht erst, wenn die Richtlinie, die den Platz braucht, erneut angewendet wird.

Lassen Sie sich vor dem Wartungsfenster schriftlich vom Eigentümer jedes betroffenen Features zustimmen. Das ist keine Bürokratie: Wer die VACL-Region ursprünglich dimensioniert hat, weiß, was sie filtert, und wer Platz schafft, weiß es in der Regel nicht.

Rechnen Sie bei Änderungen, die das Hardware-Layout verändern, mit einem Reload. Manche Plattformen verlangen ihn, manche nicht, aber ohne Wartungsfenster zu planen, wenn ein Reload möglich ist, ist der Weg, auf dem eine Routing-Änderung zum Ausfall wird. Legen Sie das Fenster um den Reload und nicht um den Befehl, und bewahren Sie den bisherigen Profiltext an einem Ort auf, an dem Sie ihn von einer Konsole lesen können, die ihre Managementsitzung verloren hat.

Anwenden und gegen die Baseline prüfen

Wenden Sie den Plan über den unterstützten Prozess der Plattform an und prüfen Sie dann die Funktionen, die Sie erhalten haben, nicht nur die hinzugefügte. Eine neu geschnittene Region, die funktioniert, während die Filterung still aufgehört hat zu passen, ist ein schlechteres Ergebnis als der ursprüngliche Fehler.

Lesen Sie die Kapazitätsausgabe erneut und vergleichen Sie sie mit der festgehaltenen Baseline, und testen Sie dann das Feature, das die Änderung ausgelöst hat. Der Nexus-TCAM-Carving-Leitfaden ist die Referenz für das hier beschriebene Breiten- und Slice-Modell, einschließlich der Hardwaregeneration, die er abdeckt.