Has anyone been able to get a 1Gbps throughput on an RB750Gr3 w/o Fasttrack?
Disabling Fasttrack yields about 220 Mbps maximum throughput.
Has anyone been able to get a 1Gbps throughput on an RB750Gr3 w/o Fasttrack?
Disabling Fasttrack yields about 220 Mbps maximum throughput.
For example with notrack?
I never used notrack
I assume jarda refers to disabling connection tracking in firewall.
Have never tested this and not sure how it will affect speeds, but you will lose any NATting functionality if you disable this
No track is useful for plain forwarding/routing on high bandwidth connections, as it doesn’t do connection tracking. So no state-full firewall, just stateless. Lowers memory and cpu load.
Unfortunately, I need to keep masqarade on so I guess fast track it is.
Then fasttrack is your best friend. Until you need to use queues…
I don’t need them but If I want them 75% performance hit sigh.
Keep in mind that you can fast-track selectively: so important stuff, needed to go in front of queue → don’t fast-track, mangle and put in queue before “bulk”
Really just move the queue rules up or how?
when marking for fast-track you can tighten the conditions a connection need to have to be fasttracked.
Ex:
add action=fasttrack-connection chain=forward comment="FastTrack: established & related" connection-mark=FT \
connection-state=established,related
So only connections marked with “FT” are fasttracked, and VOIP and other low prio traffic without that mark, don’t get processed.
then in queueing have separate queue for bulk / fasttrack (mark = “no-mark”) and other queues for other non-fasttracked traffic (mark != “no-mark”)
I’m trying to understand how this works when we know that fast track will break queues. If I fast track all established and related connections, don’t they immediately become not eligible for queuing?
This is interesting, there should be a wiki page on it if there isn’t already…
There are two kind of queues:
Fast-tracking basically bypasses a lot of normal packet processing, which makes the packet go faster through router, and allowing the router to process more packets. It’s not a silver bullet. When Fast-Tracking, packet mangling is bypassed and so are the global hooks. So Simple queues are bypassed. Queues attached to interfaces are still usable though.
So for a fast-track connection (most) of the packets will bypass mangling and will arrive at the interface queue without any markings => packet-mark = “no-mark”.
If a connection is not fast-tracked, all the functionality of MT is available and marking can be executed. => packet-mark =
And so on the interface one can have an HTB with mulple queues: 0 or more for not “fast-tracked & mangled” traffic and 1 for “fast-tracked and not mangled” traffic.
Ahh yes. I was thinking of simple queues. Thanks for the explanation.