Bufferbloat Fix mit WAN und VPN-Gateway Group
-
Das sollte man in dem Fall dann besser mal testen, ggf. einen zweiten Limiter mit anderen Werten anlegen, also 10MBit für WAN und 1MBit für VPN, dann mal testen.
Er hat es ja auf Interface, Source usw. beschränkt.
Ich habe mir das in der Doku aber auch nicht so genau durch gelesen, wie sich das ganze bei VPN Tunneln verhält, da ich so einen Anwendungsfall nicht habe.
Ich jage hier nur mit 2-3 S2S Tunneln Backups durchs WAN und dann läuft alles über den WAN Limiter, da ich im IPsec Tunnel Modus arbeite.
-
Habe es nun mal so eingestellt... Die Download-Bandbreite wird nicht halbiert und ansonsten sieht alles ok aus?
-
@enJOyIT, nein, gar nicht mit dem WAN Interface arbeiten, sondern alles auf den jeweiligen LAN Interfaces machen. Also:
- LAN - DownQ / UpQ
- VPN1 - DownQ / UpQ
- VPN2 - DownQ / UpQ
-
Sorry, habe meine Beitrag editiert... Hatte noch einen Download laufen, deshalb dachte ich der DL wäre halbiert.
-
Hatte noch einen Download laufen, deshalb dachte ich der DL wäre halbiert.
Obiger waveform.com Test lief durch eines der beiden VPNs?
-
@enjoyit said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
https://docs.netgate.com/pfsense/en/latest/recipes/codel-limiters.html
Also bei mir bringt der Netgate Vorschlag genau gar nichts...
-
@bob-dig dann machst du etwas falsch.
-
Ja, der lief durch einen VPN.
Ich muss das nochmal in Ruhe machen... Jetzt ist mir meine komplette pfsense abgeschmiert, webgui nicht mehr erreichbar etc... In der Console stand dann sowas wie
kernel: [zone pf frag entries] PF frag entries limit reached
Musste die Kiste komplett neustartem, ein Neuladen der Module hat nicht gereicht.
Nicht, dass mir durch die Konfiguration das jetzt regelmäßig passiert?
Sowas hatte ich bis jetzt noch nie und die Kiste läuft schon zwei Jahre hier. -
@thiasaef said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
@bob-dig dann machst du etwas falsch.
Hattest recht, hatte IPv6 nicht bedacht.
Hat zwar meiner Downloadrate nicht gut getan, aber zumindest die Ping bleibt nun insbesondere im Upload stabiler.
-
@enjoyit said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
kernel: [zone pf frag entries] PF frag entries limit reached
MTU / MSS auf den VPN Interfaces falsch eingestellt?
-
Da habe ich bisher nichts eingestellt. Und es lief bisher auch ohne Probleme, bis ich nun am Traffic Shaper rumgespielt habe
Oder kann das damit gar nichts zu tun haben?
-
@bob-dig said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Hattest recht, hatte IPv6 nicht bedacht.
Wenn man aber für IPv4 und IPv6 jeweils einen eigenen Limiter aufsetzen muss, dann wird das Ganze nicht mehr funktionieren, wenn beide "Protokolle" zur selben Zeit genutzt werden? Gibt wohl auch Nachteile mit DualStack.
-
Hab das jetzt mal ohne Traffic Shaper laufen lassen:
Stellt sich die Frage ob es sich in meinem Fall dennoch lohnt den Shaper zu nutzen? Ich merke in manchen Situationen schon Verzögerung wenn die Leitung ausgelastet ist. Hmm..
-
Hast du die States zwischen den Versuchen gekillt?
Wenn nicht, kannst du nicht sicher sein das alles durch den Limiter oder an ihm vorbei läuft.
Ich habe bei mir statt Tail Drop beides mal Codel gewählt, so kann ich dann auch ECN setzen.
-
Ich probiere es später nochmal und gebe dann nochmal Bescheid.
-
@nocling said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Ich habe bei mir statt Tail Drop beides mal Codel gewählt, so kann ich dann auch ECN setzen.
Das eine hat mit dem anderen aber eigentlich nichts zu tun?
@bob-dig said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Wenn man aber für IPv4 und IPv6 jeweils einen eigenen Limiter aufsetzen muss, dann wird das Ganze nicht mehr funktionieren, wenn beide "Protokolle" zur selben Zeit genutzt werden?
Warum? Einfach beide Male die gleichen Queues verwenden?
@enjoyit said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Hab das jetzt mal ohne Traffic Shaper laufen lassen:
Wenn du wirklich belastbare Messergebnisse willst, dann würde ich dir empfehlen Flent einzusetzen und als Gegenstelle einen vServer unter eigener Kontrolle zu verwenden (auf dem netperf und irtt laufen).
Stellt sich die Frage ob es sich in meinem Fall dennoch lohnt den Shaper zu nutzen?
Auf jeden Fall, aber du musst die Bandbreite vermutlich stärker begrenzen, damit fq_codel wirklich greift.
-
@thiasaef said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Warum? Einfach beide Male die gleichen Queues verwenden?
Hast wahrscheinlich wieder recht, ist halt nicht so einfach rauszulesen.
-
@bob-dig said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Gibt wohl auch Nachteile mit DualStack.
Richtig lustig wird es erst, wenn zusätzlich noch LTE Failover ins Spiel kommt. Für VPN + LTE Failover hab ich bisher noch keine praktikable Lösung gefunden, die im Failover Fall keinen manuell Eingriff erfordert.
@nocling said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Er hat es ja auf Interface, Source usw. beschränkt.
Ich hab noch mal probiert und trotz Source Beschränkung und 'State Reset' kommt es bei mir reproduzierbar zu einer Halbierung der Bandbreite. Vielleicht mach irgendwas falsch, was wir bisher noch nicht auf dem Schirm hatten? Wobei die Halbierung im Grunde genommen schon logisch wäre, da der VPN Traffic ja am Ende trotz allem durch das WAN Interface raus geht.
-
@thiasaef said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
Richtig lustig wird es erst, wenn zusätzlich noch LTE Failover ins Spiel kommt. Für VPN + LTE Failover hab ich bisher noch keine praktikable Lösung gefunden, die im Failover Fall keinen manuell Eingriff erfordert.
Da bin ich neugierig: Warum, was genau ist das Problem das manuellen Eingriff braucht?
-
@jegr wenn FQ-CoDel korrekt mit dem VPN Traffic umgehen soll, muss die zugehörige Regel auf dem VPN Interface angelegt werden, aber wenn man das macht, greift derselbe Limiter, egal ob der Tunnel über DSL (~ 250 Mbit/s) oder über LTE (~ 50 Mbit/s) aufgebaut wird.
Aber jetzt, wo ich noch mal darüber nachdenke, fällt mir auf, dass man das Problem eventuell dadurch lösen könnte, dass man von vorneherein zwei VPN Tunnel (einen über DSL und einen über LTE) aufbaut und eine Gatewaygroup (mit Failover) darüber anlegt.
