[eos] VM bekommt keine IPv6-Adresse wenn Netzwerk mit /48-Präfix erstellt wurde

    Kann ich auch bestätigen, testweise ein fd03::0/56 sowie ein fddd::0/48 angelegt ... VM erhält in beiden Fällen nur die fd80-Link-Local-IPv6-Adresse.

    Ein fd04::0/64 hingegen funktioniert. Mir fällt jetzt kein UseCase ein, wo man nicht mit einem /64 auskäme, aber vielleicht gibts Leute die hier ein Subnetting für Container etc... gerne durchführen würden - also ganz abwegig ist die Idee was größeres als /64 zu nutzen vermutlich nicht.

    Zitat von gunnarh

    Subnetting

    Ich wollte eigentlich einfach nur sehen, ob man auch andere Präfixe als /24 bzw. /64 eingeben kann. :) Mit dem Thema Subnetting hatte ich mich noch gar nicht befasst…

    Subnetting scheint mir mit der aktuellen Implementierung nicht möglich zu sein, da die IP-Adresse vom System generiert wird. Man hat also keine Möglichkeit, eine VM einem bestimmten Subnetz zuzuordnen. Zwar kann man dem Interface weitere ULAs zuweisen und die VMs können sich darüber auch erreichen, aber wenn so eine ULA als Quelladresse für Traffic ins Internet verwendet wird, funktioniert das nicht, weil wohl nur die vom System generierte IP-Adresse „genatet“ wird. Abhilfe würde hier die Zuweisung der GUA direkt auf der VM schaffen, so wie es bei IPv6 sein sollte - ohne NAT. Das ULA-Präfix des Netzwerks wäre dann ggf. auch überflüssig.

    Bliebe evtl. noch die Möglichkeit ein weiteres Netzwerk zu erstellen, aber dann bekomme ich wieder eine kostenpflichtige IPv4-Adresse, die ich nicht benötige und auch nicht möchte.

    [Suche] RS Piccolo gesucht

    Einmal editiert, zuletzt von terence (19. August 2026 um 11:27)

    Zitat von gunnarh

    Mir fällt jetzt kein UseCase ein, wo man nicht mit einem /64 auskäme, aber vielleicht gibts Leute die hier ein Subnetting für Container etc... gerne durchführen würden - also ganz abwegig ist die Idee was größeres als /64 zu nutzen vermutlich nicht.

    Das hätte aber weitere Implikationen hinsichtlich zB. des Routings. Irgendwie müsste der SDN Stack dann ja wissen welcher Next-Hop für ein gewisses Subnet zuständig ist.
    Das ist eine gewisse Komplexität die wir nach Möglichkeit nicht in der Platform haben wollen.

    Da Netzwerke immer einzelnen Blöcken zugeordnet sind: gibt es aus eurer Sicht einen Use-Case in dem ein IPv6 `/64` nicht ausreichend ist innerhalb eines logischen Netzwerks?

    Mir scheint das eine "herkömmliche" Sichtweise auf Virtualisierung zu sein, bei der man die VMs nicht als Funktionen sondern als Geräte betrachtet und darauf dann mehrere Sachen laufen lässt, wie z.B. Containeransammlungen (Pods) mit getrennten Netzen. Eine Cloud ist ja eher so gedacht, dass man die VMs schmal hält und die Orchestrierung inkl. Netzwerksegmentierung in der Cloud macht.

    Ich missbrauche eine Cloud auch gerne als VM-Provider und lasse den ganzen Rest der Managementfunktionen links liegen, aber im Prinzip sind langlebige VMs mit komplizierten "internen" Setups in einer Cloud ein Fremdkörper.

    Soweit das Wort zum Sonntag. Zurück zur Technik...

    Da die EOS Cloud aktuell kein Container-Hosting unterstützt wird man sich seine Container wohl (zumindest vorläufig) auf eigenen VMs hosten (müssen).

    Und ich denke es gibt Szenarien, die man - selbst wenn man es mit Containern löst - lieber selber hostet, als das auf eine fremd-gemanagte K3S zu deployen.

    Was den Einwand von [netcup eos] Stephan P. betrifft, dass der SDN Stack dann den Next-Hop für das Routing kennen müsste betrifft: Da kann ich jetzt nicht ganz folgen.

    Was macht es in Bezug auf die Routing Thematik für einen Unterschied, ob ich ein /56 oder ein /64 habe?
    Das SDN muss in beiden Fällen den Next-Hop kennen, ob sich dahinter dann ein /56 oder ein /64 verbirgt macht ja keinen Unterschied?

    Wenn ich als Kunde ein z.b. /56 hätte und mir das auf meiner VM dann selbst weiter in Subnetze aufteile, dann liegt diese "Routing Tabelle" welches Netz dann in welchem (Docker-/LXC)-Container genutzt wird und wie diese Subnetze untereinander kommunizieren ja vollständig in meiner Hand, auf meiner VM. Das SDN der EOS-Cloud kennt freilich nur das komplette /56 oder /64 und meine VM muss dafür Sorge tragen, dass IPv4 ARP-Requests bzw. IPv6 Neighbor Discoveries für meine Container innerhalb der virtuellen Layer2 Broadcast Domain auflösbar sind.

    Hi gunnarh ,

    Bei einer echten Aufteilung in Subnets - also es wird ein /56 zugewiesen und daraus kann man selbst /64 Netze schneiden - ist es notwendig dass der Upstream Router, also unserem SDN, bekannt ist wie das jeweilige /64 erreicht werden kann. Dafür würden wir entweder ein Transport-Netz benötigen um dort die Verbindung zwischen den Routern herzustellen, oder - falls die VMs sich ein L2 Segment teilen - müsste das SDN auf ND-Ebene wissen, welche VM für welches delegierte Prefix zuständig ist. In beiden Fällen würde das bedeuten, dass die Router-Seite im SDN wissen müsste welcher Router (bzw. welche VM) für welches /64 zuständig ist, um den Traffic entsprechend zustellen zu können.

    Soweit ich das jetzt richtig verstanden habe geht der beschriebene Use-Case aber in Richtung einer Unterteilung eines Netzwerks in logische Netzbereiche innerhalb eines einzelnen L2 Segments. In der Variante wäre das ein flaches Netz wie von dir oben beschrieben ohne geroutete Subnets.

    Also ausgehend von fd42:1234:5678::/64 wäre dann zB. fd42:1234:5678:0100::/80 einer VM zugewiesen und fd42:1234:5678:0200::/80 einer anderen. Ein /80 bietet dabei immer noch rund 281 Billionen Adressen (2^48), also mehr als genug Raum pro VM für beliebige Container-Aufteilungen. Diese VMs würden dann für "ihre" Netzbereiche ND Proxying betreiben und sich selbst um das interne Routing kümmern. Das ist dann aber kein echtes Subnetting im Sinne separater, gerouteter Netze, sondern eine Zuteilung einzelner Adressbereiche innerhalb eines gemeinsamen L2 Segments. Diese Variante kann bereits jetzt genau so genutzt werden. Zusätzliche ULA Adressen die man selbst vergibt funktionieren sowohl zwischen VMs im selben Netzwerk als auch in Richtung Internet.

    Solange wir kein Szenario mit echtem, geroutetem Subnetting über mehrere L2 Segmente hinweg vor uns haben, sehe ich ehrlich gesagt keinen konkreten Use-Case, für den ein /64 nicht ausreichend groß wäre. Deshalb ist ein entsprechendes geroutetes Subnetting aktuell auch nicht vorgesehen, da es genau die oben beschriebene Komplexität auf SDN-Seite (Next-Hop pro Subnetz) sowie zusätzliche Konfiguration auf Kundenseite mit sich bringen würde.