PFSense und Transferprobleme

Moinsen!

Was passiert denn nach den 3 Sekunden??? Fertsch? Oder von vorn?

Unter "Advanced" gibt es Settings mit denen man an Einstellungen der Netzwerkinterfaces drehen kann.


Evtl. bringt dich das weiter. Was sagt die CPU-Last? Worauf ist die PfSense installiert? Virtuell? Welche Hardware?

Hatte das aber noch nie und tappe auch im Dunkeln...

VG
Buc

Hmmm... Soll das virtuell auch produktiv gehen? Kannst du ohne viel Aufwand die PfSense auf ner eigenen Hardware 1:1 aufsetzen?
Das ist irgendwas mit der VM und den Interfaces vermute ich.

Evtl. kommt ja noch @aqui ins Boot. Der könnte einige virtuelle PfSensen betreiben ohne die produktiv je nutzen zu wollen und ne Idee haben.

Ich würde mal die vorhergehende Version installieren. Könnte ja ein Bug sein. Im PfSense Forum lesen die Entwickler mit. Besser auf Englisch posten. Wäre dann mein nächster Schritt.

Sorry, nix besseres parat... Good Luck!
Buc

Hallo.

Ich habe mich mal von einem ESX Guru belehren lassen, dass man bezüglich Kompatibilität und Stabilität auf den VMXNET 3 Adapter-Typ gehen sollte.

Das mal probiert?

Gruß
Marc

Das dürfte vermutlich auch die Ursache sein. Kollege @LordGurke hat es oben schon richtig angesprochen das manche Treiber nicht richtig mit dem VLAN Tagging umgehen können und daraus MTU Problematiken resultieren. Es gibt diverse Einträge dazu in der pfSense Knowledgebase. Es ist also vermutlich der verwendete VmWare NIC Treiber bzw. spricht dafür einen anderen zu nehmen. Siehe Post des Kollegen @luci0815 unten !
Könnte man einmal verifizieren indem man ein reines LAN Interface beidseitig verwendet ohne eins mit 802.1q Erweiterung. In einer HW Appliance ist dieser Effekt nicht reproduzierbar. Auch nicht im 802.1q Umfeld mit entsprechend supporteten NICs.
In den Advanced Settings sollte Power D immer auf Highadaptive stehen.

For best performance, use VMXNET 3 type of adapters instead of E1000.

https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-esxi.html

Open-VM-Tools installiert?

Ich glaube eher, es war gemeint, dass du das VLAN-Tagging nicht in der pfSense machen sollst sondern auf der Hardware.
Dort reichst du der pfSense dann untagged die richtigen Interfaces/Bridges herein.

Es sind schon einigen Hinweise gegeben worden, die sich auf die pfSense / den ESX als solche(n) beziehen.

Indes halte ich bei der von Dir beschriebenen Typik des Kopiervorgangs eine ganz andere Ursache für naheliegend(er). Es spricht sehr viel für eine "Überlastung" oder eingeschränkte Leistungsfähigkeit des Plattensubsystems des Hosts. Höchstwahrscheinlich sind alle logischen Datenträger, auf denen die virtuellen Datenträger der VM's vorgehalten werden, direkt im Host eingebaut - erwartungsgemäß für ein Testsystem.

Mit dem kraftvollen Start des Kopiervorgangs wird zunächst der Schreibcache des Zieldatenträgers befüllt. Aber der eigentliche Schreibvorgang kommt bei weitem nicht hinterher. Daher muss der Kopiervorgang (= die Datenübertragung zwischen den beteiligten VM's) pausieren. Sobald der Schreibcache ein wenig geleert ist, gibt es ein kurzzeitiges "Aufflammen" des Kopiervorgangs, um wieder zu pausieren. Die Ursache für dieses Verhalten kann einmal in der Verwendung des Onboard-Controllers anstelle eines leistungsfähigen Hostcontrollers liegen. Andererseits kann das Ziellaufwerk zu langsam oder zu fragmentiert oder ... sein. Selbst eine nicht optimale Erstellung der virtuellen Datenträgerdatei kann einen Leistungseinbruch bewirken, z.B. Blockgröße.

Hier wäre zu prüfen, ob die logischen Hostdatenträger optimal konfiguriert sind, insbesondere hinsichtlich der verwendeten RAID-Level (z.B. 5). Ebenso benötigt der Hostcontroller einer optimalen Konfiguration. Ferner können sich das (virtuelle) Quell- und das Ziellaufwerk gegenseitig "behindern", wenn sie auf demselben logischen Hostdatenträger vorgehalten werden. Ohnehin ist zu prüfen, wie stark das Plattensubsystem durch die VM's ausgelastet ist. So könnte der Kopiervorgang auf der pfSense einen erhöhten Schreibbedarf bewirken, wenn der zugewiesene RAM zu klein ist. Das ist ohnehin ein Thema für alle ()physischen und) virtuellen Rechner, wenn der zu knapp zugewiesene RAM einen erhöhten Auslagerungsbedarf nach sich zieht.

Alle VM's / der Host stehen in Konkurrenz bei dem Zugriff auf das Plattensubsystem. Da bei Dir das Problem reproduzierbar ist, spricht alles für das Erreichen einer Leistungsgrenze. Hingegen würde ich wegen des kraftvollen Starts des Kopiervorgangs und dessen zwischenzeitlichen Aufflammens darauf tippen, dass der Datenaustausch über die LAN-Verbindung als solche eher keine nennenswerte Einschränkung erfährt; auszuschließen als verstärkende Ursache ist es gleichwohl nicht.

Jedenfalls kann ich auf einem hiesigen Virtualisierungshost, bei dem alle logischen Datenträger an einem leistungsfähigen Hostconroller angeschlossen sind, bei bestimmten Kopiervorgängen, insbesondere wenn Quelle und Ziel letztlich auf demselben logischen Datenträger liegen, gelegentlich dieselbe Typik beobachten. Seit ich den einen logischen Datenträger von SATA-II-SSD auf SATA-III-SSD umgestellt habe, hat sich das deutlich entschärft (der Hostcontroller kann SATA-III). Übrigens besteht die Tendenz, dass das Kopieren von größeren Dateien mit Schreibleistungen bis um 260 MB/s abläuft, während viele kleinere Dateien nicht so richtig Fahrt aufnehmen. Das ist ja auch logisch mit Blick auf den Verwaltungsaufwand des Dateisystems für jede Datei beim Kopieren.

Viele Grüße
HansDampf06

Besser du nutzt dann auch die korrekte Schreibweise MB (Byte) oder Mb (bit) sonst weiss bald keiner mehr was wirklich gemeint ist...

Bist Du Dir da wirklich absolut sicher? Wenn Du selbst schon verschiedene Versionen des ESX / der pfSense sowie verschiedene NIC-Treiber ergebnislos ausprobiert hast, muss die Ursache ja an einer anderen Stelle liegen ...

Der Unterschied ist doch, dass einmal der Paketfilter nichts zu tun hat (= volle Fahrt) und ein anderes Mal ist er voll mit drin (= Fahrt relativ schnell auf dem Nullpunkt). Der Paketfilter benötigt zur Datenverarbeitung eine gewisse Zeit. Das führt zu einer zeitlichen Verzögerung. In der Zwischenzeit laufen aber "gnadenlos" weitere Pakete auf, die auf ihre Verarbeitung warten und deshalb zwischengespeichert werden müssen. Und wo erfolgt die Zwischenspeicherung, wenn der RAM der pfSense dafür nicht groß genug ist? Genau! Ab mit dem Paket auf die Festplatte (Der Datenstrom pausiert erst dann, wenn die Verarbeitung / Zwischenspeicherung die Entgegennahme weiterer Pakete ausschließt). Daher muss das Paket in die Warteschlange des Hostdatenträgers eingereiht werden. Sobald das Paket an der Reihe ist, muss es von der Festplatte zurückgeholt werden. Wenn Du jetzt auch noch die beteiligten virtuellen Datenträger des Servers (= Quelle), des Clients (= Ziel) und der pfSense (= Zwischenspeicherung) auf ein und demselben logischen Hostdatenträger hast, ist dieser Hostdatenträger mit insgesamt 4 IOPS befasst: Quelle lesen, pfSense schreiben, pfSense lesen, Ziel schreiben und das Ganze bei einer 4-GB-Datei, so dass jedweder Cache saturiert wird. Hinzukommt, dass gegebenenfalls auch Teile des Programmcodes ausgelagert werden, die immer wieder erneut eingelesen und wieder ausgelagert werden müssen - immerhin gibt es auf einer pfSense nicht nur einen aktiven Task, sondern derer eine erquickliche Zahl (zwei-/dreistellig). Schon deshalb erscheint es mir naheliegend den Flaschenhals RAM und/oder Plattensubsystem einmal näher unter die Lupe zu nehmen.

Selbstverständlich können jetzt noch die von @LordGurke / @aqui beschriebenen Probleme die ganze Sache verschlimmern, weil beispielsweise der unpassende MTU-Wert zu einer weiteren Aufsplittung des Datenflusses und somit denkbar zu einer Erhöhung des Zwischenspeicheraufwands führen kann. Ist dann noch ein suboptimaler Treiber involviert, hast Du vier zusätzliche Bremsen (Server out, pfSense in/out, Client in). Je nachdem, wie die virtuelle Netzwerkkarte die ein-/ausgehenden Pakete zwischenspeichert, kann das wiederum Auswirkungen auf den Umfang des von dem Paketfilter nutzbaren RAM haben bzw. den Zugriff auf diesen verlangsamen.

Ob die pfSense hinsichtlich des RAM zu knapp bemessen ist, ist ja leicht prüfbar. Ein erster Blick könnte mit top erfolgen, ob gemäß den Angaben zur Speichernutzung eine Inanspruchnahme des swap im Raum steht. Sodann könnten für eine präzisere Untersuchung während des Kopiervorgangs in einem bestimmten Intervall (z.B. alle 10 Sekunden) die Speicherdaten geloggt werden. Zumindest könnte das ein Einstieg sein, um das Plattensubsystem als Phänomen-Ursache erkennen oder ausschließen zu können. Dasselbe gilt für die anderen Beteiligten: Server, Client, Host.

Bei meinem Hinweis auf das Plattensubsystem geht es natürlich um eine Gesamtbetrachtung des Virtualisierungshosts, weil sich hier die verschiedenen VM's wechselseitig beeinträchtigen können. Ist der Virtualisierungshost dann auch noch insgesamt schon gut ausgelastet, kann sich das in Leistungseinbrüchen an unerwarteter Stelle spürbar auswirken, ohne dass es gleich greifbar ist. Insoweit resultiert mein Hinweis aus der hiesigen Praxiserfahrung. Freilich liegt der Rest ganz allein bei Dir ...

Wenn Du alle Anregungen als untauglich vom Tisch wischt, erübrigen sich wahrscheinlich zusätzliche Gedanken an die Zahl der vCPU's, den Typus der VHDX, die NUMA-Einstellungen etc.

Viele Grüße
HansDampf06

@hansdampf:
Nein. Einfach nein. Das ist nicht, wie Netzwerkprotokolle und Router funktionieren!
Der Paketbuffer des gesamten Betriebssystems ist begrenzt, üblicherweise auf deutlich weniger als 100 MB.
Dieser ist auch nur dafür da, die Daten zu halten, solange sie nicht an irgendeine Anwendung abgegeben werden können.

Alles, was dann kommt und nicht mehr passt, wird einfach verworfen und muss neu angefordert und gesendet werden.

Hat die pfSense zu wenig RAM, wird der Paketbuffer einfach dynamisch verkleinert. Auf jeden Fall aber wird dieser nicht auf die Festplatten ausgelagert.

Und: Dieser Paketbuffer wird nicht voll laufen, da bei TCP maximal die Größe des Transmission Window vom Sender übertragen wird. Dann wartet dieser auf ACK und wenn das nicht kommt (der Empfänger hat ja nichts bekommen), kommen auch keine weiteren Daten.
Diese Window Size ist selbst in 10G-Netzen mit Jumbo-Frames selten größer als 30-40 MB.

Mir kommt gerade eine Sache in den Kopf...
Da wir von SMB reden: Greifst du per Name oder explizit über die IP auf die Freigabe zu?
Und falls Name: Hast du in der pfSense Regeln für IPv6 eingerichtet?
Bei Zugriff per Name löst dieser natürlich bevorzugt auf IPv6 auf, so dass kaputte IPv6-Filterregeln dir das Leben schwer machen könnten.

@LordGurke: O.K., wenn mangels ausreichendem Pufferspeicher verworfen und nicht zwischengespeichert/ausgelagert wird, dann können jedenfalls keine zusätzlichen IOPS anfallen.

Das vom TO beschriebene Phänomen, dass der Kopiervorgang zum Anfang wohl volle Fahrt hat und dann nachhaltig einbricht mit periodischer Zwischenaktivität, spricht jedenfalls dafür, dass irgendetwas im Verlauf des Kopiervorgangs vollständig saturiert wird und die Sättigungsgrenze nur periodisch verlässt. In drei Sekunden wird augenscheinlich das an Datenmenge nachgeladen, was zuvor in 19 Sekunden abgearbeitet wurde. Das jeweilige 3-Sekunden-Fenster lässt zumindest eine größere Datenmenge als nur 30-40 oder 100 MB erwarten. Falls nicht, wären 19 Sekunden für diese relativ kleine Datenmenge echt krass. Weil das Phänomen nur auftritt, wenn der Paketfilter involviert ist, muss sich entweder dessen Abarbeitungsprozess (/ Vorfeld / Nachfeld) sukzessive irgendwo "aufstauen" oder aber andere Prozesse zunehmend ausbremsen - eigentlich typisch für Warteschlangen, Caches etc. Unpassende (Treiber)Versionen schließt der TO ja aus.

Naja, wer weiß, welche "Bremsbacke sich nicht von der Scheibe löst".

Gute Nacht
HansDampf06

Nicht unbedingt, da ich ja nicht nur auf die Festplatten und den RAM (hier lag nur der erste Fokus) abstell(t)e, sondern den Bogen schon etwas größer ziehe (siehe den letzten Absatz von 22:16 Uhr).

Mit Deinem jetzigen Zwischenstand kann aus meiner Sicht vorerst konstatiert werden, dass es der Paketfilter wohl eher nicht sein kann. Auch können, wie ich bereits vermutete, die NIC's und deren Treiber wohl ausgeschlossen werden. Es hat eher etwas mit dem Übergang vom Default-LAN ins VLAN20 zu tun. Dieser Vorgang benötigt doch ein Switching / Routing zwischen den beiden LAN's. Hast Du Dir schon genauer angesehen, ob hier etwas in den Keller geht? Könnte es sein, dass die lediglich zwei vCPU's schlicht zu wenig sind. Wie verhält sich die pfSense mit 3 oder 4 vCPU's?

Wie stark ist denn der Host mit VM's, vCPU's, RAM etc. ausgelastet? Was sagen top bzw. uptime hinsichtlich der aktuellen Auslastung der pfSense während des Kopiervorgangs (das sind drei Werte hintereinander - 1 / 5 / 15 Minute(n)). Sollte bei nur zwei vCPU's ein Wert von 2,0 (= 100 %; es baut sich eine Warteschlange auf) oder gar noch höher ausgeworfen werden, geht die pfSense (/ eine VM) nach meiner Erfahrung bereits in eine spürbare Leistungssättigung. Das zusätzliche Switching / Routing kann hier schlichtweg bereits zu viel des Guten sein. Die Auslastungswerte könntest Du ja mit Start kurz vor dem Kopiervorgang während seiner Dauer in eine Logdatei schreiben.

Bleiben dem Host noch genügend Ressourcen? Hat die pfSense-VM im Verhältnis zu den anderen VM's eine Priorisierung bei der Zuweisung von CPU-Anteilen? ...

Viele Grüße
HansDampf06

PS:
Ein kleiner Tipp: Ähnlich dem Ressourcenmonitor bei Windows kann webmin im Dashboard den Verlauf der wichtigsten Leistungsdaten (standardmäßig CPU, Memory, Swap, Process, Disk I/O, Network I/O) als grafischen Verlauf anzeigen. Könnte ja als Überblick hilfreiche Informationen liefern, falls webmin auf der pfSense installierbar ist.

Habs hier gerade mal auf einem 150 Euro Intel NUC (Celeron) mit singulärem 1G NIC Port und ESXi 6.7 nachgestellt nur um mal zu verifizieren ob es reproduzierbar ist. Umfeld nur mit vmxnet NICs.
Der Fehler lies sich mit 2 Debian VMs die an beiden lokalen LAN Interfaces am vSwitch laufen nicht reproduzieren.
Hab zwar nur eine 3Gig Datei gehabt die aber sowohl mit SMB/CIFS als auch per FTP und per SCP kopiert. Lief alles fehlerfrei ohne jegliche Auffälligkeiten durch.
pfSense VM und die beiden Debian VMs rannten mit je 4 GB RAM.

Auf dem vSwitch sind 2 Portgruppen eingerichtet VLAN 3 und VLAN 7. Da drinnen hängen die lokalen pfSense LAN Ports und über die wurden auch kopiert.
(die 2te VM war im "LAN Intern")

Mit anderen Worten du segmentierst nicht auf dem vSwitch selber sondern sendest alle VLANs über einen Tagged Link der pfSense auf den vSwitch, richtig ?
Gut, das müsste ich im Setup mal umstellen. Diese Frickelei mit der VLAN ID "4095" klingt irgendwie schräg aber vermutlich ist das wohl ein internes Ding das der vSwitch nur über diese Portgruppe überhaupt von extern tagged Frames annimmt. Wie gesagt netztechnisch gesehen sehr schräg aber nundenn...
Vermutlich liegt da auch der (Fehler)Hund begraben...?! Komisch ist nur das es ja rennt bis zu einem gewissen Volumen und dann abbricht was ja dann doch eher für ein Buffer Problem o.ä. sprechen würde. Hätte man MTU oder Tagging Probleme würde es von Anfang an gar nicht gehen.

Buffer Problem in Verbindung mit tagged Interfaces. Nur im Default VLAN allein kann man ja nicht kopieren bzw. wenn dann ja immer ohne Router oder FW Beteiligung. Die sind ja nur involviert wenn ein 2tes IP Segment mit im Spiel ist.
Oder willst du damit sagen einer der Beteiligten liegt am gleichen Interfaces einmal im Default VLAN (untagged) und der andere in einem tagged VLAN was dann rennt. Aber wenn beide sich in einem tagged VLAN am gleichen Interface befinden geht es nicht ?
Was die 4095 Thematik anbetrifft ist das hier ja nochmal recht gut beschrieben:
https://communities.vmware.com/t5/vSphere-vNetwork-Discussions/VLAN-id-4 ...

Bäcker soll auch ganz nett sein, bis auf die frühen Arbeitszeiten. Wenn man da mal Mist gemacht hat, ist es am nächsten Tag wieder weg.

lks

PS: Ich habe auch manchmal solche Momente.

Der war gut ! Auf alle Fälle erheblich stressfreier und immer an der frischen Luft. Sicher im Endeffekt besser als die IT !!!
Asymetrisches Routing mit einem Wirrwarr an Regeln... Da passiert dann sowas wenn man nicht mal alles ausfegt und sauber macht...
Wichtig aber ist das du nicht aufgegeben hast und den Humor behalten hast. Beim nächsten Mal machst du dann vorher immer einen Traceroute !
Das ist oft so weil man als Profi so "flach" meist nicht mehr denkt. Oder...da du da nur sehr am Rand bemerkt hast hatte das niemand wirklich auf dem Radar. Deshalb ist es wichtig immer eine Skizze zu erstellen damit Externe sich da besser reindenken können. Verbales Troubleshooting über ein Forum ist immer etwas anderes als wenn man direkt davor sitzt wie wir alle wissen.

Es war so etwas Banales, daß keiner dran gedacht hat.

Ich habe den Thread zwar mitverfolgt, aber meine Kristallkugel hat da nur Nebel gesehen, so daß ich mich aus der Diskussion rausgehalten habe. An das Gateway hätte ich auch zuletzt gedacht.

lks