Simple Queue Counts Traffic twice on VLAN interface

RouterOS General
1

Hi,
I recently noticed that a simple queue:

/queue simple
add max-limit=10M/100M name=test queue=\
    pcq-upload-default/pcq-download-default target=\
    192.168.23.0/24,192.168.11.0/24

Would count the traffic twice on a Capsman VLAN interface:

/interface vlan
add interface=bridge name=vlan23 vlan-id=23
/caps-man datapath
add bridge=bridge name=Datapath-LAN
add bridge=bridge name=Datapath-VLAN23 vlan-id=23 vlan-mode=use-tag

There is PCC load balancing but nothing unusual… connections are marked and routed accordingly…

/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark \
    in-interface=conn1 new-connection-mark=ISP-1
add action=mark-connection chain=prerouting connection-mark=no-mark \
    in-interface=conn2 new-connection-mark=ISP-2
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=bridge new-connection-mark=ISP-1 \
    passthrough=yes per-connection-classifier=src-address:2/0 src-address=\
    192.168.11.0/24
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=bridge new-connection-mark=ISP-2 \
    passthrough=yes per-connection-classifier=src-address:2/1 src-address=\
    192.168.11.0/24
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=vlan23 new-connection-mark=ISP-1 \
    passthrough=yes per-connection-classifier=both-addresses-and-ports:2/0 \
    src-address=192.168.23.0/24
add action=mark-connection chain=prerouting connection-mark=no-mark \
    dst-address-type=!local in-interface=vlan23 new-connection-mark=ISP-2 \
    passthrough=yes per-connection-classifier=both-addresses-and-ports:2/1 \
    src-address=192.168.23.0/24
add action=mark-routing chain=prerouting connection-mark=ISP-1 \
    in-interface=bridge new-routing-mark=ToISP1 passthrough=yes src-address=\
    192.168.11.0/24
add action=mark-routing chain=prerouting connection-mark=ISP-2 \
    in-interface=bridge new-routing-mark=ToISP2 passthrough=yes src-address=\
    192.168.11.0/24
add action=mark-routing chain=prerouting connection-mark=ISP-1 \
    in-interface=vlan23 new-routing-mark=ToISP1 passthrough=yes src-address=\
    192.168.23.0/24
add action=mark-routing chain=prerouting connection-mark=ISP-2 \
    in-interface=vlan23 new-routing-mark=ToISP2 passthrough=yes src-address=\
    192.168.23.0/24
add action=mark-routing chain=output connection-mark=ISP-1 \
    new-routing-mark=ToISP1
add action=mark-routing chain=output connection-mark=ISP-2 \
    new-routing-mark=ToISP2

When testing on a wireless client that belongs to VLAN23, when for example the actual download rate on my device is 50Mbps, the queue shows 100Mbps so it maxes out… the same goes for the upload, my actual upload rate is 5Mbps but the queue shows 10Mbps so it reaches its limit… All rates up/down are showing x 2 under the Queue …
The same does not happen when testing on a device that belongs to the Bridge interface ( not the VLAN23 )…

There are no other queues or queue trees, no other policy routing rules etc…
It seems that the queue captures the traffic twice, but why ? never had seen that behavior in the past on same configurations…


Any suggestions ?
I tried to replicate on another device but to my surprise i couldn’t..
ROS version is 6.49

2

Could it be that this particular CAP is talking to the CAPsMAN using L3 rather than L2 (i.e. /caps-man remote-cap print shows its IP address rather than its MAC address) and the IP address of the CAP fits into the target of the queue?

3

Why its always that simple ?
You 're most probably right… Any other solution rather than using L2 for communication between CAP and CapsMan ?
One i can think of quickly, is to use another address space for those devices that does not fit on the target address space…

4

That, or to use an unlimited queue whose target will be just the /32 address of the CAP, with the same parent like the limiting one. I’m not sure whether order or prefix length determine the precedence in this case, you have to try.

5

I could try that yes, thanks…
However, now i was looking on another network with similar setup ( more complex though ) and multiple VLANs, i do use L3 again ( i prefer it ) for communication between CAP and CapsMan i do not observe the same behavior…
And the address of the CAP fits in the target address space… That is what confused me since the beginning…
Is there any chance PCC plays any role in this behavior ?

6

That reminds me of the typical stages of debugging a software:

  1. why it doesn’t work here, given that it works elsewhere?
  2. how could it ever work elsewhere?


It should not unless you use rules that match on PCC to assign packet marks and set up simple queues to match on packet marks (which is btw another possibility how to exempt the CAPsMAN transport packets from matching the queue, but I think it might take a little bit of extra CPU power as compared to the second queue matching on a /32 target), or unless you use PCC to distribute the traffic between the CAPsMAN and the CAP via distinct physical paths. Both would be quite unusual.

7

Could it be that this particular CAP is talking to the CAPsMAN using L3 rather than L2

@sindy indeed that was the case causing the double traffic counting…

However, ( i’ ve noticed that in the past too ), setting an Upload/Download Max Limit to Unlimited does not work…
Either on a Parent-child setup or not… i will have to set a high limit for the specific queue so that it does not actually limit anything… Do i miss something ?