Dank der kurzfristigen Hilfe der Kollegen vom Community-IX sind nun FRA2 und FRA3 wieder komplett angebunden.
Das Problem war letzten Endes aufgetreten beim Versuch, die Verbindung über Tunnel durch eine direkte Nutzung eines VLANs abzulösen. In Frankfurt nutzen wir an 2 Standorten insgesamt 4 Hypervisoren, die eine gemeinsames logisches Netz bilden — so können VMs einfacher verschoben werden und der Verschnitt bei IPv4-Adressen ist geringer. Bedingt durch die Art und Weise, wie wir am Standort FRA3 angebunden sind (Transport der Community-IX-Anbindung durch ein anderes Netz) und ferner, wie dies beim Community-IX wiederum realisiert ist, rissen wir mit der direkten Nutzung des VLANs für die Zusammenführung der VM-Brücken leider wieder die Vorgabe für die Anzahl an physischen Adressen pro (Community-IX-) Port.
In Berlin nutzen wir vorsichtshalber (wie auch seinerzeit schon in DUS) ein VXLAN-Overlay, was uns zudem ermöglicht, mehrere »eigene VLANs« zu konfigurieren. Aber auch hier ist die FRA3-Anbindung leider ein Problem, denn dort sind wir auf die maximale Paketgröße (MTU) auf 1500 limitiert — an den C-IX-Switchen in BER & FRA2 können wir den VXLAN-Overhead per MTU 1600 »außen dranpappen« und habe so eine innere MTU von 1500.
Anway, wir verbinden die standortlokalen VM-Brücken nun per vorhandener Direktverbindung der Systeme und zwischen jeweils einem System in FRA2 und FRA3 wird per L2TP-Tunnel der Austausch zwischen den Standorten über das VLAN gemacht — in dem so nur 2 IP-Adressen »außen« auftauchen. Nach weiteren Tests bzgl. Spanning Tree-Einstellungen soll als Fallback auch von den beiden anderen Systemen ein Tunnel die Brücken verbinden. Da das dann aber einen Kreis bildet, muß das Spanning Tree Protokoll diesen im Normalfall auflösen — anderenfalls … wäre das ›ungut‹. Und da wir damit noch keine Erfahrung haben, kommt das auf die (längere) ToDo-Liste — in diesem Fall »to test« ;-)