BGP-Full-Table-Verarbeitung: Juniper CP/DP Convergence Testing

Im Rahmen der Qualifikation unterziehen wir neue Hardware oder Software in unserem XT³Lab üblicherweise einem umfangreichen Testing aus langen Listen einzelner Szenarien und Testfälle. Ein Beispiel dafür ist die unlängst durchgeführt Qualifikation von Juniper Networks PTX10001-36MR. Hierbei durchlief das Gerät dutzende Testschritte wie z.B. dem zur „BGP Control Plane / Data Plane Convergence“ (CP/DP Convergence).

Dieser Artikel beschäftigt sich mit Hintergründen und Details des CP/DP-Testings. Dazu stellen wir auch die Ergebnisse verschiedenster Geräte in Deutschlands größtem Juniper Technologie- & Test-Labor vor, die wir – u.a. zur besseren Bewertung des PTX – ebenfalls den CP/DP-Convergence-Tests unterzogen haben.

Verarbeitung von BGP-Full-Tables auf Control-Plane/Data-Plane moderner Router

In Service-Provider-Kontexten wird oftmals das Border Gateway Protocol (BGP) eingesetzt, um sogenannte „Full-Tables“ zu transportieren und Routing-Informationen auszutauschen. Eine BGP-Full-Table umfasst alle im Internet bekannten IP-Ziele sowie den Weg dorthin. Basierend auf Quellen wie z.B. https://bgp.potaroo.net/, aber auch auf BGP-Full-Tables, welche wir selbst im XT³Lab von Partnern und Carriern aktiv empfangen, bedeutet das aktuell +/- 920.000 Einträge für IPv4 und bis zu 155.000 Einträge für IPv6.

Ein Router hält alle diese Einträge im Speicher auf der Control Plane vor. Zum Weiterleiten von Datenpaketen wird daraus für jedes Ziel lediglich der beste Weg ausgewählt und in der Data Plane programmiert. Dieser Vorgang ist auf modernen Hardware-basierten Routing-Plattformen jeweils sehr ähnlich und wird kontinuierlich wiederholt, da im globalen Internet konstant Routen aktualisiert, zurückgezogen oder anderweitig geändert werden.

CP/DP-Convergence – warum ist das relevant?

Empfängt ein Router BGP-Full-Tables von mehr als nur einer Quelle, muss er zunächst alle Informationen im Speicher vorhalten und aus jeglichen Optionen den einen besten Weg heraussuchen, um diesen in die Data Plane zu überführen. Im Rahmen des regulären Betriebs ist dies für die Control Plane an sich keine große Herausforderung, da zu jedem Zeitpunkt maximal ein paar Handvoll Updates zu verarbeiten sind.

Was aber passiert, wenn ein Router, der zuvor von zwei Nachbarn BGP-Full-Tables erhalten hat, z.B. aufgrund eines Ausfalls einer der Peers die bis zu 920.000 IPv4- und 155.000 IPv6-Ziele neu verarbeiten und berechnen muss? Wie lange dauert es in diesem Fall, alle Einträge in der Data Plane zu aktualisieren? – Genau diesen Zeitraum soll der CP/DP-Convergence-Test ermitteln!

CP/DP-Convergence-Testschritte

Bevor wir in die Details der Testmethodik einsteigen, zunächst ein paar Punkte zur Klarstellung:

• Die nachfolgend beschriebenen Tests basieren auf synthetisch herbeigeführten Rahmenparametern. Zusammensetzung und Größe der eingesetzten IP-Prefixes entsprechen nicht der einer „echten“ BGP-Full-Table.
• Es handelt sich um einen unidimensionalen Test, der z.B. nicht den zusätzlichen Effekt weitere BGP-Policies oder parallele Ereignisse auf demselben Router in Betracht zieht.
• Es existieren ggf. Features und Funktionen, welche die Auswirkungen des simulierten Fehlers limitieren könnten. In diesem Test geht es aber darum, die Zeit zu messen, die es benötigt, wenn Control Plane und Data Plane konvergieren müssen, ohne diese Optimierungen aktiviert zu haben.
• Die hier im Test gemessen Zeiten können daher grundsätzlich als bestmögliche Zeiten für den reinen Update-Vorgang interpretiert werden.

1. Lab-Setup

Um die CP/DP-Convergence-Tests durchzuführen, benutzen wir IXIA-Testsysteme von Keysight. Das „Device under Test“ (DUT), welches dem Test unterzogen wird, wird zur rechten mit zwei von der IXIA simulierten BGP-sprechenden Carriern verbunden. Jeder dieser Carrier sendet dieselbe BGP-Full-Table (bestehend aus 900.000 IPv4-Routen) in Richtung des DUT. Es wurde mittels Konfiguration –genutzt wird eine BGP-Policy mit local-pref – dazu gebracht, die Routen von Carrier1 zu bevorzugen. Zusätzlich wird auf der linken Seite noch ein per IXIA simulierter Kunde angeschlossen, der ein einziges /24 IPv4-Prefix sendet.

2. Testgrundlage

Wir erzeugen nun Datenverkehr zwischen dem /24 IPv4-Prefix des Kunden und allen 900.000 /24 IPv4-Prefixes der Carrier. Hierbei wird pro IPv4/24 exemplarisch eine IP als Quelle bzw. Ziel verwendet. So ergeben sich 900.000 individuelle Verkehrsströme. Wir stellen weiterhin sicher, dass jeder dieser Verkehrsströme ausreichend Datenrate (insbesondre Pakete pro Sekunde) aufweist, so dass mindestens ein Packet pro Sekunde pro Datenstrom transportiert wird.

Da die Routen von Carrier1 bevorzugt werden, wird der gesamte Traffic zu Carrier1 geleitet. Damit haben wir die Grundlage für unseren Test geschaffen; ein Zustand, in dem wir keinen Paketverlust oder andere Einschränkungen erwarten.

3. BGP-Withdraw

Das IXIA-Testsystem bietet einen vordefinierten Testmechanismus, welcher nun alle 900.000 IPv4-Prefixes von Carrier1 gleichzeitig zurückziehen wird. Dies geschieht mit Hilfe passender BGP-Nachrichten (Withdraw). Im Rahmen dessen muss das DUT nun

• alle BGP-Withdraw-Nachrichten auf der Control-Plane verarbeiten,
• eine neue Entscheidung über den besten Weg pro Prefix (nun in Richtung Carrier2) treffen,
• die Data-Plane aktualisieren, so dass der Verkehr zu Carrier2 geleitet wird.

Während diese Prozesse ablaufen, wird ein Teil des Verkehrs noch zu Carrier1 zugestellt werden, da die Data-Plane-Einträge noch nicht alle aktualisiert wurden. Ein Teil des Verkehrs wird aber bereits an Carrier2 zugestellt werden. Als vollständig abgeschlossen definieren den Prozess, so bald jeglicher Verkehr zu Carrier2 zugestellt wird und kein Traffic mehr bei Carrier1 ankommt.

Da wir keine physikalischen Interfaces trennen, erwarten wir im Rahmen dieses Tests keinen Paketverlust; alle Pakete werden entweder bei Carrier1 oder Carrier2 zugestellt.

Die Zeitspanne zwischen dem Control-Plane-Ereignis, an dem die Prefixes von Carrier1 zurückgezogen wurden, und dem Zeitpunkt, an dem aller Verkehr auf Carrier2 zugestellt wird, ist die hier im Test dokumentierte CP/DP-Konvergenzzeit für das DUT in Richtung 1.

4. Wiederherstellung

Als nächsten Schritt testen wir auch den Wiederherstellungsfall. Hierbei wird Carrier1 nun wieder alle Prefixes in Richtung des DUT senden. Da es konfiguriert wurde die Routen von Carrier1 zu bevorzugen, wird der Verkehr auch direkt wieder auf Carrier1 zurückgeleitet.

Die Zeitspanne zwischen diesem Control-Plane-Ereignis, an dem die Prefixes von Carrier1 wieder gesendet wurden, und dem Zeitpunkt, an dem aller Verkehr wieder zu Carrier1 zugestellt wird, ist die hier im Test dokumentierte CP/DP-Konvergenzzeit für das DUT in Richtung 2.

Dieser zweite Testschritt dauert üblicherweise etwas länger als der erste Fall, da die BGP-Nachrichten über die neuen Routen verarbeitet werden müssen, bevor eine Entscheidung zum besten Weg getroffen werden kann. Im ersten Fall liegen diese Alternativen bereits in der Control-Plane vor und können direkt pro Route genutzt bzw. ausgewählt werden.

Wie haben wir gemessen und Ergebnisse berechnet?

Wir haben entschieden, jedes DUT insgesamt dreimal dem gesamten Test zu unterziehen, d.h. jeweils einem Test in Richtung 1 (withdraw) und einem Test in Richtung 2 (re-announce). Danach berechnen wir das Mittel der gemessenen Zeiten aller drei Testläufe für Richtung 1 und Richtung 2, also den Mittelwert aus withdraw1, withdraw2 und withdraw3 ebenso wie den Mittelwert aus re-announce1, re-announce2, re-announce3. Um die Werte etwas einfacher vergleichbar zu machen, haben wir zusätzlich das Mittel über beide Richtungen gebildet, so dass wir einen Wert pro DUT pro Test erhalten.

Da wir insgesamt mit einem gleichen Wert von 900.000 Prefixes arbeiten, können wir zusätzlich die Anzahl der aktualisierten Prefixes pro Sekunde bestimmen, in dem wir die Anzahl der Prefixes durch die Konvergenzzeit dividieren. Dieser Wert (pfx/s) macht es relativ einfach, die verschiedenen Test-Plattformen direkt zu vergleichen. Sollten später auch Tests mit kleineren oder größeren Full-Tables nötig werden, ermöglicht es zudem einen relativ direkten Vergleich zwischen leicht unterschiedlichen Testreihen.

Ergebnisse verschiedenster Juniper-Geräte im CP/DP-Convergence-Test

Als größtes Juniper Networks Technologie- und -Test-Labor in Deutschland stehen in unserem XT³Lab so ziemliche alle Gerätefamilien des Herstellers zur Verfügung. Die im Test verwendeten DUTs verteilen sich dementsprechend über einen großen Teil des Juniper-Portfolios*:

• SRX Series (SRX345, SRX380, SRX1500, SRX4100, SRX5600 (IOC3)
• QFX Series (QFX10002-36Q, QFX10002-60C)
• PTX Series (PTX10001-36MR, PTX10003-80C)
• MX Series (MX80, MX104, MX204, MX10003, MX480 (MPC5/MPC7) MX10008 (LC2101)
• ACX Series (ACX7100-48L)

* Uns ist bewusst, dass einige der getesteten Geräte nicht für den Einsatz als Router mit BGP-Full-Table ausgerichtet sind, nicht alle für diesen Einsatzzweck von Juniper qualifiziert wurden oder in dieser Rolle voll supportet werden. Da einige Betreiber diese Geräte in der Vergangenheit aber – trotz der Sachlage – in entsprechenden Rollen eingesetzt haben, haben wir eben auch diese in die Testreihe aufgenommen.

Die Messergebnisse der Systeme sind in den nachfolgenden Graphen zum direkten Vergleich zusammengefasst. Insgesamt erscheinen uns dabei folgende Erkenntnisse besonders erwähnenswert:

• Die schnellsten Konvergenzzeiten werden bei den auf Juniper-TRIO-ASIC-basierenden und mit x86-Control-Plane ausgestatteten MX-Series-Systemen gemessen.
• In derselben Größenordnung platzieren sich die QFX- und PTX-Series-Geräte basierend auf Juniper-Express-ASICs.
• Die langsamsten Konvergenzzeiten werden auf Software-basierten Plattformen wie etwa Juniper SRX345/380 oder den mit Power-PC-Control-Plane ausgestatteten und auf Trio-ASIC-basierenden MX-Series-Systemen festgestellt.
• Die x86-Software-basierte SRX1500 platziert sich im Mittelfeld.
• Bemerkenswert ist, dass die x86-Software-basierte SRX4100 in derselben Region wie die Trio- oder Express-ASIC-basierten Systeme landet.

Reality-Check: Was bedeutet das nun alles?

Alle hier gemessen Zahlen basieren auf (relativ) aktuellen Software-Versionen der jeweiligen Plattformen (JUNOS 20.4R3). Da wir im XT³Lab seit mehreren Jahren regelmäßig CP/DP-Tests durchführen und einige Systeme auch schon mit früheren Software-Versionen qualifiziert haben, können wir somit sagen, dass sich die Werte bereits signifikant verbessert haben und im Rahmen neuerer JUNOS-Releases vermutlich weiter verbessern.

Ein Beispiel ist hier der MX480 mit MPC5E, an welchem sich der Fortschritt im Bereich pfx/s über die Jahre gut erkennen lässt.

Darüber hinaus sei angemerkt, dass die Testmethode zwischen den blauen bzw. dem grünen Ergebnis leicht angepasst wurde. So wurde in früheren Tests (blau) mit den dort üblichen Full-Table-Größen von 700.000 Prefixes getestet. Da jedoch in derselben Methode auf pfx/s umgerechnet wurde, bleiben die Messwerte vergleichbar. Wir können also klar erkennen, dass auch Optimierungen in Software die Werte stark verbessern können.

Ist aber die CP/DP-Konvergenzzeit die einzig relevante Größe, um die Konvergenz für BGP-Ereignisse zu beurteilen? Natürlich nicht. Wie einleitend in diesem Artikel erwähnt, ist der CP/DP-Test nur einer von vielen dutzenden, die wir im Rahmen von Plattform-Qualifikationen durchführen. Es handelt sich hierbei um eine eindimensionale Betrachtung; in bestimmten Szenarien lassen sich Konvergenzzeiten durch Konfiguration oder Features (z.B. BGP PIC Edge) auch noch weiter optimieren.

Insgesamt haben in diesem Test aber alle Geräte unter identischen Bedingungen dieselben Aufgaben erledigen müssen. Die Ergebnisse geben uns also eine gute Indikation, wie sie sich verhalten, was helfen kann, die passenden Serien bzw. Gerätefamilien für bestimmte Szenarien auszuwählen.

CP/DP-Convergence-Testing – wie geht es weiter?

Da über die Zeit konstant neue Gerätetypen und Familien auf den Markt gebracht werden, wird dieser Artikel aktualisiert und/oder es werden Folgeartikel veröffentlicht. Bereits geplant sind derzeit weitere Tests mit Juniper MX304 und der ACX7000-Gerätefamilie.

Mehr zum Test des PTX10001-36MR erfahren Sie in diesem Artikel.

Teilen Sie Ihre Meinung mit uns!

Ihre Perspektive zählt! Hinterlassen Sie einen Kommentar zu unserem Blogartikel und lassen Sie uns wissen, was Sie denken.