17
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
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
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-Key: 3835452190
Url: https://administrator.de/contentid/3835452190
Printed on: April 27, 2024 at 16:04 o'clock
17 Comments
Latest comment
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.
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.
1
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.
Wir priorisieren aber an einigen stellen Traffic. Für Sprache zum Beispiel oder wenn unzählige Clients zum Dienstbeginn den SCCM leechen wollen.
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
Gruß
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
Gruß
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
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
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.
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ß
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ß
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.
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! 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.
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.
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.
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 ...
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 ...
Moin @Spirit-of-Eli,
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
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
Moin @aqui,
ä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
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
Moin,
@aqui
Man beachte das Kleingedruckte
Danke für den Hinweis!
Sorry übrigens an den TO, wir scheinen den Thread gekapert zu haben...
Gruß
@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
Danke für den Hinweis!
Sorry übrigens an den TO, wir scheinen den Thread gekapert zu haben...
Gruß
1Zitat von @MysticFoxDE:
Moin @Spirit-of-Eli,
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
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.
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...
Moin @aqui,
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
und der Switch an welchen diese dran hängen als Uplink nur 1GBit in Richtung Ziel/Quelle hat.
Soviel zum Thema Designfehler in Storagenetzen... 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
Kein Feedback vom TO ist natürlich auch ein Feedback! 
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
How can I mark a post as solved?
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
How can I mark a post as solved?