117471
Oct 20, 2016
2217
7
0
Zuweisung Netzwerkprofil nicht resetfest
Hallo,
ein Kollege hat auf einem Hyper-V-Host ein paar Netzwerkkarten an einen "leeren" Switch angeschlossen. Die Netzwerkschnittstellen haben eine IP-Adresse und eine Subnetzmaske, aber kein Gateway.
Die Netzwerkschnittstellen werden der Kategorie "Public" zugeordnet.
Also bin ich in die PowerShell, habe mir mit Get-NetConnectionProfile den InterfaceIndex von einer der Schnittstellen geholt und diesen via Set-NetconnectionProfile in die Kategorie "Private" geschubst. Interessanterweise sind daraufhin sämtliche Schnittstellen "umgeplöppt" (ich hätte gedacht, dass nur die umspringt, deren InterfaceIndex ich angebe).
Meine Theorien dazu:
"Der Server sieht über die anderen Schnittstellen, dass er bereits mit einer MAC auf dem Switch hängt, deren Schnittstelle der Kategorie Private zugeordnet ist - also betrachtet er den gesamten Switch und somit auch die anderen Schnittstellen auch als Private". Ist das korrekt? Falls nein - warum springen alle Schnittstellen gleichzeitig um, wenn ich explizit nur eine Schnittstelle umhänge?
Zusätzlich beobachten wir, dass die Zuordnung nicht resetfest ist. Dazu folgende Theorie: "Der Server muss auf dem Switch irgendeine MAC-Adresse finden. Diese merkt er sich und verwendet sie, um das Netzwerk zukünftig zu identifizieren. Da er dort nur eigene MAC-Adressen sieht, die ja grundsätzlich erst einmal nicht kategorisiert sind, kann er das Netzwerk nicht wiedererkennen und stuft es daher als Public ein". Ist das korrekt?
"Im Grunde genommen" dürfte sich das Problem spätestens dann erledigen, wenn an dem Switch zusätzlich ein weiteres Gerät mit einer MAC-Adresse angeschlossen wird - oder?
Gruß,
Jörg
ein Kollege hat auf einem Hyper-V-Host ein paar Netzwerkkarten an einen "leeren" Switch angeschlossen. Die Netzwerkschnittstellen haben eine IP-Adresse und eine Subnetzmaske, aber kein Gateway.
Die Netzwerkschnittstellen werden der Kategorie "Public" zugeordnet.
Also bin ich in die PowerShell, habe mir mit Get-NetConnectionProfile den InterfaceIndex von einer der Schnittstellen geholt und diesen via Set-NetconnectionProfile in die Kategorie "Private" geschubst. Interessanterweise sind daraufhin sämtliche Schnittstellen "umgeplöppt" (ich hätte gedacht, dass nur die umspringt, deren InterfaceIndex ich angebe).
Meine Theorien dazu:
"Der Server sieht über die anderen Schnittstellen, dass er bereits mit einer MAC auf dem Switch hängt, deren Schnittstelle der Kategorie Private zugeordnet ist - also betrachtet er den gesamten Switch und somit auch die anderen Schnittstellen auch als Private". Ist das korrekt? Falls nein - warum springen alle Schnittstellen gleichzeitig um, wenn ich explizit nur eine Schnittstelle umhänge?
Zusätzlich beobachten wir, dass die Zuordnung nicht resetfest ist. Dazu folgende Theorie: "Der Server muss auf dem Switch irgendeine MAC-Adresse finden. Diese merkt er sich und verwendet sie, um das Netzwerk zukünftig zu identifizieren. Da er dort nur eigene MAC-Adressen sieht, die ja grundsätzlich erst einmal nicht kategorisiert sind, kann er das Netzwerk nicht wiedererkennen und stuft es daher als Public ein". Ist das korrekt?
"Im Grunde genommen" dürfte sich das Problem spätestens dann erledigen, wenn an dem Switch zusätzlich ein weiteres Gerät mit einer MAC-Adresse angeschlossen wird - oder?
Gruß,
Jörg
Please also mark the comments that contributed to the solution of the article
Content-Key: 318518
Url: https://administrator.de/contentid/318518
Printed on: April 25, 2024 at 09:04 o'clock
7 Comments
Latest comment
Hallo,
Dein Horst die Parent VM (Dein Host ist nachdem die Rolle Hyper-V installiert wurde ebenfalls dann eine VM) hängt auch da dran? Horst ist Workgroup oder DomainMember? LAN direkt per (lokal) GPedit.msc oder (Domäne) GPO in ein Privates LAN (Lokal) oder in dein Domänen-LAN (GPO) schubsen wenn der Horst mal neu starten sollte.
Kein Gateway erreichbar - keine Erkennung. Was tatsächlich das Gateway ist (z.B. ein PC) ist irrelevant.
Gruß,
Peter
Zitat von @117471:
Die Netzwerkschnittstellen haben eine IP-Adresse und eine Subnetzmaske, aber kein Gateway.
Die Netzwerkschnittstellen werden der Kategorie "Public" zugeordnet.
Und eben weil die kein Gateway finden können alle an diesen Switch angeschlossenen VMs eben nicht erkennen......Die Netzwerkschnittstellen haben eine IP-Adresse und eine Subnetzmaske, aber kein Gateway.
Die Netzwerkschnittstellen werden der Kategorie "Public" zugeordnet.
Dein Horst die Parent VM (Dein Host ist nachdem die Rolle Hyper-V installiert wurde ebenfalls dann eine VM) hängt auch da dran? Horst ist Workgroup oder DomainMember? LAN direkt per (lokal) GPedit.msc oder (Domäne) GPO in ein Privates LAN (Lokal) oder in dein Domänen-LAN (GPO) schubsen wenn der Horst mal neu starten sollte.
Kein Gateway erreichbar - keine Erkennung. Was tatsächlich das Gateway ist (z.B. ein PC) ist irrelevant.
Gruß,
Peter
Hallo,
NLA und Gateway ist dein Freund Suchbegriff
Gruß,
Peter
Zitat von @117471:
allerdings ist das dann wohl eher die Brechstange...?!?
NÖ - warum sollte es? Wenn nunmal kein aktive reagierendes Gateyway zum Zietpunkt der Netzwerkschittstellenaktivierung existiert. Das Gateway selbst muss ja gar nicht als Gateway funktionieren, es muss nur antworten - nur Blöd wenn mann dann zum Arbeiten das Gateway doch wieder anfassen muss. Wenn dein Horst selbst eine eigene Hardwareschittstelle hat (kein V-Switch) ....allerdings ist das dann wohl eher die Brechstange...?!?
NLA und Gateway ist dein Freund Suchbegriff
Gruß,
Peter