xaero1982
Goto Top

PFSense und Transferprobleme

Moin Zusammen,

leidiges Thema PFSense - ich hab mich mal wieder ran gewagt.
Ich hab hier so ein paar VLANs laufen und nen ESX.

So weit so gut.

Grundsätzlich funktioniert es wie gewünscht in meinen zwei Testnetzen, aber ich habe ein sehr kurioses Problem.

Ich kopiere eine 4gb große Testdatei vom Server auf den Client. Er fängt an und bricht ein auf 0. Dort verharrt der Kopiervorgang ziemlich exakt 19 Sekunden (reproduzierbar) und kopiert dann für knappe 3 Sekunden weiter.

Schalte ich den Paketfilter vollständig in den erweiterten Einstellungen ab bekomme ich durchgehende 113mb/s.

Firewallregeln sind aktuell auf any any any für das VLAN20 und das LAN(Default-VLAN 1) in dem der Server ist.

Ansonsten ist die PFSense gerade frisch installiert und abgesehen vom GW, DNS, 4 Interfaces, davon 2 VLAN, und ein paar AnyRegeln ist sie nackt.

Hat jemand eine Idee?

Grüße

Content-ID: 666746

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

Printed on: December 12, 2024 at 16:12 o'clock

LordGurke
LordGurke May 14, 2021 updated at 15:47:12 (UTC)
Goto Top
Blockierst du über eine Regel ICMP resp. erlaubst du es nicht?
Könnte ggf. ein MTU-Problem sein, was durch blockiertes ICMP sichtbar wird.

Ansonsten könnte das auch ein Rate-Limit-Problem sein. Wie werden denn die Daten übertragen, also über welches Protokoll?
Xaero1982
Xaero1982 May 14, 2021 at 17:48:57 (UTC)
Goto Top
Ich hab eine Regel auf den Interfaces

Any Any Any

Kopiert einfach über den Explorer von Windows.
the-buccaneer
the-buccaneer May 14, 2021 at 20:32:06 (UTC)
Goto Top
Moinsen!

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

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

pfsense1

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
Xaero1982
Xaero1982 May 14, 2021 at 21:35:33 (UTC)
Goto Top
Nein, dann gehts wieder auf 0. Dachte das geht aus dem Text hervor?

Das wird irgendwas mit der Firewall zu tun haben, aber was weiß ich nicht.

Die Last ist quasi gen 0.

Auch das .... aufm ESX! Nen Server auf dem noch einige andere VMs laufen. Leistung ist für ne PFSense definitiv genug vorhanden.

Grüße
the-buccaneer
the-buccaneer May 14, 2021 at 21:53:21 (UTC)
Goto Top
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. face-wink

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
Xaero1982
Xaero1982 May 15, 2021 at 08:35:13 (UTC)
Goto Top
Danke für den Versuch!face-smile

Ja, sie soll produktiv gehen und das nicht auf einer extra Büchse. Hätte auch keine sinnvolle Alternative parat aktuell.

Ich hab noch nicht mal eine zweite Lan-Karte aktuell da😂

Bei der vorherigen Version gab es ähnliche Probleme. Hat also keinen Zweck.

Esx version 6.5 ist aktuell installiert und die pfsense 2.5.1

Lan-Adapter ist e1000 in der vm. Denke auch nicht, dass es daran liegt, sondern irgendwas mit dem Paketfilter.

Grüße
radiogugu
radiogugu May 15, 2021 at 10:19:42 (UTC)
Goto Top
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
aqui
aqui May 15, 2021 updated at 14:30:49 (UTC)
Goto Top
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.
Xaero1982
Xaero1982 May 15, 2021 at 13:55:13 (UTC)
Goto Top
Moin Zusammen,
Moin aqui,

du meinst, wenn ich dich richtig verstehe, Client und Server im gleichen VLAN bzw. im Default VLAN, right?

Wenn das gehen sollte bringt mir das nur leider nicht wirklich viel. D.h. ich müsste, wenn die PFSense direkt aufm Blech installieren?

Kann ich morgen mal testen, wenn ich vor Ort bin.

Melde mich dann.

Grüße
Inf1d3l
Inf1d3l May 15, 2021 updated at 14:33:55 (UTC)
Goto Top
For best performance, use VMXNET 3 type of adapters instead of E1000.

https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-esxi.html
Xaero1982
Xaero1982 May 15, 2021 at 14:31:41 (UTC)
Goto Top
Zitat von @Inf1d3l:

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

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

Hatte ich mit der alten Version auch schon mal probiert und brachte nichts. Ich hatte es dann erstmal zur Seite gelegt, aber nun muss ich ran face-smile

Zumindest für eine gewisse Zeit soll es mit auf den ESX. Ggf. besorg ich dann mal eine richtige Appliance dafür, aber bis dahin muss es laufen. Ich werde es morgen testen.

Grüße
Inf1d3l
Inf1d3l May 15, 2021 at 14:33:43 (UTC)
Goto Top
Open-VM-Tools installiert?
LordGurke
LordGurke May 15, 2021 at 14:58:05 (UTC)
Goto Top
Zitat von @Xaero1982:

Moin Zusammen,
Moin aqui,

du meinst, wenn ich dich richtig verstehe, Client und Server im gleichen VLAN bzw. im Default VLAN, right?

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.
Xaero1982
Xaero1982 May 15, 2021 at 15:18:27 (UTC)
Goto Top
Zitat von @Inf1d3l:

Open-VM-Tools installiert?

Müsste ich checken, aber ich vermute nicht nein.
Xaero1982
Xaero1982 May 15, 2021 at 15:20:20 (UTC)
Goto Top
Zitat von @LordGurke:

Zitat von @Xaero1982:

Moin Zusammen,
Moin aqui,

du meinst, wenn ich dich richtig verstehe, Client und Server im gleichen VLAN bzw. im Default VLAN, right?

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.

Auch das war der Gedanke beim letzten mal und so habe ich für jedes VLAN einen virtuellen Switch erstellt und wollte die Karten dann zuteilen, aber da war glaube ich bei 8 Schluss. Aber ich brauche mehr. Daher war das dann auch keine Option.

Ich werde es morgen nochmal testen mit vmxnet 3 Karten und ohne VLAN und mal schauen was dann die Übertragung sagt.

Werde morgen berichten.
HansDampf06
HansDampf06 May 15, 2021 at 15:25:09 (UTC)
Goto Top
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
Xaero1982
Xaero1982 May 15, 2021 updated at 16:08:52 (UTC)
Goto Top
Hi Hans,

schade um deinen ganzen Text face-sad aber wie ich ja oben schrieb kann es daran gar nicht liegen, weil bei deaktivierter Firewall ich volle 113mb/sek habe. Also nein, da ist nichts ausgelastet und nicht überlastet.

260mb/sek sind bei normalen Sata Platten bzw. Sata-SSDs zwar möglich, aber nicht über ein 1gbit Lan. Da ist bei 113mb/sek Schluss und die erreiche ich immer.

Grüße
aqui
aqui May 15, 2021 at 18:11:26 (UTC)
Goto Top
Besser du nutzt dann auch die korrekte Schreibweise MB (Byte) oder Mb (bit) sonst weiss bald keiner mehr was wirklich gemeint ist... face-wink
Xaero1982
Xaero1982 May 15, 2021 at 18:27:37 (UTC)
Goto Top
Zitat von @aqui:

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

Wenn 113mbit das maximum wären, würde es ganz andere Probleme geben face-smile

Schön, dass du wieder unter uns bist face-smile
HansDampf06
HansDampf06 May 15, 2021 at 20:16:56 (UTC)
Goto Top
Zitat von @Xaero1982:

schade um deinen ganzen Text face-sad aber wie ich ja oben schrieb kann es daran gar nicht liegen, weil bei deaktivierter Firewall ich volle 113mb/sek habe. Also nein, da ist nichts ausgelastet und nicht überlastet.

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
LordGurke
LordGurke May 15, 2021 updated at 21:12:19 (UTC)
Goto Top
@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.
LordGurke
LordGurke May 15, 2021 at 21:09:06 (UTC)
Goto Top
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.
HansDampf06
HansDampf06 May 15, 2021 at 22:04:34 (UTC)
Goto Top
@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
Xaero1982
Xaero1982 May 16, 2021 at 08:07:11 (UTC)
Goto Top
Moin Moin,

also erster Test war noch mal:

VMTools installiert.
Ergebnis: Keins - also sprich, das Problem ist nachwievor vorhanden.

Client in das Default VLAN gesteckt
Ergebnis: Volle 113MB/s liegen konstant an ohne Einbrüche bei aktivem IP Filter.
(Das widerspricht leider auch deiner Theorie Hans face-smile )

Jetzt installiere ich die Büchse nochmal neu mit VMXNet 3 Adaptern und berichte dann.

Grüße und danke für die rege Beteiligung face-smile
Xaero1982
Xaero1982 May 16, 2021 updated at 09:46:13 (UTC)
Goto Top
So, Büchse neu installiert mit VMXNet 3 Adaptern und das Ergebnis ist identisch.

edit: @LordGurke: Name oder IP - beides macht leider keinen Unterschied.

edit2: @HansDampf06: Die VMs haben 4GB Ram, 40 GB Festplatte auf einer SSD im RAID 1 und 2 V-CPUs in einem Dual Xeon Server. Leistung sollte da definitiv genug sein. Des Weiteren ist eine 4 Port Intel LAN Karte verbaut über die die PFSense läuft.
Xaero1982
Xaero1982 May 16, 2021 at 11:25:02 (UTC)
Goto Top
Ich bestell ne LAN Karte und versuchs mal aufm Blech. Alles andere wird wohl nichts werden.
HansDampf06
HansDampf06 May 16, 2021 at 13:39:14 (UTC)
Goto Top
Zitat von @Xaero1982:

Client in das Default VLAN gesteckt
Ergebnis: Volle 113MB/s liegen konstant an ohne Einbrüche bei aktivem IP Filter.
(Das widerspricht leider auch deiner Theorie Hans face-smile )

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.
Xaero1982
Xaero1982 May 16, 2021 at 15:12:28 (UTC)
Goto Top
Nimms mir nicht übel. Ich weiß deine Mühe wirklich zu schätzen, aber du bist hier auf der falschen Fährte.

Es gibt wirklich im gesamten Netz genug Leistung. Aktuell ist ein ätzender Schulrouter dazwischen, den ich weg haben will, weil das Ding 9 Jahre alt ist und ich nicht für über 5k einen neuen kaufen will, der mich eh nie überzeugt hat.
Darüber geht die volle Leistung ohne Probleme.

Und was du ausschließt ist das Problem - zumindest in der Kombination: Der Paketfilter.

Und nein, da geht rein gar nichts in den Keller. Da langweilen sich alle Komponenten.

Dualport LAN Karte ist bestellt und wenn sie da ist bau ich sie in ein extra Blech und installiere darauf die PFSense. Mit dem Ryzen 5 1600+, 16 GB Ram, SSD, sollte genug Power vorhanden sein für das Ding.


Grüße und nen schönen Restsonntag
aqui
aqui May 17, 2021 at 06:46:14 (UTC)
Goto Top
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.
Xaero1982
Xaero1982 May 17, 2021 at 07:25:31 (UTC)
Goto Top
Moin Aqui,

hast du denn VLANs genutzt? Da scheint ja der Knackpunkt zu liegen in der Kombination. Im Default-VLAN läuft es ja. Wenn der Client im VLAN ist zeigt sich eben dieses Fehlerbild wenn der Paketfilter aktiv ist. Ist er es nicht läuft es.
aqui
aqui May 17, 2021 updated at 07:54:35 (UTC)
Goto Top
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.
vswitch
(die 2te VM war im "LAN Intern")
Xaero1982
Xaero1982 May 17, 2021 at 08:24:22 (UTC)
Goto Top
Hi Aqui,

ja aber genau das kann ich bei mir nicht umsetzen. Weil ich der PFSense 10 Netzwerkkarten zuordnen müsste aus dem jeweiligen VLAN und es gehen keine 10. Ich glaube bei 6 oder 8 war schluss.

Daher muss ich es in der PFSense selber regeln und als VLAN ID 4095 angeben (Das Thema hatten wir schon face-smile )

Grüße
aqui
aqui May 17, 2021 updated at 08:38:49 (UTC)
Goto Top
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.
Xaero1982
Xaero1982 May 17, 2021 at 08:42:39 (UTC)
Goto Top
Richtig. Wird aber auch so in den Kbs gemacht: https://kb.vmware.com/s/article/1004252

Es geht auch wie du es gemacht hast in deinem Beispiel, aber eben nicht mit der Menge an VLANs die ich brauche.

Naja aber wenn es ein Bufferproblem wäre würde es ja auch im Default-VLAN nicht laufen. Tut es aber.

Ich denke Donnerstag kann ich es spätestens testen, wenn ich vorher keine Zeit habe mit der Installation auf einem separaten Blech. Dann kann ich zumindest schon mal eingrenzen woran es liegt. Sofern die Karte bis dahin da ist.
aqui
aqui May 17, 2021 updated at 08:56:56 (UTC)
Goto Top
Naja aber wenn es ein Bufferproblem wäre
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 ...
Xaero1982
Xaero1982 May 17, 2021 at 10:49:26 (UTC)
Goto Top
Du hast recht. Hatte es ja wie gesagt im Default getestet und da ging es. Ansonsten erfolgte der Kopiervorgang immer zwischen VLAN 20 und Default VLAN - da hängen die Server, Drucker usw. drin. Ist so gewachsen und lässt sich bei der Größe hier kaum ändern, ohne nicht alles lahm zu legen.

Nun habe ich auf deinen Hinweis mal die ACL aufm Switch zwischen VLAN 20 und VLAN 30 entfernt. Jeweils bei einem Client die PFSense als Gateway gesetzt und mal den Kopiervorgang zwischen den beiden VLANs getestet - von Client zu Client.
Das ging ohne Probleme - volle Geschwindigkeit durchgehend.

Was auch sehr interessant ist, dass die Geschwindigkeit im VLAN 30 - Server -> Client bei ca. 70MB/s liegt und zwischen Client VLAN 20 und Client VLAN 30 sind es volle 113MB/s.

Es wird immer absurder :D
Xaero1982
Xaero1982 May 17, 2021 at 11:47:56 (UTC)
Goto Top
Gut, also das kann man ja eigentlich keinem erzählen, also bleibt das ja sicher unter uns.

Es war ja wie gesagt alles nur Testbetrieb. Sprich, die PFSense lief parallel zum Schulrouter. D.h. ich hab das Gateway auf dem Client dann manuell angepasst zum Testen, damit es über die PFSense läuft. Was ich aber natürlich nie angepasst habe war das Gateway auf dem Fileserver.

Nachdem ich das getan habe gings wie am Schnürchen mit 113MB/Sek.

Ich bin dann mal weg face-smile neuen Job suchen. Vielleicht als Garten- und Landschaftsbauer oder so.

Danke euch für die Beteiligung und die vielen Ideen.

Grüße
Lochkartenstanzer
Lochkartenstanzer May 17, 2021 updated at 11:52:15 (UTC)
Goto Top
Zitat von @Xaero1982:

Ich bin dann mal weg face-smile neuen Job suchen. Vielleicht als Garten- und Landschaftsbauer oder so.

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. face-smile

lks

PS: Ich habe auch manchmal solche Momente.
Xaero1982
Xaero1982 May 17, 2021 at 12:02:20 (UTC)
Goto Top
Zitat von @Lochkartenstanzer:

Zitat von @Xaero1982:

Ich bin dann mal weg face-smile neuen Job suchen. Vielleicht als Garten- und Landschaftsbauer oder so.

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. face-smile

lks

PS: Ich habe auch manchmal solche Momente.

Nee, Bäcker geht nicht. Das ist mir zu früh, wobei die Gartenmenschen auch früh unterwegs sind. Mh na muss ich mir mal was raussuchen mit normalen Arbeitszeiten ;)

Grüße

PS: Ich hab nun zwei Vermutungen: Es war so banal und trivial, dass es niemand vorgeschlagen hat oder es hat einfach auch sonst niemand dran gedacht. Letzteres wäre natürlich gut für mich ;) Das erste eher ... nun ... face-smile
aqui
aqui May 17, 2021 updated at 12:39:05 (UTC)
Goto Top
Ich bin dann mal weg neuen Job suchen. Vielleicht als Garten- und Landschaftsbauer oder so.
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 ! face-wink
Es war so banal und trivial, dass es niemand vorgeschlagen hat
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. face-wink
Lochkartenstanzer
Lochkartenstanzer May 17, 2021 at 12:37:59 (UTC)
Goto Top
Zitat von @Xaero1982:

PS: Ich hab nun zwei Vermutungen: Es war so banal und trivial, dass es niemand vorgeschlagen hat oder es hat einfach auch sonst niemand dran gedacht.

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

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
Xaero1982
Xaero1982 May 17, 2021 at 15:34:21 (UTC)
Goto Top
Hach ich mag euch face-smile

Ich hab da aber auch echt nicht dran gedacht, dass die andere Seite ja auch das gleiche Gateway haben muss face-smile

Naja am WE werde ich dann noch weiter werkeln und die produktiv schalten und diesen blöden Schulrouter rausnehmen. Und dann schmeiß ich die ACLs vom Switch und verwalte das über die PFSense. Ist denke ich sinnvoller, als das zu verteilen

Das stimmt, aber ich finde es dennoch immer wieder spannend von welcher Seite andere an so ein Problem herangehen. Da lernt man ja auch nur dazu face-smile

Und ja, ein Traceroute hätte sicher schon Licht ins Dunkel gebracht, wenn es mir dann auch irgendwie in dem Moment noch klar gewesen wäre face-smile

Dennoch finde ich es sehr kurios, dass wirklich immer exakt 19 Sekunden nichts passierte und dann 2,5 Sekunden kopiert wurde - bis der Vorgang fertig war. Echt schräg.

Ich wünsche euch einen schönen Feierabend face-smile