...
Queues in RouterOS are processed using CPU resources, so limiting traffic with queues on the devices with relatively weak CPU CPUs is not an effective configuration. In other words, switch-based units will be overloaded very soonfast, because they are meant to process layer 2 traffic by using a switch-chip, not CPU. To avoid such such inefficiency, RouterOS allows limiting traffic using switch chips.
...
| Warning |
|---|
This paragraph applies to CCR2116, CCR2216 devices, and CRS3xx, CRS5xx series switches, not . It doesn't apply to CRS1xx/CRS2xx series switches!. |
For CRS3xx series switches, it is possible to limit ingress traffic that matches certain parameters with ACL rules and it is possible to limit ingress/egress traffic per port basis. The policer is used for ingress traffic, the shaper is used for egress traffic. The ingress policer controls the received traffic with packet drops. Everything that exceeds the defined limit will get dropped. This can affect the TCP congestion control mechanism on end hosts and the achieved bandwidth can be actually less than defined. The egress shaper tries to queue packets that exceed the limit instead of dropping them. Eventually, it will also drop packets when the output queue gets full, however, it should allow utilizing the defined throughput better.
...
In Strict Priority scheduling mode, the highest priority queue is served first. The queue number represents the priority and the queue with the highest queue number has the highest priority. Traffic is transmitted from the highest priority queue until the queue is empty, and then moves to the next highest priority queue, and so on. If no congestion is present on the egress port, the packet is transmitted as soon as it is received. If congestion occurs on at the port where high-priority traffics keep traffic keeps coming, the lower-priority queues starve.
On all CRS switches the scheme where MAC-based egress traffic scheduling is done according to internal Priority would be the following: [MAC address] -> [QoS Group] -> [Priority] -> [Queue];
In this example, host1 (E7:16:34:00:00:01) and host2 (E7:16:34:00:00:02) will have higher priority 1 and the rest of the hosts will have lower priority 0 for transmitted traffic on port ether7. Note that CRS has a maximum of 8 queues per port.
...
The scheme where MAC based traffic shaping is done according to internal Priority would be following: [MAC address] -> [QoS Group] -> [Priority] -> [Queue] -> [Shaper];
In this example, unlimited traffic will have priority 0 and limited traffic will have priority 1 with the a bandwidth limit of 10Mbit. Note that CRS has a maximum of 8 queues per port.
...
| Code Block | ||
|---|---|---|
| ||
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether6 hw=yes add bridge=bridge1 interface=ether7 hw=yes add bridge=bridge1 interface=ether8 hw=yes |
Create a QoS group for use in UFDB:
...
| Code Block | ||
|---|---|---|
| ||
/interface ethernet switch shaper add port=ether8 rate=10M target=queue1 |
If the CRS switch supports Access Control List, this configuration is simpler:
| Code Block | ||
|---|---|---|
| ||
/interface ethernet switch acl policer add name=policer1 yellow-burst=100k yellow-rate=10M /interface ethernet switch acl add mac-dst-address=E7:16:34:A1:CD:18 policer=policer1 |
VLAN-based traffic scheduling + shaping using internal Priorities
A best practice is to assign lower internal QoS Priority for traffic limited by shaper to make it also less important in the Strict Priority scheduler. (higher priority should be more important and unlimited)
...
Configure ether6, ether7, ether8 port queues to work according to Strict Priority and QoS scheme only for VLAN-based QoS:
| Code Block | ||
|---|---|---|
| ||
/interface ethernet switch port
set ether6 per-queue-scheduling="strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-prior\
ity:0,strict-priority:0,strict-priority:0,strict-priority:0" priority-to-queue=0:0,1:1,2:2 \
qos-scheme-precedence=vlan-based
set ether7 per-queue-scheduling="strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-prior\
ity:0,strict-priority:0,strict-priority:0,strict-priority:0" priority-to-queue=0:0,1:1,2:2 \
qos-scheme-precedence=vlan-based
set ether8 per-queue-scheduling="strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-prior\
ity:0,strict-priority:0,strict-priority:0,strict-priority:0" priority-to-queue=0:0,1:1,2:2 \
qos-scheme-precedence=vlan-based |
...
By default, CRS1xx/CRS2xx series devices will ignore the PCP/CoS/802.1p value and forward packets based on FIFO (First-In-First-Out) manner. When the device's internal queue is not full, then packets are in a FIFO manner, but as soon as a queue is filled, then higher-priority traffic can will be sent out first. Let's consider a scenario when when ether1 and ether2 is are forwarding data to ether3, but when ether3 is congested, then packets are going to be scheduled, we can configure the switch to hold lowest priority packets until all higher priority packets are sent out, this is a very common scenario for VoIP type setups, where some traffic needs to be prioritized.
...
The same Ingress Port policer also can be used for the traffic storm control to prevent disruptions on Layer 2 ports caused by broadcast, multicast, or unicast traffic storms.
...
Example with multiple packet types that includes include ARP and ND protocols and unregistered multicast traffic. Unregistered multicast is the traffic which is not defined in the Multicast Forwarding database:
...