Neutron ist der Netzwerkdienst, mit dem jedes OpenStack-Projekt eigene isolierte, softwaredefinierte Netze aufbaut, ohne einen physischen Switch anzufassen. In einer modernen Cloud setzt er meist auf OVN auf, das die Data Plane programmiert, sodass Mandanten private Subnetze, Router und öffentliche Anbindung vollständig über die API erhalten. Diese Schicht zu verstehen verwandelt eine einzelne startbare Instanz in eine sauber angebundene Anwendung.

Dieses Tutorial baut das Mandanten-Netzwerk von Grund auf: ein privates Netz und Subnetz, einen Router, der es mit dem Provider-Netz verbindet, und Floating IPs, die Instanzen nach außen erreichbar machen. Es ist der praktische Begleiter zum Starten der ersten Instanz und baut auf Linux-Grundlagen wie dem Bridge-Networking auf, das unter der SDN-Schicht liegt.

Voraussetzungen

• Eine laufende OpenStack-2025.2-Cloud mit openstack-Client und projektbezogenen Zugangsdaten.
• Ein vorhandenes externes (Provider-)Netz, das der Cloud-Admin angelegt hat. Listen Sie es auf, um den Namen zu erhalten.
• Die Rolle member auf Ihrem Projekt, um Netze und Router zu erstellen.

source ~/acme-openrc
openstack network list --external

Das Neutron-Objektmodell

Vier Objekte erledigen die Arbeit. Ein Netz ist eine Layer-2-Broadcast-Domain. Ein Subnetz ist ein IP-Bereich mit Gateway und DNS, an ein Netz gebunden. Ein Router verbindet Subnetze untereinander und mit dem externen Netz und führt SNAT für ausgehenden Verkehr aus. Eine Floating IP ist eine öffentliche Adresse aus dem externen Netz, die Sie (per DNAT) auf den privaten Port einer Instanz abbilden.

Schritt 1: Mandanten-Netz und Subnetz erstellen

Erstellen Sie ein privates Netz für Ihr Projekt und schneiden Sie daraus ein Subnetz mit DHCP-Bereich, Gateway und DNS-Resolver. Die CIDR wählen Sie frei, denn sie ist von jedem anderen Mandanten isoliert.

openstack network create acme-net
openstack subnet create acme-subnet 

--network acme-net 

--subnet-range 10.0.0.0/24 

--gateway 10.0.0.1 

--dns-nameserver 1.1.1.1 

--allocation-pool start=10.0.0.10,end=10.0.0.200

Schritt 2: Einen Router erstellen

Ein Router gibt dem Subnetz einen Weg nach draußen. Erstellen Sie ihn, setzen Sie das externe Netz als Gateway und hängen Sie das Mandanten-Subnetz als internes Interface an:

openstack router create acme-router
openstack router set acme-router --external-gateway ext-net
openstack router add subnet acme-router acme-subnet

Mit Gateway und internem Interface können Instanzen in acme-subnet das Internet bereits ausgehend per Source-NAT erreichen. Eingehender Zugriff erfordert weiterhin eine Floating IP.

Schritt 3: Routing prüfen

Prüfen Sie den Router, um zu bestätigen, dass er sowohl ein externes Gateway als auch einen internen Port auf Ihrem Subnetz hat:

openstack router show acme-router -c external_gateway_info -c name
openstack port list --router acme-router

Schritt 4: Floating IP zuweisen und verknüpfen

Um eine Instanz von außen erreichbar zu machen, weisen Sie eine Floating IP aus dem externen Netz zu und binden sie an die Instanz. Die Instanz muss bereits in acme-net sein:

openstack floating ip create ext-net

notieren Sie die zurückgegebene Adresse, z. B. 203.0.113.50
openstack server add floating ip web-01 203.0.113.50
openstack server show web-01 -c addresses

Neutron installiert eine DNAT-Regel auf dem Router, sodass Verkehr an 203.0.113.50 an die private Adresse der Instanz weitergeleitet wird. Zusammen mit einer SSH-Security-Group-Regel erreichen Sie die VM nun.

Schritt 5: Konnektivität Ende zu Ende testen

Pingen Sie von einem Host im externen Netz die Floating IP an und verbinden Sie sich per SSH. Prüfen Sie in der Instanz, dass auch das ausgehende Routing funktioniert:

ping -c3 203.0.113.50
ssh -i ~/.ssh/mykey.pem ubuntu@203.0.113.50

in der VM:
ip route
ping -c3 1.1.1.1

Häufige Fehler und Fehlersuche

Externes Netz hat kein Subnetz oder keine freien IPs

Schlägt floating ip create fehl, ist das Provider-Netz evtl. erschöpft oder hat kein Subnetz. Ein Admin prüft mit openstack subnet show am externen Netz und erweitert den Allocation-Pool.

Instanz kann nach außen pingen, ist aber nicht erreichbar

Ausgehend funktioniert SNAT auch ohne Floating IP – das deutet also auf eine fehlende Floating-IP-Verknüpfung oder eine Security-Group hin, die eingehendes ICMP/SSH blockiert. Prüfen Sie mit openstack floating ip list und ergänzen Sie die Regeln aus dem Security-Groups-Leitfaden.

No route to host / Router ohne Gateway

Schlägt das Ausgehende komplett fehl, hat der Router vermutlich kein externes Gateway oder kein Subnetz-Interface. Führen Sie openstack router set --external-gateway und openstack router add subnet erneut aus und bestätigen Sie mit openstack router show.

MTU- und Fragmentierungsprobleme

Overlay-Netze (VXLAN/Geneve) erzeugen Encapsulation-Overhead. Hängen große Pakete, während kleine funktionieren, senken Sie die Instanz-MTU oder stellen Sie sicher, dass die MTU des Netzes korrekt gesetzt ist – ein klassischer SDN-Stolperstein aus den darunterliegenden Tunneln.

Aufräumen

openstack server remove floating ip web-01 203.0.113.50
openstack floating ip delete 203.0.113.50
openstack router remove subnet acme-router acme-subnet
openstack router delete acme-router
openstack network delete acme-net

Fazit

Sie haben ein vollständiges Mandanten-Netzwerk gebaut: ein privates Subnetz, einen Router nach draußen und Floating IPs, die Instanzen bei Bedarf erreichbar machen – alles softwaredefiniert und von jedem anderen Projekt isoliert. Dieses Self-Service-Networking entspricht dem Modell der Public Clouds, läuft aber auf Infrastruktur, die Sie kontrollieren. Kombinieren Sie es mit Security Groups, um den Zugriff zu sperren, und mit Ihrer ersten Instanz für einen kompletten Workload.

Ausfallsicheres, mandantenfähiges SDN im großen Maßstab zu entwerfen – mit redundanten Routern, vernünftigen MTUs und vorhersehbarer Performance – betreibt clouditiv für Sie auf einer gemanagten On-Premise-Cloud, damit Ihre Teams Self-Service-Networking erhalten, ohne die SDN-Komplexität selbst zu tragen.