Messtechnik für IPv6
IPv6-Tests statt Spekulation
Am 3. Februar 2011 hat die IANA die letzten von circa 4.3 Milliarden öffentlichen IPv4-Adressen offiziell vergeben. Dies 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 eine 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 2128 Adressen (3,4 × 1038). Dies stellt einen Ansatz dar, 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 zu 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 in Betrieb. 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 100-MBit-Interfaces, ergab folgende Ergebnisse: Der Durchsatz mit IPv4 ohne Paketverluste lag bei maximal 31 MBit/s bei Laufzeiten zwischen 80 µs bis 120 µs. Wenn mehr als 31 MBit/s eingespeist waren, sank der Durchsatz von IPv4 auf 12 MBit/s, die Laufzeit stieg auf 43 ms. Recovery setzte erst bei 28 MBit/s ein.
Bei IPv6 betrug der Durchsatz ohne Paketverluste maximal 2 MBit/s bei Laufzeiten um 550 µs. Wenn mehr als 2 MBit/s eingespeist wurden, blieb der Durchsatz von IPv6 bei 2 MBit/s und die Laufzeit stieg auf 30 ms. Recovery begann bei 2 MBit/s. Im Mischbetrieb von IPv4 und IPv6 lag der Durchsatz ohne Paketverluste bei nur 10 MBit/s bei IPv4 und 0,5 MBit/s bei IPv6 bei Laufzeiten von 100 µs für IPv4 und 1,6 ms für IPv6. IPv4 verdrängte IPv6 bis 30 MBit/s. 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.
Dieses Beispiel macht ersichtlich, welch elementare 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 Hardware ermö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 dabei, 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.
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. Dort ist das IPv6-Protokoll noch oft in der Software implementiert und muss deswegen bezüglich 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 MBit 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 oft bei steigender Last auch die Laufzeit zum Teil nicht unerheblich ansteigt.
Die zweite wichtige Testreihe untersucht das Überlastverhalten, also wenn das System mehr Pakete empfängt, als es weiterleiten kann. Netzwerkkomponenten bieten dabei eine Vielzahl von Optionen, um Class-of-Service, Quality-of-Service oder Service-Level-Agreements zu realisieren. Basierend auf Flags im Datenpaket (zum Beispiel VLAN ID oder Prio, Tos/DiffServ, UDP oder TCP Ports) sind die Paket in Warteschleifen (Queues) geparkt und werden entsprechend ihrer Priorität, weiterverarbeitet. Neben der Überprüfung der Queueing-Mechanismen 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 an dieser Stelle 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. Des Weiteren bricht bei einigen Router-Modellen der Durchsatz zusammen, wenn es zu Paketverlusten kommt. Dies bedeutet, dass sich der Durchsatz ohne Paketverluste beim Auftreten von Paketverlusten nicht mehr erreichen lässt.
Routing
Eine Netzwerkkomponente muss nicht nur Pakete über die Backplane transportieren, sondern auch entscheiden, welches Paket zu welchem Port weiterzuleiten ist. Dazu gibt es verschiedene Routing-Protokolle für das interne Netzwerk (meist OSPF oder ISIS und MPLS) und das externe Netzwerk (meist BGP), die ihre jeweiligen IPv6-Erweiterungen tragen. Die Netzwerkkomponente muss also nicht nur kontinuierlich Pakete weiterleiten, sondern ständig die Routing-Protokolle überwachen und die Routing-Tabellen auf den aktuellen Stand bringen. Dies hat Einfluss auf Parameter wie Durchsatz und Laufzeit.
Weitere elementare Fragestellungen sind beispielsweise:
Routing Advertising: Wie viele Adressen kann die Netzwerkkomponente lernen. Wie schnell werden die Routing-Tabellen erstellt, also wie lange dauert es, bis der Transport der Datenpakete tatsächlich erfolgt? Welchen Einfluss hat das Advertising auf Durchsatz und Laufzeit?
Route Flapping: Wie schnell stellen die Systeme Topologieänderungen in den Routing-Tabellen dar? Welchen Einfluss hat das Flapping auf Durchsatz und Laufzeit?
Convergence Time: Vielen Netze halten für den Fall eines Link-Ausfalls alternative Routen vor. Wie lange dauert es, bis die Datenpakete über diese alternative Route laufen, wenn eine primäre Route ausfällt?
Tunneling-Mechanismen
In den wenigsten Fällen führen die Verantwortlichen IPv6 als alleiniges Protokoll ein. Meist wird IPv6 parallel zu IPv4 laufen, oder IPv6-Inseln sind ü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 ist. Diese Mechanismen gilt es zum Beispiel durch einfache Ende-zu-Ende-Tests funktional und auf ihre Leistung hin zu überprüfen. Die Schichten oberhalb von IPv6, also zum Beispiel UDP oder TCP, haben sich nicht verändert. Wenn jedoch die dazugehörigen Server, Load-Balancer, Firewalls, IDS-Systeme etc. IPv6 unterstützen sollen, muss natürlich deren IPv6-Funktionalität und -Leistung überprüft werden. Das eingangs beschriebene Beispiel hat unter anderem gezeigt, dass der IPv4-Traffic den IPv6-Traffic verdrängt. Dies würde bei einem Server dazu führen, dass bei zunehmender Last alle auf IPv6 basierenden Applikationen zuerst gestört sind 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 weiteres Beispiel verdeutlicht diesen Effekt: Bei einer Bandbreite von 1 GBit/s und einer Paketgröße von 1.500 Byte wird ungefähr alle 12 µs ein Paket versendet (82.239 Pakete pro Sekunde). Bei einer größtmöglichen TCP-Window-Größe von 64k muss der Sender nach 64k-Paketen auf eine Bestätigung warten. Die Bestätigung kommt bei diesem Beispiel nach 2 × 550 µs (beide Richtungen sind einzurechnen), also 1100 µs. Dies bedeutet, dass der Sender in dieser Zeit 91 Pakete hätte senden können. Das entspricht bei einer Paketgröße von 1.500 Byte ungefähr 1,2 MBit/s (1.500 Byte × 91 × 8 × 20 %). Bei Überlast steigt die Laufzeit auf 30ms (30.000 µs). Dies wiederum ergibt dann eine Wartezeit von 60.000 µs. In dieser Zeit hätten sich 5.000 Pakete senden lassen. Das entspricht einer ungefähren Bandbreite von 72 MBit/s, 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 ist es nötig, 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 zu überprüfen. Abhängig vom Netzdesign (IPv4 und IPv6 parallel) gestalten sich die Testmöglichkeiten sehr komplex. Von Interesse ist zum Beispiel, 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 Session-Aufbauraten haben.
Die Wolke - das Cloud Computing - bleibt oftmals nebulös und undurchsichtig, jedenfalls bisher aus Sicht von funktionalen und Performance-Tests. Moderne Messsysteme können aber seit mittlerweile in die Cloud hineinsehen (oder heraussehen). Es ist heute möglich, den Durchsatz und die Paketverluste eines virtuellen Servers zu ermitteln oder virtuelle Firewalls innerhalb eines virtuellen Servers zu testen, und dies sowohl für IPv4 und IPv6. Die Testmethoden unterscheiden sich nicht von den vorher betrachteten. Die einzige Einschränkung besteht zurzeit noch in der Genauigkeit der Laufzeitmessungen, da die Zeitstempel für die Laufzeitmessungen mithilfe des virtuellen Servers selbst entstehen.
Alle erläuterten Testmethoden verfolgen den Ansatz, die Eigenschaften einer einzelnen Netzwerkkomponente oder eines Netzwerkes zu untersuchen. In einigen Einsatzbereichen ist allerdings zu klären, welche Eigenschaften ein Netzwerk insgesamt haben muss, damit eine bestimmte Applikation zuverlässig funktioniert. Dazu nutzt man so genannte Impairment-Generatoren, 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. Mit diesen Generatoren lässt sich testen, 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 eingehen.
Fazit
Die IPv6-Migration ist entgegen mancher Beteuerungen zwar kein Selbstläufer, die zu erwartenden Problemstellungen sind jedoch durchaus zu meistern, 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 dazu stehen zur Verfügung.
Lesen Sie mehr zum Thema
