how-to block ads
Mikrotik Shaper Would anyone be able (or willing) to share a very basic BRIDGED and transparent shaper code for MT?
I have a few examples, And some paid versions LOL... and have run in to the strangest snag I think I have found. When running speed tests from a test PC everything works like it should. Tx and RX are shaped. They show the queues getting hit at the proper queue, Etc.. NOW, if I run a simultaneous test going both directions, only one rule gets hit, and it's a combination of the two directions throughput.
I know this should be easy. And I thought it was. But testing is proving I've done something wrong, or MT isn't working like it should. I'm going to assume it's me, but it just feels very strange. Tried on 5.2 and 5.23. Also tried to route through this box, and it acts the same danged way.
Is is needed that I mark my packets each direction, and via the appropriate interface?? Currently I have only marked them via one rule. I'd post code, but this does incorporate some paid for use code, so I shouldn't unfortunately.
I only mark the packet in the firewall based upon src/dst ports, layer 7, etc. I do not mark based upon interface.
add action=mark-connection chain=prerouting comment="SMTP - Port 25 - Connection" disabled=no new-connection-mark=MAIL_CON passthrough=yes port=25 protocol=tcp
add action=mark-connection chain=prerouting comment="SMTPS - Port 587 - Connection" disabled=no new-connection-mark=MAIL_CON passthrough=yes port=587 protocol=tcp
add action=mark-connection chain=prerouting comment="POP3 - Port 110 - Connection" disabled=no new-connection-mark=MAIL_CON passthrough=yes port=110 protocol=tcp
add action=mark-connection chain=prerouting comment="IMAP - PORT 143 - Connection" disabled=no new-connection-mark=MAIL_CON passthrough=yes port=143 protocol=tcp
add action=mark-packet chain=prerouting comment="MAIL Traffic - Packet" connection-mark=MAIL_CON disabled=no new-packet-mark=MAIL passthrough=no
In the queue tree is where it is shaped based upon the exiting interface (notice it is on the interface and not the bridge)
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=100M name=TRAFFIC_OUT parent=to_internet priority=8
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=250M name=TRAFFIC_IN parent=to_customers priority=8
Then the individual leafs
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=512k max-limit=10M name=MAIL_IN packet-mark=MAIL parent=TRAFFIC_IN priority=6 queue=default
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=128k max-limit=10M name=MAIL_OUT packet-mark=MAIL parent=TRAFFIC_OUT priority=6 queue=default
I survived Hale-Bopp!
reply to gunther_01
We aren't marking based on interface. So that looks the same, But we are using address lists for source and destination. Which means we are marking for both direction.
I have tried using global in and outs while bridged, and also interfaces I believe. Now I've routed the box, and using interfaces. Either way shows the same response.
When I run a "both" test, Btest from PC through MT to another MT, only one queue picks up both directions of that test. And sums the throughput in that one queue. For some reason the packets going two directions are getting hit on only one queue when we do a both speed test.
Now when we do single direction tests, everything works as expected. Very strange IMO. And I have seen this with other configurations I have done. And all of those have failed when added to our network and it's traffic. To the point the MT locks up after a few seconds. So something is obviously wrong there LOL. It's not my imagination