...
| Warning |
|---|
This article applies to CRS1xx and CRS2xx series switches and not to CRS3xx series switches. For CRS3xx series devices read the CRS3xx, CRS5xx series switches and CCR2116, CCR2216 manual. |
Port switching
...
In order to To set up port switching on CRS1xx/2xx series switches, check the Bridge Hardware Offloading page.
| Warning |
|---|
It is possible to create multiple isolated switch group groups by using multiple bridges with enabled hardware offloading, this is possible only on CRS1xx/2xx series switches. For more complex setups (for example, VLAN filtering) you should use the port isolation feature instead. |
...
If invalid VLAN filtering is not enabled, management access to the device using tagged or untagged (VLAN 0) traffic is already allowed from any port, though this is not a good practice, this can cause security issues and can cause the device's CPU to be overloaded in certain situations (most commonly with a broadcast type of traffic).
If you are intending intend to use invalid VLAN filtering (which you should), then ports, from which you are going to access the switch, must be added to the VLAN table for untagged (VLAN 0) traffic, for example, in case you want to access the switch from ether2:
...
| Code Block | ||
|---|---|---|
| ||
/interface ethernet switch egress-vlan-tag add tagged-ports=ether2,switch1-cpu vlan-id=99 |
After a valid VLAN99 configuration has been set up, you can enable unknown/invalid VLAN filtering, which will not allow the management access through different ports than specified in the VLAN table:
...
| Note |
|---|
It is recommended to get a Serial Console cable and test testing it before configuring VLANs because you may lose access to the CPU and/or the port you are connected to. |
...
| Note |
|---|
Some changes may take some time to take effect due to already-learned MAC addresses. In such cases flushing the Unicast Forwarding Database can help: |
| Warning |
|---|
Multiple hardware offloaded bridge configuration is designed as a fast and simple port isolation solution, but it limits part of the VLAN functionality supported by the CRS switch-chip. For advanced configurations use one bridge within the CRS switch chip for all ports, configure VLANs, and isolate port groups with port isolation profile configuration. |
...
| Note |
|---|
When an entry is created under |
...
| Note |
|---|
It is possible to use the built-in switch chip and the CPU at the same time to create a Switch-Router setup, where a device acts as a switch and as a router at the same timesimultaneously. You can find a configuration example in the CRS-Router guide. |
...
InterVLAN routing configuration consists of two main parts – VLAN tagging in switch-chip and routing in RouterOS. This configuration can be used in many applications by combining it with a DHCP server, Hotspot, PPP, and other features for each VLAN.
...
| 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 |
Set VLAN tagging on the CPU port for all VLANs to make packets tagged before they are routed:
...
| Warning |
|---|
Make sure the VLAN interfaces are created on top of the bridge interface instead of any of the physical interfaces. If the VLAN interfaces are created on a slave interface, then the packet might not be received correctly, and therefore routing might fail. More detailed information can be found in the VLAN interface on a slave interface manual page. |
...
| Warning |
|---|
Using multiple bridges on a single switch chip with enabled unknown/invalid VLAN filtering can cause unexpected behavior. You should always use a single bridge configuration whenever using VLAN filtering. If port isolation is required, then the port isolation feature should be used instead of using multiple bridges. |
...
CRS-1: The first switch on the edge of the service provider network has to properly identify traffic from the customer VLAN id ID on port and assign a new service VLAN id ID with ingress VLAN translation rules. VLAN trunk port configuration for service provider VLAN tags is in the same egress-vlan-tag tag table. The main difference from basic Port-Based VLAN configuration is that the CRS switch-chip has to be set to do forwarding according to service (outer) VLAN id ID instead of customer (inner) VLAN idID.
| Code Block | ||
|---|---|---|
| ||
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether1 hw=yes add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether9 hw=yes /interface ethernet switch ingress-vlan-translation add customer-vid=200 new-service-vid=400 ports=ether1 add customer-vid=300 new-service-vid=500 ports=ether2 /interface ethernet switch egress-vlan-tag add tagged-ports=ether9 vlan-id=400 add tagged-ports=ether9 vlan-id=500 /interface ethernet switch set bridge-type=service-vid-used-as-lookup-vid |
CRS-2: The second switch in the service provider network require requires only switched ports to do forwarding according to service (outer) VLAN id ID instead of customer (inner) VLAN idID.
| Code Block | ||
|---|---|---|
| ||
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether9 hw=yes add bridge=bridge1 interface=ether10 hw=yes /interface ethernet switch set bridge-type=service-vid-used-as-lookup-vid |
...
- Ports in a switch group using a bridge;
- Ingress VLAN translation rules to define new service VLAN assignments on ports;
- tagged-ports for service provider VLAN trunks;
- CRS switch-chip set to use service VLAN id ID in switching lookup.
| Code Block | ||
|---|---|---|
| ||
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether3 hw=yes add bridge=bridge1 interface=ether4 hw=yes add bridge=bridge1 interface=ether10 hw=yes /interface ethernet switch ingress-vlan-translation add customer-vid=200 new-service-vid=400 ports=ether3 add customer-vid=300 new-service-vid=500 ports=ether4 /interface ethernet switch egress-vlan-tag add tagged-ports=ether10 vlan-id=400 add tagged-ports=ether10 vlan-id=500 /interface ethernet switch set bridge-type=service-vid-used-as-lookup-vid |
...
Set the switch to filter VLANs based on the service tag (0x88a8):
| Code Block | ||
|---|---|---|
| ||
/interface ethernet switch set bridge-type=service-vid-used-as-lookup-vid |
...
| Note |
|---|
Since the switch is set to look up VLAN ID based on the service tag, which is overridden with a different EtherType, then VLAN filtering is only done on the outer tag of a packet, the inner tag is not checked. |
...
The second example requires ports to be switched in a group. Mirroring configuration sets the ether5 port as a mirror0 analyzer port and sets the mirror0 port to be used when mirroring from VLAN occurs. VLAN table entry enables mirroring only for VLAN 300 traffic between ether2 and ether7 ports.
...
The third configuration also requires ports to be switched in a group. Mirroring configuration sets the ether5 port as a mirror0 analyzer port and sets the mirror0 port to be used when mirroring from the Unicast Forwarding database occurs. The entry from the Unicast Forwarding database enables mirroring for packets with source or destination MAC address E7:16:34:A1:CD:18 from ether8 port.
...
| Warning |
|---|
Bridge (R)STP is not aware of the underlying switch trunking configuration and some trunk ports can move to a discarding or blocking state. When trunking member ports are connected to other bridges, you should either disable the (R)STP or filter out any BPDU between trunked devices (e.g. with ACL rules). |
...
And configure port isolation/leakage profile for selected Community (2) to allow DHCP traffic destined only to the port where the trusted DHCP server is located. registration status and traffic-type properties have to be set empty in order to apply restrictions only for DHCP protocol.
...
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 at the egress port, a packet is transmitted as soon as it is received. If congestion occurs in the port where high-priority traffics 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.
| 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:
...
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 a bandwidth limit of 10Mbit. Note that CRS has a maximum of 8 queues per port.
...
| 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
The 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)
...
Create QoS groups for use in the VLAN table.
| Code Block | ||
|---|---|---|
| ||
/interface ethernet switch qos-group add name=group0 priority=0 add name=group1 priority=1 add name=group2 priority=2 |
...
| Code Block | ||
|---|---|---|
| ||
/interface ethernet switch shaper add port=ether6 rate=10M |
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 sent in a FIFO manner, but as soon as a queue is filled, then higher-priority traffic can be sent out first. Let us consider a scenario when ether1 and ether2 are forwarding data to ether3, but when ether3 is congested, then packets are going to be scheduled, we can configure the switch to hold the 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.
...
Both Ingress Port policer and Shaper provide bandwidth-limiting features for CRS switches.
...
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.
...