Bufferbloat Fix mit WAN und VPN-Gateway Group
-
@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.
-
Laufen die VPN Tunnel nicht auch durch WAN1 oder WAN2 um ins Internet zu gelangen?
Wenn man also jetzt auf jedem dieser Interface einen passenden Limiter legt, wo ist dann das Problem?
Bei mit funktioniert das auch für die S2S IPsec Tunnel auf diese weise.
-
@nocling said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
wo ist dann das Problem?
Dass FQ-CoDel dann nur noch einen Datenstrom (den des Tunnelverkehrs) zu Gesicht bekommt und nicht mehr korrekt funktioniert?
-
@NOCling, hier mal auf die Schnelle eine Analyse mit Flent:
Das Problem dürfte sich noch verschärfen, wenn man sich mit dem Limiter der tatsächlichen Bandbreite annähert. -
@thiasaef said in Bufferbloat Fix mit WAN und VPN-Gateway Group:
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.
@JeGr, die Idee funktioniert mit WireGuard übrigens auch nicht ohne Weiteres, siehe: https://forum.netgate.com/topic/170725/forcing-wg-to-use-an-specific-wan-interface-to-build-the-tunnel
