10
Wie am besten? Server mit mehreren VLANs verbinden, oder Routen lassen?
Hallo zusammen,
mal eine allgemeine Verständnis-Frage wie man so etwas am besten und effizientesten löst:
Gegeben sei ein HyperV Server welcher 2 VMs hat: Einen DC und einen Applikations/File-Server. Der HyperV-Host hat 2 Physikalische Netzwerkkarten, beide sind als SET-Team eingerichtet. Diesem vSwitch ist eine Management vEthernet Karte zugewiesen um eben auf den Host selber auch darauf zuzugreifen für Management. Die Beiden Netzwerkkarten sind an einem Layer 2 Switch angeschlossen.
An diesem Switch hängen mehrere lokale Subnetze, jedes hat sein eigenes VLAN.
Netz A ist VLAN ID10
Netz B ist VLAN ID 20
Netz C ist VLAN ID 30
Netz A ist das Verwaltung Netz und darf auf den DC und Applikationsserver zugreifen. Also haben diese beiden VMs jeweils eine vNIC zugeordnet, welche die VLAN ID 10 hat - damit können alle Clients im Netzwerk A wunderbar mit den Servern arbeiten.
Jetzt gibt es aber Geräte im Netzwerk B welche auch auf ganz bestimmte Dienste auf den Applikations-Server drauf sollen, z..B. auf ein Webservice der da läuft auf Port 8090.
Auch Geräte im Netzwerk C sollen auf den Applikations-Server, via sFTP über Port 22. Wobei aber vom Netzwerk C nicht alle Geräte dahin dürfen, sondern nur bestimmte, also entweder auf MAC-Adress-ebene filtern, oder stumpf auf IP-Adress-ebene Filtern.
Wie macht man sowas jetzt am besten?
1. Dem Applikations-Server weitere vNICs zuordnen welche jeweils im VLAN 20 und VLAN 30 hängen und über die Windows-Firewall nur bestimmte eingehende IP Adressen gestatten darauf zuzugreifen?
2. oder einen Router an den Layer2 Switch mit dran hängen welcher auch als Gateway dient für alle Subnetze, also an allen VLANs hängt und darauf via Polciy based Routing arbeiten,
3. oder auf dem Hyper-V eine Routing-VM installieren (Welche da aber die einfach und nicht zu aufgebläht ist) um den Traffic direkt über den vSwitch abzufangen?
4. oder einen dicken Switch besorgen, worüber man solche entsprechenden Routing-Regeln einstellen kann - aber fungiert er dann noch als Switch wenn man nichts weiter konfiguriert außer eben die Mac Adressen doder IP Adressen der Endgeräte um zu sagen wer mit wem sprechen darf?
Variante 1 ist ja das einfachste, und hätte den voreilt, dass man den Gateway Eintrag der Endgeräte nicht anpassen muss, aber ich denke mal das ist dennoch die ungünstigste variante weil ein Server mit mehreren IP Adressen wird sicherlich hier und da probleme machen
Wie macht man so etwas am besten, bzw. was gibt es da an Switchen oder Routing-VMs um sowas einfach und elegant und ohne Flaschenhals umzusetzen, was auch in deutlich größeren Netzwerken mit deutlich mehr Subnetzen sauber funktioniert?
mal eine allgemeine Verständnis-Frage wie man so etwas am besten und effizientesten löst:
Gegeben sei ein HyperV Server welcher 2 VMs hat: Einen DC und einen Applikations/File-Server. Der HyperV-Host hat 2 Physikalische Netzwerkkarten, beide sind als SET-Team eingerichtet. Diesem vSwitch ist eine Management vEthernet Karte zugewiesen um eben auf den Host selber auch darauf zuzugreifen für Management. Die Beiden Netzwerkkarten sind an einem Layer 2 Switch angeschlossen.
An diesem Switch hängen mehrere lokale Subnetze, jedes hat sein eigenes VLAN.
Netz A ist VLAN ID10
Netz B ist VLAN ID 20
Netz C ist VLAN ID 30
Netz A ist das Verwaltung Netz und darf auf den DC und Applikationsserver zugreifen. Also haben diese beiden VMs jeweils eine vNIC zugeordnet, welche die VLAN ID 10 hat - damit können alle Clients im Netzwerk A wunderbar mit den Servern arbeiten.
Jetzt gibt es aber Geräte im Netzwerk B welche auch auf ganz bestimmte Dienste auf den Applikations-Server drauf sollen, z..B. auf ein Webservice der da läuft auf Port 8090.
Auch Geräte im Netzwerk C sollen auf den Applikations-Server, via sFTP über Port 22. Wobei aber vom Netzwerk C nicht alle Geräte dahin dürfen, sondern nur bestimmte, also entweder auf MAC-Adress-ebene filtern, oder stumpf auf IP-Adress-ebene Filtern.
Wie macht man sowas jetzt am besten?
1. Dem Applikations-Server weitere vNICs zuordnen welche jeweils im VLAN 20 und VLAN 30 hängen und über die Windows-Firewall nur bestimmte eingehende IP Adressen gestatten darauf zuzugreifen?
2. oder einen Router an den Layer2 Switch mit dran hängen welcher auch als Gateway dient für alle Subnetze, also an allen VLANs hängt und darauf via Polciy based Routing arbeiten,
3. oder auf dem Hyper-V eine Routing-VM installieren (Welche da aber die einfach und nicht zu aufgebläht ist) um den Traffic direkt über den vSwitch abzufangen?
4. oder einen dicken Switch besorgen, worüber man solche entsprechenden Routing-Regeln einstellen kann - aber fungiert er dann noch als Switch wenn man nichts weiter konfiguriert außer eben die Mac Adressen doder IP Adressen der Endgeräte um zu sagen wer mit wem sprechen darf?
Variante 1 ist ja das einfachste, und hätte den voreilt, dass man den Gateway Eintrag der Endgeräte nicht anpassen muss, aber ich denke mal das ist dennoch die ungünstigste variante weil ein Server mit mehreren IP Adressen wird sicherlich hier und da probleme machen
Wie macht man so etwas am besten, bzw. was gibt es da an Switchen oder Routing-VMs um sowas einfach und elegant und ohne Flaschenhals umzusetzen, was auch in deutlich größeren Netzwerken mit deutlich mehr Subnetzen sauber funktioniert?
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-ID: 669775
Url: https://administrator.de/contentid/669775
Printed on: December 5, 2024 at 15:12 o'clock
10 Comments
Latest comment
Eigentlich eine klassische Bilderbuch Firewall oder Accesslisten Anwendung...
Die eigentliche, zentrale Frage die du gar nicht beantwortet hast ist ob es und wenn ja welche Security Policy denn besteht diese VMs bzw. Server zu schützen? Davon hängt doch alles andere ab.
Variante 1 ist sicher die schlechteste Option wenn es darum geht Zugriffe zu reglementieren. Normalerweise macht das eine zentrale L3 Instanz wo diese Sicherheitspolicies umgesetzt werden.
Jeder popelige Layer 3 VLAN Switch von der Stange oder jede beliebige Firewall wie z.B. OPNsense oder pfSense usw. kann so etwas technisch umsetzen.
Vorteil1: Schnelles Forwarding in Wirespeed. Nachteil1: L3 ACLs auf Switches sind nicht stateful.
Vorteil2: Sehr granulare Regeln bzw. Policies die stateful sind. Nachteil2: Kein Wirespeed bzw. abhängig von der Anbindung.
Diese 2 klassischen und einfachen Design Szenarien beschreiben 2 hiesige Forenthreads:
Layer 2 Lösung mit bestehendem Switch und ext. Router o. Firewall
Layer 3 VLAN Switch Lösung mit ACL
Lesen und verstehen...
Ob man bei Lösung 1 die L3 Instanz als bare Metal oder VM betreibt ist dabei egal. Beispiele für VMs findest du hier und hier. Das kann man sogar im laufenden Betrieb parallel aufsetzen und testen.
Nebenbei: Policy "Routing" ist für so ein simples Szenario nicht erforderlich! Hier machst du vermutlich einen Denkfehler. Simple Firewall Regeln oder ACLs reichen dafür vollauf.
Die eigentliche, zentrale Frage die du gar nicht beantwortet hast ist ob es und wenn ja welche Security Policy denn besteht diese VMs bzw. Server zu schützen? Davon hängt doch alles andere ab.
Variante 1 ist sicher die schlechteste Option wenn es darum geht Zugriffe zu reglementieren. Normalerweise macht das eine zentrale L3 Instanz wo diese Sicherheitspolicies umgesetzt werden.
Jeder popelige Layer 3 VLAN Switch von der Stange oder jede beliebige Firewall wie z.B. OPNsense oder pfSense usw. kann so etwas technisch umsetzen.
Vorteil1: Schnelles Forwarding in Wirespeed. Nachteil1: L3 ACLs auf Switches sind nicht stateful.
Vorteil2: Sehr granulare Regeln bzw. Policies die stateful sind. Nachteil2: Kein Wirespeed bzw. abhängig von der Anbindung.
Diese 2 klassischen und einfachen Design Szenarien beschreiben 2 hiesige Forenthreads:
Layer 2 Lösung mit bestehendem Switch und ext. Router o. Firewall
Layer 3 VLAN Switch Lösung mit ACL
Lesen und verstehen...
Ob man bei Lösung 1 die L3 Instanz als bare Metal oder VM betreibt ist dabei egal. Beispiele für VMs findest du hier und hier. Das kann man sogar im laufenden Betrieb parallel aufsetzen und testen.
Nebenbei: Policy "Routing" ist für so ein simples Szenario nicht erforderlich! Hier machst du vermutlich einen Denkfehler. Simple Firewall Regeln oder ACLs reichen dafür vollauf.
1
Ich verstehe noch nicht ganz den Ist-Zustand. Die drei Netze gibt es schon, richtig? Wie arbeiten die den bisher, völlig getrennt? Was ist denn aktuell das Gateway?
1
Der Ist-zustand ist aktuell Variante 2 aber ich denke das ist auf dauer so auch nicht gut, weil alles erst über den Switch läuft, der Schiebt es weiter zum Router, der macht das umsetzen in ein anderes Netz, gibt es weiter zum Switch, der gibts weiter zum Server, und den ganzen weg muss das ganze wieder zurück. Das kostet doch unnötig zeit und Latenzen und Traffic was man sicherlich optimaler lösen kann.
Was genau ist mit Security Policy gemeint? es soll halt so sein, dass nichts vom Netzwerk A ins Netzwerk B oder C soll (von den Clients und anderem Server im Netzwerk A) - außer eben genau das, was via Regelwerk gesagt wurde, also dass z.B. die eine bestimmte IP aus Netzwerk B, Richtung IP Netzwerk A (Applikations-Server) nur über diesen einen Port zugreifen darf.
Das läuft aktuell über eine Securepoint UTM, also ähnlich wie eine Sophos oder was es da so gibt.
Angenommen der Applikations-Server im Netz A/VLAN10 hat die IP: 192.168.10.10
Der Client aus Netzwerk B/VLAN20 hat die IP 192.168.20.5
die Firewall hat an einem Netzwerkanschluss mehrere VLANs zugeordnet, die Zonen. Jeder Client der der in einer Regel auftauchen soll wird als Host-Objekt mit seiner IP in der jeweiligen Zone angelegt.
Dann reicht eine einzelne Regel zu um z.B. einen Ping abzusetzen und zurück zu bekommen:
Quelle: Client (192.168.20.5, Zone VLAN20), Ziel: AppServer (192.168.10.10, Zone VLAN10), Dienst: ICMP Echo-Req
damit kann ich vom Client-PC mit seiner IP 192.168.20.5 direkt die 192.168.10.10 anpingen (sofern da die Windows-Firewall zustimmt) und erhalte auch sauber einen ping zurück. Natürlich ist der Router in seinem jeweiligen VLAN als Gateway bei den Clients hinterlegt.
Das funktioniert so schon sehr gut, aber ich habe so das gefühl, dass es nicht richtig ist die UTM für sowas zu verwenden, eben weil die Pakete mehrere wege nehmen müssen, was sicherlich nochweniger gut ist, wenn mehrere Clients auf verschiedenen Servern riesige Dateien verschieben mit zich Gigabyte größe, und das ganze über eine einzelne 10G Schnittstelle der UTM...
Klar, gibt auch größere UTMs vo denen, wo ich auch mit mehreren Schnittstellen auf den Switch gehen könnte, aber ich weiß halt nicht, ob das ganze "gut" ist es so zu betreiben - auch wenn es gut funktioniert und ich mich mitlerweile recht gut eingefuchst habe wie da was zu konfigurieren ist.
dachte bisher, dass Policy Based Routing genau sowas ist, also welche IP über welchen Port wohin darf (optional noch via HIDENAT oder DESTNAT).
Mit dem Begriff Statefull oder Stateless (diese Einstellung gibt es auch auf der UTM) kann ich leider nix anfangen was damit gemeint ist
Was genau ist mit Security Policy gemeint? es soll halt so sein, dass nichts vom Netzwerk A ins Netzwerk B oder C soll (von den Clients und anderem Server im Netzwerk A) - außer eben genau das, was via Regelwerk gesagt wurde, also dass z.B. die eine bestimmte IP aus Netzwerk B, Richtung IP Netzwerk A (Applikations-Server) nur über diesen einen Port zugreifen darf.
Das läuft aktuell über eine Securepoint UTM, also ähnlich wie eine Sophos oder was es da so gibt.
Angenommen der Applikations-Server im Netz A/VLAN10 hat die IP: 192.168.10.10
Der Client aus Netzwerk B/VLAN20 hat die IP 192.168.20.5
die Firewall hat an einem Netzwerkanschluss mehrere VLANs zugeordnet, die Zonen. Jeder Client der der in einer Regel auftauchen soll wird als Host-Objekt mit seiner IP in der jeweiligen Zone angelegt.
Dann reicht eine einzelne Regel zu um z.B. einen Ping abzusetzen und zurück zu bekommen:
Quelle: Client (192.168.20.5, Zone VLAN20), Ziel: AppServer (192.168.10.10, Zone VLAN10), Dienst: ICMP Echo-Req
damit kann ich vom Client-PC mit seiner IP 192.168.20.5 direkt die 192.168.10.10 anpingen (sofern da die Windows-Firewall zustimmt) und erhalte auch sauber einen ping zurück. Natürlich ist der Router in seinem jeweiligen VLAN als Gateway bei den Clients hinterlegt.
Das funktioniert so schon sehr gut, aber ich habe so das gefühl, dass es nicht richtig ist die UTM für sowas zu verwenden, eben weil die Pakete mehrere wege nehmen müssen, was sicherlich nochweniger gut ist, wenn mehrere Clients auf verschiedenen Servern riesige Dateien verschieben mit zich Gigabyte größe, und das ganze über eine einzelne 10G Schnittstelle der UTM...
Klar, gibt auch größere UTMs vo denen, wo ich auch mit mehreren Schnittstellen auf den Switch gehen könnte, aber ich weiß halt nicht, ob das ganze "gut" ist es so zu betreiben - auch wenn es gut funktioniert und ich mich mitlerweile recht gut eingefuchst habe wie da was zu konfigurieren ist.
dachte bisher, dass Policy Based Routing genau sowas ist, also welche IP über welchen Port wohin darf (optional noch via HIDENAT oder DESTNAT).
Mit dem Begriff Statefull oder Stateless (diese Einstellung gibt es auch auf der UTM) kann ich leider nix anfangen was damit gemeint ist
Was genau ist mit Security Policy gemeint?
In jeder auf Datensicherheit bedachten Firma gibt es festgelegete Security Regeln nach denen Netzwerk Segmentierungen und Zugriffe geregelt sind und die es entsprechend dazu konform umzusetzen gilt. Ist ja schon seit Jahrzehnten so. was man sicherlich optimaler lösen kann.
Richtig! Dann eben einen Trunk mit hoher Link Speed oder statt eines VLAN Trunks dedizierte Links in die entsprechenden VLANs. Oder eben gleich die L3 VLAN Switch Lösung die das alles in Silizum und Wirespeed macht. Wenn du dann mit nicht stateful ACLs leben kannst ist alles gut.Das läuft aktuell über eine Securepoint UTM
Ist doch ideal, dann hast du ja also schon die Hardware um zumindestens Lösung 1 problemlos umzusetzen.Dann reicht eine einzelne Regel zu um z.B. einen Ping abzusetzen und zurück zu bekommen:
Jepp bingo! So einfach ist das Ganze! dass es nicht richtig ist die UTM für sowas zu verwenden, eben weil die Pakete mehrere Wege nehmen müssen
Das ist ja üblich so bei einem IP Routing. Vielleicht fehlen dir dazu noch die jeweiligen Grundlagen?! Mit moderner Hardware ist es heute (fast) egal ob du eine Layer 2 Forwarding auf Mac Adressbasis machst oder das gleiche auf IP Basis.wenn mehrere Clients auf verschiedenen Servern riesige Dateien verschieben mit zich GIgabyte größe, und das ganze über eine einzelne 10G Schnittstelle der UTM...
So pauschal gesagt ohne das genaue Design deines Restnetzwerkes zu kennen kann man das nicht sagen. Wenn die Clients mit den üblichen 1Gig angebunden sind könnten dies zu mindestens 10 dieser Clients gleichzeitig in Wirespeed erledigen.Sollten es mehr sein löst man das idealerweise mit einem üblichen LACP LAG und Link Aggregation um die Last entsprechend zu minimieren. Bei mit Trunk angebundenen L3 Devices ist das eh üblicher Standard. Reicht das nicht, nimmt man einem L3 Switch der diese Limits nicht kennt.
Es kommt also, wie immer, auf die jeweiligen Anforderungen und die Infrastruktur drauf an was du als gestandener Informatiker ja auch sicher selber weisst.
2
Oh, also meinst du, dass die Securepoint UTM schon ganz gut für sowas gedacht ist? Klar könnte ich auch mit mehreren Links auf den Switch gehen, aber ich hab so meine bedenken, dass wenn eben zich tausende Anfragen aus verschiedenen Netzen ein einzelnes Physikalisches Interface was eben in mehreren VLAN steht, schnell überlasten kann?
LACP mit aktuellen Windows Hyper-V Servern wird ja nicht mehr sogern gesehen/genutzt, zumindest scheint MS das so zu wollen, wenn die ihre sache mit dem SET vSwitch so pushen...
LACP von Switch zu UTM geht natürlich...aber ich hab immer bammel, dass die CPU so einer UTM schnell überlastet sein könnte und dann nix mehr geht, oder gar pakete verworfen werden.
Kenne das ja von Windows Systemen die eine 10G Karte drin haben. Wenn die CPU nicht stark genug ist, erreicht man nichtmal 10G bei einem Single-File-Stream (RSS und VMQ hilft ja nur bei vielen gleichzeitigen anfragen um die Last auf mehrere CPU-Kerne zu verteilen)
LACP mit aktuellen Windows Hyper-V Servern wird ja nicht mehr sogern gesehen/genutzt, zumindest scheint MS das so zu wollen, wenn die ihre sache mit dem SET vSwitch so pushen...
LACP von Switch zu UTM geht natürlich...aber ich hab immer bammel, dass die CPU so einer UTM schnell überlastet sein könnte und dann nix mehr geht, oder gar pakete verworfen werden.
Kenne das ja von Windows Systemen die eine 10G Karte drin haben. Wenn die CPU nicht stark genug ist, erreicht man nichtmal 10G bei einem Single-File-Stream (RSS und VMQ hilft ja nur bei vielen gleichzeitigen anfragen um die Last auf mehrere CPU-Kerne zu verteilen)
Also dein Ist-Zustand ist "Router-on-a-Stick" (keine Sorge, den Begriff habe ich auch erst spät gelernt und finde ihn scheußlich) mit einer UTM zwischen den Netzen. Das kann man machen und das muss nicht mal schlecht sein. Ich habe das auch so gemacht, weil mir das am ehesten liegt. Für mich besteht der Vorteil in der einheitlichen Administration, ich kann alles in meiner Sophos UTM regeln, der Switch übernimmt keinerlei Routing.
Ich habe aktuell exakt eine Ausnahme, der Datensicherungsserver hängt mit einem Bein im Management-Netz der ESXi. Der Grund dürfte klar sein. Ansonsten habe ich nur wenig Daten, die zwischen den Netzen verkehren (RDP Sessions, Druckaufträge). VoIP ist noch nicht ganz sauber gelöst, die Telefonie hängt im Client Netz. Die Entscheidung ist an irgendeinem Punkt bewusst gefallen, das erstmal so zu machen.
Von welchen Datenmengen reden wir denn bei dir? Bei mir ist der größte Nachteil nicht die Geschwindigkeit oder die Auslastung der UTM sondern der Single Point of Failure. Meine UTM Hardware habe ich doppelt, es gibt aber keinen automatischen Failover.
PS: Konsequent betrachtet muss der Traffic auch immer erst zum Hardware-Switch. Wenn also der "kürzeste Weg" das Ziel ist, dürfte der Traffic bei mir nicht mal den Hypervisor verlassen.
Ich habe aktuell exakt eine Ausnahme, der Datensicherungsserver hängt mit einem Bein im Management-Netz der ESXi. Der Grund dürfte klar sein. Ansonsten habe ich nur wenig Daten, die zwischen den Netzen verkehren (RDP Sessions, Druckaufträge). VoIP ist noch nicht ganz sauber gelöst, die Telefonie hängt im Client Netz. Die Entscheidung ist an irgendeinem Punkt bewusst gefallen, das erstmal so zu machen.
Von welchen Datenmengen reden wir denn bei dir? Bei mir ist der größte Nachteil nicht die Geschwindigkeit oder die Auslastung der UTM sondern der Single Point of Failure. Meine UTM Hardware habe ich doppelt, es gibt aber keinen automatischen Failover.
PS: Konsequent betrachtet muss der Traffic auch immer erst zum Hardware-Switch. Wenn also der "kürzeste Weg" das Ziel ist, dürfte der Traffic bei mir nicht mal den Hypervisor verlassen.
Ja SinglePointOfFailure ist klar - da haben wir die utm auch in doppelter Ausführung da, bekommt ab und eine aktuelle konfig drauf und wird wieder beiseite gelegt. Ein paar Stunden Totalausfall ist auch nicht so wild, also es muss in diesem Fall nichts super hochredundant sein.
Große datenstreams gibt es nicht, aber halt sehr viele Maschinen welche Datenbanken füllen, also viele kleine Daten...
Große datenstreams gibt es nicht, aber halt sehr viele Maschinen welche Datenbanken füllen, also viele kleine Daten...
dass wenn eben zich tausende Anfragen aus verschiedenen Netzen ein einzelnes Physikalisches Interface was eben in mehreren VLAN steht, schnell überlasten kann?
Kommt eben drauf an wieviel diese "zich tausende Anfragen" dann als kumulierte Bandbreite letztendlich bedeuten und was das Datenblatt der UTM als L3 Maximaldurchsatz vorgibt??In der IT ist Raten und Angst haben immer sehr schlecht. Besser du arbeitetst mit Fakten dann muss man auch keine Angst haben. Als gestandener Informatiker kennt man aber solche Allerwelts Binsenweisheiten.
LACP mit aktuellen Windows Hyper-V Servern wird ja nicht mehr sogern gesehen/genutzt
Das hast du dann gründlich missverstanden! Es ging mitnichten um den Server sondern die UTM die dann mit einem LACP LAG an den Switch angebunden wird zur Lastverteilung!!Das mit deinen 10Gig Ängsten ist auch unsinnig wenn man entsprechende NICs hat die Offloading usw. supporten. Nur bei Billokarten muss die CPU das Packet Assembling Disassembling handeln aber als verantwortungsvoller Netzwerker baut man so einen Kram auch nicht gerade in einen Server.
Das dazu noch deutlich andere Problematiken besonders bei Winblows kommen hat aber nix mit der Karte oder Netzinfrastruktur selber zu tun. Siehe die zahllosen Threads zu der Thematik von @MysticFoxDE hier im Forum die das belegen.
Große datenstreams gibt es nicht
Dann bist du doch mit der UTM gut gerüstet und musst nur mal machen... Oder du nimmst Geld in die Hand und beschaffst einen performanten Layer 3 VLAN Core Switch. Idealerweise als Full Stack so das du LAGs auch noch redundant anbinden kannst.
Klassische 08/15 Designs dazu kennst du ja sicher zu Genüge...?!
1
@aqui, ich wollt nur mal Danke sagen dass du dein Fachwissen hier auch weitergibst und dir vorallem die Zeit dazu nimmst auch einem DAU wie mich etwas zu erleuchten (auch wenn du sicherlich bei einigen Fragen genervt mit den Augen rollst :D ), danke dir Trotzdem 
Gut dann weiß ich schonmal bescheid, dass die Sache mit der UTM nicht soooo schlecht ist. Klar, ein richtiger L3 Switch kann das noch schneller als die UTM die mit 20Gb/s angegeben ist https://www.securepoint.de/fileadmin/securepoint/downloads/utm/datenblat ...
die UTM gibts auch als VirtualLicence, also dass man die als VM laufen lassen kann, dann wären die Interfaces ja auch alles vNICs auf dem vSwitch des HyperV Servers, aber da es eben ein Windows HyperV ist, wird das sicherlich nicht so performen wie das BareMetal ding.
die Gesammtbandbreite werd ich sicherlich nie ausschöpfen, ich hab nur bedenken, dass die Latenzen eb pakete verarbeitet werden, ins unermessliche steigen, ich meine was ist, wenn aus 50 VLans mehrere Hundertausend mini Pakete angeflogen kommen (und Broadcast der am ende auch immer wieder verworfen werden muss) - das wird zwar sicherlich nicht die 10Gb/s Bandbreite eines SFP+ Ports auslasten in summe, aber müssen die pakete nicht trotzdem sequentiell abgearbeitet werden, also dass es da mitunter eine große queue geben kann?
und mit dem LACP meinte ich auch die UTM - die kann das, also dass ich die mit mehreren Ports via LACP mit dem Switch kopple - aber Windows kann das halt nicht, bzw. soll man wohl nicht mehr so machen. Aber Windows ist halt eh so eigen, mal schauen ob MS irgendwann mal den TCP Stack wieder halbwegs performant hinbekommt, out-of-the-box... ist aber eine andere geschichte ^^
MLAG Switche kenne ich auch - würde nur hier in dem umfeld genau - garnichts bringen -.- da müsste die gesammte Infrastruktur und verkabelung umgebaut werden, aber wie gesagt, so auf extreme Hochverfügbarkeit kommt es nicht an. Hardware die ausfallen kann, steht als Cold-Standby da. Und es ist immer eine innerhalb kürzester zeit da zum wechseln. Es wird auch 2x im Jahr geprüft in einem Parallel-Test-Netzwerk, ob die ersatzhardware auch so funktioniert, wie sie sollte.
Gut dann weiß ich schonmal bescheid, dass die Sache mit der UTM nicht soooo schlecht ist. Klar, ein richtiger L3 Switch kann das noch schneller als die UTM die mit 20Gb/s angegeben ist https://www.securepoint.de/fileadmin/securepoint/downloads/utm/datenblat ...
die UTM gibts auch als VirtualLicence, also dass man die als VM laufen lassen kann, dann wären die Interfaces ja auch alles vNICs auf dem vSwitch des HyperV Servers, aber da es eben ein Windows HyperV ist, wird das sicherlich nicht so performen wie das BareMetal ding.
die Gesammtbandbreite werd ich sicherlich nie ausschöpfen, ich hab nur bedenken, dass die Latenzen eb pakete verarbeitet werden, ins unermessliche steigen, ich meine was ist, wenn aus 50 VLans mehrere Hundertausend mini Pakete angeflogen kommen (und Broadcast der am ende auch immer wieder verworfen werden muss) - das wird zwar sicherlich nicht die 10Gb/s Bandbreite eines SFP+ Ports auslasten in summe, aber müssen die pakete nicht trotzdem sequentiell abgearbeitet werden, also dass es da mitunter eine große queue geben kann?
und mit dem LACP meinte ich auch die UTM - die kann das, also dass ich die mit mehreren Ports via LACP mit dem Switch kopple - aber Windows kann das halt nicht, bzw. soll man wohl nicht mehr so machen. Aber Windows ist halt eh so eigen, mal schauen ob MS irgendwann mal den TCP Stack wieder halbwegs performant hinbekommt, out-of-the-box... ist aber eine andere geschichte ^^
MLAG Switche kenne ich auch - würde nur hier in dem umfeld genau - garnichts bringen -.- da müsste die gesammte Infrastruktur und verkabelung umgebaut werden, aber wie gesagt, so auf extreme Hochverfügbarkeit kommt es nicht an. Hardware die ausfallen kann, steht als Cold-Standby da. Und es ist immer eine innerhalb kürzester zeit da zum wechseln. Es wird auch 2x im Jahr geprüft in einem Parallel-Test-Netzwerk, ob die ersatzhardware auch so funktioniert, wie sie sollte.
Also so eine UTM ist schon sehr effizient im Verwerfen von Broadcast-Paketen
Du kannst ja mal schauen, welche CPU Auslastung und welchen Datendurchsatz deine UTM hat wenn grade richtig viel los ist im Netz. Ich habe bei mir 2 Gebäude und mal über lange Zeit den Traffic zwischen beiden angeschaut. Da alle Server im neueren Bau stehen weiß ich sehr gut wie viel Traffic meine Geräte und RDS-User aus dem alten Gebäude mit irgendeinem Server austauschen. Es waren bei 10 aktiven Usern ~2 MBit peak!
Sich Gedanken machen ist gut aber ich glaube nicht, das du hier eine Performance-Verbesserung erreichen kannst, die man als Anwender auch wahr nehmen kann.
Du kannst ja mal schauen, welche CPU Auslastung und welchen Datendurchsatz deine UTM hat wenn grade richtig viel los ist im Netz. Ich habe bei mir 2 Gebäude und mal über lange Zeit den Traffic zwischen beiden angeschaut. Da alle Server im neueren Bau stehen weiß ich sehr gut wie viel Traffic meine Geräte und RDS-User aus dem alten Gebäude mit irgendeinem Server austauschen. Es waren bei 10 aktiven Usern ~2 MBit peak!
Sich Gedanken machen ist gut aber ich glaube nicht, das du hier eine Performance-Verbesserung erreichen kannst, die man als Anwender auch wahr nehmen kann.
1