Montag 15 September 2014

IPv6 - Testen statt spekulieren

Am 3. Februar 2011 hat die IANA die letzten von ca. 4.3 Milliarden öffentlichen IPv4 Adressen offiziell vergeben. Das bedeutet nun nicht gerade das Ende der Welt, wie wir sie kannten, denn Carrier, Provider, Unternehmen oder Universitäten verfügen über weit mehr Adressen als aktuell in Gebrauch sind. Dennoch müssen sich Anwender rechtzeitig Gedanken über den Einsatz von IPv6 machen, wollen sie nicht in die Falle laufen. Dazu gehört etwa die Auswahl von Netzkomponenten, die das „neue“ Protokoll geeignet unterstützen. Fachgerechtes Testing vermeidet im Ernstfall Probleme.

IPv6 wurde – angesichts des weltweit rasant steigenden Bedarfs an IP-Adressen -  im Rahmen der RFC 2460 bereits im Jahre 1998 verabschiedet. Die Nachricht über die letzten vergebenen IPv4-Adressen hat die öffentliche Diskussion zwar wieder entflammt, aber auch gezeigt, dass die Implementierung nach wie vor zu wünschen übrig lässt. Die Resultate eines kürzlich veröffentlichten Infoblox-Reports bestätigen, dass von den 2.400 Befragten IT-Verantwortlichen lediglich die Hälfte weiß, welche installierten Netzwerkelemente bereits IPv6 unterstützen. Ob diese Unterstützung in der Praxis auch tauglich ist, darüber lässt sich ohne entsprechende Messungen nur spekulieren.

Eine IPv6 Adresse besteht im Gegensatz zu einer IPv4 Adresse aus 128 Bit und ermöglicht damit einen Adressraum von 2 hoch 128 Adressen (3.4 x 10 hoch 38). Damit wurde ein Ansatz gewählt, der aus heutiger Sicht eine schier unendliche Verfügbarkeit garantiert, auf der anderen Seite aber durchaus Ängste bei der Einführung schürt, weil die Auswirkungen auf das Performanceverhalten der Netzgeräte sowie die Kompatibilität einem unerforschten Kontinent gleichen.

Testen von IPv6

Der Einsatz von IPv6 ohne Testen gleicht einem Blindflug. „Schaun mer mal, dann sehn mer schon“ ist mit Sicherheit keine geeignete Einführungsstrategie. Ein reales Beispiel verdeutlicht dies eindrucksvoll:

Ein zehntausendfach im Einsatz befindlicher Router eines namhaften Herstellers ist für IPv4 im Einsatz. Laut Datenblatt unterstützt dieser Router auch IPv6. Was liegt näher, diesen Router auch für IPv6 einzusetzen? Eine Messreihe, durchgeführt mit nur zwei 100Mb-Interfaces, ergab folgende Ergebnisse:

Der Durchsatz mit IPv4 ohne Paketverluste lag bei max. 31 Mbps bei Laufzeiten zwischen  80µs – 120µs. Wenn mehr als 31 Mbps eingespeist wurden, sank der Durchsatz von IPv4 auf 12 Mbps, die Laufzeit stieg auf 43ms.Recovery setzte erst bei 28 Mbps ein.

Bei IPv6 betrug der Durchsatz ohne Paketverluste maximal 2 Mbps bei Laufzeiten um 550µs. Wenn mehr als 2 Mbps eingespeist wurden blieb der Durchsatz von IPv6 bei 2 Mbps und die Laufzeit stieg auf 30ms.Recovery begann bei 2 Mbps.

Im Mischbetrieb von IPv4 und IPv6 lag der Durchsatz ohne Paketverluste bei nur 10 Mbps IPv4 und 0.5 Mbps bei IPv6 bei Laufzeiten von 100 µs für IPv4 und 1.6ms für IPv6. IPv4 verdrängte IPv6 bis 30Mbps.

Je nach Alter und Implementierungsgrad werden sich Router hier ähnlich verhalten, da offenbar viele Hersteller mit der IPv6-Implementation in ihre Hardware gerade erst begonnen haben.

Aus diesem Beispiel wird ersichtlich, welche elementaren  Fragen sich aus dem Einsatz von IPv6 in der Praxis ergeben. Wird das System unter realen Bedingungen funktionieren? Wo sind die Grenzen des eingesetzten Systems? Und was passiert, wenn das System überlastet wird?

Die Vorteile geeigneter Messungen im Vorfeld liegen auf der Hand. Sie können eine effektive Kapazitätsplanung bezüglich der Hardwareermöglichen, aufwändiges und langwieriges Trouble-Shooting durch proaktive Konzepte ersetzen und Ausfallzeiten minimieren.

Aber nicht nur bei der Herstellerauswahl helfen funktionale und Performance-Tests Zeit und Geld zu sparen. Auch die Verifizierung von Proof-of-Concepts, Regression Testing, im Kunden-Support oder in der Produktion geben Messungen wertvolle Aufschlüsse über Erfolg oder zu erwartende Probleme.

IPv6 Test Cases

Der Einsatz von IPv6 in reinen L2 Ethernet-Netzen sollte kein Problem darstellen, da der MAC-Layer sich nicht verändert hat. Nur das TYPE Feld im Ethernet-Header ändert seinen Wert von 0x800 für IPv4 auf 0x86dd für IPv6. Solange die Netzwerkkomponenten diesen Wert ignorieren, sind reine L2 Ethernet-Netze zu 100 Prozent IPv6 kompatibel.

Völlig anders verhält es sich bei Netzwerkkomponenten, die basierend auf Schicht 3, also der IP Adresse, arbeiten. Hier ist das IPv6-Protokoll noch oft in der Software implementiert und muss deswegen bzgl. Seiner Funktionalität und Performance untersucht werden.

Die alten Bekannten sind hier Durchsatz, Paketverluste, Laufzeit, Laufzeitverteilung und Jitter. Hinzu kommen Messungen auf Basis von RFC2544 und RFC2889 unter Berücksichtigung von CoS und QoS.

Der Durchsatz (Throughput) ist per RFC2544 die maximale Last (in Mb pro Sekunde oder Paketen pro Sekunde), bei der keine Paketverluste auftreten. Moderne Messgeräte ermitteln diesen Wert automatisch, indem sie die Last solange erhöhen, bis Paketverluste auftreten. Sehr wichtig ist dabei, das Laufzeitverhalten (Latency) und den Jitter der Pakete parallel zu beobachten,  da oftmals bei steigender Last auch die Laufzeit zum Teil nicht unerheblich ansteigt.

Die zweite wichtige Testreihe untersucht das Überlastverhalten, also wenn mehr Pakete empfangen werden, als weitergeleitet werden können.  Netzwerkkomponenten bieten hier eine Vielzahl von Angeboten, um Class-of-Service, Quality-of-Service oder Service-Level-Agreements zu realisieren. Basierend auf Flags im Datenpaket (z.B. VLAN ID oder Prio, Tos/DiffServ, UDP oder TCP Ports), werden die Paket in „Warteschleifen (Queues)“ geparkt und entsprechend ihrer Priorität, weiterverarbeitet. Neben der Überprüfung der Queueing-Mechanismen als solche ist es von erheblicher Bedeutung, die Paket-Drop-Mechanismen zu verstehen. Werden die Pakete möglichst gleichmäßig verteilt verworfen, wirkt sich dies nachteilig auf alle TCP basierenden Übertragungen aus. Die Verwerfung in einem großen Burst ist gut für TCP basierende Übertragungen, aber sehr schlecht für Sprach- und TV-Übertragungen sowie Fehlererkennungs- und -korrekturmechanismen.

Auch hier ist es notwendig, die Laufzeiten und den Jitter der Pakete im Auge zu behalten. Eine Minimierung der Paketverluste auf Kosten der Laufzeit ist für viele Anwendungen nutzlos. Desweiteren bricht bei einigen Router-Modellen der Durchsatz zusammen, wenn es zu Paketverlusten kommt. D.h., dass der Durchsatz ohne Paketverluste beim Auftreten von Paketverlusten nicht mehr erreicht wird.

Routing

Eine Netzwerkkomponente muss nicht nur Pakete über die Backplane transportieren, sondern entscheiden, welches Paket zu welchem Port weitergeleitet werden soll. Dazu gibt es verschiedene Routingprotokolle für das interne Netzwerk (meistens OSPF oder ISIS und MPLS) und das externe Netzwerk (meistens BGP), die ihre jeweiligen IPv6-Erweiterungen tragen. Die Netzwerkkomponente muss also nicht nur kontinuierlich Pakete weiterleiten, sondern ständig die Routingprotokolle überwachen und die Routing-Tabellen auf den aktuellen Stand bringen. Dies hat Einfluss auf Parameter wie Durchsatz und Laufzeit. Weitere elementare Fragestellungen sind etwa:

Routing Advertising: Wie viele Adressen kann die Netzwerkkomponente lernen. Wie schnell werden die Routingtabellen erstellt, also wie lange dauert es, bis Datenpakete tatsächlich transportiert werden? Welchen Einfluss hat das Advertising auf Durchsatz und Laufzeit?

Route Flapping: Wie schnell werden Topologie-Änderungen in den Routingtabellen dargestellt? Welchen Einfluss hat das Flapping auf Durchsatz und Laufzeit?

Convergence Time: In vielen Netzen werden für den Fall eines Linkausfalls alternative Routen vorgehalten. Wie lange dauert es, bis die Datenpakete über diese alternative Route geleitet werden, wenn eine primäre Route ausfällt?

Tunneling-Mechanismen

In den wenigsten Fällen wird IPv6 als alleiniges Protokoll eingeführt. Meist wird IPv6 parallel zu IPv4 laufen oder IPv6-Inseln werden über IPv4 Netze miteinander verbunden gegebenenfalls auch IPv4-Inseln über IPv6-Netze. Dazu existieren zahlreiche Tunneling-Protokolle (DS Light, 6RD, etc.), die entweder darauf basieren, dass die Adresse am Eingang des Tunnels erstmals übersetzt und am Ausgang wieder in die Original-Adresse umgewandelt wird, oder das gesamte  Paket des einen Protokolls  in ein Paket des anderen Protokolls eingepackt wird. Diese Mechanismen gilt es z.B. durch einfache Ende-zu-Ende-Tests funktional und performant zu überprüfen.

Application-Layer-Testing und Security

Die Schichten oberhalb von IPv6, z.B. UDP oder TCP, haben sich nicht verändert. Wenn aber die dazugehörigen Server, Load-Balancer, Firewalls, IDS Systeme etc. IPv6 unterstützen sollen, muss natürlich deren IPv6-Funktionalität und -Performance überprüft werden. Das Eingangs beschriebene Beispiel hat unter anderem gezeigt, dass der IPv4-Traffic den IPv6-Traffic verdrängt. Das würde bei einem Server dazu führen, dass bei zunehmender Last alle auf IPv6 basierenden Applikationen zuerst gestört werden oder nicht mehr funktionieren, da deren Pakete zuerst verworfen werden. Zusätzlich hätten die deutlich höheren Laufzeiten von IPv6 direkten Einfluss auf die verfügbare TCP-basierende Applikationsbandbreite, da die Bestätigungen erst deutlich verspätet beim Client ankommen würden. Ein Beispiel verdeutlicht dies.

Bei einer Bandbreite von 1Gbps und einer Paketgröße von 1500 Byte wird ungefähr alle 12µs ein Paket versendet  (82239 Pakete pro Sekunde). Bei einer größtmöglichen TCP Window-Size von 64k muss der Sender nach 64k-Paketen auf eine Bestätigung warten. Die Bestätigung kommt bei diesem Beispiel nach 2x 550 µs (es müssen beide Richtungen eingerechnet werden), also 1100µs. Das bedeutet, dass der Sender in dieser Zeit 91 Pakete hätte senden können. Das entspricht bei einer Paketgröße von 1500 Byte ungefähr 1.2 Mbps (1500 Byte x 91 x 8 x 20%). Bei Überlast steigt die Laufzeit auf 30ms (30000µs). Das ergibt dann eine Wartezeit von 60000µs. In dieser Zeit hätten 5000 Pakete gesendet werden können. Das entspricht einer ungefähren Bandbreite von 72 Mbps, die nur durch die erhöhten Laufzeiten verloren gehen. Dabei ist noch nicht die zusätzlich benötigte Bandbreite für Re-Transmission durch Paketverluste eingerechnet. Ebenso wenig die Einflüsse von Slow-Start und Congestion-Control.

Beim Security-Testing muss analog zu IPv4 der Einfluss von Attacken, angefangen vom „einfachen“ distributed Denial-of-Service bis hin zu Viren, Würmern und Trojanern auf Firewalls, IDS und ähnliche Geräte überprüft werden. Je nach Netzdesign (IPv4 und IPv6 parallel) werden die Testmöglichkeiten sehr komplex. Von Interesse ist z.B. wie sich Attacken auf den Durchsatz und die Laufzeit des regulären Traffics auswirken und ob die Attacken Einfluss auf die Anzahl der parallelen Sessions und die Sessionaufbauraten haben.

Cloud Computing

Die Wolke – das Cloud-Computing - bleibt oftmals nebulös und undurchsichtig,  jedenfalls bisher aus Sicht von funktionalen und Performance-Tests. Moderne Mess-Systeme können aber seit mittlerweile in die Cloud hineinsehen( bzw. heraussehen). Es ist heute möglich, den Durchsatz bzw. die Paketverluste eines virtuellen Servers zu ermitteln oder virtuelle Firewalls innerhalb eines virtuellen Servers zu testen. Und das sowohl für IPv4 und IPv6. Die Testmethoden unterscheiden sich nicht von den vorher betrachteten. Die einzige Einschränkung besteht zur Zeit noch in der Genauigkeit der Laufzeitmessungen, da die Zeitstempel für die Laufzeitmessungen mit Hilfe des virtuellen Server selbst erstellt werden.

Netzwerk Simulation

Alle erläuterten Testmethoden verfolgen den Ansatz, die Eigenschaften einer einzelnen Netzwerkkomponente oder eines Netzwerkes zu untersuchen. In einigen Einsatzbereichen muss allerdings geklärt werden, welche Eigenschaften ein Netzwerk insgesamt haben muss, damit eine bestimmte Applikation zuverlässig funktioniert. Dazu werden sogenannte Impairment-Generatoren verwendet, die in der Lage sind, Paketverluste, Laufzeit, Jitter, etc. zu erzeugen. Je nach Genauigkeit und Leistung stehen derartige Impairment-Generatoren als Software oder als Hardware zur Verfügung.

Mittels dieser Generatoren kann getestet werden, wie viel Paketverluste, Laufzeit oder Jitter eine Applikation verträgt, damit sie noch zuverlässig arbeiten kann. Die ermittelten Werte können dann in das Netzdesign übernommen werden.

Alles in allem zeigt sich, dass die IPv6-Migration entgegen mancher Beteuerungen zwar kein Selbstläufer ist, die zu erwartenden Problemstellungen aber durchaus zu meistern sind, wenn sich der Anwender nicht auf „IPv6-Ready“-Labels verlässt, sondern die Verifikation der Leistungsfähigkeit der einzelnen Komponenten im Umfeld der Netzwerkumgebung unter realen Bedingungen testet. Die entsprechenden Werkzeuge hierzu stehen zur Verfügung.

Dieser Fachbeitrag ist im August 2011 in der Zeitschrift LANline erschienen: http://www.lanline.de/fachartikel/ipv6-tests-statt-spekulation.html

 

 

 

<- Zurück zu: Home

Powered by cobago systems