Keine IP nach Umzug auf neuen host (Proxmox)

ersin · 23. April 2021 um 14:54

Hallo Jörg,

Danke für den Hinweis. Klar, da gehört static hin, hatte ich eingangs auch so stehen. Weiß der Kuckuck, wie das manual dahin gekommen ist (vermutlich copy&paste).

Hier die korrigierte Fassung

auto lo
iface lo inet loopback
iface eno1 inet manual
iface enp1s0f0 inet manual
iface enp1s0f1 inet manual
iface enp1s0f2 inet manual
iface enp1s0f3 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.0.0.34 # green IP of vm host 
    netmask 255.255.0.0
    gateway 10.0.0.254 # green IP firewall (OPNSense)
    bridge-ports enp1s0f0
    bridge-stp off
    bridge-fd 0

auto vmbr1
iface vmbr1 inet manual
    bridge-ports enp1s0f1
    bridge-stp off
    bridge-fd 0

Aaber, jetzt wirds so richtig zum Mäusemelken: die Korrektur hat nix gebracht!

Nach Neustart alles wie gehabt: keine IP

Hier der output von ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether b4:96:91:74:92:14 brd ff:ff:ff:ff:ff:ff
3: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
    link/ether b4:96:91:74:92:15 brd ff:ff:ff:ff:ff:ff
4: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 2c:f0:5d:c7:f4:8c brd ff:ff:ff:ff:ff:ff
5: enp1s0f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b4:96:91:74:92:16 brd ff:ff:ff:ff:ff:ff
6: enp1s0f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b4:96:91:74:92:17 brd ff:ff:ff:ff:ff:ff
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b4:96:91:74:92:14 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b696:91ff:fe74:9214/64 scope link 
       valid_lft forever preferred_lft forever
8: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b4:96:91:74:92:15 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b696:91ff:fe74:9215/64 scope link 
       valid_lft forever preferred_lft forever
9: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i0 state UNKNOWN group default qlen 1000
    link/ether ba:b8:09:49:eb:7e brd ff:ff:ff:ff:ff:ff
10: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fa:41:c2:5d:b3:93 brd ff:ff:ff:ff:ff:ff
11: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether a6:48:39:7d:d3:3a brd ff:ff:ff:ff:ff:ff
12: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
    link/ether fa:41:c2:5d:b3:93 brd ff:ff:ff:ff:ff:ff
13: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i1 state UNKNOWN group default qlen 1000
    link/ether a2:82:af:d7:cf:a1 brd ff:ff:ff:ff:ff:ff
14: fwbr100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:29:5c:39:11:59 brd ff:ff:ff:ff:ff:ff
15: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP group default qlen 1000
    link/ether 76:53:1c:16:f2:be brd ff:ff:ff:ff:ff:ff
16: fwln100i1@fwpr100p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i1 state UP group default qlen 1000
    link/ether 52:29:5c:39:11:59 brd ff:ff:ff:ff:ff:ff
17: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr101i0 state UNKNOWN group default qlen 1000
    link/ether ba:2e:aa:06:b3:3c brd ff:ff:ff:ff:ff:ff
18: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 06:6f:4c:18:a6:45 brd ff:ff:ff:ff:ff:ff
19: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 5e:1c:08:94:f7:a8 brd ff:ff:ff:ff:ff:ff
20: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
    link/ether 06:6f:4c:18:a6:45 brd ff:ff:ff:ff:ff:ff

Werde das WE drüber grübeln und dann ggf. erneut qm restore vom Backup der VM durchführen.

BG, ersin

ersin · 23. April 2021 um 14:59

Hallo Thorsten,
Guckst Du hier!
Aah Danke. Genau danach hatte ich gesucht.
Lässt sich auch prima mit Details ausblenden kombinieren (s.o).

Schönes WE, ersin

Michael · 23. April 2021 um 15:13

Ich habe das mal mit meinem Eintrag verglichen … hier gibt es einen Eintrag mehr:

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.111
        netmask 255.255.255.0
        gateway 192.168.1.1
        bridge_ports eno3
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0   <<<< das steht bei Dir nicht!
#default bridge (dell-Server)

Davon abgesehen steht bei mir ganz oben in der Datei /etc/network/interfaces:

allow-hotplug eno3       <<<<< das steht bei Dir auch nicht!
iface eno3 inet manual

Wie hast du denn diese "Dropdown-Menus " hinbekommen? Ok

MachtDochNix · 23. April 2021 um 15:20

Hallo Ersin,

danke dafür und ein Herz von mir.

Ich habe es im Link ergänzt. Mal schauen ob sich das etabliert.

Beste Grüße

Thorsten

MachtDochNix · 23. April 2021 um 15:21

Folge dem Link von mir.

ersin · 23. April 2021 um 16:47

Hallo Michael,

eigentlich wollte ich nach Hause gehe, bin aber (doch noch) deinem Hinweis nachgegangen: die zusätzlichen Einträge allow-hotplug und bridge_maxwait haben nix gebracht.

Neugierig geworden, hab ich mal im Netz gesucht und bei Debian gefunden:

bridge_maxwait time
forces to time seconds the maximum time that the Debian bridge setup scripts will wait for the bridge ports to get to the forwarding status, doesn’t allow factional part. If it is equal to 0 then no waiting is done.

Demnach wird also normalerweise (ab-)gewartet, bis der bridge-port in den forwarding status gelangt, das ist ja normalerweise auch erwünscht.

Es sei denn, man will und braucht nicht zu warten, dann kann man das Warten mit dem Wert 0 unterbinden. Ob das in der Paxis ein paar Sekunden bringt, sei mal dahingestellt.

Jedenfalls, dmesg zufolge braucht der bridge-port (hier enp1s0f0) aber schon ein wenig Zeit, um diesen Zustand zu erreichen, daher habe ich mal probeweise bridge_maxwait 3 gesetzt, hat aber auch nix gebracht.

Für heute lass ichs mal gut sein.
Danke für die Rückmeldungen und schönes WE euch allen.
ersin

ersin · 23. April 2021 um 17:31

One more thing,

das Problem hat mir keine Ruhe gelassen, hab mal den neuen host (hv01) runtergefahren, abgeklemmt und wieder den alten host (pve) hochgefahren, nur um dessen Einstellugen zum Vergleich anzugucken (dort sind auch keine Einträge allow-hotplug und bridge-maxwait). Siehe da (wie erwartet) läuft alles. Alles, wie es sein soll.

root@pve:~# cat /etc/network/interfaces

auto lo
iface lo inet loopback

iface enp1s0 inet manual
iface enp2s0 inet manual

auto vmbr0
iface vmbr0 inet static
address 10.0.0.20/16
gateway 10.0.0.254
bridge-ports enp1s0
bridge-stp off
bridge-fd 0
#intern/green

auto vmbr1
iface vmbr1 inet manual
bridge-ports enp2s0
bridge-stp off
bridge-fd 0
#extern/red

root@pve:~# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
    link/ether 78:ac:c0:3d:75:05 brd ff:ff:ff:ff:ff:ff
3: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether 78:ac:c0:3d:75:04 brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 78:ac:c0:3d:75:04 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.20/16 brd 10.0.255.255 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::7aac:c0ff:fe3d:7504/64 scope link
       valid_lft forever preferred_lft forever
5: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 78:ac:c0:3d:75:05 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::7aac:c0ff:fe3d:7505/64 scope link
       valid_lft forever preferred_lft forever
6: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i0 state UNKNOWN group default qlen 1000
    link/ether b2:d3:9b:cd:af:30 brd ff:ff:ff:ff:ff:ff
7: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 72:43:f7:50:78:67 brd ff:ff:ff:ff:ff:ff
8: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether f6:e5:cc:45:22:c9 brd ff:ff:ff:ff:ff:ff
9: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
    link/ether 72:43:f7:50:78:67 brd ff:ff:ff:ff:ff:ff
10: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i1 state UNKNOWN group default qlen 1000
    link/ether 72:64:bb:d6:46:95 brd ff:ff:ff:ff:ff:ff
11: fwbr100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1a:4f:4b:5a:90:d3 brd ff:ff:ff:ff:ff:ff
12: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP group default qlen 1000
    link/ether 42:14:44:b4:3d:b4 brd ff:ff:ff:ff:ff:ff
13: fwln100i1@fwpr100p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i1 state UP group default qlen 1000
    link/ether 1a:4f:4b:5a:90:d3 brd ff:ff:ff:ff:ff:ff
14: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr101i0 state UNKNOWN group default qlen 1000
    link/ether 52:5e:19:41:c9:25 brd ff:ff:ff:ff:ff:ff
15: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ea:9a:3f:76:e4:fe brd ff:ff:ff:ff:ff:ff
16: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether ae:6b:25:6a:ba:0d brd ff:ff:ff:ff:ff:ff
17: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
    link/ether ea:9a:3f:76:e4:fe brd ff:ff:ff:ff:ff:ff

Die bridge vmbr0 hat wie vorgesehen die IP 10.0.0.20 erhalten.
Ich sehe in den Einstellungen keine relevanten Unterschiede zur neuem Host (abgesehen davon, dass er die IP ~.34 erhalten soll an Stelle ~.20).

Jetzt stöpsel ich wieder um und gehe rätselnd nach Hause…

jrichter · 24. April 2021 um 01:25

Hallo Ersin,

kannst Du denn manuell eine ip konfigurieren? Z. B. so:

ip addr add 10.0.0.34/16 dev vmbr0

Wenn ja, dann mach das doch mal. Dann kannst Du die Weboberfläche aufrufen und dort mal die Netzkonfiguration checken.

Außerdem wäre noch der Output von „brctl show“ interessant.

Beste Grüße

Jörg

ersin · 24. April 2021 um 12:03

Hallo Jörg,

gute Idee, zu versuchen, der bridge eine weitere IP hinzuzufügen.
Werde ich gleich bei nächster Gelegenheit (am Mo) probieren.

Meine Überlegungen vor dem Umzug:
(das schreibe ich hier auf, weil mir dabei Vieles klarer wird und zum Nachlesen für später)

Im neuen Host stecken ja i.d.R andere NICs als im alten, d.h. deren Namen sind womöglich andere (je nachdem, ob onboard, PCI-slot u.a. Kriterien). Im vorliegenden Fall:

Host	NIC#1	#2	Kommentar
alt	enp1s0	enp2s0	1x-onboard + 1xNIC
neu	eno1	enp1s0f0 - enp1s0f3	1x-onboard + 4xNIC

Daher müssen im neuen Host die Zuordnungen der bridges den neuen Namen angepasst werden, weshalb in /etc/network/interfaces im altem & neuen Host (nach Vergewisserung, u.a. durch Raus- und Reinstecken der Kabel) die bridges wie folgt zugeordnet sind:

Host	bridge	NIC	IP	Kommentar
alt	vmbr0	enp1s0	10.0.0.20	grünes Netz
alt	vmbr1	enp2s0	DHCP	rotes Netz
neu	vmbr0	enp1s0f0	ohne IP	grünes Netz (sollte 10.0.0.34 sein)
neu	vmbr1	enp1s0f1	DHCP	rotes Netz

Trotzdem bleibt die „grüne” bridge ohne IP.

Daher denke ich, dass der Fehler irgendwo „ganz woanders“ liegt und bin gespannt auf deine Idee…

VG, ersin

Michael · 24. April 2021 um 12:35

Moment mal … wird die Schreibweise mit der /16 so auch akzeptiert?
Ich habe die Netzmaske in einer Extra-Zeile:

address 192.168.1.10
netmask 255.255.255.0
...

Bist du sicher, dass beides geht?
Was ist denn, wenn du die Schnittstelle zum Testen mal auf DHCP stellst und schaust, ob sie dann eine Adresse bekommt?
Ist die MAC überhaupt in der devices.csv eingetragen? Das müsste sie imho sein, damit der Rechner ins Internet darf…

Mehr fällt mir gerade nicht ein.
Viele Grüße,
Michael

alois · 24. April 2021 um 12:44

Hallo Michael,

das ist aber nicht /16, sondern /24

Gruß

Alois

ersin · 24. April 2021 um 13:04

Hallo Michael,

Bist du sicher, dass beides geht?

Bei Debian wird zwar oft explizit netmask angegeben, aber so ab Debian 8 (und Ubuntu sowieso) geht wohl beides. Hier weitere Beispiele.

VG, ersin

Cgsman · 25. April 2021 um 09:28

Hallo, Ihr beiden,

ja, beides geht.

Gruß Christoph

Michael · 25. April 2021 um 10:16

Ja, wir haben Subnetze und VLANs. Da sind /24er Netze richtig…
Aber in diesem Fall gehen mir nun auch die Ideen aus

Cgsman · 25. April 2021 um 11:47

Hallo,
also ich hab mir das oben genannte Schema nochmal angesehen: Das Besondere ist, dass durch die gateway-Anweisung, die nicht, wie sonst häufig, auf die externe Router-IP zeigt, sondern intern auf den OpnSense, es jetzt wirklich davon abhängig ist, ob der OpnSense die Anfragen auf die proxmox-Gui auch „durchlassen“ muss…hm…wahrscheinlich ist dann - ich habe mir die OpnSense-Konfigurationen nicht angesehen - dort eine Regel nicht aktiviert, die es braucht, um auf die Proxmox-Gui zu kommen.
„Verbiegen“ darf man das aber jetzt nicht mehr, weil sich sonst die vms nicht gegenseitig finden etc.
Tatsächlich kann man den Proxmox an ein zusätzliches reales Netzinterface binden, aber die Frage ist, wie man das Teil fernwarten möchte. (Meine Proxmox-Gui hängt in einem roten Netz).
Ansonsten empfiehlt es sich evtl. wirklich, die Opnsense-Konfiguration zu überprüfen !
L.G.
Christoph

Michael · 26. April 2021 um 05:55

Hallo Christoph – das verstehe ich nicht; bzw sehe ich es genau umgekehrt : Wenn du bei der OPNSense aus dem LAN kommst, kannst du in der Regel auch auf das OPNSense-WebUI (und auf das eigene Proxmox-WebUI dann sowieso!) zugreifen, während es bei Zugriff aus dem WAN per default aus gutem Grund verhindert wird.
Hier geht es ja --so wie ich es bisher verstanden habe-- gar nicht um einen Proxmox-Zugriff von außen sondern um das Problem, dass der Proxmox-Hypervisor aus irgendeinem Grund keine IP-Adresse auf vmbr0 hat??!

Vielleicht hilft es ja noch, sich den Status mit
brctl show anzusehen.

Ansonsten hier nochmal die offizielle Doku – auch dort wird die Netzmaske explizit angegeben. Vielleicht will Proxmox ja doch diese Syntax??
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_network_configuration

Ansonsten noch: Warum gibst du dem neuen Server nicht auch die .20 als IP-Adresse? Wenn es damit geht, weißt du, dass die OPNSense etwas blockiert…

Viele Grüße,
Michael

jrichter · 26. April 2021 um 06:45

Hallo,

solange der Proxmox keine IP hat, ist es völlig egal, ob die OPNSense irgendwas blockt. Das erste Problem ist die IP für vmbr0, alles andere kommt später.

Zum Debuggen gibt es nun schon mehrere Vorschläge:

die andere Syntax ausprobieren
eine IP-Adresse manuell vergeben - vielleicht gibt es ja irgendein Problem mit der Karte, was man so ausschließen könnte
die Einstellungen im Webinterface kontrollieren, vielleicht findet sich ja dort was

Wenn der Host für die vmbr0 eine IP hat, dann kann man weitere Tests anstellen (kommt man ins Internet, auf die OPNSense, …).

Beste Grüße

Jörg

Cgsman · 26. April 2021 um 08:25

stimmt, Jörg - das hab ich bei dem ganzen Hin und Her übersehen !

ersin · 26. April 2021 um 15:36

Hallo Jörg,

deine Idee, der bridge händisch eine weitere IP (in diesem Fall überhaupt erst eine) hinzuzufügen, hat mich ein gutes Stück weitergebracht:

Der einzige Zugang war bislang die Konsole direkt am Rechner. Nun gehts auch wieder via ssh und vor allem erreiche ich das WebIF und kann Einstellungen überprüfen.

Hier ein paar outputs, vllt. sieht ja jemand was Auffälliges oder Ungewöhnliches.

root@hv01:~# brctl show (der Lesbarkeit halber tabelliert)

bridge name	bridge id	STP enabled	interfaces
fwbr100i0	8000.5aaeedd25be0	no	fwln100i0
-	-	-	tap100i0
fwbr100i1	8000.427dc3436f23	no	fwln100i1
-	-	-	tap100i1
fwbr101i0	8000.7e6b83e950ac	no	fwln101i0
-	-	-	tap101i0
vmbr0	8000.b49691749214	no	enp1s0f0
-	-	-	fwpr100p0
-	-	-	fwpr101p0
vmbr1	8000.b49691749215	no	enp1s0f1
-	-	-	fwpr100p1

root@hv01:~# ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether b4:96:91:74:92:14 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 2c:f0:5d:c7:f4:8c brd ff:ff:ff:ff:ff:ff
4: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
link/ether b4:96:91:74:92:15 brd ff:ff:ff:ff:ff:ff
5: enp1s0f2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether b4:96:91:74:92:16 brd ff:ff:ff:ff:ff:ff
6: enp1s0f3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether b4:96:91:74:92:17 brd ff:ff:ff:ff:ff:ff
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b4:96:91:74:92:14 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.34/16 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::b696:91ff:fe74:9214/64 scope link
valid_lft forever preferred_lft forever
8: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether b4:96:91:74:92:15 brd ff:ff:ff:ff:ff:ff
inet6 fe80::b696:91ff:fe74:9215/64 scope link
valid_lft forever preferred_lft forever
9: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i0 state UNKNOWN group default qlen 1000
link/ether 2e:af:78:f6:90:3f brd ff:ff:ff:ff:ff:ff
10: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 5a:ae:ed:d2:5b:e0 brd ff:ff:ff:ff:ff:ff
11: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether 6e:e6:04:9c:02:79 brd ff:ff:ff:ff:ff:ff
12: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
link/ether 5a:ae:ed:d2:5b:e0 brd ff:ff:ff:ff:ff:ff
13: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i1 state UNKNOWN group default qlen 1000
link/ether e6:76:9f:a2:98:9c brd ff:ff:ff:ff:ff:ff
14: fwbr100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 42:7d:c3:43:6f:23 brd ff:ff:ff:ff:ff:ff
15: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP group default qlen 1000
link/ether f6:7d:b8:28:17:5e brd ff:ff:ff:ff:ff:ff
16: fwln100i1@fwpr100p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i1 state UP group default qlen 1000
link/ether 42:7d:c3:43:6f:23 brd ff:ff:ff:ff:ff:ff
17: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr101i0 state UNKNOWN group default qlen 1000
link/ether 6e:6d:fa:d1:40:9b brd ff:ff:ff:ff:ff:ff
18: fwbr101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 7e:6b:83:e9:50:ac brd ff:ff:ff:ff:ff:ff
19: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether fe:a4:b8:92:97:c6 brd ff:ff:ff:ff:ff:ff
20: fwln101i0@fwpr101p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr101i0 state UP group default qlen 1000
link/ether 7e:6b:83:e9:50:ac brd ff:ff:ff:ff:ff:ff
root@hv01:~#

root@hv01:~# ip a | grep vmbr

2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
4: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 10.0.0.34/16 scope global vmbr0
8: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
11: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
15: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP group default qlen 1000
19: fwpr101p0@fwln101i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
root@hv01:~#

Und hier ein screenshot von Node hv01-Network:

So weit so gut.

Das ursprüngliche Problem jedoch bleibt:

Die Zuweisung der IP innerhalb /etc/network/interfaces scheitert nach wie vor (aus mir immer noch unbekannten Gründen).

Aufgefallen ist mir die Spalte Autostart (No), weshalb ich probeweise Einträge wie auto enp1s0f0 oder allow-hotplug enp1s0f0 (entspricht Autostart unter ProxMox-WebIF) versucht habe: ohne Erfolg (wobei im alten server pve alles auch ohne diese Parameter funktioniert)

Mit der Hilfslösung „händisch IP zuweisen“ könnte man zur Not übergangsweise leben, aber da ist immer noch Problem #2:

Der host hat zwar eine Verbindung zur Firewall, kommt aber nicht raus ins Internet (alle anderen clients hingegen sehr wohl, wie etwa das admin-notebook, auf dem ich diesen Beitrag gerade schreibe) Und Ja, er ist korrekt (mit IP ~.34) in Firewall/Aliase eingetragen.

root@hv01:~# ping -c2 10.0.0.254
PING 10.0.0.254 (10.0.0.254) 56(84) bytes of data.
64 bytes from 10.0.0.254: icmp_seq=1 ttl=64 time=0.198 ms
64 bytes from 10.0.0.254: icmp_seq=2 ttl=64 time=0.197 ms
root@hv01:~# ping -c2 heise.de
connect: Network is unreachable
root@hv01:~# ping -c2 193.99.144.80
connect: Network is unreachable

Hab mal ein paar config-Dateien angeguckt:

root@hv01:~# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.0.0.34 hv01.linuxmuster.lan hv01
root@hv01:~# cat /etc/resolv.conf
search linuxmuster.lan
nameserver 10.0.0.254

Zum Vergleich der alte host pve (wo alles funktioniert)

root@pve:~# cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.0.0.20 pve.pss.example pve
root@pve:~# cat /etc/resolv.conf
search pss.example
nameserver 10.0.0.254

Sieht alles OK aus, bis auf den den Unterschied zum alten host pve: der neue host hv01 hat die domain linuxmuster.lan.

Der alte host pve hingegen erreicht heise.de wie erwartet über fw und modem:

root@pve:~# traceroute heise.de
traceroute to heise.de (193.99.144.80), 30 hops max, 60 byte packets
1 firewall.linuxmuster.lan (10.0.0.254) 0.292 ms 0.272 ms 0.259 ms
2 192.168.1.1 (192.168.1.1) 0.746 ms 0.805 ms 1.461 ms
3 62.155.246.204 (62.155.246.204) 22.393 ms 22.908 ms 23.842 ms
4 217.5.109.10 (217.5.109.10) 27.839 ms 28.328 ms 29.087 ms
5 62.159.61.15 (62.159.61.15) 32.331 ms 32.852 ms 32.852 ms
6 82.98.102.19 (82.98.102.19) 32.286 ms 31.857 ms 32.217 ms
7 82.98.102.23 (82.98.102.23) 32.901 ms 32.965 ms 34.063 ms
8 * * *
9 * * *
10 * * *
11 212.19.61.13 (212.19.61.13) 24.967 ms !X * *
root@pve:~#

Soviel Input für jetzt.

VG, ersin

Cgsman · 26. April 2021 um 15:52

Hallo, ersin,

in der Tat sehe ich etwas: Bei der CIDR sollte tatsächlich eine Netzmaske stehen…also eben die bekannte CIDR-Notation mit slash und Bitanzahl für die gesetzten Bits (10.0.0.34/16)…
Wir hatten ja schon darüber gesprochen, ob die netmask…- Angabe ok ist - für Debian sicherlich, aber evtl. nicht für die Proxmox-Funktionalität ? (Ein Schuss ins Blaue, ich weiß ! Aber die CIDR stimmt definitiv so nicht !). Steht denn hintendran der Gateway ? (Muss !)

Gruß Christoph