Queues in RouterOS are processed using CPU resources, so limiting traffic with queues on the devices with relatively weak CPU is not an effective configuration. In other words, switch-based units will be overloaded very soon, because they are meant to process layer 2 traffic. To avoid such inefficiency, RouterOS allows limiting traffic using switch chips.
CRS3XX Series devices
This current section corresponds to the following devices:
|Model||Switch Chip||CPU||Cores||Wireless||SFP+ port||ACL rules||Jumbo Frame (Bytes)|
This article applies to CRS3xx series switches and not to CRS1xx/CRS2xx series switches!
It is possible to limit certain types of traffic using ACL rules. For CRS3xx series switches, it is possible to limit ingress traffic that matches certain parameters and it is possible to limit ingress/egress traffic per port basis. For ingress traffic QoS policer is used, for egress traffic, QoS shaper is used:
Port-Based Traffic Shaping:
MAC Based Traffic Shaping:
VLAN Based Traffic Shaping:
Protocol Based Traffic Shaping:
This subsection does not apply to CRS3XX series devices!
MAC based traffic scheduling and shaping: [MAC address in UFDB] -> [QoS Group] -> [Priority] -> [Queue] -> [Shaper]
VLAN based traffic scheduling and shaping: [VLAN id in VLAN table] -> [QoS Group] -> [Priority] -> [Queue] -> [Shaper]
Protocol based traffic scheduling and shaping: [Protocol in Protocol VLAN table] -> [QoS Group] -> [Priority] -> [Queue] -> [Shaper]
PCP/DEI based traffic scheduling and shaping: [Switch port PCP/DEI mapping] -> [Priority] -> [Queue] -> [Shaper]
DSCP based traffic scheduling and shaping: [QoS DSCP mapping] -> [Priority] -> [Queue] -> [Shaper]
MAC based traffic scheduling using internal Priority
In Strict Priority scheduling mode, the highest priority queue is served first. The queue number represents the priority and the queue with highest queue number has the highest priority. Traffic is transmitted from 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, packet is transmitted as soon as it is received. If congestion occurs on the port where high priority traffics keep 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 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.
Create a QoS group for use in UFDB:
Add UFDB entries to match specific MACs on ether7 and apply QoS group1:
Configure ether7 port queues to work according to Strict Priority and QoS scheme only for destination address:
MAC based traffic shaping using internal Priority
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 bandwidth limit 10Mbit. Note that CRS has a maximum of 8 queues per port.
Create a group of ports for switching:
Create QoS group for use in UFDB:
Add UFDB entry to match specific MAC on ether8 and apply QoS group1:
Configure ether8 port queues to work according to Strict Priority and QoS scheme only for destination address:
Apply bandwidth limit for queue1 on ether8:
If CRS switch supports Access Control List, this configuration is simpler:
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)
In this example:
Switch port ether6 is using a shaper to limit the traffic that comes from ether7 and ether8.
When a link has reached its capacity, the traffic with the highest priority will be sent out first.
VLAN10 -> QoS group0 = lowest priority
VLAN20 -> QoS group1 = normal priority
VLAN30 -> QoS group2 = highest priority
Create QoS groups for use in the VLAN table:
Add VLAN entries to apply QoS groups for certain VLANs:
Configure ether6, ether7, ether8 port queues to work according to Strict Priority and QoS scheme only for VLAN based QoS:
Apply bandwidth limit on ether6:
PCP based traffic scheduling
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 be sent out first. Let's consider a scenario when ether1 and ether2 is 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.
To achieve such a behavior, switch together ether1, ether2, and ether3 ports:
Enable Strict Policy for each internal queue on each port:
Map each PCP value to an internal priority value, for convenience reasons simply map PCP to an internal priority 1-to-1:
Since the switch will empty the largest queue first and you need the highest priority to be served first, then you can assign this internal priority to a queue 1-to-1:
Finally, set each switch port to schedule packets based on the PCP value:
Both Ingress Port policer and Shaper provide bandwidth limiting features for CRS switches:
Ingress Port Policer sets RX limit on port:
Shaper sets TX limit on port:
Traffic Storm Control
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.
Broadcast storm control example on ether5 port with 500 packet limit per second:
Example with multiple packet types that includes ARP and ND protocols and unregistered multicast traffic. Unregistered multicast is the traffic which is not defined in the Multicast Forwarding database: