The WIKI does not use passthrough for PCC associated mangle rules.
The 2019 MUM presentation at Lebanon uses passthrough on all rules.
The MUM presentation from Steve Discher uses passthrough on all rules.
There does not seem to be clear consistent logic on when to use passthrough and Mangle.
Another disturbing difference in the three references above, is that the 2019 MUM presentation uses a Mangle input chain rule for incoming traffic on the WAN side when marking connections
The other two use Mangle prerouting chain rules to do the same. I cannot fathom why the difference nor the outcomes of each.
What is clear… Facts I hope andthe sum total of what I know and have some sense of certainty!
(1) When passthrough=yes, the data flow being examined will be passed to the next rule in the Mangle ruleset for matching
(2) When passthrough=no, the data flow will NOT be passed to the next rule in the Mangle ruleset and will exit the Mangle ruleset
(3) When an accept rule is matched in Mangle rule, the data flow will NOT be passed to the next rule and will exit the Mangle ruleset.
(4) Marking connections is more efficient than marking packets.
Probably wrong assumptions on Mangle rules my part…
Assumption A: Marking connections that are followed by a required next step e.g. a marking route rule, need passthrough=yes but the marking route rule does not need passthrough=yes.
Assumption B: Marking route rules do not require further Mangle rules as they are routed next, not mangled.
Assumption C: Marking connection rules do NOT automatically require passthrough=yes which seems confusingly to me to be the case or logic, and in particular for the following situations:
(i) Output chain Mangle mark connection rules, since they are leaving the router do NOT require passthrough=yes - as they are gone, no further processing occurs on this daTA flow???
(ii) Inbound to Wan interface mark connection rules, since do they not require any routing marks applied at this juncture get marked and then follow standard incoming traffic processing…
In other words, it does not make sense to be all or none. Mangle occurs at different times throughout the lifecycle of packet flow and thus the Mangle rules are consulted for matching purposes at the appropriate times. Thus a mangle rule on input to the router has no need to be be passed to an output chain mangle rule for example…
Connections to router go through prerouting and input.
Connections through router (in this case forwarded ports) go through prerouting and forward.
If you need multi-WAN support for both, use prerouting for marking connections. If you care only about one, then just input or forward is enough.
(1) correct, (2) correct, (3) correct, (4) in context of PCC, correct
A: if marking routing is the last thing you need, yes
B: see A
C: if you check manual, you’ll find out that passthrough=yes is default value, so if you don’t see it in exported config, it’s enabled
It’s likely that many examples contain implicit passtrough=yes as a mistake, because it doesn’t really do much, it doesn’t break anything, probably only wastes few cpu cycles by unnecessarily checking an extra rule or few.
Much thanks Sob, Point ONE: I completely missed the connection between the need for pre-routing and multi-wan for marking connection. So in other words for a single WAN scenario one can use input chain and forward chain in Mangle rules.
However due to the fact that in PCC type scenarios we are talking two or more WANs typically pre-routing becomes a necessity for both.
Then how do you explain the use of input chain mangle rules in the 2019 MUM Lebanon Presentation??
Point TWO: Okay so in fact all three presentations use passthrough=yes for all rules as the wiki’s omission is a moot point if they are included by default. Understood. However you know me better by now and that a non-logic oriented argument simply doesn’t fly, or more to the point I will be fly in your soup until logic is provided. Flys poop!
Thus if you concur with my remarks at A. and B what happened when you got to my remark C. Sucked into my cone of confusion??? Deferring to a default setting is a CHEAP escape trick for some, but you are now in my web of sticky questions and will not be released until an evidence based logic is provided.
So, lets discuss…
example 1. Output - marking outgoing WAN connections (output chain).
a. when does this occur in packet flow
b. is there any other mangle rule that these packets needs to be matched too during output???
example 2. Input - marking incoming WAN connections (prerouting chain)
a. when does this occur in packet flow
b. is there any other mangle rule that these packets need to be matched to during input???
Meanwhile you peruse this post, I will be searching for the above answers…
MUM presentation doesn’t deal with forwarded ports. Only incoming connections it cares about are those to router itself, so input chain is fine.
Example 1:
a) You know the images at https://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6, I’m not sure how better to describe it.
b) It’s up to you. Call it cheap trick if you want, I don’t have any “oh it’s so cool, I need to have that” example, but I’m sure it’s possible to find some use for marking routing and doing something after. Check all possible values for action= and use your imagination. If nothing better, you can always log the packets just for fun. It doesn’t make much sense, but it’s possible.
First of all, try to comply with following logic when mangling/marking:
First rule is connection mark - it uses contrack - adding info about new connection to table
Then it’s best to use (if needed) routing mark on existing connection marks
Last of all, if needed use packet mark - alone (worst), on connection mark, on routing mark, or (best) on routing mark originating from connection mark - in this case, mikrotik watch evry packet to apply mark-packet - it’s most cpu consuming
first understand meanings of chains, as it is most helpful…
output chain means - traffic generated - going out from router (let’s say ping to 77.88.2.8 dns), traffic that goes through router (ex. web, mail, ftp etc.) if going first to prerouting then forward. It’s less consuming to router for the packets not to pass prerouting chain rules only to use forward chain (not input - packets coming to router itself - ex. winbox, telnet, ssh?) and watch for input interface.
If you need to mark something, consider bottleneck or multiple screen principle - you want to detect/filter something at most early as you can on the entrance- so observe traffic flow diagram for router os…
It doesnt, but after the first rule ex. marking packets (voip) pushing them to QoS, it can be a second one hitting the criteria, which can for ex change ToS but it should be done in PREROUTING/FORWARD chain…
input chain mangle passthrought will not check against output chain rules, it can raise CPU maybe as Sob said
