kodach
Goto Top

VLAN, DHCP und Hyper-V

Guten Abend

Ich baue mir gerade eine kleine Übungsumgebung auf Windows Server 2019 in der Evaluierungsversion. Dabei habe ich wohl ein Überlegungsfehler, und sehe im moment zumindest keinen fehler.


Ich habe auf einem Alten Server den DC1, auf einem zweiten alten Hyper-V und dort eine VM mit dem DC2. Beide sind verbunden und Replizieren sauber. Auf beiden DC ist der DNS sowie DHCP installiert.

DC1: 10.10.1.250
DC2: 10.10.1.251
VLAN 2: 10.10.2.0/24

Was habe ich gemacht:
Ich habe auf beiden DC's jeweils zwei NIC Ports mit der Server 209 Version und Teaming zusammengefasst (Switchunabhängig, Dynamisch und kein Standbyadapter). Dann habe ich zusätzlich bei den Teams eine neue Schnittstelle für das VLAN 2 erfasst.
Also habe ich nun NIC1 (TEAM), NIC2 (TEAM VLAN 2)
Ich habe beiden NICs eine statische IP gegeben. Als DNS haben beide die 10.10.1.250 sowie 10.10.1.251 drin. Desweiteren folgende IPs:
NIC1: 10.10.1.100, Gateway 10.10.1.1 (Unifi USG mit eingerichtetem VLAN)
NIC2: 10.10.2.50, Gateway 10.10.2.1 (Unifi USG mit eingerichtetem VLAN)

Als nächstes habe ich im DHCP zwei neue Bereiche erstellt
Bereich 10.10.1.0 mit den Bereichsoptionen (Router 10.10.1.1, DNS Server 10.10.1.251, 10.10.1.250, DNS-Domänenname test.local)
Bereich 10.10.2.0 mit den Bereichsoptionen (Router 10.10.6.1, DNS Server 10.10.1.251, 10.10.1.250, DNS-Domänenname test.local)

Hänge ich ein Laptop an einen Switchport, erhalte ich vom DHCP eine IP aus dem 10.10.1.0/24 Netz. Konfiguriere ich den Switch Port auf VLAN2, so erhalte ich vom DHCP aus dem 10.10.2.0/24 Netz meine IP.

Soweit scheint mal alles zu gehen. Nun zum Hyper V:
Hier habe ich zwei neue viruell Switch erstellt:
1. Extern, Als Adapter den NIC1 aus dem TEAM, Gemeinsames Verwenden dieses Netzwerkadapters für des Verwaltungsbetriebssystem zulassen, SR-IOV (Single-Root I/O Virtualization) aktivieren), VLAN ID nicht angepasst.
2. Extern, Als Adapter den NIC2 aus dem TEAM, Gemeinsames Verwenden dieses Netzwerkadapters für des Verwaltungsbetriebssystem zulassen, SR-IOV (Single-Root I/O Virtualization) aktivieren), VLAN ID nicht angepasst.

Wenn ich nun eine VM erstelle mit einem dieser Adapter, so erhalte ich keine IP zugewiesen. Ich habe auch schon ohne die SR-IOV Einstellung einige Tests gemacht und habe bereits versucht eine VLAN-ID anzugeben. Beides blieb ohne erfolg.

Ebenfalls habe ich mal versucht als zweiten Virtuellen Switch NIC1 zu wählen und dann die VLAN ID in Hyper-V zu übergeben. Aber so kann ich den Switch nicht speichern da NIC1 bereits in Verwendung ist.

EDIT: Ich habe ganz vergessen zu erwähnen, dass der DHCP funktioniert wenn ich eine VM mit NIC1 erstelle.

Ich bedanke mich schon jetzt für jeden Hilfehinweis.

Gruss

Koda

Content-Key: 510611

Url: https://administrator.de/contentid/510611

Printed on: April 19, 2024 at 12:04 o'clock

Member: aqui
aqui Oct 31, 2019 at 17:41:25 (UTC)
Goto Top
Was bedeutet VLAN ID nicht angepasst ??
Du musst dem vSwitch die VLAN ID mitgeben, damit dieser sie weiterleitet und der physische USG Port erkennt zu welchem VLAN diese Pakete kommen.
Der ausgehende NIC Port auf die externen Switches muss diese Pakete taggen aus dem entsprechenden VLAN.
Nochwas...
DNS-Domänenname test.local
Die Root Domain .local ist absolut TABU was interne Netze anbetrifft ! Die ist weltweit durch die IANA dem mDNS Dienst zugewiesen:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Das wird dir also früher oder später Probleme bereiten im Netzwerk.
Welche interen DNS Namen sinnvoll sind und warum .local ein NoGo ist erklärt dir diese Doku:
https://www.heise.de/select/ct/2017/26/1513540412603853
Wenn dann .lokal, .intern oder kodach.home.arpa wenn du ganz vorschriftsmässig agierst !
Member: KodaCH
KodaCH Oct 31, 2019 at 18:09:57 (UTC)
Goto Top
Hallo aqui

Vielen Dank für deine Antwort und deine Hinweise.

Zitat von @aqui:

Wenn dann .lokal, .intern oder kodach.home.arpa wenn du ganz vorschriftsmässig agierst !
Dann werde ich dies noch anpassen. Danke. Eigentlich wollte ich da später eine TLD verwenden (.ch). Da muss ich maal schauen ob eine normale TLD ok ist. Ansonsten würde ich auf .intern oder home.arpa wechseln.

Zitat von @aqui:

Was bedeutet VLAN ID nicht angepasst ??
Du musst dem vSwitch die VLAN ID mitgeben, damit dieser sie weiterleitet und der physische USG Port erkennt zu welchem VLAN diese Pakete kommen.
In den TEAM Einstellungen habe ich natürlich die VLAN id angepasst. Dort mit bin auch neue Schnittstelle, auf Speziefisches VLAN und habe die ID angegeben.
Im Hyper-V virtual Switch habe ich die Option "VLAN-ID" "Identifizierung virtueller LANs für das Verwaltungsbetriebssystem aktivieren" jedoch nicht aktiviert. Ich dachte, dass die bei NIC2 (dem VLAN vom TEAMING) ja bereits vergeben wurde.

Ich habe nun eine Lösung gefunden, verstehe aber nicht genau wieso die VLAN-ID mehrfach eingetragen werden muss. Kann mir das ggf jemand erklären?

Ich habe nun wie im ersten Beitrag geschrieben zwei NICs im TEAM erfasst, und habe für mein VLAN eine weitere Schnittstelle erfasst. In dieser Schnittstelle habe ich die VLAN ID vergeben.

In Hyper-V habe ich zwei Virtuelle Switches erstellt
  • Extern, NIC1, keine VLAN ID
  • Extern, NIC2, VLAN ID

Eine VM mit NIC1 erhält Netz, eine VM mit NIC2 jedoch nicht.
Nun habe ich in den Einstellungen der VM gesehen das unter Netzwerkkarte die VLAN-ID nicht eingetragen ist. Wenn ich diese nun eintrage funktioniert es. Meine erste Vermutung war, dass bei einer bestehenden VM die VLAN-ID nicht übernommen wird. Aber auch bei einer neuen VM wird diese nicht übernommen.

Weshalb muss ich also beim TEAMING bei der Schnittstelle die VLAN-ID eintragen (Nach meinem Verständnis ist diese dann fix drin, für den Host muss ich dann nichts mehr ändern damit diese im VLAN Netz ist), aber auch Zusätzlich im virtuellen Switch in den Haupteinstellungen UND in bei der Netzwerkkarte bei der Virtuellen Maschine?

Gruss und Danke

Koda
Member: NordicMike
NordicMike Oct 31, 2019 at 19:10:16 (UTC)
Goto Top
Ich bin noch nicht ganz sauber dahinter gestiegen, was Du gebaut hast. Was macht auf einem Domain Controller ein Teaming (Verbund zweier Netzwerkports).

Zweiachser am besten schematisch auf, was Du hast. Beschreibe auch, was Du vor hast bzw was Dein Ziel ist. Willst Du etwa durch zuweisen verschiedener Netzwerkkarten die VMs ins VLAN oder VLAN1 stecken?
Member: KodaCH
KodaCH Oct 31, 2019 at 19:22:16 (UTC)
Goto Top
Guten Abend

Auf dem DC1 habe ich zwei Ports mit Teaming zusammen verbunden. Ich habe diverse Berichte gefunden das dies vorteilhaft sei für die VLAN Einrichtung selbst wenn das Teaming nur aus einem NIC bestehen sollte. Da der DC1 auch der DHCP Server ist, und dies auch für das VLAN sein soll habe ich mich auf die Suche gemacht weshalb dies nicht auf Anhieb funktioniert hat. Dort habe ich dann (was für mich nachvollziehbar klang) gelesen, dass der DHCP Server in jedem VLAN ein Standbein haben muss. Nach dem ich dies gemacht habe klappte alles.
Mit der Teaming Variante ist es natürlich sehr angenehm ein weiteren Netzwerkadapter für ein VLAN zu erstellen.

Auf dem zweiten Server welcher der Hyper-V Server ist habe ich ebenfalls das Teaming gemacht da es dort vorteile bringen soll und ich den Server so sehr einfach in alle nötigen VLANs stecken kann. Dies war (nach versuchen) nötig, damit ich eine VM dann in ein entsprechendes VLAN stecken konnte.
Ich ging urspünglich davon aus das ein virtueller Switch im Hyper-V ausreicht wenn dieser auf der weiteren Schnittstelle der Verbundenen Netwerkkarte zeigt. Dort ist ja bei der Schnittstelle bereits die VLAN ID drin. Aber wie oben beschrieben war dies ein irrtum. Nach dem ich die VLAN-ID beim Teaming aber auch im Hyper-V im Virtuellen Switch UND in den Einstellungen der VM gemacht habe geht es auch. Finde es einfach noch speziell das ich die Virtuelle ID an allen drei Orten eintragen musste.

Ich hoffe dies ist einigermassen Verständlich.
Member: NordicMike
NordicMike Oct 31, 2019 at 19:43:08 (UTC)
Goto Top
Du hast zwei Möglichkeiten beim zweiten Server:

1) Zwei Netzwerkkarten mit zwei Kabel an zwei Ports am Switch verbinden. Ein Port (am Switch) auf VLAN untagged und den anderen Port auf VLAN1 untagged stellen. Der Server benötigt dann keine VLAN Einstellungen mehr, für ihn sind es bereits zwei voneinander getrennte Netze. Er weiß auch gar nicht, dass der Switch mit VLANs arbeitet, oder ob es zwei getrennte Switche sind, für ihn sind es einfach zwei Netze. Du kannst sie LAN1 und LAN2 benennen oder, falls Du weißt, was Du tust, und Dich auskennst, auch VLAN und VLAN1 benennen um Namensgleichheit mit Deinem restlichen Netzwerk zu haben. Du brauchst dann nur noch zwei virtuelle Hyper-V Switche, die jeweils auf eine der zwei Netzwerkkarten schauen.

2) oder Du stellst einen Switch Port auf VLAN untagged + VLAN1 tagged und verbindest den zweiten Server nur mit einer Netzwerkkarte und einem Kabel zum Switch Port. Im Hyper-V brauchst Du nur einen externen virtuellen Switch. Beim einrichten der VM weist Du diese eine Netzwerkkarte zu und kannst direkt darunter einstellen, ob sie auf eine bestimmte VLAN ID horchen soll. Wenn Du 1 eingibst, ist die VM im VLAN1 und wenn Du nichts eingibst, ist die VM im VLAN.
Member: KodaCH
KodaCH Nov 01, 2019 at 06:54:53 (UTC)
Goto Top
Guten Morgen

Danke für deine Antwort NordicMike.

Variante 1 kommt für mich eigentlich nicht in Frage. Wenn ich mal übertrieben gesagt 10 VLANs hätte, würde ich ja 10 Netzwerkkarten benötigen, oder 10 NIC Ports face-smile

Variante 2 (Ich gehe mal nur vom Hyper-V Server aus):
Ich habe UniFi Geräte. Ich habe dem Port bereits unter "Switch Port Profile" gesagt das er alle Netze darauf hat. Heisst das, dass wenn ich Teaming verwende ich einfach wie jetzt ein Teaming machen kann, dann für jedes VLAN eine neue Schnittstelle und das selbe im Hyper-V (so das ich die VLAN ID einfach mehrfach übergeben muss), oder aber ich lösche das Teaming, verwende nur ein Kabel und müsste dafür nur einmal die VLAN ID übergeben? Dann hätte ich ja eher Vorteile wenn ich das Teaming lasse, da man ja nicht wirklich täglich neue VMs erstellt face-smile

Gruss

Koda
Member: NordicMike
Solution NordicMike Nov 01, 2019 at 07:09:50 (UTC)
Goto Top
Hi Koda

Das Teaming vor dem Hyper-V virtuellen Switch gemacht. Wenn Du 4 Leitungen hast, die zusammen ein Teaming bilden, benötigst Du für den Hyper-V trotzdem nur einen Hyper-V virtuellen Switch, dieser genießt die Vorteile vom Teaming automatisch. Das Teaming verwaltet nur der Host. Die VMs haben dann nur noch eine Netzwerkkarte, ohne zu wissen, dass es ein Teaming gibt.

Das Teaming bietet zwei Vorteile:
1) Bei Ausfall einer Leitung ist noch eine weitere Leitung da
2) Im Betrieb wird eine Lastverteilung gemacht, somit muss eine zweite Anfrage nicht warten, bis die erste Anfrage fertig ist, das wirkt sich etwas schneller auf die Gesamtperformance aus. In kleinen Netzwerken so gut wie gar nicht zu spüren.

Wenn Du also mit nur einer Leitung zwischen Switch und Host verbindest, bringt Dir das Teaming gar nichts, nur eine komplizierte Falschkonfiguration, da man beim Teaming noch mehr beanten muss, z.B. Round Robin, broadcast, load balancing uvm...