PFsense Hardware

m0nji

@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.

micneu

@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.

thiasaef

@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:

...

m0nji

@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

thiasaef

@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.

m0nji

@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?

thiasaef

@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.

thiasaef

Da der RTTsd Wert erhöht ist aber der Status als Online angezeigt wird.

Bei mir sieht es unter Last so aus:

NOCling

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.

m0nji

@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

thiasaef

@m0nji die Firewall Rule Action ist ja hoffentlich 'Match' und nicht auf 'Pass'.

m0nji

@thiasaef ja das habe ich gefühlt 10-mal überprüft

JeGr

@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

m0nji

@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.

thiasaef

@m0nji die ICMP Regeln kann man zusammenfassen, wenn man jeweils beide Interfaces auswählt.

NOCling

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.

thiasaef

@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

NOCling

Ja stimmt, die ICMP Regeln sind immer noch notwendig, sonst kommt es unter Last zu einem nicht gewünschtem Verhalten.

sub2010

@thiasaef

Danke für deine Ausführungen, ich habe die Einstellungen angepasst.
Gleichzeitig habe ich ein Upgrade auf 2.6 durchgeführt. Deine Einstellungen die du im Link erwähnt hast, gelten aber auch für diese Version?

Hier meine Einstellungen (Abweichend zu deinem Screenshot, aufgrund der Version?)

LTE IN

LTE OUT

Floating Rules
Da bin ihc mir bei dem Gateway nicht sicher, meinst du das WAN Interface unter dem Punkt Gateway: Default? Wenn ja, gehe ich von dem LTE WAN Interfache aus, richtig?

Laut deiner Liste:
1.) Add quick pass floating rule to handle ICMP traceroute. This rule matches ICMP traceroute packets so that they are not matched by the WAN-Out limiter rule that utilizes policy routing. Policy routing breaks traceroute.

Action: Pass
Quick: Tick Apply the action immediately on match.
Interface: WAN
Direction: out
Address Family: IPv4
Protocol: ICMP
ICMP subtypes: Traceroute
Source: any
Destination: any
Description: policy routing traceroute workaround
Click Save
2.) Add quick pass floating rule to handle ICMP echo-request and echo-reply. This rule matches ping packets so that they are not matched by the limiter rules. See bug 9024 for more info.

Action: Pass
Quick: Tick Apply the action immediately on match.
Interface: WAN
Direction: any
Address Family: IPv4
Protocol: ICMP
ICMP subtypes: Echo reply, Echo Request
Source: any
Destination: any
Description: limiter drop echo-reply under load workaround
Click Save
3.) Add a match rule for incoming state flows so that they're placed into the FQ-CoDel in/out queues

Action: Match
Interface: WAN
Direction: in
Address Family: IPv4
Protocol: Any
Source: any
Destination: any
Description: WAN-In FQ-CoDel queue
Gateway: Default
In / Out pipe: fq_codel_in_q / fq_codel_out_q
Click Save
4.) Add a match rule for outgoing state flows so that they're placed into the FQ-CoDel out/in queues

Action: Match
Interface: WAN
Direction: out
Address Family: IPv4
Protocol: Any
Source: any
Destination: any
Description: WAN-Out FQ-CoDel queue
Gateway: WAN_DHCP
In / Out pipe: fq_codel_out_q / fq_codel_in_q
Click Save/Apply Changes

thiasaef

@sub2010 said in PFsense Hardware:

Deine Einstellungen die du im Link erwähnt hast, gelten aber auch für diese Version?

Ja.

Quick: Tick Apply the action immediately on match.

Das hast du bei der 1. ICMP Regel vergessen zu setzen.

Wenn ja, gehe ich von dem LTE WAN Interfache aus, richtig?

Ja, allerdings hast du zweimal WAN-Out in der Beschriftung stehen. Ist nur die Beschriftung falsch?

Hier meine Einstellungen (Abweichend zu deinem Screenshot, aufgrund der Version?)

Und was sagt https://www.dslreports.com/speedtest jetzt?