fasttrak problem with RB91x transparent bridge

Hi all,

I have several trunk type point-to-point links between two switches made with RB91x bridges (bridge-station bridge) and ROS 7.5

I am using a qos configuration identical to the script of mducharme’s FastTrack-Friendly Queues post;

Everything works fine except fasttrack, I can see that some tcp or udp connections are well fasttracked in the “Connections” tab, but the counter for the “dummy” rule remains at 0.

It’s the same in IP/Settings, fastrack is active but the counters are at 0.

A priori the material is fasttrack compatible according to the ROS documentation

I’ve tested everything after having scoured the forum a lot looking for similar cases, tested several version of ROS 7, I can’t find anything conclusive.

Has anyone with RB9xx type cards ever managed to get fasttrack to work?

thanks in advance for your help

Do I understand you right that your RB91x devices are tranparrently (on L2) passing traffic between ether and wireless interfaces?

Fasttrack is firewall feature and if you don’t explicitly enable use-ip-firewall=yes on bridge settings, IP firewall doesn’t apply to bridged traffic at all, so no fasttrack-ed traffic.

hello,

yes that’s right just a transparent level 2 bridge between eth1 and wlan1 (I also tested with the vlan filtering option on the bridge and tagging each vlan on the ports it doesn’t change anything)

I put some screenshots.

The only thing I haven’t done yet is downgrade to version 6.

I don’t think this is a display bug as I have no performance change with or without fasttrack.

Before I only used fastpath but now I have voip on the link and I have to be able to manage congestion in case
IMG_4429.jpeg
IMG_4431.jpeg
IMG_4427.jpeg
IMG_4430.jpeg

As I explained, fasttrack is about firewalling. Simple bridging between two ports members of bridge, bypasses routing/firewalling (i.e. anything defined under /ip and subtree). If you’d like to use interface queues (which again doesn’t have to much with routing) to prioritize (or rather de-prioritize) some traffic, you can do it in /queue simple … and for queues to work traffic actually must not be fasttracked (fasttracking means that packets, eligible for fasttracking, avoid most of processing, queuing however needs packet processing in its fullest).

ok in this case I will have to revise the way I manage the qos :confused: