Performance Routing vs Switching auf PC-Hardware

[BenutzerGa4gooPh]

Guten Morgen!

Gegeben:
PC Hardware mit Prozessor J1900 und 4 Stück GBit-LAN-Netzwerkadaptern
http://ark.intel.com/de/products/78867/ ... o-2_42-GHz

Problem:
Ich möchte 2 PCs mit Netzwerkanschlüssen und IPFire (Sicherheitszone LAN) verbinden. Ein dedizierter HW-Switch lohnt sich demzufolge nicht - zumindest sehe ich das bei derzeit nur 2 PCs mit NW-Karten im Home-Netzwerk nicht ein. Wenn es mehr werden, dann natürlich.

Frage:
Was ist performanter, 2 Ports bridgen oder routen? (Ersteres geht nach Recherche auf jeden Fall, letzeres müsste gehen, indem ich die Regeln der von mir nicht benötigten Sicherheitszone DMZ entsprechend anpasse.)

Hinweise:

Google kenne ich, hilft mir aber nicht weiter, da logischerweise Treffer erscheinen, die mir sagen, dass Switching viel schneller ist als Routing wegen der Bearbeitung OSI-Layer 2 - und nicht noch OSI-Layer-3 bearbeitet werden muss - und Switches über spezielle HW verfügen. Hilft mir bei "vergewaltigter" PC-HW nicht weiter. Erstere absolute Aussage wage ich aufgrund der SW-Realisierung zu relativieren: Linux-Bridging auf PC-HW ist vlt. nur eine Krücke, einige Linuxe haben Routing-Fähigkeiten nach Installation vorbereitet, Bridging eher nicht. Allerdings würde Routing noch durch einfache (?) FW-Regeln bearbeitet - aber nur zwischen 2 LAN-Ports ohne aufwändiges NAT. WLAN hat in IPFire übrigens auch eine eigene Sicherheitszone (BLAU).

Man kann sicherlich von Debian ausgehen, IPFire beruht darauf.

Aktuelles PFSense (Basis FreeBSD) kennt OPT-Interfaces (anpasspare geroutete Sicherheitszonen) - dafür aber kein UEFI, nur MBR und damit nur trickreich ein korrektes SSD-Alignment möglich ist. Sehr zeitgemäß. Ich möchte auch nicht unbedingt CSM/Legacy in meinem EFI-BIOS einstellen. PFSense habe ich ad acta gelegt.

LG Jana

[MSfree]

Frage:
Was ist performanter, 2 Ports bridgen oder routen?

Ich glaube, die Frage stellt sich bei 3 Rechnern noch nicht. Da dürfte Routing praktisch genauso schnell sein wie Bridging. In beiden Fällen müssen die Netzwerkpakete durch den Kernel des Rechners in der Mitte von einer Netzwerkkarte auf die andere geschoben werden und ob eine der 4 CPU-Kerne dann noch mit 1% durch Routing belastet wird oder nicht, spielt kaum eine Rolle.

Bridging ist halt viel einfacher zu konfigurieren.

Das einfachste ist, du probierst es aus. Meine Vermutung ist, daß die Netzwerkkarten das Haupthindernis sind und nicht, ob bridged oder routed. Die CPU ist es jedenfall nicht.

[BenutzerGa4gooPh]

Das einfachste ist, du probierst es aus. Meine Vermutung ist, daß die Netzwerkkarten das Haupthindernis sind und nicht, ob bridged oder routed. Die CPU ist es jedenfall nicht.

Wirst wohl Recht haben. Gerade entdeckt: http://wiki.ipfire.org/en/hardware/passivenics

Ausprobieren kann ich nicht, derzeit nur ein Lappi mit NW-Karte und langsames Internet. WLAN-Geräte (Tablet, Smartphone) sind ungeeignet. Erstmal will ich die richtige FW-Distri wählen. (Zukunft eingebaut.)

Jedenfalls gerade festgestellt, dass IPFire auch nur im Legacy/CSM-Modus bootet. Ist das Absicht? Ich habe schon die amd64_x86-Version. Na ja, mal sehen was ClearOS tut ... .

[r4pt0r]

IIRC ist die schlechte EFI-Implementierung von GRUB schuld daran, dass EFI von fpSense noch nicht unterstützt wird - ne FW *muss* zuverlässig booten, da kann man sich nicht auf halbgare implementierungen verlassen. Mit Version 2.4 wird auf den FreeBSD-Loader gewechselt, damit ist zuverlässiges booten per EFI möglich. K.A. warum pfSense überhaupt so lange auf GRUB rumgeritten ist...

Das alignment wird davon aber i.d.r. nicht beeinflusst - der FreeBSD Installer erkennt das ziemlich gut, auch viele SSDs bzw allgemein Laufwerke die 512er blockgrößen vorlügen werden dank umfangreicher blacklisten korrekt erkannt und Partitionen korrekt ausgerichtet.

Zur eigentlichen Frage: eine bridge ist theoretisch schneller, da das Kernelrouting von FreeBSD aber sowieso schon sehr schnell und (im Gegensatz zu Linux) für 1GbE++ optimiert ist, wirst du mit Gbit links keine wirklichen Performanceunterschiede haben bzw wenn dann nur eine minimal erhöhte Latenz. Durchsatz wird mit beiden Varianten problemlos für die Sättigung der Gbit-links ausreichen (sofern es die Hardware hergibt). Ich hab an meinen FreeBSD-gateways nichts weiter optimiert und 3 der 4 GBit-uplinks werden praktisch jede nacht währrend der lokalen backups gesättigt. (am vierten hängt der langsame WAN-uplink)

Da du aber sowieso nur nen switch sparen willst (die es ab 20 eur gibt...), macht bridging am wenigsten Aufwand....


Nochmal ergänzend zum Thema Hardware: https://calomel.org/network_performance.html

[BenutzerGa4gooPh]

Das alignment wird davon aber i.d.r. nicht beeinflusst - der FreeBSD Installer erkennt das ziemlich gut, auch viele SSDs bzw allgemein Laufwerke die 512er blockgrößen vorlügen werden dank umfangreicher blacklisten korrekt erkannt und Partitionen korrekt ausgerichtet.

Das hatte ich nach der pFSense-Installation mit Linux-Live-Iso (Mint17.3 ) geprüft.

Code: Alles auswählen

fdisk -l -u /dev/sda

Allerdings nutzt PFSense wohl Formate, mit denen Linux/gparted nicht zurechtkommt. Die erste Part. ging jedoch bei 512 und nicht bei 2048 los. Hier hat einer getrickst: https://forum.pfsense.org/index.php?top ... #msg472348
(Braucht man wohl eine FreeBSD-Live-Iso für.)

Aber egal, ich habe jetzt die Community-Version von ClearOS gezogen.
https://www.clearos.com/clearfoundation ... -community
Ging auch ohne Registrierung. Und diese startet mit UEFI, gerade am Lappi probiert. Bei Gelegenheit installiere ich richtig. Mal sehen, wie mir das gefällt.

Ansonsten bin ich wegen Routing vs Switching Performance beruhigt. Wie es eben bequemer ist.

Und wegen des Switches geht es mir nicht um die paar Piepen, aber für 2 PCs mit NW-Karten? Davon einer erst künftig.

Und jetzt lese ich in aller Gemütlichkeit deinen laaangen Link.

[BenutzerGa4gooPh]

Zusammenfassung:

Nochmal ergänzend zum Thema Hardware: https://calomel.org/network_performance.html

Ist ein guter Link für Auswahl und Optimierung von Netzwerkkomponenten, vor allem bei Eigenbau und "Zweckentfremdung" von Standard-PC-Hardware. Für performante NW-HW sind aktive NW-Karten (eigener Controller) wichtig, evtl. sogar spezielle Serverkarten. Sowie deren Anbindung an die CPU.

Zu ClearOS:
Version 7.2.0 laesst sich im EFI/GPT-Modus installieren.
Problem: Der Installer kann keinen EFI-Bootloder schreiben. Ohne den Grund anzuzeigen.
Abhilfe: Installation nicht abbrechen, einfach weiter machen. Danach noch einmal Installations-ISO im Rescue-Modus booten und Bootloader schreiben:

Code: Alles auswählen

chroot /mnt/sysimage
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

(ClearOS basiert auf Redhat/CentOS.) Reboot und funktioniert.
Das korrekte SSD-Alignment macht der Installer bei allen 3 Partitionen korrekt. Geprüft mit

Code: Alles auswählen

parted /dev/sda align-check opt

1. Eindruck: Scheint etwas mächtig zu sein, die Installation von PFSense geht viel schneller. Wer also langsame HW, kein UEFI-BIOS hat sollte ueberlegen ... .

Ich danke MSFree und r4pt0r herzlich für die Hilfe. Anmerkungen sind willkommen, morgen setze ich auf [gelöst].

[r4pt0r]

Zusammenfassung:

Nochmal ergänzend zum Thema Hardware: https://calomel.org/network_performance.html

Ist ein guter Link für Auswahl und Optimierung von Netzwerkkomponenten, vor allem bei Eigenbau und "Zweckentfremdung" von Standard-PC-Hardware. Für performante NW-HW sind aktive NW-Karten (eigener Controller) wichtig, evtl. sogar spezielle Serverkarten. Sowie deren Anbindung an die CPU.

Die betagten aber noch immer sehr guten Intel e1000 Pro für PCIe gibts noch immer neu und man bekommt sie mittlerweile hinterhergeworfen - da machts keinen Sinn mit irgendwelchen Desktop-NICs rumzuspielen.
Auch Serverboards gibts relativ günstig, die haben dann oft schon gute onboard-NICs die per PCIe angebunden sind. Z.B. die aktuellen Asus P10 gibts ab 184 EUR mit 4x Intel I210: https://www.mindfactory.de/product_info ... 24198.html

Ansonsten wie im anderen Thread schon gesagt: fürn Heimgebrauch bekommt auch ausrangierte Netzwerkappliances ohne Lizenz zum Schrottwert bei ebay. Das sind i.d.r. normale Serversysteme (meistens Supermicro oder Intel), ggf mit abgespeckten Anschlüssen (kein VGA, PS2 etc) und im bunten Gehäuse.

[wanne]

Zur ursprünglichen frage: Heutige Desktop CPUs bekommst du auch mit 40G nicht ausgelastet. (Mit VPN dann schon. Aber das ist die Crypto.)
Deswegen ist Routing minimal schneller, weil da die Broadcast Pakete nicht mit übertragen werden.

1GiB Router mit WLAN (Das man dann einfach abschalten kann.) gibt es für <50€. Und die brauchen dann 5W statt 40W. Pro Jahr macht das dann auch nen Fufi oder so. Bevor du anfängst da anfängst irgend was Nachzukaufen kannst du sowas nehmen. Da hast du dann aber wirklich Performance Probleme: Statefull firewalling ist dann nicht mehr. (Defakto lassen sich aber alle derartigen Regeln mit syn- oder vollständigem Filtering besser umsetzen.)
Wenn es mehr als 2 Netze sein sollen musst du drauf achten, dass der Switch programmierbar ist.
Die machen dann zwar meist tatsächlich nicht die vollen 1G aber die meisten kommen so nahe dran, dass man da nichts von spürt.

[BenutzerGa4gooPh]

1 GiBit-Router mit WLAN (Das man dann einfach abschalten kann.) gibt es für <50€. Und die brauchen dann 5W statt 40W. Pro Jahr macht das dann auch nen Fufi oder so. Bevor du anfängst da anfängst irgend was Nachzukaufen kannst du sowas nehmen.

Du hast natürlich Recht und für den Hausgebrauch genügt das sicher meist. Ich wollte jedoch für wenig Geld eine kleine Firewall-Applliance (64bit-PC) und habe das gekauft:
http://www.qotom.net/goods-129-QOTOM-Q1 ... ni+PC.html
https://www.amazon.de/Celeron-Firewall- ... 6S57A&th=1
Etwa 10 Watt. Laut Beiträgen im PFSense-Forum schaffen manche zwischen 800 und 900 MBit/s zu routen - trotz Desktop-NICs. Realtek auf der Zotac ZBox CI323 hat nach Forenbeitraegen wohl arge Performannce-Probleme. Das APU2C4 von PCEngine schafft:

Dual way routing test through the APU2 from a client in green to a server in red: (this need a DNAT Rule to forward port 5001 back to the client in green.)
..
Interval Transfer Bandwidth
[ 5] 0.0-60.0 sec 6.44 GBytes 921 Mbits/sec
[ 4] 0.0-60.0 sec 3.64 GBytes 520 Mbits/sec

http://wiki.ipfire.org/en/hardware/pcengines/apu2b4

Ausserdem würde mich das Flashen nerven und so bin ich nicht auf OpenWrts oder DDWrts Gnade - und die der WLAN-FW-Hersteller angewiesen. Reiche Auswahl: https://distrowatch.com/search.php?category=Firewall
Des weiteren kann ich beliebige Pakete dazu installieren.

Ansonsten wie im anderen Thread schon gesagt: fürn Heimgebrauch bekommt auch ausrangierte Netzwerkappliances ohne Lizenz zum Schrottwert bei ebay. Das sind i.d.r. normale Serversysteme (meistens Supermicro oder Intel), ggf mit abgespeckten Anschlüssen (kein VGA, PS2 etc) und im bunten Gehäuse.

Ja. Wenn ich das eher gewusst hätte, sicher ueberlegenswert (auch Strom, Lüfter). Da hatte ich meine Buechse jedoch. Und mein "Schreibtischgeraet" ist nur gross wie 2 nebeneinder liegende Smartphones und 5 cm hoch. Kann es auch am/unter Schreibtisch anschrauben, eine nette (VESA?) Halterung gibt es dazu. Und du mit 19-Zoll-Ohren (am Geraet meine ich selbstverstaendlich) kannst dir was einfallen lassen.

Am Ende wohl alles Hobby, ein Plastikrouter mit DDWrt/Openwrt würde wohl uns allen zuhause genuegen?!

Tante Edit hat gesagt:
Hersteller von Plastikroutern nutzen oftmals proprietäres HW-NAT. Um 1GBit/s Uplinks mit DDWRT/OpenWrt (HW-NAT nicht unterstützt) einigermassen zu bedienen, bedarf es einer schnellen CPU, ab 1 GHz. Also eines zeitgemäßen Routers ab etwa 100 Euro. Viel mehr muss nicht sein:
https://www.dd-wrt.com/wiki/index.php/Supported_Devices

[dufty2]

Linux schafft es nicht.
Linux schafft es nicht ohne Tricks [1] zwischen zwei Ports zu forwarden mit 'LineRate' bei 10 Gbps.
Das Problem hierbei sind die kleinen Pakete, von denen es 14 Millionen pro Sekunde abhändeln müsste.
Die Zahlen, die ich gesehen habe, liegen bei 2 bis 3 Mpps.

Da Jana aber ein Zehntel 10 Gbps verwendet, besteht noch Hoffnung

[1] z. B. mit DPDK

[wanne]

Wo rechne ich jetzt falsch?
10*1000MBit/s/(1500*8Bit)=0.8Mpps
Oder umgekehrt:
2M/s*1500*8=24GBit/s
Ist man also auch weit über 10G.

[dufty2]

Die "1500" sind Dein Fehler

Diese "dicken" Pakete machen nicht die Herausforderungen, sondern (wie oben bereits erwähnt) die kleinen:

Minimale "frame size": 84 Byte
=> ( ( 10**10 ) / ( 84 * 8 ) ) ~= 14880952
also roundabout 14.9 Mpps

[BenutzerGa4gooPh]

@wanne:
Wenn man/frau wüsste, was das Ziel der Rechnung ist und 1500 (mtu?) bedeutet?
Vlt. "Wie postet man richtig" mal lesen. Duck und wech.

[MSfree]

Die "1500" sind Dein Fehler

Diese "dicken" Pakete machen nicht die Herausforderungen, sondern (wie oben bereits erwähnt) die kleinen:

Minimale "frame size": 84 Byte
=> ( ( 10**10 ) / ( 84 * 8 ) ) ~= 14880952
also roundabout 14.9 Mpps

Naja, sowohl 1500Byte große als auch 84Byte kleine Pakete sind Extremwerte. Bei meinem Heimserver komme ich auf eine durchschnittliche Paketgröße von 993Byte, in dem ich die Informationen, die ifconfig für (RX+TX)-Bytes und (RX+TX)-Pakets ausgibt, durcheinander teile.

[dufty2]

Naja, sowohl 1500Byte große als auch 84Byte kleine Pakete sind Extremwerte. Bei meinem Heimserver komme ich auf eine durchschnittliche Paketgröße von 993Byte, in dem ich die Informationen, die ifconfig für (RX+TX)-Bytes und (RX+TX)-Pakets ausgibt, durcheinander teile.

Diese "Durchschnittswertbildung" ist falsch bzw. zu einfach gedacht (in diesem speziellen Falle).
In einem Haus befinden sich das einjährige Kleinkind und die 99jährige Uroma, also ist der Durchschnitt 50.
Aber in beiden Fällen ist der Abstand "wahres Alter - Durchschnitt" 49 Jahre, also extrem groß.

Kleine Pakete (UDP) und große (Dateientransfer) kommen relativ häufig vor, vgl. auch IMIX
https://en.wikipedia.org/wiki/Internet_Mix

Natürlich sind die 14.9 Mpps ein bischen unreal, aber gerade mit dieser "line rate" brüsten sich halt Cisco & Co.

[MSfree]

Diese "Durchschnittswertbildung" ist falsch bzw. zu einfach gedacht (in diesem speziellen Falle).

Komisch, daß Statistik immer sofort ohne Nachdenken angezweifelt wird. Du liegst mit deiner Aussage nämlich völlig daneben. Der Mittelwert repräsentiert hier nämlich tatsächlich die Anzahl der Pakete pro Sekunde, die sich maximal aus 993Bytes pro Paket ergeben, nämlich für 10GBit/s rund 1.25Mio PPS. Wie stark die Paketgröße um den Mittelwert herum variieren ist für die PPS völlig uninteressant.

Auf die 993Bytes pro Paket erhebe ich allerdings keinen global gültigen Anspruch, denke aber, daß dieser Wert nicht so schlecht liegt, der ist nämlich über 200 Tage gemittelt aus etwa 2.2TiB Traffic.

[wanne]

Bei meinem Heimserver komme ich auf eine durchschnittliche Paketgröße von 993Byte, in dem ich die Informationen, die ifconfig für (RX+TX)-Bytes und (RX+TX)-Pakets ausgibt, durcheinander teile.

Und jetzt bitte die durchscnittliche Paket und Datenrate.
Ich wette Deutlich kleiner 1MBit/s. Wenn durch ne Leitung über 100MBit/s durchgeht, dann sind das zu über 99% >1400Byte Pakete. (Zumindest solage da kein Gnutella oder VPN am werk ist.)
In den Meisten Netzwerken sind TCP-Verbindungsaufbauten und DNS relativ dominierende pakettypen aber die schaffen keine 100MBit/s im LAN sondern machen ihre Pakete mit der Zeit und extrem kleinen Datenraten. Wenn dein Netzwerk wirklich am Limit ist, kannst du die vernachlässigen.

[dufty2]

Der Mittelwert repräsentiert hier nämlich tatsächlich die Anzahl der Pakete pro Sekunde, die sich maximal aus 993Bytes pro Paket ergeben, nämlich für 10GBit/s rund 1.25Mio PPS..

Was die "993Bytes pro Paket" mit den "1.25Mio PPS" zu tun haben, erschließt sich mir nicht.
Aber ich muss nicht alles verstehen

Zur Verdeutlichung mal meine client-Daten aus ein paar Stunden "df.de-Rumgesurfe":
RX packets 19008 bytes 17720545 (16.8 MiB)
TX packets 19076 bytes 2462387 (2.3 MiB)

(RX b)/(RX p) = 932
(TX b)/(TX p) = 130
(RX b + TX B)/(RX p + TX p) = 530

Aber diese "530" sind falsch (nicht im mathematischen Sinn):
Vom Server kommen Daten mit 1400+ an, der Client schickt ACKs mit 64+ zurück.
500 (oder 600) sind eher selten.
Man sieht es auch im tcpdump/wireshark.

[wanne]

Vom Server kommen Daten mit 1400+ an, der Client schickt ACKs mit 64+ zurück.

Ja. Das ist halt das verhalte bei ner lahmen leitung.
Linux (RedHat und vermutlich wirds mit debian ähnlich sein.) verzögert ACKs per default um 40ms.
Das heißt bei 100MBit/s 3k·~1500Byte auf einen Ack mit ~64Byte.
Macht im schnitt ~1500Byte. (Ganz so viel ist es nicht, weil die Windowsize da auchnoch reinspielt. Trotzem in der Größenordnung stimmt das.)
Das gilt aber für einen Download.
Dein Debianrumgesurfe sieht natürlich völlig anders aus. Da sind massenhaft TCP aufbauten und DNS mit drin. Viel kleine übertragungen statt einem dicken Download.
Aber da hast du ne RTT von 20ms und dein aufbau hat dann 3 mal 64Byte in 30ms.
Mit einer Verbindung machst du also 6kiB/s umd da 1GBit/s 156250Verbindugen.
Das hast du irgend wo im Internet aber garantiert nicht in deien LAN. Selbst mit torrent nicht.

Das ist das was ich gemeint habe:
Wenn du deine Leitung mit 100MBit/s auslastest dann ist deine durchscnittsgröße an Paketen ~1500Byte. (Solange du keine jumbo frames hast.)
Dein average beim Surfen sieht anders aus. Aber da redest du dann auch von durchschnittlichen Auslastungen von <1MBit/s und das gibt deine CPU eh her.

[BenutzerGa4gooPh]

Vielleich solltet ihr euch auf Szenarien einigen (oder unterscheiden), die leicht an Grenzen stoßen, für die man eben schnelle NW-Komponenten benötigt:
- Rootserver, Downloadserver, Onlinezeitungen (heise.de), Shopping (amazon.de)
- teilausgelagerte Datenbanken von Firmen (Firma A nutzt ERP-System, Firma B hostet, macht "Rechnerläufe")
- Firmen mit mehreren Standorten und notwendigen DB-Synchronisationen
- Gateways in großen Firmen
- interne Firmenserver
- etc.
Und daraus entsprechende Verkehrstypen, überwiegende Frame-/Paketgrößen ableiten? Und wo liegen Grenzen? Für CPU-Grenzen gibt es preiswert schnellere CPUs oder Cluster. Die NW-Karten (damit Frames) einschl LANEs sind da wohl eher Grenzen.10GBit-Karten sind wohl immer noch selten, schweineteur.

Und die neuen Customer-WLAN-Router kriegen jetzt Probleme: 1 GBit/s reicht nicht mehr für den Access der neuesten WLAN-Technologien AC3200 als Summe von 2 oder 3 Bändern. Für die Switchports sowieso noch nie. Zwischen CPU und Switch-Trunk leider nur 1 Gbit/s. Wer braucht's derzeit - außer Customer-Router-Marketing?! Die Hersteller von WLAN-Clients ziehen sowieso nicht mit. Oder können das technisch aufgrund Platzverhältnissen für Antennen gar nicht. Profi-Hersteller (Cisco) nutzen aktive, blockierungsfreie Backplanes und viele CPUs.

[r4pt0r]

Zum Thema JumboFrames:
JF bringen bei GBit in der Praxis eigenlich nur eine Verringerung der CPU-Last. Performancegewinne (wenn es mit aktueller Hardware noch welche gibt), bewegen sich im Promillebereich:

Code: Alles auswählen

# netperf -H 10.50.50.1 -t TCP_STREAM -C -c -l 60 -- -m 1472
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.50.50.1 () port 0 AF_INET : histogram : interval : dirty data : demo
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % C      % C      us/KB   us/KB

 65536  32768   1472    60.01       989.50   12.27    2.20     4.064   1.456

# netperf -H 10.50.50.1 -t TCP_STREAM -C -c -l 60 -- -m 8972
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.50.50.1 () port 0 AF_INET : histogram : interval : dirty data : demo
Recv   Send    Send                          Utilization       Service Demand
Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
Size   Size    Size     Time     Throughput  local    remote   local   remote
bytes  bytes   bytes    secs.    10^6bits/s  % C      % C      us/KB   us/KB

 65536  32768   8972    60.03      989.52   9.76     1.45     3.232   0.961

989.50 -> 989.52 MBit/s; das geht als Messtoleranz durch...
Der Benchmark lief im (priorisierten) mgmt-VLAN vom Client (i7 6700, Intel PRO/1000 Onboard) über 2x cisco SG300 mit 2xGBit Uplink zum Gateway (Xeon L5410, Intel PRO/1000). OS an beiden Enden ist FreeBSD; 12-CURRENT bzw TrueOS am Client und 10.3-RELEASE am Gateway.
Einziger unterschied ist die 2.5% höhere CPU-Last mit der kleinen Framegröße - Für ein CPU-schwaches Gateway in einem größeren Netz kann das durchaus einen Unterschied machen; rein aus Sicht der Performance speziell im Heimgebrauch sind JF komplett zu vernachlässigen wenn man mit halbwegs brauchbarer Hardware arbeitet.

Für Subnetze in denen SIP-Geräte sind macht man sich meist mit JF mehr Probleme, da durch die path MTU discovery oft die Latenzen zu stark erhöht werden. Alte SIP-Endgeräte steigen auch gerne einfach aus, billige Switches fangen mit JF auch gerne an Pakete zu droppen - Netgear ist hier mal wieder der notorische Klassendepp (ProSafe....)
Wenn man eher fragwürdige Hardware im "normalen" Heimnetz betreibt würde ich JF einfach ignorieren und bei 1500 Byte MTU bleiben - macht am wenigsten Aufwand und man lädt keine Gremlins ein. In Verbindung mit WLAN ist die MTU sowieso nochmal ein ganz anderes Biest; da hilft meistens nur (viel) testen und benchmarken wenn man an der MTU schrauben will.

In Netzen/VLANs in denen nur Server/Infrastruktur-Geräte kommunizieren und über die auch Backups laufen, habe ich i.d.R. eine MTU von 9000 gesetzt. Hier überwiegt ganz klar der Vorteil der niedrigeren CPU-Last.
Interfaces die von Clients angesprochen werden (also im LAN oder DMZ), haben i.d.R. eine MTU von 1500 gesetzt. Hier werden sowieso praktisch nur Windowskisten bedient und diese Büchse der Pandora öffne ich sicher nicht indem ich an denen ne höhere MTU setze, speziell da hier Hardware aus allen Preisklassen bis ~10 Jahre alter vorhanden ist...
Am WAN ist man meist durch den ISP beschnitten - oft sogar auf (deutlich) <1500 Byte. Bei FTTH-Anschlüssen oder regionalen Netzbetreibern kann man immer öfter auch mit höherer MTU fahren - das macht vor allem dann Sinn, wenn der ISP z.B. cache-/accelerator-/CDN-appliances im eigenen Netz hat (z.B. von Netflix, cloudflare, akamai, google...).

[r4pt0r]

10GBit-Karten sind wohl immer noch selten, schweineteur.

Die Karten aus der "ersten" Generation mit Mellanox ConnectX2 Chipsatz gibts teilweise noch Neu für ~100EUR. Ansonsten sind neue Dualport-Karten bereits bei ~200EUR angekommen (vor nichtmal 2 Jahren noch ~600EUR).
Fürn "SOHO"-Gebrauch kann man auch auf gebrauchte Karten zurückgreifen - Singleport HP oder IBM Karten gibts für ~30 EUR, dualport ab ~50 EUR. Twinax-Kabel liegen bei 20-40 EUR je nach länge, ansonsten gibts die günstigen Finisar SFP-Module um ~25EUR/Stück und LWL-Patchkabel sind ab ~10m schon lange günstiger als CAT7.

Für <100 EUR kann man sich also schon nen 10GBit uplink zwischen 2 Rechnern bauen.

[wanne]

Und die neuen Customer-WLAN-Router kriegen jetzt Probleme: 1 GBit/s reicht nicht mehr für den Access der neuesten WLAN-Technologien AC3200 als Summe von 2 oder 3 Bändern. Für die Switchports sowieso noch nie. Zwischen CPU und Switch-Trunk leider nur 1 Gbit/s. Wer braucht's derzeit - außer Customer-Router-Marketing?! Die Hersteller von WLAN-Clients ziehen sowieso nicht mit. Oder können das technisch aufgrund Platzverhältnissen für Antennen gar nicht. Profi-Hersteller (Cisco) nutzen aktive, blockierungsfreie Backplanes und viele CPUs.

Wie gesagt: GBit/s bekommst du auch nurch einen Plastikrouter. Da ist er zwar an seiner Grenze und kommt in paar unüblichen Szenarien nicht mehr mit aber im Heimgebrauch ist das voll im Maß.
Das WLAN "bis zu" ist quatsch. Ich wette dass du auch bei den neuen 4.6GBit/s verdammt froh sein kannst, wenn du da 100MBit/s drüber bekommst. Alles kein Problem für die CPU.

Wenn man eher fragwürdige Hardware im "normalen" Heimnetz betreibt würde ich JF einfach ignorieren und bei 1500 Byte MTU bleiben

Full ACK. Ist (leider) den Aufwand nicht wert.
Das sieht etwas anders in Firmennetzwerken aus, wo man überall die gleiche Hardware und die gleichen Anwendungnen hat und dann dick testen kann. Sonst ist alles außer 1500byte insbesondere mit IPv4 absoluter Garant für Ärger.

@r4pt0r: Ja Glsfaser würde ich wenn ich lieb fragen würde wohl sogar ausgemusterrte Melanox-InfiniBand-Hrdware umsonst irgend wo her bekommen. Die frage ist, wie du das in dein Netzwerk integrierst. Insbesonder die Switches sind dann nämlich nicht mehr so für umme zu haben.

[r4pt0r]

@r4pt0r: Ja Glsfaser würde ich wenn ich lieb fragen würde wohl sogar ausgemusterrte Melanox-InfiniBand-Hrdware umsonst irgend wo her bekommen. Die frage ist, wie du das in dein Netzwerk integrierst. Insbesonder die Switches sind dann nämlich nicht mehr so für umme zu haben.

Infiniband braucht man sich aber auch eher nicht mehr ans Bein hängen, ausser für uplinks zwischen switches macht das kaum sinn bzw ist ja sowieso nicht wirklich für Hostanbindung gedacht gewesen, zumal es sich ja hier nicht mehr um Ethernet handelt (oder wurde da noch was aus dem Vorhaben "Ethernet-over-Infiniband"?)

10GbE Switches sind nach wie vor ziemlich teuer - selber "trend" wie schon bei FC. Einziger (positiver) Unterschied: Bei 10GbE switches wird nicht mehr so krass über Lizenzen abkassiert wie bei FC. Da kauft man ja für 15k EUR nen switch und muss dann zusätzlich per Lizenzen die Ports freischalten

Für kleine deployments, z.b. Storageserver + 1-4 Virtualisierungshosts kann man auch ohne switch auskommen und tangiert damit auch das vorhandene Netz nicht. Teilweise war für solche Setups ja schon FC vorhanden, das lässt sich dann nahtlos überführen. Blockdevices werden dann per iSCSI durchgereicht und man kann den Link auch noch anderweitig nutzen; da ist man schon deutlich flexibler als mit FC.

Ich warte hauptsächlich noch bis switches mit 10G uplinks preislich halbwegs interessant werden. Aktuell sind hier manche switches mit 4-fach LAG verbunden, was zu Stoßzeiten trotzdem eng wird. Bei 6-8 ports die für uplink-LAGs verloren gehen wäre 10G uplink wirklich eine Erlösung, auch weil dann wieder mehr "heiße" links auf den selben switch gelegt werden können.

[dufty2]

Das ist das was ich gemeint habe:
Wenn du deine Leitung mit 100MBit/s auslastest dann ist deine durchscnittsgröße an Paketen ~1500Byte.

Tja, fürchte, Deine 2. Rechung (und die Schlussfolgerungen daraus) sind genauso falsch wie Deine 1. Rechnung

Das Grundprinzip TCP lautet (extrem vereinfacht): data <1500>, data <1500>, ACK <64>, data <1500>, data <1500>, ACK <64>, etc.
=> Daraus kann nie und nimmer ein Durschnitt von 1500 werden.
Doch probieren geht über studieren!
Win client mit iperf über 100 Mbps Switch an Linux-VM:

Code: Alles auswählen

C:\_personal>iperf3.exe -c 10.10.10.10 -t 3
Connecting to host 10.10.10.10, port 5201
[  4] local 10.10.10.11 port 28963 connected to 10.10.10.10 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  11.5 MBytes  96.5 Mbits/sec
[  4]   1.00-2.00   sec  11.2 MBytes  94.4 Mbits/sec
[  4]   2.00-3.00   sec  11.2 MBytes  94.4 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-3.00   sec  34.0 MBytes  95.1 Mbits/sec                  sender
[  4]   0.00-3.00   sec  34.0 MBytes  95.1 Mbits/sec                  receiver

iperf Done.

C:\_personal>

So, und was sagt Wirekshark?

Code: Alles auswählen

frame.cap_len <= 100
Pakete 36823  Angezeigt: 12340 (33.5%)

frame.cap_len >= 1400
Pakete 36823  Angezeigt: 24209 (65.7%)

Merkste was?