1 - How does the command work?
2 - Traffic entering your diffserv domain is frequently mis-
marked in transit from the perspective of your network. What does this mean and what are the consequences of this?
3 - and
traffic exiting yours may be mis-marked from the perspective of
the transiting provider. What does this mean and what are the consequences of this?
Maybe read the man-page?
https://man.archlinux.org/man/tc-cake.8.en
Traffic entering your diffserv domain is frequently mis-marked in transit from the perspective of your network, and traffic exiting yours may be mis-marked from the perspective of the transiting provider.
Apply the wash option to clear all extra diffserv (but not ECN bits), after priority queuing has taken place.
If you are shaping inbound, and cannot trust the diffserv markings (as is the case for Comcast Cable, among others), it is best to use a single queue "besteffort" mode with wash.
You add the keyword wash to your cake invocation or you do not do this depending on your goals.
As it says... essentially unless you have an agreement with your upstreams to classify traffic based on your desires, what ever DSCPs your ISP uses will be dependent on what your ISP wants to achieve with those DSCPs. So if you use diffserv3/4/8 on your ingress side you should make sure to sanitize the ingress DSCPs so they match your classification desires.
The reverse, what ever DSCPs you use inside your home network unless you have a (likely costly) agreement with your ISPs will not make sense for your ISP and marked packets might be delayed or dropped.
If I might ask, what is the motivation behind your series of detailed questions?
I wanted a more detailed explanation of how it works. From what I researched, it turns all traffic into besteffort, but I tested it here and it continues to fall into other tins besides besteffort.
Wouldn't it be downstream? And would there be any problem in not clearing their markings?
When do these decisions that the ISP makes in the markings happen? When it reaches the operator's modem or at a specific point on the route?
I forgot to mention that I don't use tags upstream, but traffic still falls into other categories besides besteffort.
Well, as the man page tries to explain, wash will re-mark any DSCP to CS0 after cake has queued up a packet. So let's look at an example a packet comes in marked EF (DSCP dec46) into a cake instance configured to use diffserv4:
a) cake will look at the existing DSCP, EF, to steer that packet into the matching priority tin (for diffserv4 EF maps into the highest priority tin Voice).
b) cake will then re-mark the packet's DSCP to CS0 but still treat it to Voice priority.
(In case besteffort is selected, the packet will stay in the only existing priority tier, but the DSCP will be remarked nevbertheless).
So it does not turn everything into best effort it will just "wash away" the old DSCP...
Misunderstanding, I was answering the question 2 about mismarked packets that is packets coming from your upstream that carry DSCPs that do not map these packets into the priority tin you want them to end up in.
It turns out the most robust thing to do with ingress packets is to meaningfully remark the DSCPs to match your intentions. For that the "copy the egress DSCP (that you can assign according to your wishes) to ingress packets for the same connection" works pretty well. If you just use besteffort on your ingress without wash and without the conntrack based remarking action I just mentioned your ISP's DSCPs will still be retained and might e.g. affect the WiFi/WMM priority scheduling.
You need to ask your ISP... typically ISPs are know to clear those DSCPs they use in their own network, DSCPs they do not use they might or might not re-mark to any other DSCP (often, but not always CS0). Maybe read a few of the DSCP related RFCs like:
https://www.rfc-editor.org/rfc/rfc2474.html
https://www.rfc-editor.org/rfc/rfc2475
Well, cake in default configuration will use the existing DSCP value to steer a packet into its priority tiers, so if in diffserv3/4/8 you see packets in other tins than BestEffort there will have been packets with the required DSCPs...
Here is a command you can run on your OpenWrt rputer to see all DSCPs different from CS0 on br-lan:
tcpdump -i br-lan -v -n '(ip and (ip[1] & 0xfc) >> 2 != 0)' or '(ip6 and (ip6[0:2] & 0xfc0) >> 4 != 0)'
Maybe have a look whether you catch any packets there... (Keep in mind some applications will by default use DSCPs different from CS0).
So the markings I saw are from some application that uses DSCP markings? If so, is it recommended to use the wash command on them?
1- I would like to know if there is also a method to clear tags without using CAKE.
2 - How do I add DSCP tags?
Likely.
Since your ISP is unlikely to honour your priority intentions from your DSCPs you might be better off using wash for the egress/upload side.
Sure, you can use iptables/nftables (and you can configure this via the luci firewall GUI), and you can use tc as well for that, but note for IPv4 when modifying the IP header you also need to recompute and adjust the checksum.
Typically you can use:
a) the applications marking capabilities (e.g. iputils ping allows you to specify the 8bit TOS value, if you just multiply your DSCP by 4 (to shift the 6bit DSCP value two bits to the left)) you have the corresponding TOS value
b) you can use the OS's capability to DSCP mark, e.g. windows/powershell allows to create application specific marking rules
c) you can use iptables/nftables to create marking rules (you can configure these also via the luci GUI for the firewall).
Note, all of these work for egress packets, for ingresing packets you can only use c) and/or eBPF rules as used by qosify.
For starting out, have a look at either eBPF-based qosify or qosmate that allow much easier marking of ingress traffic. qosmate uses a method in which it copies your egress DSCPs into the conntrack database and applies the same DSCP to incoming packets even before cake sees them, which is neat in that this allows to easily mark ingress and egress packets for the same flow with the same mark... this is often all one needs.
Cool, thanks for the help.