I searched Raw examples but there are no examples yet.

Just wonder which one is faster.

Thanks.

as you know raw is feature to drop packets before connection tracking it means that we can drop packets before the packets process by router.
fast track (FastPath+contrack=fasttrack)
actually usage of fast track and raw dependence based on scenario and solution.(fast track use mange facility and work on tcp/udp packets.
finally raw and fast track are two subjects separate each other.

as you know raw is feature to drop packets before connection tracking it means that we can drop packets before the packets process by router.
fast track (FastPath+contrack=fasttrack)
actually usage of fast track and raw dependence based on scenario and solution.(fast track use mange facility and work on tcp/udp packets.
finally raw and fast track are two subjects separate each other.

I think I don't understand your answer. Lets say we have 2 machines that can transfer storage using some port (we need lowest latency and highest bandwidth on this certain port between those 2 IPs) Is it better idea to put 2 rules in RAW table or add 2 rules adding connection to fasttrack?

I know fasttrack is significantly more advanced bc it's stateful, raw is stateless so everything suggests that RAW table should be absolutely fastest. But just to be sure - is my logic correct? Is raw really faster than fasttracked connection? (after establishing ofc we don't care about initial firewall matching penalty that happens before adding connection to fasttrack list)

JFYI: accept action in raw table does not mean to bypass all others.

IP RAW - feature that allows traffic to skip Connection tracking
fasttrack-connection - feature that allows traffic to skip everything else except Connection tracking.

No - you can't have both at the same time

Biggest minus of connection tracking is that if it captures packet fragments in NEEDS to de-fragment them - very time and resource consuming process, to account that packet properly

There are 2 ways to use it:

1) connection-tracking enabled=yes and use action="no-track" for some specific traffic to SKIP connection tracking for some traffic.
2) connection-tracking enabled=no and use action="accept" for some specific traffic to SEND it to connection tracking (yes, even if conntrack is off)

So fasttrack and raw is 2 excluding features really

My mind is busy with other question - what firewall filter chain=input/forward rules should i move to ip raw chain=prerouting??

JFYI: accept action in raw table does not mean to bypass all others.

Oh. So action accept in RAW just ends packet processing in RAW table? I thought it maybe stops all tables processing as in skips NAT, filtering, mangling etc. In case it doesn't i guess it makes sense how those 2 things can't be used in the same way for boosting valid traffic.

Then the question is - is there a way to achieve faster accept than fasttrack? I mean something like skip all tables AND connection tracking? Take packet, intantly take routing decision and push to output without NAT, without conntrack, without filter, without anything? I know some of those are pretty important like NAT but lets say i know those IP addresses don't need NAT or anything and there's nothing to do with those packets apart from dumb switch-like pipe basing on IP and port.

fastest way to get packet through - FASTPATH

if you need connection tracking (NAT in most cases) , and nothing else - FASTTRACK.

If you need to use other features, but some traffic doesn't require connection tracking - RAW table

fastest way to get packet through - FASTPATH

if you need connection tracking (NAT in most cases) , and nothing else - FASTTRACK.

If you need to use other features, but some traffic doesn't require connection tracking - RAW table

Can I use FASTPATH on RouterOS?

Edit: nvm found it. There's quite a lot of restrictions which are pretty much global and can't be applied only to certain traffic.

fastest way to get packet through - FASTPATH

if you need connection tracking (NAT in most cases) , and nothing else - FASTTRACK.

If you need to use other features, but some traffic doesn't require connection tracking - RAW table

No features, but just a single line of raw firewall, it disables fasttrack...
if you make a rule to "no-track" it goes in slowpath...

so you have to keep fasttrack if you need just one basic firewall raw rule