Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
[Sammelthread]Der 100Gbit Netzwerk Thread, ein bisschen 40gbit und „beyond“ ;)
Hab gerade bei mir zuhause die Verkabelung umgestellt und dann 2h Fiber debugged...
Stellt sich raus: Der Zulieferer hat mir komplett falsche Kabel geschickt. Bestellt war OS2 MTP APC... Die gibt es eigentlich NUR in APC, ich hab die noch nie UPC gesehen (Multimode MTP ist dagegen immer UPC, nie APC).
Bekommen habe ich... OS2 MTP UPC. Bis man darauf kommt (vor allem wenn man eigentlich APC bestellt hatte und es nichts andere gibt) dauert etwas. Hab vorher natürlich alles andere probiert, von Patchkabeln zwischendrin, über meine eigenen MTP Breakout Boxen, etc etc...
Mit einem APC Kabel ging es dann problemfrei. Und statt der -20dBm RX (bei 3dBm TX) kommen jetzt auch 2dBm im RX an.
Ich hab die Verkabelung also erstmal zurückgebaut auf mehrere lange LC Patchkabel. Nicht schön, aber wird funktionieren, bis die Situation gelöst ist.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dass Multimode nie APC ist, liegt daran, dass das MM grundsätzlich keine Sinn macht. Es gab noch die APC bei MM und wird es auch nie geben.
War denn der Stecker das OS2 nonAPC grün oder blau?
Wir haben auch Lieferanten die würfeln, in dem Fall Kupplungen, einfach aus. Da kannste nicht mehr erkennen, was auf der anderen Seite im "Gerät" für nen Stecker ist. Da ist halt echt Müll.
Gelb ist der Stecker, und es war Edge Optic. Sie haben sich auch entschuldigt und tauschen die Kabel aus. Auf der Website stand APC, im internen System stand UPC. Und dann haben sie halt UPC gebaut...
Gehört wohl eher in den 1/10 Gbit Thread. Hatte letzthin bei einem Netzwerkkabel Shop nachgefragt, von welchem Distributor denn Kabel für mein freifliegendes Kupfer Setup zu empfehlen wären. In allen Farben und Längen war die Anforderung. Die nette Inhaberin meinte, ja nimm Cat7a für Dein Setup. Habe den Shop gleich geblacklisted.
Ich spiele gerade mal wieder. Vor allem mit Linux als Gaming-Kiste, aber wenn man schon mal dabei ist, kann man ja auch mal einen Abstecher zum Netzwerk machen! Bisher hatte ich mein Glück ja nur mit Linux als Server versucht (erfolglos). Mit Linux als Client (zumindest mit meiner Distribution Garuda) und WinServer war SMB-Direct aber erstaunlich einfach: Da mein Kernel schon mit SMB-Direct "enabled" kompiliert war, brauchte es nur die Installation der CIFS Utils, einen Mount und ab geht die Post:
Code:
$ sudo pacman -S cifs-utils
$ sudo mount -t cifs //server/share /mnt/smb -o vers=3.1.1,rdma,username=yourname
//check:
$ sudo dmesg | grep CIFS
[ 6294.823205] CIFS: VFS: RDMA transport established
Wenn ich jetzt vom Linux-Client auf's die SMB-Freigabe kopiere, zeigt der Taskmanager wie es sein soll unter Netzwerk keinen Traffic auf der NIC und der Performance Monitor unter den RMDA bzw. SMB Direct Countern Aktivität. Noice.
Leider ist Test-Server (VM mit einem Port der ConnectX-5 per Passthrough durchgereicht) Storage zu klein und lahm für aussagekräftige Zwecke. Aber das hier gefällt:
Bricht aber quasi sofort massiv auf die Storage-Geschwindigkeit ein. Mit sowas kann man sich auch seine SSDs kaputtschreiben.
Coolio, mit der oben verlinkten Anleitung funktioniert RDMA tatsächlich über den Mikrotik.
Wie gewonnen, so zerronnen: ich habe zwar zunächst einen 10Gbit-Switch ausmustern können, aber muss ich jetzt wieder einen 100Gbit-Switch in den Standard-Fuhrpark aufnehmen? Und statt einer Dual-10Gbit NIC, von der nur 1 Port belegt ist, zieht in den Server nun wohl wieder eine Dual-100Gbit-NIC ein, von der beide Ports (1x100, 1x10) belegt sein werden. Wenn ich eh schon dabei bin, kann ich auch die zwei NVME wieder dazu stecken, von denen ich eh noch nicht genau wusste, was ich damit machen wollte…
Der kleine Server war bisher bei 40W Dauerlast, solange ich nicht eine dritte Kiste mit 100Gbit anbinden will und deshalb den Switch brauche, könnte ich mit plus 5-10W (ConnectX-5 statt Emulex plus 2 Gen3 NVME) wegkommen.
Der CRS504-4XQ-IN soll 25W verbrauchen was ja eigentlich wenig ist für einen 4x 100G Switch. Mit 25-100G wird man aber immer Daten zentral halten und bearbeiten. Wenn man Energie sparen möchte ist wohl die Alternative ein oder 2 dual/quad nics im Server (100G, 25G reichen meist und können ja bereits wie eine lokale NVMe ca 3GB/s mit rdma/SMB Direct). Mit den sparsamen Karten wie der Mellanox 4lx sollte man mit DAC Kabeln (max 5m) deutlich unter 10W pro Karte landen. Die anderen Mellanox oder eine Intel mit 4x25G brauchen wohl gerne das Doppelte.
Ja, mir reicht im Prinzip aktuell eine Dual NIC, da ich de facto nur noch einen Rechner habe, der mit 100Gbit angebunden ist. Und der ist wiederum aber selbst voll mit schnellem Storage (12TB NVME gen4, 2TB NVME gen5), so dass es das eigentlich gar nicht braucht...
Ich könnte nen 32 Port 100Gbit Switch zum Einkaufspreis (EUR 234 zzgl Versand) verkaufen… dann kannst Du selbst.
Beitrag automatisch zusammengeführt:
Mal zurück zum Thema RDMA: EIGENTLICH ist es ja immer noch anders herum spannender als das was ich da so frickel', also wie bekommt man möglichst einfach einen RDMA powered FIleserver mit einem freien OS hin...
Ich will ja neben Stromsparen auch noch weg von MS...
Ja, mir reicht im Prinzip aktuell eine Dual NIC, da ich de facto nur noch einen Rechner habe, der mit 100Gbit angebunden ist. Und der ist wiederum aber selbst voll mit schnellem Storage (12TB NVME gen4, 2TB NVME gen5), so dass es das eigentlich gar nicht braucht...
Normalfall dürfte ja ein schnelles (NVMe oder HD+NVMe Hybrid) 25G+ SMB Direkt Primärstorage mit allen aktuellen Daten sein.
Daten werden immer direkt auf dem Storage bearbeitet und per ZFS Snaps versioniert.
Dazu kommt ein (HD) Backup und Redundanzsystem mit stündlichem oder täglichem sync der Daten und eigenen Snaps.
Mit ZFS und inkrementeller Replikation reichen da 2,5-10G um es auszulasten. 25G+ und rdma ist da nice to have.
Dazu kommen ein oder mehrere Workstations mit 25G+ und SMB Direkt.
Da braucht man nur ein kleineres M.2 Bootlaufwerk. Daten werden immer direkt auf dem Storage bearbeitet und gelagert. Das ist ja so schnell wie eine lokale NVMe.
Bis ca 8 Workstations kommt man mit DAC Verkabelung hin (2-4 nics im Server) sofern alle Rechner im gleichen Raum, sonst halt eine Raumverteilung mit 100G Switch.
Ich versuch's mal wieder mit nem Linux "RDMA-powered" SMB-Server für Windows Clients. Oder kurz: mit ksmbd. Die erste Frage ist für mich, mit welcher Distri kommt man out-of-the-box möglichst weit, ohne vertieft selbst einsteigen zu müssen.
Test-Client1: ConnectX-4 mit Garuda Linux
Test-Client2: ConnectX-5 mit Server 2022
SMB-Direct / RDMA funktioniert 1. grundsätzlich im Netz, 2. zwischen dem Server (Server 2022) selbst und Test-Client 2 (Server 2022) und 3. auch Test-Client 2 (jetzt als Server) und Test-Client 1 (Linux). Damit wäre also gesichert, dass beide Clients schonmal mit Windows als SMB-Direct Server können.
Dummerweise geht ksmbd nicht ohne weiteres unter Garuda Linux. Wäre ja auch zu einfach. Also schauen wir doch mal, welche distri besser geeignet wäre…?
Proxmox 9.1-1:
ksmbd im repository, dummerweise wohl immer noch fehlerhaft. SMB-Shares tauchen unter Windows nicht auf. ksmbd service braucht teilweise ewig zum restart. Angeblich geht's mit 'nem Backport - das hat aber schon bei meinen ersten Versuchen damals(tm) nicht hingehauen und daher verfolge ich das erst einmal nicht weiter. Vielleicht später.
CachyOS:
Kein ksmbd in den repositories. Müsste man über AUR nachrüsten. CachyOS eh nur probiert, weil man bei Arch ja grds. den neuesten Scheiss bekommen kann. Gefrickel, außerdem eh kein echtes "Server OS". Vielleicht später, aber eher nie.
Ubuntu 25.10 - wird von den ksmbd Entwicklern wohl selbst benutzt und soll angeblich funzen:
ksmbd im repository.
Kernel mit CONFIG_SMB_SERVER_SMBDIRECT=y ("$ cat /boot/config-$(uname -r)")
Positiv: share einrichten läuft. Access geht, copy geht.
Negativ: RDMA-Counter unter Windows springen nicht an. Last im Task Manager auf der NIC.
Erste Analyse-Versuche:
1.
#CONFIG_CIFS_SMB_DIRECT is not set ... *KOTZ* - Frage die sich stellt: brauch' ich das nun für'n Server oder nicht? Für Testzwecke in die andere Richtung bräuchte ich es jedenfalls, ein mount -t cifs -o rdma wirft nämlich leider die Fehlermeldung:
Code:
[ 3760.034438] CIFS: VFS: CONFIG_CIFS_SMB_DIRECT is not enabled
[ 3760.034928] CIFS: VFS: cifs_mount failed w/return code = -2
2. Ich kann meinen Ubuntu-Server zwar von verschiedenen Maschinen aus pingen, aber eine SMB-Connection klappt nur von dem Host, auf dem die VM läuft... sehr, sehr sonderbar. Wenn ich nicht pingen könnte, würde ich ja tippen, ich hätte mit meiner SR-IOV Konfig irgendwas verbaselt, aber mit ping ist die VM ja erreichbar...?
SR-IOV Konfig ist grds. ok und am fehlenden "CIFS_SMB_DIRECT" auf dem Ubuntu-Server lag der grundsätzlich nicht funktionierende Zugriff auch nicht. Die Lösung war: Auf meinem Test-"Client" (Win Server 2022) waren standardmäßig Unauthorized Guest Account Logons verboten. Darauf kommt man aber mit der Windows-Fehlermeldung beim Share-Zugriff um's Verrecken nicht. Erst ein "net use \\server\share" brachte die Erleuchtung:
You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.
Also als nächstes doch mal nen custom kernel frickeln, in dem die flag enabled ist... *kotz ^2*
P.S.: Wollte eigentlich schon gestern angefangen haben, konnte aber nicht. Aus der Kategorie „selten dämlich“: Ganzen Abend (ca. 3h) vertandelt mit Rumhampeln an der Netzwerkkonfiguration an meinem Haupt-Client (Garuda). Meine Kiste wollte ums Verrecken nicht die gewünschten IPs bzw. Subnetze den "richtigen" NICs zuordnen. Habe wild NICs enabled und disabled, IP-settings manuell gesetzt und zurück, virtuelle NICs und Bridges resetted und gelöscht (hab ja auch ne KVM sowie Docker Umgebung da drupp). Half allex nix. Zwischendurch dann alles komplett verbastelt so dass auch mal gar nichts mehr ging. Wild über die eigene Unfähigkeit mit Linux geflucht (das Verständnis wie Linux netzwerkt sitzt halt noch nicht so tief) - bis ich irgendwann (viel zu spät) gerafft habe, dass ich wohl leider eine physische & logische Verbindung zwischen den beiden Subnetzen in den Switches hatte, die eigentlich hätten getrennt sein sollen... zwei DHCP-Server im gleichen Netz ist halt einfach nicht geil fällt einem dann wieder mal sehr plastisch auf die Füße. Zum Glück ging dann das Wiederherstellen eines funktionierenden Zustands etwas schneller...
P.P.S: Oh mann... wie bastele ich denn am einfachsten den gleichen Kernel nochmal nur mit der dämlichen Option enabled?
#ACHTUNG: NICHT als root:
apt source linux-image-unsigned-$(uname -r)
...und dann wie unter dem Link beschrieben.
P.P.P.P.S: Wenn das dann auch nicht funktioniert, nehme ich vielleicht mal etwas Komplexität heraus und installiere mal ein Ubuntu auf's Blech oder reiche den Port der ConnectX-5 mit DDA/Passthrough an die VM durch. Damit habe ich unter Hyper-V auch schon viel zu lange nicht mehr rumgemacht...
Manmanman. Selbst mit dem modifizierten Kernel lässt sich die Share auf dem Windows-Server nicht mit Option rdma mounten. Ohne geht's. Zum Vergleich: von meinem Hauptrechner mit Garuda-Linux geht es mit rdma. Liegt also irgendwie noch am Setup auf der Ubuntu-Seite.
Ich seh's positiv: vielleicht ist das ja der gleiche Grund, warum es mit Ubuntu als Server nicht klappt. Werd also die Tage mal das Setup vereinfachen. Das MUSS doch irgendwie gehen.
UPDATE: hab jetzt ubuntu server 25.10 auf's blech installiert und RDMA/smbdirect funktioniert NICHT mit ksmbd als server.
Custom Kernel auf'm Blech installiert und mit Ubuntu als CLIENT funktioniert es. Es ist doch echt zum Heulen.
Ich bekomme auch eine RDMA-/SMB-Direct-Verbindung zwischen meinem Gardua-Linux als Client und Ubuntu als Server hin - zumindest bekomme ich die gleiche Meldung (s.u. ganz am Ende) wie zwischen den Linux Clients und Windwos Server und dann funktioniert es ja mit den Windows RDMA Performance Countern. Wenn ich mich mit meinem Linux-Client zum Linux-Server verbinde, zeigt mir ksmbd (sudo journalctl -f) auch brav an, dass Server und Client smb_direct miteinander sprechen!
Mit Windows als Client sehe ich das aber nie! Nur irgendwelchen SMB2 Mist. Da ja es ansonsten klappt, klingt für mich sehr danach, dass Windows-Client und Linux-Server es irgendwie nicht schaffen, SMB-Direct miteinander auszuhandeln. Dabei behauptet Windows, die Linux-Box würde artig 3.1.1 sprechen (10.10.100.110 ist die IP der ConnectX-5 in der Ubuntu-Box):
Was ich noch nicht verstehe: dmesg zeigt mir auf dem Linux-Client folgende Fehlermeldungen (egal ob mit Windows oder Linux als Server), smb-direct funktioniert aber trotzdem (sowohl mit Windows-Server, daher vermutlich auch mit linux-client <--> linux-server):
