PFsense Hardware
-
@sub2010 das Traffic Shaping via fq_codel hat nur dann einen positiven Effekt auf die Latenzen unter Last, wenn du deine Datenrate via Limiter künstlich drosselst. Ein grober Richtwert dafür sind 95 % der normalerweise erreichbaren Datenrate. Ob es funktioniert, kannst du auf https://dslreports.com/speedtest/ testen.
An meiner Leitung kommen laut Speedtest tatsächlich 160Mbit an.
Ich bin von obigem Screenshot ausgegangen und da kamen halt nur 143 Mbit/s an.
-
@thiasaef
Danke für die Antwort, dass lag daran das ich im Home Office nicht alleine war ;).Hier meine Konfig:
Ich habe aber nicht verstanden wo ich das ebenfalls für den Upload eintragen kann. Weißt du wo das geht?Soweit so gut, bei der WAN Verbindung scheint es zu funktionieren. Da der RTTsd Wert erhöht ist aber der Status als Online angezeigt wird.
login-to-viewVielen Dank für die Unterstützung, ich berichte ob die Funktion bei der LTE Version ebenfalls so gut funktioniert.
-
@sub2010 sicher das es funktioniert wie gewüncht?
soweit ich weiß hast du soeben den upload auf 152mbit begrenzt und nicht den download. den download setzt der wizard auf dem lan interface. das war auch der grund weswegen ich das nicht genutzt habe, weil man eben nicht den download pro WAN interface setzen kann. -
@sub2010 deine anfrage zur neuen hardware ist doch schon lange abgeschloßen, oder sehe ich das falsch. du bist hier schon deine sense am fein justieren.
-
@sub2010 ich hab oben verlinkt, wie man fq_codel richtig einstellt. Vom Wizard hab ich keine Ahnung, aber deinen Screenshots nach zu urteilen bist du noch sehr weit von einer korrekten Einstellung enfernt:
... -
@thiasaef
wenn er den wizard benutzt hat, erstellt dieser interface regeln, keine limiters.
limiters würden in diesem beispiel wohl auch nicht funktionieren, weil du limiters auf eine fw rule setzt (in / out pipe).
angenommen er hat jetzt einen dsl limiter mit 150/40 welchen er auf die lan rule richtung internet seiner clients legt, wo er auch als gateway, die gateway failover group nutzt. wenn jetzt dsl ausfällt und dadurch lte einspringt, greift dennoch der gleiche dsl limiter.dennoch sind limiter ein guter ansatz um beispielsweise bufferbloat in den griff zu bekommen
-
@m0nji natürlich funktionieren die Limiter auch in Kombination mit Dual WAN und Failover.
Ich hab das bei mir ganz simpel über zwei Floating Rules auf den WAN_DSL / WAN_LTE Interfaces gelöst.
@m0nji said in PFsense Hardware:
dennoch sind limiter ein guter ansatz um beispielsweise bufferbloat in den griff zu bekommen
Paketverlust und Latenzen auf einem LTE Link bekommt man damit ebenfalls gut in den Griff.
-
@thiasaef
interessant und danke für die info. wie sehen diese regeln bei dir aus? das heißt dann auch, du nutzt keine limiter auf dem LAN interface? -
@m0nji, exakt so, wie es hier beschrieben wurde: https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/815
das heißt dann auch, du nutzt keine limiter auf dem LAN interface?
Exakt.
-
Da der RTTsd Wert erhöht ist aber der Status als Online angezeigt wird.
login-to-viewBei mir sieht es unter Last so aus:
-
Genau dafür legt man Floating Rules an, und das pro Gateway für IPv4 und IPv6, also in dem Fall sind das dann 4 Regeln.
Denn in den erweiterten Optionen setzt man ja explizit das Gateway und dann die Pipes.
So stellt man sicher, das jeder Limitier auf auf dem richtigem WAN Interface sitzt.
-
@nocling
ja das war mir nicht mehr wirklich bewusst, dass man die Limiter auch bei den Floating Rules benutzen kann. Habe das testweise auch bei mir mal umgesetzt und es scheint zu funktionieren. Wenngleich ich auch ein etwas ungutes Gefühl habe, wenn ich da jetzt Regeln habe, die auf den WAN1 & 2 Interfaces liegen mit ANY in Source/Destination
-
@m0nji die Firewall Rule Action ist ja hoffentlich 'Match' und nicht auf 'Pass'.
-
@thiasaef ja das habe ich gefühlt 10-mal überprüft
-
@m0nji Vielleicht machts Sinn die Regel auch mal optisch zu posten, damit die Leute das sehen und verstehen? Ich musste gerade im Kopf auch 3x überlegen, bis ich verstanden habe, dass ihr match auf floats macht
-
@jegr
sind die Regeln von @thiasaef aus dem verlinkten Beitrag (https://forum.netgate.com/topic/112527/playing-with-fq_codel-in-2-4/815)Die icmp Regeln sind Pass Regeln und die letzten 4 sind Match Regeln
Die ersten 2 Match Regeln sind IN Direction Regeln und die letzten beiden Match Regeln sind OUT Direction Regeln. -
@m0nji die ICMP Regeln kann man zusammenfassen, wenn man jeweils beide Interfaces auswählt.
-
Zudem ist die Regel mit Richtung OUT.
Die ICMP Regel habe ich inzwischen wieder deaktiviert, weil das mal ein Fehlverhalten war, das ist soweit mir bekannt ist aber behoben worden. ICMP sollte nicht länger verworfen werden.
-
@nocling said in PFsense Hardware:
Die ICMP Regel habe ich inzwischen wieder deaktiviert, weil das mal ein Fehlverhalten war, das ist soweit mir bekannt ist aber behoben worden.
Gerade eben mit 2.6.0 getestet. Ohne die Regeln funktioniert traceroute via ICMP bei mir nicht:
traceroute -I netgate.com traceroute to netgate.com (199.60.103.104), 30 hops max, 60 byte packets 1 _gateway (192.168.1.1) 0.213 ms 0.190 ms 0.187 ms 2 199.60.103.104 (199.60.103.104) 1.841 ms 1.839 ms 2.008 ms 3 199.60.103.104 (199.60.103.104) 7.242 ms 8.821 ms 8.819 ms 4 199.60.103.104 (199.60.103.104) 10.758 ms 12.598 ms 12.715 ms 5 199.60.103.104 (199.60.103.104) 12.491 ms 12.536 ms 12.833 ms 6 199.60.103.104 (199.60.103.104) 33.998 ms 35.192 ms 35.186 ms 7 199.60.103.104 (199.60.103.104) 28.251 ms 24.201 ms 24.282 ms 8 199.60.103.104 (199.60.103.104) 16.290 ms 16.395 ms 16.583 ms 9 199.60.103.104 (199.60.103.104) 13.551 ms 13.662 ms 16.119 ms -
Ja stimmt, die ICMP Regeln sind immer noch notwendig, sonst kommt es unter Last zu einem nicht gewünschtem Verhalten.