the pcc dose not work when it works with fasttrack

shiyiqiang08 · Wed Dec 05, 2018 7:39 am

hello
when i use fasttrack
the pcc do not work
when i turn off the fasttrack
everything is ok
is this a bug ?
thank you very much

Steveocee · Wed Dec 05, 2018 1:04 pm

PCC requires mangle and connection tracking to work.
Fast track removes all connection tracking in an effort to process packets faster.

No bug. No magic.

nkourtzis · Wed Dec 05, 2018 1:07 pm

No, it is not a bug. It is actually mentioned somewhere in the wiki. Fasttrack bypasses some sections of the Firewall engine (part of which is mangle) and this makes it incompatible with some features that look inside packets, like pcc (which is based on source/destination addresses/ports).

shiyiqiang08 · Wed Dec 05, 2018 3:38 pm

PCC requires mangle and connection tracking to work.
Fast track removes all connection tracking in an effort to process packets faster.

No bug. No magic.

thank you very much

shiyiqiang08 · Wed Dec 05, 2018 3:42 pm

PCC requires mangle and connection tracking to work.
Fast track removes all connection tracking in an effort to process packets faster.

No bug. No magic.

because i saw somebody use it with pcc in the forum
and works fine
so i am confused how it work
my english is poor ,i am from china ,but i am a fun of ros.

shiyiqiang08 · Wed Dec 05, 2018 3:49 pm

No, it is not a bug. It is actually mentioned somewhere in the wiki. Fasttrack bypasses some sections of the Firewall engine (part of which is mangle) and this makes it incompatible with some features that look inside packets, like pcc (which is based on source/destination addresses/ports).

thank you ,the issue confuses me so much time
it takes me so much time to find the reason
it is my fault

mkx · Wed Dec 05, 2018 6:05 pm

Let's assume that there are a few subnets behind the router. Those subnets are separated on L2 (either physical ether ports or VLANs) and L3 (different network addresses). Which is proper / best way of excluding certain subnet from being fasttracked? For example because those subnets will be subject to PCC or simple queue or ...

shiyiqiang08 · Fri Dec 07, 2018 2:54 pm

Let's assume that there are a few subnets behind the router. Those subnets are separated on L2 (either physical ether ports or VLANs) and L3 (different network addresses). Which is proper / best way of excluding certain subnet from being fasttracked? For example because those subnets will be subject to PCC or simple queue or ...

when you add fasttrack rule,you can define the rule of yourself and separate the ip that you do not want to fasttrack
or you can make filter rule before the fasttrack rule and choose no passthrough

mkx · Fri Dec 07, 2018 9:40 pm

when you add fasttrack rule,you can define the rule of yourself and separate the ip that you do not want to fasttrack
or you can make filter rule before the fasttrack rule and choose no passthrough

.

I've created rule such as this:

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related src-address=!192.168.41.0/24

.
and placed it just above the usual action=accept connection-state=established,related ... but it didn't work. I have a /queue simple targeting the same subnet. If fasttrack is disabled, queue works just fine, but it doesn't work with fasttrack rule as defined above.

sebastia · Fri Dec 07, 2018 9:47 pm

Hey

I've the following for selective fast-tracking and working fine:

add action=fasttrack-connection chain=forward comment="FastTrack: established & related" connection-bytes=8000-0 \
    connection-mark=FT connection-state=established,related

add action=accept chain=est_rel comment="Accept: established & related" connection-state=established,related
add action=drop chain=est_rel comment="Drop: invalid" connection-state=invalid

So:
* only fast-track after iniital 8k, so that some other filtering like TLS can be applied
* only if it's explicitly marked for FT in mangling, that's on connection level so it's cheap
* catch rule for above for some of the packets which don't get fasttracked to keep the connection tracking alive

sebastia · Fri Dec 07, 2018 11:46 pm

I've created rule such as this:

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related src-address=!192.168.41.0/24

That rule gets applied in both directions ... on the way back from internet to internal src-address exclude will not do the job...

Fasttracking behaves like connection-marking, once set it's for both directions.

mkx · Sat Dec 08, 2018 12:19 am

That rule gets applied in both directions ... on the way back from internet to internal src-address exclude will not do the job...

Fasttracking behaves like connection-marking, once set it's for both directions.

Do I understand correctly that if the connection is initiated from 192.168.41.0/24 (src address matches), it should not be fasttracked? And that's true for both directions?

sebastia · Sat Dec 08, 2018 12:36 am

Yes

The rule

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related src-address=!192.168.41.0/24

will do following
* LAN -> WAN
will not fasttrack if the src is .41. network.
* WAN -> LAN
will fasttrack ALL connections as none have src from .41. range

Result: all connections end up fasttracked

To correct:

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related src-address=!192.168.41.0/24 in-interface-list=LAN
# or similar

mkx · Sat Dec 08, 2018 6:04 pm

The rule
Code: Select all
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related src-address=!192.168.41.0/24
will do following
* LAN -> WAN
will not fasttrack if the src is .41. network.
* WAN -> LAN
will fasttrack ALL connections as none have src from .41. range

Result: all connections end up fasttracked

.
But for the outgoing packets, shouldn't those be "non-fasttracked" with the original rule? They will have src-address matching, hence queues should work at least for UL (which they didn't)? What about un-fasttracking the returning packets (=DL)? It would need another fasttrack rule with dst-address=192.168.41.0/24 ... or?
And why do you think including in-interface-list=LAN should make any difference? For UL it won't make any difference as all packets enter RB through one of LAN interfaces ... and for DL it will un-fasttrack all packets regardless of the dst-address.

The thing is that I'm running a few VLANs and in-interface for .41 subnet is vlan-41 ... and if I created an accept rule with "connection-state=established,related in-interface=vlan-41 action=accept" and pushed it on top of FW rules, it still didn't work as expected (not even for UL). At the same time I'd need another similar rule for incoming packets (for those vlan-41 would be out-interface).

sebastia · Sat Dec 08, 2018 10:07 pm

Short answer: "FastTracked is a connection state".
For demonstration see list of connections, first column: "F" = fasttrack for the connection.

This means that a connection either is or isn't FT. Since connection exists of two parts, up & down, both share same status.

With the original rule this happens for outbound connection:
add action=fasttrack-connection chain=forward connection-state=established,related src-address=!192.168.41.0/24

1. packet from .41.2 to 1.1.1.1, state: new
state != est/rel => result: no FT, mangling / queue will work
2. packet from 1.1.1.1 to .41.2, state: established
src is not in .41. & state=est => result: FT => new state: established & FastTracked
3. packet from .41.2 to 1.1.1.1, state: established, FT
already FT -> mangling / simple queue is bypassed

with the change "in-interface-list=LAN"
1. packet from .41.2 to 1.1.1.1, state: new
state != est/rel => result: no FT, mangling / queue will work
2. packet from 1.1.1.1 to .41.2, state: established
src is not in .41 & state=est & in-interface!=LAN => result: no FT, mangling / queue will work
3. packet from .41.2 to 1.1.1.1, state: established
src is in exclude range => result: no FT, mangling / queue will work

from another source
1. packet from .40.2 to 1.1.1.1, state: new
state != est/rel => result: no FT, mangling / queue will work
2. packet from 1.1.1.1 to .40.2, state: established
src is not in .40. & state=est & in-interface!=LAN => result: no FT
3. packet from .40.2 to 1.1.1.1, state: established
state=est & in-int=Lan & src!=.41. => result: FT, new state: est, FT -> mangling / simple queue will be bypassed
4. packet from 1.1.1.1 to .40.2, state: est, FT
already FT -> bypassing mangling & simple queue

Edit: clarified which queue is by-passed => simple queue

mkx · Sat Dec 08, 2018 10:56 pm

@sebastia: I really appreciate your effort to explain things to me.
So if I understand things correctly, a connection can get fasttracked at any time (even after a few packets exchanged) if any packet passes the rule criteria. However, when a connection is fasttracked, it won't get un-fasttracked until it lasts?

sebastia · Sat Dec 08, 2018 11:00 pm

Correct

eXS · Sun Dec 09, 2018 1:15 am

The rule

/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related src-address=!192.168.41.0/24

I tried to keep a queue functional by excluding [!] the IP's, similar to above ^, but it would not work. I had to put accept rules with that traffic before the fasttrack rule then the queue started working again --> viewtopic.php?f=2&t=139341#p702303

mkx · Sun Dec 09, 2018 1:14 pm

I tried to keep a queue functional by excluding [!] the IP's, similar to above ^, but it would not work.

.
That was my problem as well, hence my question here. I also had a similar rule, but instead of src-address I used in-interface, but that didn't work as well. I'll probably try to do as @sebastia explained nicely above in some not-so-distant future.

I solved the problem so far by marking connections in mangle rule and having fasttracked non-marked connections (I got this idea somewhere on this forum, quite probably it was described by either @sindy or @CZfan):

/ip firewall mangle
add action=mark-connection chain=forward comment="Guest VLAN" connection-state=new in-interface=vlan-41\
    new-connection-mark=vlan41 passthrough=yes
    
/ip firewall filter
add action=fasttrack-connection chain=forward comment="fasttrack ... everything that is not marked (see mangle rules)"\
    connection-mark=no-mark connection-state=established,related
# after that comes the normal accept established,related rule

.
As I wrote before, all my traffic that should be limited by simple queues, comes from vlan-41 interface.

I have yet to decide which approach I like better. The now-working approach is slightly complicated as it needs configuration in two distinct config sections. It wouldn't work nicely if connection marks were needed for anything else (e.g. for selective routing or some such). The approach explained by @sebastia is better as all rules are kept together. But (at least to me) it is not as understandable as it is the other one. I assume that both approaches are more or less equally resource-friendly.

the pcc dose not work when it works with fasttrack

the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Re: the pcc dose not work when it works with fasttrack

Who is online