I'm running a CCR1009 on 6.42.6. I am testing inter-vlan performance using iperf. The CCR is only capable of gigabit on a single connection if the connection is fasttracked. The following are the first 2 rules of my firewall forward chain:
When I have packets flowing from vlan1 to vlan201, it gets fasttracked. I can see the special dummy rule is showing full gigabit and the packets aren't flowing through any other rules. However, when I test from vlan201 to vlan1, the special dummy rule is showing 15Mb/s and the first two rules above are showing ~500Mb/s (a cpu is maxed out). I can also see these packets going through one of my mangle rules. This tells me the packets are not getting fasttracked. Why would fasttrack only be working in one direction? Any clues as to how I get it to fasttrack properly?

Normally it works in such a way that vast majority of packets of a fasttracked connection in both directions is handled by fasttracking, and only every n-th packet of a fasttracked connection per each direction is intentionally not fasttracked and takes the standard path. So I'd log the traffic of the mangle rule to see whether the packets which are not fasttracked are actually connection tracked - fasttracking doesn't work without connection tracking, and something is telling me that connections not answered yet (i.e. unidirectional ones) may not get fasttracked. If you use iperf and there is no mirror flow, I'd rather ask how comes that the same effect doesn't happen in both directions.

does the parent receiving interface support fastpath?

Same any soultion ?

Which protocol is used for testing? If UDP is used, then I guess ROS might not be able to classify the stream as connection[*] and those packets wouldn't be part of "established" connection ... or not every time. It should work with TCP testing though.

[*]Unlike TCP there's no connection state for UDP on protocol level. Instead ROS tries to analyze stream to determine if there's a two-way communication. Which might not happen as soon as ROS expects in certain use cases.

BTW, for the firewall filter construct as mentioned in OP's post it is vital to maintain interface list membership current ...

I was able to fix this. It was a while ago so I don't remember exactly, but I think it was changing this:
to this: