Add new PCQ classifiers

RouterOS General
1

Hi,
seems current PCQ classifiers (dst-ip-addr, src-ip-addr) working only on etherType=0x800=ip packet
when device working in bridge mode and bridging packets, when it’s attached QUEUE on INTERFACE, it’s only classyfing plain IP packets.
Packets with etherType=pppoe sesssions, or packets with VLAN header, or Vlan-in-Vlan header ARE NOT BEING PLACED IN PCQ QUEUE!

I think best solution will be to add two PCQ classifiers: src-mad-addr, dst-mac-addr - then we don’t care what services being bridged through…

2

Queue work only on layer 3 traffics, So don’t work on bridge ports.
Queue don’t limit traffics forward through bridge ports.

3

If you are also doing queues on the pppoe server, and your transport / backhaul network is using vlan tags, then your marking rules on the pppoe server could also set a dot1p priority (cos) flag on the vlan headers. Middle switches could queue based on dot1p.

Other than that, you’re out of luck for prioritizing traffic within a tunnel.

4

yes, this is good; but the queue do not support layer 2 traffics, so this is not related to pcq classifiers.

5

hmmm - I would have thought that wmm might support this. It’s always one of those shadowy things that’s always just below the surface, doing its job, and you cannot configure it. (QoS is this way in Ubiquiti also)

6

I though “interface queue” is last queue before calling hw transmit - so it should work on L2 as well. any comment from MT engineers?

7

bump …

8

i have used simple queue and queue tree on bridge implementation

9

First of all it is important to know if you use use-ip-firewall in bridge settings.

Second, it is not good practice to limit traffic after encapsulation happened, you need to limit traffic before you encapsulate traffic into pppoe packet.

So i would suggest to move your queues to HTB Global, or to the simple queues, Where you can work with IPs.