IPv6 – Know-how tut not!

Kommentieren Drucken

Moderne Netze funktionieren einfach! Switches, über Glasfasern und Twisted Pairs gekoppelt, mit oder ohne „Layer-3-Instanzen“, haben einen so hohen Grad der Verfügbarkeit erreicht, wie wir uns vor 10 Jahren noch nicht erträumt haben. Redundanzen sind eigentlich rausgeschmissenes Geld (o.k., dieses Thema wäre einen eigenen „Standpunkt“ wert). Sogar vergleichsweise neue Verfahren wie virtuelles Routing oder Network Access Control haben in der Praxis ihren Schrecken verloren. Somit ziehe ich meistens aus, um Fehler in Anwendungen zu finden: Überlastete Server, nicht funktionierende Path MTU Discovery oder auch Inkonsistenzen in der Namen-Auflösung sind typische Probleme in den Netzen meiner Kunden. Routing-Probleme, Spanning Tree Loops und Duplex Mismatch sind dagegen selten geworden. Heute ist Analyse-Know-how auf Layer 4 bis 7 gefragt.

So gesehen, ist IPv6 ein Rückschritt! Nichts funktioniert mehr, wie wir es gewohnt sind. Die letzten Monate mit praktischen IPv6-Testszenarien haben mich immer wieder an den Rand der Verzweiflung getrieben. Alleine das Implementieren eines einfachen DHCPv6-Servers oder der Test eines VRRPv3-Failover offenbaren ungeahnte Stolpersteine. Layer-3-Know-how gesucht!

Bedenken Sie, jeder Knoten hat mehrere IPv6-Adressen, von denen einige automatisch generiert werden („Autokonfiguration“). DHCP konkurriert nicht nur mit der Autokonfiguration, sondern ist sogar auf sie angewiesen. DHCPv6 ist beispielsweise nicht der Lage, dem Client die Adresse eines Default Gateway mitzuteilen. Dafür ist bei IPv6 der entsprechende Router verantwortlich. Und für die korrekte Funktion von VRRPv3 ist es entscheidend, dass der Client eine ganz bestimmte IPv6-Adresse als Default Gateway verwendet, nämlich diejenige, die von beiden Routern als „virtuelle“ Adresse anerkannt wird. Fehler an dieser Stelle machen sich leider erst unangenehm bemerkbar, wenn eine Komponente ausfällt (und das passiert ja nicht alle Tage, siehe oben).

Noch unübersichtlicher wird es, wenn man den durch Standards (hier: RFCs) mehr oder weniger exakt umrissenen Bereich verlässt und sich in die Freiheiten der Hersteller-Implementierungen wagt. Interessant ist zum Beispiel die Frage, wie ein Dual Stack Client, also ein Client, der sowohl IPv4 als auch IPv6 „spricht“, Namen zu IP-Adressen auflöst. Bekanntermaßen gibt es hier die „A Resource Records“ für IPv4 und „AAAA Resource Records“ für IPv6-Adressen. Ein IPv4-Namenserver (DNS) kann damit IPv6-Adressen zurückliefern und umgekehrt. Für ein Migrations-Szenario kann es aber entscheidend sein, in welcher Reihenfolge ein Client die verschiedenen Records am DNS anfragt. Und auch, ob zuerst der IPv4-DNS gefragt wird oder der über eine IPv6-Adresse erreichbare.

Beide Beispiele zeigen, dass die Implementierung von IPv6-fähigen Netzen ebenso viel Know-how verlangt wie die Migration einer Client-Server-Umgebung dorthin. Und für das Verständnis der Zusammenhänge ist die Protokollanalyse eine nicht zu unterschätzende, eigentlich sogar unverzichtbare Hilfe! Erst der Blick auf die Datenpakete offenbart die Zusammenhänge und gibt mir das für Planung und Betrieb einer IPv6-Umgebung benötigte Verständnis. So sehe ich, welche Wirkung ein verstellter Konfigurations-Parameter tatsächlich zeigt. Der Protokollanalysator ist derzeit mein wichtigstes Lernmittel.

 

zugeordnete Kategorien: Allgemein, Data Center, LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.