MikroTik

Posted: **Tue Apr 28, 2015 9:58 am**

Starting from v6.29rc9, we introduced new and existing feature - FastTrack. Easy way to make your Firewall/NAT router up to 5x faster.

*) ipv4 fasttrack fastpath - accelerates connection tracking and nat for marked connections (more than 5x performance improvement compared to regular slow path conntrack/nat) - currently limited to TCP/UDP only;
*) added ~fasttrack-connection~ firewall action in filter/mangle tables for marking connections as fasttrack;
*) added fastpath support for bridge interfaces - packets received and transmitted on bridge interface can go fastpath (previously only bridge forwarded packets could go fastpath);
*) packets now can go half-fastpath - if input interface supports fastpath and packet gets forwarded in fastpath but output interface does not support fastpath or has interface queue other than only-hw-queue packet gets converted to slow path only at the dst interface transmit time;
*) trafflow: add natted addrs/ports to ipv4 flow info.

http://www.mikrotik.com/download/share/FastTrack.pdf

FastTrack documentation,
http://wiki.mikrotik.com/wiki/Manual:Wi ... escription

Posted: **Tue Apr 28, 2015 10:05 am**

Can we get some bigger pictures. I can not see the firewall examples. Also if possible show examples in text version.
If I understand this correctly I have to make a mangle rule to mark packets as fasttrack. But then I guess I need to make another rule to make some processing with them ?

Posted: **Tue Apr 28, 2015 11:00 am**

As far as i understood, in case of regular home router, you should have these 3 rules in beginning of firewall filter forward, to use Fasttrack.

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

Note, that all packets that goes fasttrack, will not be visible in firewall and you will not be able to limit them in queue global.

Posted: **Tue Apr 28, 2015 12:03 pm**

I added this rule to the top.

[admin@RB850Gx2] > /ip firewall filter print 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 
 1    chain=forward action=accept connection-state=established,related log=no log-prefix=""

There were no changes in CPU Load. And:

/ip settings print
           [......]
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0

Still need some kind of action to get it working?

PS v6.29rc11

Posted: **Tue Apr 28, 2015 12:26 pm**

I will wait for 6.29 final before trying this, but in your rules you add a fasttrack rule and then an accept rule. What happens if there is no accept rule. Doesn't the fasttrack rule here do exactly this - passthrough all packets matched by it ?

Posted: **Tue Apr 28, 2015 12:35 pm**

I will wait for 6.29 final before trying this, but in your rules you add a fasttrack rule and then an accept rule. What happens if there is no accept rule. Doesn't the fasttrack rule here do exactly this - passthrough all packets matched by it ?

Yes, but accept is also needed - it was mentioned in the presentation that a few packets (10%) will still need to be processed outside of fast-track, because of connection integrity checking, out of order delivery, security, etc.

If you didnt have the normal allow, those would be dropped.

Check the MikroTik presentation from the US MUM.

Posted: **Tue Apr 28, 2015 1:59 pm**

For the first moment it looked very exciting and promising.

But now I am not sure that adding additional rules, especially if they break other commonly used features like statistics and queues, will help significantly. Moreover when it is applicable only in some cases.

I would rather see some real improvement then such half-way things. There are surely reserves in packets processing and in memory usage that could be addressed...

If there are some conditions that would allow fasttrack, why I have to create additional user rules for it? Why packets that could be processed in fasttrack mode are not processed so transparently in the background?

Posted: **Tue Apr 28, 2015 2:04 pm**

The idea is to "fasttrack" some specific machine without slowing it's traffic for processing. Let's say you have a network of users, you have firewall and queues for them. But then you have a VIP customer (or your own PC) that you will not filter or slow down, and you want the best available speed for it. This is the situation for fasttrack.

Posted: **Tue Apr 28, 2015 2:08 pm**

Yeah, but even in those cases, you still want the best available speed... That would not completely block out the rest of the network, so even "VIP" customers need SOME restrictions imposed on them.

I think this feature will be most useful when the MikroTik router is used as a CPE device - in those cases, you don't want to impose any restrictions onto the device itself, but you want to impose them upstream, at your central router(s). So if both routers are MikroTik routers, you can use fastpath, and fasttrack to get the best inner-network performance, and still apply statistics and queues on the "edge" routers.

Posted: **Tue Apr 28, 2015 2:10 pm**

My home devices also don't need any filtering or queuing. The AP is only there for wireless access. Why not make the internet faster with a few rules?

Posted: **Tue Apr 28, 2015 2:14 pm**

Normis, that should be said before.
Boen_robot, agree with you.

We will see how it will be effective in real traffic situations. But I still would rather see some general improvements like I wrote before.

Posted: **Tue Apr 28, 2015 2:50 pm**

KBV - Did you use CCR device? FastTrack will work properly on CCR devices starting from 6.29rc14 version

Posted: **Tue Apr 28, 2015 2:56 pm**

Question - if I have no rules in forward chain - only in input chain (typical transit router) - will FastTrack be active?

IMO, if there are no rules in a default chain, that chain should automatically be FastTracked (so I dont have to add rules now to tons of transit routers to take advantage of FastTrack).

Posted: **Tue Apr 28, 2015 3:43 pm**

It is not about filter rules, it is also about NAT. Basically it is fastpath solution when connection tracking is necessary.
You obviously need to process some packets normal way through the connection tracking to put all local/public IPs in order, so i do not think that automatic fasttrack is possible. Nut i think it should be in all board default config that also have NAT.

Posted: **Tue Apr 28, 2015 4:40 pm**

It is not about filter rules, it is also about NAT. Basically it is fastpath solution when connection tracking is necessary

Connection tracking can operate without NAT, It is rather a function of the "Full State Firewall"
If the FS firewall and NAT is not necessary, tracking is better forcibly disable

Posted: **Tue Apr 28, 2015 7:29 pm**

FastTrack

great improvement, thanks... just tested a bit

Posted: **Tue Apr 28, 2015 8:33 pm**

Wow simply adding the filter to accept fasttrack and away it goes...

ip settings print
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 268210
ipv4-fasttrack-bytes: 307676029

I went 6.29rc13 due to the fix of the excessive sector-rewrites. I had a new router go from 1000 to over a million in its total sector-rewrite count due to 6.28 in yes 4 days uptime....

Posted: **Tue Apr 28, 2015 9:26 pm**

ip settings prin
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0

0 bytes

Posted: **Tue Apr 28, 2015 9:36 pm**

visalink: How does/do your firewall rule/rules look like?

or

Did you use CCR device? FastTrack will work properly on CCR devices starting from 6.29rc14 version.

Posted: **Tue Apr 28, 2015 10:06 pm**

KBV - Did you use CCR device? FastTrack will work properly on CCR devices starting from 6.29rc14 version

Oh, no. I did not know that it only works on CCR
I tried to run on 850gx2

Posted: **Tue Apr 28, 2015 10:15 pm**

I run it on RB2011UAS-2HnD and it works.

fasttrack-works.png

Posted: **Tue Apr 28, 2015 10:30 pm**

visalink: How does/do your firewall rule/rules look like?

or

Did you use CCR device? FastTrack will work properly on CCR devices starting from 6.29rc14 version.

ip/firewall/filter
chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=""
chain=forward action=accept connection-state=established,related log=no log-prefix=""

Only a test in RB750g, no result...

Posted: **Tue Apr 28, 2015 10:33 pm**

I feel there is some kind of trick

Posted: **Wed Apr 29, 2015 12:01 am**

On rb333 don't work.
ip fi filter print stats
1 forward fasttrack-connection 282 362 923 317 144
2 input accept 6 086 144 43 102
ip settings pr
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0

Posted: **Wed Apr 29, 2015 3:41 am**

It won't work unless there is some NAT, Bridges involved in your traffic, plus 6.29B13 upwards, plus of course accepting the fast-track in the filter rules..

For example Ive got 4 more MTs downstream in my network, but its only the one using NAT that it works on as its masquerading.

Ive not put in a single mangle rule for this, I have mangle rules for other routing, but merely putting in the filter rule to accept fast-track and its gone nuts - this in a great way. Yes I have noticed a throughput increase and BIG CPU drop in high use.

Posted: **Wed Apr 29, 2015 6:46 am**

Tested on my old and good RB333, but it seens it is not working.
I have a PPPoE client connection, so a dynamic mangle rule to "change MSS" to 1452.
Does it matter?
And yes, the counters are running for all filter rules.

[admin@RB333] > ip fi fi pri
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 
 1    chain=forward action=accept connection-state=established,related log=no log-prefix="" 
 2    chain=forward action=drop connection-state=invalid log=no log-prefix="" 
 [admin@NALTECSAT] > ip set pri  
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0

Posted: **Wed Apr 29, 2015 8:20 am**

It is not about filter rules, it is also about NAT. Basically it is fastpath solution when connection tracking is necessary
Connection tracking can operate without NAT, It is rather a function of the "Full State Firewall"
If the FS firewall and NAT is not necessary, tracking is better forcibly disable

i think you misunderstood me - RB75x, RB95x, RB2011, hAP, mAP, cAP - most common setups on these boards includes masquerade rule and some firewall filters. So with this FastTrack feature you "magically" make them much faster. So i expect that default configuration (from factory), will have it enabled by default.

I did some testing, on FastTrack, I have 500Mbps connection at the office, sitting on CCR1009, for a test purpose i replaced it with RB2011, and run some "linux distribution" torrent download this morning.

Without FastTrack - 220-240Mbps download with CPU 100%
With FastTrack - 460-500Mbps (full pipe) download with CPU 56-84%

As i need queues and IPsec i switched back to CCR1009, but this opens lots of possibilities..

Posted: **Wed Apr 29, 2015 8:49 am**

Tested on my old and good RB333, but it seens it is not working.
I have a PPPoE client connection, so a dynamic mangle rule to "change MSS" to 1452.
Does it matter?
And yes, the counters are running for all filter rules.

This is just a theory..
1) FastTrack is a Conntrack extension of FastPath,
2) FastPath requires in and out interface support to work
3) pppoe-client doesn't have FastPath support

Result:
fasttrack doesn't work on pppoe-clients

Posted: **Wed Apr 29, 2015 8:53 am**

These results sound very promising. But can only be used in some configurations. The typical home router can benefit a lot.
But for example I want to somehow use this on ptp wireless connections, because i have a mangle rule to set nv2 priority from dscp for QoS. And as this changes header of all packets I guess fasttrack is not possible in this scenario ?

Posted: **Wed Apr 29, 2015 9:03 am**

These results sound very promising. But can only be used in some configurations. The typical home router can benefit a lot.
But for example I want to somehow use this on ptp wireless connections, because i have a mangle rule to set nv2 priority from dscp for QoS. And as this changes header of all packets I guess fasttrack is not possible in this scenario ?

I do not think it is possible, only changes made by ConnTrack is supported, in your case those are custom changes.

But it is a firewall action, so you can basically use it in any place where you have "accept everything else" logic just add "fasttrack everything else" rule before the accept.

Posted: **Wed Apr 29, 2015 9:48 am**

I tryed 6.29rc14 today, no joy

RB951G, cpu on 100%, routing take all cpu .
fast-track counting packages, but on ip settings no counter

I use VPLS/MPLS on this router

Posted: **Wed Apr 29, 2015 12:38 pm**

At this moment FastTrack is not working on PowerPC devices, but with latest rc14 version it works on other platforms.

Posted: **Wed Apr 29, 2015 2:38 pm**

These results sound very promising. But can only be used in some configurations. The typical home router can benefit a lot.
But for example I want to somehow use this on ptp wireless connections, because i have a mangle rule to set nv2 priority from dscp for QoS. And as this changes header of all packets I guess fasttrack is not possible in this scenario ?
I do not think it is possible, only changes made by ConnTrack is supported, in your case those are custom changes.

But it is a firewall action, so you can basically use it in any place where you have "accept everything else" logic just add "fasttrack everything else" rule before the accept.

Unfortunately I am dropping everything else, not accepting that...

Posted: **Wed Apr 29, 2015 2:43 pm**

But at least established and related could be fasttracked, hopefully. Had not time to make own tests so far...

Posted: **Wed Apr 29, 2015 6:17 pm**

playing with new feature with an rb411ar

had to enable wireless-fp to work?!?!
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 189561
ipv4-fasttrack-bytes: 14324143

Posted: **Wed Apr 29, 2015 8:23 pm**

Is working for me with these rules:

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

Posted: **Wed Apr 29, 2015 9:12 pm**

Any chance RCs could include the 'wireless-cm2' package?
At least for mipsbe...

Thanks

Posted: **Wed Apr 29, 2015 9:30 pm**

It is the first time I want to upgrade RouterOS to get some feature.

I might not need to upgrade my RB2011 to take full advantage of my new pipe after all.

Posted: **Thu Apr 30, 2015 12:38 am**

Mikrotik, please PLEASE take your time. I don't think most of us care if you take 3 months. Take the time to perfect 6.29, or at least make it as good as possible.

Also, awesome

Posted: **Thu Apr 30, 2015 1:07 am**

Note, that all packets that goes fasttrack, will not be visible in firewall and you will not be able to limit them in queue global.

I wonder whether those packets will be accounted by Traffic Flow...

Posted: **Thu Apr 30, 2015 5:15 am**

Note, that all packets that goes fasttrack, will not be visible in firewall and you will not be able to limit them in queue global.
I wonder whether those packets will be accounted by Traffic Flow...

That is a question I have too.

Mikrotik, can you shine a torch on this ?

Posted: **Thu Apr 30, 2015 8:07 am**

In current implementation (6.29rc15) FastTracked (and FastPathed) packets will not be accounted in Traffic Flow.
But.. there are possibilities to extend FastPath/FastTrack feature set in the future.

At the moment, please, test basic FastTrack functionality, and report back if you encounter any issues.

Posted: **Thu Apr 30, 2015 8:54 am**

Any chance RCs could include the 'wireless-cm2' package?
At least for mipsbe...

Thanks

you can just guess the link:
http://www.mikrotik.com/download/share/ ... mipsbe.npk

the files are there

Posted: **Thu Apr 30, 2015 11:59 am**

If this is something like "NAT Accelerator" or I don't know how is called by other manufacture, it's a very good job.
congratulation Mikrotik, I hope will be released soooooon.
There are some cheap brands like tpl.nk etc, at half price and do +2x faster pppoe/NAT like a MikroTik.

Posted: **Thu Apr 30, 2015 12:05 pm**

Looking like this will not work with pppoe. At least for now.

Posted: **Thu Apr 30, 2015 2:20 pm**

All supported all platforms, including mipsle?

Posted: **Thu Apr 30, 2015 3:55 pm**

Looks like currently it is implemented only in MIPSBE, i was not able to get other architectures working.

Posted: **Thu Apr 30, 2015 7:06 pm**

Yes, it seems so.
I also tried it on MIPSBE. There are small oddities, but generally works well

On my other platforms it has not yet happened.

Posted: **Fri May 01, 2015 12:11 am**

I tried it on RB2011UiAS-2HnD with a VLAN for internet on my WAN port, this is in a bridge called bridge-wan with another VLAN for IPTV(needs different VLAN MAC). Added the firewall rules but internet stops working unless torch is active on the VLAN port(which stops fasttrack I guess).

Maybe some need to investigate?

Posted: **Fri May 01, 2015 7:27 am**

What about IPv6?

Is the rule with "action=accept" after the "action=fasttrack.." really required?

Posted: **Fri May 01, 2015 2:32 pm**

Very big shame on no PPPoE client support - most of all networks I work with require PPP style connection with it being the out-interface for NAT.

Is there a limitation on being able to enable this for PPP connections making it not possible or is it something that is being worked on?

Posted: **Fri May 01, 2015 8:44 pm**

For me, on my 2011UiAS-2HnD with 6.29rc14 "IPv4 Fasttrack Active" keeps saying no whilst i have added the firewall rule. Am i missing something?

[admin@MikroTik] > /ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; default configuration
      chain=forward action=drop connection-state=new 
      connection-nat-state=!dstnat in-interface=wan log=no log-prefix="" 

 1    chain=forward action=fasttrack-connection 
      connection-state=established,related log=no log-prefix="" 

 2    ;;; default configuration
      chain=forward action=accept connection-state=established,related log=no 
      log-prefix="" 

 3    ;;; default configuration
      chain=forward action=drop connection-state=invalid log=no log-prefix=""

[admin@MikroTik] > /ip settings print
              ip-forward: yes
          send-redirects: yes
     accept-source-route: no
        accept-redirects: no
        secure-redirects: yes
               rp-filter: no
          tcp-syncookies: no
         max-arp-entries: 8192
             arp-timeout: 30s
         icmp-rate-limit: 10
          icmp-rate-mask: 0x1818
         allow-fast-path: yes
   ipv4-fast-path-active: no
  ipv4-fast-path-packets: 0
    ipv4-fast-path-bytes: 0
   ipv4-fasttrack-active: no
  ipv4-fasttrack-packets: 852
    ipv4-fasttrack-bytes: 395836

Edit: Nevermind, in the web interface i can see fasttrack gets disabled as soon as i connect winbox through the MAC adress of the router.... It does not do it when i use the assigned ip adress.

Posted: **Sat May 02, 2015 8:05 am**

[admin@Matrix] > ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; Fasttrack
      chain=forward action=fasttrack-connection 
      connection-state=established,related log=no log-prefix="" 

 1    ;;; Fasttrack
      chain=forward action=accept connection-state=established,related log=no 
      log-prefix="" 

 2    ;;; Fasttrack
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

 3    ;;; Add Syn Flood IP to the list
      chain=input action=add-src-to-address-list tcp-flags=syn protocol=tcp 
      address-list=Syn_Flooder address-list-timeout=30m 
      connection-limit=30,32 log=no log-prefix="" 

 4    ;;; allow l2tp
      chain=input action=accept protocol=udp dst-port=1701 log=no 
      log-prefix="" 

 5    ;;; allow pptp
      chain=input action=accept protocol=tcp dst-port=1723 log=no

[admin@Matrix] > ip settings print
              ip-forward: yes
          send-redirects: yes
     accept-source-route: no
        accept-redirects: no
        secure-redirects: yes
               rp-filter: no
          tcp-syncookies: no
         max-arp-entries: 8192
             arp-timeout: 30s
         icmp-rate-limit: 10
          icmp-rate-mask: 0x1818
         allow-fast-path: yes
   ipv4-fast-path-active: no
  ipv4-fast-path-packets: 0
    ipv4-fast-path-bytes: 0
   ipv4-fasttrack-active: yes
  ipv4-fasttrack-packets: 124436175
    ipv4-fasttrack-bytes: 73674832855

Posted: **Sat May 02, 2015 4:28 pm**

Work fine RB951G-2HnD - 6.29rc14

/ip settings> print
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 9958656
ipv4-fasttrack-bytes: 10423205479

Posted: **Sun May 03, 2015 1:46 pm**

6.29rc14
With enabled FastTrack increased connections with last-ack state, is that normal?

/ip firewall filter
add action=fasttrack-connection chain=forward comment=\
    "fasttrack established+related" connection-state=established,related
    
add chain=forward comment="enable established+related" connection-state=\
    established,related
    
add action=drop chain=forward comment="drop invalid" connection-state=\
    invalid

last-ack.png

Posted: **Mon May 04, 2015 12:21 am**

I'm guessing this doesn't work on vlan interfaces yet? Or have I missed something?
Below from a CCR running 6.29rc14:

/ip firewall filter
add action=fasttrack-connection chain=forward comment="Accept established/related" connection-state=established,related in-interface=vlan10
add chain=forward comment="Accept established/related" connection-state=established,related in-interface=vlan10
add action=drop chain=forward comment="Drop invalid" connection-state=invalid in-interface=vlan10
add action=drop chain=forward comment="Drop everything else" in-interface=vlan10

              ip-forward: yes
          send-redirects: no
     accept-source-route: no
        accept-redirects: no
        secure-redirects: no
               rp-filter: strict
          tcp-syncookies: no
         max-arp-entries: 8192
             arp-timeout: 30s
         icmp-rate-limit: 10
          icmp-rate-mask: 0x1818
         allow-fast-path: yes
   ipv4-fast-path-active: no
  ipv4-fast-path-packets: 0
    ipv4-fast-path-bytes: 0
   ipv4-fasttrack-active: yes
  ipv4-fasttrack-packets: 0
    ipv4-fasttrack-bytes: 0

Posted: **Mon May 04, 2015 9:15 pm**

My home devices also don't need any filtering or queuing. The AP is only there for wireless access. Why not make the internet faster with a few rules?

just a guess: "because complormised SOHO/home network may cost consumers ANYthing, inlcluding their lives, sometimes"? or "because secuirty is least feature to sacrifice in networking/devices/" or maybe "because its proper Kung-Foo" ?
just sayin.

Posted: **Tue May 05, 2015 12:32 am**

6.29rc14
With enabled FastTrack increased connections with last-ack state, is that normal?

/ip firewall filter
add action=fasttrack-connection chain=forward comment=\
    "fasttrack established+related" connection-state=established,related
    
add chain=forward comment="enable established+related" connection-state=\
    established,related
    
add action=drop chain=forward comment="drop invalid" connection-state=\
    invalid

last-ack.png

Same here.

Posted: **Tue May 05, 2015 1:37 am**

Hm - after some testing:

Looks like UDP packages have some problems - example SNMP. Only the first line of snmpwalk will be shown. TCP doesn't work correct too (connection timeouts). RouterOS 6.29, RB951G-2HnD

Posted: **Tue May 05, 2015 12:40 pm**

Hm - after some testing:

Looks like UDP packages have some problems - example SNMP. Only the first line of snmpwalk will be shown. TCP doesn't work correct too (connection timeouts). RouterOS 6.29, RB951G-2HnD

I tested SNMP walk - all ok, also what is wrong With TCP? How did you test that?

Posted: **Tue May 05, 2015 2:24 pm**

Icinga Monitoring

And after that I tested SNMPWALK and Netcat to TCP ports and connection was not possible.

I used this rules (are now disabled):

0 X ;;; Allow Established / Related
chain=forward action=fasttrack-connection
connection-state=established,related log=no log-prefix=""

1 chain=forward action=accept connection-state=established,related log=no
log-prefix=""

in forwarding chain.

Posted: **Wed May 06, 2015 5:04 am**

Does fasttrack work with vlans ?

Do the fastpath bridge improvements mentioned in the MUM presentation extend to vlans and bonding ? e.g. can traffic on vlan or bonding interfaces go via fastpath ?

Posted: **Wed May 06, 2015 8:57 am**

FastTrack is an extension of FastPath - both have same set of requirements.

So ATM both doesn't have support for VLAN interfaces, but it is on top of our FastPath To-Do list.

Posted: **Wed May 06, 2015 12:07 pm**

FastTrack is an extension of FastPath - both have same set of requirements.

So ATM both doesn't have support for VLAN interfaces, but it is on top of our FastPath To-Do list.

Thank you for the answer Strods

What about bonding ?

Posted: **Thu May 07, 2015 1:28 pm**

What about bonding ?

I think this answers also about bonding:

FastTrack is an extension of FastPath - both have same set of requirements.

and also hints that it is not on "top of their FastPath To-Do list"

after week of testing on my RB2011 at home i notice:
1) connection tracking table is polutied with ~40k connections in "last ack" state (usually have <500 entries in conntrack)
2) free memory is down from 105MiB to 80MIB (most likely this is result the result of 1) )
3) Average CPU load is down 2-3times.

In regular home usage i was not able to find any issues downloading,browsing,gaming,streaming, or Voiping.

as network administrator i would like to see some read-only "dummy rule" with comment "fasttrack traffic" in firewall and queues.
it is very easy to forget that big chunk of the traffic is taking shortcut and is not visible somewhere.

Posted: **Fri May 08, 2015 5:21 pm**

6.29rc14 with fasttrack enable is unusable.
I was testing it on few boards (Omnitik, RB750, RB750GL, RB532A).
After few hours: "router was rebooted without proper shutdown by watchdog timer".

Posted: **Fri May 08, 2015 11:11 pm**

FasTtrack bug - "last ack" status is for 24h instead of several seconds.

Posted: **Sun May 10, 2015 10:39 pm**

counters for fast path are a good improvement, thank you

Posted: **Mon May 11, 2015 10:38 pm**

What happened with 6.29rc? rc14 is 12days old.

Usualy RC are updated hourly as you say on download site: RouterOS v6.x release candidate - These versions are updated hourly

Posted: **Tue May 12, 2015 9:17 am**

Unfortunately drivers of RB1xx, RB5xx, RB850 devices does not support FastPath feature so also FastTrack is not possible on these RouterBOARD models.

Starting from version 6.29rc18 fix for last-ack state connections polluting Connection Tracking table is available for testing. You can download it here:
http://www.mikrotik.com/download

Posted: **Tue May 12, 2015 5:35 pm**

rc18 is a improvement with the connections get cleared out

Working well

Posted: **Tue May 12, 2015 8:57 pm**

On RC14 I had the problem, that ARP on VLANs was broken (client got an IP with DHCP, but was not even arp-pingable). After downgrade, problem was solved. Anyone else?

Posted: **Tue May 12, 2015 9:30 pm**

Unfortunately drivers of RB1xx, RB5xx, RB850 devices does not support FastPath feature so also FastTrack is not possible on these RouterBOARD models.

Starting from version 6.29rc18 fix for last-ack state connections polluting Connection Tracking table is available for testing. You can download it here:
http://www.mikrotik.com/download

http://wiki.mikrotik.com/wiki/Manual:Fast_Path shows RB1100 supporting FastPath on 1-10,11

Which one is true?

Posted: **Tue May 12, 2015 10:26 pm**

Unfortunately drivers of RB1xx, RB5xx, RB850 devices does not support FastPath feature so also FastTrack is not possible on these RouterBOARD models.

Starting from version 6.29rc18 fix for last-ack state connections polluting Connection Tracking table is available for testing. You can download it here:
http://www.mikrotik.com/download
http://wiki.mikrotik.com/wiki/Manual:Fast_Path shows RB1100 supporting FastPath on 1-10,11

Which one is true?

Strods wrote: rb1xx - it mean rb133, rb150, rb153 etc...
You mean rb1100 - it is rb1xxx. And it is supported

Posted: **Wed May 13, 2015 12:20 am**

Unfortunately drivers of RB1xx, RB5xx, RB850 devices does not support FastPath feature so also FastTrack is not possible on these RouterBOARD models.

Starting from version 6.29rc18 fix for last-ack state connections polluting Connection Tracking table is available for testing. You can download it here:
http://www.mikrotik.com/download
http://wiki.mikrotik.com/wiki/Manual:Fast_Path shows RB1100 supporting FastPath on 1-10,11

Which one is true?
Strods wrote: rb1xx - it mean rb133, rb150, rb153 etc...
You mean rb1100 - it is rb1xxx. And it is supported

Uh, my bad. Didn't know about RB1XX boards (didn't find them on routerboard.com).
Do you know if it is supported on RB1100 as of today (ppc wasn't supported in rc14)?

Thanks.

Posted: **Wed May 13, 2015 8:39 am**

Sorry if my post was not fully clear. Yes RB1xx does not support FastTrack. RB1xxx does support FastTrack. Rb1xx are pretty old devices and support for FastPath is not added to them.

Posted: **Wed May 13, 2015 8:53 am**

Why not support FastTrack in RB850?

Posted: **Wed May 13, 2015 12:25 pm**

rb2011, 6.29rc18
i got a lot of rules, just added fasttrack at the end, got no "last ack" problem, something forwarding
am i doing wright?

upd1: after 1 hour counter in IP-firewall is ticking, but on ip-settings fasttrack and fastpaph show disabled

can someone help me with RC, i got 2 questions, where can i find main topic about 6.29RC?

Posted: **Wed May 13, 2015 1:45 pm**

dmi3 - If your counters under IP/Settings are rising, then yes - FastTrack is working. Please write about your 6.29rc problems in this topic - http://forum.mikrotik.com/viewtopic.php?f=21&t=96048
Ulypka - Drivers of ethernet interfaces for this device does not support FastPath so also FastTrack is not supported.

Important note: Previously mentioned model devices does not support FastTrack on their ethernet interfaces. If, for example, you would use RB433 with wireless-fp package, then you can configure FastTrack on wireless because FastPath on wireless is possible there.

Posted: **Wed May 13, 2015 1:50 pm**

So, it is not a hardware limitation then? For which devices is it really impossible?

Posted: **Wed May 13, 2015 2:10 pm**

dmi3 - If your counters under IP/Settings are rising, then yes - FastTrack is working. Please write about your 6.29rc problems in this topic - http://forum.mikrotik.com/viewtopic.php?f=21&t=96048

thx!
as i updated earlier: my fasttrack working about 2 hours but then counter in IP-firewall is ticking, on ip-settings fasttrack and fastpaph show disabled

is it bug?

only change i made - reconnect CAP to itself capsman server, but i dont think its the reason

UPD1: after 2 more hours my fastttrack Active chechbox on ip-settings is back! omg
maybe winbox issue?

Posted: **Thu May 14, 2015 10:11 pm**

I just checked - 6.29rc20 is out......

What's new in 6.29rc20 (2015-May-14 16:00):

*) fasttrack - correctly close fasttrack connections;
*) firewall - fixed sector writes rising starting since 6.28;
*) tile - fixed fasttrack;
*) snmp - fix rare bug when some OIDs where skipped;
*) ssh - added aes-ctr cipher support;
*) mesh - fixed kernel crash;
*) ipv4 fasttrack fastpath - accelerates connection tracking and nat for marked
connections (more than 5x performance improvement compared to regular slow
path conntrack/nat) - currently limited to TCP/UDP only;
*) added ~fasttrack-connection~ firewall action in filter/mangle tables for marking
connections as fasttrack;
*) added fastpath support for bridge interfaces - packets received and transmitted
on bridge interface can go fastpath (previously only bridge forwarded packets
could go fastpath);
*) packets now can go half-fastpath - if input interface supports fastpath and
packet gets forwarded in fastpath but output interface does not support fastpath
or has interface queue other than only-hw-queue packet gets converted
to slow path only at the dst interface transmit time;
*) trafflow: add natted addrs/ports to ipv4 flow info;
*) queue tree: some queues would stop working after some configuration changes;
*) tilegx: enable autoneg for sfp ports in netinstall;
*) health - fix voltage on some RB4xx;
*) romon - fix 100% CPU usage;
*) romon - moved under tools menu in console;
*) email - store hostname for consistency;
*) vrrp - do not reset interface when no interesting config changes;
*) async - fixed ppp server;
*) sstp - fixed router lockup;
*) queue tree: some queues would stop working after some configuration changes.
*) console - allow '-' characters in unknown command argument names;
*) snmp - fix rare bug when some OIDs where skipped;
*) fixed CRS226 10G ports could lose link (introduced in 6.28);
*) fixed FREAK vulnerability in SSL & TLS;

Posted: **Fri May 15, 2015 2:14 pm**

snmp was fixed twice or once fixed and secondly broken again?

Posted: **Fri May 15, 2015 9:23 pm**

*) ssh - added aes-ctr cipher support;

Yes! Finally, I would be able to create ROS VMs with Packer.

Posted: **Mon May 18, 2015 8:35 pm**

Noticed new action icons on the "Firewall - Filter Rules"... and they are damn pretty! Does all icons will be new, just like them?

Posted: **Tue May 19, 2015 5:04 am**

Noticed new action icons on the "Firewall - Filter Rules"... and they are damn pretty! Does all icons will be new, just like them?

I guess the Winbox main icons has been changed as well.

Posted: **Tue May 19, 2015 8:14 am**

I guess the Winbox main icons has been changed as well.

No, the Winbox haven't changed since 3.0rc9. But just after installing RC of 6.29 I saw them.

And there are still old icons when connection to some older firmwares.

Posted: **Wed May 20, 2015 2:31 am**

I guess the Winbox main icons has been changed as well.
No, the Winbox haven't changed since 3.0rc9. But just after installing RC of 6.29 I saw them.

And there are still old icons when connection to some older firmwares.

You know, Winbox download DLL files from your device. So, if you use the new RC version, the new pack of icons will be used.

Posted: **Thu May 21, 2015 8:07 am**

Why not to mark packet at mangle postrouting? Like this:

/ip firewall mangle
add action=fasttrack-connection chain=postrouting

All traffic already have filtered and we also mark new connection.

Posted: **Thu May 21, 2015 11:31 am**

Why not to mark packet at mangle postrouting?

It does only make sense to use FastTrack on specific (known) connections before they enter filter/other routing chains. Using it afterwards makes no sense at all...

Posted: **Thu May 21, 2015 11:59 am**

Why not to mark packet at mangle postrouting?
It does only make sense to use FastTrack on specific (known) connections before they enter filter/other routing chains. Using it afterwards makes no sense at all...

We mark whole connection. It is better mark first packet (when connection state is new), but after all filters. Maybe it is better to do in mangle postrouting chain.

Posted: **Fri May 22, 2015 11:22 pm**

My ISP offers different services on the WAN side with the help of VLANS. e.g:

- VLAN34 is internet
- VLAN 4 is digital television
- VLAN 7 is SIP / Telephony.

Can i do something clever to be able to use fasttrack for the internet traffic? On my 200/200mbps connection i can see that the Mikrotik really has a hard time handling the traffic.

Posted: **Sat May 23, 2015 10:23 am**

Have another device strip the tagging?

Posted: **Sat May 23, 2015 10:30 am**

Mikrotik have mentioned that FastTrack will get vlan support.

We just have to be patient

Posted: **Sat May 23, 2015 11:01 am**

Wow good news, thanks

Posted: **Sat May 23, 2015 11:07 am**

My ISP offers different services on the WAN side with the help of VLANS. e.g:

- VLAN34 is internet
- VLAN 4 is digital television
- VLAN 7 is SIP / Telephony.

Can i do something clever to be able to use fasttrack for the internet traffic? On my 200/200mbps connection i can see that the Mikrotik really has a hard time handling the traffic.

maybe the other vlans can be manged at wire speed with rb switch if apply, only nat needed for internet traffic

Posted: **Mon May 25, 2015 11:43 am**

Why not to mark packet at mangle postrouting?
It does only make sense to use FastTrack on specific (known) connections before they enter filter/other routing chains. Using it afterwards makes no sense at all...
We mark whole connection. It is better mark first packet (when connection state is new), but after all filters. Maybe it is better to do in mangle postrouting chain.

It is much easier to think about fasttrack as flag in the Conntrack table.

so far i have implemented 3 scenarios:

1) in " drop everything else" style firewall, best is to fasttrack connection-state=established,related cause connection-state=new packets have to go through all the firewall filter rules, and we can fasttrack connection only starting from first established packet.

2)in "accept everything else" style firewall, you can just place fasttrack rule in the end of firewall chain.

3) if you use queues, in mangle mark connections with connection-mark and then in the end fasttrack all connections that doesn't have connection-mark.

In any of these cases i use chain=forward, as fasttrack doesn't work on input and output traffic.

Posted: **Mon May 25, 2015 12:13 pm**

working fasttrack 6.29 x86 ?

Posted: **Mon May 25, 2015 2:17 pm**

working fasttrack 6.29 x86 ?

That would require RouterOS x86 to use DPDK.

No small task!

Posted: **Wed May 27, 2015 2:07 pm**

1. b450g supported?
2. what about ip/ proxy with fasttrack?

Posted: **Wed May 27, 2015 5:18 pm**

best is to fasttrack connection-state=established,related

Is this fasttrack rule replacing the default "accept connection-state=established,related"-rule or do I still need it?

Posted: **Wed May 27, 2015 5:53 pm**

My guess is you still need it, because not all connections can be fast-tracked. So you probably have to put the fast-track rule first, and a "normal" established/related accept rule afterwards to catch non-fasttrackable connections (like gre, ipsec-esp, icmp, etc...)

Posted: **Wed May 27, 2015 8:53 pm**

My guess is you still need it, because not all connections can be fast-tracked. So you probably have to put the fast-track rule first, and a "normal" established/related accept rule afterwards to catch non-fasttrackable connections (like gre, ipsec-esp, icmp, etc...)

This is good idea IMHO. Looking forward to test fasttrack soon.

Posted: **Thu May 28, 2015 11:11 am**

My guess is you still need it, because not all connections can be fast-tracked. So you probably have to put the fast-track rule first, and a "normal" established/related accept rule afterwards to catch non-fasttrackable connections (like gre, ipsec-esp, icmp, etc...)

This is also for connections that uses fasttrack, as far as i can see some of the packets are going the slow path to maintain all the timeouts and states in order.

As it was told in MUM presentation "fasttrack-connection" works similar to "connection-mark" so even when triggered, packet passes through to the next rule. Only following packets from this connection will go FastPath, one that triggered "fasttrack-connection" rule have to pass through in regular slow-path way.

Posted: **Thu May 28, 2015 1:21 pm**

Is there some way to benefit from fasttrack if I am setting priority from dscp ?

/ip firewall mangle add action=set-priority chain=prerouting new-priority=from-dscp-high-3-bits

Posted: **Thu May 28, 2015 1:32 pm**

Just tested on the CCR-1016 and it's working as expected, added "action=fastrack" to a few most used NAT rules to test it out and seeing less CPU usage but hard to tell the speed difference yet.

Posted: **Thu May 28, 2015 9:34 pm**

RB2011:

Before: 220-240Mbps at 100%
After: I saturate my 250Mbps pipe at 50%

Both with downstream traffic only.

I guess I am all set for when 500Mbps is offered (unless the jump would be straight to 1Gbps)

Posted: **Fri May 29, 2015 2:34 pm**

How to read this picture?

fasttrack.jpg

(all rules are without any conditions)

Posted: **Fri May 29, 2015 3:37 pm**

Hi all,

please verify the hardware support, not all the RouterBoards are supported ( for example RB450/RB450G are not supported )

List of devices with FastPath support
RouterBoard Interfaces
RB6xx series ether1,2
RB7xx series all ethernets
RB8xx series ether1,2
RB9xx series all ethernets
RB1000 all ethernets
RB1100 series ether1-10,11
RB2011 series all ethernets and sfp
CCR series routers all ethernets and sfps
All RouterBOARD devices wireless interfaces, if wireless-fp package used
x86 wireless interfaces, if wireless-fp package used

source : http://wiki.mikrotik.com/wiki/Manual:Fast_Path

Best Regards,

Daniell

Posted: **Fri May 29, 2015 5:30 pm**

Sure. It is rb750 and the fasttrack is indicated to be on.

Posted: **Fri May 29, 2015 7:09 pm**

What about the CRS series?

Posted: **Fri May 29, 2015 7:14 pm**

Sure. It is rb750 and the fasttrack is indicated to be on.

I have the same problem. According to the firewall filter table, lots of packets and bytes. However, "ip setting" shows 0 packets and 0 bytes for fastTrack (yes, it shows fasttrack active). So is fasttrack working or not?

Posted: **Fri May 29, 2015 11:48 pm**

Hi all,

i have verified tonight for Mikrotik CRS109-8G-1S-2HND-IN and Mikrotik CRS 125-24G-1S-2Hnd-in and the feature it's working.

Best Regards,

Daniel

Posted: **Sat May 30, 2015 10:16 pm**

Ok. I tried fasttrack in real situation and after few minutes I swithed it off.

First of all, the fasttracking firewall rules are showing nonesence counter values. And finally I have found that bypassed user queues are so much important for me that I cannot sacrifice them.

So, it works, speeds the throughput and spares CPU, but the side costs are too high.

Posted: **Mon Jun 01, 2015 11:22 am**

Ok. I tried fasttrack in real situation and after few minutes I swithed it off.

First of all, the fasttracking firewall rules are showing nonesence counter values. And finally I have found that bypassed user queues are so much important for me that I cannot sacrifice them.

So, it works, speeds the throughput and spares CPU, but the side costs are too high.

you don't need to fasttrack all, you need to mark specific traffic that you don't need to queue. also why nonsense counters ?

Posted: **Mon Jun 01, 2015 12:20 pm**

Hello

Just a stupid question, i understand the benefits of using Fasttrack. Where can we found a simple explanation on how to implement it with some examples?

Thanks for your help

Posted: **Mon Jun 01, 2015 12:41 pm**

First page of this thread has the basic Firewall rules that you need: http://forum.mikrotik.com/viewtopic.php ... 76#p479776

Posted: **Mon Jun 01, 2015 5:18 pm**

Well. I queue all traffic according to the user ip addresses. Then there is almost no possibility to use fasttrack. The statistics is nonsense because it uses only hits that were not able to be processed by the fasttracking rule even fulfilled its criteria. The same values show subsequent accepting rule also.

Posted: **Tue Jun 02, 2015 11:51 am**

Like others said before, this is not for devices where you queue all traffic. At home - I don't queue myself (why?). I simply want a LAN through NAT, and this gives me ability to have nearly 2x the speed I had before. For ISP this will not be a big benefit, unless they have unlimited VIP type of clients.

Let me give an example. Take the RB951G out of the box, don't alter the default config. Speedtest gives some 250Mbit. I add one Fasttrack rule - speedtest now gives 500Mbit (ISP doesn't give more). Simple.

Posted: **Tue Jun 02, 2015 12:18 pm**

Seems like it's not working on PPTP and GRE interfaces of my RB2011. Do you plan to support fasttrack on GRE/PPTP/etc ?
It's a common practice when PPTP connection to ISP is used.

Posted: **Tue Jun 02, 2015 12:31 pm**

It seems like FastTrack somehow disturbs my ssh/cifs server connections through IPSec-tunnel..

Ping still works as expected and I can even connect to suitable ports with telnet, but connecting with Putty (ssh) or Windows Explorer (CIFS) just hangs until timeout.. Anyhow, From IP/Firewall/Connection I can see established TCP-connection between client and server in both cases.. SSH to RB works fine, its just connections to servers behind my RB.

After disabling these 3 firewall rules everything works fine again:
0 X chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=""
1 X chain=forward action=accept connection-state=established,related log=no log-prefix=""
2 X chain=forward action=drop connection-state=invalid log=no log-prefix=""

..but if I enable these again, problem comes back immediately (it also kills active ssh connections)..

Is anyone else noticed anything like this?

Not the biggest problem for me, because my RB2011UiAS-2HnD can handle my Internet connection pretty well also without FastTrack, but just a notice..

Posted: **Tue Jun 02, 2015 1:10 pm**

It seems like FastTrack somehow disturbs my ssh/cifs server connections through IPSec-tunnel..

Well FastTrack basically skips lots of processing steps, like firewall and queues, maybe it skips something IPSEc related also.
You just need to create more specific rule that excludes all IPsec traffic from FastTrack.

This is the reason it is implemented as firewall action, not an option that is enabled by default. One rule solution is not for your setup.

And Fastpath doesn't go together with IPSec

Posted: **Tue Jun 02, 2015 11:03 pm**

As long as I have a plenty of cpu power, the fasttrack is not bringing any advantage to me. Only in case the standard processing will be slower than my needs I would maybe start thinking to fasttrack part of the traffic. Now I am fasttracking only the traffic within internal address ranges that doesn't help too much anyway.

Posted: **Thu Jun 04, 2015 1:24 am**

The idea is to "fasttrack" some specific machine without slowing it's traffic for processing. Let's say you have a network of users, you have firewall and queues for them. But then you have a VIP customer (or your own PC) that you will not filter or slow down, and you want the best available speed for it. This is the situation for fasttrack.

FastTract allows a smoother streaming of a video on my home NAS, across the Net, over open VPN connection. I was not able to do this, prior to FastTract, without heavy breakups.

It's not that I normally watch a video over the vpn connection to home. But as a test of performance, it does 'fast tract'.

(My nominal home bandwidth is: 100mbps down, 2.4mbps up).

One thing though. The firewall rules preceding FastTract, are needed to drop invalid input, and new forward which is not dsn-natted for obvious reason.

On this point, do these rules still work when Bittorents are running?

It's a good feature from MikroTik. From where I sit.

Posted: **Thu Jun 04, 2015 8:54 am**

The idea is to "fasttrack" some specific machine without slowing it's traffic for processing. Let's say you have a network of users, you have firewall and queues for them. But then you have a VIP customer (or your own PC) that you will not filter or slow down, and you want the best available speed for it. This is the situation for fasttrack.
FastTract allows a smoother streaming of a video on my home NAS, across the Net, over open VPN connection. I was not able to do this, prior to FastTract, without heavy breakups.

It's not that I normally watch a video over the vpn connection to home. But as a test of performance, it does 'fast tract'.

(My nominal home bandwidth is: 100mbps down, 2.4mbps up).

One thing though. The firewall rules preceding FastTract, are needed to drop invalid input, and new forward which is not dsn-natted for obvious reason.

On this point, do these rules still work when Bittorents are running?

It's a good feature from MikroTik. From where I sit.

on which miktotik model have you tested?

Posted: **Thu Jun 04, 2015 9:01 am**

on which miktotik model have you tested?

RB493G

Posted: **Thu Jun 04, 2015 9:26 am**

rb4xx are not supported:

http://wiki.mikrotik.com/wiki/Manual:Fast_Path

Posted: **Thu Jun 04, 2015 9:53 am**

That's interesting. Hmm.

Video streaming over openvpn connection from my home NAS was definitely much smoother. From G3 connection on mobile phone.

The only change which I am aware of was my redoing of netinstall on RB493G. But this was due to my first misdiagnosis of its faulty power supply.

Two attempts at netinstall pointed to the faulty PSU which failed to reboot my RB493 after the R6.29 upgrade.

Apart from that I cannot explain the smoother streaming.

Cheers.

.

Posted: **Thu Jun 04, 2015 11:28 am**

FastPath and FastTrack are a bit different things, AFAICS

I wonder, is it possible to use FastTrack on the router with ConnectionTracking disabled

so it just skips processing of Filter, Mangle, etc.

Posted: **Thu Jun 04, 2015 12:15 pm**

FastPath and FastTrack are a bit different things, AFAICS

I wonder, is it possible to use FastTrack on the router with ConnectionTracking disabled so it just skips processing of Filter, Mangle, etc.

Fasttrack have 3 requirements to work:
1) FastPath support for all involved drivers
2) Connection tracking enabled
3) action=fasttrack-connection rule

Posted: **Thu Jun 04, 2015 12:21 pm**

While playing with new 6.30rc10 i notice this:

*) improved connection list: added connection packet/byte counters, added separate counters for fasttrack, added current rate display, added flag wheather connection is fasttracked/srcnated/dstnated, removed 2048 connection entry limit;

It looks like there are now much more comprehensive way to observe fasttrack in action:

conntrack_new_look.png

3 things i would like to indicate:
1) flags for entries (especially i love "dying" one

)
2) from counters of selected connections i can see tat only 6 packets in original direction and 2 packets in Reply direction went to slowpath, rest was fasttracked.
3) it is now much more easy to operate with connection-bytes and see what connections you need to handle

Posted: **Thu Jun 04, 2015 4:25 pm**

While playing with new 6.30rc10 i notice this:

*) improved connection list: added connection packet/byte counters, added separate counters for fasttrack, added current rate display, added flag wheather connection is fasttracked/srcnated/dstnated, removed 2048 connection entry limit;

mmm this is a great feature. Nice work Mikrotik.

What do orig/repl mean ? I am assuming send/receive... ?

Posted: **Mon Jun 08, 2015 1:20 pm**

Excellent work guys. I just tested on RB951G and I got significant CPU performance!!!
Thank you!

Posted: **Mon Jun 08, 2015 2:41 pm**

what is faster: router with conntrack disabled, or fasttrack-enabled?

Posted: **Mon Jun 08, 2015 3:09 pm**

FastPath (routing with disabled connection tracking) is faster than FastPath with enabled connection tracking handler (which is FastTrack).

You can see description and examples of FastTrack in our latest newsletter (FastPath + Conntrack= FastTrack):
http://download2.mikrotik.com/news/news_65.pdf

Posted: **Mon Jun 08, 2015 4:52 pm**

On RB951G-2HnD not work for me. version 6.29.1

/ip settings print
ip-forward: yes
send-redirects: yes
accept-source-route: no
accept-redirects: no
secure-redirects: yes
rp-filter: no
tcp-syncookies: no
max-arp-entries: 8192
arp-timeout: 30s
icmp-rate-limit: 10
icmp-rate-mask: 0x1818
allow-fast-path: yes
ipv4-fast-path-active: no
ipv4-fast-path-packets: 0
ipv4-fast-path-bytes: 0
ipv4-fasttrack-active: yes
ipv4-fasttrack-packets: 0
ipv4-fasttrack-bytes: 0

On fasttrack filter rule number of packets and bytes increase.

Posted: **Mon Jun 08, 2015 4:56 pm**

make sure you are not using the MAC address to configure your device (Winbox MAC).
Also post your rule please

Posted: **Mon Jun 08, 2015 5:56 pm**

I use IP to configure device.

[admin@MikroTik] > /ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=forward action=fasttrack-connection
connection-state=established,related log=no log-prefix=""

1 chain=forward action=accept connection-state=established,related log=no
log-prefix=""

2 chain=forward action=drop connection-state=invalid log=no log-prefix=""

Posted: **Mon Jun 08, 2015 6:17 pm**

As I understand, is on vrrp intrefaces fasttrack don't works too?

Posted: **Wed Jun 10, 2015 11:19 am**

As I understand, is on vrrp interfaces fasttrack don't works too?

Nop it is not supported at the moment, last i know it was in "top of fast-path to-do list" together with VLAN support.

Posted: **Wed Jun 10, 2015 11:27 am**

Update from 6.30RC15... New dynamic dummy rule for fasttrack packets just appeared in Firewall forward, mangle prerouting,forward,postrouting.

234.png

WIth this workaround i think it is almost possible to avoid all confusion about missing fastracked packets, if someone unaware of fasttrack starts to configure router.

This rule will appear as soon as fasttrack-connection rule is enabled, and will remain there until the next reboot, even if you delete/disable fasttrack-connection rule. Support states that it is done by design - as connections that are marked for fasttrack might remain active even after fasttrack-connection rule is disabled.

now only thing missing is similar solution for simple queues - dynamic dummy simple queue for fasttracked traffic.

Posted: **Wed Jun 10, 2015 11:34 am**

now only thing missing is similar solution for simple queues - dynamic dummy simple queue for fasttracked traffic.

and also similar counter in TrafficFlow: how much traffic you have not billed

Posted: **Wed Jun 10, 2015 11:51 am**

and also similar counter in TrafficFlow: how much traffic you have not billed

well... from where i sit fasttrack and trafficflow doesn't have place on the same router, one is mostly for CPE usage, other is mostly for ISP.
I i personally do not think it is MUST HAVE feature

Posted: **Wed Jun 10, 2015 11:39 pm**

It would be possible to write a fast path Traffic Flow plug in.

Hopefully we will see one. We use Netflow for billing and diagnostics.

Posted: **Thu Jun 11, 2015 11:42 am**

Some nice improvements in v6.30rc17 (already in RC section):

*) fasttrack - added dummy firewall rule in filter and mangle tables to show packets/bytes that get processed in fasttrack and bypass firewall;
*) fastpath - vlan interfaces support fastpath;

Posted: **Thu Jun 11, 2015 12:01 pm**

Some nice improvements in v6.30rc17 (already in RC section):

*) fasttrack - added dummy firewall rule in filter and mangle tables to show packets/bytes that get processed in fasttrack and bypass firewall;
*) fastpath - vlan interfaces support fastpath;

Thanks for all the work on vlan fastpath MikroTik!

Posted: **Thu Jun 11, 2015 12:10 pm**

*) fasttrack - added dummy firewall rule in filter and mangle tables to show packets/bytes that get processed in fasttrack and bypass firewall;

I do confirm this dummy rules are useful. But yet very frustrating, as when I see some new lines in the same tables it brings some questions kind of "who did it without me?!"

May I please ask you for some questions to better understand this feature?

1. Am I right that FastTrack is some technique that router uses to process packets that belongs to specific connection according to connection tracking mechanism that already exists before?

2. When I use

add chain=forward action=fasttrack-connection connection-state=established,related

I'm in fact somehow "mark" the connection as one that should be processed in that "magic" way?

3. I can do these marking in ip/firewall or in ip/mangle, whatever I like?

4. I should not fasttrack new connections?

5. What if I do fasttrack for all connections (forward, input, output), new, established, related - it won't break the proccessing, right?

6. What if I do the action (fasttrack-connection) in prerouting chain, so all connections be marked before any other processing occurs?

Thank you in advance for answering and explaining!

Posted: **Thu Jun 11, 2015 12:46 pm**

1) Yes, first packets of the connections must go the regular way, so that your firewall and nat configuration can be applied to connection, and only then rest of the packets from that connection can be fasttracked

2) Yes. But this rule is for all connections, you can always make it more narrow, for example fasttrack only connections from local network to DMZ and have deep packet inspection, netflow, queues for all public connections

3) yes

4) i think you can, but it will give you no benefit, as first packets will have to go regular way to create conntrack entry anyway.

5) fasttrack works only for forward traffic, and same answer as 4)

6) do not forget that packet that triggers the fasttrack-connection rule will continue the normal way, only next packet will go fastpath way, so you should be fine.

Posted: **Thu Jun 11, 2015 1:00 pm**

I really like the latest beta/rc release! Better speeds than before. Don't know if it is because of the AC improvements or the FastPath/VLAN support..

Posted: **Fri Jun 12, 2015 2:33 pm**

How do i use Fasttrack feature

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

If i give this simple queues not working....

Posted: **Fri Jun 12, 2015 2:36 pm**

What's new in 6.30rc19 (2015-Jun-12 11:45):

*) fastpath - vlan interfaces support fastpath;
*) fastpath - partial support for bonding interfaces (rx only);
*) fastpath - vrrp interfaces support fastpath;

Number of possible setups with Fasttrack just got bigger. And, yes, also works with Q-in-Q, just tested it

Posted: **Fri Jun 12, 2015 2:40 pm**

How do i use Fasttrack feature

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

If i give this simple queues not working....

Yes, that is how fasttrack works - you create a firewall rule that allow connections to skip some processing (including simple queues).
If you use simple queues for all your traffic, sorry, you can't use fasttrack.
But if you use simple queues only for specific traffic, you can always create a more specific fasttrack-connection rule.

Posted: **Fri Jun 12, 2015 2:42 pm**

aguntukk, queues are for slowing down traffic. fasttrack is for speeding it up. you can't have both at the same time

at least make a more specific fasttrack rule, if you want only specific traffic to be fast, and other to be queued

Posted: **Fri Jun 12, 2015 3:25 pm**

You can not use fasttrack with queues.

Fasttrack = skip processing of packets
Queues = processing

Posted: **Mon Jun 15, 2015 7:27 pm**

Thanks for Your help about Fasttrack

Posted: **Mon Jun 15, 2015 7:29 pm**

How do i give null route in mikrotik??
Any idea?

Posted: **Mon Jun 15, 2015 8:06 pm**

Wrong thread.

/ip route add dst-address=192.0.2.2 type=blackhole

Posted: **Tue Jun 16, 2015 3:26 pm**

The feature is great, however its user interface is confusing. I think the fast-track rule shouldn't just mark connections, but should automatically work as "Accept", so that the packets don't fall through to the next rule which is in 100% Accept. That's really weird.

I'd expect that only those packets which cannot be fast tracked should fall through to following rules (and ultimately be accepted).

And the dummy rule in 6.30RC only adds to the overall confusion...

2015-06-16_14-21-03.png

Posted: **Tue Jun 16, 2015 4:49 pm**

The feature is great, however its user interface is confusing. I think the fast-track rule shouldn't just mark connections, but should automatically work as "Accept", so that the packets don't fall through to the next rule which is in 100% Accept. That's really weird.

I'd expect that only those packets which cannot be fast tracked should fall through to following rules (and ultimately be accepted).

And the dummy rule in 6.30RC only adds to the overall confusion...

Same thing here.

2015-06-16_14-21-03.png

 0    ;;; ICMP Permit
      chain=input action=accept protocol=icmp log=no log-prefix="" 

 1    ;;; Accept related input connections
      chain=input action=accept connection-state=established,related log=no log-prefix="" 

 2    ;;; Forward FastTrack
      chain=forward action=fasttrack-connection connection-state=established,related log=no 
      log-prefix="" 

 3    ;;; Accept related forward connections
      chain=forward action=accept connection-state=established,related log=no log-prefix=""

Posted: **Tue Jun 16, 2015 7:42 pm**

I agree. It is confusing. Fasttrack rules should have exactly the same behaviour, feel and look like all other rules.

Posted: **Tue Jun 16, 2015 8:54 pm**

seems like people are requesting an ability to do 'action=fasstrack passthrough=no'. MT?

Posted: **Wed Jun 17, 2015 9:55 am**

seems like people are requesting an ability to do 'action=fasstrack passthrough=no'. MT?

Can't you simply add a drop rule after it?

Posted: **Wed Jun 17, 2015 10:20 am**

I only drop invalid connections in forward chain. I only have fasttrack rule without accept rule after it, because the packets are accepted anyway and it works.

Posted: **Wed Jun 17, 2015 12:55 pm**

It seems like FastPath/FastTrack cannot be switched off in configuration Bridge+Firewall+Queues (no routing)

"Use IP Firewall" box is checked ON, "Allow Fast Path" is OFF in Bridge Settings, and either Firewall Filter fasttrack forward rule is DISABLED too.
But -- Bridge Fast Path Packets & Bytes counters are actively increasing, Simple Queues counters are almost empty and not functioning AFAICS, so the Firewall counters and either Torch -- looks like only start packets of every session goes to Firewall.

RB750UP, ROS 6.30rc19 now.
(6.29 and other RC's crashed often and eating CPU by management process -- http://forum.mikrotik.com/viewtopic.php ... 36#p485836 )
[Ticket#2015060366000431] [Ticket#2015053066000266] [Ticket#2015052966000214]

Who else can test firewalling/queuing BRIDGE?

Posted: **Sat Jun 20, 2015 2:27 pm**

How can I switch off the default dummy fasttrack rule in the filter? What sense in it anyway, we have the same counters in IP-Settings...

Posted: **Tue Jun 23, 2015 9:50 am**

I see here one example where FastTrack would be very usefull: ! VoIP !!!.

VoIP is usually configured on separate VLAN that has to be prioritized.

Is it possible to use FastTrack for VoIP VLAN? or is that RFE?

Posted: **Wed Jun 24, 2015 1:32 am**

I was anticipating this feature and installed 6.29.1 only to find out that it's not supported on my router at home which is an RB450G. It has been one of the most popular ones and there isn't a night and day difference between this and the 750G which is indeed supported. Their hardware is almost identical. Why can't this be supported? Is it some hardware limitation or just company policy? I had exactly zero problems with the 450G since I've installed it 4-5 years ago. Sad.

Posted: **Wed Jun 24, 2015 9:35 pm**

I wonder if I ever get an answer...

Posted: **Wed Jun 24, 2015 11:54 pm**

Are you really complaining about not getting an answer in a forum within 8 hours?

Posted: **Thu Jun 25, 2015 12:42 am**

Are you really complaining about not getting an answer in a forum within 8 hours?

Check your clock, please. It was about a day later.

But no. It was merely a rhetorical question, if that helps to satisfy your curiosity (or your feeling of righteousness).

Posted: **Thu Jun 25, 2015 1:11 am**

It was on the same day.

Posted: **Thu Jun 25, 2015 10:24 am**

Does FastPath work with EOIP or GRE tunnels ? We have many router which they are just a simple bridge between an ethernet and an EOIP tunnel to pass pppoe to remote router .
In that situation fastpath would be very useful .

Posted: **Thu Jun 25, 2015 11:14 am**

It was on the same day.

depends on your local settings. I see 20hours difference (not being fooled by am/pm...)

Posted: **Thu Jun 25, 2015 9:04 pm**

Just made a test with queue. Mikrotik just ignores the queues at all if FastTrack is active.

Posted: **Thu Jun 25, 2015 9:35 pm**

exactly. no slow processing (queues, firewall) at all. by design

Posted: **Fri Jun 26, 2015 3:01 am**

I'm experiencing the exact same thing. Same routerboard here.

Any solutions?

It seems like FastTrack somehow disturbs my ssh/cifs server connections through IPSec-tunnel..

Ping still works as expected and I can even connect to suitable ports with telnet, but connecting with Putty (ssh) or Windows Explorer (CIFS) just hangs until timeout.. Anyhow, From IP/Firewall/Connection I can see established TCP-connection between client and server in both cases.. SSH to RB works fine, its just connections to servers behind my RB.

After disabling these 3 firewall rules everything works fine again:
0 X chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=""
1 X chain=forward action=accept connection-state=established,related log=no log-prefix=""
2 X chain=forward action=drop connection-state=invalid log=no log-prefix=""

..but if I enable these again, problem comes back immediately (it also kills active ssh connections)..

Is anyone else noticed anything like this?

Not the biggest problem for me, because my RB2011UiAS-2HnD can handle my Internet connection pretty well also without FastTrack, but just a notice..

Posted: **Fri Jun 26, 2015 10:00 am**

Just made a test with queue. Mikrotik just ignores the queues at all if FastTrack is active.

I don't use "Allow Fast Path" in "Bridge Settings", but I do "Use IP Firewall" there.

Beside of that, "Bridge Fast Path Packets & Bytes" counters are actively (not Mikro!) ticking now, ROS version 6.29.. 6.30rc19.. 6.30rc22.

I don't order and don't like it

My production Queuing Bridge just totally broken by this issue... all users fill all link bandwidth without any limits now. DNAT and Firewall don't functioning too.

I really don't want to change Queuing Bridge to Queuing Router due to lack of IP subnets, and I don't want to change my RB750UP based AP-sectors too because I like this simple & smart PoE installation.

Posted: **Fri Jun 26, 2015 10:41 am**

Fasttrack will not be active if you don't add the firewall rule for it. And Fastpath can be disabled from IP->Settings and for bridge in Bridge->Settings too. Check also Queue->Interface queues.

Posted: **Fri Jun 26, 2015 11:37 am**

Fasttrack will not be active if you don't add the firewall rule for it. And Fastpath can be disabled from IP->Settings and for bridge in Bridge->Settings too. Check also Queue->Interface queues.

Well, screenshot is below.

2015-06-26 13-22-51 Скриншот экрана.png

Interface Queues are all changed to wireless-default (i.e. sfq) because of WISP infrastructure after RB750UP.
Why did this config work successfully all other ROS versions before 6.29?

Posted: **Sat Jun 27, 2015 10:57 am**

FastPath (routing with disabled connection tracking) is faster than FastPath with enabled connection tracking handler (which is FastTrack).

You can see description and examples of FastTrack in our latest newsletter (FastPath + Conntrack= FastTrack):
http://download2.mikrotik.com/news/news_65.pdf

If FastPath is disabled , which one is faster
1- Completely disable connection tracking ?
or
2- Use FastTrack with enabled connection tracking ?

Thanks for clarification

Posted: **Mon Jun 29, 2015 1:27 pm**

Well, screenshot is below.

I think you need to write to support with description and supout.rif file from latest RC.

Posted: **Mon Jun 29, 2015 1:29 pm**

If FastPath is disabled , which one is faster
1- Completely disable connection tracking ?
or
2- Use FastTrack with enabled connection tracking ?

Thanks for clarification

Simple FastPath will be faster, cause fasttrack enables the same FastPath in case of conntrack. so it is all packets FastPath vs most packets FastPath.

Posted: **Mon Jun 29, 2015 2:17 pm**

If FastPath is disabled , which one is faster
1- Completely disable connection tracking ?
or
2- Use FastTrack with enabled connection tracking ?

Thanks for clarification

Simple FastPath will be faster, cause fasttrack enables the same FastPath in case of conntrack. so it is all packets FastPath vs most packets FastPath.

You mean "Simple FastPath = Completely disable connection tracking" ?
So in my question 1 would be faster , right ?

Posted: **Tue Jun 30, 2015 9:43 am**

You mean "Simple FastPath = Completely disable connection tracking" ?
So in my question 1 would be faster , right ?

Yes and Yes.

Posted: **Wed Jul 01, 2015 1:11 pm**

it's not supported on my router at home which is an RB450G

FastTrack is supported only half router models. So it's normal.

Posted: **Wed Jul 01, 2015 2:36 pm**

Curious if anyone with battery/solar powered routers with this function enabled have any power usage data to share

Posted: **Sat Jul 04, 2015 5:33 pm**

I have one router that has no rules in firewall filter. But limits one network using SQ, but also the traffic except that network goes through router. I am thinking to make rule that will fasttrack all connections except that one network that uses SQ. Is it good idea? Will it lower CPU usage or not?

something like this:
/ip firewall filter> print

Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=forward action=jump jump-target=fastrack 
      dst-address-list=!fasttrack log=no log-prefix="" 

 1    chain=forward action=jump jump-target=fastrack 
      src-address-list=!fasttrack log=no log-prefix="" 

 2    chain=fastrack action=fasttrack-connection log=no log-prefix=""

Posted: **Sat Jul 11, 2015 1:51 pm**

How can I switch off the default dummy fasttrack rule in the filter? What sense in it anyway, we have the same counters in IP-Settings...

Vote against dummy rules in firewall: http://forum.mikrotik.com/viewtopic.php?f=1&t=98471

Posted: **Tue Jul 14, 2015 10:55 am**

Do I understand correctly, that it does not work with l2tp interface?

Posted: **Tue Jul 14, 2015 11:14 am**

Do I understand correctly, that it does not work with l2tp interface?

No, currently it is not supported

Posted: **Wed Jul 15, 2015 1:59 am**

Do I understand correctly, that it does not work with l2tp interface?
No, currently it is not supported

Also doesn't work with PPPoE clients AFAIK. Is this going to be supported in the future? (And just to be bold, any ETA?

)

Posted: **Wed Jul 22, 2015 10:50 am**

So I currently use PCC mangle rules, and I use NAT on my WAN interfaces, however I do not use "masquerade" instead I use "src-nat" and specify a range of public IP's to use.

Will fasttrack work on this setup? I have no way to test and I'm reluctant to upgrade and test it on my live environment.

Hoping someone can let me know if it should work with this setup?

tx

Posted: **Sun Aug 16, 2015 9:47 am**

Why do I have the "special dummy rule" duplicated three times in Mangle?

Posted: **Mon Aug 17, 2015 11:15 pm**

Why do I have the "special dummy rule" duplicated three times in Mangle?

Look closely there's 3 distinct rules...

forward, prerouting and postrouting.

Just gives you a breakdown of total.

Posted: **Mon Sep 07, 2015 2:18 am**

From what I can see, the main constraint of Fasttrack is Qos of VoIP queue priorities. Simply because Fasttrack does not enlarge an existing bandwidth pipe, it only removes processing at internal 'checkpoint' to speed up delivery.

From this angle though, the intended working of QoS of VoIP (using mangle marking pre-routing, plus queue tree settings) remains a valid reason. It's bandwidth priority required to ensure QoS of such as VoIP calls.

Using macgaiver's apt metaphor of a club entrance, logistically speaking, there are clearly three queues at the club entrance.

- A special priority entrance for VIP (always available for very important personnel).
- A quick pass-through for regular faces, and
- A queue for unknown faces.

I think the real challenges is to make Fasttrack work only in the 'remaining nominal bandwidth' after allowing for QoS (i.e. VIP entrance) whenever it's needed. This way, a VoIP call does not turns into a conversation of broken words with silence breaks in between. This would definitely result in a better overall performance of suitable MikroTik routerboads. A win-win, using a cliche. I believe Jarda has a very good point here in respect of having more than one queue for Fasttracking.

It broke my initiated VoIP call on the receiver's end when Fatstrack was turned on even though with a connection of 100mbps/down and 2.4mbps/up.

I does sounds like a contradictory issue as it currently stands. But I thought of giving a fresh perspective.
Cheers

Posted: **Mon Sep 07, 2015 8:20 am**

Just imagine that someone has weak router, fast Internet access and doesn't care about the qos. His router is a bottleneck without fasttrack. When fasttrack is on: whooooo, what a ride!

Posted: **Wed Sep 09, 2015 2:53 am**

Anyone have any tips for why I would have a fasttrack connection rule in forward, but yet "fasttrack active" is no? I see traffic going to the fasttrack rule. Thoughts?

Posted: **Wed Sep 09, 2015 8:30 am**

If subsequent accepting rule counts the same like previous fasttracking rule, the fasttrack is not applied. Probably some of the conditions are not met in your case. Check the wiki.

Posted: **Wed Sep 09, 2015 2:09 pm**

Why do I have the "special dummy rule" duplicated three times in Mangle?
Look closely there's 3 distinct rules...

forward, prerouting and postrouting.

Just gives you a breakdown of total.

But why all chains' counters are always equal?

MT-dummy.png

Posted: **Thu Sep 10, 2015 2:38 am**

Perhaps it's a trivial thing. But it does not make sense.

When Fasttrack is engaged under 6.30.4, Speedtest.net (by Ookla) does not indicate a better performance that I would expect. In fact, it gives much lower performance than my nominal bandwidth 100mbps/down and 2.4mbps up.

Does anybody have the same experiences?

MikroTik

FastTrack - New feature in 6.29

FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29

Re: FastTrack - New feature in 6.29