Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: leetminiwheat <LeetMiniWheat@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>,
	cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] squash/ignore DSCP and mangle table questions
Date: Mon, 13 Apr 2015 10:16:10 -0400	[thread overview]
Message-ID: <CAGHZhqEPr5pHbaQiA71CVSiGTqJMHnRfxQNaxQr_B0L-p7hJUQ@mail.gmail.com> (raw)
In-Reply-To: <CAGHZhqF7Lrj-OYoSG8SqH2a31+bYU--wAz-RXA6KELUCti2d3w@mail.gmail.com>

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

Upon further inspection, the SQM log says:

SQM: Keeping differentiated services code points (DSCP) from ingress.
SQM: Perform DSCP based filtering on ingress. (3-tier classification),

so perhaps the shaper can use this information? but only on ingress?

I'm using the latest SQM scripts from git. Could this also be why my
interfaces are remaining at 1000 txqueuelen due to new scripts? (I'm on
3.10.50-1)

Still confused about what the xset stuff is doing though.

On Mon, Apr 13, 2015 at 9:43 AM, leetminiwheat <LeetMiniWheat@gmail.com>
wrote:
>
>
>
> On Mon, Apr 13, 2015 at 7:32 AM, Sebastian Moeller <moeller0@gmx.de>
wrote:
>
> > > >         "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?
> >
> >         Because often we do not want to trust the internet to do the
right thing and not game our classification? At least this is a common
argument made...
> >
> > > I assume many ISPs and routers will squash them anyways,
> >
> >         ISPs are free to set the DSCP values to whatever suits them,
and sometimes they do weird things, in essence per default we should not
trust them...
> >
> > > but wouldn't it serve *some* purpose to differentiate between
different traffic types?
> >
> >         Sure, if you know what you do setting reasonable DSCP values
for VoIP sounds like a good thing (but due to fq_codel’s inner working
might not be required). Alas iptables is only available to us after the
packets went through the IFB, so any resetting of DSCP values would be for
internal network nodes, our shaper unfortunately can not use this
information…
>
> Curious, if fq_codel runs after iptables and can't use DSCP information,
why does it mark packets in the mangle chain? I'm still trying to wrap my
head around the --set-xmark
>
> relevant snippet here with squash disabled and ignore ingress set to
allow. Can anyone answer why it's matching DSCP marks and what is it doing
with xset? I assumed it was marking packets for use in QOS, such as the
chain suggests "Chain QOS_MARK_ge00" but this is a jump target from both
PREROUTING and POSTROUTING so it should hit FORWARD too,
>
>
#####################################################################################################
> #iptables -nL -t mangle
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination
> MARK       tcp  --  0.0.0.0/0            0.0.0.0/0            MARK xset
0x2/0xff
> fwmark     all  --  0.0.0.0/0            0.0.0.0/0
> QOS_MARK_ge00  all  --  0.0.0.0/0            0.0.0.0/0           [goto]
 mark match 0x0/0xff
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> mssfix     all  --  0.0.0.0/0            0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> DSCP       udp  --  0.0.0.0/0            0.0.0.0/0            multiport
ports 123,53 DSCP set 0x24
>
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination
> QOS_MARK_ge00  all  --  0.0.0.0/0            0.0.0.0/0           [goto]
 mark match 0x0/0xff
>
> Chain QOS_MARK_ge00 (2 references)
> target     prot opt source               destination
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            MARK xset
0x2/0xff
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            DSCP match
0x08 MARK xset 0x3/0xff
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            DSCP match
0x30 MARK xset 0x1/0xff
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            DSCP match
0x2e MARK xset 0x1/0xff
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            DSCP match
0x24 MARK xset 0x1/0xff
> MARK       all  --  0.0.0.0/0            0.0.0.0/0            tos
match0x10/0x3f MARK xset 0x1/0xff
>
> Chain fwmark (1 references)
> target     prot opt source               destination
>
> Chain mssfix (1 references)
> target     prot opt source               destination
> TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp
flags:0x06/0x02 /* wan (mtu_fix) */ TCPMSS clamp to PMTU
>
#####################################################################################################
> #iptables -S -t mangle
> -P PREROUTING ACCEPT
> -P INPUT ACCEPT
> -P FORWARD ACCEPT
> -P OUTPUT ACCEPT
> -P POSTROUTING ACCEPT
> -N fwmark
> -N mssfix
> -A PREROUTING -i vtun+ -p tcp -j MARK --set-xmark 0x2/0xff
> -A PREROUTING -j fwmark
> -A PREROUTING -i ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00
> -A FORWARD -j mssfix
> -A OUTPUT -p udp -m multiport --ports 123,53 -j DSCP --set-dscp 0x24
> -A POSTROUTING -o ge00 -m mark --mark 0x0/0xff -g QOS_MARK_ge00
> -A QOS_MARK_ge00 -j MARK --set-xmark 0x2/0xff
> -A QOS_MARK_ge00 -m dscp --dscp 0x08 -j MARK --set-xmark 0x3/0xff
> -A QOS_MARK_ge00 -m dscp --dscp 0x30 -j MARK --set-xmark 0x1/0xff
> -A QOS_MARK_ge00 -m dscp --dscp 0x2e -j MARK --set-xmark 0x1/0xff
> -A QOS_MARK_ge00 -m dscp --dscp 0x24 -j MARK --set-xmark 0x1/0xff
> -A QOS_MARK_ge00 -m tos --tos 0x10/0x3f -j MARK --set-xmark 0x1/0xff
> -A mssfix -o ge00 -p tcp -m tcp --tcp-flags SYN,RST SYN -m comment
--comment "wan (mtu_fix)" -j TCPMSS --clamp-mss-to-pmtu
>
#####################################################################################################
>
> I've inserted my custom --set-dscp user created chains into PREROUTING
and POSTROUTING, which I excluded from the above but I still don't
understand what exactly these marks are doing, even after reading the
documentation. It seems like it's still replacing DSCP from what I can tell.
>
> ------
> Also, another unrelated question regarding queue buffers;
>
> All my ifconfig interfaces show txqueuelen:1000 except for ifb4ge00 and
ifb4gw00, both of which I have SQM rate limiting on. wasn't this supposed
to be tweaked by debloat scripts? /etc/config/debloat says obsoleted by
/etc/hotplug.d/iface/02-debloat but that file is empty.
>
> uci seems to show the txqueuelen options disabled. Did something change,
are these not needed anymore, or did I screw up a config somewhere?
>  # uci show | grep debloat
> debloat.@wireless[0]=wireless
> debloat.@wireless[0].txqueuelen=4
> debloat.@wirelessn[0]=wirelessn
> debloat.@wirelessn[0].txqueuelen=16
> debloat.@wired10[0]=wired10
> debloat.@wired10[0].txqueuelen=4
> debloat.@wired100[0]=wired100
> debloat.@wired100[0].txqueuelen=16
> debloat.@wired1000[0]=wired1000
> debloat.@wired1000[0].txqueuelen=32
> uci: Entry not found
>
>
> Thanks for your time, and my apologies if these questions seem dumb or
regarded as unnecessary mailing list spam - I'm still learning and tweaking
things. I do my best to search the wikis and google before asking here.
>
>
>
>
>
>

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

  reply	other threads:[~2015-04-13 14:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13  6:37 leetminiwheat
2015-04-13  7:36 ` Sebastian Moeller
2015-04-13 10:27   ` leetminiwheat
2015-04-13 10:36     ` leetminiwheat
     [not found]     ` <ECC39EB0-9C54-4C17-9285-2484AD08ACF3@gmx.de>
2015-04-13 13:43       ` leetminiwheat
2015-04-13 14:16         ` leetminiwheat [this message]
2015-04-13 14:23           ` Sebastian Moeller
2015-04-13 16:48             ` leetminiwheat
2015-04-13 21:39               ` Sebastian Moeller
2015-04-15  1:35                 ` leetminiwheat
2015-04-15  9:05                   ` Sebastian Moeller
2015-04-22  0:19                     ` leetminiwheat
2015-04-22  0:28                       ` leetminiwheat
2015-04-22  9:19                         ` Sebastian Moeller
2015-04-22  9:03                       ` Sebastian Moeller
2015-04-22 10:17                         ` leetminiwheat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGHZhqEPr5pHbaQiA71CVSiGTqJMHnRfxQNaxQr_B0L-p7hJUQ@mail.gmail.com \
    --to=leetminiwheat@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox