11
Hyper-V virtueller Switch
Hallochen allerseits,
mir geht es um eine Verständnisfrage zu den virtuellen Switchen des Hyper-V-Hosts, die ich anhand der verfügbaren Informationen (Hilfefunktion, Google etc.) für mich nicht abschließend beantworten kann. Im Kern geht es dabei um die direkte Kommunikation der virtuellen Maschinen untereinander und mit physischen Maschinen im (lokalen) Netzwerk.
Es soll für die Betrachtung folgende Situation gegeben sein: zwei virtuelle Maschinen (VM01, VM0), zwei physische Netzwerkkarten (NCA, NCB), zwei externe virtuelle Switche (VSwA (gebunden an NCA), VSwB (gebunden an NCB)), ein interner Switch (VSwC) und ein physische Switch (Cisco), mit dem die Netzwerkkarten verbunden sind.
Klar ist, dass der interne / private virtuelle Switch (nur) der direkten Kommunikation zwischen den virtuellen Maschinen dient (je nachdem, ob der HV-Host mit eingebunden ist (intern) oder nicht (privat)). In der gegebenen Situation:
VM01 <-> VSwC <-> VM02 [oder bei intern auch: VM01 (/VM02) <-> VSwC <-> HV-Host]
Genauso klar ist, dass der externe virtuelle Switch der Kommunikation mit dem physischen Netzwerk dient, indem dieser Switch an eine physische Netzwerkkarte gebunden wird, so dass die mit diesem Switch verbundenen virtuellen Maschinen über diese physische Netzwerkkarte mit dem lokalen Netzwerk etc. kommunizieren können. Ist der HV-Host beim externen Switch mitberechtigt, so kann auch er über die Netzwerkkarte mit dem lokalen Netzwerk etc. kommunizieren. Soweit alles wunderbar. In der gegebenen Situation gilt
VM01 <-> VSwA/VSwB <-> NCA/NCB <-> Cisco
VM02 <-> VSwA/VSwB <-> NCA/NCB <-> Cisco
Sind VM01 und VM02 NICHT am selben virtuellen Switch angebunden, muss die Kommunikation (zwingend) über den physischen Switch laufen, beispielsweise wie folgt:
VM01 <-> VSwA <-> NCA <-> Cisco <-> NCB <-> VSwB <-> VM02
Jetzt die Verständnisfrage: Wie sieht es aber aus, wenn beide virtuellen Maschinen am selben externen virtuellen Switch angebunden sind? Läuft dann die Kommunikation dennoch über den physischen Switch oder können sie unmittelbar über den externen virtuellen Switch, also ohne Umweg über den physischen Switch, miteinander kommunizieren? Also, ob
VM01 <-> VSwA <-> NCA <-> Cisco <-> NCA <-> VSwA <-> VM02
ODER
VM01 <-> VSwA <-> VM02
gilt?
Wünschenswert wäre natürlich letzteres, obschon ich bisher davon ausgehe, dass die Kommunikation über den physischen Switch erfolgt, auch wenn beide virtuelle Maschinen an demselben virtuellen Switch angebunden sind. Das ist natürlich ein deutlicher Umweg, der sich durch Latenz und beschränkte Bandbreite erheblich bemerkbar machen kann, wenn die virtuellen Maschinen verteilte Aufgaben wahrnehmen. Eine direkte Kommunikation hätte diese Flaschenhälse nicht oder nicht in dem Ausmaß - eben wie beim internen/privaten virtuellen Switch.
Wenn keine direkte Kommunikation über den virtuellen Switch möglich ist, erfordert eine direkte Kommunikation die Anbindung der virtuellen Maschinen an einen zweiten virtuellen Switch (intern/privat), also jeweils dualhomed. Dualhomed bedeutet aber zugleich einen höheren Verwaltungsaufwand und möglicherweise Zweifelsfragen für die Netzwerkkonfiguration, weil die virtuellen Maschinen bei notwendiger Verbindung zum lokalen physischen Netzwerk zur gleichen Zeit in zwei Netzwerken miteinander verbunden sind.
Im Voraus schon vielen Dank für Euren Input
HansDampf06
mir geht es um eine Verständnisfrage zu den virtuellen Switchen des Hyper-V-Hosts, die ich anhand der verfügbaren Informationen (Hilfefunktion, Google etc.) für mich nicht abschließend beantworten kann. Im Kern geht es dabei um die direkte Kommunikation der virtuellen Maschinen untereinander und mit physischen Maschinen im (lokalen) Netzwerk.
Es soll für die Betrachtung folgende Situation gegeben sein: zwei virtuelle Maschinen (VM01, VM0), zwei physische Netzwerkkarten (NCA, NCB), zwei externe virtuelle Switche (VSwA (gebunden an NCA), VSwB (gebunden an NCB)), ein interner Switch (VSwC) und ein physische Switch (Cisco), mit dem die Netzwerkkarten verbunden sind.
Klar ist, dass der interne / private virtuelle Switch (nur) der direkten Kommunikation zwischen den virtuellen Maschinen dient (je nachdem, ob der HV-Host mit eingebunden ist (intern) oder nicht (privat)). In der gegebenen Situation:
VM01 <-> VSwC <-> VM02 [oder bei intern auch: VM01 (/VM02) <-> VSwC <-> HV-Host]
Genauso klar ist, dass der externe virtuelle Switch der Kommunikation mit dem physischen Netzwerk dient, indem dieser Switch an eine physische Netzwerkkarte gebunden wird, so dass die mit diesem Switch verbundenen virtuellen Maschinen über diese physische Netzwerkkarte mit dem lokalen Netzwerk etc. kommunizieren können. Ist der HV-Host beim externen Switch mitberechtigt, so kann auch er über die Netzwerkkarte mit dem lokalen Netzwerk etc. kommunizieren. Soweit alles wunderbar. In der gegebenen Situation gilt
VM01 <-> VSwA/VSwB <-> NCA/NCB <-> Cisco
VM02 <-> VSwA/VSwB <-> NCA/NCB <-> Cisco
Sind VM01 und VM02 NICHT am selben virtuellen Switch angebunden, muss die Kommunikation (zwingend) über den physischen Switch laufen, beispielsweise wie folgt:
VM01 <-> VSwA <-> NCA <-> Cisco <-> NCB <-> VSwB <-> VM02
Jetzt die Verständnisfrage: Wie sieht es aber aus, wenn beide virtuellen Maschinen am selben externen virtuellen Switch angebunden sind? Läuft dann die Kommunikation dennoch über den physischen Switch oder können sie unmittelbar über den externen virtuellen Switch, also ohne Umweg über den physischen Switch, miteinander kommunizieren? Also, ob
VM01 <-> VSwA <-> NCA <-> Cisco <-> NCA <-> VSwA <-> VM02
ODER
VM01 <-> VSwA <-> VM02
gilt?
Wünschenswert wäre natürlich letzteres, obschon ich bisher davon ausgehe, dass die Kommunikation über den physischen Switch erfolgt, auch wenn beide virtuelle Maschinen an demselben virtuellen Switch angebunden sind. Das ist natürlich ein deutlicher Umweg, der sich durch Latenz und beschränkte Bandbreite erheblich bemerkbar machen kann, wenn die virtuellen Maschinen verteilte Aufgaben wahrnehmen. Eine direkte Kommunikation hätte diese Flaschenhälse nicht oder nicht in dem Ausmaß - eben wie beim internen/privaten virtuellen Switch.
Wenn keine direkte Kommunikation über den virtuellen Switch möglich ist, erfordert eine direkte Kommunikation die Anbindung der virtuellen Maschinen an einen zweiten virtuellen Switch (intern/privat), also jeweils dualhomed. Dualhomed bedeutet aber zugleich einen höheren Verwaltungsaufwand und möglicherweise Zweifelsfragen für die Netzwerkkonfiguration, weil die virtuellen Maschinen bei notwendiger Verbindung zum lokalen physischen Netzwerk zur gleichen Zeit in zwei Netzwerken miteinander verbunden sind.
Im Voraus schon vielen Dank für Euren Input
HansDampf06
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 454930
Url: https://administrator.de/forum/hyper-v-virtueller-switch-454930.html
Ausgedruckt am: 31.03.2025 um 14:03 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
Teste a es aus indem du das Physikalische LAN-Patchkabel ziehst und gleichzeitig ein Ping im Dauermodus zwischen den beiden Servern betreibst (Ping IP -t)
Gruß,
Peter
Teste a es aus indem du das Physikalische LAN-Patchkabel ziehst und gleichzeitig ein Ping im Dauermodus zwischen den beiden Servern betreibst (Ping IP -t)
Gruß,
Peter
Ist der HV-Host beim externen Switch mitberechtigt
Sowas wie eine "Berechtigung" ist Blödsinn, denn solche Begrifflichkeiten kennt ein externer Switch nicht. Für den zählt einzig und allein nur ob das vom vSwitch bzw. ausgehender NIC empfangene Ethernet Paket eine IEEE 802.1q konforme VLAN Information trägt die der Switch auswerten kann (Tagged Paket) oder eben nicht (Untagged Paket). Und natürlich das das Paket eine gültige Mac Adresse hat die für seine Forwarding Table relevant ist.Was anderes gibt es da nicht.
Ob Microsoft intern sowas wie "Berechtigungen" auf vSwitches kennt mag sein. Rein Netzwerk technisch, was den L2 oder L3 Paket Transport anbetrifft, ist das aber vollommen irrelevant.
Zum Rest: Siehe oben... (Ping -t) Versuch macht klug !
Zitat von @aqui:
Ist der HV-Host beim externen Switch mitberechtigt
Sowas wie eine "Berechtigung" ist Blödsinn, .... Ob Microsoft intern sowas wie "Berechtigungen" auf vSwitches kennt ...Zur informativen Kenntnisnahme - im Hyper-V-Manager gibt es bei den Einstellungen für einen externen virtuellen Switch eine Checkbox mit folgendem Text: "Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen". Naja und das von mir verwendete Wort 'mitberechtigt' dürfte in diesem Zusammenhang ohne weiteres ein Synonym für 'zulassen' sein ...
Zitat von @Pjordorf:
Teste a es aus indem du das Physikalische LAN-Patchkabel ziehst und gleichzeitig ein Ping im Dauermodus zwischen den beiden Servern betreibst (Ping IP -t)
Teste a es aus indem du das Physikalische LAN-Patchkabel ziehst und gleichzeitig ein Ping im Dauermodus zwischen den beiden Servern betreibst (Ping IP -t)
Diesen Test kann ich leider erst Ende nächster Woche machen, weil ich erst dann wieder physischen Zugriff auf den Host habe. Daher hatte ich gehofft, dass jemand die Antwort auf meine Frage schon jetzt positiv weiß.
Ich hatte mir auch schon Gedanken darüber gemacht, ob ich es irgendwie austesten kann, insbesondere remote. Alle Ansätze wie Sniffer & Co. versprechen leider nicht, wirklich Licht ins Dunkel zu bringen - sollten die virtuellen Maschinen bei einem externen virtuellen Switch direkt kommunizieren, werden mit Sicherheit dennoch die Pakete über die Netzwerkkarte am physischen Switch sichtbar sein, so dass sich aus der Sichtbarkeit nichts ableiten ließe. Tracert liefert bei einem physischen Switch hinter der physischen Netzwerkkarte keinen Zwischenpunkt für den Übertragungsweg. Und dann wird es, abgesehen vom Ping, schon eng mit den in Betracht kommenden praktischen Ansätzen.
Auch für diesen Test mit dem Ping vermute ich ganz stark, dass mit dem Trennen des Netzwerkkabels zugleich an die virtuellen Maschinen signalisiert werden wird, sie seien nicht mehr mit dem Netzwerk verbunden - etwas anderes macht eigentlich auch keinen wirklichen Sinn. Dann funktioniert natürlich auch kein Ping. Aber in der Tat wird das Ausprobieren zeigen, ob diese Prognose zutreffend ist.
Sollte es jemand bereits wissen, dann bitte keine falsche Scheu!
Gruß
HansDampf06
Hallo,
Gruß,
Peter
Zitat von @HansDampf06:
Naja und das von mir verwendete Wort 'mitberechtigt' dürfte in diesem Zusammenhang ohne weiteres ein Synonym für 'zulassen' sein ...
Ungefähr so als wenn einer sagt du hast Kohle und ein anderer es sofort mit "Du bist Steinreich" gleichsetzt. Lies dich mal ein was dort mit zulassen gemeint ist. Das hat nichts, aber auch gar nichts mit Berechtigungen zu tun. Du verwechselst Äpfel und Birnen. Es fragt nur ob du mit diesen Adapter den Hyper-V Host verwalten willst. Manche Übersetzungen sind blöd mislungen Naja und das von mir verwendete Wort 'mitberechtigt' dürfte in diesem Zusammenhang ohne weiteres ein Synonym für 'zulassen' sein ...
Alle Ansätze wie Sniffer & Co. versprechen leider nicht, wirklich Licht ins Dunkel zu bringen
Denn die gehen von einer Physikalischen Schnittstelle ausTracert liefert bei einem physischen Switch hinter der physischen Netzwerkkarte keinen Zwischenpunkt für den Übertragungsweg.
Ist auch so gedacht. Und warum sollte jeder Switch der im wege ist sich melden? Chaos wäre PerfektAuch für diesen Test mit dem Ping vermute ich ganz stark, dass mit dem Trennen des Netzwerkkabels zugleich an die virtuellen Maschinen signalisiert werden wird, sie seien nicht mehr mit dem Netzwerk verbunden
Warum sollte der Virtuelle Switch dies der Virtuellen NIC der VM sagen? Die Virtuelle NIC ist immer noch mit den Virtuellen Switch Verbunden, nur ein Port nicht.Aber in der Tat wird das Ausprobieren zeigen, ob diese Prognose zutreffend ist.
Teste es aus, du liest zuviel Science Fiktion.Gruß,
Peter
Ich hatte schon überlegt, ob ich das "Stöckchen" (= mein Post von 22:04) hinhalte oder nicht - es war wegen der zu erwartenden "TROLLigkeit" einfach zu reizvoll. Aber, dass jemand ganz anderes darüber springt, als der, von dem ich es für möglich gehalten hätte, ändert nichts daran, dass es inhaltlich der erwarteten Reaktion entspricht ... Nämlich das Aufblähen einer für den verständigen Leser völlig belanglosen Wortwahl in Bezug auf die zu behandelnde Fragestellung, nur um sich am Thema vorbei mächtig "aufzuplustern" und "wichtiger" zu machen, als nötig. Landläufig wird so etwas als Nebenkriegsschauplatz bezeichnet.
Lieber @Pjordorf, ich könnte jetzt nach Herzenslust Deinen letzten Post in sprachlicher Hinsicht auseinandernehmen und Du würdest mir mit Sicherheit sukzessive weiteren Spaß liefern - schließlich ist das mein täglich Brot. Aber ich lasse es auf sich beruhen, denn auch ein gestandener Player aus Team "Level 5" kann nicht immer gewinnen und ich bedarf weder einer Machtdemonstration noch des sinnlosen Beiträge-Schruppens! Da weiß ich besseres zu tun!
Freilich steht es Dir frei, jetzt Deinen ganzen Frust, den Du von woher auch immer in Dir trägst, unter diesem Thema abzulassen. Nur werde ich weder auf Polemik noch auf sonstige neben dem Thema liegende Anmerkungen reagieren.
Zurück zum Thema und in der Sache selbst:
@Pjordorf
Wie bereits mitgeteilt, werde ich nächste Woche Deinen Ping-Vorschlag ausprobieren. Mein diesbezügliches Erwartungsbild habe ich bereits skizziert und nächste Woche wird die reale Praxis des Ausprobierens zeigen, ob sich dieses Erwartungsbild bestätigen wird.
Deine Annahme, das Trennen des Netzwerkkabels würde sich bei den virtuellen Maschinen nicht auswirken, würde nämlich voraussetzen, dass der Begriff 'Switch' beim 'externen virtuellen Switch' so zu verstehen ist, wie wir das von einem physischen Switch gewöhnt sind. Bei einem 'internen / privaten virtuellen Switch' mag das in der Tat vergleichbar sein. Aber bei einem 'externen virtuellen Switch' habe ich meine Zweifel, weshalb ich auch glaube, dass dort eine direkte Kommunikation zwischen den virtuellen Maschinen (Binnenkommunikation) nicht stattfindet - nur ich weiß es eben nicht positiv. Und dieses positives Wissen will ich HABEN.
Warum ich das glaube? Weil meinem Eindruck nach bei einem 'externen virtuellen Switch' der Begriff 'Switch' etwas irreführend ist - ein bekanntes Phänomen, wenn gebräuchliche Begriffe der leichteren Verständlichkeit wegen für etwas verwendet werden, auf das sie nicht vollständig passen. Richtig mag zwar sein, dass mehrere virtuelle Maschinen an diesen Switch angeschlossen werden können und sich dadurch die physische Netzwerkkarte - vergleichbar mit dem Uplink eines physischen Switches - teilen. Aber wie das 'Zulassen' des Verwaltungsbetriebssystems zeigt, geht es wohl vornehmlich um eine gemeinsame / geteilte Nutzung der Netzwerkkarte in Bezug auf das angeschlossene physische Netzwerk, also die Außenkommunikation, und zwar in gewisser Weise nebeneinander. Eine Binnenkommunikation ist allem Anschein nach gar nicht die Zielrichtung dieses Switches, worauf gerade die Auslegung des oben zitierten Checkbox-Textes betreffend das 'Zulassen' hindeutet. Andernfalls müsste dieser Text eigentlich zugleich einen Hinweis auf die Möglichkeit der Kommunikation des Verwaltungsbetriebssystems mit den virtuellen Maschinen über diesen Switch (gleichsam dem 'internen virtuellen Switch') enthalten - daran fehlt es. Und so lässt der Vergleich der Variante 'extern' mit der Variante 'intern' berechtigterweise durchaus den Schluss zu, dass die Variante 'extern' nicht der Binnenkommunikation dient. Hinzukommt der Fakt, dass es diese beiden Varianten gibt, obschon doch eine Variante ausreichen würde, der im Bedarfsfall eben noch eine physische Netzwerkkarte gleichsam einem Uplink zugeordnet werden kann, um neben der Binnen- auch eine Außenkommunikation realisieren zu können. Das wäre dann ein wahrlich virtueller Switch, wie wir es von einem physischen Switch gewöhnt sind.
Und das alles will ich nicht nur mutmaßen, sondern SICHER wissen - ob Binnenkommunikation über den 'externen virtuellen Switch' oder eben nicht!
Gute Nacht!
Lieber @Pjordorf, ich könnte jetzt nach Herzenslust Deinen letzten Post in sprachlicher Hinsicht auseinandernehmen und Du würdest mir mit Sicherheit sukzessive weiteren Spaß liefern - schließlich ist das mein täglich Brot. Aber ich lasse es auf sich beruhen, denn auch ein gestandener Player aus Team "Level 5" kann nicht immer gewinnen und ich bedarf weder einer Machtdemonstration noch des sinnlosen Beiträge-Schruppens! Da weiß ich besseres zu tun!
Freilich steht es Dir frei, jetzt Deinen ganzen Frust, den Du von woher auch immer in Dir trägst, unter diesem Thema abzulassen. Nur werde ich weder auf Polemik noch auf sonstige neben dem Thema liegende Anmerkungen reagieren.
Zurück zum Thema und in der Sache selbst:
@Pjordorf
Wie bereits mitgeteilt, werde ich nächste Woche Deinen Ping-Vorschlag ausprobieren. Mein diesbezügliches Erwartungsbild habe ich bereits skizziert und nächste Woche wird die reale Praxis des Ausprobierens zeigen, ob sich dieses Erwartungsbild bestätigen wird.
Deine Annahme, das Trennen des Netzwerkkabels würde sich bei den virtuellen Maschinen nicht auswirken, würde nämlich voraussetzen, dass der Begriff 'Switch' beim 'externen virtuellen Switch' so zu verstehen ist, wie wir das von einem physischen Switch gewöhnt sind. Bei einem 'internen / privaten virtuellen Switch' mag das in der Tat vergleichbar sein. Aber bei einem 'externen virtuellen Switch' habe ich meine Zweifel, weshalb ich auch glaube, dass dort eine direkte Kommunikation zwischen den virtuellen Maschinen (Binnenkommunikation) nicht stattfindet - nur ich weiß es eben nicht positiv. Und dieses positives Wissen will ich HABEN.
Warum ich das glaube? Weil meinem Eindruck nach bei einem 'externen virtuellen Switch' der Begriff 'Switch' etwas irreführend ist - ein bekanntes Phänomen, wenn gebräuchliche Begriffe der leichteren Verständlichkeit wegen für etwas verwendet werden, auf das sie nicht vollständig passen. Richtig mag zwar sein, dass mehrere virtuelle Maschinen an diesen Switch angeschlossen werden können und sich dadurch die physische Netzwerkkarte - vergleichbar mit dem Uplink eines physischen Switches - teilen. Aber wie das 'Zulassen' des Verwaltungsbetriebssystems zeigt, geht es wohl vornehmlich um eine gemeinsame / geteilte Nutzung der Netzwerkkarte in Bezug auf das angeschlossene physische Netzwerk, also die Außenkommunikation, und zwar in gewisser Weise nebeneinander. Eine Binnenkommunikation ist allem Anschein nach gar nicht die Zielrichtung dieses Switches, worauf gerade die Auslegung des oben zitierten Checkbox-Textes betreffend das 'Zulassen' hindeutet. Andernfalls müsste dieser Text eigentlich zugleich einen Hinweis auf die Möglichkeit der Kommunikation des Verwaltungsbetriebssystems mit den virtuellen Maschinen über diesen Switch (gleichsam dem 'internen virtuellen Switch') enthalten - daran fehlt es. Und so lässt der Vergleich der Variante 'extern' mit der Variante 'intern' berechtigterweise durchaus den Schluss zu, dass die Variante 'extern' nicht der Binnenkommunikation dient. Hinzukommt der Fakt, dass es diese beiden Varianten gibt, obschon doch eine Variante ausreichen würde, der im Bedarfsfall eben noch eine physische Netzwerkkarte gleichsam einem Uplink zugeordnet werden kann, um neben der Binnen- auch eine Außenkommunikation realisieren zu können. Das wäre dann ein wahrlich virtueller Switch, wie wir es von einem physischen Switch gewöhnt sind.
Und das alles will ich nicht nur mutmaßen, sondern SICHER wissen - ob Binnenkommunikation über den 'externen virtuellen Switch' oder eben nicht!
Gute Nacht!
Naja und das von mir verwendete Wort 'mitberechtigt' dürfte in diesem Zusammenhang ohne weiteres ein Synonym für 'zulassen' sein ...
Hat aber ja, wie schon vermutet, nur rein etwas mit dem Winblows OS intern und (vermutlich) Zugriffsrechten für die Konfig zu tun !Rein Netzwerk technisch ist das also völlig irrelevant und spielt für das Forwarding der Ethernet Frames an sich keinerlei Rolle aus rein technischer Sicht.
Dort bestimmt einzig das IEEE 802.1q Tagging oder Nicht Tagging was mit dem Frame gemacht wird im Switch. Das gilt für den vSwitch wie für den physischen Switch.
Hallo,
Gruß,
Peter
Zitat von @HansDampf06:
Deine Annahme, das Trennen des Netzwerkkabels würde sich bei den virtuellen Maschinen nicht auswirken, würde nämlich voraussetzen,
Das ich das so dargestellt habe. Ich sagte nur das ein entfernen des Patchkabels nicht an weitere Clients oder what so ever gemeldet wird. Wie bei einen externen (Der ist dann Physikalisch vorhanden) Switch wird das ziehen eines Patchkabels bzw. das entfernen nicht an Geräte an anderen Ports gemeldet. Das dann evt. keine Kommunikation mehr gegeben ist iegt in der Natur der SacheDeine Annahme, das Trennen des Netzwerkkabels würde sich bei den virtuellen Maschinen nicht auswirken, würde nämlich voraussetzen,
dass der Begriff 'Switch' beim 'externen virtuellen Switch' so zu verstehen ist,
Erkläre deinen "externen virtuellen Switch". Was soll das sein. Kann den jeder Kaufen?ob Binnenkommunikation über den 'externen virtuellen Switch' oder eben nicht!
Ist mir zuviel Binnenkommunikation hier im BinnengewässerGruß,
Peter
Zitat von @Pjordorf:
dass der Begriff 'Switch' beim 'externen virtuellen Switch' so zu verstehen ist,
Erkläre deinen "externen virtuellen Switch". Was soll das sein. Kann den jeder Kaufen?ob Binnenkommunikation über den 'externen virtuellen Switch' oder eben nicht!
Ist mir zuviel Binnenkommunikation hier im BinnengewässerIch beschränke mich darauf, auf den Hyper-V-Manager und auf die von Microsoft verwendete Terminologie zu verweisen: Rechtsseitige Auswahlleiste "Aktionen", Unterpunkt "Manager für virtuelle Switches..." -> [bitte einmal mit der linken Maustaste darauf klicken] -> im nun geöffneten Fenster linksseitig den obersten Punkt "Neuer virtueller Netzwerkswitch" und dann rechtsseitig die Wahl zwischen "Extern", "Intern" oder "Privat" treffen.
Conclusio: Hast Du Dich jemals schon mit Hyper-V und dessen Konfiguration befasst? Deine Entäußerungen begründen erhebliche Zweifel. Aber das ist nicht meine Baustelle ...
MfG HansDampf06
Zitat von @aqui:
nur rein etwas mit ... die Konfig zu tun !
Rein Netzwerk technisch ist das also völlig irrelevant und spielt für das Forwarding der Ethernet Frames an sich keinerlei Rolle aus rein technischer Sicht.
nur rein etwas mit ... die Konfig zu tun !
Rein Netzwerk technisch ist das also völlig irrelevant und spielt für das Forwarding der Ethernet Frames an sich keinerlei Rolle aus rein technischer Sicht.
Da sind wir ganz einer Meinung.
Übrigens bekommt jede eingerichtete virtuelle Netzwerkkarte eine eigene - dynamisch oder manuell konfigurierte - MAC, so dass der Transport der Frames netzwerktechnisch letztlich unproblematisch sein dürfte ... Jedenfalls muss ich mich so lange, wie es keine Probleme gibt, nicht weiter darum kümmern - mache ich bei physischen Netzwerkkarten nach ihrer Einrichtung ja auch nicht, wenn es nicht aus irgendeinem Grund erforderlich erscheint.
Indes hilft nach meinem Dafürhalten diese Betrachtung der netzwerktechnischen Behandlung von Frames bei meiner Frage nicht weiter. Offen und gänzlich unbehandelt bleibt dabei nämlich: 1. routet dieser 'externe virtuelle Switch' ausschließlich von der jeweiligen virtuellen Netzwerkkarte über die physische Netzwerkkarte nach außen und umgekehrt (= das ist meine derzeitige Annahme) ODER 2. routet dieser Switch zugleich zwischen den virtuellen Netzwerkkarten, die mit ihm verbunden sind (= das will ich wissen, ob ja oder nein).
Wenn die Antwort auf diese Frage keiner weiß, bleibt eben nur das Ausprobieren in der Hoffnung, dadurch eine eindeutige Antwort zu finden ...
MfG HansDampf06
und auf die von Microsoft verwendete Terminologie zu verweisen:
Und die ist ja bekanntermaßen etwas Netzwerk fremd bei Microsoft. Mit Vernetzung haben die das ja bekanntermaßen nicht so, folglich sind auch deren verwendete Termini sachlich oft falsch und führen zu Verwirrung. Das sollte man immer im Hinterkopf haben wenn Netzwerker mit (Winblows) Server Admins reden ! 
diese Betrachtung der netzwerktechnischen Behandlung von Frames bei meiner Frage nicht weiter.
Dann ist man als Netzwerker natürlich raus ! Das ist dann eine rein Winblows interne Sache dann....Allerdings das ein interner vSwitch "routet" also Layer 3 Funktionalitäten hat kann man wohl sicher ausschliessen. Keiner der Hypervisor Hersteller hat L3 fähige vSwitches im Portfolio. Wäre auf einem Hypervisor auch Unsinn.
Routing im Sinne von IP Routing ist das ganz sicher nicht. Aber vermutlich meinst du hier Mac Forwarding bzw. die Mac Forwarding Datenbank des vSwitches ?!
Aber egal...das ist rein ne Microsoft Sache dann...
