Keine IP nach Umzug auf neuen host (Proxmox)

Server v7
18

Hallo Jörg,

Ja, mach ich, sobald ich (heute so gegen 11:30) wieder an der Schule bin…
Wollte mir diese Sachen ohnehin genauer angucken, weil ich dort den Fehler (oder Hinweise drauf) vermute.

BG, ersin

Update 11:50:
hier die Daten, ich seh da nix ungewöhnliches. Aber vllt. fällt euch was auf.

/etc/network/interfaces

network interface settings; autogenerated

Please do NOT modify this file directly, unless you know what

you’re doing.

If you want to manage parts of the network configuration manually,

please utilize the ‚source‘ or ‚source-directory‘ directives to do

so.

PVE will preserve these directives, but will NOT read its network

configuration from sourced files, so do not attempt to move any of

the PVE managed interfaces into external files!

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 manual
address 10.0.0.34 # green IP of vm host
netmask 255.255.0.0 # CIDR 16
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

output 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 56:38:c4:1c:33:c4 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 4a:18:06:1a:40:a0 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 ce:56:7b:c5:52:76 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 4a:18:06:1a:40:a0 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 aa:e1:2b:6e:6c:bb 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 7e:bc:8e:7a:b2:17 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:e9:9c:ab:b7:1e 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 7e:bc:8e:7a:b2:17 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 7e:ca:61:3c:f4:d0 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 ca:bb:61:fa:2c:0a 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 b6:92:95:ba:a0:46 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 ca:bb:61:fa:2c:0a brd ff:ff:ff:ff:ff:ff

(Anm.: das einleitende # bewirkt hier Fettdruck, weiß jemand, wie ich längeren Text in eine scrollbare Box bekomme?)

19

Hallo Michael,

Ja, hab ich (auf das Dashboard von OPNSense komme ich ja, daher extra vergewissert, weil der neue Host ja nicht mehr die IP ~20 hat, sondern ~34).

BG, ersin

20

Hallo Ersin,

schreibe mal in die /etc/network/interfaces:

iface vmbr0 inet static

(static statt manual - manual heißt, dass Du das Device zur Laufzeit manuell konfigurierst, static heißt, dass es mit den angegebenen Werten konfiguriert werden soll).

Beste Grüße

Jörg

21

Guckst Du hier!

22

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 :confused:

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

23

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

1 „Gefällt mir“
24

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 :arrow_forward: " hinbekommen? Ok

25

Hallo Ersin,

danke dafür und ein Herz von mir. :slight_smile:

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

Beste Grüße

Thorsten

26

Folge dem Link von mir.

27

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

28

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…

29

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

30

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

31

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

32

Hallo Michael,

das ist aber nicht /16, sondern /24

Gruß

Alois

33

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

34

Hallo, Ihr beiden,

ja, beides geht.

Gruß Christoph

35

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

36

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

37

Hallo Christoph – das verstehe ich nicht; bzw sehe ich es genau umgekehrt :thinking: : 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