herb99
Goto Top

2 Rechner (Ubuntu und freeBSD (freeNAS)) mit zusätzlichen Netzwerkkarten im bestehenden LAN direkt verbinden - Routing?

Hallo!

Ich habe ein bestehendes LAN im Bereich 10.0.10.X mit einer pfSense (10.0.10.1), einem Gbit-Switch und einigen Rechnern (freeNAS, vdr, Desktop).
vdr hat die 10.0.10.6
freeNAS hat die 10.0.10.7

Ich habe nun sowohl vdr als auch freeNAS mit einer zusätzlichen 10Gbit-Karte ausgestattet und jeweils feste IP's ohne Gateway mit Netzmaske 255.255.255.0 konfiguriert.
vdr hat zusätzlich die 10.0.20.6
freeNAS hat zusätzlich die 10.0.20.7

Beide Rechner sollen weiterhin aus dem normalen LAN für andere Geräte über die alten Netzwerkkarten im Bereich 10.0.10.X erreichbar bleiben.
Die Kommunikation zwischen den beiden Systemen soll aber ausschließlich über das Netz 10.0.20.X laufen.

Im Moment bekommen alle Netzwerkkarten die gewünschten IP's und auch ein ping klappt im Bereich 10.0.20.X in beide Richtungen.

Wenn ich nun aber eine nfs-Freigabe vom freeNAS (nur 10.0.20.6 erlaubt für Zugriff) am vdr mounte, so klappt zwar der mount, aber beim Kopieren größerer Dateien geht die Geschwindigkeit irgendwann gegen Null und der Vorgang muß abgebrochen werden.

Was muß ich hier noch ändern um die beiden Systeme mit festen IP's nur über die 10Gbit-Nic's miteinander "sprechen" zu lassen?

Vielen Dank!

Content-ID: 353321

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

Ausgedruckt am: 25.11.2024 um 15:11 Uhr

aqui
aqui 31.10.2017 aktualisiert um 12:08:47 Uhr
Goto Top
Das erklärt alles was du zu tun hast:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
  • Neues IP Netz definieren (Hast du gemacht)
  • IPv4 Forwarding auf dem Ubuntu aktivieren !
  • Statische Route auf der pfSense definieren !
  • Fertisch !
Mehr ist nicht zu tun. Siehe Tutorial oben.
Was muß ich hier noch ändern
Nix...jedenfalls nix was das IP Routing anbetrifft. NFS solltest du mit UDP Enkapsulierung laufen lassen.
herb99
herb99 31.10.2017 um 12:38:19 Uhr
Goto Top
Danke für Deine Antwort!

ip_forwarding hab ich gerade mal aktiviert. Danach funktioniert am vdr der Internetzugang nichtmehr - obwohl die IP's stimmen.
Ist wohl so weil ich auf der pfSense noch keine statische Route definiert habe, oder?

Warum muß auf der pfSense überhaupt eine statische Route eingerichtet werden?
Die weiß doch eigentlich nix von dem neuen Netz und das alte Netz besteht ja weiterhin.

Netzwerk ist echt nicht mein Ding ;)
aqui
aqui 31.10.2017 aktualisiert um 13:07:44 Uhr
Goto Top
Danach funktioniert am vdr der Internetzugang nichtmehr
Daraus kann man dann nur schliessen das du vergessen hast eine Default Route oder default Gateway am Ubuntu auf die pfSense zu setzen !!
Ohne das ist es logisch das das dann in die Hose geht !
netstat -rn zeigt dir die Routing Tabelle auf dem Ubuntu ! Und ein traceroute -n 8.8.8.8 zeigt dir den Weg der IP Pakete Hop für Hop ins Internet.
Netzwerk ist echt nicht mein Ding
Das merkt man leider...und genau deshalb gibt es hier die oben genannten Tutorials face-wink
LordGurke
LordGurke 31.10.2017 um 13:28:18 Uhr
Goto Top
@aqui:
Er will ja, dass der Traffic nicht über den 1G-Switch läuft sondern über die 10G-Direktverbindung.
Da wäre eine Route über die pfSense vollkommen kontraindiziert face-wink

Das müsste auch eigentlich automatisch funktionieren, wenn er auf die 10G-Interfaces die 10.0.20.x/24 konfiguriert und die Freigabe über ebendiese IP-Adressen mounted.
Von daher wäre die Frage, auf welchen Interfaces du welche IP-Adressen konfiguriert hast und wie die Routingtabelle auf beiden Systemen aussieht ("ip -4 route list") - um sicherzustellen, dass der Traffic richtig fließt.
Wenn der Traffic korrekt fließt könnte es durchaus ein Kabel- oder Treiberproblem sein. Lasse dir mal mit "ifconfig" anzeigen, wie die Fehlercounter auf den 10G-Interfaces aussehen.
aqui
aqui 31.10.2017 aktualisiert um 13:43:39 Uhr
Goto Top
Da wäre eine Route über die pfSense vollkommen kontraindiziert
Der Einwand ist berechtigt aber kontraindiziert ist die Route denke ich nicht, denn sie sollte ja nicht stören. Sie dient lediglich dazu das Clients aus dem Netz an der pfSense die die pfSense als Gateway haben Geräte im "NAS Netz" erreichen können z.B. zu Management Zwecken etc.
Der Ubuntu Server wird ja dann so oder so ein ICMP Redirect senden das die Clients danach dann direkt über den Ubuntu gehen.
Für den Ubuntu selber ist die Route egal, da er das NAS Netz ja direkt angeschlossen hat und so die Route für ihn gar nicht zum Tragen kommt. Er wird immer direkt das 10G NAS Interface (NIC) nutzen um Daten vom NAS zu holen.
Sein Design sieht ja vermutlich so aus:

(Internet)===(pfSense)---lokalesLAN---(NIC1_Ubuntu_NIC2)---NAS_LAN---(NAS)


Klassisches Design aus dem Tutorial also.
LordGurke
LordGurke 31.10.2017 um 13:43:10 Uhr
Goto Top
Die Frage ist, ob es gewünscht ist, dass aus dem Client-Netz zugegriffen werden kann. Normalerweise will man das bei diesem Netzwerkdesign ja vermeiden...
aqui
Lösung aqui 31.10.2017 aktualisiert um 13:47:49 Uhr
Goto Top
OK, keine Frage ! Da hast du natürlich absolut Recht. Das ist die grundsätzliche Frage.
Wenn dem so ist und es nicht gewollt ist, dann sollte diese statische Route auf der pfSense natürlich entfallen.
Oder sollte es gewollt sein....eine entsprechnde Firewall Regel eingerichtet sein die den Traffic aus diesem Netz ins NAS Netz entsprechend regelt.
Das muss der TO entscheiden.
herb99
herb99 31.10.2017 aktualisiert um 15:09:28 Uhr
Goto Top
Hallo nochmal!

LordGurke hat mich richtig verstanden. Es geht mir ja nicht darum zwei Netze miteinander zu verbinden, sondern ich möchte sozusagen auf ein bestehendes Netz eine weitere Kommunikationsschnittstelle für 2 Rechner schaffen. Der Rest der aktuellen Funktionalität soll dadurch absolut nicht beeinträchtigt werden. Es gibt ja "historisch gewachsene" Dienste und Zugänge an denen ich nicht rütteln will und für die auch die 1Gbit-Verbindung völlig ausreichend ist.

Momentan scheint es jedenfalls zu laufen, warum auch immer es erst garnicht wollte, Manchmal hilft eben doch ein Reboot ;)

Ich habe allerdings nach wie vor instabile Übertragungen per nfs, aber das ist dann eine andere Baustelle.

Zur Kontrolle:

aktuelle Lage im 1Gbit-Netz:

pfSense
10.0.10.1

vdr
IP: 10.0.10.6
M: 255.255.255.0
GW: 10.0.10.1

freeNAS
IP: 10.0.10.7
M: 255.255.255.0
GW: 10.0.10.1

neue NIC's:
vdr
IP: 10.0.20.6
M: 255.255.255.0
GW: nix

freeNAS
IP: 10.0.20.7
IP: 10.0.20.7
M: 255.255.255.0
GW: nix

Ich kann Freigaben auf dem vdr mounten. Gleiche nfs-Freigaben auf den 1Gbit-Nic's laufen schon seit Jahren fehlerfrei.
Auf den beiden 10Gbit-NIC's gibt ein Test mit iperf:

easyvdr@easyVDR:~$ iperf -c 10.0.20.7
Client connecting to 10.0.20.7, TCP port 5001
TCP window size: 325 KByte (default)
[ 3] local 10.0.20.6 port 54518 connected with 10.0.20.7 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.5 GBytes 9.89 Gbits/sec

Zur Sicherheit mal noch die Ausgaben von "netstat -rn"

freeNAS:

root@freenas:/ # netstat -rn
Routing tables

Internet:
Destination Gateway Flags Netif Expire
default 10.0.10.1 UGS alc0
10.0.10.0/24 link#1 U alc0
10.0.10.7 link#1 UHS lo0
10.0.20.0/24 link#3 U mlxen0
10.0.20.7 link#3 UHS lo0
127.0.0.1 link#2 UH lo0>

vdr:

Kernel-IP-Routentabelle
Ziel Router Genmask Flags MSS Fenster irtt Iface
0.0.0.0 10.0.10.1 0.0.0.0 UG 0 0 0 eth0
10.0.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
easyvdr@easyVDR:~$



Es läuft also. Ich werde mich jetzt mal eher weiter damit beschäftigen warum die Übertragungen irgendwann bis auf Null einbrechen.
Als ich noch mir meinem Desktop-PC und dem freeNAS getestet habe gab es solche Probleme nicht. Die Harware ist also sicher ok.

Danke!!
LordGurke
LordGurke 31.10.2017 um 15:26:24 Uhr
Goto Top
Es könnte sein, dass die Network-Buffer für NFS nachjustiert werden müssen - du kannst über die Mount-Optionen "rsize" und "wsize" steuern, wie groß die Blöcke sind die Übertragen werden, bis ein ACK benötigt wird. Das reduziert theoretisch die CPU-Last, erhöht aber prinzipiell auch die Auswirkungen, wenn tatsächlich mal Pakete verloren gehen - dann kommt erstmal alles massiv ins Stocken.

Beobachte auch mal die Load-Average und CPU-Auslastung auf beiden Systemen während einer Dateiübertragung.
Vielleicht schaffen die Festplatten resp. der Controller auch einfach diese Geschwindigkeiten nicht, was bei theoretisch ~1 GByte/s zwar eher unwahrscheinlich ist, aber...

Nachdem die Systeme direkt verkabelt sind kannst du auch mal testweise die MTU auf 9000 Bytes erhöhen (sofern die NICs das mitmachen) und die rsize beim Mount auf Werte um 1152000 festlegen (das wären 128 x 9000 Bytes - also 128 Blöcke, die übertragen werden, ohne dass die Gegenstelle dies bestätigen muss).
herb99
herb99 31.10.2017 aktualisiert um 16:45:18 Uhr
Goto Top
Das ist verdammt merkwürdig!
Ich habe jetzt schon diverse Kombinationen durchgetestet - wahrscheinlich ohne wirklich eine Strategie dabei zu haben ;)

Die CPU-Last kann man auf beiden Systemen vernachlässigen - das schaffen die beide locker.

Ich teste aktuell mit den von Dir angegebenen Werten von 1152000 für rsize und wsize beim mount-Befehl.

Ich lasse in verschiedenen Terminals htop und ethstatus für den 10Gbit-Nic auf dem vdr anzeigen.
In einem weiteren Terminal sehe ich den Inhalt der Freigabe auf dem freeNAS.

Wenn ich nun in einem weiteren Terminal ( ;) ) auf dem vdr mit

dd if=/dev/zero of=/media/vdr_auf_freenas/dd-testfile bs=4M count=200

eine Datei generiere, so zeigt mir das Terminal mit ethstatus gute 620MByte pro Sekunde (entspricht etwa dem Maximum meines Raid-Z2) für etwa 2 Sekunden an.
Logisch - in der Zeit wird eine Datei von 800MByte auf dem freeNAS geschrieben.

Auf dem freeNAS ist diese Datei nach den knapp 2 Sekunden auch schon zu sehen und ändert sich nicht mehr in der Größe.

Nun aber der Knaller:
Das dd-Kommando im Terminal des vdr wird erst nach ca. 86 Sekunden beendet und zeigt dann eine Geschwindigkeit von etwa 9,8 MB/s.

Wie kann das sein?
LordGurke
LordGurke 31.10.2017 um 16:56:48 Uhr
Goto Top
Das wird offenbar lokal im RAM gebuffert und dann (langsamer) per Netzwerk übertragen.
Daher auch die Wartezeit, weil der das Programm nicht beenden kann, solange Daten gescgrieben werden.
herb99
herb99 31.10.2017 um 17:11:15 Uhr
Goto Top
Warum zeigt dann ethstatus für den 10Gbit-Nic eine Übertragung von gut 620MByte/s an?
Und auf dem freeNAS ist die Datei ja auch schon nach kurzer Zeit komplett da.

Das verstehe ich nun wirklich nicht....
aqui
aqui 31.10.2017 aktualisiert um 18:20:10 Uhr
Goto Top
sondern ich möchte sozusagen auf ein bestehendes Netz eine weitere Kommunikationsschnittstelle für 2 Rechner schaffen.
Nicht das wir uns dann da falsch verstehen !
Das geht natürlich grundsätzlich aber nur solange die beiden 10G NICs isoliert und einzeln mit einer Patchstrippe verbunden sind. Es darf keinerlei Draht irgendwo ins andere IP Netz gesteckt werden.
Wenn das gegeben ist ist das OK und natürlich kann dann die Route in der FW entfallen.
620MB = 5 Gig. Das ist kein berauschender Durchsatz !
Hast du auf dem NAS und dem Ubuntu Jumbo Frames auf den 10G NICs aktiviert ? Das solltest du zwingend machen.
https://www.cyberciti.biz/faq/rhel-centos-debian-ubuntu-jumbo-frames-con ...
Der Lord hat das ja richtigerweise schon angemerkt.

Du solltest auf beiden Systemen mit aktiviertem Jumbo mal NetIO laufen lassen:
https://web.ars.de/netio/
bzw.
Netzwerk Management Server mit Raspberry Pi
Das gibt wenigstens verlässliche Werte zurück die unabhängig vom Protokoll und der Paketsize ist.
Sofern auf beiden Systemen unixoide OS laufen rennt das da problemlos.
herb99
herb99 31.10.2017 um 19:11:17 Uhr
Goto Top
Die beiden 10Gbit-Karten sind direkt verbunden.
Ich hatte vorher meinen Win10-Desktop mit dem freeNAS mit der 10er Nic's verbunden.
Da hatte ich aus einer Softramdisk nahezu das Maximum an Geschwindigkeit - beide Seiten cachen ja auch.
Die 620MByte/s sind in etwa das physische Maximum was mein Raid schafft zu schreiben. Da hängen 6 4TB-Platten extra an einem HBA-Controler in einem x8-Steckplatz. Der Xeon hat damit eh keine wirklichen Probleme ;)

Da das freeNAS in der Konstellation mit dem Win10-PC normal funktionierte (habe da auch mtu=9000 in den Options der Netzwerkkarte angegeben), denke ich, das ich ein Problem beim vdr habe.

Mal gucken....das wird wohl ne größere Teststrecken.....

Danke das Ihr euch bisher auch nen Kopf gemacht habt.

Schönen Abend noch!
aqui
aqui 01.11.2017 um 11:16:18 Uhr
Goto Top
nahezu das Maximum an Geschwindigkeit - beide Seiten cachen ja auch.
Gemessen mit was ?? Hoffentlich dann ohne eine Protokollbindung wie SMB/CIFS, FTP, NFS usw. !
Letztere verfälschen immer das Ergebnis.
Aber es hört sich in der Tat dann wirklich so an das das NAS hier NICHT der böse Buhmann ist.
Am VDR dann checken das die NIC auch im richtigen PCIe Slot mit den entsprechenden Lanes steckt !
herb99
herb99 01.11.2017 um 13:15:51 Uhr
Goto Top
Gemessen wurde mit dd direkt auf dem zfs-Dateisystem (ohne Kompression) auf dem freeNAS, also ganz ohne Netzwerk.

Ich bin gerade dabei die 30m Glasfaserkabel wieder durch die Bude zu zotteln und werde erneut mit einem 10er Nic im Win10-Rechner testen.

Mal sehen was rauskommt....

Gruß!
herb99
herb99 01.11.2017 um 13:51:01 Uhr
Goto Top
Hier unter Win10 mal ohne irgendwelche Optimierungen (JumboFrames sind aktiviert) aus dem Cache des freeNAS in eine SoftRamDisk übertragen. War teilweise bei 990MByte/s.
Die Hardware läuft also problemlos und auch das freeNAS macht was es soll, wenn ich mal bedenke das ich keinerlei SSD's für ARC oder so benutze.

10gnic
aqui
aqui 01.11.2017 um 14:13:24 Uhr
Goto Top
War teilweise bei 990MByte/s.
Was ein sehr guter Wert ist bei diesen Rahm,enbedingungen !
Fazit also: der VDR.
LordGurke
LordGurke 01.11.2017 um 15:10:43 Uhr
Goto Top
Was sagt denn die Load-Average auf dem VDR während hoher Netzwerklast?
Kann durchaus sein, dass zu wenig Interrupt-Operationen zur Verfügung stehen bzw. irqbalanced installiert werden muss damit ausreichend Softinterrupts zur Verfügung stehen.
herb99
herb99 01.11.2017 um 16:39:27 Uhr
Goto Top
Nein, im vdr steckt das gleiche Board wie im Desktop-PC.
Und im vdr ist viel weniger verbaut. Das scheidet aus denke ich.....
LordGurke
LordGurke 01.11.2017 um 16:45:25 Uhr
Goto Top
Das Interrupt-Handling, insbesondere die Zuteilung von Soft-Interrupts ist eine Einstellung des Kernels. Wenn das unterschiedliche Distributionen sind, ist es durchaus möglich, dass auf dem VDR die Einstellungen suboptimal sind.
Sollten nicht genügend Interrupts zur Verfügung stehen, kannst du das anhand der Load-Average sehen, alternativ in "top" als "SI"-Wert.
herb99
herb99 01.11.2017 um 16:55:02 Uhr
Goto Top
Ok, momentan ist die Karte aber nicht im vdr und ich bin eh am überlegen ob ich nicht komplett auf 10Gbit umstelle.
Hängt davon ab wie die nächsten Tage so laufen.
Momentan will Win10 z.B. absolut kein iSCSI-Target vom freeNAS über den 10Gbit-Nic finden, obwohl es anzeigt auch an dieser Schnittstelle zu suchen.

Das sind eben so die DInge die ich erstmal hinbekommen muß bevor weiter umgerüstet wird ;)

Trotzdem vielen Dank für Eure Gedanken zum Thema!!
herb99
herb99 02.11.2017 um 09:39:02 Uhr
Goto Top
Hier mal zwei Bilder vom Benchmark mit verschiedenen Dateigrößen.
Ich denke ich werde mal doch 2 SSD's als ARC einbauen und gucken wie es dann aussieht....

cdm_lauf1
cdm_lauf2
aqui
aqui 02.11.2017 um 14:47:08 Uhr
Goto Top
und ich bin eh am überlegen ob ich nicht komplett auf 10Gbit umstelle.
Uuhhh.... böses Faul ! Hattest du etwa nur die 10G Karte im NAS und im VDR nur 1 G ??
Das wäre tödlich bei TCP pasierten Storage Protokollen weil es dann unweigerlich zum Buffer Bloating kommt:
https://en.wikipedia.org/wiki/Bufferbloat
Sowas funktioniert ausschliesslich nur wenn Layer 2 Flow Control auf NIC und Switch aktiviert ist.
Also die direkte Verbindung VDR - NAS sollte schon 10G auf beiden Seiten sein !
10G im Heimnetz macht wenig Sinn. Hier reicht es wenn du ggf. mit LACP LAGs arbeitest im VDR um etwas Lastverteilung dahin zu machen.
herb99
herb99 02.11.2017 um 16:03:32 Uhr
Goto Top
Uuhhh.... böses Faul ! Hattest du etwa nur die 10G Karte im NAS und im VDR nur 1 G ??

Nene, keine Sorge ;)

Ganz sooo übel stell ich mich dann doch nicht an. face-smile

Es ging immer um ein normales Gigabitnetz in dem ich zwei der Rechner zusätzlich mit 10Gigabit direkt verbunden habe.
Funktioniert momentan mit dem Win10 per iSCSI auf dem freeNAS auch super.

atto