Is it possible to create more than one connection-mark for a specific connection? For example, one for doing traffic shaping and another for routing policy?
Thanks.
Re: Multiple connection-marks
Yes you can. Mark the connections first in prerouting and/or postrouting chain for traffic shaping, and then
place the queues in global-in and/or global-out interfaces.
Then use again connection marks on forward chain for routing policy.
place the queues in global-in and/or global-out interfaces.
Then use again connection marks on forward chain for routing policy.
-
-
bartmanxxi
just joined
- Posts: 6
- Joined:
Re: Multiple connection-marks
Ok, but the seconf time I mark the connection will be overiten?
Re: Multiple connection-marks
Yes, they will be overwritten the second time, but not before those packets
are captured by the queues in global-in interface.
Take a look at the flowing diagram on wiki so you can understand it better:
http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
are captured by the queues in global-in interface.
Take a look at the flowing diagram on wiki so you can understand it better:
http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
Re: Multiple connection-marks
Sorry for bump but is it possible now in different way? Routing marks are not stateful (unlike connection marks) so when you're overwriting them you either loose PBR info or QoS info for related packets. Is there any other way to acieve stateful routing-mark criteria AND stateful QoS criteria at the same time?
Naive solution is to create NxM connection marks where N is number of PBR-related marks and M is number of QoS related marks but it explodes quite quickly to 100+ marks. Stateful routing marks are necessary if you apply PBR to outgoing traffic (not forwarded). For example if you want router to reply to pings using the same interface that has been used to ping regardless of src ip.
Naive solution is to create NxM connection marks where N is number of PBR-related marks and M is number of QoS related marks but it explodes quite quickly to 100+ marks. Stateful routing marks are necessary if you apply PBR to outgoing traffic (not forwarded). For example if you want router to reply to pings using the same interface that has been used to ping regardless of src ip.
Re: Multiple connection-marks
EDIT: before I finished it, @lapsio has edited his post to suggest the same in less detail. Keeping it here for the lazy ones.
Only one connection mark can be assigned to a connection at a time, so assigning a new connection mark means rewriting (losing) the previous one. So to use connection marks to statefully control both routing marks for routing purposes and packet marks for QoS purposes requires, you have to use composite routing marks.
Let's say you need to assign two distinct routing marks and three distinct packet marks for QoS and all combinations of those two categories are possible.
So first you use one set of mangle rules using the criteria for routing to assign intermediate connection marks - cm_r1 and cm_r2.
Then, you use two similar sets of mangle rules, each referring to one of the connection marks assigned above and both using the same criteria for QoS, to assign the final composite connection marks - cm_r1_q1, cm_r1_q2, cm_r1_q3, cm_r2_q1, cm_r2_q2, cm_r2_q3.
Or you may use custom chains for the same purpose and assign the final composite connection marks at once:
Only one connection mark can be assigned to a connection at a time, so assigning a new connection mark means rewriting (losing) the previous one. So to use connection marks to statefully control both routing marks for routing purposes and packet marks for QoS purposes requires, you have to use composite routing marks.
Let's say you need to assign two distinct routing marks and three distinct packet marks for QoS and all combinations of those two categories are possible.
So first you use one set of mangle rules using the criteria for routing to assign intermediate connection marks - cm_r1 and cm_r2.
Then, you use two similar sets of mangle rules, each referring to one of the connection marks assigned above and both using the same criteria for QoS, to assign the final composite connection marks - cm_r1_q1, cm_r1_q2, cm_r1_q3, cm_r2_q1, cm_r2_q2, cm_r2_q3.
Or you may use custom chains for the same purpose and assign the final composite connection marks at once:
Code: Select all
/ip firewall mangle
### chain=prerouting:
# skip to routing and packet mark assignment if packet belongs to an already marked connection:
add chain=prerouting action=jump jump-target=assign-r-q-marks connection-mark=!no-mark
# only packets belonging to not-yet-marked connections, i.e. initial packets of each connection, get here
# because chain=assign-r-q-marks always provides a final verdict so nothing ever returns from there
add chain=prerouting action=jump jump-target=r1-conns ...criteria for selection of routing policy #1 here...
# only initial packets matching routing policy #2 criteria should get here
add chain=prerouting action=mark-connection new-connection-mark=cm_r2_q1 passthrough=yes ...criteria for selection of QoS policy #1 here...
add chain=prerouting action=mark-connection new-connection-mark=cm_r2_q2 passthrough=yes connection-mark=no-mark ...criteria for selection of QoS policy #2 here...
#only initial packets matching routing policy #2 criteria and QoS policy #3 criteria should get here
add chain=prerouting action=mark-connection new-connection-mark=cm_r2_q3 passthrough=yes connection-mark=no-mark
add chain=prerouting action=jump jump-target=assign-r-q-marks
### chain=r1_conns:
add chain=r1_conns action=mark-connection new-connection-mark=cm_r1_q1 passthrough=yes ...criteria for selection of QoS policy #1 here...
add chain=r1_conns action=mark-connection new-connection-mark=cm_r1_q2 passthrough=yes connection-mark=no-mark ...criteria for selection of QoS policy #2 here...
#only initial packets matching routing policy #1 criteria and QoS policy #3 criteria should get here
add chain=r1_conns action=mark-connection new-connection-mark=cm_r1_q3 passthrough=yes connection-mark=no-mark
add chain=r1_conns action=jump jump-target=assign-r-q-marks
### chain=assign-r-q-marks:
### first, assign routing marks:
add chain=assign-r-q-marks action=mark-routing new-routing-mark=r1 connection-mark=cm_r1_q1,cm_r1_q2,cm_r1_q3 passthrough=yes
add chain=assign-r-q-marks action=mark-routing new-routing-mark=r2 passthrough=yes
### then, assign packet (QoS) marks:
add chain=assign-r-q-marks action=mark-packet new-packet-mark=q1 connection-mark=cm_r1_q1,cm_r2_q1 passthrough=no
add chain=assign-r-q-marks action=mark-packet new-packet-mark=q2 connection-mark=cm_r1_q2,cm_r2_q2 passthrough=no
add chain=assign-r-q-marks action=mark-packet new-packet-mark=q3 passthrough=noRe: Multiple connection-marks
Hmm I wonder if it'd be possible to template it. I mean to create marks for QoS, marks for routing and make script that will duplicate given chain M times and will compute and replace new marks for each routing mark. And do the same for QoS queues.
I know it would be just nobody has time to write such script because it'd take at least 2 days XD
Also I think having like 2k rules in mangle could have terrible impact on performance
I know it would be just nobody has time to write such script because it'd take at least 2 days XD
Also I think having like 2k rules in mangle could have terrible impact on performance
Re: Multiple connection-marks
What kind of input to the generating script would you expect? It is a matter of two hours to write such script, but you'd spend the remaining 46 hours debugging it 
What do you mean by doing the same for QoS queues - to create an own copy of the queue tree for each WAN? What if the WANs have different bandwidth?
The 2k mangle rules are not that bad as each packet would pass just a small subset of them.
What do you mean by doing the same for QoS queues - to create an own copy of the queue tree for each WAN? What if the WANs have different bandwidth?
The 2k mangle rules are not that bad as each packet would pass just a small subset of them.
Re: Multiple connection-marks
I mean that for example for following rules:What kind of input to the generating script would you expect? It is a matter of two hours to write such script, but you'd spend the remaining 46 hours debugging it
What do you mean by doing the same for QoS queues - to create an own copy of the queue tree for each WAN? What if the WANs have different bandwidth?
The 2k mangle rules are not that bad as each packet would pass just a small subset of them.
Code: Select all
chain=prerouting action=jump jump-target=routemark connection-mark=no-mark
chain=routemark action=mark-connection new-connection-mark=mgmt in-interface=br-mgmt
chain=routemark action=mark-connection new-connection-mark=srv dst-address-list=networkSERVICE
...
chain=prerouting action=jump jump-target=qosmark connection-mark=no-mark
chain=qosmark action=mark-connection new-connection-mark=www protocol=tcp dst-port=80,443
chain=qosmark action=mark-connection new-connection-mark=ssh protocol=tcp dst-port=22
...
Code: Select all
chain=prerouting action=jump jump-target=qosmark-mgmt connection-mark=mgmt
chain=qosmark-mgmt action=mark-connection new-connection-mark=mgmt-www protocol=tcp dst-port=80,443
chain=qosmark-mgmt action=mark-connection new-connection-mark=mgmt-ssh protocol=tcp dst-port=22
...
chain=prerouting action=jump jump-target=qosmark-srv connection-mark=srv
chain=qosmark-srv action=mark-connection new-connection-mark=srv-www protocol=tcp dst-port=80,443
chain=qosmark-srv action=mark-connection new-connection-mark=srv-ssh protocol=tcp dst-port=22
...
and so on, one copy for each routing mark given as parameter
Who is online
Users browsing this forum: lubara and 175 guests