DSCP QOS Traffic Shaping Question
-
@ngr2001 While bufferbloat may be a+ with new tcp connections (in my experience), it is only generally during fast start/hystart. Turning off windows auto-tuning tcp can score a+ bufferbloat without fq_codel.
-
@ngr2001
I like synproxy too. It seems to work awesome with fq_codel. But actually dislike TCP in general. Why do we do this to ourselves? -
@ngr2001 The easy answer is: use more than one machine. Maybe one for security and another for traffic shaping.
-
Sorry, I understand your comments but they are not addressing my question. As originally stated, I have no issue with any other layer on my network. My clients are tagging specific traffic with DSCP values just fine, those values are then prioritized by by my switch. I only want to know how one can prioritize certain DSCP values in PFSense.
-
@ngr2001 If you use policy shaping for each individual DSCP marking, you could assign each dscp class of traffic its own limiter.
I have tagged all EF or VA on the LAN before, and use those tags in floating rules to assign each class of DSCP its own fq codel queue. If you use match rules without the quick option checked, DSCP should auto-prioritize?
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html
The match action is unique to floating rules. A rule with the match action will not pass or block a packet, but only match it for purposes of assigning traffic to queues or limiters for traffic shaping. Match rules do not work with Quick enabled.
-
Tag and Tagged
The Tag and Tagged fields are useful in concert with floating rules, so the firewall can mark a packet with a specific string as it enters an interface, and then act differently on a matched packet on the way out with a floating rule. See Marking and Matching for more on this topic.
https://docs.netgate.com/pfsense/en/latest/firewall/configure.html#tag-and-tagged
Marking and Matching
Using the Tag and Tagged fields, a connection can be marked by an interface tab rule and then matched in the outbound direction on a floating rule. This is a useful way to act on WAN outbound traffic from one specific internal host that could not otherwise be matched due to NAT masking the source. It can also be used similarly for applying shaping outbound on WAN from traffic specifically tagged on the way into the firewall.
For example, on a LAN rule, use a short string in the Tag field to mark a packet from a source of 10.3.0.56. Then on a floating rule, quick, outbound on WAN, use Tagged with the same string to act on the traffic matched by the LAN rule.
-
Word of caution though: https://www.rfc-editor.org/rfc/rfc8325#section-2.3
Trust: From a QoS-perspective, "trust" refers to the accepting of
the QoS markings of a packet by a network device. Trust is
typically extended at Layer 3 (by accepting the DSCP), but may
also be extended at lower layers, such as at Layer 2 by accepting
UP markings. For example, if an AP is configured to trust DSCP
markings and it receives a packet marked EF, then it would treat
the packet with the Expedite Forwarding PHB and propagate the EF
marking value (DSCP 46) as it transmits the packet.
Alternatively, if a network device is configured to operate in an
untrusted manner, then it would re-mark packets as these entered
the device, typically to DF (or to a different marking value at
the network administrator's preference). Note: The terms
"trusted" and "untrusted" are used extensively in [RFC4594].UP: User Priority. A value associated with an MSDU that indicates
how the MSDU is to be handled. The UP is assigned to an MSDU in
the layers above the MAC; see [IEEE.802.11-2016], Section 3.1.
The UP defines a level of priority for the associated frame, on a
scale of 0 to 7.Wi-Fi: An interoperability certification defined by the Wi-Fi
Alliance. However, this term is commonly used, including in the
present document, to be the equivalent of IEEE 802.11. -
@ngr2001 You should probably try it in virtual machine first. Because jenkins and allsorts of other crap crashes and creates crappy stuff in config files. Also, creating new fq codel pipes requires a reboot because of the flows parameter. It needs to reserve memory.
-
@ngr2001 Caveats
By default, pfSense software only matches the first packet of a connection, which is the packet that creates an entry in the state table. If a connection starts with a different DSCP value, has no DSCP value in the starting packet, or otherwise changes DSCP values during the connection, the traffic will not be classified as expected.
Tip
This can be worked around by using “no state” rules, but crafting these rules in a secure manner is difficult, so it is not a viable workaround for most environments.
-
I appreciate the responses here but I am still kind of lost on finding a solution. Please allow me to rephrase the question and scenario.
My Switch is set to Trust DSCP, my clients properly tag DSCP values to packets like Zoom & Teams etc. On the PFSense side I have Codel Limiters in place to combat bufferbloat and those are working nicely see below.
What I would like to do achieve next is some kind of simple rule that simply tells PFSense to Trust DSCP, aka prioritize the packets accordingly if there is a DSCP value, i.e. DSCP Value 46 would get high priority. I would rather not have to create a rule for every single DSCP value, is there any way to plug an play this. Much like when one configures a CISCO switch and issue AUTO QOS and all the DSCP value and queues get populated for you. Keep in mind the solution has to also be compatible with the existing Codel lmiiter.
