that’s great news. Thanks for the information.
don’t know if this could be supported but it would be great if we could prioritize traffic based on TCP/UDP port.
We have plans to implement QoS profile assignment via Switch ACL rules, where you can match almost any L2/L3/L4 fields. The command will be something like this:
# NOT IMPLEMENTED YET! IT MAY BE A SUBJECT TO CHANGE.
/interface/ethernet/switch/rule add protocol=tcp dst-port=1337 qos-profile=my-prioritized-traffic
Would it be possible to omit “protocol=???” to catch UDP and TCP in one rule?
Please finish Q-in-Q,MACSEC and VXLAN processing/offloading in switch chip and stabilize Ros v7 along side with this new endeavor of your MT
First of all thanks for the documentation @raimondsp . Upon checking it I have come across a thing that would be great if clarified:
in
Port settings
…
By default, ports are untrusted and receive the lowest (0, best-effort) priority, where priority fields are cleared from the egress packets.
Is this for the
dscp
or the
priority
parameter? As in neither case marks 0 the lowest priority since in case of RFC4594 DiffServ Service Classes (DSCP)
dscp=8
should mark the lowest priority (CS1 Low-Priority Data which is below DF (CS0) Standard in the pecking order). In case of Priority Code Point (PCP) governed by 802.1Q-2022 (IEEE Standard for Local and Metropolitan Area Networks–Bridges and Bridged Networks) currently the lowest priority 0 (for background traffic) has PCP value 1 and the default PCP value 0 is for the one notch higher (priority 1) best effort traffic. So is the above quoted part of the documentation refers to PCP or DSCP?
If the above refers to PCP, than PCP value or PCP defined priority as it does make difference since PCP value 0 has priority 1, while PCP value 1 has priority 0.
If the above refers to DSCP, than the same question rises: does it refer to the value, in which case 0 has higher priority (DF (CS0)) than 8 (CS1)?
While we are at it in the same documentation regarding the PCP values the
QoS Profile
…
priority (integer: 0..7; Default: 0) - VLAN priority value (IEEE 802.1q PCP - Priority Code Point). …
refer to the PCP value or the priority (as unlike higher values in the case of the first two PCP values of 0 and 1 these don’t match)?
Thanks in advance for the explanation (and for clearing this up in the documentation).
Hi,
You are right - the “Scavenger” class (CS1, DSCP=8) is the lowest DiffServ class, lower than Best-Effort (DSCP=0). I didn’t know that the same applies to PCP, where PCP=1 means the lowest priority, followed by Best-Effort (PCP=0). It makes sense since PCP values are usually obtained from DSCP by shifting the three least significant bits. We will update the documentation to clarify that the default QoS profile is Best-Effort (PCP=0, DSCP=8), but it isn’t the lowest priority. Also, we will consider renaming the QoS profile’s priority field to pcp to avoid further confusion.
An example to assign the lowest priority to the port:
/interface/ethernet/switch/qos/profile add name=lowest-priority priority=1 dscp=8
/interface/ethernet/switch/port set ether1 qos-profile=lowest-priority
Thank you for the feedback!
The most often used priority sequence for the 3 bit field is: 1,2,0,3,4,5,6,7
So indeed 1 is lowest, 2 is above that, and then 0 (default) is higher and 3-7 are above that (7 is highest).
Thanks for your work on this. I’m looking forward to taking advantage of QoS-HW. If I understand, we’re now able to mark in hardware but enforcement still requires queues, which are mostly incompatible with fasttrack. On the CRS309, we still depend on fasttrack above ~400mbps so a hardware solution will be a big improvement.
In addition to prioritizing voice and other real-time traffic (gaming, Teams calls, etc. who can tag DSCP), if it is possible I would like to see:
- fq_codel-like mechanism that controls bufferbloat and ensures users’ traffic does not get choked out by noisy neighbours
- Shaping/queueing for media changes, e.g. 10G-1G flow, 10G-1G/2.5G-WiFi flow, etc. where traffic is repeatedly dropped/retried and throughput suffers as a result. I am struggling with this on my network where I have my NAS and virtualization hosts connected at 10G and a 10G link to the otherwise-1G switch where my access points, workstations, and other devices are connected.
Hello,
I don’t know if it related or not. Sorry if i made a mistake to post here.
I am currently using switch rules on a CRS305 in front of CCR2116 tp change COS on DHCP (ipv6 ipv4) requests. These DHCP requests with COS 6 are a requirement to authenticate to my ISP.
I decided to remove the CRS305 and use only the CCR2116. Of course i moved the switch rules from the CRS305 to the CCR.
But the rules do not work at all. Switch rules to change COS are never applied.
I am not sure, but i think i have understand that the switch are applied to ingress traffic, not egress. I my case, the DHCP client requests are of course egress from the CCR to my ISP.
Am i right or i make a mistake ?
Is there a workaround to change COS for DHCP egress requests ?
thanks.
are you using L3 HW offload? or any other Switch Function?
Hello,
I do not change this params from default (upgraded to 7.10.2).
Switch > Switch1 > L3HW Offloading is DISABLED
Switch > Port > sfpX (wan port) > L3HW Offloading is ENABLED (i tried to disable but the web interface give an error for Storm Rate which is to 10000% per default).
/interface/ethernet/switch/print
Columns: NAME, TYPE, L3-HW-OFFLOADING, QOS-HW-OFFLOADING
# NAME TYPE L3-HW-OFFLOADING QOS-HW-OFFLOADING
0 switch1 Marvell-98DX3255 no no
[admin@router1] > /interface/ethernet/switch/print detail
Flags: I - invalid
0 name="switch1" type=Marvell-98DX3255 mirror-source=none mirror-target=none mirror-egress-target=none l3-hw-offloading=no qos-hw-offloading=no
[admin@router1] > /interface/ethernet/switch/port print detail
Flags: I - invalid
0 name="sfp1.lan" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
1 name="sfp2.wan1" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
2 name="sfp-sfpplus3" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
3 name="sfp-sfpplus4" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
4 name="ether1.wan2" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
5 name="ether2" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
6 name="ether3" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
7 name="ether4" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
8 name="ether5" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
9 name="ether6" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
10 name="ether7" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
11 name="ether8" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
12 name="ether9" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
13 name="ether10" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
14 name="ether11" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
15 name="ether12" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes l3-hw-offloading=yes qos-profile=default qos-map=default qos-trust-l2=ignore qos-trust-l3=ignore
16 name="switch1-cpu" switch=switch1 storm-rate=100 limit-unknown-unicasts=no limit-unknown-multicasts=no limit-broadcasts=yes
/interface/ethernet/switch/rule/print detail
Flags: X - disabled, I - invalid; D - dynamic
0 X ;;; orange dhcp4 COS6
switch=switch1 ports=sfp2.wan1 mac-protocol=ip vlan-id=832 protocol=udp dst-port=67 copy-to-cpu=no redirect-to-cpu=no mirror=no new-vlan-priority=6
1 X ;;; orange dhcp6 COS6
switch=switch1 ports=sfp2.wan1 mac-protocol=ipv6 vlan-id=832 protocol=udp dst-port=547 copy-to-cpu=no redirect-to-cpu=no mirror=no new-vlan-priority=6
2 X ;;; orange icmp6 COS6 (fe00::/7 = fe80::/10 + ff02::/16)
switch=switch1 ports=sfp2.wan1 mac-protocol=ipv6 vlan-id=832 protocol=icmp dst-address6=fe00::/7 copy-to-cpu=no redirect-to-cpu=no mirror=no new-vlan-priority=6
3 X ;;; orange arp COS6
switch=switch1 ports=sfp2.wan1 mac-protocol=arp vlan-id=832 copy-to-cpu=no redirect-to-cpu=no mirror=no new-vlan-priority=6
The switch rules are currently disabled (i have just disabled them because they do not work at all)
Is this related ? should i disable ?
L3HW offload has to be enabled on the switch before enabling it on the ports makes any difference. If it’s not enabled at the switch level, then none of the HW QoS marking will apply.
Thanks.
Do i need to enable on the switch ?
/interface/ethernet/switch/set l3-hw-offloading=yes
Does my current switch rules will work or do i need to rewrite them ?
thanks
Hi,
Enabling l3-hw-offloading on the switch level globally turns on L3HW (i.e., starts l3hw driver). Other l3hw configuration options do not matter when l3-hw-offloading=no (RouterOS still keeps showing them for diagnostic purposes).
Switch ACL Rules (/interface/ethernet/switch/rule) work with L3HW. Moreover, Switch Rules have a higher priority than L3HW. For example, you can create a rule to drop traffic or redirect it to the CPU - in both cases, the respective packets will not reach L3HW.
Thanks.
As i understand, switch ACL are only for inbound traffic, not outbound (my case).
is a little off topic but i have the following question:
is MikroTik considering in the long term to have some Eggress ACL (switch rules) support on CRS Switches ?
I am interested to know this too.
In my opinion, the current switch ACL language is extremely prohibitive. Mikrotik needs to develop an all new Switch ACL language that can handle more use-cases, a few off the top of my head:
- Ingress + Egress traffic flows
- Multiple actions, e.g. Rewrite + Count
- Ability to match on different and multiple parts of the packet header e.g. Outer and Inner VLAN tag
- Ability to rewrite outer and inner VLAN tags
- Ability to strip and add multiple VLAN tags
Ideally this would provide an abstraction layer allowing it to be used on current and future hardware, even if it has different switch ASIC’s.
I would like this to have some fast-path option in the firewall. This would allow doing content matching by source for use in traffic shaping appliances and QoS on some radio hardware. ie, match zoom’s ASN IPs and mark those voice on ingress.
interface rate setting for QoS. Most backhaul radios are not as fast as their interface, Ie we have 10G ports on 1.5Gbps radios. It would be nice to set that to the expected rate.
identify and drop ECN marks in hardware when rates approach/exceed the rate set on the interface as mentioned above.
Would be really nice to get fq_codel in there if the hardware can handle it. cake even better. Ability to handle a queue tree even better.
reporting. netflow or similar data.
much of this can be done in software, but at huge performance costs. If any of it can be done in hardware that would be great for the *isp market.
I’m wondering as well, does this QoS-HW mean fq-codel traffic shaping in hardware as opposed to a CPU only thing?
Cheers
Paul