Open vSwitch - Hilfe gesucht bei der Config

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Benutzeravatar
Madtrick
Beiträge: 4
Registriert: 20.11.2018 12:22:41
Lizenz eigener Beiträge: MIT Lizenz

Open vSwitch - Hilfe gesucht bei der Config

Beitrag von Madtrick » 20.04.2020 03:08:54

Hallo zusammen,
ich hoffe ihr könnt mir weiter helfen.
Dies ist mein erster Versuch mit Open vSwitch. Ich habe mir die Wiki reingezogen und mich an die Config gemacht. Da ich in der Materie VLAN, Trunk, Bind etc. neu bin, fehlt mir einfach die Sicherheit, dass das was ich lese und versuche umzusetzten dann auch korrekt ist.

Daher bitte ich euch meine bisherige Konfiguration einmal anzusehen und mir vielleicht mit Rat und/oder Hinweisen zu Seite zu stehen.

Hier einmal die Interfaces:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
  address 10.10.10.5/24
  gateway 10.10.10.1

allow-vmbr0 eno2
iface eno2 inet manual
  ovs_type OVSPort
  ovs_bridge vmbr0

#allow-vmbr1 enp4s0f0
iface enp4s0f0 inet manual
  mtu 1500

#allow-vmbr1 enp4s0f1
iface enp4s0f1 inet manual
  mtu 1500

allow-vmbr1 bond0
iface bond0 inet manual
  ovs_bonds enp4s0f0 enp4s0f1
  ovs_type OVSBond
  ovs_bridge vmbr1
  ovs_options lacp=active bond_mode=balance-tcp
#  other_config:lacp-time=fast
#  ovs_mtu 9000

allow-ovs vmbr0
iface vmbr0 inet manual
  ovs_type OVSBridge
  ovs_ports eno2

allow-ovs vmbr1
iface vmbr1 inet manual
  ovs_type OVSBridge
  ovs_ports bond0 vlan11 vlan12 vlan60 vlan61 vlan70 vlan71
  ovs_mtu 9000
Die auskommentierten Zeilen habe ich mit aus dem Wiki. Aber ich bin mir halt nicht sicher und weiß nicht ob das so sein muss.
  • Das erste Interface hängt separat untagged als Endgerät im VLAN1. Administrativer Zugang zum Server. Statische IP ohne Bridge.
  • Das zweite Interface soll mit Bridge für VMs zur Verfügung stehen. Ebenfalls komplett separiert. Das VLAN10 kommt tagged auf diesem Interface rein. So kann ich den VMs das Tag mitgeben.
  • Die beiden anderen Interfaces sollen einen Bond bilden, auf dem dann 6 VLANs rein kommen. Auch da kann ich beim erstellen der VMs dann das passende VLAN-Tag mitgeben.
Alles hängt an einem L3-Switch, der die VLANs verwaltet und per ACLs die Zugriffe regelt.

Viele Grüße, Dirk

Benutzeravatar
noobadix
Beiträge: 53
Registriert: 03.02.2009 03:23:22

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von noobadix » 21.04.2020 01:21:11

Hi!
Bin selbst noch am Lernen, erzähle dir aber mal was mich stutzig macht:

1. Managementzugriff mache ich normalerweise über ein eigenes VLAN
2. Von 802.3ad hast du bislang nichts direkt gesagt, stellst aber bei "iface bond0" eine LACP-Option ein. Hat das 'nen Grund?
3.Funktioniert das sicherlich die MTU auf Jumboframe zu setzen? Gerade bei LACP muss die Gegenseite ja auch so eingestellt werden.

Insgesamt finde ich es schwer zu begreifen, was denn letztlich bei rauskommen soll, aber das kann auch an mir liegen. Könntest du vielleicht trotzdem klarer sagen, was genau du erreichen möchtest? Ein Netzplan wäre vielleicht hilfreich.

Lieben Gruß
Know your tools, train your basics.

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von unitra » 21.04.2020 05:29:17

Ohne Netzplan, mit Verkabelung, mit Schnittellen un den dazugehörigen VLANs und IP Adresierung ist das kaum verständlich was, wie und wo konfiguriert ist.

Benutzeravatar
Madtrick
Beiträge: 4
Registriert: 20.11.2018 12:22:41
Lizenz eigener Beiträge: MIT Lizenz

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von Madtrick » 21.04.2020 21:22:05

Hallo zusammen,
klasse, dass ihr euch gemeldet habt.

Ja das stimmt. Ohne Plan ist es nicht ganz so gut.
Den Plan habe ich eben grob aktualisiert, dass er jetzt so ungefähr stimmt. Aber vom Prinzip ist er richtig.
Und sicherlich ist er nicht ganz "regelkonform". Hoffe es reicht aber zum Verständnis.

Hier einmal der Plan vom PVE-Server mit den VMs und deren VLANs, etc...:
Bild
https://www.dropbox.com/s/kjryw15fcx76n ... s.png?dl=0

Ich hoffe man wird einigermaßen draus schlau.

Ich habe letzte Woche mehrere Testläufe mit verschiedenen Möglichkeiten probiert. Lesen, lernen und ein wenig try and error.
Diese Konstellation hat schon mal augenscheinlich funktioniert. Auch genau mit der schon geposteten Konfig.
Der Bond0 endetet in der Bridge1. Beim Erstellen einer VM konnte ich direkt das VLAN und eine IP mitgeben. Das klappte soweit. Aber ob das alles so richtig ist? Da fehlt mir die Erfahrung etc...
Die eno1 soll ausschließlich für die Administration des PVE sein. Also https und SSH Zugang. Nicht mehr. Statische IP und ist als Endgerät im nativen VLAN1. Der Switchport für die eno1 ist ungetagged.
Die eno2 soll auch isoliert genutzt werden. Doch halt mit Bridge, damit ich später weitere VMs dran hängen kann. Der Switchport für die eno2 war glaube ich tagged. Bin mir gerade aber nicht sicher.
Jedenfalls konnte ich auch dort der VM beim Erstellen die IP und das VLAN mitgeben.

Bevor ich aber nun endgültig das System ausbaue, wäre es klasse, wenn ich die Unsicherheiten noch soweit aus dem Weg räumen kann.
Nach diesen Beispielen habe ich diese Konfiguration zusammen geschustert. Naja, ich fand es schwer, aus den Einzelbeispielen eine zusammenhängende Konfig zu erstellen.
So recht ist auch noch nicht der Groschen durchgängig gefallen. Aber vlt begreife ich es ja dann doch noch mal.

Der Switch kann laut diesem Manual mit Jumbo Frames umgehen:
https://wiki.mikrotik.com/wiki/Manual:C ... s_switches
Dort steht :
  • Model: CRS326-24S+2Q+
  • Switch Chip: Marvell-98DX8332
  • CPU Cores: 650MHz
  • Wireless: -
  • SFP+ port: +
  • ACL rules: 170
  • Unicast FDB entries: 32,000
  • Jumbo Frame (Bytes): 10218
Also um die Fragen noch einmal klar zu beantworten.

1. Managementzugriff soll über das VLAN1 über die eno1 zum Server selber.
2. Nachdem was ich gelesen habe gibt es wohl 6 Bondingmodes. Mode 4 wäre zu bevorzugen, wenn das möglich ist. So komme ich zu LACP und Mode4.
3. Der Dokumentation des Switches nach, werden Jumboframes unterstützt.

Bitte berichtigt mich, wenn ich etwas nicht korrekt ist oder ich auf dem falschen Weg bin.

Viele Grüße

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von unitra » 22.04.2020 12:20:18

Also erst einmal eines vorab, die Netzskizze ist gut, da könnten sich Einige andere professionelle die mit Netzwerken tag täglich arbeiten, Einiges davon abgucken.

Jetzt zu den Fragen. Die Vorschläge sind kosmetische Verbesserungen und ändern grundsätzlich nichts an der Funktion des Netzwerkes, kann man ändern, muß man nicht unbedingt wenn alles funktioniert. Man sollte aber darüber schon die eine oder andere Minute nachdenken.

1. WENN es der Mikrotik Router erlaubt, und nur 1 Host auf der Schnittelle ether4 verbunden ist, dann konfigurere routed Interface, ohne VLAN und ohne Interface VLAN. und eventuel ein kleineres Netz /30 oder /29, richtet sich an der Anzahl der verbundenen Hosts. Ich gehe hier nur von 2 Nodes aus, eine IP für das Router-Interface Router und eine IP für den verbundenen Host. Kleineres IP Netz, sind direkt miteinander verbunden, Point-to-Point Netzwerk.

Code: Alles auswählen

/ip address add address=10.10.10.1/30 interface=ether4
Für den Host 10.10.10.2/30.

Zu 2. https://www.kernel.org/doc/Documentatio ... onding.txt Mode 4 IEEE 802.3ad ist cross-vendor unterstützt. LACP ist der richtige weg. LACP-PDU Probing lass lieber auf slow, also alle 30 Sekunden, wenn Du richtig gute Gründe hast, stelle es auf Fast, also LACP-PDU jede Sekunde schicken.

Zu 3. Wenn man Jumbo Frames konfiguriert dann sollte man die Jumbo Frames überall gleich konfigureren. D.h. bei jedem Host, am virtual Switch, am Mikrotik Router. Oder belasse alles bei MTU 1500. Das ist einfacher wenn irgendetwas nicht geht, es einfacher im Troubleshootingfall. Dieses MTU 9000 nur auf ein paar Interfaces, wie Salz streuen ist "bad design", sollte man nicht machen, wird oft vergessen, führt manchmal zu komischen Fehlern im Netzwerk, und man kommt nicht mehr so schnell drauf, und oft sind dann schon etliche Studen wenn icht Tage vergangen. Also entweder alles auf MTU 9000 umstellen oder gar nichts. Natürlich nicht am ether1 Interface wo PPP läuft in Richtung des WANs oder des Internets.

Ansonsten Hut ab, das sieht gut aus.
Madtrick hat geschrieben: ↑ zum Beitrag ↑
21.04.2020 21:22:05
Hallo zusammen,
...
1. Managementzugriff soll über das VLAN1 über die eno1 zum Server selber.
2. Nachdem was ich gelesen habe gibt es wohl 6 Bondingmodes. Mode 4 wäre zu bevorzugen, wenn das möglich ist. So komme ich zu LACP und Mode4.
3. Der Dokumentation des Switches nach, werden Jumboframes unterstützt.

Bitte berichtigt mich, wenn ich etwas nicht korrekt ist oder ich auf dem falschen Weg bin.

Benutzeravatar
Madtrick
Beiträge: 4
Registriert: 20.11.2018 12:22:41
Lizenz eigener Beiträge: MIT Lizenz

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von Madtrick » 22.04.2020 13:31:05

Danke für die Blumen. :-)
Ich bemühe mich und versuche zu lernen.
Das gilt halt auch hier bei uns für unser Netzwerk. Es ist ein bisher ziemlich zusammen gebasteltes und gewachsenes Netzwerk. Damit ist jetzt Schluss und ich versuche Strukturen zu schaffen.
Also es ist kein Büronetz mit Hochverfügbarkeit oder so.
Durch unsere Tätigkeit im ehrenamtlichen Bereich, kommt dann schon Strukturen vor, wie in einem Büro.
So teile ich diese Bereiche hier nun nach unseren Tätigkeiten ein wenig auf, damit nicht jeder wie vorher quasi überall hin kann.
Das noch mal ein wenig zum Hintergrund.
Die Vorschläge sind kosmetische Verbesserungen und ändern grundsätzlich nichts an der Funktion des Netzwerkes, kann man ändern, muß man nicht unbedingt wenn alles funktioniert. Man sollte aber darüber schon die eine oder andere Minute nachdenken.
Also entnehme ich, dass das Config-File soweit okay ist.?
Diese Konstellation hat sich aus meiner laienhaften Sicht so ergeben.
Was könnte man ggfs. noch ändern, bzw. wo könnte man noch drüber nachdenken?
Mein Horizont ist da noch zu begrenzt.
WENN es der Mikrotik Router erlaubt, und nur 1 Host auf der Schnittelle ether4 verbunden ist, dann konfigurere routed Interface, ohne VLAN und ohne Interface VLAN. und eventuel ein kleineres Netz /30 oder /29, richtet sich an der Anzahl der verbundenen Hosts. Ich gehe hier nur von 2 Nodes aus, eine IP für das Router-Interface Router und eine IP für den verbundenen Host. Kleineres IP Netz, sind direkt miteinander verbunden, Point-to-Point Netzwerk.
Im VLAN1, also mein Adminnetz sind noch weitere Host. Ich habe einen alten HP Laptop zum reinen Administrations Rechner gemacht, der nur bei Bedarf in das VLAN1 gehängt wird. Das VLAN1 ist komplett vom Rest abgekapselt. Daher auch der andere Private IP-Bereich.
Das mit der ether4 hat sich etwas geändert. Der MT Switch hängt nun ebenfalls "nur" als "AdminHost" an einem kleinen 4 Port Switch. Dieser kleine Switch ist dann quasi mein autarkes Adminnetz (VLAN1), welches quasi nur im Administrationsfall angeschaltet wird. Den IP-Bereich halte ich so klein es geht.
Denke, abgeschaltet ist es quasi am sichersten. ;-)
Mode 4 IEEE 802.3ad ist cross-vendor unterstützt. LACP ist der richtige weg. LACP-PDU Probing lass lieber auf slow, also alle 30 Sekunden, wenn Du richtig gute Gründe hast, stelle es auf Fast, also LACP-PDU jede Sekunde schicken.
hmmm... du meinst diese auskommentierte Zeile?

Code: Alles auswählen

#  other_config:lacp-time=fast

Also wenn ich das auskommentiert lasse, müsste es slow sein. Richtig?
hihi. Da ich noch nicht weiß, was das für eine Option ist, habe ich weder Gründe dafür, noch dagegen. :-)

Zu 3:
Ahhh, wieder etwas gelernt. Das heißt, wenn MTU auf 9000, dann im kompletten Netzwerk und bis zu jedem Host. Sonst wäre es nicht sinnvoll. Richtig?
Ich belasse es dann bei der MTU 1500. Sollte ich das bei jedem Interface in der Konfig dazu schreiben?

Punkt 4 neu:
Sollte ich sonst noch irgendetwas in der Konfig berücksichtigen oder wären ggfs noch weitere Optionen in der Konfig sinnvoll?

Punkt 5 neu:
Was mir gerade noch auffällt ist, dass einmal in der Konfig der Parameter "MTU" heißt und einmal OVS_MTU". Welcher wäre der korrekte?
Was ja noch sein müsste ist, dass die ganze Konfig auf OVS aufbaut. Also es darf kein Mischbetrieb sein. Z. B. eine Bridge von Linux und eine von OVS.
Und was ist mit den auskommentierten Parametern:

Code: Alles auswählen

#allow-vmbr1 enp4s0f0

und

Code: Alles auswählen

#allow-vmbr1 enp4s0f1
Können die raus oder müssten die rein?
Wie gesagt. Die kommen aus dem Versuch, aus den Wiki Beispielen die passenden Komponenten zu übernehmen.
Dort waren sie mit dabei, aber soweit ich es noch weiß, klappte es damit nicht richtig.
Bleibt halt die Frage, ob sie wie in der Wiki mit rein müssten, weil es richtig wäre oder ob sie raus bleiben können...

Hier dann noch einmal die Konfig überarbeitet:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
  address 10.10.10.5/24
  gateway 10.10.10.1


allow-vmbr0 eno2
iface eno2 inet manual
  ovs_type OVSPort
  ovs_bridge vmbr0

allow-ovs vmbr0
iface vmbr0 inet manual
  ovs_type OVSBridge
  ovs_ports eno2


#allow-vmbr1 enp4s0f0
iface enp4s0f0 inet manual
  mtu 1500

#allow-vmbr1 enp4s0f1
iface enp4s0f1 inet manual
  mtu 1500

allow-vmbr1 bond0
iface bond0 inet manual
  ovs_bonds enp4s0f0 enp4s0f1
  ovs_type OVSBond
  ovs_bridge vmbr1
  ovs_options lacp=active bond_mode=balance-tcp
  other_config:lacp-time=slow
  ovs_mtu 1500

allow-ovs vmbr1
iface vmbr1 inet manual
  ovs_type OVSBridge
  ovs_ports bond0 vlan11 vlan12 vlan60 vlan61 vlan70 vlan71
  ovs_mtu 1500
Ganz herzlichen Dank und viele Grüße

Benutzeravatar
unitra
Beiträge: 638
Registriert: 15.06.2002 21:09:38
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: 127.128.129.130

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von unitra » 22.04.2020 19:03:53

3) Keine MTU setzen, die Defaulteinstellung belassen. Ich bin mir nicht sicher wie der vSwitch die Layer2 MTU berechnen, also den Ethernetrahmen. Der Ethernetrahmen ist 1518 Byte groß, 14 Byte Header, bis zu 1500 Byte Payload (Daten), 4 Byte CRC. Schlimstenfalls verringerst Du den Rahmen, bzw. die Payload (Daten) auf effektiv 1500 byte - 18 byte = 1482 Byte. Jede Implementierung ob Software oder Hardware ist ein Wening anders. Keine MTU konfigurieren.

4) Nein.

5) Vermutlich sind die beiden auskommentierten Konfigurationszeilen vSwitch spezifisch. Es sind 2 physiche Schnittstellen (enp4s0f0) und (enps4s0f1), die im (bond0) enthalten sind. Die Bride1 referiert dann auf das bond0 Interface. Zumindest wenn man die spezielle Konfiguration betrachtet.
Pseudocode: bridge1 -> bond0 -> eth0 & eth1

Code: Alles auswählen

allow-vmbr1 bond0
iface bond0 inet manual
  ovs_bonds enp4s0f0 enp4s0f1
  ovs_type OVSBond
  ovs_bridge vmbr1
  ovs_options lacp=active bond_mode=balance-tcp
  other_config:lacp-time=slow
  ovs_mtu 1500
Ich würde die Zeilen zunächst entfernen, dann entweder den vSwitch neustarten, oder abwechselnd erst der der Schnittelle (enp4s0f0) den Link abschalten (ggfls Kabel ziehen), dann einstecken, dann der anderen, mit genügend Zeit dazwischen, auto-negotiate brauch bis zu 30 Sekunden um die Bandbreite mit der Gegenseite auszuhandeln. Und immer dazwischen schauen ob alles so funktioniert wie erwartet.

Generell gilt der Grundsatz, weniger ist oft mehr. Die die an allen Nerdknöpfen drehen entweder wissen Sie ganz genau was sie damit anstellen, oder sie haben oft Glück zum jetztigen Zeitpunkt und die Katastrophe kommt dann erst sehr viel später. Spätestens beim nächsten Stromausfall.
Madtrick hat geschrieben: ↑ zum Beitrag ↑
22.04.2020 13:31:05
...
Zu 3:
Ahhh, wieder etwas gelernt. Das heißt, wenn MTU auf 9000, dann im kompletten Netzwerk und bis zu jedem Host. Sonst wäre es nicht sinnvoll. Richtig?
Ich belasse es dann bei der MTU 1500. Sollte ich das bei jedem Interface in der Konfig dazu schreiben?

Punkt 4 neu:
Sollte ich sonst noch irgendetwas in der Konfig berücksichtigen oder wären ggfs noch weitere Optionen in der Konfig sinnvoll?

Punkt 5 neu:
Was mir gerade noch auffällt ist, dass einmal in der Konfig der Parameter "MTU" heißt und einmal OVS_MTU". Welcher wäre der korrekte?
Was ja noch sein müsste ist, dass die ganze Konfig auf OVS aufbaut. Also es darf kein Mischbetrieb sein. Z. B. eine Bridge von Linux und eine von OVS.
Und was ist mit den auskommentierten Parametern:

Code: Alles auswählen

#allow-vmbr1 enp4s0f0

und

Code: Alles auswählen

#allow-vmbr1 enp4s0f1

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
  address 10.10.10.5/24
  gateway 10.10.10.1


allow-vmbr0 eno2
iface eno2 inet manual
  ovs_type OVSPort
  ovs_bridge vmbr0

allow-ovs vmbr0
iface vmbr0 inet manual
  ovs_type OVSBridge
  ovs_ports eno2


#allow-vmbr1 enp4s0f0
iface enp4s0f0 inet manual
  mtu 1500

#allow-vmbr1 enp4s0f1
iface enp4s0f1 inet manual
  mtu 1500

allow-vmbr1 bond0
iface bond0 inet manual
  ovs_bonds enp4s0f0 enp4s0f1
  ovs_type OVSBond
  ovs_bridge vmbr1
  ovs_options lacp=active bond_mode=balance-tcp
  other_config:lacp-time=slow
  ovs_mtu 1500

allow-ovs vmbr1
iface vmbr1 inet manual
  ovs_type OVSBridge
  ovs_ports bond0 vlan11 vlan12 vlan60 vlan61 vlan70 vlan71
  ovs_mtu 1500
Ganz herzlichen Dank und viele Grüße

Benutzeravatar
Madtrick
Beiträge: 4
Registriert: 20.11.2018 12:22:41
Lizenz eigener Beiträge: MIT Lizenz

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von Madtrick » 22.04.2020 20:04:59

Prima.
Dann ist soweit erst einmal alles klar.

Jetzt kommt das große ABER...

... ich sitze gerade an der Maschine und habe sie neu installiert, damit alles möglichst sauber ist.
hmmm... was soll ich sagen...
Ich bekomme gerade so gar nichts wiederholt hin, wie ich es mir Schritt für Schritt dokumentiert habe.

Rechner installiert. Standardmäßig legt er auf der ersten eth eine Standard Linux Brücke an, welche er mit der IP konfiguriert, welche ich bei der Install vergebe.
Nach 4 Minuten ist die Install durch und ich lasse erst mal Updates durch laufen.
Dann reboot und an die Netzwerk Konfig...

Weil ja openVswitch keinen Mischbetrieb mit Standard Linux Brücken etc. musste sie eh weg und habe der eno1 eine statischen IP gegeben.
Also nichts wirklich berauschendes.
Und das Entfernen und Anlegen der statischen IP für die eno1 mache ich absichtlich über die GUI.
Erstens gab es da nie ein Problem.
Und zweitens werden die Einstellungen vor dem Schreiben in die interfaces noch auf Plausibilität überprüft.
Keine Fehlermeldungen etc.

Genau das klappt heute nicht mehr. Also nicht mal einmal das geht:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
  address 10.10.10.5/24
  gateway 10.10.10.1
Schon sehr seltsam. Oder sehe ich jetzt den Wald vor lauter Bäumen nicht?

Nach dem Reboot komme ich nicht über die IP dran.
Über IPMI kann ich mich dann einloggen.
Ein

Code: Alles auswählen

ip -d address
liefert jedenfalls gar keine IPs zurück.

Jemand noch eine Idee?

Benutzeravatar
noobadix
Beiträge: 53
Registriert: 03.02.2009 03:23:22

Re: Open vSwitch - Hilfe gesucht bei der Config

Beitrag von noobadix » 23.04.2020 00:26:30

Wenn du die GUI benutzt, konfigurierst du den NetworkManager. Dieser dienst arbeitet NEBEN ifupdown, welches über die /etc/network/interfaces konfiguriert wird. Ich habe es seit kurzem so gehalten, dass, wenn ich mit ifupdown arbeite, ich gar keine GUI installiere um den NetworkManager als Fehlerquelle auszuschließen.
Proxmox arbeitet zwar mit einer /etc/network/interfaces, aber mit einer flüchtigen: https://pve.proxmox.com/wiki/Network_Configuration
Also: Wenn man Einstellungen über die GUI/den NetworkManager vornimmt, sollte man die Hände von der /etc/network/interfaces lassen.
Das hast du aber auch, oder?
Hast du nach dem Einstellen der IP den PC rebootet? Falls nicht, versuch das mal.

Ansonsten bin ich nicht sicher, ob die CIDR-Notation in der Interfaces erlaubt ist. Obwohl: Wenn der NetworkManager das so reinschreibt? Habe ich aber zumindest noch nie gemacht.
https://www.debian.org/doc/manuals/debi ... _static_ip
Ich hätte folgendes erwartet:

Code: Alles auswählen

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
  address 10.10.10.5
  netmask 255.255.255.0
  gateway 10.10.10.1
Know your tools, train your basics.

Antworten