Re: [Cerowrt-devel] squash/ignore DSCP and mangle table questions

[leetminiwheat <LeetMiniWheat@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]

Thanks for the reply,


On Mon, Apr 13, 2015 at 3:36 AM, Sebastian Moeller <moeller0@gmx.de> wrote:

>         "Ignore DSCP on ingress”, this basically uses an 1-tier HTB
shaper on ingress, DSCP marks in the packets are simply ignored, but not
touched.

So if I understand this correctly, this means they're kind of in
passthrough mode on ignore but the qdiscs don't act on them due to no
iptables MARKing? And If *not* ignoring DSCP on ingress, they're still
passed through untouched but prioritized internally with the qdiscs?

>         "Squash DSCP on inbound packets (ingress):” this will replace all
DSCP marks with 0x0 (I believe), but only after the ingress qdisc.
> In essence this means you can actually interpret ingress DSCP marks from
upstream ("Ignore DSCP on ingress” set to ALLOW) but wipe them after the
ingress shaping (with "Squash DSCP on inbound packets (ingress);” active).
So the default should be “Ignore DSCP on ingress” and Squash (the second
can be argued, as long as no one bases routing decisions on the marks they
do not hurt). The rest of your questions are beyond my expertise...

Hmm, why would we want to remove all DSCP on output then? I assume many
ISPs and routers will squash them anyways, but wouldn't it serve *some*
purpose to differentiate between different traffic types?


Also, regarding my mangling questions I think I figured out the correct
chains to insert my rules in. mangle PREROUTING and mangle POSTROUTING
because both of those have a jump at the end to a chain that MARKs for
qdiscs based on DSCP values. They appear to be working since I see the MARK
rules counting upward. I assume PRE and POST go through FORWARD anyways so
it's redundant, and using FORWARD only didn't appear to be working. I've
ended up with this:

# Mangle sw10 packets to reclassify mumble traffic. Hopefully this passes
through DSCP so WMM can recognize 0x2e as VoIP traffic
iptables -t mangle -N RECLASS_sw10
iptables -t mangle -A RECLASS_sw10 -p tcp -m tcp --sport 6484  -j DSCP
--set-dscp 0x2e
iptables -t mangle -A RECLASS_sw10 -p tcp -m tcp --dport 6484  -j DSCP
--set-dscp 0x2e
iptables -t mangle -A RECLASS_sw10 -p udp -m udp --sport 6484 -j DSCP
--set-dscp 0x2e
iptables -t mangle -A RECLASS_sw10 -p udp -m udp --dport 6484 -j DSCP
--set-dscp 0x2e
iptables -t mangle -I PREROUTING -i sw10 -j RECLASS_sw10
iptables -t mangle -I POSTROUTING -o sw10 -j RECLASS_sw10

# Mangle gw00 to reclassify guest as low priority
iptables -t mangle -N RECLASS_gw00
iptables -t mangle -A RECLASS_gw00 -j DSCP --set-dscp 0x08
iptables -t mangle -I PREROUTING -i gw00 -j RECLASS_gw00
iptables -t mangle -I POSTROUTING -o gw00 -j RECLASS_gw00


However, I'm not sure how the port specific rules handle
RELATED,ESTABLISHED because I believe the initial connection is done on
port 6484 but then it uses a random high port. I'm not sure how I could add
a RELATED,ESTABLISHED match to connections on port 6484 to my custom zone
that reclassifies to 0x2e to catch *all* traffic related to it.

[-- Attachment #2: Type: text/html, Size: 3493 bytes --]