Manual:CRS1xx/2xx series switches examples: Difference between revisions
added post-v6.41 bridge hw-offload configurations |
No edit summary |
||
| (126 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Versions| v6. | {{Versions| v6.41 +}} | ||
{{Warning|This manual is moved to [[https://help.mikrotik.com/docs/pages/viewpage.action?pageId=103841836 CRS1xx/2xx series switches examples]]}} | |||
__TOC__ | __TOC__ | ||
=Summary= | |||
Basic use cases and configuration examples for Cloud Router Switch features. | Basic use cases and configuration examples for Cloud Router Switch features. | ||
{{Warning | This article applies to CRS1xx and CRS2xx series switches and not to CRS3xx series switches.}} | {{Warning | This article applies to CRS1xx and CRS2xx series switches and not to CRS3xx series switches. For CRS3xx series devices read the [[Manual:CRS3xx_series_switches | CRS3xx series switches]] manual.}} | ||
=Port switching= | |||
In order to setup port switching on CRS1xx/2xx series switches, check the [[Manual:Interface/Bridge#Bridge_Hardware_Offloading | Bridge Hardware Offloading]] page. | |||
{{ Warning | It is possible to create multiple isolated switch group 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. }} | |||
{{ Note | Port switching in RouterOS v6.41 and newer is done using the bridge configuration. Prior to RouterOS v6.41 port switching was done using the <var>master-port</var> property, for more details check the [[Manual:Master-port | Master-port]] page. }} | |||
=Management access configuration= | |||
In general, switches are only supposed to forward packets by using the built-in switch chip, but not allow access to the device itself for security reasons. It is possible to use device's serial port for management access, but in most cases such an access method is not desired and access using an IP address is more suitable. In such cases you will need to configure management access. | |||
In all types of management access it is assumed that ports must be switched together, use the following commands to switch together the required ports: | |||
<pre> | |||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 31: | Line 33: | ||
add bridge=bridge1 interface=ether4 hw=yes | add bridge=bridge1 interface=ether4 hw=yes | ||
add bridge=bridge1 interface=ether5 hw=yes | add bridge=bridge1 interface=ether5 hw=yes | ||
</pre> | |||
You should also assign an IP address to the bridge interface so the device is reachable using an IP address (the device is also reachable using a MAC address): | |||
<pre> | |||
/ip address | /ip address | ||
add address=192.168.88.1/24 interface= | add address=192.168.88.1/24 interface=bridge1 | ||
</pre> | </pre> | ||
==Untagged== | |||
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 broadcast type of traffic). | |||
If you are intending to use invalid VLAN filtering (which you should), then ports, from which you are going to access the switch, must to be added to the VLAN table for untagged ('''VLAN 0''') traffic, for example, in case you want to access the switch from '''ether2''': | |||
<pre> | <pre> | ||
/interface vlan | /interface ethernet switch vlan | ||
add | add vlan-id=0 ports=ether2,switch1-cpu | ||
</pre> | |||
==Tagged== | |||
/ | Allowing only tagged traffic to have management access to the device through a specific port is a much better practice. For example, to allow only '''VLAN99''' to access the device through '''ether2''' you should first add an entry to the VLAN table, which will allow the selected port and the CPU port ('''switch1-cpu''') to forward the selected VLAN ID, therefore allowing management access: | ||
add | <pre> | ||
/interface ethernet switch vlan | |||
add ports=ether2,switch1-cpu vlan-id=99 | |||
</pre> | </pre> | ||
Packets that will be sent out from the CPU, for example, ping replies will not have a VLAN tag, to solve this you need to specify which ports should always send out packets with a VLAN tag for a specific VLAN ID: | |||
<pre> | <pre> | ||
/interface ethernet switch egress-vlan-tag | /interface ethernet switch egress-vlan-tag | ||
add tagged-ports=ether2 | add tagged-ports=ether2,switch1-cpu vlan-id=99 | ||
</pre> | </pre> | ||
After valid VLAN99 configuration has been setup, you can enable unknown/invalid VLAN filtering, which will not allow the management access through different ports than specified in the VLAN table: | |||
<pre> | <pre> | ||
/interface ethernet switch | /interface ethernet switch | ||
| Line 61: | Line 71: | ||
</pre> | </pre> | ||
=== | In this example VLAN99 will be used to access the device, a VLAN interface on the bridge must be created and an IP address must be assigned to it. | ||
<pre> | |||
/interface vlan | |||
add interface=bridge1 name=MGMT vlan-id=99 | |||
/ip address | |||
add address=192.168.99.1/24 interface=MGMT | |||
</pre> | |||
=VLAN= | |||
{{Note | It is recommended to get Serial Console cable and test it before configuring VLANs because you | {{Note | It is recommended to get Serial Console cable and test it before configuring VLANs because you | ||
| Line 68: | Line 86: | ||
{{Note | Some changes may take some time to take effect due to already learned MAC addreses. In such cases flushing Unicast Forwarding Database can help: <code>/interface ethernet switch unicast-fdb flush</code>}} | {{Note | Some changes may take some time to take effect due to already learned MAC addreses. In such cases flushing Unicast Forwarding Database can help: <code>/interface ethernet switch unicast-fdb flush</code>}} | ||
{{ | {{Warning | Multiple hardware offloaded bridge configuration is designed as fast and simple port isolation solution, but it limits part of VLAN functionality supported by CRS switch-chip. | ||
For advanced configurations use one | For advanced configurations use one bridge within CRS switch chip for all ports, configure VLANs and isolate port groups with port isolation profile configuration.}} | ||
==Port Based VLAN== | |||
{{ Note | For CRS3xx series devices you must use bridge VLAN filtering, you can read more about it in the [[ Manual:Interface/Bridge#Bridge_VLAN_Filtering | Bridge VLAN Filtering]] section. }} | |||
=== | ===Example 1 (Trunk and Access ports)=== | ||
[[File:Port-Based.png|center|frame|alt=Alt text|Port Based VLAN 1]] | [[File:Port-Based.png|center|frame|alt=Alt text|Port Based VLAN 1]] | ||
Switch together the required ports: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 97: | Line 108: | ||
</pre> | </pre> | ||
Specify the VLAN ID that the switch must set on untagged (VLAN0) traffic for each access port: | |||
<pre> | <pre> | ||
/interface ethernet switch ingress-vlan-translation | /interface ethernet switch ingress-vlan-translation | ||
add ports=ether6 customer-vid=0 new-customer-vid=200 | add ports=ether6 customer-vid=0 new-customer-vid=200 | ||
add ports=ether7 customer-vid=0 new-customer-vid=300 | add ports=ether7 customer-vid=0 new-customer-vid=300 | ||
add ports=ether8 customer-vid=0 new-customer-vid=400 | add ports=ether8 customer-vid=0 new-customer-vid=400 | ||
</pre> | </pre> | ||
{{ Note | When an entry is created under <code>/interface ethernet switch ingress-vlan-translation</code>, then the switch chip will add a VLAN tag on ingress frames on the specified port. To remove the VLAN tag on the same port for egress frames, an <code>/interface ethernet switch egress-vlan-tag</code> entry should be created for the same VLAN ID where only tagged ports are specified. If specific VLAN is forwarded only between access ports, the <code>/interface ethernet switch egress-vlan-tag</code> entry should still be created without any tagged ports. Another option is to create extra entries under <code>/interface ethernet switch egress-vlan-translation</code> menu to set untagged (VLAN0) traffic.}} | |||
You must also specify which VLANs should be sent out the trunk port with a VLAN tag. Use the <var>tagged-ports</var> property to setup a trunk port: | |||
<pre> | <pre> | ||
/interface ethernet switch egress-vlan-tag | /interface ethernet switch egress-vlan-tag | ||
| Line 115: | Line 126: | ||
</pre> | </pre> | ||
Add entries to the VLAN table to specify VLAN memberships for each port and each VLAN ID: | |||
<pre> | <pre> | ||
/interface ethernet switch vlan | /interface ethernet switch vlan | ||
add ports=ether2,ether6 vlan-id=200 | add ports=ether2,ether6 vlan-id=200 | ||
add ports=ether2,ether7 vlan-id=300 | add ports=ether2,ether7 vlan-id=300 | ||
add ports=ether2,ether8 vlan-id=400 | add ports=ether2,ether8 vlan-id=400 | ||
</pre> | </pre> | ||
After valid VLAN configuration has been setup, you can enable unknown/invalid VLAN filtering: | |||
<pre> | <pre> | ||
/interface ethernet switch | /interface ethernet switch | ||
| Line 131: | Line 140: | ||
</pre> | </pre> | ||
{{ 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 time. You can find a configuration example in the [[Manual:CRS_Router | CRS-Router]] guide. }} | |||
===Example 2 (Trunk and Hybrid ports)=== | |||
[[File:Port-Based-e2.png|center|frame|alt=Alt text|Port Based VLAN 2]] | [[File:Port-Based-e2.png|center|frame|alt=Alt text|Port Based VLAN 2]] | ||
Switch together the required ports: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 156: | Line 157: | ||
</pre> | </pre> | ||
Specify the VLAN ID that the switch must set on untagged (VLAN0) traffic for each access port: | |||
<pre> | <pre> | ||
/interface ethernet switch ingress-vlan-translation | /interface ethernet switch ingress-vlan-translation | ||
add ports=ether6 customer-vid=0 new-customer-vid=200 | add ports=ether6 customer-vid=0 new-customer-vid=200 | ||
add ports=ether7 customer-vid=0 new-customer-vid=300 | add ports=ether7 customer-vid=0 new-customer-vid=300 | ||
add ports=ether8 customer-vid=0 new-customer-vid=400 | add ports=ether8 customer-vid=0 new-customer-vid=400 | ||
</pre> | </pre> | ||
By specifying ports as <var>tagged-ports</var>, the switch will always send out packets as tagged packets with the corresponding VLAN ID. Add appropriate entries according to the diagram above: | |||
<pre> | <pre> | ||
/interface ethernet switch egress-vlan-tag | /interface ethernet switch egress-vlan-tag | ||
| Line 174: | Line 173: | ||
</pre> | </pre> | ||
Add entries to the VLAN table to specify VLAN memberships for each port and each VLAN ID: | |||
<pre> | <pre> | ||
/interface ethernet switch vlan | /interface ethernet switch vlan | ||
| Line 183: | Line 181: | ||
</pre> | </pre> | ||
After valid VLAN configuration has been setup, you can enable unknown/invalid VLAN filtering: | |||
<pre> | <pre> | ||
/interface ethernet switch | /interface ethernet switch | ||
| Line 190: | Line 187: | ||
</pre> | </pre> | ||
==Protocol Based VLAN== | |||
[[File:Protocol-Based.png|center|frame|alt=Alt text|Protocol Based VLAN]] | [[File:Protocol-Based.png|center|frame|alt=Alt text|Protocol Based VLAN]] | ||
Switch together the required ports: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 215: | Line 202: | ||
</pre> | </pre> | ||
Set VLAN for IP and ARP protocols: | |||
<pre> | <pre> | ||
/interface ethernet switch protocol-based-vlan | /interface ethernet switch protocol-based-vlan | ||
| Line 225: | Line 211: | ||
</pre> | </pre> | ||
Set VLAN for IPX protocol: | |||
<pre> | <pre> | ||
/interface ethernet switch protocol-based-vlan | /interface ethernet switch protocol-based-vlan | ||
| Line 233: | Line 218: | ||
</pre> | </pre> | ||
Set VLAN for AppleTalk AARP and AppleTalk DDP protocols: | |||
<pre> | <pre> | ||
/interface ethernet switch protocol-based-vlan | /interface ethernet switch protocol-based-vlan | ||
| Line 243: | Line 227: | ||
</pre> | </pre> | ||
==MAC Based VLAN== | |||
{{ Warning | Internally all MAC addresses in MAC based VLANs are hashed, certain MAC addresses can have the same hash, which will prevent a MAC address being loaded in to the switch chip if the hash matches with a hash from a MAC address that has been already loaded, for this reason it is recommended to use Port bases VLANs in combination with MAC based VLANs. This is a hardware limitation. }} | |||
[[File:MAC-Based.png|center|frame|alt=Alt text|MAC Based VLAN]] | [[File:MAC-Based.png|center|frame|alt=Alt text|MAC Based VLAN]] | ||
Switch together the required ports: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 264: | Line 242: | ||
</pre> | </pre> | ||
Enable MAC based VLAN translation on access port: | |||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
| Line 271: | Line 248: | ||
</pre> | </pre> | ||
Add MAC-to-VLAN mapping entries in MAC based VLAN table: | |||
<pre> | <pre> | ||
/interface ethernet switch mac-based-vlan | /interface ethernet switch mac-based-vlan | ||
| Line 280: | Line 256: | ||
</pre> | </pre> | ||
Add VLAN200, VLAN300 and VLAN400 tagging on ether2 port to create it as VLAN trunk port: | |||
<pre> | <pre> | ||
/interface ethernet switch egress-vlan-tag | /interface ethernet switch egress-vlan-tag | ||
| Line 289: | Line 264: | ||
</pre> | </pre> | ||
Additionally, add entries to the VLAN table, specify VLAN membership for each port and enable unknown/invalid VLAN filtering, see an example below - [[ Manual:CRS1xx/2xx_series_switches_examples#Unknown.2FInvalid_VLAN_filtering | Unknown/Invalid VLAN filtering]]. This is required for network setups where more interfaces are added to the bridge, as it allows to define VLAN boundaries. | |||
==InterVLAN Routing== | |||
[[File:InterVLAN-Routing.png|center|frame|alt=Alt text|InterVLAN Routing]] | [[File:InterVLAN-Routing.png|center|frame|alt=Alt text|InterVLAN Routing]] | ||
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 DHCP server, Hotspot, PPP and other features for each VLAN | 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 DHCP server, Hotspot, PPP and other features for each VLAN. | ||
Switch together the required ports: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 316: | Line 283: | ||
</pre> | </pre> | ||
Set VLAN tagging on CPU port for all VLANs to make packets tagged before they are routed: | |||
<pre> | <pre> | ||
/interface ethernet switch egress-vlan-tag | /interface ethernet switch egress-vlan-tag | ||
| Line 323: | Line 289: | ||
add tagged-ports=switch1-cpu vlan-id=300 | add tagged-ports=switch1-cpu vlan-id=300 | ||
add tagged-ports=switch1-cpu vlan-id=400 | add tagged-ports=switch1-cpu vlan-id=400 | ||
</pre> | |||
add ingress VLAN translation rules to ensure that the correct VLAN ID assignment is done on access ports: | |||
<pre> | |||
/interface ethernet switch ingress-vlan-translation | /interface ethernet switch ingress-vlan-translation | ||
add ports=ether6 customer-vid=0 new-customer-vid=200 | add ports=ether6 customer-vid=0 new-customer-vid=200 | ||
add ports=ether7 customer-vid=0 new-customer-vid=300 | add ports=ether7 customer-vid=0 new-customer-vid=300 | ||
add ports=ether8 customer-vid=0 new-customer-vid=400 | add ports=ether8 customer-vid=0 new-customer-vid=400 | ||
</pre> | </pre> | ||
Create the VLAN interfaces on top of the bridge interface: | |||
<pre> | <pre> | ||
/interface vlan | /interface vlan | ||
add name= | add name=VLAN200 interface=bridge1 vlan-id=200 | ||
add name= | add name=VLAN300 interface=bridge1 vlan-id=300 | ||
add name= | add name=VLAN400 interface=bridge1 vlan-id=400 | ||
</pre> | |||
{{ 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 packet might not be received correctly and therefore routing might fail. More detailed information can be found in the [[ Manual:Layer2_misconfiguration#VLAN_interface_on_a_slave_interface | VLAN interface on a slave interface]] manual page. }} | |||
Add IP addresses to created the VLAN interfaces. In this example, three 192.168.x.1 addresses are added to VLAN200, VLAN300 and VLAN400 interfaces: | |||
<pre> | |||
/ip address | /ip address | ||
add address=192.168.20.1/24 interface= | add address=192.168.20.1/24 interface=VLAN200 | ||
add address=192.168.30.1/24 interface= | add address=192.168.30.1/24 interface=VLAN300 | ||
add address=192.168.40.1/24 interface= | add address=192.168.40.1/24 interface=VLAN400 | ||
</pre> | </pre> | ||
==Unknown/Invalid VLAN filtering== | |||
VLAN membership is defined in the VLAN table. Adding entries with VLAN ID and ports makes that VLAN traffic valid on those ports. After valid VLAN configuration has been setup, unknown/invalid VLAN filtering can be enabled. This VLAN filtering configuration example applies to [[#InterVLAN_Routing | InterVLAN Routing]] setup. | |||
<pre> | <pre> | ||
/interface ethernet switch vlan | /interface ethernet switch vlan | ||
add ports=switch1-cpu,ether6 vlan-id=200 | add ports=switch1-cpu,ether6 vlan-id=200 | ||
add ports=switch1-cpu,ether7 vlan-id=300 | add ports=switch1-cpu,ether7 vlan-id=300 | ||
add ports=switch1-cpu,ether8 vlan-id=400 | add ports=switch1-cpu,ether8 vlan-id=400 | ||
</pre> | </pre> | ||
* Option 1: disable invalid VLAN forwarding on specific ports: | * Option 1: disable invalid VLAN forwarding on specific ports (more common): | ||
<pre> | <pre> | ||
/interface ethernet switch | /interface ethernet switch | ||
| Line 363: | Line 334: | ||
* Option 2: disable invalid VLAN forwarding on all ports: | * Option 2: disable invalid VLAN forwarding on all ports: | ||
<pre> | <pre> | ||
/interface ethernet switch | /interface ethernet switch | ||
| Line 369: | Line 339: | ||
</pre> | </pre> | ||
{{ 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 port isolation feature should be used instead of using multiple bridges. }} | |||
==VLAN Tunneling (Q-in-Q)== | |||
This example covers typical VLAN tunneling use case where service provider devices add another VLAN tag for independent forwarding in the mean time allowing customers to use their own VLANs. | This example covers typical VLAN tunneling use case where service provider devices add another VLAN tag for independent forwarding in the mean time allowing customers to use their own VLANs. | ||
| Line 380: | Line 351: | ||
'''CRS-1''':The first switch on the edge of service provider network has to properly indentify traffic from customer VLAN id on port and assign new service VLAN id with ingress VLAN translation rules. <br /> | '''CRS-1''': The first switch on the edge of service provider network has to properly indentify traffic from customer VLAN id on port and assign new service VLAN id with ingress VLAN translation rules. <br /> | ||
<br /> | <br /> | ||
VLAN trunk port configuration for service provider VLAN tags is in the same ''egress-vlan-tag'' table. <br /> | VLAN trunk port configuration for service provider VLAN tags is in the same ''egress-vlan-tag'' table. <br /> | ||
<br /> | <br /> | ||
The main difference from basic [[#Port_Based_VLAN | Port Based VLAN]] configuration is that CRS switch-chip has | The main difference from basic [[#Port_Based_VLAN | Port Based VLAN]] configuration is that CRS switch-chip has to be set to do forwarding according to service (''outer'') VLAN id instead of customer (''inner'') VLAN id. | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether1 hw=yes | add bridge=bridge1 interface=ether1 hw=yes | ||
| Line 403: | Line 366: | ||
/interface ethernet switch ingress-vlan-translation | /interface ethernet switch ingress-vlan-translation | ||
add customer-vid=200 new-service-vid=400 ports=ether1 | add customer-vid=200 new-service-vid=400 ports=ether1 | ||
add customer-vid=300 new-service-vid=500 ports=ether2 | add customer-vid=300 new-service-vid=500 ports=ether2 | ||
/interface ethernet switch egress-vlan-tag | /interface ethernet switch egress-vlan-tag | ||
| Line 414: | Line 377: | ||
</pre> | </pre> | ||
'''CRS-2''': The second switch in the service provider network require only switched ports | '''CRS-2''': The second switch in the service provider network require only switched ports to do forwarding according to service (''outer'') VLAN id instead of customer (''inner'') VLAN id. | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether9 hw=yes | add bridge=bridge1 interface=ether9 hw=yes | ||
| Line 434: | Line 391: | ||
'''CRS-3''': The third switch has similar configuration to CRS-1: | '''CRS-3''': The third switch has similar configuration to CRS-1: | ||
* Ports in a switch group using | * Ports in a switch group using a bridge; | ||
* Ingress VLAN translation rules to define new service VLAN assingments on ports; | * Ingress VLAN translation rules to define new service VLAN assingments on ports; | ||
* <var>tagged-ports</var> for service provider VLAN trunks; | * <var>tagged-ports</var> for service provider VLAN trunks; | ||
* CRS switch-chip set to use service VLAN id in switching lookup. | * CRS switch-chip set to use service VLAN id in switching lookup. | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether3 hw=yes | add bridge=bridge1 interface=ether3 hw=yes | ||
| Line 455: | Line 405: | ||
/interface ethernet switch ingress-vlan-translation | /interface ethernet switch ingress-vlan-translation | ||
add customer-vid=200 new-service-vid=400 ports=ether3 | add customer-vid=200 new-service-vid=400 ports=ether3 | ||
add customer-vid=300 new-service-vid=500 ports=ether4 | add customer-vid=300 new-service-vid=500 ports=ether4 | ||
/interface ethernet switch egress-vlan-tag | /interface ethernet switch egress-vlan-tag | ||
| Line 466: | Line 416: | ||
</pre> | </pre> | ||
=== | ===CVID Stacking=== | ||
It is possible to use CRS1xx/CRS2xx series switches for CVID Stacking setups. CRS1xx/CRS2xx series switches are capable of VLAN filtering based on the outer tag of tagged packets that have two CVID tags (double CVID tag), these switches are also capable of adding another CVID tag on top of an existing CVID tag (CVID Stacking). For example, in a setup where '''ether1''' is receiving tagged packets with CVID 10, but it is required that '''ether2''' sends out these packets with another tag CVID 20 (VLAN10 inside VLAN20) while filtering out any other VLANs, the following must be configured: | |||
Switch together '''ether1''' and '''ether2''': | |||
<pre> | |||
/interface bridge | |||
add name=bridge1 | |||
/interface bridge port | |||
add bridge=bridge1 interface=ether1 hw=yes | |||
add bridge=bridge1 interface=ether2 hw=yes | |||
</pre> | |||
Set the switch to filter VLANs based on service tag (0x88a8): | |||
<pre> | |||
/interface ethernet switch | |||
set bridge-type=service-vid-used-as-lookup-vid | |||
</pre> | |||
Add a service tag SVID 20 to packets that have a CVID 10 tag on '''ether1''': | |||
<pre> | |||
/interface ethernet switch ingress-vlan-translation | |||
add customer-vid=10 new-service-vid=20 ports=ether1 | |||
</pre> | |||
Specify '''ether2''' as the tagged/trunk port for SVID 20: | |||
<pre> | |||
/interface ethernet switch egress-vlan-tag | |||
add tagged-ports=ether2 vlan-id=20 | |||
</pre> | |||
Allow '''ether1''' and '''ether2''' to forward SVID 20: | |||
<pre> | |||
/interface ethernet switch vlan | |||
add ports=ether1,ether2 vlan-id=20 | |||
</pre> | |||
Override the SVID EtherType (0x88a8) to CVID EtherType (0x8100) on '''ether2''': | |||
<pre> | |||
/interface ethernet switch port | |||
set ether2 egress-service-tpid-override=0x8100 ingress-service-tpid-override=0x8100 | |||
</pre> | |||
Enable unknown/invalid VLAN filtering: | |||
<pre> | |||
/interface ethernet switch | |||
set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether1,ether2 | |||
</pre> | |||
{{ Note | Since the switch is set to look up VLAN ID based on 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. }} | |||
=Mirroring= | |||
[[File:Mirroring.png|center|frame|alt=Alt text|Mirroring]] | [[File:Mirroring.png|center|frame|alt=Alt text|Mirroring]] | ||
| Line 472: | Line 473: | ||
The Cloud Router Switches support three types of mirroring. Port based mirroring can be applied to any of switch-chip ports, VLAN based mirroring works for all specified VLANs regardless switch-chip ports and MAC based mirroring copies traffic sent or received from specific device reachable from the port configured in Unicast Forwarding Database. | The Cloud Router Switches support three types of mirroring. Port based mirroring can be applied to any of switch-chip ports, VLAN based mirroring works for all specified VLANs regardless switch-chip ports and MAC based mirroring copies traffic sent or received from specific device reachable from the port configured in Unicast Forwarding Database. | ||
==Port Based Mirroring== | |||
The first configuration sets ether5 port as a mirror0 analyzer port for both ingress and egress mirroring, mirrored traffic will be sent to this port. Port based ingress and egress mirroring is enabled from ether6 port. | The first configuration sets ether5 port as a mirror0 analyzer port for both ingress and egress mirroring, mirrored traffic will be sent to this port. Port based ingress and egress mirroring is enabled from ether6 port. | ||
| Line 484: | Line 485: | ||
</pre> | </pre> | ||
==VLAN Based Mirroring== | |||
The second example requires ports to be switched in a group. Mirroring configuration sets ether5 port as a mirror0 analyzer port and sets 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 second example requires ports to be switched in a group. Mirroring configuration sets ether5 port as a mirror0 analyzer port and sets 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. | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 509: | Line 503: | ||
</pre> | </pre> | ||
==MAC Based Mirroring== | |||
The third configuration also requires ports to be switched in a group. Mirroring configuration sets ether5 port as a mirror0 analyzer port and sets mirror0 port to be used when mirroring from Unicast Forwarding database occurs. The entry from Unicast Forwarding database enables mirroring for packets with source or destination MAC address E7:16:34:A1:CD:18 from ether8 port. | The third configuration also requires ports to be switched in a group. Mirroring configuration sets ether5 port as a mirror0 analyzer port and sets mirror0 port to be used when mirroring from Unicast Forwarding database occurs. The entry from Unicast Forwarding database enables mirroring for packets with source or destination MAC address E7:16:34:A1:CD:18 from ether8 port. | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 534: | Line 521: | ||
</pre> | </pre> | ||
=Trunking= | |||
[[File:Trunking3.png|center|frame|alt=Alt text|Trunking]] | [[File:Trunking3.png|center|frame|alt=Alt text|Trunking]] | ||
| Line 540: | Line 527: | ||
The Trunking in the Cloud Router Switches provides static link aggregation groups with hardware automatic failover and load balancing. IEEE802.3ad and IEEE802.1ax compatible Link Aggregation Control Protocol is not supported yet. Up to 8 Trunk groups are supported with up to 8 Trunk member ports per Trunk group. | The Trunking in the Cloud Router Switches provides static link aggregation groups with hardware automatic failover and load balancing. IEEE802.3ad and IEEE802.1ax compatible Link Aggregation Control Protocol is not supported yet. Up to 8 Trunk groups are supported with up to 8 Trunk member ports per Trunk group. | ||
Configuration requires a group of switched ports and an entry in the Trunk table: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 protocol-mode=none | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 564: | Line 542: | ||
</pre> | </pre> | ||
This example also shows proper bonding configuration in RouterOS on the other end: | |||
<pre> | <pre> | ||
/interface bonding | /interface bonding | ||
| Line 573: | Line 550: | ||
{{ Note | You can find a working example for trunking and port based VLANs at [[Manual:CRS_VLANs_with_Trunks | CRS VLANs with Trunks]] page.}} | {{ Note | You can find a working example for trunking and port based VLANs at [[Manual:CRS_VLANs_with_Trunks | CRS VLANs with Trunks]] page.}} | ||
{{ Warning | Bridge (R)STP is not aware of underlying switch trunking configuration and some trunk ports can move to 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 [[Manual:CRS1xx/2xx_series_switches#Access_Control_List | ACL rules]]).}} | |||
=Limited MAC Access per Port= | |||
Disabling MAC learning and configuring static MAC addresses gives ability to control what exact devices can communicate to CRS1xx/2xx switches and through them. | Disabling MAC learning and configuring static MAC addresses gives ability to control what exact devices can communicate to CRS1xx/2xx switches and through them. | ||
Configuration requires a group of switched ports, disabled MAC learning on those ports and static UFDB entries | Configuration requires a group of switched ports, disabled MAC learning on those ports and static UFDB entries: | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
add bridge=bridge1 interface=ether6 hw=yes | add bridge=bridge1 interface=ether6 hw=yes learn=no unknown-unicast-flood=no | ||
add bridge=bridge1 interface=ether7 hw=yes | add bridge=bridge1 interface=ether7 hw=yes learn=no unknown-unicast-flood=no | ||
/interface ethernet switch unicast-fdb | /interface ethernet switch unicast-fdb | ||
add mac-address=4C:5E:0C:00:00:01 port=ether6 svl=yes | add mac-address=4C:5E:0C:00:00:01 port=ether6 svl=yes | ||
add mac-address=D4:CA:6D:00:00:02 port=ether7 svl=yes | add mac-address=D4:CA:6D:00:00:02 port=ether7 svl=yes | ||
/interface ethernet switch acl | |||
add action=drop src-mac-addr-state=sa-not-found src-ports=ether6,ether7 table=egress | |||
</pre> | </pre> | ||
CRS1xx/2xx switches also allow to learn one dynamic MAC per port to ensure only one end user device is connected no matter of its MAC address | CRS1xx/2xx switches also allow to learn one dynamic MAC per port to ensure only one end user device is connected no matter of its MAC address: | ||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
set ether6 learn-limit=1 | set ether6 learn-limit=1 | ||
| Line 628: | Line 581: | ||
</pre> | </pre> | ||
{{Note | Prior to RouterOS v6.42 MAC learning on ports was configured using property <var>learn-override</var> under <code>/interface ethernet switch port</code> menu.}} | |||
====Port Level Isolation | =Isolation= | ||
==Port Level Isolation== | |||
[[File:Port-level-Isolation.png|center|frame|alt=Alt text|Port Level Isolation]] | [[File:Port-level-Isolation.png|center|frame|alt=Alt text|Port Level Isolation]] | ||
| Line 645: | Line 600: | ||
* Community X (X <= 30) ports - Port-level isolation profile X | * Community X (X <= 30) ports - Port-level isolation profile X | ||
'''This example requires a group of switched ports. Assume that all ports used in this example are in one switch group | '''This example requires a group of switched ports. Assume that all ports used in this example are in one switch group.''' | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether2 hw=yes | add bridge=bridge1 interface=ether2 hw=yes | ||
| Line 670: | Line 613: | ||
</pre> | </pre> | ||
The first part of port isolation configuration is setting the Uplink port – set port profile to 0 for ether2 | The first part of port isolation configuration is setting the Uplink port – set port profile to 0 for ether2: | ||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
| Line 677: | Line 619: | ||
</pre> | </pre> | ||
Then continue with setting isolation profile 1 to all isolated ports and adding the communication port for port isolation profile 1 | Then continue with setting isolation profile 1 to all isolated ports and adding the communication port for port isolation profile 1: | ||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
| Line 688: | Line 629: | ||
</pre> | </pre> | ||
Configuration to set Community | Configuration to set Community 2 and Community 3 ports is similar: | ||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
| Line 697: | Line 637: | ||
/interface ethernet switch port-isolation | /interface ethernet switch port-isolation | ||
add port-profile=2 ports=ether2,ether7,ether8 type=dst | add port-profile=2 ports=ether2,ether7,ether8 type=dst | ||
/interface ethernet switch port | /interface ethernet switch port | ||
set ether9 isolation-leakage-profile-override=3 | set ether9 isolation-leakage-profile-override=3 | ||
| Line 708: | Line 646: | ||
</pre> | </pre> | ||
==Protocol Level Isolation== | |||
[[File:Protocol-level-Isolation.png|center|frame|alt=Alt text|Protocol Level Isolation]] | [[File:Protocol-level-Isolation.png|center|frame|alt=Alt text|Protocol Level Isolation]] | ||
| Line 715: | Line 653: | ||
The following example shows how to configure it on CRS. | The following example shows how to configure it on CRS. | ||
Switch together the required ports: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether1 hw=yes | add bridge=bridge1 interface=ether1 hw=yes | ||
| Line 738: | Line 665: | ||
</pre> | </pre> | ||
Set the same Community port profile for all DHCP client ports. Community port profile numbers are from 2 to 30. | |||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
| Line 748: | Line 674: | ||
</pre> | </pre> | ||
And configure port isolation/leakage profile for selected Community (2) to allow DHCP traffic destined only to port where the trusted DHCP server is located. <var>registration-status</var> and <var>traffic-type</var> properties have to be set empty in order to apply restriction only for DHCP protocol. | |||
<pre> | <pre> | ||
/interface ethernet switch port-isolation | /interface ethernet switch port-isolation | ||
| Line 756: | Line 681: | ||
</pre> | </pre> | ||
=Quality of Service (QoS)= | |||
<b>QoS configuration schemes</b> | <b>QoS configuration schemes</b> | ||
| Line 776: | Line 700: | ||
[QoS DSCP mapping] -> [Priority] -> [Queue] -> [Shaper] | [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. | In Strict Priority scheduling mode, the highest priority queue is served first. | ||
| Line 788: | Line 712: | ||
Note that CRS has maximum 8 queues per port. | Note that CRS has maximum 8 queues per port. | ||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether6 hw=yes | add bridge=bridge1 interface=ether6 hw=yes | ||
| Line 806: | Line 721: | ||
</pre> | </pre> | ||
Create QoS group for use in UFDB: | |||
<pre> | <pre> | ||
/interface ethernet switch qos-group | /interface ethernet switch qos-group | ||
| Line 812: | Line 727: | ||
</pre> | </pre> | ||
Add UFDB entries to match specific MACs on ether7 and apply QoS group1: | |||
<pre> | <pre> | ||
/interface ethernet switch unicast-fdb | /interface ethernet switch unicast-fdb | ||
| Line 818: | Line 733: | ||
add mac-address=E7:16:34:00:00:02 port=ether7 qos-group=group1 svl=yes | add mac-address=E7:16:34:00:00:02 port=ether7 qos-group=group1 svl=yes | ||
</pre> | </pre> | ||
Configure ether7 port queues to work according Strict Priority and QoS scheme only for destination address: | |||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
| Line 827: | Line 741: | ||
</pre> | </pre> | ||
==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];<br /> | The scheme where MAC based traffic shaping is done according to internal Priority would be following: [MAC address] -> [QoS Group] -> [Priority] -> [Queue] -> [Shaper];<br /> | ||
| Line 834: | Line 747: | ||
Note that CRS has maximum 8 queues per port. | Note that CRS has maximum 8 queues per port. | ||
Create a group of ports for switching: | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether6 hw=yes | add bridge=bridge1 interface=ether6 hw=yes | ||
| Line 852: | Line 757: | ||
</pre> | </pre> | ||
Create QoS group for use in UFDB: | |||
<pre> | <pre> | ||
/interface ethernet switch qos-group | /interface ethernet switch qos-group | ||
| Line 858: | Line 763: | ||
</pre> | </pre> | ||
Add UFDB entry to match specific MAC on ether8 and apply QoS group1: | |||
<pre> | <pre> | ||
/interface ethernet switch unicast-fdb | /interface ethernet switch unicast-fdb | ||
| Line 864: | Line 769: | ||
</pre> | </pre> | ||
Configure ether8 port queues to work according Strict Priority and QoS scheme only for destination address: | |||
<pre> | <pre> | ||
/interface ethernet switch port | /interface ethernet switch port | ||
| Line 872: | Line 777: | ||
</pre> | </pre> | ||
Apply bandwidth limit for queue1 on ether8: | |||
<pre> | <pre> | ||
/interface ethernet switch shaper | /interface ethernet switch shaper | ||
| Line 878: | Line 783: | ||
</pre> | </pre> | ||
If CRS switch supports Access Control List, this configuration | If CRS switch supports Access Control List, this configuration is simpler: | ||
<pre> | <pre> | ||
/interface ethernet switch acl policer | /interface ethernet switch acl policer | ||
| Line 887: | Line 792: | ||
</pre> | </pre> | ||
==VLAN based traffic scheduling + shaping using internal Priorities== | |||
Best practice is to assign lower internal QoS Priority for traffic limited by shaper to make it also less important in Strict Priority scheduler. | Best practice is to assign lower internal QoS Priority for traffic limited by shaper to make it also less important in Strict Priority scheduler. | ||
| Line 893: | Line 798: | ||
In this example:<br /> | In this example:<br /> | ||
VLAN10 -> QoS group0 = | Switch port ether6 is using shaper to limit the traffic that comes from ether7 and ether8.<br /> | ||
VLAN20 -> QoS group1 = normal | When link has reached its capacity, the traffic with the highest priority will be sent out first.<br /> | ||
VLAN30 -> QoS group2 = | VLAN10 -> QoS group0 = lowest priority<br /> | ||
VLAN20 -> QoS group1 = normal priority<br /> | |||
VLAN30 -> QoS group2 = highest priority<br /> | |||
<pre> | <pre> | ||
/interface bridge | /interface bridge | ||
add name=bridge1 | add name=bridge1 | ||
/interface bridge port | /interface bridge port | ||
add bridge=bridge1 interface=ether6 hw=yes | add bridge=bridge1 interface=ether6 hw=yes | ||
| Line 915: | Line 813: | ||
</pre> | </pre> | ||
Create QoS groups for use in VLAN table. | |||
<pre> | <pre> | ||
/interface ethernet switch qos-group | /interface ethernet switch qos-group | ||
| Line 923: | Line 821: | ||
</pre> | </pre> | ||
Add VLAN entries to apply QoS groups for certain VLANs. | |||
<pre> | <pre> | ||
/interface ethernet switch vlan | /interface ethernet switch vlan | ||
add ports=ether7,ether8 qos-group=group0 vlan-id=10 | add ports=ether6,ether7,ether8 qos-group=group0 vlan-id=10 | ||
add ports=ether7,ether8 qos-group=group1 vlan-id=20 | add ports=ether6,ether7,ether8 qos-group=group1 vlan-id=20 | ||
add ports=ether7,ether8 qos-group=group2 vlan-id=30 | add ports=ether6,ether7,ether8 qos-group=group2 vlan-id=30 | ||
</pre> | </pre> | ||
Configure ether6, ether7, ether8 port queues to work according Strict Priority and QoS scheme only for VLAN based QoS. | |||
<pre> | <pre> | ||
/interface ethernet switch port | /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\ | 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 \ | ity:0,strict-priority:0,strict-priority:0,strict-priority:0" priority-to-queue=0:0,1:1,2:2 \ | ||
| Line 942: | Line 843: | ||
</pre> | </pre> | ||
Apply bandwidth limit on ether6. | |||
<pre> | <pre> | ||
/interface ethernet switch shaper | /interface ethernet switch shaper | ||
add port= | add port=ether6 rate=10M | ||
</pre> | </pre> | ||
===Bandwidth Limiting | ==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 FIFO manner, but as soon as a queue is filled, then higher priority traffic can be sent out first. Lets 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 behaviour, switch together '''ether1''', '''ether2''' and '''ether3''' ports: | |||
<pre> | |||
/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=ether3 hw=yes | |||
</pre> | |||
Enable '''Strict Policy''' for each internal queue on each port: | |||
<pre> | |||
/interface ethernet switch port | |||
set ether1,ether2,ether3 per-queue-scheduling="strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0" | |||
</pre> | |||
Map each PCP value to an internal priority value, for convenience reasons simply map PCP to an internal priority 1-to-1: | |||
<pre> | |||
/interface ethernet switch port | |||
set ether1,ether2,ether3 pcp-based-qos-priority-mapping=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7 | |||
</pre> | |||
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: | |||
<pre> | |||
/interface ethernet switch port | |||
set ether1,ether2,ether3 priority-to-queue=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7 | |||
</pre> | |||
Finally, set each switch port to schedule packets based on the PCP value: | |||
<pre> | |||
/interface ethernet switch port | |||
set ether1,ether2,ether3 qos-scheme-precedence=pcp-based | |||
</pre> | |||
=Bandwidth Limiting= | |||
Both Ingress Port policer and Shaper provide bandwidth limiting features for CRS switches. | Both Ingress Port policer and Shaper provide bandwidth limiting features for CRS switches. | ||
| Line 967: | Line 904: | ||
</pre> | </pre> | ||
=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. | 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. | ||
| Line 985: | Line 922: | ||
</pre> | </pre> | ||
== | =See also= | ||
* [[Manual:CRS1xx/2xx_series_switches | CRS1xx/2xx series switches]] | |||
/ | * [[Manual:CRS_Router | CRS Router]] | ||
* [[Manual:CRS1xx/2xx_VLANs_with_Trunks | CRS1xx/2xx VLANs with Trunks]] | |||
/ | * [[Manual:Basic_VLAN_switching | Basic VLAN switching]] | ||
* [[Manual:Interface/Bridge#Bridge_Hardware_Offloading | Bridge Hardware Offloading]] | |||
* [[Manual:Interface/Bridge#Spanning_Tree_Protocol | Spanning Tree Protocol]] | |||
* | * [[Manual:Interface/Bridge#IGMP_Snooping | IGMP Snooping]] | ||
* [[Manual:Interface/Bridge#DHCP_Snooping_and_DHCP_Option_82 | DHCP Snooping and Option 82]] | |||
* [[M:Maximum_Transmission_Unit_on_RouterBoards | MTU on RouterBOARD]] | |||
[ | * [[Manual:Layer2_misconfiguration | Layer2 misconfiguration]] | ||
* [[Manual:Master-port | Master-port]] | |||
[ | |||
{{cont}} | {{cont}} | ||
[[Category: | [[Category:Bridging and switching]] | ||
[[Category: | [[Category:Examples]] | ||
Latest revision as of 10:02, 17 January 2022
Applies to RouterOS: v6.41 +
Warning: This manual is moved to [CRS1xx/2xx series switches examples]
Summary
Basic use cases and configuration examples for Cloud Router Switch features.
Warning: This article applies to CRS1xx and CRS2xx series switches and not to CRS3xx series switches. For CRS3xx series devices read the CRS3xx series switches manual.
Port switching
In order to setup port switching on CRS1xx/2xx series switches, check the Bridge Hardware Offloading page.
Warning: It is possible to create multiple isolated switch group 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.
Note: Port switching in RouterOS v6.41 and newer is done using the bridge configuration. Prior to RouterOS v6.41 port switching was done using the master-port property, for more details check the Master-port page.
Management access configuration
In general, switches are only supposed to forward packets by using the built-in switch chip, but not allow access to the device itself for security reasons. It is possible to use device's serial port for management access, but in most cases such an access method is not desired and access using an IP address is more suitable. In such cases you will need to configure management access.
In all types of management access it is assumed that ports must be switched together, use the following commands to switch together the required ports:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether3 hw=yes add bridge=bridge1 interface=ether4 hw=yes add bridge=bridge1 interface=ether5 hw=yes
You should also assign an IP address to the bridge interface so the device is reachable using an IP address (the device is also reachable using a MAC address):
/ip address add address=192.168.88.1/24 interface=bridge1
Untagged
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 broadcast type of traffic).
If you are intending to use invalid VLAN filtering (which you should), then ports, from which you are going to access the switch, must to be added to the VLAN table for untagged (VLAN 0) traffic, for example, in case you want to access the switch from ether2:
/interface ethernet switch vlan add vlan-id=0 ports=ether2,switch1-cpu
Tagged
Allowing only tagged traffic to have management access to the device through a specific port is a much better practice. For example, to allow only VLAN99 to access the device through ether2 you should first add an entry to the VLAN table, which will allow the selected port and the CPU port (switch1-cpu) to forward the selected VLAN ID, therefore allowing management access:
/interface ethernet switch vlan add ports=ether2,switch1-cpu vlan-id=99
Packets that will be sent out from the CPU, for example, ping replies will not have a VLAN tag, to solve this you need to specify which ports should always send out packets with a VLAN tag for a specific VLAN ID:
/interface ethernet switch egress-vlan-tag add tagged-ports=ether2,switch1-cpu vlan-id=99
After valid VLAN99 configuration has been setup, you can enable unknown/invalid VLAN filtering, which will not allow the management access through different ports than specified in the VLAN table:
/interface ethernet switch set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether2,ether3,ether4,ether5
In this example VLAN99 will be used to access the device, a VLAN interface on the bridge must be created and an IP address must be assigned to it.
/interface vlan add interface=bridge1 name=MGMT vlan-id=99 /ip address add address=192.168.99.1/24 interface=MGMT
VLAN
Note: It is recommended to get Serial Console cable and test 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 addreses. In such cases flushing Unicast Forwarding Database can help: /interface ethernet switch unicast-fdb flush
Warning: Multiple hardware offloaded bridge configuration is designed as fast and simple port isolation solution, but it limits part of VLAN functionality supported by CRS switch-chip. For advanced configurations use one bridge within CRS switch chip for all ports, configure VLANs and isolate port groups with port isolation profile configuration.
Port Based VLAN
Note: For CRS3xx series devices you must use bridge VLAN filtering, you can read more about it in the Bridge VLAN Filtering section.
Example 1 (Trunk and Access ports)
Switch together the required ports:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether6 hw=yes add bridge=bridge1 interface=ether7 hw=yes add bridge=bridge1 interface=ether8 hw=yes
Specify the VLAN ID that the switch must set on untagged (VLAN0) traffic for each access port:
/interface ethernet switch ingress-vlan-translation add ports=ether6 customer-vid=0 new-customer-vid=200 add ports=ether7 customer-vid=0 new-customer-vid=300 add ports=ether8 customer-vid=0 new-customer-vid=400
Note: When an entry is created under /interface ethernet switch ingress-vlan-translation, then the switch chip will add a VLAN tag on ingress frames on the specified port. To remove the VLAN tag on the same port for egress frames, an /interface ethernet switch egress-vlan-tag entry should be created for the same VLAN ID where only tagged ports are specified. If specific VLAN is forwarded only between access ports, the /interface ethernet switch egress-vlan-tag entry should still be created without any tagged ports. Another option is to create extra entries under /interface ethernet switch egress-vlan-translation menu to set untagged (VLAN0) traffic.
You must also specify which VLANs should be sent out the trunk port with a VLAN tag. Use the tagged-ports property to setup a trunk port:
/interface ethernet switch egress-vlan-tag add tagged-ports=ether2 vlan-id=200 add tagged-ports=ether2 vlan-id=300 add tagged-ports=ether2 vlan-id=400
Add entries to the VLAN table to specify VLAN memberships for each port and each VLAN ID:
/interface ethernet switch vlan add ports=ether2,ether6 vlan-id=200 add ports=ether2,ether7 vlan-id=300 add ports=ether2,ether8 vlan-id=400
After valid VLAN configuration has been setup, you can enable unknown/invalid VLAN filtering:
/interface ethernet switch set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether2,ether6,ether7,ether8
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 time. You can find a configuration example in the CRS-Router guide.
Example 2 (Trunk and Hybrid ports)
Switch together the required ports:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether6 hw=yes add bridge=bridge1 interface=ether7 hw=yes add bridge=bridge1 interface=ether8 hw=yes
Specify the VLAN ID that the switch must set on untagged (VLAN0) traffic for each access port:
/interface ethernet switch ingress-vlan-translation add ports=ether6 customer-vid=0 new-customer-vid=200 add ports=ether7 customer-vid=0 new-customer-vid=300 add ports=ether8 customer-vid=0 new-customer-vid=400
By specifying ports as tagged-ports, the switch will always send out packets as tagged packets with the corresponding VLAN ID. Add appropriate entries according to the diagram above:
/interface ethernet switch egress-vlan-tag add tagged-ports=ether2,ether7,ether8 vlan-id=200 add tagged-ports=ether2,ether6,ether8 vlan-id=300 add tagged-ports=ether2,ether6,ether7 vlan-id=400
Add entries to the VLAN table to specify VLAN memberships for each port and each VLAN ID:
/interface ethernet switch vlan add ports=ether2,ether6,ether7,ether8 vlan-id=200 learn=yes add ports=ether2,ether6,ether7,ether8 vlan-id=300 learn=yes add ports=ether2,ether6,ether7,ether8 vlan-id=400 learn=yes
After valid VLAN configuration has been setup, you can enable unknown/invalid VLAN filtering:
/interface ethernet switch set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether2,ether6,ether7,ether8
Protocol Based VLAN
Switch together the required ports:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether6 hw=yes add bridge=bridge1 interface=ether7 hw=yes add bridge=bridge1 interface=ether8 hw=yes
Set VLAN for IP and ARP protocols:
/interface ethernet switch protocol-based-vlan add port=ether2 protocol=arp set-customer-vid-for=all new-customer-vid=0 add port=ether6 protocol=arp set-customer-vid-for=all new-customer-vid=200 add port=ether2 protocol=ip set-customer-vid-for=all new-customer-vid=0 add port=ether6 protocol=ip set-customer-vid-for=all new-customer-vid=200
Set VLAN for IPX protocol:
/interface ethernet switch protocol-based-vlan add port=ether2 protocol=ipx set-customer-vid-for=all new-customer-vid=0 add port=ether7 protocol=ipx set-customer-vid-for=all new-customer-vid=300
Set VLAN for AppleTalk AARP and AppleTalk DDP protocols:
/interface ethernet switch protocol-based-vlan add port=ether2 protocol=0x80F3 set-customer-vid-for=all new-customer-vid=0 add port=ether8 protocol=0x80F3 set-customer-vid-for=all new-customer-vid=400 add port=ether2 protocol=0x809B set-customer-vid-for=all new-customer-vid=0 add port=ether8 protocol=0x809B set-customer-vid-for=all new-customer-vid=400
MAC Based VLAN
Warning: Internally all MAC addresses in MAC based VLANs are hashed, certain MAC addresses can have the same hash, which will prevent a MAC address being loaded in to the switch chip if the hash matches with a hash from a MAC address that has been already loaded, for this reason it is recommended to use Port bases VLANs in combination with MAC based VLANs. This is a hardware limitation.
Switch together the required ports:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether7 hw=yes
Enable MAC based VLAN translation on access port:
/interface ethernet switch port set ether7 allow-fdb-based-vlan-translate=yes
Add MAC-to-VLAN mapping entries in MAC based VLAN table:
/interface ethernet switch mac-based-vlan add src-mac=A4:12:6D:77:94:43 new-customer-vid=200 add src-mac=84:37:62:DF:04:20 new-customer-vid=300 add src-mac=E7:16:34:A1:CD:18 new-customer-vid=400
Add VLAN200, VLAN300 and VLAN400 tagging on ether2 port to create it as VLAN trunk port:
/interface ethernet switch egress-vlan-tag add tagged-ports=ether2 vlan-id=200 add tagged-ports=ether2 vlan-id=300 add tagged-ports=ether2 vlan-id=400
Additionally, add entries to the VLAN table, specify VLAN membership for each port and enable unknown/invalid VLAN filtering, see an example below - Unknown/Invalid VLAN filtering. This is required for network setups where more interfaces are added to the bridge, as it allows to define VLAN boundaries.
InterVLAN Routing
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 DHCP server, Hotspot, PPP and other features for each VLAN.
Switch together the required ports:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes 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 CPU port for all VLANs to make packets tagged before they are routed:
/interface ethernet switch egress-vlan-tag add tagged-ports=switch1-cpu vlan-id=200 add tagged-ports=switch1-cpu vlan-id=300 add tagged-ports=switch1-cpu vlan-id=400
add ingress VLAN translation rules to ensure that the correct VLAN ID assignment is done on access ports:
/interface ethernet switch ingress-vlan-translation add ports=ether6 customer-vid=0 new-customer-vid=200 add ports=ether7 customer-vid=0 new-customer-vid=300 add ports=ether8 customer-vid=0 new-customer-vid=400
Create the VLAN interfaces on top of the bridge interface:
/interface vlan add name=VLAN200 interface=bridge1 vlan-id=200 add name=VLAN300 interface=bridge1 vlan-id=300 add name=VLAN400 interface=bridge1 vlan-id=400
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 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.
Add IP addresses to created the VLAN interfaces. In this example, three 192.168.x.1 addresses are added to VLAN200, VLAN300 and VLAN400 interfaces:
/ip address add address=192.168.20.1/24 interface=VLAN200 add address=192.168.30.1/24 interface=VLAN300 add address=192.168.40.1/24 interface=VLAN400
Unknown/Invalid VLAN filtering
VLAN membership is defined in the VLAN table. Adding entries with VLAN ID and ports makes that VLAN traffic valid on those ports. After valid VLAN configuration has been setup, unknown/invalid VLAN filtering can be enabled. This VLAN filtering configuration example applies to InterVLAN Routing setup.
/interface ethernet switch vlan add ports=switch1-cpu,ether6 vlan-id=200 add ports=switch1-cpu,ether7 vlan-id=300 add ports=switch1-cpu,ether8 vlan-id=400
- Option 1: disable invalid VLAN forwarding on specific ports (more common):
/interface ethernet switch set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether2,ether6,ether7,ether8
- Option 2: disable invalid VLAN forwarding on all ports:
/interface ethernet switch set forward-unknown-vlan=no
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 port isolation feature should be used instead of using multiple bridges.
VLAN Tunneling (Q-in-Q)
This example covers typical VLAN tunneling use case where service provider devices add another VLAN tag for independent forwarding in the mean time allowing customers to use their own VLANs.
Note: This example contains only Service VLAN tagging part.
It is recommended to additionally set Unknown/Invalid VLAN filtering configuration on ports.
CRS-1: The first switch on the edge of service provider network has to properly indentify traffic from customer VLAN id on port and assign new service VLAN id with ingress VLAN translation rules.
VLAN trunk port configuration for service provider VLAN tags is in the same egress-vlan-tag table.
The main difference from basic Port Based VLAN configuration is that CRS switch-chip has to be set to do forwarding according to service (outer) VLAN id instead of customer (inner) VLAN id.
/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 only switched ports to do forwarding according to service (outer) VLAN id instead of customer (inner) VLAN id.
/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
CRS-3: The third switch has similar configuration to CRS-1:
- Ports in a switch group using a bridge;
- Ingress VLAN translation rules to define new service VLAN assingments on ports;
- tagged-ports for service provider VLAN trunks;
- CRS switch-chip set to use service VLAN id in switching lookup.
/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
CVID Stacking
It is possible to use CRS1xx/CRS2xx series switches for CVID Stacking setups. CRS1xx/CRS2xx series switches are capable of VLAN filtering based on the outer tag of tagged packets that have two CVID tags (double CVID tag), these switches are also capable of adding another CVID tag on top of an existing CVID tag (CVID Stacking). For example, in a setup where ether1 is receiving tagged packets with CVID 10, but it is required that ether2 sends out these packets with another tag CVID 20 (VLAN10 inside VLAN20) while filtering out any other VLANs, the following must be configured:
Switch together ether1 and ether2:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether1 hw=yes add bridge=bridge1 interface=ether2 hw=yes
Set the switch to filter VLANs based on service tag (0x88a8):
/interface ethernet switch set bridge-type=service-vid-used-as-lookup-vid
Add a service tag SVID 20 to packets that have a CVID 10 tag on ether1:
/interface ethernet switch ingress-vlan-translation add customer-vid=10 new-service-vid=20 ports=ether1
Specify ether2 as the tagged/trunk port for SVID 20:
/interface ethernet switch egress-vlan-tag add tagged-ports=ether2 vlan-id=20
Allow ether1 and ether2 to forward SVID 20:
/interface ethernet switch vlan add ports=ether1,ether2 vlan-id=20
Override the SVID EtherType (0x88a8) to CVID EtherType (0x8100) on ether2:
/interface ethernet switch port set ether2 egress-service-tpid-override=0x8100 ingress-service-tpid-override=0x8100
Enable unknown/invalid VLAN filtering:
/interface ethernet switch set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports=ether1,ether2
Note: Since the switch is set to look up VLAN ID based on 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.
Mirroring
The Cloud Router Switches support three types of mirroring. Port based mirroring can be applied to any of switch-chip ports, VLAN based mirroring works for all specified VLANs regardless switch-chip ports and MAC based mirroring copies traffic sent or received from specific device reachable from the port configured in Unicast Forwarding Database.
Port Based Mirroring
The first configuration sets ether5 port as a mirror0 analyzer port for both ingress and egress mirroring, mirrored traffic will be sent to this port. Port based ingress and egress mirroring is enabled from ether6 port.
/interface ethernet switch set ingress-mirror0=ether5 egress-mirror0=ether5 /interface ethernet switch port set ether6 ingress-mirror-to=mirror0 egress-mirror-to=mirror0
VLAN Based Mirroring
The second example requires ports to be switched in a group. Mirroring configuration sets ether5 port as a mirror0 analyzer port and sets 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.
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether7 hw=yes /interface ethernet switch set ingress-mirror0=ether5 vlan-uses=mirror0 /interface ethernet switch vlan add ports=ether2,ether7 vlan-id=300 learn=yes ingress-mirror=yes
MAC Based Mirroring
The third configuration also requires ports to be switched in a group. Mirroring configuration sets ether5 port as a mirror0 analyzer port and sets mirror0 port to be used when mirroring from Unicast Forwarding database occurs. The entry from Unicast Forwarding database enables mirroring for packets with source or destination MAC address E7:16:34:A1:CD:18 from ether8 port.
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether8 hw=yes /interface ethernet switch set ingress-mirror0=ether5 fdb-uses=mirror0 /interface ethernet switch unicast-fdb add port=ether8 mirror=yes svl=yes mac-address=E7:16:34:A1:CD:18
Trunking
The Trunking in the Cloud Router Switches provides static link aggregation groups with hardware automatic failover and load balancing. IEEE802.3ad and IEEE802.1ax compatible Link Aggregation Control Protocol is not supported yet. Up to 8 Trunk groups are supported with up to 8 Trunk member ports per Trunk group.
Configuration requires a group of switched ports and an entry in the Trunk table:
/interface bridge add name=bridge1 protocol-mode=none /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether6 hw=yes add bridge=bridge1 interface=ether7 hw=yes add bridge=bridge1 interface=ether8 hw=yes /interface ethernet switch trunk add name=trunk1 member-ports=ether6,ether7,ether8
This example also shows proper bonding configuration in RouterOS on the other end:
/interface bonding add name=bonding1 slaves=ether2,ether3,ether4 mode=balance-xor transmit-hash-policy=layer-2-and-3 \ link-monitoring=mii mii-interval=100ms
Note: You can find a working example for trunking and port based VLANs at CRS VLANs with Trunks page.
Warning: Bridge (R)STP is not aware of underlying switch trunking configuration and some trunk ports can move to 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).
Limited MAC Access per Port
Disabling MAC learning and configuring static MAC addresses gives ability to control what exact devices can communicate to CRS1xx/2xx switches and through them.
Configuration requires a group of switched ports, disabled MAC learning on those ports and static UFDB entries:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether6 hw=yes learn=no unknown-unicast-flood=no add bridge=bridge1 interface=ether7 hw=yes learn=no unknown-unicast-flood=no /interface ethernet switch unicast-fdb add mac-address=4C:5E:0C:00:00:01 port=ether6 svl=yes add mac-address=D4:CA:6D:00:00:02 port=ether7 svl=yes /interface ethernet switch acl add action=drop src-mac-addr-state=sa-not-found src-ports=ether6,ether7 table=egress
CRS1xx/2xx switches also allow to learn one dynamic MAC per port to ensure only one end user device is connected no matter of its MAC address:
/interface ethernet switch port set ether6 learn-limit=1 set ether7 learn-limit=1
Note: Prior to RouterOS v6.42 MAC learning on ports was configured using property learn-override under /interface ethernet switch port menu.
Isolation
Port Level Isolation
Port-level isolation is often used for Private VLAN, where:
- One or multiple uplink ports are shared among all users for accessing gateway or router.
- Port group Isolated Ports is for guest users. Communication is through the uplink ports only.
- Port group Community 0 is for department A. Communication is allowed between the group members and through uplink ports.
- Port group Community X is for department X. Communication is allowed between the group members and through uplink ports.
The Cloud Router Switches use port-level isolation profiles for Private VLAN implementation:
- Uplink ports – Port-level isolation profile 0
- Isolated ports – Port-level isolation profile 1
- Community 0 ports - Port-level isolation profile 2
- Community X (X <= 30) ports - Port-level isolation profile X
This example requires a group of switched ports. Assume that all ports used in this example are in one switch group.
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether6 hw=yes add bridge=bridge1 interface=ether7 hw=yes add bridge=bridge1 interface=ether8 hw=yes add bridge=bridge1 interface=ether9 hw=yes add bridge=bridge1 interface=ether10 hw=yes
The first part of port isolation configuration is setting the Uplink port – set port profile to 0 for ether2:
/interface ethernet switch port set ether2 isolation-leakage-profile-override=0
Then continue with setting isolation profile 1 to all isolated ports and adding the communication port for port isolation profile 1:
/interface ethernet switch port set ether5 isolation-leakage-profile-override=1 set ether6 isolation-leakage-profile-override=1 /interface ethernet switch port-isolation add port-profile=1 ports=ether2 type=dst
Configuration to set Community 2 and Community 3 ports is similar:
/interface ethernet switch port set ether7 isolation-leakage-profile-override=2 set ether8 isolation-leakage-profile-override=2 /interface ethernet switch port-isolation add port-profile=2 ports=ether2,ether7,ether8 type=dst /interface ethernet switch port set ether9 isolation-leakage-profile-override=3 set ether10 isolation-leakage-profile-override=3 /interface ethernet switch port-isolation add port-profile=3 ports=ether2,ether9,ether10 type=dst
Protocol Level Isolation
Protocol level isolation on CRS switches can be used to enchance network security. For example, restricting DHCP traffic between the users and allowing it only to trusted DHCP server port can prevent security risks like DHCP spoofing attack. The following example shows how to configure it on CRS.
Switch together the required ports:
/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=ether3 hw=yes add bridge=bridge1 interface=ether4 hw=yes add bridge=bridge1 interface=ether5 hw=yes
Set the same Community port profile for all DHCP client ports. Community port profile numbers are from 2 to 30.
/interface ethernet switch port set ether2 isolation-leakage-profile-override=2 set ether3 isolation-leakage-profile-override=2 set ether4 isolation-leakage-profile-override=2 set ether5 isolation-leakage-profile-override=2
And configure port isolation/leakage profile for selected Community (2) to allow DHCP traffic destined only to port where the trusted DHCP server is located. registration-status and traffic-type properties have to be set empty in order to apply restriction only for DHCP protocol.
/interface ethernet switch port-isolation add port-profile=2 protocol-type=dhcpv4 type=dst forwarding-type=bridged ports=ether1 \ registration-status="" traffic-type=""
Quality of Service (QoS)
QoS configuration schemes
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 transmited traffic on port ether7.
Note that CRS has maximum 8 queues per port.
/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 QoS group for use in UFDB:
/interface ethernet switch qos-group add name=group1 priority=1
Add UFDB entries to match specific MACs on ether7 and apply QoS group1:
/interface ethernet switch unicast-fdb add mac-address=E7:16:34:00:00:01 port=ether7 qos-group=group1 svl=yes add mac-address=E7:16:34:00:00:02 port=ether7 qos-group=group1 svl=yes
Configure ether7 port queues to work according Strict Priority and QoS scheme only for destination address:
/interface ethernet switch port
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 \
qos-scheme-precedence=da-based
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 maximum 8 queues per port.
Create a group of ports for switching:
/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 QoS group for use in UFDB:
/interface ethernet switch qos-group add name=group1 priority=1
Add UFDB entry to match specific MAC on ether8 and apply QoS group1:
/interface ethernet switch unicast-fdb add mac-address=E7:16:34:A1:CD:18 port=ether8 qos-group=group1 svl=yes
Configure ether8 port queues to work according Strict Priority and QoS scheme only for destination address:
/interface ethernet switch port
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 \
qos-scheme-precedence=da-based
Apply bandwidth limit for queue1 on ether8:
/interface ethernet switch shaper add port=ether8 rate=10M target=queue1
If CRS switch supports Access Control List, this configuration is simpler:
/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
Best practice is to assign lower internal QoS Priority for traffic limited by shaper to make it also less important in Strict Priority scheduler. (higher priority should be more important and unlimited)
In this example:
Switch port ether6 is using shaper to limit the traffic that comes from ether7 and ether8.
When 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
/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 QoS groups for use in VLAN table.
/interface ethernet switch qos-group add name=group0 priority=0 add name=group1 priority=1 add name=group2 priority=2
Add VLAN entries to apply QoS groups for certain VLANs.
/interface ethernet switch vlan add ports=ether6,ether7,ether8 qos-group=group0 vlan-id=10 add ports=ether6,ether7,ether8 qos-group=group1 vlan-id=20 add ports=ether6,ether7,ether8 qos-group=group2 vlan-id=30
Configure ether6, ether7, ether8 port queues to work according Strict Priority and QoS scheme only for VLAN based QoS.
/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
Apply bandwidth limit on ether6.
/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 in FIFO manner, but as soon as a queue is filled, then higher priority traffic can be sent out first. Lets 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 behaviour, switch together ether1, ether2 and ether3 ports:
/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=ether3 hw=yes
Enable Strict Policy for each internal queue on each port:
/interface ethernet switch port set ether1,ether2,ether3 per-queue-scheduling="strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0,strict-priority:0"
Map each PCP value to an internal priority value, for convenience reasons simply map PCP to an internal priority 1-to-1:
/interface ethernet switch port set ether1,ether2,ether3 pcp-based-qos-priority-mapping=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7
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:
/interface ethernet switch port set ether1,ether2,ether3 priority-to-queue=0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7
Finally, set each switch port to schedule packets based on the PCP value:
/interface ethernet switch port set ether1,ether2,ether3 qos-scheme-precedence=pcp-based
Bandwidth Limiting
Both Ingress Port policer and Shaper provide bandwidth limiting features for CRS switches.
- Ingress Port Policer sets RX limit on port:
/interface ethernet switch ingress-port-policer add port=ether5 meter-unit=bit rate=10M
- Shaper sets TX limit on port:
/interface ethernet switch shaper add port=ether5 meter-unit=bit rate=10M
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:
/interface ethernet switch ingress-port-policer add port=ether5 rate=500 meter-unit=packet packet-types=broadcast
- Example with multiple packet types which includes ARP and ND protocols and unregistered multicast traffic. Unregistered multicast is traffic which is not defined in Multicast Forwarding database.
/interface ethernet switch ingress-port-policer add port=ether5 rate=5k meter-unit=packet packet-types=broadcast,arp-or-nd,unregistered-multicast
See also
- CRS1xx/2xx series switches
- CRS Router
- CRS1xx/2xx VLANs with Trunks
- Basic VLAN switching
- Bridge Hardware Offloading
- Spanning Tree Protocol
- IGMP Snooping
- DHCP Snooping and Option 82
- MTU on RouterBOARD
- Layer2 misconfiguration
- Master-port
[ Top | Back to Content ]