m.fessler
Goto Top

Ethernet Flusssteuerung, Flow Control. Wann macht diese Sinn? Ein, Aus, Mismatch?

Seid gegrüßt!

Wie haltet ihr es eigentlich mit der Flusskontrolle in 08/15 SOHO Umgebungen (Gigabit)?
Scheinbar gehen hier die Meinungen stark auseinander.
Von "macht meist mehr Probleme als es hilft, schalte ich grundsätzlich aus" bis "immer ein" ist alles dabei.

Auf Switches die mir so begegnen ist es default meist aus, Intel NICs dagegen haben meist "RX and TX Enabled" (warum eigentlich?).
Ich neige dazu das auch so zu belassen und hatte (oder denke ich zumindest) diesbezüglich noch nie Probleme, auch wenn man immer wieder liest, dass gerade so ein Mismatch problematisch sein soll.

Wie handhabt ihr das?
In welchen Situationen macht es Sinn es überall einzuschalten?
Was ist eigentlich bei "dummen" unmanaged Switches gemeint, wenn sie 802.3x in den Specs stehen haben?
Dass sie die Frames einfach stumpf weiterleiten aber sonst nicht weiter darauf reagieren?

Danke schon mal für jede Rückmeldung!
Grüße,
Martin

Content-ID: 3835452190

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

Ausgedruckt am: 21.11.2024 um 12:11 Uhr

Spirit-of-Eli
Spirit-of-Eli 25.01.2024 um 07:24:55 Uhr
Goto Top
Moin,

das "Feature" macht ja eigentlich nur Sinn wenn im Netz unterschiedliche Bandbreiten an den Links hängen. Dann kann der entgegen nehmende Switch quasi sagen "hey mach mal langsam".
In einem reinen Gbit Netz macht es daher keinen Sinn.

Dumm Switche arbeiten halt schon im Default auf Durchzug wo hingegen intelligente Switche schauen wohin die Paket müssen.
10939953361
10939953361 25.01.2024 aktualisiert um 07:40:54 Uhr
Goto Top
Die Frage ist wo man das Feature und für was aktiviert. Überall anmachen habe ich noch nie gesehen. Und speziell 802.3x ist mir schon lange nciht mehr untergekommen.

Wir priorisieren aber an einigen stellen Traffic. Für Sprache zum Beispiel oder wenn unzählige Clients zum Dienstbeginn den SCCM leechen wollen.
Coreknabe
Coreknabe 25.01.2024 um 09:09:33 Uhr
Goto Top
Moin,

ich würde mal behaupten, dass das im SOHO-Bereich komplett wumpe ist, zumindest solange es keine Probleme gibt, die damit zusammenhängen könnten.

Habe für uns auch immer wieder mal ein wenig recherchiert, kann da aber nur für eine KMU-Umgebung sprechen. Um 2010 herum sollte Flow Control für iSCSI-Verbindungen noch tunlichst deaktiviert werden, heutzutage empfiehlt Ruckus, das gerade für iSCSI-Verbindungen zu aktivieren, per Default ist das in der ICX-Reihe immer aktiv. Meine Vermutung, meine, das auch mal irgendwo gelesen zu haben, ist die Hardware heute einfach schnell genug, um das abzuarbeiten. Wahrscheinlich gibt's jetzt die Knute von @aqui face-wink

Gruß
Spirit-of-Eli
Spirit-of-Eli 25.01.2024 um 10:01:44 Uhr
Goto Top
Euch ist schon bewusst was "Flow-Control" macht?

Der Mechanismus greift nur bei unterschiedlichen Bandbreiten. Bsp. kommen die Pakete mit Gbit an und sollen an einem anderen Port den jeweiligen Switch über einen 100Mbit Port zu einem weiteren Switch verlassen. Dann ist es ist ja nicht möglich die Transfer Rate aufrecht zu erhalten. Spätestens bis der Puffer im Switch mit Gbit voll ist.
Nur an dieser Stelle kommt Flow-Control zu tragen. Daher ist es default auch mittlerweile ausgeschaltet.

Anders als in meinem Beispiel vielleicht beschrieben müssen die involvierten Geräte zwingend "Flow-Control" unterstützen und aktiviert haben damit dies auch funktioniert.

https://www.itwissen.info/Flusskontrolle-flow-control.html
aqui
aqui 25.01.2024 um 13:17:09 Uhr
Goto Top
per Default ist das in der ICX-Reihe immer aktiv.
Nein, das ist falsch. Auch hier ist es wie bei JEDEM Hersteller generell deaktiviert und das sollte man aus guten Gründen auch immer so lassen.
Man hat es in der Tat in alten Zeiten mal bei großen Speed Unterschieden gemacht was aber immer in gravierenden Buffer Bloating Problemen endet. Heute sind die Port Buffer eh so klein (ganz besonders im Billigbereich) das eine Aktivierung so oder so kontraproduktiv ist.
Zumal auch bei allen Endgeräten es auch nirgendwo aktiviert ist. Flow Control ist ja bekanntlich immer eine zweiseitige Geschichte.
Wer Buffering im Netzwerk braucht hat eh einen groben Designfehler. face-wink
Coreknabe
Coreknabe 25.01.2024 um 13:39:11 Uhr
Goto Top
Nö, bei Ruckus ist das per Default eingeschaltet:
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...

Trifft für die 09010-Version ebenfalls zu.

Und für iSCSI sogar empfohlen:
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...

https://support.purdi.com/hc/en-gb/articles/360016780711-Ruckus-ICX-iSCS ...

OK, interessiert den TO allerdings nicht, weil er vom SOHO-Bereich schreibt...

Gruß
10939953361
10939953361 25.01.2024 um 13:42:47 Uhr
Goto Top
Zitat von @aqui:

Wer Buffering im Netzwerk braucht hat eh einen groben Designfehler. face-wink

Ja und warum hat dann jedes Gerät ob günstig, billig oder teuer sowas in Hard- und Software implementiert? Und im Falle der Hardware kann es fast nie deaktiviert werden, egal wir groß der Buffer im RAM der Hardware ist!

Ich denke der TO fragt nach Treiberoptionen (Intel NIC) und überblickt die volle Materie nicht.
aqui
aqui 25.01.2024 aktualisiert um 14:25:39 Uhr
Goto Top
Nö, bei Ruckus ist das per Default eingeschaltet:
Das mag sein ist aber nur die halbe (Handbuch) Wahrheit. Konfigtechnsich ist es global vorbereitet aber nicht aktiv, da die Negotiation NICHT aktiviert ist was man erst mit einem Kommando machen muss. Folglich ist es also nicht aktiv wie bei allen anderen auch! face-wink

GigabitEthernet1/1/1 is up, line protocol is up
Port up for 29 day(s) 21 minute(s) 30 second(s)
Hardware is GigabitEthernet, address is 94b3.4f34.124e (bia 94b3.4f34.127c)
Configured speed auto, actual 1Gbit, configured duplex fdx, actual fdx
Configured mdi mode AUTO, actual MDI
EEE Feature Disabled
Tagged member of 3 L2 VLANs, port state is FORWARDING
BPDU guard is Disabled, ROOT protect is Disabled, Designated protect is Disabled
STP configured to ON, priority is level0, mac-learning is enabled
MACsec is Disabled
Mirror disabled, Monitor disabled
Openflow is Disabled, Openflow Hybrid mode is Disabled, Flow Control is config enabled, oper enabled, negotiation disabled
...

Im iSCSI wird es schon lange nicht mehr gemacht eben wegen der Buffer Bloat Problematiken.
https://en.wikipedia.org/wiki/Bufferbloat
In Storage Netzwerken mittlerweile ein NoGo.
billig oder teuer sowas in Hard- und Software implementiert?
Der Ethernet Standard schreibt es vor und wenn man Standard konforme HW betreibt muss es zumindestens enthalten sein. Hat deshalb heute jeder Billigchipset ist aber nirgendwo weder Switch, Router noch Endgerät aktiv.
Und im Falle der Hardware kann es fast nie deaktiviert werden
Das ist so nicht richtig denn es ist generell in allen Netzwerk Endgeräten bekanntlich immer inaktiv! Bringt ja auch nix, denn sollte sowas im Netzwerk aktiv werden hat man ein Congestion Problem und damit, wie schon gesagt, einen groben Designfehler in Bezug auf verfügbarer Bandbreite.
10939953361
10939953361 25.01.2024 um 14:41:03 Uhr
Goto Top
Sorry, aber ich habe mich wohl nicht richtig ausgedrückt.

In einem "Storage Netzwerk" mit Storage Switches kann man das Ganze nicht deaktivieren. Weder bei TCP/IP noch FC, iWARP usw...
Bei z. B. einem Converged Switch wird das Feature spätestens bei DCB oder vergleichbar aktiviert oder ist wie bei FC usw immer aktiv.

Das hat aber nur im entferntesten etwas damit zu tun, was der TO im Treiber seiner Intel NIC sieht.
Selbst der 19,99 Switch hat sowas am laufen, kann es nicht deaktiviert bekommen und kann nur auf wenige Kilobyte zugreifen. Jedes Switch, NIC, SoC usw haben sowas aus Prinzip in die Hardware eingebaut. JEDES.
Bessere Geräte oder spezialisierte Geräte lassen dazu hin und wieder auf Softwareebene zusätzlich etwas mehr Spielraum oder größtmöglich Kontrolle. Ausschalten, im Sinne von Off, ist allerdings mit Stromversorgung gleichzusetzen. Kein Switch als Forwarder kann ohne leben und selbst alte Bridges, die vorher ein Store machen mussten, kommen nicht ohne aus, auch wenn es hier anders abläuft.
10939953361
10939953361 25.01.2024 um 14:45:37 Uhr
Goto Top
Bei der Ruckus-Default Implementierung geht aber "nur" um "Auto-Neg" der "Flowcontrol" und welche Zustände erreicht werdne können als Autimatismus.

Also bitte nicht alles zum Brei verrühren, nur weil es "Flowcontrol" heißt in verschiedenen Fällen. Das Wort beschreibt viele Features und (Quasi)-Standards.

https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...
MysticFoxDE
MysticFoxDE 25.01.2024 um 21:44:12 Uhr
Goto Top
Moin @Spirit-of-Eli,

Der Mechanismus greift nur bei unterschiedlichen Bandbreiten. Bsp. kommen die Pakete mit Gbit an und sollen an einem anderen Port den jeweiligen Switch über einen 100Mbit Port zu einem weiteren Switch verlassen.

jain, den Flowcontrol greift auch dann, wenn zwei Client mit vollem GBit entweder gleichzeitig senden oder empfangen möchten und der Switch an welchen diese dran hängen als Uplink nur 1GBit in Richtung Ziel/Quelle hat. 😉

Sprich, bei höher gleichzeitiger Auslastung durch unterschiedliche Clients mach Flowcontrol auch bei 1G durchaus einen Sinn.

Darüber hinaus funktioniert Flowcontrol nur dann ganz effizient, wenn es in der gesamten Übertragungskette und nicht nur teilweise aktiviert ist.

Gruss Alex
MysticFoxDE
MysticFoxDE 25.01.2024 um 21:50:48 Uhr
Goto Top
Moin @aqui,

In Storage Netzwerken mittlerweile ein NoGo.

ähm, das ist nicht korrekt, im Gegenteil, wenn du ISCSi über nicht Non-Blocking Switche fährst, was bei den meisten übrigens der Fall ist, dann musst du Flowcontrol benutzen um die Übertragung bei hoher Last irgendwie dennoch stabil zu halten.

Gruss Alex
Coreknabe
Coreknabe 26.01.2024 um 09:02:03 Uhr
Goto Top
Moin,

@aqui
Das mag sein ist aber nur die halbe (Handbuch) Wahrheit. Konfigtechnsich ist es global vorbereitet aber nicht aktiv, da die Negotiation NICHT aktiviert ist was man erst mit einem Kommando machen muss. Folglich ist es also nicht aktiv wie bei allen anderen auch!

Man beachte das Kleingedruckte face-wink
Danke für den Hinweis!

Sorry übrigens an den TO, wir scheinen den Thread gekapert zu haben...

Gruß
Spirit-of-Eli
Spirit-of-Eli 26.01.2024 um 09:24:41 Uhr
Goto Top
Zitat von @MysticFoxDE:

Moin @Spirit-of-Eli,

Der Mechanismus greift nur bei unterschiedlichen Bandbreiten. Bsp. kommen die Pakete mit Gbit an und sollen an einem anderen Port den jeweiligen Switch über einen 100Mbit Port zu einem weiteren Switch verlassen.

jain, den Flowcontrol greift auch dann, wenn zwei Client mit vollem GBit entweder gleichzeitig senden oder empfangen möchten und der Switch an welchen diese dran hängen als Uplink nur 1GBit in Richtung Ziel/Quelle hat. 😉

Sprich, bei höher gleichzeitiger Auslastung durch unterschiedliche Clients mach Flowcontrol auch bei 1G durchaus einen Sinn.

Darüber hinaus funktioniert Flowcontrol nur dann ganz effizient, wenn es in der gesamten Übertragungskette und nicht nur teilweise aktiviert ist.

Gruss Alex

Spannendes Thema im Detail. Das war mir so auch noch nicht bewusst.
aqui
aqui 26.01.2024 aktualisiert um 12:06:52 Uhr
Goto Top
und der Switch an welchen diese dran hängen als Uplink nur 1GBit in Richtung Ziel/Quelle hat.
Soviel zum Thema Designfehler nicht nur in Storagenetzen... face-wink
MysticFoxDE
MysticFoxDE 26.01.2024 um 11:30:02 Uhr
Goto Top
Moin @aqui,

und der Switch an welchen diese dran hängen als Uplink nur 1GBit in Richtung Ziel/Quelle hat.
Soviel zum Thema Designfehler in Storagenetzen... face-wink

die Aussage galt auch nicht nur für Storagetraffic, sondern gilt eigentlich bei jeglichem Datenverkehr. 😉

Ausserdem kann ich ISCSi im Primär-SAN-Bereich überhaupt nicht leiden und bei Backup-Storages gehen wir davon auch mittlerweile weg.

Gruss Alex
aqui
aqui 28.01.2024 um 11:22:11 Uhr
Goto Top
Kein Feedback vom TO ist natürlich auch ein Feedback! face-sad

Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?