Ein großes Stern-VPN dimensionieren: erst zählen, dann BGP wählen
Präfixe sind die einfache Zahl. Sitzungen, Update-Last und die Wiederherstellung nach dem Ausfall eines Hubs entscheiden, ob das Design bei einigen tausend Filialen trägt.
Dreitausend Filialen klingen nach einem Routingproblem, verhalten sich aber wie ein Buchhaltungsproblem. Die Präfixsumme ist in zehn Minuten ausgerechnet, und sie ist selten die Zahl, die weh tut. Weh tut die Arbeit pro Sitzung, der Update-Schwall, wenn eine gemeinsame Komponente ausfällt, und die Zeit, bis die Weiterleitung wieder zur neuen Topologie passt.
Gehen Sie die Arithmetik deshalb in der richtigen Reihenfolge durch. Zählen Sie die Beziehungen, zählen Sie die Präfixe und die Alternativen, zählen Sie dann, was in einer schlechten Stunde passiert, und vergleichen Sie erst danach Protokolle und Plattformen. In umgekehrter Reihenfolge wird die Übung zu einer Debatte über Routenlimits, die niemand mit den vorliegenden Informationen entscheiden kann.
Vier Budgets, nicht eines
Jedes Budget beantwortet eine andere Frage, und jedes kann auf einer anderen Plattform die bindende Einschränkung sein. Wer sie getrennt aufschreibt, verhindert, dass eine einzige große Präfixzahl für das gesamte Design einsteht.
| Budget | What you are really counting |
|---|---|
| Sessions | Peers per hub, keepalive or hello processing, authentication state, and the per-neighbor memory that never shows up in a route count |
| Prefixes | Alternatives received, prefixes selected, entries installed for forwarding, and how much of that each spoke is allowed to see |
| Churn | Updates generated by a flapping link, a hub outage, or every branch reconnecting after a regional event |
| Recovery | Time to detect, reselect, reinstall and restore the application, measured end to end rather than per box |
Die letzten beiden werden in einer Design-Review übersprungen. Ein Netz, das im Ruhezustand bequem in den Speicher passt, kann sich immer noch schlecht verhalten, wenn vierhundert Filialen innerhalb von zwei Minuten wieder verbinden, weil die Arbeit schneller eintrifft, als die Control Plane sie abarbeiten kann. Schreiben Sie die Schwallgröße als Zahl auf, zusammen damit, wie lange der Dienst beeinträchtigt bleiben darf. Das macht aus einer vagen Sorge einen Test, den jemand tatsächlich fahren kann.
In allen vier steckt außerdem eine Plattformfrage: ob Verschlüsselung, Weiterleitung und Routing dieselbe CPU teilen oder getrennte Pfade haben. Zwei Geräte mit identischer Routenkapazität können sich unter Last sehr unterschiedlich verhalten, und im Datenblatt steht selten, welches Sie kaufen.
Rechnen Sie mit Ihren eigenen Zahlen
Nehmen Sie ein erdachtes Design: 3,000 Filialen, je drei Präfixe vor der Aggregation und zwei Hubs pro Filiale für Redundanz. Das Hub-Paar muss vor der Zusammenfassung rund 9,000 Filialpräfixe halten, und das Design ergibt 6,000 Sitzungen zwischen Filiale und Hub, wenn jede Filiale mit beiden peert.
Fügen Sie nun die Teile hinzu, die keine Präfixe sind. Jede Sitzung trägt Zustand und periodische Nachrichten, selbst wenn sich nichts ändert. Jeder Hub kann mehr als einen Pfad pro Präfix halten, wenn schnelles Umschalten erwartet wird, sodass die Zahl der Alternativen die der ausgewählten überschreiten kann. Und die Sicht jedes Spokes ist eine eigene Policy-Entscheidung: jeder Filiale die Routen aller anderen zu geben, vervielfacht die Arbeit auf eine Weise, die die Zählung auf der Hub-Seite nicht zeigt.
Das sind Planungszahlen für ein Design-Gespräch, keine Messung eines Produkts. Der nützliche Ertrag der Übung ist die Form der Kurve, nicht eine Aussage darüber, wo ein bestimmter Router aufgibt.
Was BGP bringt und was ein IGP bringt
BGP trennt, was ein Router empfangen, was er ausgewählt und was er angekündigt hat, und jedes davon wird per Policy gesteuert. Genau das braucht ein Filialnetz, denn ein Spoke sollte normalerweise eine Default-Route, die zentralen Dienste und sehr wenig anderes sehen. Zählt man nur die endgültige Tabelle, bleiben die Alternativen und Ankündigungen verborgen, und genau die wachsen, wenn man Redundanz hinzufügt.
Ein IGP ist nicht automatisch falsch. Wenn Topologie, Arealstruktur und Adjacency-Modell zum Dienst passen, konvergiert ein Link-State-Protokoll schnell und braucht weniger Policy-Gerüst. Die Falle ist anzunehmen, es könne dieselbe Exportkontrolle pro Nachbar ausdrücken wie BGP: eine OSPF-Area ist eine Flooding-Grenze, kein Filter, den man an eine Filiale hängt.
Entscheiden Sie in jedem Fall zuerst das Sichtbarkeitsmodell. Defaults, Zusammenfassungen für zentrale Dienste oder vollständige Filialdetails sind drei verschiedene Produkte, und eine Zusammenfassung, die einen spezifischeren Ausfall verbirgt, ist eine Designentscheidung, die aufgeschrieben werden muss, statt sie während einer Störung zu entdecken.
Testen Sie den Schwall, nicht den Ruhezustand
Bauen Sie den Vergleich um den Ausfall herum, den Sie tatsächlich erwarten: ein Hub fällt aus, ein regionales WAN-Ereignis oder ein Wartungsfenster, das die Hälfte der Standorte auf einmal offline nimmt. Messen Sie die Wiederherstellung aus Sicht der Filiale, einschließlich der Anwendung, denn eine Control Plane, die in Sekunden konvergiert, bedeutet wenig, wenn die Sitzung Minuten zum Wiederaufbau braucht.
show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPFHalten Sie fest, was die Plattform am Höhepunkt des Schwalls tut, nicht in Ruhe, und wiederholen Sie es mit aktivierten Sicherheitsfunktionen. Ein Proof of Concept, der nur eine ruhige Tabelle zeigt, ist ein Speichertest, und der Speicher war nie die interessante Zahl.