5
Einsatz von VLAN-IDs - kein Gateway erkannt
Hallo,
irgendwie habe ich einen Denkfehler gemacht...
Ich möchte, dass alle VMs in Hyper-V mit VLAN-IDs arbeiten. Dafür habe ich in den Einstellungen der VM die VLAN-IDs eingetragen und am Switch die LAG-Ports für beide VLANs auf tagged eingestellt, d. h., Pakete von VLAN 1 und VLAN 2 sollen über den gleichen LAG-Port transportiert werden.
Mein Problem:
Die VMs in VLAN 1 können sich untereinander kommunizieren. Ping funktioniert einwandfrei. Aber wenn ich einer VM die IP-Adresse für VLAN 2 vergebe und auch in den Einstellungen der VM die VLAN-ID, funktioniert kein Ping. Es konnte kein Gateway erkannt werden. Die IP-Konfiguration war korrekt.
Laut Wireshark wurden nur ARP-Anfragen verschickt. Mithilfe von Port Mirroring konnte ich am Switch was von VLAN 1 finden, jedoch nichts von VLAN 2, obwohl beide VLANs über den gleichen Port kommen.
Einziger Unterschied: Das Gateway von VLAN 1 ist der L3-Switch, das von VLAN 2 der Router. Von VLAN 1 aus kann ich den Router von VLAN 2 erreichen und vor der Umstellung hatte alles einwandfrei funktioniert. Aus diesem Grund vermute ich das Problem am Switch oder in der VM selbst...
Folgendes hatte ich in dieser Reihenfolge gemacht:
1. Änderung der Switch-Ports auf tagged und auf "Trunk", nicht "Access"
2. Eintragung von VLAN-IDs in den VM-Einstellungen
und fertig...
Irgendwer noch eine Idee? Hatte ich was übersehen?
LG
So sieht das Netzwerk grob aus:
irgendwie habe ich einen Denkfehler gemacht...
Ich möchte, dass alle VMs in Hyper-V mit VLAN-IDs arbeiten. Dafür habe ich in den Einstellungen der VM die VLAN-IDs eingetragen und am Switch die LAG-Ports für beide VLANs auf tagged eingestellt, d. h., Pakete von VLAN 1 und VLAN 2 sollen über den gleichen LAG-Port transportiert werden.
Mein Problem:
Die VMs in VLAN 1 können sich untereinander kommunizieren. Ping funktioniert einwandfrei. Aber wenn ich einer VM die IP-Adresse für VLAN 2 vergebe und auch in den Einstellungen der VM die VLAN-ID, funktioniert kein Ping. Es konnte kein Gateway erkannt werden. Die IP-Konfiguration war korrekt.
Laut Wireshark wurden nur ARP-Anfragen verschickt. Mithilfe von Port Mirroring konnte ich am Switch was von VLAN 1 finden, jedoch nichts von VLAN 2, obwohl beide VLANs über den gleichen Port kommen.
Einziger Unterschied: Das Gateway von VLAN 1 ist der L3-Switch, das von VLAN 2 der Router. Von VLAN 1 aus kann ich den Router von VLAN 2 erreichen und vor der Umstellung hatte alles einwandfrei funktioniert. Aus diesem Grund vermute ich das Problem am Switch oder in der VM selbst...
Folgendes hatte ich in dieser Reihenfolge gemacht:
1. Änderung der Switch-Ports auf tagged und auf "Trunk", nicht "Access"
2. Eintragung von VLAN-IDs in den VM-Einstellungen
und fertig...
Irgendwer noch eine Idee? Hatte ich was übersehen?
LG
So sieht das Netzwerk grob aus:
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 319043
Url: https://administrator.de/contentid/319043
Printed on: April 19, 2024 at 04:04 o'clock
5 Comments
Latest comment
VLAN 1 wird vermutlich nicht gehen. Bei vielen Switches wo das das native VLAN ist erlauben die keinen Tag.
Musst du ausprobieren ob der interne vSwitch das kann.
Am schnellsten geht das mit dem Wireshark am Ausgangsport und dann checkst du mal ob die da mit 802.1q ID 1 und 2 ankommen, dann klappt das !
Denk dran das du das Übertragen der Tags erlauben muss wenn du Winblows benutzt sonst zeigt der Kabelhai das nicht an, da Windows verher die Tags abstrippt.
Die VLANs sind 2 vollkommen voneinander getrennte Broadcast Domains die sich nicht "sehen". Wie soll denn da auch ein Ping VLAN übergreifend passieren ?
Dafür braucht es bekanntermaßen ein Router oder L3 Switch wie du hier täglich ja in diversen Threads erfährst oder wenn du dir das hiesige VLAN Tutorial mal zu Gemüte führst:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Oooops...sorry lese gerade das dein Switch ein L3 Switch ist. Shame on me...
Sollte man besser immer bleiben lassen oder gibt es einen wirklich triftigen Grund dafür ?
Deine ToDos den L3 Switch richtig einzurichten
ip route 10.2.0.0 255.255.255.0 10.99.0.254
Du schreibst auch was von LAGs, also Link Aggregation mit 802.3ad und LACP.
Da musst du aufpassen das dein vSwitch das kann und entsprechend die Ports nach draußen auf den externen Switch so einstellen.
Hier natürlich ebenso das Server 1 eine LAG Gruppe ist und Server 2 die andere. Im Switch kannst du dir dann den LACP State ansehen ob der LAG auch aktiv ist !
Damit sollte dies recht einfache Szenario dann fehlerfrei klappen.
Musst du ausprobieren ob der interne vSwitch das kann.
Am schnellsten geht das mit dem Wireshark am Ausgangsport und dann checkst du mal ob die da mit 802.1q ID 1 und 2 ankommen, dann klappt das !
Denk dran das du das Übertragen der Tags erlauben muss wenn du Winblows benutzt sonst zeigt der Kabelhai das nicht an, da Windows verher die Tags abstrippt.
Es konnte kein Gateway erkannt werden. Die IP-Konfiguration war korrekt.
Ahem....das ist aber auch klar wenn dein externer Switch kein L3 (Routing) Switch ist !Die VLANs sind 2 vollkommen voneinander getrennte Broadcast Domains die sich nicht "sehen". Wie soll denn da auch ein Ping VLAN übergreifend passieren ?
Dafür braucht es bekanntermaßen ein Router oder L3 Switch wie du hier täglich ja in diversen Threads erfährst oder wenn du dir das hiesige VLAN Tutorial mal zu Gemüte führst:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Oooops...sorry lese gerade das dein Switch ein L3 Switch ist. Shame on me...
Einziger Unterschied: Das Gateway von VLAN 1 ist der L3-Switch, das von VLAN 2 der Router.
Böses Faul ! Asymetrisches Routing !! Zeugt nicht gerade von einem guten Netzwerker... Sollte man besser immer bleiben lassen oder gibt es einen wirklich triftigen Grund dafür ?
Deine ToDos den L3 Switch richtig einzurichten
- VLANs anlegen und Ports zuweisen (tagged und untagged). Bei tagged Ports wird das native VLAN 1 in der regel immer untagged übertragen !
- In den VLANs auf dem L3 Switch entsprechende IP Adressen (Gateway IPs) festlegen. Z.B.: 10.1.0.254 /24 (VLAN 1) und 10.2.0.254 /24 (VLAN 2)
- Gateway der Endgeräte in den VLANs zeigt dann immer auf die korrespondierende L3 Switch IP im VLAN
- Der Internet Router sollte in einem L3 Switchdesign niemals in einem der Servernetze oder generell Produktivnetze / VLANs liegen !! Grund dafür dürfte klar sein.
- Hier also immer ein separates "Internet / WAN" VLAN erzeugen z.B. 99 mit einem untagged Port (für den Router) und IP 10.99.0.254 /24 auf dem Switch (Router IP mal angenommen 10.99.0.1)
- Default Route auf dem Switch einrichten: ip route 0.0.0.0 /0 10.99.0.1 (Router IP der im VLAN 99 hängt)
- Auf dem Router dann statische Routen für die VLAN IP Netze einrichten:
ip route 10.2.0.0 255.255.255.0 10.99.0.254
- Fertisch !
Du schreibst auch was von LAGs, also Link Aggregation mit 802.3ad und LACP.
Da musst du aufpassen das dein vSwitch das kann und entsprechend die Ports nach draußen auf den externen Switch so einstellen.
Hier natürlich ebenso das Server 1 eine LAG Gruppe ist und Server 2 die andere. Im Switch kannst du dir dann den LACP State ansehen ob der LAG auch aktiv ist !
Damit sollte dies recht einfache Szenario dann fehlerfrei klappen.
Danke für die ausführliche Antwort.
Ja, weil die VMs in VLAN 2 von einer anderen Firma sind, wegen der Firewall. Der Router ist auch die zentrale Firewall. Das interne Netzwerk, also kein "Außennetzwerk", wird mithilfe von ACLs auf dem zentralen L3-Switch geschützt.
Wegen dem nativen VLAN: Ich hatte im Handbuch vom Cisco SG500 nachgeschaut und konnte nichts bei "VLAN-Management" finden. Wo kann ich prüfen, ob die Ports natives VLAN haben?
Dem Router sind keine Netzwerke aus dem internen Bereich bekannt. Ist also schon beachtet.
Heißt das, nicht alle vSwitche beherrschen LAG?
Sollte man besser immer bleiben lassen oder gibt es einen wirklich triftigen Grund dafür ?
Ja, weil die VMs in VLAN 2 von einer anderen Firma sind, wegen der Firewall. Der Router ist auch die zentrale Firewall. Das interne Netzwerk, also kein "Außennetzwerk", wird mithilfe von ACLs auf dem zentralen L3-Switch geschützt.
Wegen dem nativen VLAN: Ich hatte im Handbuch vom Cisco SG500 nachgeschaut und konnte nichts bei "VLAN-Management" finden. Wo kann ich prüfen, ob die Ports natives VLAN haben?
Der Internet Router sollte in einem L3 Switchdesign niemals in einem der Servernetze oder generell Produktivnetze / VLANs liegen !! Grund dafür dürfte klar sein.
Dem Router sind keine Netzwerke aus dem internen Bereich bekannt. Ist also schon beachtet.
Da musst du aufpassen das dein vSwitch das kann und entsprechend die Ports nach draußen auf den externen Switch so einstellen.
Heißt das, nicht alle vSwitche beherrschen LAG?
Ich glaube, dass es eine andere Ursache gibt, denn ich bin auf dem gleichen Server auf dieses Phänomen gestoßen. Sogar in Hyper-V sind die virtuellen Netzwerkadapter alle auf "Privates Netzwerk" eingestellt.
Ja, weil die VMs in VLAN 2 von einer anderen Firma sind, wegen der Firewall. Der Router ist auch die zentrale Firewall.
Dann hast du ein grundsätzlich falsches Design gemacht ! Bzw. es intuitiv richtig gemacht, denn so gibt es ja vermutlich auch keinerlei Kommunikation zw. diesen VLANs.Das bedeutet dann das das VLAN der anderen Firma KEINE IP Adresse auf dem VLAN L3 Switch konfiguriert haben darf in dem VLAN !!
Damit ist dann ein Routing über den Switch technisch ausgeschlossen und die Endgeräte haben dann nur das Gateway direkt auf dem Router.
Das einzige Problem ist das du das VLAN 1 gewählt hast. Wenn du das für deine eigene Fa. nimmst ist das kein Problem aber die andere Firma solltest du immer in ein separates VLAN nehmen und niemals in das VLAN 1 was ja das native VLAN ist sofern du das nicht umgestellt hast.
So oder so hast du aber immer ein Sicherheitsproblem, denn auch wenn du es so machst, sprich also Router und VLAN der anderen Firma in ein Netzsegment um den Switch zu umgehen und dein VLAN in einseparates Segment musst du auf dem Switch beide VLANs mit IP Adressen versehen um dein Netzwerk wieder zum Router routen zu können wie oben beschrieben. Auch dann musst du also zwingend mit ACLs entweder am Router oder FW leben. Du kannst das andere Netz so nicht vollkommen isolieren.
Es sei denn der Router hat einen 2ten Port oder supportet idealerweise ein VLAN Tagging am Port so das du beide VLANs auf getrennte Interfaces am Router legen kannst
Das Design so ist nicht nicht wasserdicht oder erfordert Aufwand es wasserdicht zu machen.
Dem Router sind keine Netzwerke aus dem internen Bereich bekannt. Ist also schon beachtet.
Das müsste s aber zwingend wenn dein VLAN in einem anderen IP Segment liegt !Anders kann es ncht gehen. Eben nur wenn der Router 2 Interfaces hat egal ob physisch oder virtuell mit Tagging.
Oder soll es ein VLAN übergreifendes Routing geben ?
Dann wäre die o.a. Konfig aber auch richtig, denn die andere Fa. kann dann nur über die FW routen. Ein asymetrisches Routing ist dann ausgeschlossen wenn es keine Switch IP in dem VLAN der anderen Firma gibt.
Wegen dem nativen VLAN
Der Dativ ist dem Genetiv sein Tod.... Heißt das, nicht alle vSwitche beherrschen LAG?
Jau, ganz genau !Der vSwitch muss dafür den Standard 802.3ad mit LACP supporten, minimal aber ein statisches Link Aggregation, was aber suboptimal ist.
Ohne das keine Link Aggreagtion sondern im Gegenteil es droht die Gefahr eines Loops im Netzwerk !
Ohne aktiven Spanning Tree sollte man dann niemals arbeiten wenn man nicht sicher ist ob der vSwitch das kann !
Sogar in Hyper-V sind die virtuellen Netzwerkadapter alle auf "Privates Netzwerk" eingestellt.
Das wäre dann in der tat etwas was gar nichts mit dem Netzwerk bzw. der Infrastruktur zu tun hätte sondern mit der lokalen Winblows Firewall.Aber das kann man ja schnell fixen über die FW Settings mit erweiterten...
Hallo,
seitdem ich alle Netzwerkkarten aufgrund eines bereits erwähnten Fehlers neu konfiguriert habe, geht alles wieder. Auch das Gateway ist wieder erreichbar.
seitdem ich alle Netzwerkkarten aufgrund eines bereits erwähnten Fehlers neu konfiguriert habe, geht alles wieder. Auch das Gateway ist wieder erreichbar.
