Fast Track Example Please !

RouterOS General
1

MT Team;
Please give us some Fast track examples of how and when it should be used.
What exactly it does and how we can benefit from it.

You added this feature with absolutly no explanation or information of what it is used for.

2

the forum topic includes numerous examples.

here it is again. the feature can be used in different scenarios, where you mark specific traffic, and then add a special firewall rule for it, with action fasttrack. This will speed up this traffic by not processing it. This is useful for traffic that you will not be limiting or filtering anyway.

For home users, you can even fasttrack ALL your LAN traffic by simply adding one firewall rule:

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related
add chain=forward action=accept connection-state=established,related

the second rule is needed, because some of this traffic will not be possible to fasttrack, so you need to accept it. make sure this rule is above others, in the beginning of your firewall. if you don’t want to fasttrack all, just one specific IP, modify the rule accordingly.

once rule is added, see if packets are counting for this rule in the firewall filter list. also check if the fasttracked packet count is increasing in “ip settings” menu

3

I’m not Mikrotik but I can tell you what it basically is. It’s Mikrotik’s answer to Cisco CEF, and other such accelerations.
Basically, the idea is that all packets in a flow will follow the same rules as the first packet, so it’s inefficient to check all of the rules for each packet. Once a flow has been evaluated by firewall rules, nat rules, qos, etc - the results are cached (like dynamic NAT mappings) and so future packets in the same flow will be forwarded according to the same specifications as the first one was.

Basically, it’s a big acceleration because the packets get to skip all of the firewall chains, etc. However, fast track currently requires the egress interface to use hardware queues only. This is because the system is trying to avoid thinking about packets ever again. Forward and forget. If it gets forwarded into a PCQ, then it can’t just forward the packet - there’s more thinking to do. The goal is to just take the raw packet and write the same data raw onto the egress device with whatever changes in MAC addresses / src/dst IP addresses in place. PPPoE interfaces, VPN interfaces, etc cannot participate in this because more thinking is required- the encapsulation packet must be generated, and in the case of VPN, the packet must be encrypted, so any operation like this precludes the mindless moving of data between physical interfaces.

Reading Normis’s reply reminded me that it is only available for TCP and UDP at the moment, so there’s that, too.

4

Is it normal that both fasttrack and accept counters increment equally?
I’d expect the second rule to only catch packets that were not matched by the first one. So… is the fasttrack feature working at all?
2015-06-08_11-39-28.png

5

Yes it is normal.
If you use 6.29 you can go into /ip settings and see number of fastracked packets.
If you use 6.30rc10+, then you can go into /ip firewall connection and see counters for every connection tracking entry.

6

So basically, fasttrack is skip the firewall and run like a pegasus for packets? :slight_smile:

7

It’s error described already by me somewhere here. Hopefully it is supposed to be corrected in 6.30. Looking forward.

8

Dear normis,

MikroTik certified consultant here.

  1. You stated that with those rules ALL LAN traffic will be fast-tracked.

If I understand correctly only TCP traffic has connection-states: established and related. If you go to /ip firewall connections, you will also see that this is indicated as “TCP State” and only TCP connections get those states.

So, will those rules match any other packets rather than TCP packets, like UDP or ICMP? Which of those packets will be fast-tracked?

  1. You stated that some packets that match the 1st rule may not be fast-tracked (for some reason), thus we need to specify the 2nd rule to accept that traffic.

So, why are the counters of both rules equal then?


Thanks,
Ionas

9

That’s it. Fasttrack is still not cooked well enough.

10

  1. Connection tracking state is NOT TCP state, Connection tracking state works on all prootocols even ICMP.

  2. fasttrack-connection is similar to mark-connection, it triggers a action in connection tracking, packet itself continue to go to the next rule.
    New connection tracking effect will start to work only from next packet from this connection. So you need a rule that handles these packets :slight_smile:

11

I was asked by macgaiver “why?” during receiving his negative rating. Hence the answer:

Because mikrotik still did not finished the meal. They told me that they were going to rework the fasttrack in some way that it is not so much clear for me so far. At least it seemed that the dummy rules behavior should change somehow and maybe other things will change. Hope it will be for good.