DSCP isn't being queued correctly (update: Confirmed)



  • Hello everyone! I'm new here, so pardon my newb-ness. I've been experimenting with queuing packets that have DSCP markings and I've noticed that AF31 and EF both seem to get lumped together in the 2.0 release version.

    For example, I have the following set up:

    qVoice - Floating rule on LAN and WAN telling my pfSense box to place anything inbound or outbound that has EF markings into the HFSC queue "qVoice".

    qExpedited - Floating rule on LAN and WAN telling my pfSense box to place anything inbound or outbound that has AF31 markings into the HFSC queue "qExpedited".

    What I've observed is that both AF31 and EF traffic are being placed into qExpedited, however, if I disable the qExpedited floating rule, both AF31 and EF then get placed into the qVoice queue instead. It's almost as if there's a typo somewhere that defines AF31 and EF as both having the same header values or something. I don't think that's the case though because both types always get thrown into qExpedited regardless of whether I move that rule to the bottom of the rule list or not. Using the "Apply action immediately on match" option on either the qVoice or qExpedited rule doesn't make a difference either. Weird.

    Now, I know this has been brought up before (http://redmine.pfsense.org/issues/923) but I'm not finding any other mention of it. I do know that when I ran 2.0 RC1 I wasn't noticing this behavior, so I'm wondering if this may have been addressed during the RC process but then resurfaced again in the final release build. This isn't a huge deal to me because even with this glitch I can still separate my voice traffic from my bulk / default traffic, but I miss having the capability to differentiate AF31 and EF for tracking and rate-limiting purposes.

    Can anyone help a newb out please?

    UPDATE: While doing some further experimenting on this I got rid of my qExpedited rule altogether and modified my qVoice rule to only place AF31 traffic into the qVoice queue to see what happens. In other words, EF traffic should be treated as default traffic now because it no longer matches any set rules; AF31 should now be the only thing going into qVoice. I cleared states and started moving 80-ish Kbps of bi-directional EF traffic through the LAN and WAN interfaces. I then monitored my queues and found my EF traffic was being routed through qVoice! This strongly suggests to me that the values for AF31 and EF are indeed the same wherever they are defined in pfSense. Is this something I can tweak myself? Should I submit a bug report?


Log in to reply