Label pro VRF oder pro Präfix? Die echte Kapazitätsrechnung

Zwei Designs werben für dasselbe Kundenpräfix über denselben Provider-Core. Das eine weist ein Label pro Präfix zu, das andere ein einziges Label für die gesamte VRF, und das zweite sieht auf jeder Folie billiger aus. Die Labelzahl ist real, aber sie ist nicht das Budget, das üblicherweise zuerst ausgeht. Die Wahl zwischen beiden bedeutet, vier Ressourcen zu zählen statt einer, und die Labels sind die kleinste davon.

Die Wahl hängt auch davon ab, was der Egress-Router mit dem Paket tun muss, nachdem er das Label entfernt hat. Dieser funktionale Unterschied, nicht die Label-Arithmetik, sollte die Entscheidung treiben.

Was jede Zuweisung tatsächlich spart

Die Zuweisung pro Präfix trägt Weiterleitungsinformationen im Label. Der Egress-Router kann das Paket direkt an die richtige Adjacency senden, ohne eine Zielsuche, weshalb sie bei großen VRF-Routensätzen gut skaliert und weshalb sie ein Label für jedes angekündigte Präfix in jeder VRF verbraucht. Die Zuweisung pro VRF, etwa Junos vrf-table-label, kündigt ein Label pro Routing-Instanz an und nutzt dieses Label, um die VRF-Tabelle auszuwählen; der Router führt dann eine IP-Suche innerhalb der Tabelle durch.

Das ist ein echter Architekturunterschied und kein Abstimmknopf. Labeling pro VRF liefert einen kleineren Labelraum und eine einfachere Ankündigung, um den Preis einer Suche und eines Labels, das nichts über das Ziel aussagt. Labeling pro Präfix gibt der Egress-Linecard vorab mehr Informationen und kostet Labels im Verhältnis zu den Routen, die Sie tragen.

Das Label-Konto ist das kleine

MPLS-Labels sind endlich, aber der Labelraum ist groß genug, dass gewöhnliche Service-Provider ihn mit ein paar tausend Präfixen nicht erschöpfen. Wo Labeling pro VRF wirklich hilft, sind Plattformen mit kleinen Hardware-Labeltabellen oder Designs, in denen eine einzelne VRF einen vollen Internet-Feed trägt und Labels pro Präfix den Labelbedarf mit der Routenzahl vervielfachen würden. Das sind reale Einschränkungen, und sie sind der Grund, warum es die Funktion gibt. Keine davon betrifft die Zahl der Präfixe in der Tabelle.

Zählen Sie Labels für den Dienst und den Transport, bevor Sie wählen. Ein Design pro VRF braucht weiterhin Transportlabels für die Loopbacks und für jeden Hop auf dem Pfad, und es braucht weiterhin Adjacency-Zustand. Wenn das Design-Briefing nur Dienstlabels zählt, wird die Ersparnis auf dem falschen Konto gemessen.

Route-Feeds kosten Speicher vor Labels

Jeder empfangene Pfad verbraucht Steuerungsebene-Speicher, Update-Verarbeitung und Konvergenzzeit, ob die VRF nun ein Label oder zehntausend verwendet. Ein voller Internet-Feed innerhalb einer VRF ist teuer wegen der BGP-Pfade, der RIB, der FIB-Einträge und der Änderungen dahinter, nicht wegen des Labels vor der Tabelle. Derselbe Feed erhöht auch den Schadensradius eines Route Leaks oder eines Policy-Fehlers innerhalb dieses Mandanten.

Fragen Sie also, was der Kunde tatsächlich braucht. Wenn der Vertrag private Standorte plus einen Standardausgang umfasst, fügt eine volle Tabelle Kosten hinzu, ohne eine Anforderung hinzuzufügen. Das ist eine kommerzielle Frage, und sie verdient eine schriftliche Antwort statt einer Annahme, die aus dem letzten Design geerbt wurde. Wenn der Dienst den Feed wirklich für Policy oder für lokale Ausgangsauswahl braucht, machen Sie daraus eine ausdrückliche Position mit eigener Kapazitätsreservierung und eigenem Fehlerverhalten.

Wann Labeling pro VRF der richtige Standard ist

Es ist ein guter Standard, wenn die Plattform es als unterstützt dokumentiert, wenn die VRF-Routenzahl groß ist und wenn die Kosten der Egress-Suche für das Verkehrsprofil akzeptabel sind. Es ist auch die natürliche Wahl, wenn operative Einfachheit mehr zählt als die letzte Mikrosekunde aus der Weiterleitung herauszupressen, denn ein Label pro Mandant ist leichter zu erklären und zu prüfen als ein Label pro Präfix.

Es ist der falsche Standard, wenn die Dokumentation der Plattform die Funktion an bestimmte Hardware- oder Release-Einschränkungen bindet oder wenn das Design von Weiterleitungsentscheidungen pro Präfix am Egress abhängt. Lesen Sie die eigene Referenz der Plattform zur Aussage, bevor Sie das Verhalten annehmen; der Junos-Befehl ist dokumentiert, aber die Hardware- und Release-Grenzen darum herum entscheiden tatsächlich über den Einsatz.

Ein Budget, das Sie verteidigen können

Bauen Sie den Kapazitätsfall als fünf getrennte Zahlen: empfangene Pfade, ausgewählte Routen, installierte Weiterleitungseinträge, Dienstlabels und Transportlabels. Ergänzen Sie Next-Hop- und Adjacency-Zustand, Mandantenzahl und das Redundanzmodell. Eine Momentaufnahme des Glückspfads einer einzelnen VRF ist keine Skalenzahl, und eine nominale Labelraumgröße ist keine verfügbare Hardwaretabelle.

Dann vereinbaren Sie den Fehlermodus ebenso wie den Dauerzustand. Was passiert, wenn der Feed um die Hälfte wächst, wenn ein Mandant eine zweite VRF hinzufügt oder wenn die Plattform einen Neustart braucht, um eine Tabelle neu zu dimensionieren? Ein Budget, das diese Fragen übersteht, ist mehr wert als eine Labelzahl, die nur auf dem Papier funktioniert.

Wählen Sie die Zuweisung nach der Egress-Aktion und den Plattformgrenzen, und machen Sie dann den Route-Feed zu einer ausdrücklichen Dienstentscheidung. Das Label ist der sichtbare Teil des Designs; die Routen sind der Teil, für den jeden Tag bezahlt werden muss.