Bufferbloat Fix mit WAN und VPN-Gateway Group
-
@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
