Falls du zufällig ein SDN VLAN mit der ID des Native VLANs angelegt hast, kann das nicht funktionieren.
Das ist so.
Wir haben drei Native VLAN die ich zur Verfügung habe.
Die Vlans:
102
103
104
Ich bekomme auch die Dhcp Adressen von dem Nativen Vlan.
Scheint alles so zu funktionieren, bis auf den Zugriff auf den Host.
Hier mal die Routen:
Die hier sollte das doch abdecken?
Code:
10.128.0.0/16 via 192.168.240.1 dev vmbr2
10.144.188.0/24 dev ens1f0np0 proto kernel scope link src 10.144.188.10
10.144.189.0/24 dev vmbr1 proto kernel scope link src 10.144.189.10
172.16.1.0/28 dev eno8303 proto kernel scope link src 172.16.1.1
192.168.0.0/24 dev vlan10 proto kernel scope link src 192.168.0.1
192.168.1.0/24 dev vmbr3 proto kernel scope link src 192.168.1.1
192.168.240.0/24 dev vmbr2 proto kernel scope link src 192.168.240.2Die hier sollte das doch abdecken?
Code:
10.144.189.0/24 dev vmbr1 proto kernel scope link src 10.144.189.10Das wundert mich. Normalerweise dürfte die VM kein Netzwerk haben oder der PVE.
Das VNET102 gibt den Traffic getagged an den Switch nach draußen. Der PVE arbeitet aber im gleichen VLAN untagged.
Gib der VM mal statt dem VNET102 die Bridge direkt. Dann sollte DHCP immer noch funktionieren und der Host erreichbar sein.
Das VNET102 gibt den Traffic getagged an den Switch nach draußen. Der PVE arbeitet aber im gleichen VLAN untagged.
Gib der VM mal statt dem VNET102 die Bridge direkt. Dann sollte DHCP immer noch funktionieren und der Host erreichbar sein.
ja das habe ich nicht wirklich in der selber in der Hand.
das ist die Info die ich erhalten habe:
Ein paar Details: Die Vlans 101, 102, 103, 104 sind keine nativen Vlans, sondern normale Layer 2 Vlans.
Das native Vlan hat die ID 2.
Der Switchport ist wie folgt konfiguriert:
switchport trunk native vlan 2
switchport trunk allowed vlan 101-104
switchport mode trunk
spanning-tree portfast disable
spanning-tree bpduguard disable
spanning-tree guard none
ip dhcp snooping trust
Das sind Cisco Switches
das ist die Info die ich erhalten habe:
Ein paar Details: Die Vlans 101, 102, 103, 104 sind keine nativen Vlans, sondern normale Layer 2 Vlans.
Das native Vlan hat die ID 2.
Der Switchport ist wie folgt konfiguriert:
switchport trunk native vlan 2
switchport trunk allowed vlan 101-104
switchport mode trunk
spanning-tree portfast disable
spanning-tree bpduguard disable
spanning-tree guard none
ip dhcp snooping trust
Das sind Cisco Switches
Last edited:
Cisco sieht man schon an der Syntax.
Spanning Tree portfast ist immer auf Serverports empfohlen. VMware empfiehlt das auch für ESXi.
Also ist dein Host im VLAN2. Dann dürfte er keine IP im gleichen Segment wie die VM in VLAN 102 haben.
Wenn du noch eine IP in dem Segment frei hast, kannst du auf dem vmbr mal ein vlan interface vlan102 anlegen und schauen von wo du diese IP erreichst.
Wenn du das VLAN auf dem Bond abgreifst, kommt auf der Bridge nix mehr an.
Deshalb als Source bei dem VLAN Interface die vmbr eintragen.
Irgendetwas ist bei deinem Setup etwas komisch.
Anscheinend hast du ein Netzwerkerteam, was recht verschlossen ist. Das habe ich leider schon bei einigen größeren Unternehmen gesehen.
Man müsste einmal die koplette Konfiguration auf den Switches checken und die Proxmox Konfiguration darauf in Einklang bringen.
Dieses an Fehlern langhangeln, dauert ewig und ist nicht Nachhaltig.
Anscheinend hast du ein Netzwerkerteam, was recht verschlossen ist. Das habe ich leider schon bei einigen größeren Unternehmen gesehen.
Man müsste einmal die koplette Konfiguration auf den Switches checken und die Proxmox Konfiguration darauf in Einklang bringen.
Dieses an Fehlern langhangeln, dauert ewig und ist nicht Nachhaltig.