Das Testen von neuen Netzkomponenten ist bei der Weiterentwicklung skalierbarer und komplexer Netzwerkarchitekturen essentiell. In diesem Bewusstsein hat Xantaro die Testmöglichkeiten seines XT3Labs in Frankfurt kontinuierlich ausgebaut. Innerhalb unserer Laborumgebung simulieren wir komplexe Szenarien und testen neuste Technologien und Systeme bevor diese von unseren Kunden in Produktionsnetze implementiert werden. Aber auch unabhängig von tatsächlichen Kundenprojekten ermöglichen uns umfangreiche Tests, Innovationen zu erforschen und unsere Kunden herstellerneutral zu beraten. So können wir Lösungen entwickeln, die spezifischen Anforderungen entsprechen oder Fallstricke zum Beispiel hinsichtlich der Skalierbarkeit aufdecken.

 

Testen bedeutet heute mehr als die Generierung von Paketen

Geht es um den Funktionstest der Data-Plane, so existieren diverse Tools, die eine entsprechende Paketgenerierung bis zu einem bestimmten Maß mit Standard-x86-Hardware ermöglichen. Wird die Funktionalität der Control-Plane einem Test unterzogen, entstehen schnell komplexe Szenarien und es bedarf mehr als einfacher Layer 2 oder Layer 3 Paketgenerierung. Die Prüfung der Skalierbarkeit von Protokollen wie BGP, ISIS oder RSVP auf Routing-Plattformen, die Millionen Routing-Einträge unterstützen, ist ein hervorragendes Beispiel.

Besonders interessant wird es, bei der Kombination von Data-Plane- und Control-Plane-Tests. So z.B., wenn eine neue Software-Version für einen MPLS PE-Router für den Netzbetrieb verifiziert werden muss. Das Gerät kann im produktiven Einsatz Millionen von Routing-Einträgen enthalten, die es über BGP von anderen PE-Routern aus dem Core-Netz erhält. Zudem wird ein Interior-Gateway-Protocol (IGP) wie OSPF oder ISIS verwendet, um die Erreichbarkeit der Geräte sicherzustellen, sowie LDP, RSVP oder SPRING, um MPLS Label-Switch-Pfade zwischen diesen Zielen aufzubauen.

 

Ausschlaggebend: Testbedingungen so realitätsnah wie möglich

Für aussagekräftige und zuverlässige Testergebnisse ist es hier essentiell, die gesamte Netzwerkumgebung des „Device Under Test“ (DUT) so genau wie möglich zu berücksichtigen. Ein produktives Netz mit physischer Hardware nachzustellen, ist in der Regel allerdings sehr kostspielig. Der Einsatz virtueller Appliances kann bei der Simulation einer komplexen Netztopologie helfen, Tests in großem Maßstab sind hierbei jedoch sowohl für Control-Plane als auch Data-Plane meist nicht umsetzbar.

Es bräuchte also eine Lösung, die das gesamte Kernnetz eines Providers an einem sowie das Access-Netz mit Kunden an einem weiteren physischen Port simulieren könnte. Zusätzlich sollte diese Lösung in der Lage sein, eine Reihe von PE-Routern und Präfixe zu generieren und Datenverkehr von diesen Präfixen mit den korrekten MPLS-Labeln zum DUT weiterzuleiten. Sobald Pakete das Testgerät in Richtung des Zugangsnetzwerks verließen, sollte der vollständige Empfang aller Pakete überprüft und im Fall eines Datenverlusts betroffene Dienste festgestellt werden.

 

Simulation komplexer Netzwerkumgebungen mit IxNetwork

Fiktion? Nein, denn in unserem XT3Lab betreiben wir eine 100G-fähige Testumgebung, die diese Anforderungen erfüllt. Ein Schlüsselelement unserer Testumgebung ist dabei die IxNetwork-Lösung unseres Technologiepartners IXIA. Zahlreiche Tests wurden mittels unserer Lösung bereits erfolgreich umgesetzt – ob im Labor oder vor Ort beim Kunden. Und auch neue Plattformen wie Arista Networks R-Serie haben unsere Testexperten so bereits auf Herz und Nieren geprüft.

Im Folgenden geben wir eine kurze Einführung und zeigen auf, wie mit IxNetwork eine Netzwerkumgebung mit Endkunden und einem Provider-Netz simuliert werden kann.

 

a) Simulation von Kunden

Zunächst simulieren wir die Kunden des CPE auf einem physischen Port. Hierzu generieren wir 100 VLANs, 100 IP-Adressen, 100 BGP-Sessions und 100 Netzwerkbereiche mit je zehn Präfixen. Die Grafik zeigt die Benutzeroberfläche von IxNetwork mit der entsprechenden visuellen CPE-Einstellung.

Sobald diese Einstellungen aktiviert sind, zeigt sich, dass IxNetwork 100 Kunden mit jeweils zehn Präfixen simuliert und somit insgesamt 1000 BGP-Präfixe generiert werden. Über die CLI-Ausgabe des eingesetzten MX480-Routers von Juniper Networks verifizieren wir nun, dass das DUT die Routing-Einträge anhand des eingehenden Interfaces in die richtige VRF setzt:

xuser@friedberg> show bgp summary 
...
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.100.1.2                1        163        301       0       1     1:20:01 Establ
  VRF-1.inet.0: 10/10/10/0
10.100.2.2                2        164        304       0       1     1:20:03 Establ
  VRF-2.inet.0: 10/10/10/0
...

 

b) Simulation des Provider-Netzes

Die Simulation des Provider-Core-Netzwerks stellt sich etwas komplizierter dar. Hier nutzen zwei physikalische Ports zur Simulation von zwei P-Routern, die über ISIS, LDP und BFD mit dem DUT kommunizieren. Hinter den P-Routern erzeugen wir 50 PE-Router mit 100 VRFs, die 100 Kunden auf der anderen Seite entsprechen. Jede VRF sendet 50.000 Präfixe, so dass unser DUT insgesamt 5 Millionen Präfixe aus dem Kernnetz lernen und für das Forwarding auf der Linecard einspeisen muss.

Starten wir dieses Szenario, können wir Stabilität und Speicherauslastung des Testgeräts überwachen und beobachten, ob es durch den Lernprozess aller Routen zu ungewünschten Nebeneffekten kommt.

xuser@friedberg> show route summary table bgp.l3vpn.0    
Autonomous system number: 64512
Router ID: 10.255.255.1

bgp.l3vpn.0: 5000000 destinations, 5000000 routes (5000000 active, 0 holddown, 0 hidden)
                 BGP: 5000000 routes, 5000000 active

Wie anhand der CLI-Ausgabe zu sehen, hat der Router alle Präfixe erfolgreich geladen; die Skalierung der Control-Plane scheint in Ordnung. Im nächsten Schritt erstellen wir nun einige Traffic-Elemente, mit denen wir den bidirektionalen Datenverkehr zwischen allen Präfixen testen und die Erreichbarkeit verifizieren.

Beim Paketverlust für einen der Dienste, können wir dem Fehler nachgehen, indem wir mit IxNetwork ein neues Traffic-Objekt für den spezifischen fehlerhaften Dienst erstellen und die Nachverfolgung der Ziel-IP-Adresse aktivieren. Der nachfolgende Screenshot zeigt die resultierende Präfix-Auswertung. Hier ist zu sehen, dass Traffic bis Präfix 20.0.151.18 einwandfrei weitergeleitet wird, es aber für 20.0.151.19 und größere Präfixe zu einem vollen Paketverlust kommt – eine Information, die hilft, die Ursache effizient zu identifizieren.


Testumgebung und Expertise für zuverlässige Testergebnisse

Aufgrund der Komplexität ist es nicht immer möglich, das komplette Netz eines Kunden zu simulieren und oft steht auch nur das zu testende Gerät selbst als Hardware zur Verfügung. Mit dem zuvor aufgezeigten Ansatz wird es jedoch möglich, große Teile der Netzwerk-Infrastruktur abzubilden und den Einsatz von Hardware so gering wie möglich zu halten.

Dieser Blog gibt Ihnen einen kleinen Einblick in die Möglichkeiten unserer Netzwerk-Testumgebung. Sollte Sie Interesse an dieser Art oder weiteren Testoptionen haben, besprechen wir gerne Ihre individuellen Details. Kontaktieren Sie uns hierzu einfach über das nachfolgende Kontaktformular.

 


FrauHerr

 

 

Hier finden Sie alle Informationen zum Datenschutz.