Ruckus ICX7450 Flowcontrol an oder aus?

Moin @Coreknabe,


by the way, ich wusste bis zu deinem Post nicht wirklich, dass Ruckus Networks auch Schalter ...


... im Programm hat, ich dachte bisher, dass die eher nur auf W-LAN-Kabel und so spezialisiert sind. 🤪

Gruss Alex

Als Netzwerker gilt immer: Kein Flow Control aktivieren! Jeder Switch jedes Herstellers hat das deshalb auch per Default deaktiviert. Es ist deshalb problematisch weil Switchverfahren unterschiedlich sind Store and Forward oder Cut Through. Letztere haben so gut wie keine Port Buffer so das dort Flow Control eh sinnfrei ist. Abgesehen davon ist es keine gute Idee die Infrastruktur als "Paket Buffer" zu nutzen. Bei anderen ist die Ausstattung sehr unterschiedlich. Sehr wenig Port Buffer, viele einfache Switches können Pause Frames nur empfangen aber nicht senden usw.
Wenn generell Flow Control aktiv werden würde hättest du primär ein Design Problem, denn das würde ja nur in Congestion Situationen aktiv werden. Auch bei Storage Protokollen sollten die Endgeräte selber bzw. deren verwendete Protokolle solche Problematiken lösen aber nicht die Infrastruktur.
Was du in jedem Falle außer einem guten, Congestion vermeidenden Designs machen solltest ist Jumbo Framing auf dem Switch zu aktivieren. Das erfordert einen Reboot.
Lesenswert: https://blogs.cisco.com/perspectives/to-flow-or-not-to-flow (Man achte auf das NetApp Papier!)

Ooops, du hast Recht. Ist aber die Ausnahme. Cisco z.B. hat es überall per Default deaktiviert.
Nebenbei: Du betreibst hoffentlich keine uralte, nicht mehr supportete Firmware (8.0.30) in deinem Switch?!
Allein schon eine nicht UFI Firmware zu verwenden ist fahrlässig. Kann man nur hoffen das es ein cut and paste Fehler ist?!

Die Wikipedia hat die Antwort:
https://en.wikipedia.org/wiki/Ethernet_flow_control
Es gibt Flow Control auch für serielle Schnittstellen was aber im Ethernet Umfeld sicher nicht gemeint ist.
Hardware ist das einfache Stop-Pause und Software die IEEE 802.1Qbb Standard basierte Variante.
Was den ICX anbetrifft belasse es auf dem Default. Wenn ein Port das negotiated bzw. negotiaten kann, kann er das machen im Congestion Fall. Wenn es nicht negotiated wird ist es eh deaktiviert. Negative Einflüsse auf die Konfig oder den Betrieb hat es nicht.

Nicht ganz... Per se kann er es ja, nutzt es aber nur dann wenn das Endgerät es unbedingt will und ihn aktiv und höflich danach fragt. 😉
DU hast dich doch selber für die IT entschieden! Da gilt bekanntlich Lesen und Lernen bis zur Rente... 🤣

Moin @Coreknabe,


ja, etwas zumindest, aber dazu war auch eine mitllerweile jahrzehntelange Übung nötig. 🙃


Das was NetApp in seiner Doku als "hardware flow control" ist das klassische Flow Control, welches bei einer Überlastsituation, seitens dessen der am Verschlucken ist lediglich ein Pause Frame versendet. Daraufhin sollte der Datenverkehr am nächsten aktiven Netzwerkknoten kurzzeitig pausiert werden, damit sich der Verschluckende etwas erholen kann. Der Nachteil an dem klassische Flow Control ist jedoch, dass aufgrund des Pause-Frames nicht nur der Datenverkehr pausiert wird, der auch tatsächlich die Überlast erzeugt, sondern jeglicher Datenverkehr Richtung des Verschluckenden, sprich, auch der, der nichts mit dem Verschlucken zu tun hat.

An dieser Stelle muss ich jetzt aber mal kurz sagen, dass bei einer Überlast, jegliche Art der Überlaststeuerung besser ist wie keine davon und dass meiner bisherigen Erfahrung nach, die älteren und simplen Überlaststeuerungen, in der Praxis oft viel besser wie die Neueren funktionieren. 🙃

By the Way, das klassische Flow Control stammt übrigens aus dem Jahr 1997 und wird stand heute noch nicht mal ansatzweise von allen Switchen, Router, NIC's & Co, anständig supportet. 😔

Na ja, wie auch immer, auf jeden Fall haben sich einige daran gestört, dass das klassische Flow Control mit seinem Pause-Frame, eben kurz jeglichen Datenverkehr richtung des Verschluckenden pausiert und nicht nur denn, der quasi auch direkt für die entsprechende Überlast verantwortlich ist und so wurde Ende September 2011 mit IEEE 802.1Qbb, eine erweiterte Form von Flow Control, das sogenannte „priority-based flow control“ oder abgekürzt „PFC“, geboren.

Und bei PFC oder auch DCB wie es heutzutage eher genannt wird, kann man bei einer Überlast, theoretisch zumindest, viel filigraner eingreifen und quasi nur bestimmte Dienste ausbremsen und nicht gleich alles.
Praktisch ist das Ganze jedoch sehr kompliziert, weil man dafür auch ein Regelwerk schreiben muss, was den Meisten jedoch nicht wirklich bewusst ist. Ohne ein Regelwerk ist eine Aktivierung von PFC jedoch absolut sinnlos, weil es schlichtweg ohne ein Regelwerk absolut nichts bewirkt. 🙃

Ferner macht PFC bei einer Schnittstelle über die nur iSCSI Datenverkehr läuft, was in Normalfall auch so sein sollte, überhaupt keinen Sinn, da eben auch nur iSCSI Datenverkehr pausiert werden muss und kein anderer.

Ja, OK, bei so neumodischen Dingen wie „Fully Converged Networks“ sieht die Sache natürlich ganz anders aus, denn da benötigst man PFC/DCB schon eher.

Bei dem Meisten was ich von diesem Fully Converged Murks in der Praxis bisher jedoch sehen musste, habe ich mir gleichzeitig sowohl das Lachen als auch das Weinen verkneifen müssen und das ganz sicher nicht aus Freude. 😔
Alleine schon wegen den ganzen Flüchen die ich diesbezüglich losgelassen habe, komme ich später wahrscheinlich direkt in die Hölle … na ja … dort ist wenigstens warm. 😁

Und ja, ich weiss, Höllenfeuer und Teufel und so … aber … ich habe ja auch einen grossen und mächtigen Hausdrachen und wenn ich mit diesem weiter fleissig übe, dann bekomme ich das Ding mit dem Feuer, also wie man damit umgeht ohne sich dabei die Pfoten zu verbrennen, hoffentlich schon noch gebacken. 🤪

Beste Grüsse aus BaWü
Alex