Documentation
This document describes RouterOS, the operating system of MikroTik devices.
While the documentation is still being migrated, many additional articles are located in our old documentation portal..
[RouterOS] Pages Feed
Confluence Syndication Feed |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Switch Chip Features
Page edited by Guntis G. - "typos" IntroductionThere are several types of switch chips on Routerboards and they have different sets of features. Most of them (from now on "Other") have only the basic "Port Switching" feature, but there are a few with more features:
Notes
Cloud Router Switch (CRS) series devices have highly advanced switch chips built-in, they support a wide variety of features. For more details about switch chip capabilities on CRS1xx/CRS2xx series devices check the CRS1xx/CRS2xx series switches manual, for CRS3xx series devices check the CRS3xx, CRS5xx series switches, and CCR2116, CCR2216 routers manual.
The command-line configuration is under the switch menu. This menu contains a list of all switch chips present in the system and some sub-menus as well. [admin@MikroTik] > /interface ethernet switch print Flags: I - invalid # NAME TYPE MIRROR-SOURCE MIRROR-TARGET SWITCH-ALL-PORTS 0 switch1 Atheros-8327 none none 1 switch2 Atheros-8227 none none Depending on the switch type there can be different configuration capabilities available. FeaturesPort SwitchingTo set up port switching on non-CRS series devices, check the Bridge Hardware Offloading page. Port switching in RouterOS v6.41 and newer is done using the bridge configuration. Before RouterOS v6.41 port switching was done using the master-port property. Switch All Ports FeatureEther1 port on RB450G/RB435G/RB850Gx2 devices has a feature that allows it to be removed/added to the default switch group, this setting is available on the
Port MirroringPort mirroring lets the switch to copy all traffic that is going in and out of one port ( Sub-menu:
Sub-menu:
Sub-menu:
Sub-menu:
Port mirroring configuration example: /interface ethernet switch set switch1 mirror-source=ether2 mirror-target=ether3 If you set mirror-source as an Ethernet port for a device with at least two switch chips and these mirror-source ports are in a single bridge while mirror-target for both switch chips are set to send the packets to the CPU, then this will result in a loop, which can make your device inaccessible. Port SettingsProperties under this menu are used to configure VLAN switching and filtering options for switch chips that support a VLAN Table. These properties are only available to switch chips that have VLAN Table support, check the Switch Chip Features table to make sure your device supports such a feature. Ingress traffic is considered as traffic that is being sent IN a certain port, this port is sometimes called ingress port. Egress traffic is considered as traffic that is being sent OUT of a certain port, this port is sometimes called egress port. Distinguishing them is very important to properly set up VLAN filtering since some properties apply only to either ingress or egress traffic.
On QCA8337 and Atheros8327 switch chips, a default VLAN TableVLAN table specifies certain forwarding rules for packets that have a specific 802.1Q tag. Those rules are of higher priority than switch groups configured using the Bridge Hardware Offloading feature. Basically, the table contains entries that map specific VLAN tag IDs to a group of one or more ports. Packets with VLAN tags leave the switch chip through one or more ports that are set in the corresponding table entry. The exact logic that controls how packets with VLAN tags are treated is controlled by a VLAN ID based forwarding takes into account the MAC addresses dynamically learned or manually added in the host table. QCA8337 and Atheros8327 switch-chips also support Independent VLAN Learning (IVL) which does the learning based on both - MAC addresses and VLAN IDs, thus allowing the same MAC to be used in multiple VLANs. Packets without VLAN tag are treated just as if they had a VLAN tag with port
Devices with MT7621, MT7531, RTL8367, 88E6393X, 88E6191X, 88E6190 switch chips support HW offloaded vlan-filtering in RouterOS v7. VLAN-related configuration on the "/interface ethernet switch" menu is not available. VLAN Forwarding Both NOTES:
The tables above are meant for more advanced configurations and to double-check your understanding of how packets will be processed with each VLAN related property. Host TableThe host table represents switch chip's internal MAC address to port mapping. It can contain two kinds of entries: dynamic and static. Dynamic entries get added automatically, this is also called a learning process: when switch chip receives a packet from a certain port, it adds the packet's source MAC address and port it received the packet from to the host table, so when a packet comes in with the same destination MAC address, it knows to which port it should forward the packet. If the destination MAC address is not present in the host table (so-called unknown-unicast traffic) then it forwards the packet to all ports in the group. Dynamic entries take about 5 minutes to time out. Learning is enabled only on ports that are configured as part of the switch group, so you won't see dynamic entries if you have not set up port switching. Also, you can add static entries that take over dynamic if a dynamic entry with the same MAC address already exists. Since port switching is configured using a bridge with hardware offloading, any static entries created on one table (either bridge host or switch host) will appear on the opposite table as a dynamic entry. Adding a static entry on the switch host table will provide access to some more functionality that is controlled via the following params:
Every switch chip has a finite number of MAC addresses it can store on the chip, see the Introduction table for a specific host table size. Once a host table is full, different techniques can be utilized to cope with the situation, for example, the switch can remove older entries to free space for more recent MAC addresses (used on QCA-8337 and Atheros-8327 switch chips), another option is to simply ignore the new MAC addresses and only remove entries after a timeout has passed (used on Atheros8316, Atheros8227, Atheros-7240, ICPlus175D and Realtek-RTL8367 switch chips), the last option is a combination of the previous two - only allow a certain amount of entries to be renewed and keep the other host portion intact till the timeout (used on MediaTek-MT7621, MT7531 switch chip). These techniques cannot be changed with configuration. For Atheros8316, Atheros8227 and Atheros-7240 switch chips, the switch-cpu port will always participate in the host learning process when at least one hardware offloaded bridge port is active on the switching group. It will cause the switch-cpu port to learn MAC addresses from non-HW offloaded interfaces. This might cause packet loss when a single bridge contains HW and non-HW offloaded interfaces. Also, packet loss might appear when a duplicate MAC address is used on the same switching group regardless if hosts are located on different logical networks. It is recommended to use HW offloading only when all bridge ports can use HW offloaded or keep it disabled on all switch ports when one or more bridge ports cannot be configured with HW offloading. Rule TableRule table is a very powerful tool allowing wire-speed packet filtering, forwarding and VLAN tagging based on L2, L3 and L4 protocol header field conditions. The menu contains an ordered list of rules just like in Each rule contains a conditions part and an action part. The action part is controlled by the following parameters:
The conditions part is controlled by the rest of the parameters:
IPv4 and IPv6 specific conditions cannot be present in the same rule. Because the rule table is processed entirely in switch chips hardware, there is a limitation to how many rules you may have. Depending on the number of conditions (MAC layer, IP layer, IPv6, L4 layer) you use in your rules, the number of active rules may vary from 8 to 32 for Atheros8316 switch chip, from 24 to 96 for Atheros8327/QCA8337 switch chip and from 42 to 256 for 88E6393X switch chip. You can always do Port isolationPort isolation provides the possibility to divide (isolate) certain parts of your network, this might be useful when you need to make sure that certain devices cannot access other devices, this can be done by isolating switch ports. Port isolation only works between ports that are members of the same switch. Switch port isolation is available on all switch chips since RouterOS v6.43.
(R/M)STP will only work properly in PVLAN setups, (R/M)STP will not work properly in setups, where there are multiple isolated switch groups, because switch groups might not properly receive BPDUs and therefore fail to detect network loops. The Switch chips with a VLAN table support (QCA8337, Atheros8327, Atheros8316, Atheros8227 and Atheros7240) can override the port isolation configuration when enabling a VLAN lookup on the switch port (the Private VLANIn some scenarios, you might need to forward all traffic to an uplink port while all other ports are isolated from each other. This kind of setup is called Private VLAN configuration, the Switch will forward all Ethernet frames directly to the uplink port allowing the Router to filter unwanted packets and limit access between devices that are behind switch ports. To configure switch port isolation, you need to switch all required ports: /interface bridge add name=bridge1 /interface bridge port add interface=sfp1 bridge=bridge1 hw=yes add interface=ether1 bridge=bridge1 hw=yes add interface=ether2 bridge=bridge1 hw=yes add interface=ether3 bridge=bridge1 hw=yes By default, the bridge interface is configured with Override the egress port for each switch port that needs to be isolated (excluding the uplink port): /interface ethernet switch port-isolation set ether1 forwarding-override=sfp1 set ether2 forwarding-override=sfp1 set ether3 forwarding-override=sfp1 It is possible to set multiple uplink ports for a single switch chip, this can be done by specifying multiple interfaces and separating them with a comma. Isolated switch groupsIn some scenarios you might need to isolate a group of devices from other groups, this can be done using the switch port isolation feature. This is useful when you have multiple networks but you want to use a single switch, with port isolation you can allow certain switch ports to be able to communicate through only a set of switch ports. In this example, devices on ether1-3 will only be able to communicate with devices that are on ether1-3, while devices on ether4-5 will only be able to communicate with devices on ether4-5 (ether1-3 is not able to communicate with ether4-5) Port isolation is only available between ports that are members of the same switch. To configure isolated switch groups you must first switch all ports: /interface bridge add name=bridge /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 By default, the bridge interface is configured with Then specify in the /interface ethernet switch port-isolation set ether1 forwarding-override=ether2,ether3 set ether2 forwarding-override=ether1,ether3 set ether3 forwarding-override=ether1,ether2 To create an isolated switch group for B devices: /interface ethernet switch port-isolation set ether4 forwarding-override=ether5 set ether5 forwarding-override=ether4 CPU Flow ControlAll switch chips have a special port that is called switchX-cpu, this is the CPU port for a switch chip, it is meant to forward traffic from a switch chip to the CPU, such a port is required for management traffic and routing features. By default the switch chip ensures that this special CPU port is not congested and sends out Pause Frames when link capacity is exceeded to make sure the port is not oversaturated, this feature is called CPU Flow Control. Without this feature packets that might be crucial for routing or management purposes might get dropped. Since RouterOS v6.43 it is possible to disable the CPU Flow Control feature on some devices that are using one of the following switch chips: Atheros8227, QCA8337, Atheros8327, Atheros7240 or Atheros8316. Other switch chips have this feature enabled by default and cannot be changed. To disable CPU Flow Control use the following command: /interface ethernet switch set switch1 cpu-flow-control=no StatisticsSome switch chips are capable of reporting statistics, this can be useful to monitor how many packets are sent to the CPU from the built-in switch chip. These statistics can also be used to monitor CPU Flow Control. You can find an example of the switch chip's statistics below: [admin@MikroTik] > /interface ethernet switch print stats name: switch1 driver-rx-byte: 221 369 701 driver-rx-packet: 1 802 975 driver-tx-byte: 42 621 969 driver-tx-packet: 310 485 rx-bytes: 414 588 529 rx-packet: 2 851 236 rx-too-short: 0 rx-too-long: 0 rx-broadcast: 1 040 309 rx-pause: 0 rx-multicast: 486 321 rx-fcs-error: 0 rx-align-error: 0 rx-fragment: 0 rx-control: 0 rx-unknown-op: 0 rx-length-error: 0 rx-code-error: 0 rx-carrier-error: 0 rx-jabber: 0 rx-drop: 0 tx-bytes: 44 071 621 tx-packet: 312 597 tx-too-short: 0 tx-too-long: 8 397 tx-broadcast: 2 518 tx-pause: 2 112 tx-multicast: 7 142 tx-excessive-collision: 0 tx-multiple-collision: 0 tx-single-collision: 0 tx-excessive-deferred: 0 tx-deferred: 0 tx-late-collision: 0 tx-total-collision: 0 tx-drop: 0 tx-jabber: 0 tx-fcs-error: 0 tx-control: 2 112 tx-fragment: 0 tx-rx-64: 6 646 tx-rx-65-127: 1 509 891 tx-rx-128-255: 1 458 299 tx-rx-256-511: 178 975 tx-rx-512-1023: 953 tx-rx-1024-1518: 672 tx-rx-1519-max: 0 Some devices have multiple CPU cores that are directly connected to a built-in switch chip using separate data lanes. These devices can report which data lane was used to forward the packet from or to the CPU port from the switch chip. For such devices an extra line is added for each row, the first line represents data that was sent using the first data lane, the second line represents data that was sent using the second data line, and so on. You can find an example of the switch chip's statistics for a device with multiple data lanes connecting the CPU and the built-in switch chip: [admin@MikroTik] > /interface ethernet switch print stats name: switch1 driver-rx-byte: 226 411 248 0 driver-rx-packet: 1 854 971 0 driver-tx-byte: 45 988 067 0 driver-tx-packet: 345 282 0 rx-bytes: 233 636 763 0 rx-packet: 1 855 018 0 rx-too-short: 0 0 rx-too-long: 0 0 rx-pause: 0 0 rx-fcs-error: 0 0 rx-overflow: 0 0 tx-bytes: 47 433 203 0 tx-packet: 345 282 0 tx-total-collision: 0 0 Setup ExamplesMake sure you have added all needed interfaces to the VLAN table when using secure 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 Switch-Router guide. When allowing access to the CPU, you are allowing access from a certain port to the actual router/switch, this is not always desirable. Make sure you implement proper firewall filter rules to secure your device when access to the CPU is allowed from a certain VLAN ID and port, use firewall filter rules to allow access to only certain services. Devices with MT7621, MT7531, RTL8367, 88E6393X, 88E6191X, 88E6190 switch chips support HW offloaded vlan-filtering in RouterOS v7. VLAN-related configuration on the "/interface ethernet switch" menu is not available. VLAN Example 1 (Trunk and Access Ports)RouterBOARDs with Atheros switch chips can be used for 802.1Q Trunking. This feature in RouterOS v6 is supported by QCA8337, Atheros8316, Atheros8327, Atheros8227 and Atheros7240 switch chips. In this example, ether3, ether4, and ether5 interfaces are access ports, while ether2 is a trunk port. VLAN IDs for each access port: ether3 - 400, ether4 - 300, ether5 - 200. 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 By default, the bridge interface is configured with Add VLAN table entries to allow frames with specific VLAN IDs between ports: /interface ethernet switch vlan add ports=ether2,ether3 switch=switch1 vlan-id=200 add ports=ether2,ether4 switch=switch1 vlan-id=300 add ports=ether2,ether5 switch=switch1 vlan-id=400 Assign /interface ethernet switch port set ether2 vlan-mode=secure vlan-header=add-if-missing set ether3 vlan-mode=secure vlan-header=always-strip default-vlan-id=200 set ether4 vlan-mode=secure vlan-header=always-strip default-vlan-id=300 set ether5 vlan-mode=secure vlan-header=always-strip default-vlan-id=400
On QCA8337 and Atheros8327 switch chips, a default VLAN Example 2 (Trunk and Hybrid Ports)VLAN Hybrid ports can forward both tagged and untagged traffic. This configuration is supported only by some Gigabit switch chips (QCA8337, Atheros8327). 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 By default, the bridge interface is configured with Add VLAN table entries to allow frames with specific VLAN IDs between ports. /interface ethernet switch vlan add ports=ether2,ether3,ether4,ether5 switch=switch1 vlan-id=200 add ports=ether2,ether3,ether4,ether5 switch=switch1 vlan-id=300 add ports=ether2,ether3,ether4,ether5 switch=switch1 vlan-id=400 In the switch port menu set /interface ethernet switch port set ether2 vlan-mode=secure vlan-header=leave-as-is set ether3 vlan-mode=secure vlan-header=leave-as-is default-vlan-id=200 set ether4 vlan-mode=secure vlan-header=leave-as-is default-vlan-id=300 set ether5 vlan-mode=secure vlan-header=leave-as-is default-vlan-id=400
Management access configurationIn these examples, there will be shown examples for multiple scenarios, but each of these scenarios requires you to have switched ports. Below you can find how to switch multiple ports: /interface bridge add name=bridge1 /interface bridge port add interface=ether1 bridge=bridge1 hw=yes add interface=ether2 bridge=bridge1 hw=yes By default, the bridge interface is configured with In these examples, it will be assumed that ether1 is the trunk port and ether2 is the access port, for configuration as the following: /interface ethernet switch port set ether1 vlan-header=add-if-missing set ether2 default-vlan-id=100 vlan-header=always-strip /interface ethernet switch vlan add ports=ether1,ether2,switch1-cpu switch=switch1 vlan-id=100 TaggedTo make the device accessible only from a certain VLAN, you need to create a new VLAN interface on the bridge interface and assign an IP address to it: /interface vlan add name=MGMT vlan-id=99 interface=bridge1 /ip address add address=192.168.99.1/24 interface=MGMT Specify from which interfaces it is allowed to access the device: /interface ethernet switch vlan add ports=ether1,switch1-cpu switch=switch1 vlan-id=99 Only specify trunk ports in this VLAN table entry, it is not possible to allow access to the CPU with tagged traffic through an access port since the access port will tag all ingress traffic with the specified When the VLAN table is configured, you can enable /interface ethernet switch port set ether1 vlan-header=add-if-missing vlan-mode=secure set ether2 default-vlan-id=100 vlan-header=always-strip vlan-mode=secure set switch1-cpu vlan-header=leave-as-is vlan-mode=secure UntaggedTo make the device accessible from the access port, create a VLAN interface with the same VLAN ID as set in /interface vlan add name=VLAN100 vlan-id=100 interface=bridge1 /ip address add address=192.168.100.1/24 interface=VLAN100 Specify which access (untagged) ports are allowed to access the CPU: /interface ethernet switch vlan add ports=ether1,ether2,switch1-cpu switch=switch1 vlan-id=100 Most commonly an access (untagged) port is accompanied by a trunk (tagged) port. In case of untagged access to the CPU, you are forced to specify both the access port and the trunk port, this gives access to the CPU from the trunk port as well. Not always this is desired and a Firewall might be required on top of VLAN filtering. When the VLAN table is configured, you can enable /interface ethernet switch port set ether1 vlan-header=add-if-missing vlan-mode=secure set ether2 default-vlan-id=100 vlan-header=always-strip vlan-mode=secure set switch1-cpu vlan-header=leave-as-is vlan-mode=secure To setup the management port using untagged traffic on a device with the Atheros7240 switch chip, you will need to set Untagged from tagged portIt is possible to allow access to the device from the trunk (tagged) port with untagged traffic. To do so, assign an IP address on the bridge interface: /ip address add address=10.0.0.1/24 interface=bridge1 Specify which ports are allowed to access the CPU. Use /interface ethernet switch vlan add ports=ether1,switch1-cpu switch=switch1 vlan-id=1 When the VLAN table is configured, you can enable /interface ethernet switch port set ether1 default-vlan-id=1 vlan-header=add-if-missing vlan-mode=secure set switch1-cpu default-vlan-id=1 vlan-header=leave-as-is vlan-mode=secure
This configuration example is not possible for devices with the Atheros8316 and Atheros7240 switch chips. For devices with QCA8337 and Atheros8327 switch chips, it is possible to use any other Inter-VLAN routingMany MikroTik's devices come with a built-in switch chip that can be used to greatly improve overall throughput when configured properly. Devices with a switch chip can be used as a router and a switch at the same time, this gives you the possibility to use a single device instead of multiple devices for your network. For this type of setup to work, you must switch all required ports together /interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether3 hw=yes Create a VLAN interface for each VLAN ID and assign an IP address to it: /interface vlan add interface=bridge1 name=VLAN10 vlan-id=10 add interface=bridge1 name=VLAN20 vlan-id=20 /ip address add address=192.168.10.1/24 interface=VLAN10 add address=192.168.20.1/24 interface=VLAN20 Setup a DHCP Server for each VLAN: /ip pool add name=POOL10 ranges=192.168.10.100-192.168.10.200 add name=POOL20 ranges=192.168.20.100-192.168.20.200 /ip dhcp-server add address-pool=POOL10 disabled=no interface=VLAN10 name=DHCP10 add address-pool=POOL20 disabled=no interface=VLAN20 name=DHCP20 /ip dhcp-server network add address=192.168.10.0/24 dns-server=8.8.8.8 gateway=192.168.10.1 add address=192.168.20.0/24 dns-server=8.8.8.8 gateway=192.168.20.1 Enable NAT on the device: /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 Add each port to the VLAN table and allow these ports to access the CPU to make DHCP and routing work: /interface ethernet switch vlan add independent-learning=yes ports=ether2,switch1-cpu switch=switch1 vlan-id=10 add independent-learning=yes ports=ether3,switch1-cpu switch=switch1 vlan-id=20 Specify each port to be an access port, and enable secure VLAN mode on each port and on the switch1-cpu port: /interface ethernet switch port set ether2 default-vlan-id=10 vlan-header=always-strip vlan-mode=secure set ether3 default-vlan-id=20 vlan-header=always-strip vlan-mode=secure set switch1-cpu vlan-mode=secure On QCA8337 and Atheros8327 switch chips, a default If your device has a switch rule table, then you can limit access between VLANs on a hardware level. As soon as you add an IP address on the VLAN interface you enable inter-VLAN routing, but this can be limited on a hardware level while preserving DHCP Server and other router-related services. To do so, use these ACL rules. With this type of configuration, you can achieve isolated port groups using VLANs. /interface ethernet switch rule add dst-address=192.168.20.0/24 new-dst-ports="" ports=ether2 switch=switch1 add dst-address=192.168.10.0/24 new-dst-ports="" ports=ether3 switch=switch1 See also |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Quality of Service (QoS)
Page edited by Guntis G. - "formatting" OverviewThis document defines Quality of Service (QoS) usage in RouterOS based on Marvell Prestera DX switch chips (CRS3xx, CRS5xx series switches, and CCR2116, CCR2216 routers). QoS is a set of features in network switches that allow network administrators to prioritize traffic and allocate network resources to ensure that important data flows smoothly and with low latency. The primary function of QoS in network switches is to manage network traffic in a way that meets the specific requirements of different types of network applications. For example, voice and video data require low latency and minimal packet loss to ensure high-quality communication, while file transfers and other data applications can tolerate higher levels of latency and packet loss. QoS works by identifying the type of traffic flowing through the switch and assigning it a priority level based on its requirements. The switch can then use this information to alter packet headers and prioritize the flow of traffic, ensuring that higher-priority traffic is given preferential treatment over lower-priority traffic. The current implementation is for QoS Phase 1 - QoS Marking (introduced in RouterOS v7.10). Planned QoS implementation phases:
QoS TerminologyThese terms will be used throughout the article.
Basic Configuration ExampleIn this example, we define just one QoS level - VoIP (IP Telephony) on top of the standard "Best Effort" class. Let's imagine that we have a CRS326-24G-2S+ device where:
First, we need to define QoS profiles. Defined /interface ethernet switch qos profile add dscp=46 name=voip pcp=5 Port-based QoS profile assignment on dedicated ports for IP phones applies to ingress traffic. Other Ethernet ports will use the default /interface ethernet switch port set ether1 qos-profile=voip set ether2 qos-profile=voip set ether3 qos-profile=voip set ether4 qos-profile=voip set ether5 qos-profile=voip set ether6 qos-profile=voip set ether7 qos-profile=voip set ether8 qos-profile=voip set ether9 qos-profile=voip The trunk port receives both types of QoS traffic. We need to create VLAN priority mapping with the QoS profile and enable /interface ethernet switch qos map vlan add pcp=5 qos-profile=voip /interface ethernet switch port set sfp-sfpplus1 qos-trust-l2=trust Finally, enable QoS hardware offloading for the above settings to start working: /interface ethernet switch set switch1 qos-hw-offloading=yes It is possible to verify the port QoS profile and Layer2, and Layer3 trust settings with [admin@MikroTik] /interface/ethernet/switch/port print qos Columns: NAME, SWITCH, QOS-PROFILE, QOS-MAP, QOS-TRUST-L2, QOS-TRUST-L3 # NAME SWITCH QOS-PROFILE QOS-MAP QOS-TRUST-L2 QOS-TRUST-L3 0 ether1 switch1 voip default ignore ignore 1 ether2 switch1 voip default ignore ignore 2 ether3 switch1 voip default ignore ignore 3 ether4 switch1 voip default ignore ignore 4 ether5 switch1 voip default ignore ignore 5 ether6 switch1 voip default ignore ignore 6 ether7 switch1 voip default ignore ignore 7 ether8 switch1 voip default ignore ignore 8 ether9 switch1 voip default ignore ignore 9 ether10 switch1 default default ignore ignore 10 ether11 switch1 default default ignore ignore 11 ether12 switch1 default default ignore ignore 12 ether13 switch1 default default ignore ignore 13 ether14 switch1 default default ignore ignore 14 ether15 switch1 default default ignore ignore 15 ether16 switch1 default default ignore ignore 16 ether17 switch1 default default ignore ignore 17 ether18 switch1 default default ignore ignore 18 ether19 switch1 default default ignore ignore 19 ether20 switch1 default default ignore ignore 20 ether21 switch1 default default ignore ignore 21 ether22 switch1 default default ignore ignore 22 ether23 switch1 default default ignore ignore 23 ether24 switch1 default default ignore ignore 24 sfp-sfpplus1 switch1 default default trust ignore 25 sfp-sfpplus2 switch1 default default ignore ignore 26 switch1-cpu switch1 Now incoming packets on ports ether1-ether9 are marked with a Priority Code Point (PCP) value of 5 and a Differentiated Services Code Point (DSCP) value of 46, and incoming packets on ports ether10-ether24 are marked with PCP and DSCP values of 0. When packets are incoming to sfp-sfpplus1 port, any packets with a PCP value of 5 or higher will retain their PCP value of 5 and DSCP value of 46, while all other packets will be marked with PCP and DSCP values of 0. Understanding Map rangesTo avoid the need to define all possible PCP and DSCP mappings, RouterOS allows setting the minimal PCP and DSCP values for QoS Profile mapping. In the following example, PCP values 0-2 use the default QoS profile, 3-4 - streaming, 5 - voip, and 6-7 - control. /interface ethernet switch qos map vlan add pcp=3 qos-profile=streaming add pcp=5 qos-profile=voip add pcp=6 qos-profile=control Since the /interface ethernet switch qos map vlan add pcp=5 qos-profile=voip add pcp=6 qos-profile=default Understanding Port, Profile and Map relationEach switch port has Layer2 and Layer3 trust settings, that will change how ingress packets are classified into QoS profiles and what PCP and DSCP values will be used. Below are tables that describe all possible options:
1 applies only when ingress traffic is untagged, but the egress needs to be VLAN-tagged. Property ReferenceSwitch settingsSub-menu: Switch QoS settings (in addition to the existing ones).
Port settingsSub-menu: Switch port settings (in addition to the existing ones). Assigns a QoS profile to ingress packets on the given port. The assigned profile can be changed via match rules if the port is considered trusted. By default, ports are untrusted and receive the default QoS profile (Best-Effort, PCP=0, DSCP=0), where priority fields are cleared from the egress packets.
L3 trust mode has higher precedence than L2 unless Forwarded/routed packets obtain priority field values (PCP, DSCP) from the selected QoS profile, overwriting the original values, unless the respective trust mode is set to keep. Commands (in addition to the existing ones).
QoS SettingsSub-menu: Almost the entire QoS HW configuration is located under All QoS entries have two major flags:
QoS ProfileSub-menu: QoS profiles determine priority field values (PCP, DSCP) for the forwarded/routed packets. Congestion avoidance/resolution is based on QoS profiles. Each packet gets a QoS profile assigned based on the ingress switch port QoS settings (see
QoS MappingSub-menu: Priority-to-profile mapping table(-s) for trusted packets. All switch chips have one built-in map - default. In addition, some models allow the user to define custom mapping tables and assign different maps to various switch ports via the qos-map property:
|
Property | Description |
---|---|
qos-map (name; Default: default) | The name of the mapping table. |
qos-profile (name; Default: ) | The name of the QoS profile to assign to the matched packets. |
pcp (integer: 0..7; Default: 0) | Minimum VLAN priority (PCP) value for the lookup. |
DSCP Map
Sub-menu:
/interface/ethernet/switch/qos/map/ip
Matches DSCP values to QoS profiles.
Property | Description |
---|---|
dscp (integer: 0..63; Default: 0) | Minimum DSCP value for the lookup. |
qos-map (name; Default: default) | The name of the mapping table. If not set, the standard (built-in) mapping table gets altered. |
qos-profile (name; Default: ) | The name of the QoS profile to assign to the matched packets. |
Page edited by Guntis G. - "typos"
Overview
The MACVLAN provides a means to create multiple virtual network interfaces, each with its own unique Media Access Control (MAC) address, attached to a physical network interface. This technology is utilized to address specific network requirements, such as obtaining multiple IP addresses or establishing distinct PPPoE client connections from a single physical Ethernet interface while using different MAC addresses. Unlike traditional VLAN (Virtual LAN) interfaces, which rely on Ethernet frames tagged with VLAN identifiers, MACVLAN operates at the MAC address level, making it a versatile and efficient solution for specific networking scenarios.
Basic Configuration Example
Picture a scenario where the ether1 interface connects to your ISP, and your router needs to lease two IP addresses, each with a distinct MAC address. Traditionally, this would require the use of two physical Ethernet interfaces and an additional switch. However, a more efficient solution is to create a virtual MACVLAN interface.
To create a MACVLAN interface, select the needed Ethernet interface. A MAC address will be automatically assigned if not manually specified:
/interface macvlan add interface=ether1 name=macvlan1 /interface macvlan print Flags: R - RUNNING Columns: NAME, MTU, INTERFACE, MAC-ADDRESS, MODE # NAME MTU INTERFACE MAC-ADDRESS MODE 0 R macvlan1 1500 ether1 76:81:BF:68:69:83 bridge
Now, a DHCP client can be created on ether1 and macvlan1 interfaces:
/ip dhcp-client add interface=ether1 add interface=macvlan1
Property Reference
Sub-menu: /interface/macvlan
Configuration settings for the MACVLAN interface.
Property | Description |
---|---|
arp (disabled | enabled | local-proxy-arp | proxy-arp | reply-only; Default: enabled) | Address Resolution Protocol setting
|
arp-timeout (auto | integer; Default: auto) | Sets for how long the ARP record is kept in the ARP table after no packets are received from IP. Value auto equals to the value of arp-timeout in / ip/settings/ , default is 30s. |
comment (string; Default: ) | Short description of the interface. |
disabled (yes | no; Default: no) | Changes whether the interface is disabled. |
interface (name; Default: ) | Name of the interface on top of which MACVLAN will work. MACVLAN interfaces can be created on Ethernet or VLAN interfaces, adding VLAN on MACVLAN is not supported. |
loop-protect (on | off | default; Default: default) | Enables or disables loop protect on the interface, the default works as turned off. |
loop-protect-disable-time (time interval | 0; Default: 5m) | Sets how long the selected interface is disabled when a loop is detected. 0 - forever. |
loop-protect-send-interval (time interval; Default: 5s) | Sets how often loop protect packets are sent on the selected interface. |
mac-address (MAC; Default: ) | Static MAC address of the interface. A randomly generated MAC address will be assigned when not specified. |
mode (private | bridge; Default: bridge) | Sets MACVLAN interface mode:
|
mtu (integer; Default: 1500) | Sets Layer 3 Maximum Transmission Unit. For the MACVLAN interface, it cannot be higher than the parent interface. |
name (string; Default: ) | Interface name. |
Page edited by Guntis G.
Overview
The MACsec (Media Access Control Security) protocol is a standard security technology employed in Ethernet networks to ensure the confidentiality, integrity, and authenticity of data transmitted over the physical medium. MACsec is defined by IEEE standard 802.1AE.
MACsec utilizes GCM-AES-128 encryption over Ethernet and secures all LAN traffic, including DHCP, ARP, LLDP, and higher-layer protocols.
RouterOS MACsec implementation is in the early stage, it does not support dynamic key management via Dot1x (manual key configuration is required) and hardware-accelerated encryption (maximum throughput is highly limited by the device CPU).
Basic Configuration Example
Imagine Host1 ether1 is connected to Switch ether1 and Host2 ether1 is connected to Switch ether2. In this example, we will create two MACsec interface pairs and use a bridge to create a secure Layer2 connection between both end devices.
First, configure MACsec interfaces on Host1 and Host2. We can specify only the Ethernet interface and RouterOS will automatically generate the Connectivity Association Key (CAK) and connectivity association name (CKN). Use the print
command to see the values:
# Host1 /interface macsec add interface=ether1 name=macsec1 [admin@Host2] /interface/macsec print Flags: I - inactive, X - disabled, R - running 0 name="macsec1" mtu=1468 interface=ether1 status="negotiating" cak=71a7c363794da400dbde595d3926b0e9 ckn=f2c4660060169391d29d8db8a1f06e5d4b84a128bad06ad43ea2bd4f7d21968f profile=default # Host2 /interface macsec add interface=ether1 name=macsec1 [admin@Host2] /interface/macsec print Flags: I - inactive, X - disabled, R - running 0 name="macsec1" mtu=1468 interface=ether1 status="negotiating" cak=dc47d94291d19a6bb26a0c393a1af9a4 ckn=e9bd0811dad1e56f06876aa7715de1855f1aee0baf5982ac8b508d4fc0f162d9 profile=default
On the Switch device, to enable MACsec we need to configure the matching CAK and CKN values for the appropriate Ethernet interface:
# Switch /interface macsec add comment=Host1 cak=71a7c363794da400dbde595d3926b0e9 ckn=f2c4660060169391d29d8db8a1f06e5d4b84a128bad06ad43ea2bd4f7d21968f interface=ether1 name=macsec1 add comment=Host2 cak=dc47d94291d19a6bb26a0c393a1af9a4 ckn=e9bd0811dad1e56f06876aa7715de1855f1aee0baf5982ac8b508d4fc0f162d9 interface=ether2 name=macsec2
Once the pre-shared keys are successfully exchanged, the MACsec Key Agreement (MKA) protocol is activated. MKA is responsible for ensuring the continuity of MACsec on the link and determines which side becomes the key server in a point-to-point connection. The key server generates a Secure Association Key (SAK) that is shared exclusively with the device on the other end of the link. This SAK is used to secure all data traffic passing through the link. Periodically, the key server generates a new randomly-created SAK and shares it over the point-to-point link to maintain MACsec functionality.
In RouterOS, the MACsec interface can be configured like any Ethernet interface. It can be used as a routable interface with an IP address, or placed inside a bridge. On Host1 and Host2 we will add an IP address from the same network. On Switch, we will use a bridge.
# Host1 /ip address add address=192.168.10.10/24 interface=macsec1 # Host2 /ip address add address=192.168.10.20/24 interface=macsec1 # Switch /interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=macsec1 add bridge=bridge1 interface=macsec2
Last, confirm that Host1 can reach Host2 using a ping.
[admin@Host1] > ping 192.168.10.20 SEQ HOST SIZE TTL TIME STATUS 0 192.168.10.20 56 64 1ms438us 1 192.168.10.20 56 64 818us 2 192.168.10.20 56 64 791us 3 192.168.10.20 56 64 817us 4 192.168.10.20 56 64 783us sent=5 received=5 packet-loss=0% min-rtt=783us avg-rtt=929us max-rtt=1ms438us
Property Reference
Interface settings
Sub-menu: /interface/macsec
Configuration settings for the MACsec interface.
Property | Description |
---|---|
cak (string; Default: ) | A 16-byte pre-shared connectivity association key (CAK). To enable MACsec, configure the matching CAK and CKN on both ends of the link. When not specified, RouterOS will automatically generate a random value. |
ckn (string; Default: ) | A 32-byte connectivity association name (CKN). To enable MACsec, configure the matching CAK and CKN on both ends of the link. When not specified, RouterOS will automatically generate a random value. |
comment (string; Default: ) | Short description of the interface. |
disabled (yes | no; Default: no) | Changes whether the interface is disabled. |
interface (name; Default: ) | Ethernet interface name where MACsec is created on, limited to one MACsec interface per Ethernet. |
mtu (integer; Default: 1468) | Sets the maximum transmission unit. The |
name (string; Default: macsec1) | Name of the interface. |
profile (name; Default: default) | Sets MACsec profile, used for determining the key server in a point-to-point connection. |
status (read-only: disabled |initializing | invalid | negotiating | open-encrypted) | Shows the current MACsec interface status. |
Profile settings
Sub-menu: /interface/macsec/profile
Configuration settings for the MACsec profile.
Property | Description |
---|---|
name (string; Default: ) | Name of the profile. |
server-priority (integer: 0..255; Default: 10) | Sets the priority for determining the key server in a point-to-point connection, a lower value means higher priority. In case of a priority match, the interface with the lowest MAC address will be acting as a key server. |
Page edited by Edgars P.
Summary
Standards: IEEE 802.1Q, IEEE 802.1ad
Virtual Local Area Network (VLAN) is a Layer 2 method that allows multiple Virtual LANs on a single physical interface (ethernet, wireless, etc.), giving the ability to segregate LANs efficiently.
You can use MikroTik RouterOS (as well as Cisco IOS, Linux, and other router systems) to mark these packets as well as to accept and route marked ones.
As VLAN works on OSI Layer 2, it can be used just like any other network interface without any restrictions. VLAN successfully passes through regular Ethernet bridges.
You can also transport VLANs over wireless links and put multiple VLAN interfaces on a single wireless interface. Note that as VLAN is not a full tunnel protocol (i.e., it does not have additional fields to transport MAC addresses of sender and recipient), the same limitation applies to bridging over VLAN as to bridging plain wireless interfaces. In other words, while wireless clients may participate in VLANs put on wireless interfaces, it is not possible to have VLAN put on a wireless interface in station mode bridged with any other interface.
802.1Q
The most commonly used protocol for Virtual LANs (VLANs) is IEEE 802.1Q. It is a standardized encapsulation protocol that defines how to insert a four-byte VLAN identifier into the Ethernet header.
Each VLAN is treated as a separate subnet. It means that by default, a host in a specific VLAN cannot communicate with a host that is a member of another VLAN, although they are connected in the same switch. So if you want inter-VLAN communication you need a router. RouterOS supports up to 4095 VLAN interfaces, each with a unique VLAN ID, per interface. VLAN priorities may also be used and manipulated.
When the VLAN extends over more than one switch, the inter-switch link has to become a 'trunk', where packets are tagged to indicate which VLAN they belong to. A trunk carries the traffic of multiple VLANs; it is like a point-to-point link that carries tagged packets between switches or between a switch and router.
The IEEE 802.1Q standard has reserved VLAN IDs with special use cases, the following VLAN IDs should not be used in generic VLAN setups: 0, 1, 4095
Q-in-Q
Original 802.1Q allows only one VLAN header, Q-in-Q on the other hand allows two or more VLAN headers. In RouterOS, Q-in-Q can be configured by adding one VLAN interface over another. Example:
/interface vlan add name=vlan1 vlan-id=11 interface=ether1 add name=vlan2 vlan-id=12 interface=vlan1
If any packet is sent over the 'vlan2' interface, two VLAN tags will be added to the Ethernet header - '11' and '12'.
Properties
Property | Description |
---|---|
arp (disabled | enabled | local-proxy-arp | proxy-arp | reply-only; Default: enabled) | Address Resolution Protocol setting
|
arp-timeout (auto | integer; Default: auto) | How long the ARP record is kept in the ARP table after no packets are received from IP. Value auto equals to the value of arp-timeout in IP/Settings, default is 30s. |
disabled (yes | no; Default: no) | Changes whether the bridge is disabled. |
interface (name; Default: ) | Name of the interface on top of which VLAN will work |
mvrp (yes | no; Default: no) | Specifies whether this VLAN should declare its attributes through Multiple VLAN Registration Protocol (MVRP) as an applicant. It can be used to register the VLAN with connected bridges that support MVRP. This property only has an effect when use-service-tag is disabled. |
mtu (integer; Default: 1500) | Layer3 Maximum transmission unit |
name (string; Default: ) | Interface name |
use-service-tag (yes | no; Default: ) | IEEE 802.1ad compatible Service Tag |
vlan-id (integer: 4095; Default: 1) | Virtual LAN identifier or tag that is used to distinguish VLANs. Must be equal for all computers that belong to the same VLAN. |
MTU should be set to 1500 bytes same as on Ethernet interfaces. But this may not work with some Ethernet cards that do not support receiving/transmitting of full-size Ethernet packets with VLAN header added (1500 bytes data + 4 bytes VLAN header + 14 bytes Ethernet header). In this situation, MTU 1496 can be used, but note that this will cause packet fragmentation if larger packets have to be sent over the interface. At the same time remember that MTU 1496 may cause problems if path MTU discovery is not working properly between source and destination.
Setup examples
Layer2 VLAN examples
There are multiple possible configurations that you can use, but each configuration type is designed for a special set of devices since some configuration methods will give you the benefits of the built-in switch chip and gain larger throughput. Check the Basic VLAN switching guide to see which configuration to use for each type of device to gain maximum possible throughput and compatibility, the guide shows how to setup a very basic VLAN trunk/access port configuration.
There are some other ways to setup VLAN tagging or VLAN switching, but the recommended way is to use Bridge VLAN Filtering. Make sure you have not used any known Layer2 misconfigurations.
Layer3 VLAN examples
Simple VLAN routing
Let us assume that we have several MikroTik routers connected to a hub. Remember that a hub is an OSI physical layer device (if there is a hub between routers, then from the L3 point of view it is the same as an Ethernet cable connection between them). For simplification assume that all routers are connected to the hub using the ether1 interface and have assigned IP addresses as illustrated in the figure below. Then on each of them the VLAN interface is created.
Configuration for R2 and R4 is shown below:
R2:
[admin@MikroTik] /interface vlan> add name=VLAN2 vlan-id=2 interface=ether1 disabled=no [admin@MikroTik] /interface vlan> print Flags: X - disabled, R - running, S - slave # NAME MTU ARP VLAN-ID INTERFACE 0 R VLAN2 1500 enabled 2 ether1
R4:
[admin@MikroTik] /interface vlan> add name=VLAN2 vlan-id=2 interface=ether1 disabled=no [admin@MikroTik] /interface vlan> print Flags: X - disabled, R - running, S - slave # NAME MTU ARP VLAN-ID INTERFACE 0 R VLAN2 1500 enabled 2 ether1
The next step is to assign IP addresses to the VLAN interfaces.
R2:
[admin@MikroTik] ip address> add address=10.10.10.3/24 interface=VLAN2 [admin@MikroTik] ip address> print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK BROADCAST INTERFACE 0 10.0.1.4/24 10.0.1.0 10.0.1.255 ether1 1 10.20.0.1/24 10.20.0.0 10.20.0.255 pc1 2 10.10.10.3/24 10.10.10.0 10.10.10.255 vlan2 [admin@MikroTik] ip address>
R4:
[admin@MikroTik] ip address> add address=10.10.10.5/24 interface=VLAN2 [admin@MikroTik] ip address> print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK BROADCAST INTERFACE 0 10.0.1.5/24 10.0.1.0 10.0.1.255 ether1 1 10.30.0.1/24 10.30.0.0 10.30.0.255 pc2 2 10.10.10.5/24 10.10.10.0 10.10.10.255 vlan2 [admin@MikroTik] ip address>
At this point it should be possible to ping router R4 from router R2 and vice versa:
"Ping from R2 to R4:" [admin@MikroTik] ip address> /ping 10.10.10.5 10.10.10.5 64 byte ping: ttl=255 time=4 ms 10.10.10.5 64 byte ping: ttl=255 time=1 ms 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 1/2.5/4 ms "From R4 to R2:" [admin@MikroTik] ip address> /ping 10.10.10.3 10.10.10.3 64 byte ping: ttl=255 time=6 ms 10.10.10.3 64 byte ping: ttl=255 time=1 ms 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 1/3.5/6 ms
To make sure if the VLAN setup is working properly, try to ping R1 from R2. If pings are timing out then VLANs are successfully isolated.
"From R2 to R1:" [admin@MikroTik] ip address> /ping 10.10.10.2 10.10.10.2 ping timeout 10.10.10.2 ping timeout 3 packets transmitted, 0 packets received, 100% packet loss
InterVLAN routing
If separate VLANs are implemented on a switch, then a router is required to provide communication between VLANs. A switch works at OSI layer 2 so it uses only Ethernet header to forward and does not check IP header. For this reason, we must use the router that is working as a gateway for each VLAN. Without a router, a host is unable to communicate outside of its own VLAN. The routing process between VLANs described above is called inter-VLAN communication.
To illustrate inter-VLAN communication, we will create a trunk that will carry traffic from three VLANs (VLAN2 and VLAN3, VLAN4) across a single link between a Mikrotik router and a manageable switch that supports VLAN trunking.
Each VLAN has its own separate subnet (broadcast domain) as we see in figure above:
- VLAN 2 – 10.10.20.0/24;
- VLAN 3 – 10.10.30.0/24;
- VLAN 4 – 10.10.40.0./24.
VLAN configuration on most switches is straightforward, basically, we need to define which ports are members of the VLANs and define a 'trunk' port that can carry tagged frames between the switch and the router.
Create VLAN interfaces:
/interface vlan add name=VLAN2 vlan-id=2 interface=ether1 disabled=no add name=VLAN3 vlan-id=3 interface=ether1 disabled=no add name=VLAN4 vlan-id=4 interface=ether1 disabled=no
Add IP addresses to VLANs:
/ip address add address=10.10.20.1/24 interface=VLAN2 add address=10.10.30.1/24 interface=VLAN3 add address=10.10.40.1/24 interface=VLAN4
RouterOS /32 and IP unnumbered addresses
In RouterOS, to create a point-to-point tunnel with addresses you have to use the address with a network mask of '/32' that effectively brings you the same features as some vendors unnumbered IP address.
There are 2 routers RouterA and RouterB where each is part of networks 10.22.0.0/24 and 10.23.0.0/24 respectively and to connect these routers using VLANs as a carrier with the following configuration:
RouterA:
/ip address add address=10.22.0.1/24 interface=ether1 /interface vlan add interface=ether2 vlan-id=1 name=vlan1 /ip address add address=10.22.0.1/32 interface=vlan1 network=10.23.0.1 /ip route add gateway=10.23.0.1 dst-address=10.23.0.0/24
RouterB:
/ip address add address=10.23.0.1/24 interface=ether1 /interface vlan add interface=ether2 vlan-id=1 name=vlan1 /ip address add address=10.23.0.1/32 interface=vlan1 network=10.22.0.1 /ip route add gateway=10.22.0.1 dst-address=10.22.0.0/24
Page edited by Guntis G. - "typos and formatting"
Introduction
Layer 3 Hardware Offloading (L3HW, otherwise known as IP switching or HW routing) allows to offload some router features onto the switch chip. This allows reaching wire speeds when routing packets, which would simply not be possible with the CPU.
Switch Configuration
To enable Layer 3 Hardware Offloading, set l3-hw-offloading=yes
for the switch:
/interface/ethernet/switch set 0 l3-hw-offloading=yes
Switch Port Configuration
Layer 3 Hardware Offloading can be configured for each physical switch port. For example:
/interface/ethernet/switch/port set sfp-sfpplus1 l3-hw-offloading=yes
Note that l3hw settings for switch and ports are different:
- Setting
l3-hw-offloading
=no
for the switch completely disables offloading - all packets will be routed by CPU. - However, setting
l3-hw-offloading
=no
for a switch port only disables hardware routing from/to this particular port. Moreover, the port can still participate in Fastrack connection offloading.
To enable full hardware routing, enable l3hw on all switch ports:
/interface/ethernet/switch set 0 l3-hw-offloading=yes /interface/ethernet/switch/port set [find] l3-hw-offloading=yes
To make all packets go through the CPU first, and offload only the Fasttrack connections, disable l3hw on all ports but keep it enabled on the switch chip itself:
/interface/ethernet/switch set 0 l3-hw-offloading=yes /interface/ethernet/switch/port set [find] l3-hw-offloading=no
Packets get routed by the hardware only if both source and destination ports have l3-hw-offloading=yes
. If at least one of them has l3-hw-offloading=no
, packets will go through the CPU/Firewall while offloading only the Fasttrack connections.
The next example enables hardware routing on all ports but the upstream port (sfp-sfpplus16). Packets going to/from sfp-sfpplus16 will enter the CPU and, therefore, subject to Firewall/NAT processing.
/interface/ethernet/switch set 0 l3-hw-offloading=yes /interface/ethernet/switch/port set [find] l3-hw-offloading=yes /interface/ethernet/switch/port set sfp-sfpplus16 l3-hw-offloading=no
The existing connections may be unaffected by the l3-hw-offloading
setting change.
L3HW Settings
Basic Settings
The L3HW Settings menu has been introduced in RouterOS version 7.6.
Sub-menu: /interface ethernet switch l3hw-settings
Property | Description |
---|---|
autorestart (yes | no; Default: no) | Automatically restarts the l3hw driver in case of an error. Otherwise, if an error occurs, l3-hw-offloading gets disabled, and the error code is displayed in the switch settings and #monitor. Autorestart does not work for system failures, such as OOM (Out Of Memory). |
fasttrack-hw (yes | no; Default: yes (if supported)) | Enables or disables FastTrack HW Offloading. Keep it enabled unless HW TCAM memory reservation is required, e.g., for dynamic switch ACL rules creation. Not all switch chips support FastTrack HW Offloading (see hw-supports-fasttrack). |
ipv6-hw (yes | no; Default: no) | Enables or disables IPv6 Hardware Offloading. Since IPv6 routes occupy a lot of HW memory, enable it only if IPv6 traffic speed is significant enough to benefit from hardware routing. |
icmp-reply-on-error (yes | no; Default: yes) | Since the hardware cannot send ICMP messages, the packet must be redirected to the CPU to send an ICMP reply in case of an error (e.g., "Time Exceeded", "Fragmentation required", etc.). Enabling icmp-reply-on-error helps with network diagnostics but may open potential vulnerabilities for DDoS attacks. Disabling icmp-reply-on-error silently drops the packets on the hardware level in case of an error. |
Read-Only Properties
Property | Description |
---|---|
hw-supports-fasttrack (yes | no) | Indicates if the hardware (switch chip) supports FastTrack HW Offloading. |
Advanced Settings
This menu allows tweaking l3hw settings for specific use cases.
It is NOT recommended to change the advanced L3HW settings unless instructed by MikroTik Support or MikroTik Certified Routing Engineer. Applying incorrect settings may break the L3HW operation.
Sub-menu: /interface ethernet switch l3hw-settings
advanced
Property | Description |
---|---|
route-queue-limit-high (number; Default: 256) | The switch driver stops route indexing when route-queue-size (see #monitor) exceeds this value. Lowering this value leads to faster route processing but increases the lag between a route's appearance in RouterOS and hardware memory. Setting route-queue-limit-high=0 disables route indexing when there are any routes in the processing queue - the most efficient CPU usage but the longest delay before hardware offloading. Useful when there are static routes only. Not recommended together with routing protocols (such as BGP or OSPF) when there are frequent routing table changes. |
route-queue-limit-low (number; Default: 0) | Re-enable route indexing when route-queue-size drops down to this value. Must not exceed the high limit. Setting route-queue-limit-low=0 tells the switch driver to process all pending routes before the next hw-offloading attempt. While this is the desired behavior, it may completely block the hw-offloading under a constant BGP feed. |
shwp-reset-counter (number; Default: 128) | Reset the Shortest HW Prefix (see ipv4-shortest-hw-prefix / ipv6-shortest-hw-prefix in #monitor) and try the full route table offloading after this amount of changes in the routing table. At a partial offload, when the entire routing table does not fit into the hardware memory and shorter prefixes are redirected to the CPU, there is no need to try offloading route prefixes shorter than SHWP since those will get redirected to the CPU anyway, theoretically. However, significant changes to the routing table may lead to a different index layout and, therefore, a different amount of routes that can be hw-offloaded. That's why it is recommended to do the full table re-indexing occasionally. Lowering this value may allow more routes to be hw-offloaded but increases CPU usage and vice-versa. Setting shwp-reset-counter=0 always does full re-indexing after each routing table change. This setting is used only during Partial Offloading and has no effect when ipv4-shortest-hw-prefix=0 (and ipv6, respectively). |
partial-offload-chunk (number; Default: 1024, min: 16) | The minimum number of routes for incremental adding in Partial Offloading. Depending on the switch chip model, routes are offloaded either as-is (each routing entry in RouterOS corresponds to an entry in the hardware memory) or getting indexed, and the index entries are the ones that are written into the hardware memory. This setting is used only for the latter during Partial Offloading. Depending on index fragmentation, a single IPv4 route addition can occupy from -3 to +6 LPM blocks of HW memory (some route addition may lower the amount of required HW memory thanks to index defragmentation). Hence, it is impossible to predict the exact number of routes that may fit in the hardware memory. The switch driver uses a binary split algorithm to find the maximum number of routes that fit in the hardware. Let's imagine 128k routes, all of them not fitting into the hardware memory. The algorithm halves the number and tries offloading 64k routes. Let's say offloading succeeded. In the next iteration, the algorithm picks 96k, let's say it fails; then 80k - fails again, 72k - succeeds, 76k, etc. until the difference between succeeded and failed numbers drops below the partial-offload-chunk value. Lowering the partial-offload-chunk value increases the number of hw-offloaded routes but also raises CPU usage and vice-versa. |
route-index-delay-min (time; Default: 1s) | The minimum delay between route processing and its offloading. The delay allows processing more routes together and offloading them at once, saving CPU usage. It also makes offloading the entire routing table faster by reducing the per-route processing work. On the other hand, it slows down the offloading of an individual route. If an additional route is received during the delay, the latter resets to the route-index-delay-min value. Adding more and more routes within the delay keeps resetting the timer until the route-index-delay-max is reached. |
route-index-delay-max (time; Default: 10s) | The maximum delay between route processing and its offloading. When the maximum delay is reached, the processed routes get offloaded despite more routes pending. However, route-queue-limit-high has higher priority than this, meaning that the indexing/offloading gets paused anyway when a certain queue size is reached. |
neigh-keepalive-interval (time; Default: 15s, min: 5s) | Neighbor (host) keepalive interval. When a host (IP neighbor) gets hw-offloaded, all traffic from/to it is routed by the switch chip, and RouterOS may think the neighbor is inactive and delete it. To prevent that, the switch driver must keep the offloaded neighbors alive by sending periodical refreshes to RouterOS. |
neigh-discovery-interval (time; Default: 1m37s, min: 30s) | Unfortunately, switch chips do not provide per-neighbor stats. Hence, the only way to check if the offloaded host is still active is by sending occasional ARP (IPv4) / Neighbor Discovery (IPv6) requests to the connected network. Increasing the value lowers the broadcast traffic but may leave inactive hosts in hardware memory for longer. Neighbor discovery is triggered within the neighbor keepalive work. Hence, the discovery time is rounded up to the next keepalive session. Choose a value for neigh-discovery-interval not dividable by neigh-keepalive-interval to send ARP/ND requests in various sessions, preventing broadcast bursts. |
neigh-discovery-burst-limit (number; Default: 64) | The maximum number of ARP/ND requests that can be sent at once. |
neigh-discovery-burst-delay (time; Default: 300ms, min: 10ms) | The delay between ARP/ND subsequent bursts if the number of requests exceeds neigh-discovery-burst-limit. |
Some settings only apply to certain switch models.
Monitor
The L3HW Monitor feature has been introduced in RouterOS version 7.10. It allows monitoring of switch chip and driver stats related to L3HW.
/interface/ethernet/switch/l3hw-settings/monitor ipv4-routes-total: 99363 ipv4-routes-hw: 61250 ipv4-routes-cpu: 38112 ipv4-shortest-hw-prefix: 24 ipv4-hosts: 87 ipv6-routes-total: 15 ipv6-routes-hw: 11 ipv6-routes-cpu: 4 ipv6-shortest-hw-prefix: 0 ipv6-hosts: 7 route-queue-size: 118 fasttrack-ipv4-conns: 2031 fasttrack-hw-min-speed: 0 nexthop-cap: 8192 nexthop-usage: 93
Stats
Property | Description |
---|---|
ipv4-routes-total | The total number of IPv4 routes handled by the switch driver. |
ipv4-routes-hw | The number of hardware-offloaded IPv4 routes (a.k.a. hardware routes) |
ipv4-routes-cpu | The number of IPv4 routes redirected to the CPU (a.k.a. software routes) |
ipv4-shortest-hw-prefix | Shortest Hardware Prefix (SHWP) for IPv4. If the entire IPv4 routing table does not fit into the hardware memory, partial offloading is applied, where the longest prefixes are hw-offloaded while the shorter ones are redirected to the CPU. This field shows the shortest route prefix (/x) that is offloaded to the hardware memory. All prefixes shorter than this are processed by the CPU. "ipv4-shortest-hw-prefix=0 " means the entire IPv4 routing table is offloaded to the hardware memory. |
ipv4-hosts | The number of hardware-offloaded IPv4 hosts (/32 routes) |
ipv6-routes-total 1 | The total number of IPv6 routes handled by the switch driver. |
ipv6-routes-hw 1 | The number of hardware-offloaded IPv6 routes (a.k.a. hardware routes) |
ipv6-routes-cpu 1 | The number of IPv6 routes redirected to the CPU (a.k.a. software routes) |
ipv6-shortest-hw-prefix 1 | Shortest Hardware Prefix (SHWP) for IPv6. If the entire IPv6 routing table does not fit into the hardware memory, partial offloading is applied, where the longest prefixes are hw-offloaded while the shorter ones are redirected to the CPU. This field shows the shortest route prefix (/x) that is offloaded to the hardware memory. All prefixes shorter than this are processed by the CPU. "ipv6-shortest-hw-prefix=0 " means the entire IPv6 routing table is offloaded to the hardware memory. |
ipv6-hosts 1 | The number of hardware-offloaded IPv6 hosts (/128 routes) |
route-queue-size | The number of routes in the queue for processing by the switch chip driver. Under normal working conditions, this field is 0, meaning that all routes are processed by the driver. |
fasttrack-ipv4-conns 2 | The number of hardware-offloaded FastTrack connections. |
fasttrack-hw-min-speed 2 | When the hardware memory for storing FastTrack is full, this field shows the minimum speed (in bytes per second) of a hw-offloaded FastTrack connection. Slower connections are routed by the CPU. |
1 IPv6 stats appear only when IPv6 hardware routing is enabled (ipv6-hw=yes
)
2 FastTrack stats appear only when hardware offloading of FastTrack connections is enabled (fasttrack-hw=yes
)
Advanced Monitor
An enhanced version of Monitor with extra telemetry data for advanced users. Advanced Monitor contains all data from the basic monitor plus the fields listed below.
/interface/ethernet/switch/l3hw-settings/advanced> monitor once ipv4-routes-total: 29968 ipv4-routes-hw: 29957 ipv4-routes-cpu: 11 ipv4-shortest-hw-prefix: 0 ipv4-hosts: 3 ipv6-routes-total: 4 ipv6-routes-hw: 0 ipv6-routes-cpu: 4 ipv6-shortest-hw-prefix: 0 ipv6-hosts: 0 route-queue-size: 0 route-queue-rate: 0 route-process-rate: 0 fasttrack-ipv4-conns: 0 fasttrack-queue-size: 0 fasttrack-queue-rate: 0 fasttrack-process-rate: 0 fasttrack-hw-min-speed: 0 fasttrack-hw-offloaded: 0 fasttrack-hw-unloaded: 0 lpm-cap: 54560 lpm-usage: 31931 lpm-bank-cap: 2728 lpm-bank-usage: 46,0,0,0,2589,2591,1983,0,2728,2728,2728,2728,2728,2728,2728,2728,2728,170,0,0 pbr-cap: 8192 pbr-usage: 0 pbr-lpm-bank: 3 nat-usage: 0 nexthop-cap: 8192 nexthop-usage: 85
Stats
Property | Description |
---|---|
route-queue-rate | The rate at which routes are added to the queue for the switch driver processing. In other words, the growth rate of route-queue-size (routes per second) |
route-process-rate | The rate at which previously queued routes are processed by the switch driver. In other words, the shrink rate of route-queue-size (routes per second) |
fasttrack-queue-size | The number of FastTrack connections in the queue for processing by the switch chip driver. |
fasttrack-queue-rate | The rate at which FastTrack connections are added to the queue for the switch driver processing. In other words, the growth rate of fasttrack-queue-size (connections per second) |
fasttrack-process-rate | The rate at which previously queued FastTrack connections are processed by the switch driver. In other words, the shrink rate of fasttrack-queue-size (connections per second) |
fasttrack-hw-offloaded | The number of FastTrack connections offloaded to the hardware. The counter resets every second (or every monitor interval). |
fasttrack-hw-unloaded | The number of FastTrack connections unloaded from the hardware (redirected to software routing). The counter resets every second (or every monitor interval). |
lpm-cap | The size of the LPM hardware table (LPM = Longest Prefix Match). LPM stores route indexes for hardware routing. Not every switch chip model uses LPM. Others use TCAM. |
lpm-usage | The number of used LPM blocks. lpm-usage / lpm-cap = usage percentage. |
lpm-bank-cap | LPM memory is organized in banks - special memory units. The bank size depends on the switch chip model. This value shows the size of a single bank (in LPM blocks). lpm-cap / lpm-bank-cap = the number of banks (usually, 20). |
lpm-bank-usage | Per-bank LPM usage (in LPM blocks) |
pbr-cap | The size of the Policy-Based Routing (PBR) hardware table. PBR is used for NAT offloading of FastTrack connections. |
pbr-usage | The number of used PBR entries. pbr-usage / pbr-cap = usage percentage. |
pbr-lpm-bank | PBR shares LPM memory banks with routing tables. This value shows the LPM bank index shared with PBR (0 = the first bank). |
nat-usage | The number of used NAT hardware entries (for FastTrack connections). |
Interface Lists
It is impossible to use interface lists directly to control l3-hw-offloading
because an interface list may contain virtual interfaces (such as VLAN) while the l3-hw-offloading
setting must be applied to physical switch ports only. For example, if there are two VLAN interfaces (vlan20 and vlan30) running on the same switch port (trunk port), it is impossible to enable hardware routing on vlan20 but keep it disabled on vlan30.
However, an interface list may be used as a port selector. The following example demonstrates how to enable hardware routing on LAN ports (ports that belong to the "LAN" interface list) and disable it on WAN ports:
:foreach i in=[/interface/list/member/find where list=LAN] do={ /interface/ethernet/switch/port set [/interface/list/member/get $i interface] l3-hw-offloading=yes } :foreach i in=[/interface/list/member/find where list=WAN] do={ /interface/ethernet/switch/port set [/interface/list/member/get $i interface] l3-hw-offloading=no }
Please take into account that since interface lists are not directly used in hardware routing control., modifying the interface list also does not automatically reflect in l3hw changes. For instance, adding a switch port to the "LAN" interface list does not automatically enable l3-hw-offloading
on it. The user has to rerun the above script to apply the changes.
MTU
The hardware supports up to 8 MTU profiles, meaning that the user can set up to 8 different MTU values for interfaces: the default 1500 + seven custom ones.
l3-hw-offloading
while changing the MTU/L2MTU values on the interfaces./interface/ethernet/switch set 0 l3-hw-offloading=no /interface set sfp-sfpplus1 mtu=9000 l2mtu=9022 /interface set sfp-sfpplus2 mtu=9000 l2mtu=9022 /interface set sfp-sfpplus3 mtu=10000 l2mtu=10022 /interface/ethernet/switch set 0 l3-hw-offloading=yes
Layer 2 Dependency
Layer 3 hardware processing lies on top of Layer 2 hardware processing. Therefore, L3HW offloading requires L2HW offloading on the underlying interfaces. The latter is enabled by default, but there are some exceptions. For example, CRS3xx devices support only one hardware bridge. If there are multiple bridges, others are processed by the CPU and are not subject to L3HW.
Another example is ACL rules. If a rule redirects traffic to the CPU for software processing, then hardware routing (L3HW) is not triggered:
/interface/ethernet/switch/rule/add switch=switch1 ports=ether1 redirect-to-cpu=yes
To make sure that Layer 3 is in sync with Layer 2 on both the software and hardware sides, we recommend disabling L3HW while configuring Layer 2 features. The recommendation applies to the following configuration:
- adding/removing/enabling/disabling bridge;
- adding/removing switch ports to/from the bridge;
- bonding switch ports / removing bond;
- changing VLAN settings;
- changing MTU/L2MTU on switch ports;
- changing ethernet (MAC) addresses.
In short, disable l3-hw-offloading
while making changes under /interface/bridge/
and /interface/vlan/
:
/interface/ethernet/switch set 0 l3-hw-offloading=no /interface/bridge # put bridge configuration changes here /interface/vlan # define/change VLAN interfaces /interface/ethernet/switch set 0 l3-hw-offloading=yes
MAC telnet and RoMON
There is a limitation for MAC telnet and RoMON when L3HW offloading is enabled on 98DX8xxx, 98DX4xxx, or 98DX325x switch chips. Packets from these protocols are dropped and do not reach the CPU, thus access to the device will fail.
If MAC telnet or RoMON are desired in combination with L3HW, certain ACL rules can be created to force these packets to the CPU.
For example, if MAC telnet access on sfp-sfpplus1 and sfp-sfpplus2 is needed, you will need to add this ACL rule. It is possible to select even more interfaces with the ports
setting.
/interface ethernet switch rule add dst-port=20561 ports=sfp-sfpplus1,sfp-sfpplus2 protocol=udp redirect-to-cpu=yes switch=switch1
For example, if RoMON access on sfp-sfpplus2 is needed, you will need to add this ACL rule.
/interface ethernet switch rule add mac-protocol=0x88BF ports=sfp-sfpplus2 redirect-to-cpu=yes switch=switch1
Inter-VLAN Routing
Since L3HW depends on L2HW, and L2HW is the one that does VLAN processing, Inter-VLAN hardware routing requires a hardware bridge underneath. Even if a particular VLAN has only one tagged port member, the latter must be a bridge member. Do not assign a VLAN interface directly on a switch port! Otherwise, L3HW offloading fails and the traffic will get processed by the CPU:
/interface/vlan add interface=ether2 name=vlan20 vlan-id=20
Assign the VLAN interface to the bridge instead. This way, VLAN configuration gets offloaded to the hardware, and, with L3HW enabled, the traffic is subject to inter-VLAN hardware routing.
/interface/ethernet/switch set 0 l3-hw-offloading=no /interface/bridge/port add bridge=bridge interface=ether2 /interface/bridge/vlan add bridge=bridge tagged=bridge,ether2 vlan-ids=20 /interface/vlan add interface=bridge name=vlan20 vlan-id=20 /ip/address add address=192.0.2.1/24 interface=vlan20 /interface/bridge set bridge vlan-filtering=yes /interface/ethernet/switch set 0 l3-hw-offloading=yes
/interface/bridge/vlan/
entry.L3HW MAC Address Range Limitation (DX2000/DX3000 series only)
Marvell Prestera DX2000 and DX3000 switch chips have a hardware limitation that allows configuring only the last (least significant) octet of the MAC address for each interface. The other five (most significant) octets are configured globally and, therefore, must be equal for all interfaces (switch ports, bridge, VLANs). In other words, the MAC addresses must be in the format "XX:XX:XX:XX:XX:??", where:
- "XX:XX:XX:XX:XX" part is common for all interfaces.
- "??" is a variable part.
This requirement applies only to Layer 3 (routing). Layer 2 (bridging) does not use the switch's ethernet addresses. Moreover, it does not apply to bridge ports because they use the bridge's MAC address.
The requirement for common five octets applies to:
- Standalone switch ports (not bridge members) with hardware routing enabled (
l3-hw-offloading=yes
). - Bridge itself.
- VLAN interfaces (those that use the bridge's MAC address by default).
Route Configuration
Suppressing HW Offload
By default, all the routes are participating to be hardware candidate routes. To further fine-tune which traffic to offload, there is an option for each route to disable/enable suppress-hw-offload
.
For example, if we know that the majority of traffic flows to the network where servers are located, we can enable offloading only to that specific destination:
/ip/route set [find where static && dst-address!="192.168.3.0/24"] suppress-hw-offload=yes
Now only the route to 192.168.3.0/24 has H-flag, indicating that it will be the only one eligible to be selected for HW offloading:
[admin@MikroTik] > /ip/route print where static Flags: A - ACTIVE; s - STATIC, y - COPY; H - HW-OFFLOADED Columns: DST-ADDRESS, GATEWAY, DISTANCE # DST-ADDRESS GATEWAY D 0 As 0.0.0.0/0 172.16.2.1 1 1 As 10.0.0.0/8 10.155.121.254 1 2 AsH 192.168.3.0/24 172.16.2.1 1
H-flag does not indicate that the route is actually HW offloaded, it indicates only that the route can be selected to be HW offloaded.
Routing Filters
For dynamic routing protocols like OSFP and BGP, it is possible to suppress HW offloading using routing filters. For example, to suppress HW offloading on all OSFP instance routes, use "suppress-hw-offload yes
" property:
/routing/ospf/instance set [find name=instance1] in-filter-chain=ospf-input /routing/filter/rule add chain="ospf-input" rule="set suppress-hw-offload yes; accept"
Offloading Fasttrack Connections
Firewall filter rules have hw-offload
option for Fasttrack, allowing fine-tuning connection offloading. Since the hardware memory for Fasttrack connections is very limited, we can choose what type of connections to offload and, therefore, benefit from near-the-wire-speed traffic. The next example offloads only TCP connections while UDP packets are routed via the CPU and do not occupy HW memory:
/ip/firewall/filter add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes protocol=tcp add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=no add action=accept chain=forward connection-state=established,related
Stateless Hardware Firewall
While connection tracking and stateful firewalling can be performed only by the CPU, the hardware can perform stateless firewalling via switch rules (ACL). The next example prevents (on a hardware level) accessing a MySQL server from the ether1, and redirects to the CPU/Firewall packets from ether2 and ether3:
/interface ethernet switch rule add switch=switch1 dst-address=10.0.1.2/32 dst-port=3306 ports=ether1 new-dst-ports="" add switch=switch1 dst-address=10.0.1.2/32 dst-port=3306 ports=ether2,ether3 redirect-to-cpu=yes
Switch Rules (ACL) vs. Fasttrack HW Offloading
Some firewall rules may be implemented both via switch rules (ACL) and CPU Firewall Filter + Fasttrack HW Offloading. Both options grant near-the-wire-speed performance. So the question is which one to use?
First, not all devices support Fasttrack HW Offloading, and without HW offloading, Firewall Filter uses only software routing, which is dramatically slower than its hardware counterpart. Second, even if Fasttrack HW Offloading is an option, a rule of thumb is:
Always use Switch Rules (ACL), if possible.
Switch rules share the hardware memory with Fastrack connections. However, hardware resources are allocated for each Fasttrack connection while a single ACL rule can match multiple connections. For example, if you have a guest WiFi network connected to sfp-sfpplus1 VLAN 10 and you don't want it to access your internal network, simply create an ACL rule:
/interface/ethernet/switch/rule add switch=switch1 ports=sfp-sfpplus1 vlan-id=10 dst-address=10.0.0.0/8 new-dst-ports=""
The matched packets will be dropped on the hardware level. It is much better than letting all guest packets to the CPU for Firewall filtering.
Of course, ACL rules cannot match everything. For instance, ACL rules cannot filter connection states: accept established, drop others. That is where Fasttrack HW Offloading gets into action - redirect the packets to the CPU by default for firewall filtering, then offload the established Fasttrack connections. However, disabling l3-hw-offloading
for the entire switch, port is not the only option.
Define ACL rules with redirect-to-cpu=yes
instead of setting l3-hw-offloading=no
of the switch port for narrowing down the traffic that goes to the CPU.
Configuration Examples
Inter-VLAN Routing with Upstream Port Behind Firewall/NAT
This example demonstrates how to benefit from near-to-wire-speed inter-VLAN routing while keeping Firewall and NAT running on the upstream port. Moreover, Fasttrack connections to the upstream port get offloaded to hardware as well, boosting the traffic speed close to wire-level. Inter-VLAN traffic is fully routed by the hardware, not entering the CPU/Firewall, and, therefore, not occupying the hardware memory of Fasttrack connections.
We use the CRS317-1G-16S+ model with the following setup:
- sfp1-sfp4 - bridged ports, VLAN ID 20, untagged
- sfp5-sfp8 - bridged ports, VLAN ID 30, untagged
- sfp16 - the upstream port
- ether1 - management port
Setup interface lists for easy access:
/interface list add name=LAN add name=WAN add name=MGMT /interface list member add interface=sfp-sfpplus1 list=LAN add interface=sfp-sfpplus2 list=LAN add interface=sfp-sfpplus3 list=LAN add interface=sfp-sfpplus4 list=LAN add interface=sfp-sfpplus5 list=LAN add interface=sfp-sfpplus6 list=LAN add interface=sfp-sfpplus7 list=LAN add interface=sfp-sfpplus8 list=LAN add interface=sfp-sfpplus16 list=WAN add interface=ether1 list=MGMT
/interface bridge add name=bridge vlan-filtering=yes /interface bridge port add bridge=bridge interface=sfp-sfpplus1 pvid=20 add bridge=bridge interface=sfp-sfpplus2 pvid=20 add bridge=bridge interface=sfp-sfpplus3 pvid=20 add bridge=bridge interface=sfp-sfpplus4 pvid=20 add bridge=bridge interface=sfp-sfpplus5 pvid=30 add bridge=bridge interface=sfp-sfpplus6 pvid=30 add bridge=bridge interface=sfp-sfpplus7 pvid=30 add bridge=bridge interface=sfp-sfpplus8 pvid=30 /interface bridge vlan add bridge=bridge tagged=bridge untagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 vlan-ids=20 add bridge=bridge tagged=bridge untagged=sfp-sfpplus5,sfp-sfpplus6,sfp-sfpplus7,sfp-sfpplus8 vlan-ids=30
Routing requires dedicated VLAN interfaces. For standard L2 VLAN bridging (without inter-VLAN routing), the next step can be omitted.
/interface vlan add interface=bridge name=vlan20 vlan-id=20 add interface=bridge name=vlan30 vlan-id=30 /ip address add address=192.168.20.17/24 interface=vlan20 network=192.168.20.0 add address=192.168.30.17/24 interface=vlan30 network=192.168.30.0
Configure management and upstream ports, a basic firewall, NAT, and enable hardware offloading of Fasttrack connections:
/ip address add address=192.168.88.1/24 interface=ether1 add address=10.0.0.17/24 interface=sfp-sfpplus16 /ip route add gateway=10.0.0.1 /ip firewall filter add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes add action=accept chain=forward connection-state=established,related /ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN
At this moment, all routing still is performed by the CPU. Enable hardware routing on the switch chip:
# Enable full hardware routing on LAN ports :foreach i in=[/interface/list/member/find where list=LAN] do={ /interface/ethernet/switch/port set [/interface/list/member/get $i interface] l3-hw-offloading=yes } # Disable full hardware routing on WAN or Management ports :foreach i in=[/interface/list/member/find where list=WAN or list=MGMT] do={ /interface/ethernet/switch/port set [/interface/list/member/get $i interface] l3-hw-offloading=no } # Activate Layer 3 Hardware Offloading on the switch chip /interface/ethernet/switch/set 0 l3-hw-offloading=yes
Results:
- Within the same VLAN (e.g., sfp1-sfp4), traffic is forwarded by the hardware on Layer 2 (L2HW).
- Inter-VLAN traffic (e.g. sfp1-sfp5) is routed by the hardware on Layer 3 (L3HW).
- Traffic from/to the WAN port gets processed by the CPU/Firewall first. Then Fasttrack connections get offloaded to the hardware (Hardware-Accelerated L4 Stateful Firewall). NAT applies both on CPU- and HW-processed packets.
- Traffic to the management port is protected by the Firewall.
Typical Misconfiguration
Below are typical user errors in configuring Layer 3 Hardware Offloading.
VLAN interface on a switch port or bond
/interface/vlan add name=vlan10 vlan-id=10 interface=sfp-sfpplus1 add name=vlan20 vlan-id=20 interface=bond1
VLAN interface must be set on the bridge due to Layer 2 Dependency. Otherwise, L3HW will not work. The correct configuration is:
/interface/bridge/port add bridge=bridge1 interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged add bridge=bridge1 interface=bond1 frame-types=admit-only-vlan-tagged /interface/bridge/vlan add bridge=bridge1 tagged=bridge1,sfp-sfpplus1 vlan-ids=10 add bridge=bridge1 tagged=bridge1,bond1 vlan-ids=20 /interface/vlan add name=vlan10 vlan-id=10 interface=bridge1 add name=vlan20 vlan-id=20 interface=bridge1
Not adding the bridge interface to /interface/bridge/vlan/
For Inter-VLAN routing, the bridge interface itself needs to be added to the tagged members of the given VLANs. In the next example, Inter-VLAN routing works between VLAN 10 and 11, but packets are NOT routed to VLAN 20.
/interface bridge vlan add bridge=bridge1 vlan-ids=10 tagged=bridge1,sfp-sfpplus1 add bridge=bridge1 vlan-ids=11 tagged=bridge1 untagged=sfp-sfpplus2,sfp-sfpplus3 add bridge=bridge1 vlan-ids=20 tagged=sfp-sfpplus1 untagged=sfp-sfpplus4,sfp-sfpplus5
The above example does not always mean an error. Sometimes, you may want the device to act as a simple L2 switch in some/all VLANs. Just make sure you set such behavior on purpose, not due to a mistake.
Creating multiple bridges
The devices support only one hardware bridge. If there are multiple bridges created, only one gets hardware offloading. While for L2 that means software forwarding for other bridges, in the case of L3HW, multiple bridges may lead to undefined behavior.
Instead of creating multiple bridges, create one and segregate L2 networks with VLAN filtering.
Using ports that do not belong to the switch
Some devices have two switch chips or the management port directly connected to the CPU. For example, CRS312-4C+8XG has an ether9 port connected to a separate switch chip. Trying to add this port to a bridge or involve it in the L3HW setup leads to unexpected results. Leave the management port for management!
[admin@crs312] /interface/ethernet/switch> print Columns: NAME, TYPE, L3-HW-OFFLOADING # NAME TYPE L3-HW-OFFLOADING 0 switch1 Marvell-98DX8212 yes 1 switch2 Atheros-8227 no [admin@crs312] /interface/ethernet/switch> port print Columns: NAME, SWITCH, L3-HW-OFFLOADING, STORM-RATE # NAME SWITCH L3-HW-OFFLOADING STORM-RATE 0 ether9 switch2 1 ether1 switch1 yes 100 2 ether2 switch1 yes 100 3 ether3 switch1 yes 100 4 ether4 switch1 yes 100 5 ether5 switch1 yes 100 6 ether6 switch1 yes 100 7 ether7 switch1 yes 100 8 ether8 switch1 yes 100 9 combo1 switch1 yes 100 10 combo2 switch1 yes 100 11 combo3 switch1 yes 100 12 combo4 switch1 yes 100 13 switch1-cpu switch1 100 14 switch2-cpu switch2
Relying on Fasttrack HW Offloading too much
Since Fasttrack HW Offloading offers near-the-wire-speed performance at zero configuration overhead, the users are tempted to use it as the default solution. However, the number of HW Fasttrack connections is very limited, leaving the other traffic for the CPU. Try using the hardware routing as much as possible, reduce the CPU traffic to the minimum via switch ACL rules, and then fine-tune which Fasttrack connections to offload with firewall filter rules.
Trying to offload slow-path connections
Using certain configurations (e.g. enabling bridge "use-ip-firewall" setting, creating bridge nat/filter rules) or running specific features like sniffer or torch can disable RouterOS FastPath, which will affect the ability to properly FastTrack and HW offload connections. If HW offloaded Fasttrack is required, make sure that there are no settings that disable the FastPath and verify that connections are getting the "H" flag or use the L3HW monitor command to see the amount of HW offloaded connections.
L3HW Feature Support
- HW - the feature is supported and offloaded to the hardware.
- CPU - the feature is supported but performed by software (CPU)
- N/A - the feature is not available together with L3HW. Layer 3 hardware offloading must be completely disabled (switch
l3-hw-offloading=no
) to make this feature work. - FW - the feature requires
l3-hw-offloading
=no
for a given switch port. On the switch level,l3-hw-offloading=yes
.
Feature | Support | Comments | Release |
---|---|---|---|
IPv4 Unicast Routing | HW | 7.1 | |
IPv6 Unicast Routing | HW | /interface/ethernet/switch/l3hw-settings/set ipv6-hw=yes | 7.6 |
IPv4 Multicast Routing | CPU | ||
IPv6 Multicast Routing | CPU | ||
ECMP | HW | Multipath routing | 7.1 |
Blackholes | HW | /ip/route add dst-address=10.0.99.0/24 blackhole | 7.1 |
gateway=<interface_name> | CPU/HW | /ip/route add dst-address=10.0.0.0/24 gateway=ether1 This works only for directly connected networks. Since HW does not know how to send ARP requests, | 7.1 |
BRIDGE | HW | IP Routing from/to hardware-offloaded bridge interface. | 7.1 |
VLAN | HW | Routing between VLAN interfaces that are created on hardware-offloaded bridge interface with vlan-filtering. | 7.1 |
Bonding | HW | /interface/bonding | 7.1 |
IPv4 Firewall | FW | Users must choose either HW-accelerated routing or firewall. Firewall rules get processed by the CPU. Fasttrack connections get offloaded to HW. | 7.1 |
IPv4 NAT | FW | NAT rules applied to the offloaded Fasttrack connections get processed by HW too. | 7.1 |
MLAG | N/A | ||
VRF | N/A | Only the main routing table gets offloaded. If VRF is used together with L3HW and packets arrive on a switch port with l3-hw-offloadin g=yes , packets can be incorrectly routed through the main routing table. To avoid this, disable L3HW on needed switch ports or use ACL rules to redirect specific traffic to the CPU. | |
VRRP | N/A | ||
Controller Bridge and Port Extender | N/A | ||
VXLAN | CPU | ||
MTU | HW | The hardware supports up to 8 MTU profiles. | 7.1 |
QinQ and tag-stacking | CPU | Stacked VLAN interfaces will lose HW offloading, while other VLANs created directly on the bridge interface can still use HW offloading. |
Only the devices listed in the table below support L3 HW Offloading.
L3HW Device Support
Only the devices listed in the table below support L3 HW Offloading.
CRS3xx: Switch DX3000 and DX2000 Series
The devices below are based on Marvell 98DX224S, 98DX226S, or 98DX3236 switch chip models. These devices do not support Fasttrack or NAT connection offloading.
The 98DX3255 and 98DX3257 models are exceptions, which have a feature set of the DX8000 rather than the DX3000 series.
Model | Switch Chip | Release | IPv4 Route Prefixes1 | IPv6 Route Prefixes2 | Nexthops | ECMP paths per prefix3 |
---|---|---|---|---|---|---|
CRS305-1G-4S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
CRS310-1G-5S-4S+ | 98DX226S | 7.1 | 13312 | 3328 | 4K | 8 |
CRS310-8G+2S+ | 98DX226S | 7.1 | 13312 | 3328 | 4K | 8 |
CRS318-1Fi-15Fr-2S | 98DX224S | 7.1 | 13312 | 3328 | 4K | 8 |
CRS318-16P-2S+ | 98DX226S | 7.1 | 13312 | 3328 | 4K | 8 |
CRS326-24G-2S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
CRS328-24P-4S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
CRS328-4C-20S-4S+ | 98DX3236 | 7.1 | 13312 | 3328 | 4K | 8 |
1 Since the total amount of routes that can be offloaded is limited, prefixes with higher netmask are preferred to be forwarded by hardware (e.g., /32, /30, /29, etc.), any other prefixes that do not fit in the HW table will be processed by the CPU. Directly connected hosts are offloaded as /32 (IPv4) or /128 (IPv6) route prefixes. The number of hosts is also limited by max-neighbor-entries in IP Settings / IPv6 Settings.
2 IPv4 and IPv6 routing tables share the same hardware memory.
3 If a route has more paths than the hardware ECMP limit (X), only the first X paths get offloaded.
CRS3xx, CRS5xx: Switch DX8000 and DX4000 Series
The devices below are based on Marvell 98DX8xxx, 98DX4xxx switch chips, or 98DX325x model.
Model | Switch Chip | Release | IPv4 Routes 1 | IPv4 Hosts 7 | IPv6 Routes8 | IPv6 Hosts7 | Nexthops | Fasttrack connections 2,3,4 | NAT entries 2,5 |
---|---|---|---|---|---|---|---|---|---|
CRS317-1G-16S+ | 98DX8216 | 7.1 | 120K - 240K | 64K | 30K - 40K | 32K | 8K | 4.5K | 4K |
CRS309-1G-8S+ | 98DX8208 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 4.5K | 3.9K |
CRS312-4C+8XG | 98DX8212 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
CRS326-24S+2Q+ | 98DX8332 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
CRS354-48G-4S+2Q+, CRS354-48P-4S+2Q+ | 98DX3257 6 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
CRS504-4XQ | 98DX4310 | 7.1 | 60K - 120K | 64K | 15K - 20K | 32K | 8K | 4.5K | 4K |
CRS510-8XS-2XQ | 98DX4310 | 7.3 | 60K - 120K | 64K | 15K - 20K | 32K | 8K | 4.5K | 4K |
CRS518-16XS-2XQ | 98DX8525 | 7.3 | 60K - 120K | 64K | 15K - 20K | 32K | 8K | 4.5K | 4K |
1 Depends on the complexity of the routing table. Whole-byte IP prefixes (/8, /16, /24, etc.) occupy less HW space than others (e.g., /22). Starting with RouterOS v7.3, when the Routing HW table gets full, only routes with longer subnet prefixes are offloaded (/30, /29, /28, etc.) while the CPU processes the shorter prefixes. In RouterOS v7.2 and before, Routing HW memory overflow led to undefined behavior. Users can fine-tune what routes to offload via routing filters (for dynamic routes) or suppressing hardware offload of static routes. IPv4 and IPv6 routing tables share the same hardware memory.
2 When the HW limit of Fasttrack or NAT entries is reached, other connections will fall back to the CPU. MikroTik's smart connection offload algorithm ensures that the connections with the most traffic are offloaded to the hardware.
3 Fasttrack connections share the same HW memory with ACL rules. Depending on the complexity, one ACL rule may occupy the memory of 3-6 Fasttrack connections.
4 MPLS shares the HW memory with Fasttrack connections. Moreover, enabling MPLS requires the allocation of the entire memory region, which could otherwise store up to 768 (0.75K) Fasttrack connections. The same applies to the Bridge Port Extender. However, MPLS and BPE may use the same memory region, so enabling them both doesn't double the limitation of Fasttrack connections.
5 If a Fasttrack connection requires Network Address Translation, a hardware NAT entry is created. The hardware supports both SRCNAT and DSTNAT.
6 The switch chip has a feature set of the DX8000 series.
7 DX4000/DX8000 switch chips store directly connected hosts, IPv4 /32, and IPv6 /128 route entries in the FDB table rather than the routing table. The HW memory is shared between regular FDB L2 entries (MAC), IPv4, and IPv6 addresses. The number of hosts is also limited by max-neighbor-entries in IP Settings / IPv6 Settings.
8 IPv4 and IPv6 routing tables share the same hardware memory.
CCR2000
Model | Switch Chip | Release | IPv4 Routes | IPv4 Hosts | IPv6 Routes | IPv6 Hosts | Nexthops | Fasttrack connections | NAT entries |
---|---|---|---|---|---|---|---|---|---|
CCR2116-12G-4S+ | 98DX3255 1 | 7.1 | 16K - 36K | 16K | 4K - 6K | 8K | 8K | 2.25K | 2.25K |
CCR2216-1G-12XS-2XQ | 98DX8525 | 7.1 | 60K - 120K | 64K | 15K - 20K | 32K | 8k | 4.5K | 4K |
1 The switch chip has a feature set of the DX8000 series.
Page edited by Guntis G. - "distance"
- Overview
- WiFi Terminology
- Basic Configuration
- Configuration profiles
- Access List
- Frequency scan
- Scan command
- Sniffer
- WPS
- Radios
- Registration table
- WiFi CAPsMAN
- Advanced examples
- Replacing 'wireless' package
- Property Reference
- AAA properties
- Channel properties
- Configuration properties
- Datapath properties
- Security Properties
- Steering properties
- Miscellaneous properties
- Read-only properties
- Access List
- Frequency scan
- Flat-snoop
- Scan command
- Sniffer
- WPS
- Radios
- Registration table
- CAPsMAN Global Configuration
- CAPsMAN Provisioning
- CAP configuration
Overview
The 'WiFi' configuration menu, introduced in RouterOS 7.13, is a RouterOS menu for managing Wi-Fi 5 wave2 and newer WiFi interfaces.
Devices with compatible radios also require either the 'wifi-qcom-ac' driver package (for 802.11ac chipsets) or the 'wifi-qcom' driver package for 802.11ax and newer chipsets.
The configuration menu used to be called 'wifiwave2' in RouterOS versions before 7.13, where it was a part of the 'wifiwave2' software package.
WiFi Terminology
Before we move on let's familiarize ourselves with terms important for understanding the operation of the menu. These terms will be used throughout the article.
- Profile - refers to the configuration preset created under one of this WiFi sub-menus: aaa, channel, security, datapath, or interworking.
- Configuration profile - configuration preset defined under /interface/wifi/configuration, it can reference various profiles.
- Station - wireless client.
Basic Configuration
Basic password-protected AP
/interface/wifi set wifi1 disabled=no configuration.country=Latvia configuration.ssid=MikroTik security.authentication-types=wpa2-psk,wpa3-psk security.passphrase=8-63_characters
Open AP with OWE transition mode
Opportunistic wireless encryption (OWE) allows the creation of wireless networks that do not require the knowledge of a password to connect, but still offer the benefits of traffic encryption and management frame protection. It is an improvement on regular open access points.
However, since a network cannot be simultaneously encrypted and unencrypted, 2 separate interface configurations are required to offer connectivity to older devices that do not support OWE and offer the benefits of OWE to devices that do.
This configuration is referred to as OWE transition mode.
/interface/wifi add master-interface=wifi1 name=wifi1_owe configuration.ssid=MikroTik_OWE security.authentication-types=owe security.owe-transition-interface=wifi1 configuration.hide-ssid=yes set wifi1 configuration.country=Latvia configuration.ssid=MikroTik security.authentication-types="" security.owe-transition-interface=wifi1_owe enable wifi1,wifi1_owe
Client devices that support OWE will prefer the OWE interface. If you don't see any devices in your registration table that are associated with the regular open AP, you may want to move on from running a transition mode setup to a single OWE-encrypted interface.
Resetting configuration
WiFi interface configurations can be reset by using the 'reset' command.
/interface/wifi reset wifi1
Configuration profiles
One of the new WiFi additions is configuration profiles, you can create various presets, that can be assigned to interfaces as needed. Configuration settings for WiFi are grouped in profiles according to the parameter sections found at the end of this page - aaa, channel, configuration, datapath, interworking, and security, and can then be assigned to interfaces. Configuration profiles can include other profiles as well as separate parameters from other categories.
This optional flexibility is meant to allow each user to arrange their configuration in a way that makes the most sense for them, but it also means that each parameter may have different values assigned to it in different sections of the configuration.
The following priority determines, which value is used:
- Value in interface settings
- Value in a profile assigned to the interface
- Value in configuration profile assigned to interface
- Value in a profile assigned to the configuration profile (which in turn is assigned to the interface).
If you are at any point unsure of which parameter value will be used for an interface, consult the actual-configuration menu. For an example of configuration profile usage, see the following example.
# Creating a security profile, which will be common for both interfaces /interface wifi security add name=common-auth authentication-types=wpa2-psk,wpa3-psk passphrase="diceware makes good passwords" wps=disable # Creating a common configuration profile and linking the security profile to it /interface wifi configuration add name=common-conf ssid=MikroTik country=Latvia security=common-auth # Creating separate channel configurations for each band /interface wifi channel add name=ch-2ghz frequency=2412,2432,2472 width=20mhz add name=ch-5ghz frequency=5180,5260,5500 width=20/40/80mhz # Assigning to each interface the common profile as well as band-specific channel profile /interface wifi set wifi1 channel=ch-2ghz configuration=common-conf disabled=no set wifi2 channel=ch-5ghz configuration=common-conf disabled=no /interface/wifi/actual-configuration print 0 name="wifi1" mac-address=74:4D:28:94:22:9A arp-timeout=auto radio-mac=74:4D:28:94:22:9A configuration.ssid="MikroTik" .country=Latvia security.authentication-types=wpa2-psk,wpa3-psk .passphrase="diceware makes good passwords" .wps=disable channel.frequency=2412,2432,2472 .width=20mhz 1 name="wifi2" mac-address=74:4D:28:94:22:9B arp-timeout=auto radio-mac=74:4D:28:94:22:9B configuration.ssid="MikroTik" .country=Latvia security.authentication-types=wpa2-psk,wpa3-psk .passphrase="diceware makes good passwords" .wps=disable channel.frequency=5180,5260,5500 .width=20/40/80mhz
Access List
The access list provides multiple ways of filtering and managing wireless connections.
RouterOS will check each new connection to see if its parameters match the parameters specified in any access list rule.
The rules are checked in the order they appear in the list. Only management actions specified in the first matching rule are applied to each connection.
Connections, which have been accepted by an access list rule, will be periodically checked, to see if they remain within the permitted time and signal-range. If they do not, they will be terminated.
Take care when writing access list rules which reject clients. After being repeatedly rejected by an AP, a client device may start avoiding it.
The access list has two kinds of parameters - filtering, and action. Filtering properties are only used for matching clients, to whom the access list rule should be applied to. Action parameters can change connection parameters for that specific client and potentially overriding its default connection parameters with ones specified in the access list rule.
MAC address authentication
Implemented through the query-radius action, MAC address authentication is a way to implement a centralized whitelist of client MAC addresses using a RADIUS server.
When a client device tries to associate with an AP, which is configured to perform MAC address authentication, the AP will send an access-request message to a RADIUS server with the device's MAC address as the user name and an empty password. If the RADIUS server answers with access-accept to such a request, the AP proceeds with whatever regular authentication procedure (passphrase or EAP authentication) is configured for the interface.
Access rule examples
Only accept connections to guest network from nearby devices during business hours
/interface/wifi/access-list/print detail Flags: X - disabled 0 signal-range=-60..0 allow-signal-out-of-range=5m ssid-regexp="MikroTik Guest" time=7h-19h,mon,tue,wed,thu,fri action=accept 1 ssid-regexp="MikroTik Guest" action=reject
Reject connections from locally-administered ('anonymous'/'randomized') MAC addresses
/interface/wifi/access-list/print detail Flags: X - disabled 0 mac-address=02:00:00:00:00:00 mac-address-mask=02:00:00:00:00:00 action=reject
Assigning a different passphrase for a specific client can be useful, if you need to provide wireless access to a client, but don't want to share your wireless password, or don't want to create a separate SSID. When the matching client connects to this network, instead of using the password defined in the interface configuration, the access list will make that client use a different password. Just make sure that the specific client doesn't get matched by a more generic access list rule first.
/interface wifi access-list add action=accept disabled=no mac-address=22:F9:70:E5:D2:8E interface=wifi1 passphrase=StrongPassword
Frequency scan
The '/interface/wifi/frequency-scan wifi1' command provides information about RF conditions on available channels that can be obtained by running the frequency-scan command. Used to approximate the spectrum usage, it can be useful to find less crowded frequencies.
Running a frequency scan will disconnect all connected clients, or if the interface is in station mode, it will disconnect from AP.
Scan command
The '/interface wifi scan' command will scan for access points and print out information about any APs it detects. It doesn't show the frequency usage, per channel, but it will reveal all access points that are transmitting. You can use the "connect" button, to initiate a connection to a specific AP.
The scan command takes all the same parameters as the frequency-scan command.
Sniffer
The sniffer command enables monitor mode on a wireless interface. This turns the interface into a passive receiver for all WiFi transmissions.
The command continuously prints out information on received packets and can save them locally to a pcap file or stream them using the TZSP protocol.
The sniffer will operate on whichever channel is configured for the chosen interface.
WPS
WPS client
The wps-client command enables obtaining authentication information from a WPS-enabled AP.
/interface/wifi/wps-client wifi1
WPS server
An AP can be made to accept WPS authentication by a client device for 2 minutes by running the following command.
/interface/wifi wps-push-button wifi1
Radios
Information about the capabilities of each radio can be gained by running the `/interface/wifi/radio print detail` command. It can be useful to see what bands are supported by the interface and what channels can be selected. The country profile that is applied to the interface will influence the results.
interface/wifi/radio/print detail Flags: L - local 0 L radio-mac=48:A9:8A:0B:F7:4A phy-id=0 tx-chains=0,1 rx-chains=0,1 bands=5ghz-a:20mhz,5ghz-n:20mhz,20/40mhz,5ghz-ac:20mhz,20/40mhz,20/40/80mhz,5ghz-ax:20mhz, 20/40mhz,20/40/80mhz ciphers=tkip,ccmp,gcmp,ccmp-256,gcmp-256,cmac,gmac,cmac-256,gmac-256 countries=all 5g-channels=5180,5200,5220,5240,5260,5280,5300,5320,5500,5520,5540,5560,5580,5600,5620,5640,5660, 5680,5700,5720,5745,5765,5785,5805,5825 max-vlans=128 max-interfaces=16 max-station-interfaces=3 max-peers=120 hw-type="QCA6018" hw-caps=sniffer interface=wifi1 current-country=Latvia current-channels=5180/a,5180/n,5180/n/Ce,5180/ac,5180/ac/Ce,5180/ac/Ceee,5180/ax,5180/ax/Ce, 5180/ax/Ceee,5200/a,5200/n,5200/n/eC,5200/ac,5200/ac/eC,5200/ac/eCee,5200/ax... ...5680/n/eC,5680/ac,5680/ac/eC,5680/ax,5680/ax/eC,5700/a,5700/n,5700/ac,5700/ax current-gopclasses=115,116,128,117,118,119,120,121,122,123 current-max-reg-power=30
While Radio information gives us information about supported channel width, it is also possible to deduce this information from the product page, to do so you need to check the following parameters: number of chains, max data rate. Once you know these parameters, you need to check the modulation and coding scheme (MCS) table, for example, here: https://mcsindex.com/.
If we take hAP ax2, as an example, we can see that number of chains is 2, and the max data rate is 1200 - 1201 in the MCS table. In the MCS table we need to find entry for 2 spatial streams - chains, and the respective data rate, which in this case shows us that 80MHz is the maximum supported channel width.
Registration table
'/interface/wifi/registration-table/' displays a list of connected wireless clients and detailed information about them.
De-authentication
Wireless peers can be manually de-authenticated (forcing re-association) by removing them from the registration table.
/interface/wifi/registration-table remove [find where mac-address=02:01:02:03:04:05]
WiFi CAPsMAN
WiFi CAPsMAN allows applying wireless settings to multiple MikroTik WiFi AP devices from a central configuration interface.
More specifically, the Controlled Access Point system Manager (CAPsMAN) allows the centralization of wireless network management. When using the CAPsMAN feature, the network will consist of a number of 'Controlled Access Points' (CAP) that provide wireless connectivity and a 'system Manager' (CAPsMAN) that manages the configuration of the APs, it also takes care of client authentication.
WiFi CAPsMAN only passes wireless configuration to the CAP, all forwarding decisions are left to the CAP itself - there is no CAPsMAN forwarding mode.
Requirements:
- Any RouterOS device, that supports the WiFi package, can be a controlled wireless access point (CAP) as long as it has at least a Level 4 RouterOS license.
- WiFi CAPsMAN server can be installed on any RouterOS device that supports the WiFi package, even if the device itself does not have a wireless interface
- Unlimited CAPs (access points) supported by CAPsMAN
WiFi CAPsMAN can only control WiFi interfaces, and WiFi CAPs can join only WiFi CAPsMAN, similarly, regular CAPsMAN only supports non-WiFi caps.
The CAPs don't send traffic usage information to CAPsMAN.
CAPsMAN - CAP simple configuration example:
CAPsMAN in WiFi uses the same menu as a regular WiFi interface, meaning when you pass configuration to CAPs, you have to use the same configuration, security, channel configuration, etc. as you would for regular WiFi interfaces.
CAPsMAN:
#create a security profile /interface wifi security add authentication-types=wpa3-psk name=sec1 passphrase=HaveAg00dDay #create configuraiton profiles to use for provisioning /interface wifi configuration add country=Latvia name=5ghz security=sec1 ssid=CAPsMAN_5 add name=2ghz security=sec1 ssid=CAPsMAN2 add country=Latvia name=5ghz_v security=sec1 ssid=CAPsMAN5_v #configure provisioning rules, configure band matching as needed /interface wifi provisioning add action=create-dynamic-enabled master-configuration=5ghz slave-configurations=5ghz_v supported-bands=\ 5ghz-n add action=create-dynamic-enabled master-configuration=2ghz supported-bands=2ghz-n #enable CAPsMAN service /interface wifi capsman set ca-certificate=auto enabled=yes
CAP:
#enable CAP service, in this case CAPsMAN is on same LAN, but you can also specify "caps-man-addresses=x.x.x.x" here /interface/wifi/cap set enabled=yes #set configuration.manager= on the WiFi interface that should act as CAP /interface/wifi/set wifi1,wifi2 configuration.manager=capsman-or-local
If the CAP is hAP ax2 or hAP ax3, it is strongly recommended to enable RSTP in the bridge configuration, on the CAP
configuration.manager should only be set on the CAP device itself, don't pass it to the CAP or configuration profile that you provision.
The interface that should act as CAP needs additional configuration under "interface/wifi/set wifiX configuration.manager="
CAPsMAN - CAP VLAN configuration example:
In this example, we will assign VLAN10 to our main SSID, and will add VLAN20 for the guest network, ether5 from CAPsMAN is connected to CAP.
CAPs using "wifi-qcom" package can get "vlan-id" via Datapath from CAPsMAN, CAPs using "wifi-qcom-ac" package will need to use the configuration provided at the end of this example.
CAPsMAN:
/interface bridge add name=br vlan-filtering=yes /interface vlan add interface=br name=MAIN vlan-id=10 add interface=br name=GUEST vlan-id=20 /interface wifi datapath add bridge=br name=MAIN vlan-id=10 add bridge=br name=GUEST vlan-id=20 /interface wifi security add authentication-types=wpa2-psk,wpa3-psk ft=yes ft-over-ds=yes name=Security_MAIN passphrase=HaveAg00dDay add authentication-types=wpa2-psk,wpa3-psk ft=yes ft-over-ds=yes name=Security_GUEST passphrase=HaveAg00dDay /interface wifi configuration add datapath=MAIN name=MAIN security=Security_MAIN ssid=MAIN_Network add datapath=GUEST name=GUEST security=Security_GUEST ssid=GUEST_Network /ip pool add name=dhcp_pool0 ranges=192.168.1.2-192.168.1.254 add name=dhcp_pool1 ranges=192.168.10.2-192.168.10.254 add name=dhcp_pool2 ranges=192.168.20.2-192.168.20.254 /ip dhcp-server add address-pool=dhcp_pool0 disabled=yes interface=br name=dhcp1 add address-pool=dhcp_pool1 interface=MAIN name=dhcp2 add address-pool=dhcp_pool2 interface=GUEST name=dhcp3 /interface bridge port add bridge=br interface=ether5 add bridge=br interface=ether4 add bridge=br interface=ether3 add bridge=br interface=ether2 /interface bridge vlan add bridge=br tagged=br,ether5,ether4,ether3,ether2 vlan-ids=20 add bridge=br tagged=br,ether5,ether4,ether3,ether2 vlan-ids=10 /interface wifi capsman set enabled=yes interfaces=br /interface wifi provisioning add action=create-dynamic-enabled master-configuration=MAIN slave-configurations=GUEST supported-bands=5ghz-ax add action=create-dynamic-enabled master-configuration=MAIN slave-configurations=GUEST supported-bands=2ghz-ax /ip address add address=192.168.1.1/24 interface=br network=192.168.1.0 add address=192.168.10.1/24 interface=MAIN network=192.168.10.0 add address=192.168.20.1/24 interface=GUEST network=192.168.20.0 /ip dhcp-server network add address=192.168.1.0/24 gateway=192.168.1.1 add address=192.168.10.0/24 gateway=192.168.10.1 add address=192.168.20.0/24 gateway=192.168.20.1 /system identity set name=cAP_Controller
CAP using "wifi-qcom" package:
/interface bridge add name=bridgeLocal /interface wifi datapath add bridge=bridgeLocal comment=defconf disabled=no name=capdp /interface wifi set [ find default-name=wifi1 ] configuration.manager=capsman datapath=capdp disabled=no set [ find default-name=wifi2 ] configuration.manager=capsman datapath=capdp disabled=no /interface bridge port add bridge=bridgeLocal comment=defconf interface=ether1 add bridge=bridgeLocal comment=defconf interface=ether2 add bridge=bridgeLocal comment=defconf interface=ether3 add bridge=bridgeLocal comment=defconf interface=ether4 add bridge=bridgeLocal comment=defconf interface=ether5 /interface wifi cap set discovery-interfaces=bridgeLocal enabled=yes slaves-datapath=capdp /ip dhcp-client add interface=bridgeLocal disabled=no
CAP using "wifi-qcom-ac" package:
/interface bridge add name=bridgeLocal vlan-filtering=yes /interface wifi set [ find default-name=wifi1 ] configuration.manager=capsman disabled=no set [ find default-name=wifi2 ] configuration.manager=capsman disabled=no add disabled=no master-interface=wifi1 name=wifi21 add disabled=no master-interface=wifi2 name=wifi22 /interface bridge port add bridge=bridgeLocal comment=defconf interface=ether1 add bridge=bridgeLocal comment=defconf interface=ether2 add bridge=bridgeLocal comment=defconf interface=ether3 add bridge=bridgeLocal comment=defconf interface=ether4 add bridge=bridgeLocal comment=defconf interface=ether5 add bridge=bridgeLocal interface=wifi1 pvid=10 add bridge=bridgeLocal interface=wifi21 pvid=20 add bridge=bridgeLocal interface=wifi2 pvid=10 add bridge=bridgeLocal interface=wifi22 pvid=20 /interface bridge vlan add bridge=bridgeLocal tagged=ether1 untagged=wifi1,wifi2 vlan-ids=10 add bridge=bridgeLocal tagged=ether1 untagged=wifi21,wifi22 vlan-ids=20 /interface wifi cap set discovery-interfaces=bridgeLocal enabled=yes slaves-static=yes
Additionally, the configuration below has to be added to the CAPsMAN configuration:
/interface wifi datapath add bridge=br name=DP_AC /interface wifi configuration add datapath=DP_AC name=MAIN_AC security=Security_MAIN ssid=MAIN_Network add datapath=DP_AC name=GUEST_AC security=Security_GUEST ssid=GUEST_Network /interface wifi provisioning add action=create-dynamic-enabled master-configuration=MAIN_AC slave-configurations=GUEST_AC supported-bands=5ghz-ac add action=create-dynamic-enabled master-configuration=MAIN_AC slave-configurations=GUEST_AC supported-bands=2ghz-n
Passing datapaths "MAIN/GUEST" from the start of the example to "wifi-qcom-ac" CAP would be misconfiguration, make sure to use datapath without "vlan-id" specified to such devices.
Advanced examples
Replacing 'wireless' package
Some MikroTik Wi-Fi 5 APs, which ship with their interfaces managed by the 'wireless' menu, can install the additional 'wifi-qcom-ac' package to make their interfaces compatible with the 'wifi' menu instead.
To do this, it is necessary to uninstall the 'wireless' package, then install 'wifi-qcom-ac'.
Compatibility
The wifi-qcom-ac package includes alternative drivers for IPQ4018/4019 and QCA9984 radios that make them compatible with the WiFi configuration menu. For possible, wifi-qcom-ac/wifi-qcom/wireless, package combinations, please see the package types section here.
As a rule of thumb, the package is compatible with 802.11ac products, which have an ARM CPU. It is NOT compatible with any of our 802.11ac products which have a MIPS CPU.
Compatibility | Devices |
---|---|
Compatible | Audience, Audience LTE kit, Chateau (all variants of D53), hAP ac^2, hAP ac^3, cAP ac, cAP XL ac, LDF 5 ac, LHG XL 5 ac, LHG XL 52 ac, NetMetal ac^2, mANTBox 52 15s, wAP ac (RBwAPG-5HacD2HnD), SXTsq 5 ac |
Incompatible | RB4011iGS+5HacQ2HnD-IN (no support for the 2.4GHz interface), Cube 60Pro ac (no support for 60GHz interface), wAP ac (RBwAPG-5HacT2HnD) and all other devices with a MIPSBE CPU |
Benefits
- WPA3 authentication and OWE (opportunistic wireless encryption)
- 802.11w standard management frame protection
- 802.11r/k/v
- MU-MIMO and beamforming
- 400Mb/s maximum data rate in the 2.4GHz band for IPQ4019 interfaces
These benefits apply both to the wifi-qcom and wifi-qcom-ac packages.
Lost features
The following notable features are lost when running 802.11ac products with drivers that are compatible with the 'wifi' management interface
- Nstreme and Nv2 wireless protocols
- VLAN configuration in the wireless settings (Per-interface VLANs can be configured in bridge settings)
- Compatibility with station-bridging as implemented in the 'wireless' package, station-bridge only works between the same type of drivers. Wifi to Wifi, and Wireless to Wireless.
Property Reference
AAA properties
Properties in this category configure an access point's interaction with AAA (RADIUS) servers.
Certain parameters in the table below take format-string as their value. In a format-string, certain characters are interpreted in the following way:
Character | Interpretation |
---|---|
a | Hexadecimal character making up the MAC address of the client device in lowercase |
A | Hexadecimal character making up the MAC address of the client device in upper case |
i | Hexadecimal character making up the MAC address of the AP's interface in lowercase |
I (capital 'i') | Hexadecimal character making up the MAC address of the AP's interface in upper case |
N | The entire name of the AP's interface (e.g. 'wifi1') |
S | The entire SSID |
All other characters are used without interpreting them in any way. For examples, see default values.
Property | Description |
---|---|
called-format (format-string) | Format for the value of the Called-Station-Id RADIUS attribute, in AP's messages to RADIUS servers. Default: II-II-II-II-II-II:S |
calling-format (format-string) | Format for the value of the Calling-Station-Id RADIUS attribute, in AP's messages to RADIUS servers. Default: AA-AA-AA-AA-AA-AA |
interim-update (time interval) | Interval at which to send interim updates about traffic accounting to the RADIUS server. Default: 5m |
mac-caching (time interval | 'disabled') | Length of time to cache RADIUS server replies, when MAC address authentication is enabled. Default value: disabled. |
name (string) | A unique name for the AAA profile. No default value. |
nas-identifier (string) | Value of the NAS-Identifier attribute, in AP's messages to RADIUS servers. Defaults to the host name of the device (/system/identity). |
password-format (format-string) | Format for value to use in calculating the value of the User-Password attribute in AP's messages to RADIUS servers when performing MAC address authentication. Default value: "" (an empty string). |
username-format (format-string) | Format for the value of the User-Name attribute in APs messages to RADIUS servers when performing MAC address authentication. Default value : |
Channel properties
Properties in this category specify the desired radio channel.
Property | Description |
---|---|
band (2ghz-g | 2ghz-n | 2ghz-ax | 5ghz-a | 5ghz-ac | 5ghz-an | 5ghz-ax) | Frequency band and wireless standard that will be used by the AP. Defaults to newest supported standard. |
frequency (list of integers or integer ranges) | For an interface in AP mode, specifies frequencies (in MHz) to consider when picking control channel center frequency. For an interface in station mode, specifies frequencies on which to scan for APs. Leave unset (default) to consider all frequencies supported by the radio and permitted by the applicable regulatory profille. The parameter can contain 1 or more comma-separated values of integers or, optionally, ranges of integers denoted using the syntax RangeBeginning-RangeEnd:RangeStep Examples of valid channel.frequency values:
|
secondary-frequency (list of integers | 'disabled') | Frequency (in MHz) to use for the center of the secondary part of a split 80+80MHz channel. Only official 80MHz channels (5210, 5290, 5530, 5610, 5690, 5775) are supported. Leave unset (default) for automatic selection of secondary channel frequency. |
skip-dfs-channels (10min-cac | all | disabled) | Whether to avoid using channels, on which channel availability check (listening for presence of radar signals) is required.
|
width ( 20mhz | 20/40mhz | 20/40mhz-Ce | 20/40mhz-eC | 20/40/80mhz | 20/40/80+80mhz | 20/40/80/160mhz) | Width of radio channel. Defaults to widest channel supported by the radio hardware. |
reselect-interval (time interval) | Specifies when the interface should rescan channel availability and select the most appropriate one to use. Specifying intervall will allow the system to select this interval dynamically and randomly. This helps to avoid a situation when many APs at the same time scan network, select the same channel and prefer to use it at the same time. |
Configuration properties
This section includes properties relating to the operation of the interface and the associated radio.
Property | Description |
---|---|
antenna-gain (integer 0..30) | Overrides the default antenna gain. The master interface of each radio sets the antenna gain for every interface which uses the same radio. This setting cannot override the antenna gain to be lower than the minimum antenna gain of a radio. |
beacon-interval (time interval 100ms..1s) | Interval between beacon frames of an AP. Default: 100ms. The 802.11 standard defines beacon interval in terms of time units (1 TU = 1.024 ms). The actual interval between beacons will be 1 TU for every 1 ms configured. Every AP running on the same radio (i.e. a master AP and all its 'virtual'/'slave' APs) must use the same beacon interval. |
chains (list of integer 0..7 ) | Radio chains to use for receiving signals. Defaults to all chains available to the corresponding radio hardware. |
country (name of a country) | Determines, which regulatory domain restrictions are applied to an interface. Defaults to "Latvia". It is important to set this value correctly to comply with local regulations and ensure interoperability with other devices. |
distance () | Maximum link distance in kilometers, needs to be set for long-range outdoor links. The value should reflect the distance to the AP or station that is furthest from the device. Unconfigured value allows usage of 3KM links.
|
dtim-period (integer 1..255) | Period at which to transmit multicast traffic, when there are client devices in power save mode connected to the AP. Expressed as a multiple of the beacon interval. Higher values enable client devices to save more energy, but increase network latency. Default: 1 |
hide-ssid (no | yes) |
Default: no |
manager (capsman | capsman-or-local | local) | capsman - the interface will act as CAP only, this option should not be passed via provisioning rules to the CAP capsman-or-local - the interface will get configuration via CAPsMAN or use its own, if /interface/wifi/cap is not enabled. local - interface won't contact CAPsMAN in order to get configuration. Default: local |
mode (ap | station) | Interface operation mode
The station-bridge mode, as implemented for 'wifi' intefaces, is incompatible with APs running the older 'wireless' package and vice versa. |
multicast-enhance (enabled | disabled) | With the multicast-enhance feature enabled, an AP will convert every multicast-addressed IP or IPv6 packet into multiple unicast-addressed frames for each connected station. Default: disabled |
qos-classifier (dscp-high-3-bits | priority) |
Default: priority 802.11ac wireless chipsets do not support the dscp-high-3-bits classifier mode. For 802.11ac interfaces, please see DSCP from priority. |
ssid (string) | The name of the wireless network, aka the (E)SSID. No default value. |
tx-chains (list of integer 0..7) | Radio chains to use for transmitting signals. Defaults to all chains available to the corresponding radio hardware. |
tx-power (integer 0..40) | A limit on the transmit power (in dBm) of the interface. Can not be used to set power above limits imposed by the regulatory profile. Unset by default. |
Datapath properties
Parameters relating to forwarding packets to and from wireless client devices.
Property | Description |
---|---|
bridge (bridge interface) | Bridge interface to add interface to, as a bridge port. Virtual ('slave') interfaces are by default added to the same bridge, if any, as the corresponding master interface. Master interfaces are not by default added to any bridge. |
bridge-cost (integer) | Bridge port cost to use when adding as bridge port. Default: 10 |
bridge-horizon (none | integer) | Bridge horizon to use when adding as bridge port Default: none. |
client-isolation (no | yes) | Determines whether client devices connecting to this interface are (by default) isolated from others or not. This policy can be overridden on a per-client basis using access list rules, so a an AP can have a mixture of isolated and non-isolated clients. Traffic from an isolated client will not be forwarded to other clients and unicast traffic from a non-isolated client will not be forwarded to an isolated one. Default: no |
interface-list (interface list) | List to which add the interface as a member. No default value. |
vlan-id (none | integer 1..4095) | Default VLAN ID to assign to client devices connecting to this interface (only relevant to interfaces in AP mode). 802.11ac chipsets do not support this type of VLAN tagging , but they can be configured as VLAN access ports in bridge settings. |
Security Properties
Parameters relating to authentication.
Property | Description |
---|---|
authentication-types (list of wpa-psk, wpa2-psk, wpa-eap, wpa2-eap, wpa3-psk, owe, wpa3-eap, wpa3-eap-192) | Authentication types to enable on the interface. The default value is an empty list (no authentication, an open network). Configuring a passphrase adds to the default list the wpa2-psk authentication method (if the interface is an AP) or both wpa-psk and wpa2-psk (if the interface is a station). Configuring an eap-username and an eap-password adds to the default list wpa-eap and wpa2-eap authentication methods. |
connect-group ( string ) | APs within the same connect group do not allow more than 1 client device with the same MAC address. This is to prevent malicious authorized users from intercepting traffic intended to other users ('MacStealer' attack) or performing a denial of service attack by spoofing the MAC address of a victim. Handling of new connections with duplicate MAC addresses depends on the connect-priority of AP interfaces involved. By default, all APs are assigned the same connect-group. |
connect-priority (accept-priority/hold-priority (integers)) | These parameters determine, how a connection is handled if the MAC address of the client device is the same as that of another active connection to another AP. If omitted, hold-priority is the same as accept-priority. |
dh-groups (list of 19, 20, 21) | Identifiers of elliptic curve cryptography groups to use in SAE (WPA3) authentication. |
disable-pmkid (no | yes) | For interfaces in AP mode, disables inclusion of a PMKID in EAPOL frames. Disabling PMKID can cause compatibility issues with client devices that make use of it.
|
eap-accounting (no | yes) | Send accounting information to RADIUS server for EAP-authenticated peers. Default: no. |
Properties related to EAP, are only relevant to interfaces in station mode. APs delegate (passthrough) EAP authentication to the RADIUS server. | |
eap-anonymous-identity (string) | Optional anonymous identity for EAP outer authentication. No default value. |
eap-certificate-mode (dont-verify-certificate | no-certificates | verify-certificate | verify-certificate-with-crl) | Policy for handling the TLS certificate of the RADIUS server.
|
eap-methods (list of peap, tls, ttls) | EAP methods to consider for authentication. Defaults to all supported methods. |
eap-password (string) | Password to use, when the chosen EAP method requires one. No default value. |
eap-tls-certificate (certificate) | Name or id of a certificate in the device's certificate store to use, when the chosen EAP authentication method requires one. No default value. |
eap-username (string) | Username to use when the chosen EAP method requires one. No default value. |
Take care when configuring encryption ciphers. All client devices MUST support the group encryption cipher used by the AP to connect, and some client devices (notably, Intel® 8260) will also fail to connect if the list of unicast ciphers includes any they don't support. | |
encryption (list of ccmp, ccmp-256, gcmp, gcmp-256, tkip) | A list of ciphers to support for encrypting unicast traffic. Defaults to ccmp. |
Properties related to 802.11r fast BSS transition only apply to interfaces in AP mode. WiFi interfaces in station mode do not support 802.11r. For a client device to successfully roam between 2 APs, the APs need to be managed by the same instance of RouterOS. For information on how to centrally manage multiple APs, see CAPsMAN | |
ft (no | yes) | Whether to enable 802.11r fast BSS transitions ( roaming). Default: no. |
ft-mobility-domain (integer 0..65535) | The fast BSS transition mobility domain ID. Default: 44484 (0xADC4). |
ft-nas-identifier (string of 2..96 hex characters) | Fast BSS transition PMK-R0 key holder identifier. Default: MAC address of the interface. |
ft-over-ds (no | yes ) | Whether to enable fast BSS transitions over DS (distributed system). Default: no. |
ft-preserve-vlanid (no | yes ) |
The default behavior is essential when relying on a RADIUS server to assign VLAN IDs to users, since a RADIUS server is only used for initial authentication. |
ft-r0-key-lifetime (time interval 1s..6w3d12h15m) | Lifetime of the fast BSS transition PMK-R0 encryption key. Default: 600000s (~7 days) |
ft-reassociation-deadline (time interval 0..70s) | Fast BSS transition reassociation deadline. Default: 20s. |
group-encryption (ccmp | ccmp-256 | gcmp | gcmp-256 | tkip) | Cipher to use for encrypting multicast traffic. Defaults to ccmp. |
group-key-update (time interval) | Interval at which the group temporal key (key for encrypting broadcast traffic) is renewed. Defaults to 24 hours. |
management-encryption (cmac | cmac-256 | gmac | gmac-256) | Cipher to use for encrypting protected management frames. Defaults to cmac. |
management-protection (allowed | disabled | required) | Whether to use 802.11w management frame protection. Incompatible with management frame protection in standard wireless package. The default value depends on the value of the selected authentication type. WPA2 allows the use of management protection, WPA3 requires it. |
owe-transition-interface (interface) | Name or internal id of an interface whose MAC address and SSID to advertise as the matching AP when running in OWE transition mode. Required for setting up open APs that offer OWE, but also work with older devices that don't support the standard. See configuration example below. |
passphrase (string of up to 63 characters) | The passphrase to use for PSK authentication types. Defaults to an empty string - "". WPA-PSK and WPA2-PSK authentication requires a minimum of 8 chars, while WPA3-PSK does not have a minimum passphrase length. |
sae-anti-clogging-threshold ('disabled' | integer) | Due to SAE (WPA3) associations being CPU resource intensive, overwhelming an AP with bogus authentication requests makes for a feasible denial-of-service attack. This parameter provides a way to mitigate such attacks by specifying a threshold of in-progress SAE authentications, at which the AP will start requesting that client devices include a cookie bound to their MAC address in their authentication requests. It will then only process authentication requests that contain valid cookies. Default: 5. |
sae-max-failure-rate ('disabled' | integer) | Rate of failed SAE (WPA3) associations per minute, at which the AP will stop processing new association requests. Default: 40. |
sae-pwe (both | hash-to-element | hunting-and-pecking) | Methods to support for deriving SAE password element. Default: both. |
wps (disabled | push-button) |
|
Steering properties
Properties in this category govern mechanisms for advertising potential roaming candidates to client devices.
Property | Description |
---|---|
neighbor-group (string) | When sending neighbor reports and BSS transition management requests, an AP will list all other APs within its neighbor group as potential roaming candidates. By default, a dynamic neighbor group is created for each set of APs with the same SSID and authentication settings. |
rrm (no | yes) | Enables sending of 802.11k neighbor reports. Default: yes |
wnm (no | yes) | Enables sending of solicited 802.11v BSS transition management requests. Default: yes |
Miscellaneous properties
Property | Description |
---|---|
arp (disabled | enabled | local-proxy-arp | proxy-arp | reply-only) | Address Resolution Protocol mode:
|
arp-timeout (time interval | 'auto') | Determines how long a dynamically added ARP table entry is considered valid since the last packet was received from the respective IP address. Value auto equals to the value of arp-timeout in /ip settings, which defaults to 30s. |
disable-running-check (no | yes) |
|
disabled (no | yes) (X) | Hardware interfaces are disabled by default. Virtual interfaces are not. |
mac-address (MAC) | MAC address (BSSID) to use for an interface. Hardware interfaces default to the MAC address of the associated radio interface. Default MAC addresses for virtual interfaces are generated by
|
mtu (integer [32..2290]; Default: 1500) | Layer 3 Maximum transmission unit. |
l2mtu (integer [32..2290]; Default: 2290) | Layer 2 Maximum transmission unit. |
master-interface (interface) | Multiple interface configurations can be run simultaneously on every wireless radio. Only one of them determines the radio's state (whether it is enabled, what frequency it's using, etc). This 'master' interface, is bound to a radio with the corresponding radio-mac. To create additional ('virtual') interface configurations on a radio, they need to be bound to the corresponding master interface. No default value. |
name (string) | A name for the interface. Defaults to wifiN, where N is the lowest integer that has not yet been used for naming an interface. |
Read-only properties
Property | Description |
---|---|
bound (boolean) (B) | True for master interfaces that are currently available for WiFi manager. True for a virtual interface (configurations linked to a master interface) when both the interface itself and its master interface are not disabled and the master interface has a bound flag. |
default-name (string) | The default name for an interface. |
inactive (boolean) (I) | False for interfaces in AP mode when they've selected a channel for operation (i.e. configuration has been successfully applied). False for interfaces in station mode when they've connected to an AP (i.e. configuration has been successfully applied, and an AP with matching settings has been found). True otherwise. |
master (boolean) (M) | True for physical interfaces on the router itself or detected CAP if running as CAPsMAN. False for virtual interfaces. |
radio-mac (MAC) | The MAC address of the associated radio. |
running (boolean) (R) | True, when an interface has established a link to another device. If disable-running-check is set to 'yes', true whenever the interface is not disabled. |
Access List
Filtering parameters | |
---|---|
Parameter | Description |
interface (interface | interface-list | 'any') | Match if connection takes place on the specified interface or interface belonging to a specified list. Default: any. |
mac-address (MAC address) | Match if the client device has the specified MAC address. No default value. |
mac-address-mask (MAC address) | Modifies the mac-address parameter to match if it is equal to the result of performing bit-wise AND operation on the client MAC address and the given address mask. Default: FF:FF:FF:FF:FF:FF (i.e. client's MAC address must match value of mac-address exactly) |
signal-range (min..max) | Match if the strength of the received signal from the client device is within the given range. Default: '-120..120' |
ssid-regexp (regex) | Match if the given regular expression matches the SSID. |
time (start-end,days) | Match during the specified time of day and (optionally) days of week. Default: 0s-1d |
Action parameters | |
---|---|
Parameter | Description |
allow-signal-out-of-range (time period | 'always') | The length of time which a connected peer's signal strength is allowed to be outside the range required by the signal-range parameter, before it is disconnected. If the value is set to 'always', peer signal strength is only checked during association. Default: 0s. |
action (accept | reject | query-radius) | Whether to authorize a connection
Default: accept |
client-isolation (no | yes) | Whether to isolate the client from others connected to the same AP. No default value. |
passphrase (string) | Override the default passphrase with given value. No default value. |
radius-accounting (no | yes) | Override the default RADIUS accounting policy with given value. No default value. |
vlan-id ( none | integer 1..4095 ) | Assign the given VLAN ID to matched clients. No default value. |
Frequency scan
Information about RF conditions on available channels can be obtained by running the frequency-scan command.
Command parameters | |
---|---|
Parameter | Description |
duration (time interval) | Length of time to perform the scan for before exiting. Useful for non-interactive use. Not set by default. |
freeze-frame-interval (time interval) | Time interval at which to update command output. Default: 1s. |
frequency (list of frequencies/ranges) | Frequencies to perform the scan on. See channel.frequency parameter syntax above for more detail. Defaults to all supported frequencies. |
number (string) | Either the name or internal id of the interface to perform the scan with. Required. Not set by default. |
rounds (integer) | Number of times to go through list of scannable frequencies before exiting. Useful for non-interactive use. Not set by default. |
save-file (string) | Name of file to save output to. Not set by default. |
Output parameters | |
---|---|
Parameter | Description |
channel (integer) | Frequency (in MHz) of the channel scanned. |
networks (integer) | Number of access points detected on the channel. |
load (integer) | Percentage of time the channel was busy during the scan. |
nf (integer) | Noise floor (in dBm) of the channel. |
max-signal (integer) | Maximum signal strength (in dBm) of APs detected in the channel. |
min-signal (integer) | Minimum signal strength (in dBm) of APs detected in the channel. |
primary (boolean) (P) | Channel is in use as the primary (control) channel by an AP. |
secondary (boolean) (S) | Channel is in use as a secondary (extension) channel by an AP. |
Flat-snoop
The '/interface wifi flat-snoop' is a tool for surveying APs and stations. Monitors frequency usage, and displays which devices occupy each frequency. Provides more detailed infromation regarding nearby APs than scan, and offers easy overview of frequency usage by station/AP count.
Output parameters | |
---|---|
Parameter | Description |
duration (time interval) | Length of time to perform the scan before exiting. Useful for non-interactive use. Not set by default. |
filter-type (bsss |frequency |stas) | bsss - list of active APs and their parameters. frequency - list of station and AP count per scanned frequency stas - a detailed list of stations on each scanned frequency If filter-type is unspecified all types will be returned. |
freeze-frame-interval (time interval) | Time interval at which to update command output. Default: 1s. |
Scan command
The '/interface wifi scan' command will scan for access points and print out information about any APs it detects.
The scan command takes all the same parameters as the frequency-scan command.
Output parameters | |
---|---|
Parameter | Description |
active (boolean) (A) | This signifies that beacons from the AP have been received in the last 30 seconds. |
address (MAC) | The MAC address (BSSID) of the AP. |
channel (string) | The control channel frequency used by the AP, its supported wireless standards and control/extension channel layout. |
security (string) | Authentication methods supported by the AP. |
signal (integer) | The signal strength of the AP's beacons (in dBm). |
ssid (string) | The extended service set identifier of the AP. |
sta-count (integer) | The number of client devices associated with the AP. Only available if the AP includes this information in its beacons. |
Sniffer
Command parameters | |
---|---|
Parameter | Description |
duration (time interval) | Automatically interrupt the sniffer after the specified time has passed. No default value. |
filter (string) | A string that specifies a filter to apply to captured frames. Only frames matched by the filter expression will be displayed, saved or streamed. This works similarly to filter strings in libpcap, for example. The filter can match
A string can include the following operators:
|
number (interface) | Interface to use for sniffing. |
pcap-file (string) | Save captured frames to a file with the given name. No default value (captured frames are not saved to a file by default). |
pcap-size-limit (integer) | File size limit (in bytes) when storing captured frames locally. When this limit has been reached, no new frames are added to the capture file. No default value. |
stream-address (IP address) | Stream captured packets via the TZSP protocol to the given address. No default value (captured packets are not streamed anywhere by default). |
stream-rate (integer) | Limit the rate (in packets per second) at which captured frames are streamed via TZSP. |
WPS
interface/wifi/wps-client wifi
Command parameters | |
---|---|
Parameter | Description |
duration (time interval) | Length of time after which the command will time out if no AP is found. Unlimited by default. |
interval (time interval) | Time interval at which to update command output. Default: 1s. |
mac-address (MAC) | Only attempt connecting to AP with the specified MAC (BSSID). Not set by default. |
number (string) | Name or internal id of the interface with which to attempt a connection. Not set by default. |
ssid (string) | Only attempt to connect to APs with the specified SSID. Not set by default. |
Radios
Information about the capabilities of each radio can be gained by running the `/interface/wifi/radio print detail` command.
Property | Description |
---|---|
2g-channels (list of integers) | Frequencies supported in the 2.4GHz band. |
5g-channels (list of integers) | Frequencies supported in the 5GHz band. |
bands (list of strings) | Supported frequency bands, wireless standards, and channel widths. |
ciphers (list of strings) | Supported encryption ciphers. |
countries (list of strings) | Regulatory domains supported by the interface. |
hw-caps (list of strings) | Additional supported features (e.g. sniffer, qos-classifier-dscp). |
hw-type (string) | Radio hardware model number. |
max-interfaces (integer) | Maximum number of logical interfaces. |
max-peers (integer) | Maximum number of associated peers (connected stations). |
max-station-interfaces (integer) | Maximum number of logical interfaces in station mode. |
max-vlans (integer) | Maximum number of different per-user VLANs. |
min-antenna-gain (integer) | Minimum antenna gain permitted for the interface. |
phy-id (string) | A unique identifier. |
radio-mac (MAC) | MAC address of the radio interface. Can be used to match radios to interface configurations. |
rx-chains (list of integers) | IDs for radio chains available for receiving radio signals. |
tx-chains (list of integers) | IDs for radio chains available for transmitting radio signals. |
Registration table
The registration table contains read-only information about associated wireless devices.
Parameter | Description |
---|---|
authorized (boolean) (A) | True when the peer has successfully authenticated. |
bytes (list of integers) | Number of bytes in packets transmitted to a peer and received from it. |
interface (string) | Name of the interface, which was used to associate with the peer. |
mac-address (MAC) | The MAC address of the peer. |
packets (list of integers) | Number of packets transmitted to a peer and received from it. |
rx-rate (string) | Bitrate of received transmissions from peer. |
signal (integer) | Strength of signal received from the peer (in dBm). |
tx-rate (string) | Bitrate used for transmitting to the peer. |
uptime (time interval) | Time since association. |
CAPsMAN Global Configuration
Menu: /interface/wifi/capsman
Property | Description |
---|---|
ca-certificate (auto | certificate name ) | Device CA certificate, CAPsMAN server requires a certificate, certificate on CAP is optional. |
certificate (auto | certificate name | none; Default: none) | Device certificate |
enabled (no | yes) | Disable or enable CAPsMAN functionality |
package-path (string |; Default: ) | Folder location for the RouterOS packages. For example, use "/upgrade" to specify the upgrade folder from the files section. If an empty string is set, CAPsMAN can use built-in RouterOS packages, note that in this case only CAPs with the same architecture as CAPsMAN will be upgraded. |
require-peer-certificate (yes | no; Default: no) | Require all connecting CAPs to have a valid certificate |
upgrade-policy (none | require-same-version | suggest-same-upgrade; Default: none) | Upgrade policy options
|
interfaces (all | interface name | none; Default: all) | Interfaces on which CAPsMAN will listen for CAP connections |
CAPsMAN Provisioning
Provisioning rules for matching radios are configured in /interface/wifi/provisioning/ menu:
Property | Description |
---|---|
action (create-disabled | create-enabled | create-dynamic-enabled | none; Default: none) | Action to take if rule matches are specified by the following settings:
|
comment (string; Default: ) | Short description of the Provisioning rule |
common-name-regexp (string; Default: ) | Regular expression to match radios by common name. Each CAP's common name identifier can be found under "/interface/wifi/radio" as value "REMOTE-CAP-NAME" |
supported-bands (2ghz-ax | 2ghz-g | 2ghz-n | 5ghz-a | 5ghz-ac | 5ghz-ax | 5ghz-n; Default: ) | Match radios by supported wireless modes. |
identity-regexp (string; Default: ) | Regular expression to match radios by router identity |
address-ranges (IpAddressRange[,IpAddressRanges] max 100x; Default: "") | Match CAPs with IPs within the configured address range. Will only work for CAPs that joined CAPsMAN using IP, not MAC address. |
master-configuration (string; Default: ) | If action specifies to create interfaces, then a new master interface with its configuration set to this configuration profile will be created |
name-format (string) | Base string to use when constructing names of provisioned interfaces. Each new interface will be created by taking the base string and appending a number to the end of it, a number will only be appended if the string is not unique. If included in the string, the character sequence %I will be replaced by the system identity of the cAP, %C will be replaced with the cAP's TLS certificate's Common Name, %R, or %r for lowercase, will be replaced with the CAP's radio MAC Default: "cap-wifi" |
radio-mac (MAC address) | MAC address of radio to be matched. No default value. |
slave-configurations (string; Default: ) | If the action specifies to create interfaces, then a new slave interface for each configuration profile in this list is created. |
disabled (yes | no; Default: no) | Specifies if the provision rule is disabled. |
CAP configuration
Menu: /interface/wifi/cap
Property | Description |
---|---|
caps-man-addresses (list of IP addresses; Default: empty) | List of Manager IP addresses that CAP will attempt to contact during discovery |
caps-man-names () | An ordered list of CAPs Manager names that the CAP will connect to, if empty - CAP does not check Manager name |
discovery-interfaces (list of interfaces;) | List of interfaces over which CAP should attempt to discover Manager |
lock-to-caps-man (no | yes; Default: no) | Sets, if CAP should lock to the first CAPsMAN it connects to |
slaves-static () | Creates Static Virtual Interfaces, allows the possibility to assign IP configuration to those interfaces. MAC address is used to remember each static-interface when applying the configuration from the CAPsMAN. |
caps-man-certificate-common-names () | List of Manager certificate CommonNames that CAP will connect to, if empty - CAP does not check Manager certificate CommonName |
certificate () | Certificate to use for authenticating |
enabled (yes | no; Default: no) | Disable or enable the CAP feature |
current-caps-man-address () | Shows currently used CAPsMAN address (available since 7.15) |
current-caps-man-identity () | Shows currently used CAPsMAN identity (available since 7.15) |
slaves-datapath () |
Page edited by Ingus Raudiņš
Summary
MikroTik S+RJ10 is a unique 6-speed RJ-45 SFP+ module based on a Marvell 88X3310P transceiver. It offers up to 10 Gbps speeds using twisted-pair copper cables. All the current MikroTik devices with an SFP+ cage support the S+RJ10 module. This article serves as a guideline of S+RJ10 usage in MikroTik devices with both passive and active cooling.
General Guidance
Product specification
The average power consumption of the transceiver is 2.7 W (10GBASE-T, 30 m link) which is relatively high compared with the S+85DLC03D optical module with a maximum 0.8W power consumption. The operating temperature is 0 to +70 C, but the transceiver itself can heat up to 90 C.
S+RJ10 Positioning in devices
Due to high operating temperatures, it is recommended to use S+RJ10 transceivers while an optical transceiver or an unused SFP+ interface is in between them. Take a look at the transceivers capable distance comparison table.
As mentioned, S+RJ10 heat up more than regular transceivers, and keeping them side by side can result in overheating, especially in devices with 4 linear SFP cages. It is recommended to place S+RJ10 in every second interface while keeping an optical transceiver or an empty port in between them.
Even when using devices that come with separated SFP+ cages, for example, CRS309-1G-8S+, it is still not recommended to deploy the S+RJ10 transceivers beside each other. Use S+RJ10 in every second interface to avoid transceivers overheating which may cause unpredictable behavior.
Devices that come with 4 or 8-block SFP+ cages are not exceptions. It is recommended to use one S+RJ10 transceiver per 4xSFP+ cage block and avoid placing them side by side. Keep at least one vertical row empty(without S+RJ10) after plugging the S+RJ10 transceiver.
Using the S+RJ10 Side by Side or with passive cooling devices
There might be situations when it is not possible to use the recommended layout of the transceivers. In such cases where two or more S+RJ10 transceivers are plugged in beside one another or modules are used in passive cooling devices, the network administrator has to ensure additional cooling. The airflow around the device should be increased or the overall ambient temperature should be lowered to keep the temperature of the transceivers within the recommended range.
Page edited by Olga Ļ.
DHCP Client
Summary
/ip dhcp-client
The DHCP (Dynamic Host Configuration Protocol) is used for the easy distribution of IP addresses in a network. The MikroTik RouterOS implementation includes both server and client parts and is compliant with RFC 2131.
The MikroTik RouterOS DHCP client may be enabled on any Ethernet-like interface at a time. The client will accept an address, netmask, default gateway, and two DNS server addresses. The received IP address will be added to the interface with the respective netmask. The default gateway will be added to the routing table as a dynamic entry. Should the DHCP client be disabled or not renew an address, the dynamic default route will be removed. If there is already a default route installed prior to the DHCP client obtaining one, the route obtained by the DHCP client would be shown as invalid.
RouterOS DHCP client asks for the following options:
- option 1 - SUBNET_MASK,
- option 3 - GATEWAY_LIST,
- option 6 - TAG_DNS_LIST,
- option 33 - STATIC_ROUTE,
- option 42 - NTP_LIST,
- option 121 - CLASSLESS_ROUTE,
DHCP Options
DHCP client has the possibility to set up options that are sent to the DHCP server. For example, hostname and MAC address. The syntax is the same as for DHCP server options.
Currently, there are three variables that can be used in options:
- HOSTNAME;
- CLIENT_MAC - client interface MAC address;
- CLIENT_DUID - client DIUD of the router, same as used for the DHCPv6 client. In conformance with RFC4361
DHCP client default options include these default Options:
Name | code | value |
---|---|---|
clientid_duid | 61 | 0xff$(CLIENT_DUID) |
clientid | 61 | 0x01$(CLIENT_MAC) |
hostname | 12 | $(HOSTNAME) |
Properties
Property | Description |
---|---|
add-default-route (yes | no | special-classless; Default: yes) | Whether to install default route in routing table received from DHCP server. By default, the RouterOS client complies with RFC and ignores option 3 if classless option 121 is received. To force the client not to ignore option 3 set special-classless. This parameter is available in v6rc12+
|
client-id (string; Default: ) | Corresponds to the settings suggested by the network administrator or ISP. If not specified, the client's MAC address will be sent |
comment (string; Default: ) | Short description of the client |
default-route-distance (integer:0..255; Default: ) | Distance of default route. Applicable if add-default-route is set to yes . |
disabled (yes | no; Default: yes) | |
host-name (string; Default: ) | The hostname of the client is sent to a DHCP server. If not specified, the client's system identity will be used. |
interface (string; Default: ) | The interface on which the DHCP client will be running. |
script (script; Default: ) | Execute script when DHCP client obtains a new lease or loses an existing one. This parameter is available in v6.39rc33+ These are available variables that are accessible for the event script:
Example >> |
use-peer-dns (yes | no; Default: yes) | Whether to accept the DNS settings advertised by DHCP Server. (Will override the settings put in the /ip dns submenu. |
use-peer-ntp (yes | no; Default: yes) | Whether to accept the NTP settings advertised by DHCP Server. (Will override the settings put in the /system ntp client submenu) |
Read-only properties
Property | Description |
---|---|
address (IP/Netmask) | IP address and netmask, which is assigned to DHCP Client from the Server |
dhcp-server (IP) | The IP address of the DHCP server. |
expires-after (time) | A time when the lease expires (specified by the DHCP server). |
gateway (IP) | The IP address of the gateway which is assigned by the DHCP server |
invalid (yes | no) | Shows whether a configuration is invalid. |
netmask (IP) | |
primary-dns (IP) | The IP address of the first DNS resolver, which was assigned by the DHCP server |
primary-ntp (IP) | The IP address of the primary NTP server, assigned by the DHCP server |
secondary-dns (IP) | The IP address of the second DNS resolver, assigned by the DHCP server |
secondary-ntp (IP) | The IP address of the secondary NTP server, assigned by the DHCP server |
status (bound | error | rebinding... | requesting... | searching... | stopped) | Shows the status of the DHCP Client |
Menu specific commands
Property | Description |
---|---|
release (numbers) | Release current binding and restart the DHCP client |
renew (numbers) | Renew current leases. If the renewal operation was not successful, the client tries to reinitialize the lease (i.e. it starts the lease request procedure (rebind) as if it had not received an IP address yet) |
Configuration Examples
Simple DHCP client
Add a DHCP client on the ether1 interface:
/ip dhcp-client add interface=ether1 disabled=no
After the interface is added, you can use the "print" or "print detail" command to see what parameters the DHCP client acquired:
[admin@MikroTik] ip dhcp-client> print detail Flags: X - disabled, I - invalid 0 interface=ether1 add-default-route=yes use-peer-dns=yes use-peer-ntp=yes status=bound address=192.168.0.65/24 gateway=192.168.0.1 dhcp-server=192.168.0.1 primary-dns=192.168.0.1 primary-ntp=192.168.0.1 expires-after=9m44s [admin@MikroTik] ip dhcp-client>
If the interface used by the DHCP client is part of the VRF configuration, then the default route and other received routes from the DHCP server will be added to the VRF routing table.
DHCP client status can be checked with:
/ip dhcp-client print detail
Lease script example
It is possible to execute a script when a DHCP client obtains a new lease or loses an existing one. This is an example script that automatically adds a default route with routing-table=WAN1 and removes it when the lease expires or is removed.
/ip dhcp-client add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=ether2 script="{\r\ \n :local rmark \"WAN1\"\r\ \n :local count [/ip route print count-only where comment=\"WAN1\"]\r\ \n :if (\$bound=1) do={\r\ \n :if (\$count = 0) do={\r\ \n /ip route add gateway=\$\"gateway-address\" comment=\"WAN1\" routing-table=\$rmark\r\ \n } else={\r\ \n :if (\$count = 1) do={\r\ \n :local test [/ip route find where comment=\"WAN1\"]\r\ \n :if ([/ip route get \$test gateway] != \$\"gateway-address\") do={\r\ \n /ip route set \$test gateway=\$\"gateway-address\"\r\ \n }\r\ \n } else={\r\ \n :error \"Multiple routes found\"\r\ \n }\r\ \n }\r\ \n } else={\r\ \n /ip route remove [find comment=\"WAN1\"]\r\ \n }\r\ \n}\r\ \n"
Resolve default gateway when 'router' (option3) is from a different subnet
In some cases, administrators tend to set the 'router' option which cannot be resolved with offered IP's subnet. For example, the DHCP server offers 192.168.88.100/24 to the client, and option 3 is set to 172.16.1.1. This will result in an unresolved default route:
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 DS 0.0.0.0/0 172.16.1.1 1 1 ADC 192.168.88.0/24 192.168.88.100 ether1
To fix this we need to add /32 route to resolve the gateway over ether1, which can be done by the running script below each time the DHCP client gets an address
/system script add name="dhcpL" source={ /ip address add address=($"lease-address" . "/32") network=$"gateway-address" interface=$interface }
Now we can further extend the script, to check if the address already exists, and remove the old one if changes are needed
/system script add name="dhcpL" source={ /ip address { :local ipId [find where comment="dhcpL address"] :if ($ipId != "") do={ :if (!([get $ipId address] = ($"lease-address" . "/32") && [get $ipId network]=$"gateway-address" )) do={ remove $ipId; add address=($"lease-address" . "/32") network=$"gateway-address" \ interface=$interface comment="dhcpL address" } } else={ add address=($"lease-address" . "/32") network=$"gateway-address" \ interface=$interface comment="dhcpL address" } } }
DHCPv6 Client
Summary
Sub-menu: /ipv6 dhcp-client
DHCP-client in RouterOS is capable of being a DHCPv6-client and DHCP-PD client. So it is able to get a prefix from the DHCP-PD server as well as the DHCPv6 stateful address from the DHCPv6 server.
Properties
Property | Description |
---|---|
add-default-route (yes | no; Default: no) | Whether to add default IPv6 route after a client connects. |
comment (string; Default: ) | Short description of the client |
disabled (yes | no; Default: no) | |
interface (string; Default: ) | The interface on which the DHCPv6 client will be running. |
pool-name (string; Default: ) | Name of the IPv6 pool in which received IPv6 prefix will be added |
pool-prefix-length (string; Default: ) | Prefix length parameter that will be set for IPv6 pool in which received IPv6 prefix is added. Prefix length must be greater or equal as the length of received prefix, otherwise, prefix-length will be set to received prefix length + 8 bits. |
prefix-hint (string; Default: ) | Include a preferred prefix length. |
request (prefix, address; Default: ) | to choose if the DHCPv6 request will ask for the address or the IPv6 prefix, or both. |
script (string; Default: ) | Run this script on the DHCP-client status change. Available variables:
|
use-peer-dns (yes | no; Default: yes) | Whether to accept the DNS settings advertised by the IPv6 DHCP Server. |
Read-only properties
Property | Description |
---|---|
duid (string) | Auto-generated DUID that is sent to the server. DUID is generated using one of the MAC addresses available on the router. |
request (list) | specifies what was requested - prefix, address, or both. |
dynamic (yes | no) | |
expires-after (time) | A time when the IPv6 prefix expires (specified by the DHCPv6 server). |
invalid (yes | no) | Shows whether a configuration is invalid. |
prefix (IPv6 prefix) | Shows received IPv6 prefix from DHCPv6-PD server |
status (stopped | searching | requesting... | bound | renewing | rebinding | error | stopping) | Shows the status of DHCPv6 Client:
|
Menu specific commands
Property | Description |
---|---|
release (numbers) | Release current binding and restart DHCPv6 client |
renew (numbers) | Renew current leases. If the renewal operation was not successful, the client tries to reinitialize the lease (i.e. it starts the lease request procedure (rebind) as if it had not received an IP address yet) |
Script
It is possible to add a script that will be executed when a prefix or an address is acquired and applied or expires and is removed using the DHCP client. There are separated sets of variables that will have the value set by the client depending on prefix or address status change as the client can acquire both and each of them can have a different effect on the router configuration.
Available variables for dhcp-client
- pd-valid - value - 1 or 0 - if prefix is acquired and it is applied or not
- pd-prefix - value ipv6/num (ipv6 prefix with mask) - the prefix inself
- na-valid - value - 1 or 0 - if address is acquired and it is applied or not
- na-address - value - ipv6 address - the address
IAID
To determine what IAID will be used, convert the internal ID of an interface on which the DHCP client is running from hex to decimal.
For example, the DHCP client is running on interface PPPoE-out1. To get internal ID use the following command:
[admin@t36] /interface> :put [find name="pppoe-out1"] *15
Now convert hex value 15 to decimal and you get IAID=21
Configuration Examples
Simple DHCPv6 client
This simple example demonstrates how to enable dhcp client to receive IPv6 prefix and add it to the pool.
/ipv6 dhcp-client add request=prefix pool-name=test-ipv6 pool-prefix-length=64 interface=ether13
Detailed print should show status of the client and we can verify if prefix is received
[admin@x86-test] /ipv6 dhcp-client> print detail Flags: D - dynamic, X - disabled, I - invalid 0 interface=bypass pool-name="test-ipv6" pool-prefix-length=64 status=bound prefix=2001:db8:7501:ff04::/62 expires-after=2d23h11m53s request=prefix
Notice that server gave us prefix 2a02:610:7501:ff04::/62 . And it should be also added to ipv6 pools
[admin@MikroTik] /ipv6 pool> print Flags: D - dynamic # NAME PREFIX REQUEST PREFIX-LENGTH 0 D test-ipv6 2001:db8:7501:ff04::/62 prefix 64
It works! Now you can use this pool, for example, for pppoe clients.
Use received prefix for local RA
Consider following setup:
- ISP is routing prefix 2001:DB8::/62 to the router R1
- Router R1 runs DHCPv6 server to delegate /64 prefixes to the customer routers CE1 CE2
- DHCP client on routers CE1 and CE2 receives delegated /64 prefix from the DHCP server (R1).
- Client routers uses received prefix to set up RA on the local interface
Configuration
R1
/ipv6 route add gateway=fe80::1:1%to-ISP /ipv6 pool add name=myPool prefix=2001:db8::/62 prefix-length=64 /ipv6 dhcp-server add address-pool=myPool disabled=no interface=to-CE-routers lease-time=3m name=server1
CE1
/ipv6 dhcp-client add interface=to-R1 request=prefix pool-name=my-ipv6 /ipv6 address add address=::1/64 from-pool=my-ipv6 interface=to-clients advertise=yes
CE2
/ipv6 dhcp-client add interface=to-R1 request=prefix pool-name=my-ipv6 /ipv6 address add address=::1/64 from-pool=my-ipv6 interface=to-clients advertise=yes
Check the status
After configuration is complete we can verify that each CE router received its own prefix
On server:
[admin@R1] /ipv6 dhcp-server binding> print Flags: X - disabled, D - dynamic # ADDRESS DUID IAID SERVER STATUS 1 D 2001:db8:1::/64 0019d1393536 566 server1 bound 2 D 2001:db8:2::/64 0019d1393535 565 server1 bound
On client:
[admin@CE1] /ipv6 dhcp-client> print Flags: D - dynamic, X - disabled, I - invalid # INTERFACE STATUS REQUEST PREFIX 0 to-R1 bound prefix 2001:db8:1::/64 [admin@CE1] /ipv6 dhcp-client> /ipv6 pool print Flags: D - dynamic # NAME PREFIX PREFIX-LENGTH 0 D my-ipv6 2001:db8:1::/64 64
We can also see that IPv6 address was automatically added from the prefix pool:
[admin@CE1] /ipv6 address> print Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local # ADDRESS FROM-POOL INTERFACE ADVERTISE 0 G 2001:db8:1::1/64 to-clients yes ..
And pool usage shows that 'Address' is allocating the pool
[admin@CE1] /ipv6 pool used> print POOL PREFIX OWNER INFO my-ipv6 2001:db8:1::/64 Address to-clients
DHCP Server
Summary
The DHCP (Dynamic Host Configuration Protocol) is used for the easy distribution of IP addresses in a network. The MikroTik RouterOS implementation includes both server and client parts and is compliant with RFC 2131.
The router supports an individual server for each Ethernet-like interface. The MikroTik RouterOS DHCP server supports the basic functions of giving each requesting client an IP address/netmask lease, default gateway, domain name, DNS-server(s) and WINS-server(s) (for Windows clients) information (set up in the DHCP networks submenu)
In order for the DHCP server to work, IP pools must also be configured (do not include the DHCP server's own IP address into the pool range) and the DHCP networks.
It is also possible to hand out leases for DHCP clients using the RADIUS server; the supported parameters for a RADIUS server are as follows:
Access-Request:
- NAS-Identifier - router identity
- NAS-IP-Address - IP address of the router itself
- NAS-Port - unique session ID
- NAS-Port-Type - Ethernet
- Calling-Station-Id - client identifier (active-client-id)
- Framed-IP-Address - IP address of the client (active-address)
- Called-Station-Id - the name of DHCP server
- User-Name - MAC address of the client (active-mac-address)
- Password - " "
Access-Accept:
- Framed-IP-Address - IP address that will be assigned to a client
- Framed-Pool - IP pool from which to assign an IP address to a client
- Rate-Limit - Datarate limitation for DHCP clients. Format is: rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx-burst-threshold] [rx-burst-time[/tx-burst-time][priority] [rx-rate-min[/tx-rate-min]]]]. All rates should be numbers with optional 'k' (1,000s) or 'M' (1,000,000s). If tx-rate is not specified, rx-rate is as tx-rate too. Same goes for tx-burst-rate and tx-burst-threshold and tx-burst-time. If both rx-burst-threshold and tx-burst-threshold are not specified (but burst-rate is specified), rx-rate and tx-rate are used as burst thresholds. If both rx-burst-time and tx-burst-time are not specified, 1s is used as default. Priority takes values 1..8, where 1 implies the highest priority, but 8 - the lowest. If rx-rate-min and tx-rate-min are not specified rx-rate and tx-rate values are used. The rx-rate-min and tx-rate-min values can not exceed rx-rate and tx-rate values.
- Ascend-Data-Rate - TX/RX data rate limitation if multiple attributes are provided, first limits tx data rate, second - RX data rate. If used together with Ascend-Xmit-Rate, specifies RX rate. 0 if unlimited
- Ascend-Xmit-Rate - tx data rate limitation. It may be used to specify the TX limit only instead of sending two sequential Ascend-Data-Rate attributes (in that case Ascend-Data-Rate will specify the receive rate). 0 if unlimited
- Session-Timeout - max lease time (lease-time)
DHCP server requires a real interface to receive raw ethernet packets. If the interface is a Bridge interface, then the Bridge must have a real interface attached as a port to that bridge which will receive the raw ethernet packets. It cannot function correctly on a dummy (empty bridge) interface.
DHCP Server Properties
Property | Description |
---|---|
add-arp (yes | no; Default: no) | Whether to add dynamic ARP entry. If set to no either ARP mode should be enabled on that interface or static ARP entries should be administratively defined in /ip arp submenu. |
address-pool (string | static-only; Default: static-only) | IP pool, from which to take IP addresses for the clients. If set to static-only, then only the clients that have a static lease (added in the lease submenu) will be allowed. |
allow-dual-stack-queue (yes | no; Default: yes) | Creates a single simple queue entry for both IPv4 and IPv6 addresses, and uses the MAC address and DUID for identification. Requires IPv6 DHCP Server to have this option enabled as well to work properly. |
always-broadcast (yes | no; Default: no) | Changes whether to force broadcast DHCP replies:
|
authoritative (after-10sec-delay | after-2sec-delay | yes | no; Default: yes) | Option changes the way how a server responds to DHCP requests:
|
bootp-lease-time (forever | lease-time | time; Default: forever) | Accepts two predefined options or time value:
|
bootp-support (none | static | dynamic; Default: static) | Support for BOOTP clients:
|
client-mac-limit (integer | unlimited; Default: unlimited) | Specifies whether to limit a specific number of clients per single MAC address or leave unlimited. Note that this setting should not be used in relay setups. |
conflict-detection (yes | no; Default: yes) | Allows disabling/enabling conflict detection. If the option is enabled, then whenever the server tries to assign a lease it will send ICMP and ARP messages to detect whether such an address in the network already exists. If any of the above get a reply address is considered already used. |
delay-threshold (time | none; Default: none) | If the sec's field in the DHCP packet is smaller than the delay threshold, then this packet is ignored. If set to none - there is no threshold (all DHCP packets are processed) |
dhcp-option-set (name | none; Default: none) | Use a custom set of DHCP options defined in the option sets menu. |
insert-queue-before (bottom | first | name; Default: first) | Specify where to place dynamic simple queue entries for static DCHP leases with a rate-limit parameter set. |
interface (string; Default: ) | The interface on which the DHCP server will be running. |
lease-script (string; Default: "") | A script that will be executed after a lease is assigned or de-assigned. Internal "global" variables that can be used in the script:
|
lease-time (time; Default: 30m) | The time that a client may use the assigned address. The client will try to renew this address after half of this time and will request a new address after the time limit expires. |
name (string; Default: ) | Reference name |
parent-queue (string | none; Default: none) | A dynamically created queue for this lease will be configured as a child queue of the specified parent queue. |
relay (IP; Default: 0.0.0.0) | The IP address of the relay this DHCP server should process requests from:
|
server-address (IP; Default: 0.0.0.0) | The IP address of the server to use in the next step of the client's bootstrap process (For example, to assign a specific server address in case several addresses are assigned to the interface) |
use-framed-as-classless (yes | no; Default: yes) | Forward RADIUS Framed-Route as a DHCP Classless-Static-Route to DHCP-client. Whenever both Framed-Route and Classless-Static-Route are received Classless-Static-Route is preferred. |
use-radius (yes | no | accounting; Default: no) | Whether to use RADIUS server:
|
Leases
Sub-menu: /ip dhcp-server lease
DHCP server lease submenu is used to monitor and manage server leases. The issued leases are shown here as dynamic entries. You can also add static leases to issue a specific IP address to a particular client (identified by MAC address).
Generally, the DHCP lease is allocated as follows:
- an unused lease is in the "waiting" state
- if a client asks for an IP address, the server chooses one
- if the client receives a statically assigned address, the lease becomes offered, and then bound with the respective lease time
- if the client receives a dynamic address (taken from an IP address pool), the router sends a ping packet and waits for an answer for 0.5 seconds. During this time, the lease is marked testing
- in the case where the address does not respond, the lease becomes offered and then bound with the respective lease time
- in other cases, the lease becomes busy for the lease time (there is a command to retest all busy addresses), and the client's request remains unanswered (the client will try again shortly)
A client may free the leased address. The dynamic lease is removed, and the allocated address is returned to the address pool. But the static lease becomes busy until the client reacquires the address.
IP addresses assigned statically are not probed!
Property | Description |
---|---|
address (IP; Default: 0.0.0.0) | Specify IP address (or ip pool) for static lease. If set to 0.0.0.0 - a pool from the DHCP server will be used |
address-list (string; Default: none) | Address list to which address will be added if the lease is bound. |
allow-dual-stack-queue (yes | no; Default: yes) | Creates a single simple queue entry for both IPv4 and IPv6 addresses, and uses the MAC address and DUID for identification. Requires IPv6 DHCP Server to have this option enabled as well to work properly. |
always-broadcast (yes | no; Default: no) | Changes whether to force broadcast DHCP replies:
|
block-access (yes | no; Default: no) | Block access for this client |
client-id (string; Default: none) | If specified, must match the DHCP 'client identifier' option of the request |
dhcp-option (string; Default: none) | Add additional DHCP options from option list. |
dhcp-option-set (string; Default: none) | Add an additional set of DHCP options. |
insert-queue-before (bottom | first | name; Default: first) | Specify where to place dynamic simple queue entries for static DCHP leases with rate-limit parameter set. |
lease-time (time; Default: 0s) | Time that the client may use the address. If set to 0s lease will never expire. |
mac-address (MAC; Default: 00:00:00:00:00:00) | If specified, must match the MAC address of the client |
parent-queue (string | none; Default: none) | A dynamically created queue for this lease will be configured as a child queue of the specified parent queue. |
queue-type (default, ethernet-default, multi-queue-ethernet-default, pcq-download-default, synchronous-default, default-small, hotspot-default, only-hardware-queue, pcq-upload-default, wireless-default) | Queue type that can be assigned to the specific lease |
rate-limit (integer[/integer] [integer[/integer] [integer[/integer] [integer[/integer]]]];; Default: ) | Adds a dynamic simple queue to limit IP's bandwidth to a specified rate. Requires the lease to be static. Format is: rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx-burst-threshold] [rx-burst-time[/tx-burst-time]]]]. All rates should be numbers with optional 'k' (1,000s) or 'M' (1,000,000s). If tx-rate is not specified, rx-rate is as tx-rate too. Same goes for tx-burst-rate and tx-burst-threshold and tx-burst-time. If both rx-burst-threshold and tx-burst-threshold are not specified (but burst-rate is specified), rx-rate and tx-rate is used as burst thresholds. If both rx-burst-time and tx-burst-time are not specified, 1s is used as default. |
routes ([dst-address/mask] [gateway] [distance]; Default: none) | Routes that appear on the server when the client is connected. It is possible to specify multiple routes separated by commas. This setting will be ignored for OpenVPN. |
server (string) | Server name which serves this client |
use-src-mac (yes | no; Default: no) | When this option is set server uses the source MAC address instead of the received CHADDR to assign the address. |
Menu specific commands
check-status (id) | Check the status of a given busy (status is conflict or declined) dynamic lease, and free it in case of no response |
make-static (id) | Convert a dynamic lease to a static one |
Store Configuration
Sub-menu: /ip dhcp-server config
Store Leases On Disk: The configuration of how often the DHCP leases will be stored on disk. If they would be saved on a disk on every lease change, a lot of disk writes would happen which is very bad for Compact Flash (especially, if lease times are very short). To minimize writes on disk, all changes are saved on disk every store-leases-disk seconds. Additionally, leases are always stored on disk on graceful shutdown and reboot.
Manual changes to leases - addition/removal of a static lease, removal of a dynamic lease will cause changes to be pushed for this lease to storage.
Accounting: The accounting parameter in the DHCP server configuration enables or disables accounting for DHCP leases. When accounting is enabled, the DHCP server logs information about IP address assignments and lease renewals. This information can be useful for tracking and monitoring network usage, analyzing traffic patterns, or generating reports on IP address allocations.
Interim-update: The interim-update parameter determines whether the DHCP server sends periodic updates to the accounting server during a lease. These updates provide information about the lease duration, usage, and other relevant details. Enabling interim updates allows for more accurate tracking of lease activity.
Radius-password: The radius-password parameter is used to set the password for the RADIUS (Remote Authentication Dial-In User Service) server. RADIUS is a networking protocol commonly used for providing centralized authentication, authorization, and accounting for network access. When configuring the DHCP server to communicate with a RADIUS server for authentication or accounting purposes, you need to specify the correct password to establish a secure connection. This parameter ensures that the DHCP server can authenticate with the RADIUS server using the specified password.
Rate limiting
It is possible to set the bandwidth to a specific IPv4 address by using DHCPv4 leases. This can be done by setting a rate limit on the DHCPv4 lease itself, by doing this a dynamic simple queue rule will be added for the IPv4 address that corresponds to the DHCPv4 lease. By using the rate-limit parameter you can conveniently limit a user's bandwidth.
For any queues to work properly, the traffic must not be FastTracked, make sure your Firewall does not FastTrack traffic that you want to limit.
First, make the DHCPv4 lease static, otherwise, it will not be possible to set a rate limit to a DHCPv4 lease:
[admin@MikroTik] > /ip dhcp-server lease print Flags: X - disabled, R - radius, D - dynamic, B - blocked # ADDRESS MAC-ADDRESS HOST-NAME SERVER RATE-LIMIT STATUS 0 D 192.168.88.254 6C:3B:6B:7C:41:3E MikroTik DHCPv4_Server bound [admin@MikroTik] > /ip dhcp-server lease make-static 0 [admin@MikroTik] > /ip dhcp-server lease print Flags: X - disabled, R - radius, D - dynamic, B - blocked # ADDRESS MAC-ADDRESS HOST-NAME SERVER RATE-LIMIT STATUS 0 192.168.88.254 6C:3B:6B:7C:41:3E MikroTik DHCPv4_Server bound
Then you can set a rate to a DHCPv4 lease that will create a new dynamic simple queue entry:
[admin@MikroTik] > /ip dhcp-server lease set 0 rate-limit=10M/10M [admin@MikroTik] > /queue simple print Flags: X - disabled, I - invalid, D - dynamic 0 D name="dhcp-ds<6C:3B:6B:7C:41:3E>" target=192.168.88.254/32 parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=10M/10M max-limit=10M/10M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1
By default allow-dual-stack-queue is enabled, this will add a single dynamic simple queue entry for both DCHPv6 binding and DHCPv4 lease, without this option enabled separate dynamic simple queue entries will be added for IPv6 and IPv4.
If allow-dual-stack-queue is enabled, then a single dynamic simple queue entry will be created containing both IPv4 and IPv6 addresses:
[admin@MikroTik] > /queue simple print Flags: X - disabled, I - invalid, D - dynamic 0 D name="dhcp-ds<6C:3B:6B:7C:41:3E>" target=192.168.88.254/32,fdb4:4de7:a3f8:418c::/66 parent=none packet-marks="" priority=8/8 queue=default-small/default-small limit-at=10M/10M max-limit=10M/10M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1
Network
Sub-menu: /ip dhcp-server network
Properties
Property | Description |
---|---|
address (IP/netmask; Default: ) | the network DHCP server(s) will lease addresses from |
boot-file-name (string; Default: ) | Boot filename |
caps-manager (string; Default: ) | A comma-separated list of IP addresses for one or more CAPsMAN system managers. DHCP Option 138 (capwap) will be used. |
dhcp-option (string; Default: ) | Add additional DHCP options from the option list. |
dhcp-option-set (string; Default: ) | Add an additional set of DHCP options. |
dns-none (yes | no; Default: no) | If set, then DHCP Server will not pass dynamic DNS servers configured on the router to the DHCP clients if no DNS Server in DNS-server is set. By default, if there are no DNS servers configured, then the dynamic DNS Servers will be passed to DHCP clients. |
dns-server (string; Default: ) | the DHCP client will use these as the default DNS servers. Two comma-separated DNS servers can be specified to be used by the DHCP client as primary and secondary DNS servers |
domain (string; Default: ) | The DHCP client will use this as the 'DNS domain' setting for the network adapter. |
gateway (IP; Default: 0.0.0.0) | The default gateway to be used by DHCP Client. |
netmask (integer: 0..32; Default: 0) | The actual network mask is to be used by the DHCP client. If set to '0' - netmask from network address will be used. |
next-server (IP; Default: ) | The IP address of the next server to use in bootstrap. |
ntp-server (IP; Default: ) | the DHCP client will use these as the default NTP servers. Two comma-separated NTP servers can be specified to be used by the DHCP client as primary and secondary NTP servers |
wins-server (IP; Default: ) | The Windows DHCP client will use these as the default WINS servers. Two comma-separated WINS servers can be specified to be used by the DHCP client as primary and secondary WINS servers |
RADIUS Support
Since RouterOS v6.43 it is possible to use RADIUS to assign a rate limit per lease, to do so you need to pass the Mikrotik-Rate-Limit attribute from your RADIUS Server for your lease. To achieve this you first need to set your DHCPv4 Server to use RADIUS for assigning leases. Below is an example of how to set it up:
/radius add address=10.0.0.1 secret=VERYsecret123 service=dhcp /ip dhcp-server set dhcp1 use-radius=yes
After that, you need to tell your RADIUS Server to pass the Mikrotik-Rate-Limit attribute. In case you are using FreeRADIUS with MySQL, then you need to add appropriate entries into radcheck and radreply tables for a MAC address, that is being used for your DHCPv4 Client. Below is an example for table entries:
Error rendering macro 'code': Invalid value specified for parameter '[Ljava.lang.Object;@5e7fc9f6'INSERT INTO `radcheck` (`username`, `attribute`, `op`, `value`) VALUES ('00:0C:42:00:D4:64', 'Auth-Type', ':=', 'Accept'), INSERT INTO `radreply` (`username`, `attribute`, `op`, `value`) VALUES ('00:0C:42:00:D4:64', 'Framed-IP-Address', '=', '192.168.88.254'), ('00:0C:42:00:D4:64', 'Mikrotik-Rate-Limit', '=', '10M'),
Alerts
To find any rogue DHCP servers as soon as they appear in your network, the DHCP Alert tool can be used. It will monitor the interface for all DHCP replies and check if this reply comes from a valid DHCP server. If a reply from an unknown DHCP server is detected, an alert gets triggered:
[admin@MikroTik] ip dhcp-server alert>/log print 00:34:23 dhcp,critical,error,warning,info,debug dhcp alert on Public: discovered unknown dhcp server, mac 00:02:29:60:36:E7, ip 10.5.8.236 [admin@MikroTik] ip dhcp-server alert>
When the system alerts about a rogue DHCP server, it can execute a custom script.
As DHCP replies can be unicast, the rogue DHCP detector may not receive any offer to other DHCP clients at all. To deal with this, the rogue DHCP detector acts as a DHCP client as well - it sends out DHCP discover requests once a minute.
The DHCP alert is not recommended on devices that are configured as DHCP clients. Since the alert itself generates DHCP discovery packets, it can affect the operation of the DHCP client itself. Use this feature only on devices that are DHCP servers or using a static IP address.
Sub-menu: /ip dhcp-server alert
Properties
Property | Description |
---|---|
alert-timeout (none | time; Default: 1h) | Time after which the alert will be forgotten. If after that time the same server is detected, a new alert will be generated. If set to none timeout will never expire. |
interface (string; Default: ) | Interface, on which to run rogue DHCP server finder. |
on-alert (string; Default: ) | Script to run, when an unknown DHCP server is detected. |
valid-server (string; Default: ) | List of MAC addresses of valid DHCP servers. |
Read-only properties
Property | Description |
---|---|
unknown-server (string) | List of MAC addresses of detected unknown DHCP servers. The server is removed from this list after alert-timeout |
Menu specific commands
Property | Description |
---|---|
reset-alert (id) | Clear all alerts on an interface |
DHCP Options
Sub-menu: /ip dhcp-server option
With the help of the DHCP Option list, it is possible to define additional custom options for DHCP Server to advertise. Option precedence is as follows:
- radius,
- lease,
- server,
- network.
This is the order in which the client option request will be filled in.
According to the DHCP protocol, a parameter is returned to the DHCP client only if it requests this parameter, specifying the respective code in the DHCP request Parameter-List (code 55) attribute. If the code is not included in the Parameter-List attribute, the DHCP server will not send it to the DHCP client, but since RouterOS v7.1rc5 it is possible to force the DHCP option from the server-side even if the DHCP-client does not request such parameter:
ip/dhcp-server/option/set force=yes
Properties
Property | Description |
---|---|
code (integer:1..254; Default: ) | dhcp option code. All codes are available at http://www.iana.org/assignments/bootp-dhcp-parameters |
name (string; Default: ) | Descriptive name of the option |
value (string; Default: ) | Parameter's value. Available data types for options are:
RouterOS has predefined variables that can be used:
For example if HOSTNAME is 'kvm', then raw value will be 0x0176617264736b766d. |
raw-value (HEX string ) | Read-only field which shows raw DHCP option value (the format actually sent out) |
DHCP Option Sets
Sub-menu: /ip dhcp-server option sets
This menu allows combining multiple options in option sets, which later can be used to override the default DHCP server option set.
Example
Classless Route
A classless route adds a specified route in the clients routing table. In our example, it will add
- dst-address=160.0.0.0/24 gateway=10.1.101.1
- dst-address=0.0.0.0/0 gateway=10.1.101.1
According to RFC 3442: The first part is the netmask ("18" = netmask /24). Second part is significant part of destination network ("A00000" = 160.0.0). Third part is IP address of gateway ("0A016501" = 10.1.101.1). Then There are parts of the default route, destination netmask (0x00 = 0.0.0.0/0) followed by default route (0x0A016501 = 10.1.101.1)
/ip dhcp-server option add code=121 name=classless value=0x18A000000A016501000A016501 /ip dhcp-server network set 0 dhcp-option=classless
Result:
[admin@MikroTik] /ip route> print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADS 0.0.0.0/0 10.1.101.1 0 1 ADS 160.0.0.0/24 10.1.101.1 0
A much more robust way would be to use built-in variables, the previous example can be rewritten as:
/ip dhcp-server option add name=classless code=121 value="0x18A00000\$(NETWORK_GATEWAY)0x00\$(NETWORK_GATEWAY)"
Auto proxy config
/ip dhcp-server option add code=252 name=auto-proxy-config value="'https://autoconfig.something.lv/wpad.dat'"
Vendor Classes
Since the 6.45beta6 version RouterOS support vendor class, ID matcher. The vendor class is used by DHCP clients to optionally identify the vendor and configuration.
Vendor-class-id matcher changes to generic matcher since RouterOS v7.4beta4.
Example
In the following configuration example, we will give an IP address from a particular pool for an Android-based mobile phone. We will use the RouterBOARD with a default configuration
/ip pool add name=default-dhcp ranges=192.168.88.10-192.168.88.254 add name=pool-for-VID ranges=172.16.16.10-172.16.16.120
Configure vendor-class-id
matcher. DHCP servers configuration remains the default
/ip dhcp-server add address-pool=default-dhcp disabled=no interface=bridge name=defconf /ip dhcp-server network add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1 /ip dhcp-server vendor-class-id add address-pool=pool-for-VID name=samsung server=defconf vid=android-dhcp-9
Connect your mobile phone to the device to receive an IP address from the 172.16.16.0 network
[admin@mikrotik] > /ip dhcp-server lease print detail Flags: X - disabled, R - radius, D - dynamic, B - blocked 0 D address=172.16.16.120 mac-address=30:07:4D:F5:07:49 client-id="1:30:7:4d:f5:7:49" address-lists="" server=defconf dhcp-option="" status=bound expires-after=8m55s last-seen=1m5s active-address=172.16.16.120 active-mac-address=30:07:4D:F5:07:49 active-client-id="1:30:7:4d:f5:7:49" active-server=defconf host-name="Galaxy-S8"
If you do not know your devices Vendor Class ID, you can turn on DHCP debug logs with /system logging add topics=dhcp
. Then in the logging entries, you will see Class-ID
10:30:31 dhcp,debug,packet defconf received request with id 4238230732 from 0.0.0.0 10:30:31 dhcp,debug,packet secs = 3 10:30:31 dhcp,debug,packet ciaddr = 0.0.0.0 10:30:31 dhcp,debug,packet chaddr = 30:07:4D:F5:07:49 10:30:31 dhcp,debug,packet Msg-Type = request 10:30:31 dhcp,debug,packet Client-Id = 01-30-07-4D-F5-07-49 10:30:31 dhcp,debug,packet Address-Request = 172.16.16.120 10:30:31 dhcp,debug,packet Server-Id = 192.168.88.1 10:30:31 dhcp,debug,packet Max-DHCP-Message-Size = 1500 10:30:31 dhcp,debug,packet Class-Id = "android-dhcp-9" 10:30:31 dhcp,debug,packet Host-Name = "Galaxy-S8" 10:30:31 dhcp,debug,packet Parameter-List = Subnet-Mask,Router,Domain-Server,Domain-Name,Interface-MTU,Broadcast-Address,Address-Time,Ren ewal-Time,Rebinding-Time,Vendor-Specific 10:30:31 dhcp,info defconf assigned 172.16.16.120 to 30:07:4D:F5:07:49 10:30:31 dhcp,debug,packet defconf sending ack with id 4238230732 to 172.16.16.120 10:30:31 dhcp,debug,packet ciaddr = 0.0.0.0 10:30:31 dhcp,debug,packet yiaddr = 172.16.16.120 10:30:31 dhcp,debug,packet siaddr = 192.168.88.1 10:30:31 dhcp,debug,packet chaddr = 30:07:4D:F5:07:49 10:30:31 dhcp,debug,packet Msg-Type = ack 10:30:31 dhcp,debug,packet Server-Id = 192.168.88.1 10:30:31 dhcp,debug,packet Address-Time = 600 10:30:31 dhcp,debug,packet Domain-Server = 192.168.88.1,10.155.0.1,10.155.0.126
Generic matcher
Since RouterOS 7.4beta4 (2022-Jun-15 14:04) the vendor-id matcher is converted to a generic matcher. The genric matcher allows matching any of the DHCP options.
And an example to match DHCP option 60 similar to vendor-id-class matcher:
/ip dhcp-server matcher add address-pool=pool1 code=60 name=test value=android-dhcp-11
Match the client-id with option 61 configured as hex value:
/ip dhcp-server matcher add address-pool=pool1 code=61 name=test value=0x016c3b6bed8364
Match the code 12 using the string:
/ip dhcp-server matcher add address-pool=testpool code=12 name=test server=dhcp1 value="MikroTik"
Configuration Examples
Setup
To simply configure DHCP server you can use a setup
command.
First, you configure an IP address on the interface:
[admin@MikroTik] > /ip address add address=192.168.88.1/24 interface=ether3 disabled=no
Then you use setup
a command which will automatically ask necessary parameters:
[admin@MikroTik] > /ip dhcp-server setup Select interface to run DHCP server on dhcp server interface: ether3 Select network for DHCP addresses dhcp address space: 192.168.88.0/24 Select gateway for given network gateway for dhcp network: 192.168.88.1 Select pool of ip addresses given out by DHCP server addresses to give out: 192.168.88.2-192.168.88.254 Select DNS servers dns servers: 10.155.126.1,10.155.0.1, Select lease time lease time: 10m
That is all. You have configured an active DHCP server.
Manual configuration
To configure the DHCP server manually to respond to local requests you have to configure the following:
- An IP pool for addresses to be given out, make sure that your gateway/DHCP server address is not part of the pool.
/ip pool add name=dhcp_pool0 ranges=192.168.88.2-192.168.88.254
- A network indicating subnets that DHCP-server will lease addresses from, among other information, like a gateway, DNS-server, NTP-server, DHCP options, etc.
/ip dhcp-server network add address=192.168.88.0/24 dns-server=192.168.88.1 gateway=192.168.88.1
- In our case, the device itself is serving as the gateway, so we'll add the address to the bridge interface:
/ip address add address=192.168.88.1/24 interface=bridge1 network=192.168.88.0
- And finally, add DHCP Server, here we will add the previously created address pool, and specify on which interface the DHCP server should work on
/ip dhcp-server add address-pool=dhcp_pool0 disabled=no interface=bridge1 name=dhcp1
DHCPv6 Server
Summary
Standards: RFC 3315, RFC 3633
Single DUID is used for client and server identification, only IAID will vary between clients corresponding to their assigned interface.
Client binding creates a dynamic pool with a timeout set to binding's expiration time (note that now dynamic pools can have a timeout), which will be updated every time binding gets renewed.
When a client is bound to a prefix, the DHCP server adds routing information to know how to reach the assigned prefix.
Client bindings in the server do not show MAC address anymore (as it was in v5.8), DUID (hex) and IAID are used instead. After upgrade, MAC addresses will be converted to DUIDs automatically, but due to unknown DUID type and unknown IAID, they should be further updated by the user;
RouterOS DHCPv6 server can only delegate IPv6 prefixes, not addresses.
General
Sub-menu: /ipv6 dhcp-server
This sub-menu lists and allows to configure DHCP-PD servers.
DHCPv6 Server Properties
Property | Description |
---|---|
address-pool (enum | static-only; Default: static-only) | IPv6 pool, from which to take IPv6 prefix for the clients. |
allow-dual-stack-queue (yes | no; Default: yes) | Creates a single simple queue entry for both IPv4 and IPv6 addresses, and uses the MAC address and DUID for identification. Requires IPv6 DHCP Server to have this option enabled as well to work properly. |
binding-script (string; Default: ) | A script that will be executed after binding is assigned or de-assigned. Internal "global" variables that can be used in the script:
|
dhcp-option (string; Default: none) | Add additional DHCP options from option list. |
disabled (yes | no; Default: no) | Whether DHCP-PD server participates in the prefix assignment process. |
interface (string; Default: ) | The interface on which server will be running. |
lease-time (time; Default: 3d) | The time that a client may use the assigned address. The client will try to renew this address after half of this time and will request a new address after the time limit expires. |
name (string; Default: ) | Reference name |
Read-only Properties
Property | Description |
---|---|
dynamic (yes | no) | |
invalid (yes | no) |
Bindings
Sub-menu: /ipv6 dhcp-server binding
DUID is used only for dynamic bindings, so if it changes then the client will receive a different prefix than previously.
Property | Description |
---|---|
address (IPv6 prefix; Default: ) | IPv6 prefix that will be assigned to the client |
allow-dual-stack-queue (yes | no; Default: yes) | Creates a single simple queue entry for both IPv4 and IPv6 addresses, uses the MAC address and DUID for identification. Requires IPv4 DHCP Server to have this option enabled as well to work properly. |
comment (string; Default: ) | Short description of an item. |
disabled (yes | no; Default: no) | Whether an item is disabled |
dhcp-option (string; Default: ) | Add additional DHCP options from the option list. |
dhcp-option-set (string; Default: ) | Add an additional set of DHCP options. |
life-time (time; Default: 3d) | The time period after which binding expires. |
duid (hex string; Default: ) | DUID value. Should be specified only in hexadecimal format. |
iaid (integer [0..4294967295]; Default: ) | Identity Association Identifier, part of the Client ID. |
prefix-pool (string; Default: ) | Prefix pool that is being advertised to the DHCPv6 Client. |
rate-limit (integer[/integer] [integer[/integer] [integer[/integer] [integer[/integer]]]]; Default: ) | Adds a dynamic simple queue to limit IP's bandwidth to a specified rate. Requires the lease to be static. Format is: rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx-burst-threshold] [rx-burst-time[/tx-burst-time]]]]. All rates should be numbers with optional 'k' (1,000s) or 'M' (1,000,000s). If tx-rate is not specified, rx-rate is as tx-rate too. Same goes for tx-burst-rate and tx-burst-threshold and tx-burst-time. If both rx-burst-threshold and tx-burst-threshold are not specified (but burst-rate is specified), rx-rate and tx-rate is used as burst thresholds. If both rx-burst-time and tx-burst-time are not specified, 1s is used as default. |
server (string | all; Default: all) | Name of the server. If set to all, then binding applies to all created DHCP-PD servers. |
Read-only properties
Property | Description |
---|---|
dynamic (yes | no) | Whether an item is dynamically created. |
expires-after (time) | The time period after which binding expires. |
last-seen (time) | Time period since the client was last seen. |
status (waiting | offered | bound) | Three status values are possible:
|
For example, dynamically assigned /62 prefix
[admin@RB493G] /ipv6 dhcp-server binding> print detail Flags: X - disabled, D - dynamic 0 D address=2a02:610:7501:ff00::/62 duid="1605fcb400241d1781f7" iaid=0 server=local-dhcp life-time=3d status=bound expires-after=2d23h40m10s last-seen=19m50s 1 D address=2a02:610:7501:ff04::/62 duid="0019d1393535" iaid=2 server=local-dhcp life-time=3d status=bound expires-after=2d23h43m47s last-seen=16m13s
Menu specific commands
Property | Description |
---|---|
make-static () | Set dynamic binding as static. |
Rate limiting
It is possible to set the bandwidth to a specific IPv6 address by using DHCPv6 bindings. This can be done by setting a rate limit on the DHCPv6 binding itself, by doing this a dynamic simple queue rule will be added for the IPv6 address that corresponds to the DHCPv6 binding. By using the rate-limit
the parameter you can conveniently limit a user's bandwidth.
For any queues to work properly, the traffic must not be FastTracked, make sure your Firewall does not FastTrack traffic that you want to limit.
First, make the DHCPv6 binding static, otherwise, it will not be possible to set a rate limit to a DHCPv6 binding:
[admin@MikroTik] > /ipv6 dhcp-server binding print Flags: X - disabled, D - dynamic # ADDRESS DUID SERVER STATUS 0 D fdb4:4de7:a3f8:418c::/66 0x6c3b6b7c413e DHCPv6_Server bound [admin@MikroTik] > /ipv6 dhcp-server binding make-static 0 [admin@MikroTik] > /ipv6 dhcp-server binding print Flags: X - disabled, D - dynamic # ADDRESS DUID SERVER STATUS 0 fdb4:4de7:a3f8:418c::/66 0x6c3b6b7c413e DHCPv6_Server bound
Then you need can set a rate to a DHCPv6 binding that will create a new dynamic simple queue entry:
[admin@MikroTik] > /ipv6 dhcp-server binding set 0 rate-limit=10M/10 [admin@MikroTik] > /queue simple print Flags: X - disabled, I - invalid, D - dynamic 0 D name="dhcp<6c3b6b7c413e fdb4:4de7:a3f8:418c::/66>" target=fdb4:4de7:a3f8:418c::/66 parent=none packet-marks="" priority=8/8 queue=default -small/default-small limit-at=10M/10M max-limit=10M/10M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1
By default allow-dual-stack-queue
is enabled, this will add a single dynamic simple queue entry for both DCHPv6 binding and DHCPv4 lease, without this option enabled separate dynamic simple queue entries will be added for IPv6 and IPv4.
If allow-dual-stack-queue
is enabled, then a single dynamic simple queue entry will be created containing both IPv4 and IPv6 addresses:
[admin@MikroTik] > /queue simple print Flags: X - disabled, I - invalid, D - dynamic 0 D name="dhcp-ds<6C:3B:6B:7C:41:3E>" target=192.168.1.200/32,fdb4:4de7:a3f8:418c::/66 parent=none packet-marks="" priority=8/8 queue=default -small/default-small limit-at=10M/10M max-limit=10M/10M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1
RADIUS Support
Since RouterOS v6.43 it is possible to use RADIUS to assign a rate-limit per DHCPv6 binding, to do so you need to pass the Mikrotik-Rate-Limit attribute from your RADIUS Server for your DHCPv6 binding. To achieve this you first need to set your DHCPv6 Server to use RADIUS for assigning bindings. Below is an example of how to set it up:
/radius add address=10.0.0.1 secret=VERYsecret123 service=dhcp /ipv6 dhcp-server set dhcp1 use-radius=yes
After that, you need to tell your RADIUS Server to pass the Mikrotik-Rate-Limit attribute. In case you are using FreeRADIUS with MySQL, then you need to add appropriate entries into radcheck and radreply tables for a MAC address, that is being used for your DHCPv6 Client. Below is an example for table entries:
INSERT INTO `radcheck` (`username`, `attribute`, `op`, `value`) VALUES ('000c4200d464', 'Auth-Type', ':=', 'Accept'), INSERT INTO `radreply` (`username`, `attribute`, `op`, `value`) VALUES ('000c4200d464', 'Delegated-IPv6-Prefix', '=', 'fdb4:4de7:a3f8:418c::/66'), ('000c4200d464', 'Mikrotik-Rate-Limit', '=', '10M');
By default allow-dual-stack-queue is enabled and will add a single dynamic queue entry if the MAC address from the IPv4 lease (or DUID, if the DHCPv4 Client supports Node-specific Client Identifiers
from RFC4361), but DUID from DHCPv6 Client is not always based on the MAC address from the interface on which the DHCPv6 client is running on, DUID is generated on a per-device basis. For this reason, a single dynamic queue entry might not be created, separate dynamic queue entries might be created instead.
Configuration Example
Enabling IPv6 Prefix delegation
Let's consider that we already have a running DHCP server.
To enable IPv6 prefix delegation, first, we need to create an address pool:
/ipv6 pool add name=myPool prefix=2001:db8:7501::/60 prefix-length=62
Notice that prefix-length is 62 bits, which means that clients will receive /62 prefixes from the /60 pool.
The next step is to enable DHCP-PD:
/ipv6 dhcp-server add name=myServer address-pool=myPool interface=local
To test our server we will set up wide-dhcpv6 on an ubuntu machine:
- install wide-dhcpv6-client
- edit "/etc/wide-dhcpv6/dhcp6c.conf" as above
You can use also RouterOS as a DHCP-PD client.
interface eth2{ send ia-pd 0; }; id-assoc pd { prefix-interface eth3{ sla-id 1; sla-len 2; }; };
- Run DHCP-PD client:
sudo dhcp6c -d -D -f eth2
- Verify that prefix was added to the:
mrz@bumba:/media/aaa$ ip -6 addr .. 2: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2001:db8:7501:1:200:ff:fe00:0/64 scope global valid_lft forever preferred_lft forever inet6 fe80::224:1dff:fe17:81f7/64 scope link valid_lft forever preferred_lft forever
- You can make binding to specific client static so that it always receives the same prefix:
[admin@RB493G] /ipv6 dhcp-server binding> print Flags: X - disabled, D - dynamic # ADDRESS DU IAID SER.. STATUS 0 D 2001:db8:7501:1::/62 16 0 loc.. bound [admin@RB493G] /ipv6 dhcp-server binding> make-static 0
- DHCP-PD also installs a route to assigned prefix into IPv6 routing table:
[admin@RB493G] /ipv6 route> print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable # DST-ADDRESS GATEWAY DISTANCE ... 2 ADS 2001:db8:7501:1::/62 fe80::224:1dff:fe17:8... 1
DHCP Relay
Summary
Sub-menu: /ip dhcp-relay
The purpose of the DHCP relay is to act as a proxy between DHCP clients and the DHCP server. It is useful in networks where the DHCP server is not on the same broadcast domain as the DHCP client.
DHCP relay does not choose the particular DHCP server in the DHCP-server list, it just sends the incoming request to all the listed servers.
Properties
Property | Description |
---|---|
add-relay-info (yes | no; Default: no) | Adds DHCP relay agent information if enabled according to RFC 3046. Agent Circuit ID Sub-option contains mac address of an interface, Agent Remote ID Sub-option contains MAC address of the client from which request was received. |
delay-threshold (time | none; Default: none) | If secs field in DHCP packet is smaller than delay-threshold, then this packet is ignored |
dhcp-server (string; Default: ) | List of DHCP servers' IP addresses which should the DHCP requests be forwarded to |
interface (string; Default: ) | Interface name the DHCP relay will be working on. |
local-address (IP; Default: 0.0.0.0) | The unique IP address of this DHCP relay needed for DHCP server to distinguish relays. If set to 0.0.0.0 - the IP address will be chosen automatically |
relay-info-remote-id (string; Default: ) | specified string will be used to construct Option 82 instead of client's MAC address. Option 82 consist of: interface from which packets was received + client mac address or relay-info-remote-id |
name (string; Default: ) | Descriptive name for the relay |
Configuration Example
Let us consider that you have several IP networks 'behind' other routers, but you want to keep all DHCP servers on a single router. To do this, you need a DHCP relay on your network which will relay DHCP requests from clients to the DHCP server.
This example will show you how to configure a DHCP server and a DHCP relay that serves 2 IP networks - 192.168.1.0/24 and 192.168.2.0/24 that are behind a router DHCP-Relay.
IP Address Configuration
IP addresses of DHCP-Server:
[admin@DHCP-Server] ip address> print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK BROADCAST INTERFACE 0 192.168.0.1/24 192.168.0.0 192.168.0.255 To-DHCP-Relay 1 10.1.0.2/24 10.1.0.0 10.1.0.255 Public [admin@DHCP-Server] ip address>
IP addresses of DHCP-Relay:
[admin@DHCP-Relay] ip address> print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK BROADCAST INTERFACE 0 192.168.0.2/24 192.168.0.0 192.168.0.255 To-DHCP-Server 1 192.168.1.1/24 192.168.1.0 192.168.1.255 Local1 2 192.168.2.1/24 192.168.2.0 192.168.2.255 Local2 [admin@DHCP-Relay] ip address>
DHCP Server Setup
To setup 2 DHCP Servers on the DHCP-Server router add 2 pools. For networks 192.168.1.0/24 and 192.168.2.0:
/ip pool add name=Local1-Pool ranges=192.168.1.11-192.168.1.100 /ip pool add name=Local2-Pool ranges=192.168.2.11-192.168.2.100 [admin@DHCP-Server] ip pool> print # NAME RANGES 0 Local1-Pool 192.168.1.11-192.168.1.100 1 Local2-Pool 192.168.2.11-192.168.2.100 [admin@DHCP-Server] ip pool>
Create DHCP Servers:
/ip dhcp-server add interface=To-DHCP-Relay relay=192.168.1.1 \ address-pool=Local1-Pool name=DHCP-1 disabled=no /ip dhcp-server add interface=To-DHCP-Relay relay=192.168.2.1 \ address-pool=Local2-Pool name=DHCP-2 disabled=no [admin@DHCP-Server] ip dhcp-server> print Flags: X - disabled, I - invalid # NAME INTERFACE RELAY ADDRESS-POOL LEASE-TIME ADD-ARP 0 DHCP-1 To-DHCP-Relay 192.168.1.1 Local1-Pool 3d00:00:00 1 DHCP-2 To-DHCP-Relay 192.168.2.1 Local2-Pool 3d00:00:00 [admin@DHCP-Server] ip dhcp-server>
Configure respective networks:
/ip dhcp-server network add address=192.168.1.0/24 gateway=192.168.1.1 \ dns-server=159.148.60.20 /ip dhcp-server network add address=192.168.2.0/24 gateway=192.168.2.1 \ dns-server 159.148.60.20 [admin@DHCP-Server] ip dhcp-server network> print # ADDRESS GATEWAY DNS-SERVER WINS-SERVER DOMAIN 0 192.168.1.0/24 192.168.1.1 159.148.60.20 1 192.168.2.0/24 192.168.2.1 159.148.60.20 [admin@DHCP-Server] ip dhcp-server network>
DHCP Relay Config
Configuration of DHCP-Server is done. Now let's configure DHCP-Relay:
/ip dhcp-relay add name=Local1-Relay interface=Local1 \ dhcp-server=192.168.0.1 local-address=192.168.1.1 disabled=no /ip dhcp-relay add name=Local2-Relay interface=Local2 \ dhcp-server=192.168.0.1 local-address=192.168.2.1 disabled=no [admin@DHCP-Relay] ip dhcp-relay> print Flags: X - disabled, I - invalid # NAME INTERFACE DHCP-SERVER LOCAL-ADDRESS 0 Local1-Relay Local1 192.168.0.1 192.168.1.1 1 Local2-Relay Local2 192.168.0.1 192.168.2.1 [admin@DHCP-Relay] ip dhcp-relay>
DHCP Relay with VRF (introduced in 7.15)
Let's take the previous setup but we'll consider that the interface to the DHCP server and interfaces to DHCP clients are added in VRF:
/ip vrf add interfaces=To-DHCP-Server name=vrf_server add interfaces=Local2 name=vrf2 add interfaces=Local1 name=vrf1
In the DHCP-relay configuration dhcp-server-vrf should be added:
/ip dhcp-relay/set dhcp-server-vrf=vrf_server numbers=0,1
Due to VRF configuration there are several routing-tables - we should add additional routes:
/ip route add disabled=no distance=1 dst-address=192.168.0.0/24 gateway=To-DHCP-Server@vrf_server pref-src="" routing-table=vrf1 scope=10 suppress-hw-offload=no \ target-scope=10 add disabled=no distance=1 dst-address=192.168.0.0/24 gateway=To-DHCP-Server@vrf_server pref-src="" routing-table=vrf2 scope=10 suppress-hw-offload=no \ target-scope=10 add disabled=no dst-address=192.168.1.0/24 gateway=Local1@vrf1 routing-table=vrf_server suppress-hw-offload=no add disabled=no distance=1 dst-address=192.168.2.0/24 gateway=Local2@vrf2 pref-src="" routing-table=vrf_server scope=30 suppress-hw-offload=no \ target-scope=10
To achieve successful DHCP-server - DHCP-relay communication we should add NAT rules:
/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.2.1 dst-port=67 in-interface=To-DHCP-Server protocol=udp src-address=192.168.0.1 to-addresses=\ 192.168.0.2 add action=dst-nat chain=dstnat dst-address=192.168.1.1 dst-port=67 in-interface=To-DHCP-Server protocol=udp src-address=192.168.0.1 to-addresses=\ 192.168.0.2
Page edited by Olga Ļ.
- Description
- Configuration
- Supported features
- Examples
- References
Description
RouterOS allows to create multiple Virtual Routing and Forwarding instances on a single router. This is useful for BGP-based MPLS VPNs. Unlike BGP VPLS, which is OSI Layer 2 technology, BGP VRF VPNs work in Layer 3 and as such exchange IP prefixes between routers. VRFs solve the problem of overlapping IP prefixes and provide the required privacy (via separated routing for different VPNs).
It is possible to set up vrf-lite setups or use multi-protocol BGP with VPNv4 address family to distribute routes from VRF routing tables - not only to other routers, but also to different routing tables in the router itself.
Configuration
VRF table is created in /ip vrf
menu. After the VRF config is created routing table mapping is added (a dynamic table with the same name is created). Each active VRF will always have a mapped routing table.
[admin@arm-bgp] /ip/vrf> print Flags: X - disabled; * - builtin 0 * name="main" interfaces=all [admin@arm-bgp] /routing/table> print Flags: D - dynamic; X - disabled, I - invalid; U - used 0 D name="main" fib
Note that the order of the added VRFs is significant. To properly match which interface will belong to the VRF care must be taken to place VRFs in the correct order (matching is done starting from the top entry, just like firewall rules).
Since each VRF has mapped routing table, count of max unique VRFs is also limited to 4096.
Let's look at the following example:
[admin@arm-bgp] /ip/vrf> print Flags: X - disabled; * - builtin 0 * name="main" interfaces=all 1 name="myVrf" interfaces=lo_vrf
Since the first entry is matching all the interfaces, the second VRF will not have any interfaces added. To fix the problem order of the entries must be changed.
[admin@arm-bgp] /ip/vrf> move 1 0 [admin@arm-bgp] /ip/vrf> print Flags: X - disabled; * - builtin 0 name="myVrf" interfaces=lo_vrf 1 * name="main" interfaces=all
Connected routes from the interfaces assigned to the VRF will be installed in the right routing table automatically.
When the interface is assigned to the VRF as well as connected routes it does not mean that RouterOS services will magically know which VRF to use just by specifying the IP address in the configuration. Each service needs VRF support to be added and explicit configuration. Whether the service has VRF support and has VRF configuration options refer to appropriate service documentation.
For example, let's make an SSH service to listen for connections on the interfaces belonging to the VRF:
[admin@arm-bgp] /ip/service> set ssh vrf=myVrf [admin@arm-bgp] /ip/service> print Flags: X, I - INVALID Columns: NAME, PORT, CERTIFICATE, VRF # NAME PORT CERTIFICATE VRF 0 telnet 23 main 1 ftp 21 2 www 80 main 3 ssh 22 myVrf 4 X www-ssl 443 none main 5 api 8728 main 6 winbox 8291 main 7 api-ssl 8729 none main
Adding routes to the VRF is as simple as specifying the routing-table parameter when adding the route and specifying in which routing table to resolve the gateway by specifying @name after the gateway IP:
/ip route add dst-address=192.168.1.0/24 gateway=172.16.1.1@myVrf routing-table=myVrf
Traffic leaking between VRFs is possible if the gateway is explicitly set to be resolved in another VRF, for example:
# add route in the myVrf, but resolve the gateway in the main table /ip route add dst-address=192.168.1.0/24 gateway=172.16.1.1@main routing-table=myVrf # add route in the main table, but resolve the gateway in the myVrf /ip route add dst-address=192.168.1.0/24 gateway=172.16.1.1@myVrf
If the gateway configuration does not have an explicitly configured table to be resolved in, then it is considered, that gateway should be resolved in the "main" table.
Supported features
Different services can be placed in specific VRF on which the service is listening for incoming or creating outgoing connections. By default, all services are using the main
table, but it can be changed with a separate vrf
parameter or by specifying the VRF name separated by "@" at the end of the IP address.
Below is the list of supported services.
Feature | Support | Comment |
---|---|---|
BGP | + | /routing bgp template add name=bgp-template1 vrf=vrf1 /routing bgp vpls add name=bgp-vpls1 site-id=10 vrf=vrf1 /routing bgp vpn add label-allocation-policy=per-vrf vrf=vrf1 |
+ | /tool e-mail set address=192.168.88.1 vrf=vrf1 | |
IP Services | + | VRF is supported for /ip service set telnet vrf=vrf1 |
L2TP Client | + | /interface l2tp-client add connect-to=192.168.88.1@vrf1 name=l2tp-out1 user=l2tp-client |
MPLS | + | /mpls ldp add vrf=vrf1 |
Netwatch | + | /tool netwatch add host=192.168.88.1@vrf1 |
NTP | + | /system ntp client set vrf=vrf1 /system ntp server set vrf=vrf1 |
OSPF | + | /routing ospf instance add disabled=no name=ospf-instance-1 vrf=vrf1 |
ping | + | /ping 192.168.88.1 vrf=vrf1 |
RADIUS | + | /radius add address=192.168.88.1@vrf1 /radius incoming set vrf=vrf1 |
RIP | + | /routing rip instance add name=rip-instance-1 vrf=vrf1 |
RPKI | + | /routing rpki add vrf=vrf1 |
SNMP | + | /snmp set vrf=vrf1 |
EoIP | + | /interface eoip add remote-address=192.168.1.1@vrf1 |
IPIP | + | /interface ipip add remote-address=192.168.1.1@vrf1 |
GRE | + | /interface gre add remote-address=192.168.1.1@vrf1 |
SSTP-client | + | /interface sstp-client add connect-to=192.168.1.1@vrf1 |
OVPN-client | + | /interface ovpn-client add connect-to=192.168.1.1@vrf1 |
L2TP-ether | + | /interface l2tp-ether add connect-to=192.168.2.2@vrf |
VXLAN | + | /interface vxlan add vni=10 vrf=vrf1 |
Fetch | + | /tool/fetch address=10.155.28.236@vrf1 mode=ftp src-path=my_file.pcap user=admin password="" |
DNS | + Starting from RouterOS v7.15 | /ip dns set vrf=vrf1 |
DHCP-Relay | + Starting from RouterOS v7.15 | /ip dhcp-relay set dhcp-server-vrf=vrf1 |
Examples
Simple VRF-Lite setup
Let's consider a setup where we need two customer VRFs that require access to the internet:
/ip address add address=172.16.1.2/24 interface=public add address=192.168.1.1/24 interface=ether1 add address=192.168.2.1/24 interface=ether2 /ip route add gateway=172.16.1.1 # add VRF configuration /ip vrf add name=cust_a interface=ether1 place-before 0 add name=cust_b interface=ether2 place-before 0 # add vrf routes /ip route add gateway=172.16.1.1@main routing-table=cust_a add gateway=172.16.1.1@main routing-table=cust_b # masquerade local source /ip firewall nat add chain=srcnat out-interface=public action=masquerade
It might be necessary to ensure that packets coming in the "public" interface can actually reach the correct VRF.
This can be solved by marking new connections originated by the VRF customers and steering the traffic by routing marks of incoming packets on the "public" interface.
# mark new customer connections /ip firewall mangle add action=mark-connection chain=prerouting connection-state=new new-connection-mark=\ cust_a_conn src-address=192.168.1.0/24 passthrough=no add action=mark-connection chain=prerouting connection-state=new new-connection-mark=\ cust_b_conn src-address=192.168.2.0/24 passthrough=no # mark routing /ip firewall mangle add action=mark-routing chain=prerouting connection-mark=cust_a_conn \ in-interface=public new-routing-mark=cust_a add action=mark-routing chain=prerouting connection-mark=cust_b_conn \ in-interface=public new-routing-mark=cust_b
Static VRF-Lite Connected route leaking
Sometimes it is necessary to access directly connected resources from another vrf. In our example setup we have two connected networks each in its own VRF. And we want to allow client1 to be able to access client2.
+-----------------+ |+-vrf1-+ +-vrf2-+| client1(*.2)-------||ip *.1| |ip *.1||-------client2(*.2) (10.11.0.0/24) |+------+ +------+| (10.12.0.0/24) +-----------------+
/ip address add address=10.11.0.1/24 interface=sfp-sfpplus1 add address=10.12.0.1/24 interface=sfp-sfpplus2 # add VRF configuration /ip vrf add name=vrfTest1 interface=sfp-sfpplus1 place-before 0 add name=vrfTest2 interface=sfp-sfpplus2 place-before 0
We can say that connected network is reachable on specific vrf by setting gateway "interface@vrf"
# add vrf routes /ip route add dst-address=10.11.0.0/24 gateway="sfp-sfpplus1@vrfTest1" routing-table=vrfTest2 add dst-address=10.12.0.0/24 gateway="sfp-sfpplus2@vrfTest2" routing-table=vrfTest1
Verify routes and reachability:
[admin@CCR2004_2XS] /ip/route> print detail Flags: D - dynamic; X - disabled, I - inactive, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, i - is-is, d - dhcp, v - vpn, m - modem, y - bgp-mpls-vpn; H - hw-offloaded; + - ecmp DAc dst-address=111.11.0.0/24 routing-table=vrfTest1 gateway=sfp-sfpplus1@vrfTest1 immediate-gw=sfp-sfpplus1 distance=0 scope=10 suppress-hw-offload=no local-address=111.11.0.1%sfp-sfpplus1@vrfTest1 1 As dst-address=111.12.0.0/24 routing-table=vrfTest1 pref-src="" gateway=vrfTest2 immediate-gw=vrfTest2 distance=1 scope=30 target-scope=10 suppress-hw-offload=no 2 As dst-address=111.11.0.0/24 routing-table=vrfTest2 pref-src="" gateway=vrfTest1 immediate-gw=vrfTest1 distance=1 scope=30 target-scope=10 suppress-hw-offload=no DAc dst-address=111.12.0.0/24 routing-table=vrfTest2 gateway=sfp-sfpplus2@vrfTest2 immediate-gw=sfp-sfpplus2 distance=0 scope=10 suppress-hw-offload=no local-address=111.12.0.1%sfp-sfpplus2@vrfTest2
[admin@cl2] > /ping 111.11.0.2 src-address=111.12.0.2 SEQ HOST SIZE TTL TIME STATUS 0 111.11.0.2 56 64 67us 1 111.11.0.2 56 64 61us sent=2 received=2 packet-loss=0% min-rtt=61us avg-rtt=64u
Keep in mind that trying to leak overlapping networks will not work.
But now what if we want to access routers local address located in another vrf?
[admin@cl2] > /ping 111.11.0.1 src-address=111.12.0.2 SEQ HOST SIZE TTL TIME STATUS 0 111.11.0.1 timeout 1 111.11.0.1 timeout sent=2 received=0 packet-loss=100%
Approach with "interface@vrf" gateways works only when router is forwarding packets. To access local vrf addresses we need to route to the vrf interface.
# add vrf routes /ip route add dst-address=10.11.0.0/24 gateway=vrfTest1@vrfTest1 routing-table=vrfTest2 add dst-address=10.12.0.0/24 gateway=vrfTest2@vrfTest2 routing-table=vrfTest1
[admin@cl2] > /ping 111.11.0.1 src-address=111.12.0.2 SEQ HOST SIZE TTL TIME STATUS 0 111.11.0.1 56 64 67us 1 111.11.0.1 56 64 61us sent=2 received=2 packet-loss=0% min-rtt=61us avg-rtt=64u
Dynamic Vrf-Lite route leaking
With large enough setups static route leaking is not sufficient. Let's consider we have the same setup as in static route leaking example plus ipv6 addresses, just for demonstration.
/ip address add address=10.11.0.1/24 interface=sfp-sfpplus1 add address=10.12.0.1/24 interface=sfp-sfpplus2 # add VRF configuration /ip vrf add name=vrfTest1 interface=sfp-sfpplus1 place-before 0 add name=vrfTest2 interface=sfp-sfpplus2 place-before 0 /ipv6 address add address=2001:1::1 advertise=no interface=sfp-sfpplus1 add address=2001:2::1 advertise=no interface=sfp-sfpplus2
We can use BGP VPN to leak local routes without actually establishing BGP session.
/routing bgp vpn add export.redistribute=connected .route-targets=1:1 import.route-targets=1:2 label-allocation-policy=per-vrf name=bgp-mpls-vpn-1 \ route-distinguisher=1.2.3.4:1 vrf=vrfTest1 add export.redistribute=connected .route-targets=1:2 import.route-targets=1:1 label-allocation-policy=per-vrf name=bgp-mpls-vpn-2 \ route-distinguisher=1.2.3.4:1 vrf=vrfTest2
Be careful with import/export route targets, if not set up properly local vrf routes from itself will be imported.
Now we can see that connected routes between VRFs are exchanged
[admin@CCR2004_2XS] > /routing route print where dst-address in 111.0.0.0/8 && afi=ip4 ... Ac afi=ip4 contribution=active dst-address=111.11.0.0/24 routing-table=vrfTest1 gateway=sfp-sfpplus1@vrfTest1 immediate-gw=sfp-sfpplus1 distance=0 scope=10 belongs-to="connected" local-address=111.11.0.1%sfp-sfpplus1@vrfTest1 debug.fwp-ptr=0x202421E0 Ay afi=ip4 contribution=best-candidate dst-address=111.12.0.0/24 routing-table=vrfTest1 label=17 gateway=vrfTest2@vrfTest2 immediate-gw=sfp-sfpplus2 distance=200 scope=40 target-scope=10 belongs-to="bgp-mpls-vpn-1-bgp-mpls-vpn-2-connected-export-import" bgp.ext-communities=rt:1:2 .atomic-aggregate=no .origin=incomplete debug.fwp-ptr=0x202425A0 Ay afi=ip4 contribution=best-candidate dst-address=111.11.0.0/24 routing-table=vrfTest2 label=16 gateway=vrfTest1@vrfTest1 immediate-gw=sfp-sfpplus1 distance=200 scope=40 target-scope=10 belongs-to="bgp-mpls-vpn-2-bgp-mpls-vpn-1-connected-export-import" bgp.ext-communities=rt:1:1 .atomic-aggregate=no .origin=incomplete debug.fwp-ptr=0x202424E0 Ac afi=ip4 contribution=active dst-address=111.12.0.0/24 routing-table=vrfTest2 gateway=sfp-sfpplus2@vrfTest2 immediate-gw=sfp-sfpplus2 distance=0 scope=10 belongs-to="connected" local-address=111.12.0.1%sfp-sfpplus2@vrfTest2 debug.fwp-ptr=0x20242240
And IPv6 too:
[admin@CCR2004_2XS] /routing/route> print detail where dst-address in 2001::/8 && afi=ip6 ... Ac afi=ip6 contribution=active dst-address=2001:1::/64 routing-table=vrfTest1 gateway=sfp-sfpplus1@vrfTest1 immediate-gw=sfp-sfpplus1 distance=0 scope=10 belongs-to="connected" local-address=2001:1::1%sfp-sfpplus1@vrfTest1 debug.fwp-ptr=0x20242300 Ay afi=ip6 contribution=active dst-address=2001:2::/64 routing-table=vrfTest1 label=17 gateway=vrfTest2@vrfTest2 immediate-gw=sfp-sfpplus2 distance=200 scope=40 target-scope=10 belongs-to="bgp-mpls-vpn-1-bgp-mpls-vpn-2-connected-export-import" bgp.ext-communities=rt:1:2 .atomic-aggregate=no .origin=incomplete debug.fwp-ptr=0x202425A0 Ay afi=ip6 contribution=active dst-address=2001:1::/64 routing-table=vrfTest2 label=16 gateway=vrfTest1@vrfTest1 immediate-gw=sfp-sfpplus1 distance=200 scope=40 target-scope=10 belongs-to="bgp-mpls-vpn-2-bgp-mpls-vpn-1-connected-export-import" bgp.ext-communities=rt:1:1 .atomic-aggregate=no .origin=incomplete debug.fwp-ptr=0x202424E0 Ac afi=ip6 contribution=active dst-address=2001:2::/64 routing-table=vrfTest2 gateway=sfp-sfpplus2@vrfTest2 immediate-gw=sfp-sfpplus2 distance=0 scope=10 belongs-to="connected" local-address=2001:2::1%sfp-sfpplus2@vrfTest2 debug.fwp-ptr=0x20242360
Dynamic Vrf-Lite route leaking (old workaround)
Before ROS v7.14 there were no mechanism to leak routes from one VRF instance to another within the same router.
As a workaround, it was possible to create a tunnel between two locally configure loopback addresses and assign each tunnel endpoint to its own VRF. Then it is possible to run either dynamic routing protocols or set up static routes to leak between both VRFs.
The downside of this approach is that tunnel must be created between each VRF where routes should be leaked (create a full mesh), which significantly complicates configuration even if there are just several VRFs, not to mention more complicated setups.
For example, to leak routes between 5 VRFs it would require n * ( n – 1) / 2 connections, which will lead to the setup with 20 tunnel endpoints and 20 OSPF instances on one router.
Example config with two VRFs of this method:
/interface bridge add name=dummy_custC add name=dummy_custB add name=lo1 add name=lo2 /ip address add address=111.255.255.1 interface=lo1 network=111.255.255.1 add address=111.255.255.2 interface=lo2 network=111.255.255.2 add address=172.16.1.0/24 interface=dummy_custC network=172.16.1.0 add address=172.16.2.0/24 interface=dummy_custB network=172.16.2.0 /interface ipip add local-address=111.255.255.1 name=ipip-tunnel1 remote-address=111.255.255.2 add local-address=111.255.255.2 name=ipip-tunnel2 remote-address=111.255.255.1 /ip address add address=192.168.1.1/24 interface=ipip-tunnel1 network=192.168.1.0 add address=192.168.1.2/24 interface=ipip-tunnel2 network=192.168.1.0 /ip vrf add interfaces=ipip-tunnel1,dummy_custC name=custC add interfaces=ipip-tunnel2,dummy_custB name=custB /routing ospf instance add disabled=no name=i2_custB redistribute=connected,static,copy router-id=192.168.1.1 routing-table=custB vrf=custB add disabled=no name=i2_custC redistribute=connected router-id=192.168.1.2 routing-table=custC vrf=custC /routing ospf area add disabled=no instance=i2_custB name=custB_bb add disabled=no instance=i2_custC name=custC_bb /routing ospf interface-template add area=custB_bb disabled=no networks=192.168.1.0/24 add area=custC_bb disabled=no networks=192.168.1.0/24
Result:
[admin@rack1_b36_CCR1009] /routing/ospf/neighbor> print Flags: V - virtual; D - dynamic 0 D instance=i2_custB area=custB_bb address=192.168.1.1 priority=128 router-id=192.168.1.2 dr=192.168.1.1 bdr=192.168.1.2 state="Full" state-changes=6 adjacency=41m28s timeout=33s 1 D instance=i2_custC area=custC_bb address=192.168.1.2 priority=128 router-id=192.168.1.1 dr=192.168.1.1 bdr=192.168.1.2 state="Full" state-changes=6 adjacency=41m28s timeout=33s [admin@rack1_b36_CCR1009] /ip/route> print where routing-table=custB Flags: D - DYNAMIC; A - ACTIVE; c, s, o, y - COPY Columns: DST-ADDRESS, GATEWAY, DISTANCE DST-ADDRESS GATEWAY DISTANCE DAo 172.16.1.0/24 192.168.1.1%ipip-tunnel2@custB 110 DAc 172.16.2.0/24 dummy_custB@custB 0 DAc 192.168.1.0/24 ipip-tunnel2@custB 0 [admin@rack1_b36_CCR1009] > /ip route/print where routing-table=custC Flags: D - DYNAMIC; A - ACTIVE; c, o, y - COPY Columns: DST-ADDRESS, GATEWAY, DISTANCE DST-ADDRESS GATEWAY DISTANCE DAc 172.16.1.0/24 dummy_custC@custC 0 DAo 172.16.2.0/24 192.168.1.2%ipip-tunnel1@custC 110 DAc 192.168.1.0/24 ipip-tunnel1@custC 0
The simplest MPLS VPN setup
In this example, a rudimentary MPLS backbone (consisting of two Provider Edge (PE) routers PE1 and PE2) is created and configured to forward traffic between Customer Edge (CE) routers CE1 and CE2 routers that belong to cust-one VPN.
CE1 Router
/ip address add address=10.1.1.1/24 interface=ether1 # use static routing /ip route add dst-address=10.3.3.0/24 gateway=10.1.1.2
CE2 Router
/ip address add address=10.3.3.4/24 interface=ether1 /ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3
PE1 Router
/interface bridge add name=lobridge /ip address add address=10.1.1.2/24 interface=ether1 /ip address add address=10.2.2.2/24 interface=ether2 /ip address add address=10.5.5.2/32 interface=lobridge /ip vrf add name=cust-one interfaces=ether1 /mpls ldp add enabled=yes transport-address=10.5.5.2 lsr-id=10.5.5.2 /mpls ldp interface add interface=ether2 /routing bgp template set default as=65000 /routing bgp vpn add vrf=cust-one \ route-distinguisher=1.1.1.1:111 \ import.route-targets=1.1.1.1:111 \ import.router-id=cust-one \ export.redistribute=connected \ export.route-targets=1.1.1.1:111 \ label-allocation-policy=per-vrf /routing bgp connection add template=default remote.address=10.5.5.3 address-families=vpnv4 local.address=10.5.5.2 # add route to the remote BGP peer's loopback address /ip route add dst-address=10.5.5.3/32 gateway=10.2.2.3
PE2 Router (Cisco)
ip vrf cust-one rd 1.1.1.1:111 route-target export 1.1.1.1:111 route-target import 1.1.1.1:111 exit interface Loopback0 ip address 10.5.5.3 255.255.255.255 mpls ldp router-id Loopback0 force mpls label protocol ldp interface FastEthernet0/0 ip address 10.2.2.3 255.255.255.0 mpls ip interface FastEthernet1/0 ip vrf forwarding cust-one ip address 10.3.3.3 255.255.255.0 router bgp 65000 neighbor 10.5.5.2 remote-as 65000 neighbor 10.5.5.2 update-source Loopback0 address-family vpnv4 neighbor 10.5.5.2 activate neighbor 10.5.5.2 send-community both exit-address-family address-family ipv4 vrf cust-one redistribute connected exit-address-family ip route 10.5.5.2 255.255.255.255 10.2.2.2
Results
Check that VPNv4 route redistribution is working:
[admin@PE1] /routing/route> print detail where afi="vpn4" Flags: X - disabled, F - filtered, U - unreachable, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - modem, a - ldp-address, l - l dp-mapping, g - slaac, y - bgp-mpls-vpn; H - hw-offloaded; + - ecmp, B - blackhole Ab afi=vpn4 contribution=active dst-address=111.16.0.0/24&1.1.1.1:111 routing-table=main label=16 gateway=111.111.111.4 immediate-gw=111.13.0.2%ether9 distance=200 scope=40 target-scope=30 belongs-to="bgp-VPN4-111.111.111.4" bgp.peer-cache-id=*2C00011 .as-path="65511" .ext-communities=rt:1.1.1.1:111 .local-pref=100 .atomic-aggregate=yes .origin=igp debug.fwp-ptr=0x202427E0 [admin@PE1] /routing/bgp/advertisements> print 0 peer=to-pe2-1 dst=10.1.1.0/24 local-pref=100 origin=2 ext-communities=rt:1.1.1.1:111 atomic-aggregate=yes
Check that the 10.3.3.0 is installed in IP routes, in the cust-one route table:
[admin@PE1] > /ip route print where routing-table="cust-one" Flags: D - DYNAMIC; A - ACTIVE; c, b, y - BGP-MPLS-VPN Columns: DST-ADDRESS, GATEWAY, DISTANCE # DST-ADDRESS GATEWAY DISTANCE 0 ADC 10.1.1.0/24 ether1@cust-one 0 1 ADb 10.3.3.0/24 10.5.5.3 20
Let's take a closer look at IP routes in cust-one VRF. The 10.1.1.0/24 IP prefix is a connected route that belongs to an interface that was configured to belong to cust-one VRF. The 10.3.3.0/24 IP prefix was advertised via BGP as a VPNv4 route from PE2 and is imported in this VRF routing table, because our configured import-route-targets matched the BGP extended communities attribute it was advertised with.
[admin@PE1] /routing/route> print detail where routing-table="cust-one" Flags: X - disabled, F - filtered, U - unreachable, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - modem, a - ldp-address, l - l dp-mapping, g - slaac, y - bgp-mpls-vpn; H - hw-offloaded; + - ecmp, B - blackhole Ac afi=ip4 contribution=active dst-address=10.1.1.0/24 routing-table=cust-one gateway=ether1@cust-one immediate-gw=ether1 distance=0 scope=10 belongs-to="connected" local-address=10.1.1.2%ether1@cust-one debug.fwp-ptr=0x202420C0 Ay afi=ip4 contribution=active dst-address=10.3.3.0/24 routing-table=cust-one label=16 gateway=10.5.5.3 immediate-gw=10.2.2.3%ether2 distance=20 scope=40 target-scope=30 belongs-to="bgp-mpls-vpn-1-bgp-VPN4-10.5.5.3-import" bgp.peer-cache-id=*2C00011 .ext-communities=rt:1.1.1.1:111 .local-pref=100 .atomic-aggregate=yes .origin=igp debug.fwp-ptr=0x20242840 [admin@PE1] /routing/route> print detail where afi="vpn4" Flags: X - disabled, F - filtered, U - unreachable, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - modem, a - ldp-address, l - l dp-mapping, g - slaac, y - bgp-mpls-vpn; H - hw-offloaded; + - ecmp, B - blackhole Ay afi=vpn4 contribution=active dst-address=10.1.1.0/24&1.1.1.1:111 routing-table=main label=19 gateway=ether1@cust-one immediate-gw=ether1 distance=200 scope=40 target-scope=10 belongs-to="bgp-mpls-vpn-1-connected-export" bgp.ext-communities=rt:1.1.1.1:1111 .atomic-aggregate=no .origin=incomplete debug.fwp-ptr=0x202426C0 Ab afi=vpn4 contribution=active dst-address=10.3.3.0/24&1.1.1.1:111 routing-table=main label=16 gateway=10.5.5.3 immediate-gw=10.2.2.3%ether2 distance=200 scope=40 target-scope=30 belongs-to="bgp-VPN4-10.5.5.3" bgp.peer-cache-id=*2C00011 .ext-communities=rt:1.1.1.1:111 .local-pref=100 .atomic-aggregate=yes .origin=igp debug.fwp-ptr=0x202427E0
The same for Cisco:
PE2#show ip bgp vpnv4 all BGP table version is 5, local router ID is 10.5.5.3 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1.1.1.1:111 (default for vrf cust-one) *>i10.1.1.0/24 10.5.5.2 100 0 ? *> 10.3.3.0/24 0.0.0.0 0 32768 ? PE2#show ip route vrf cust-one Routing Table: cust-one Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets B 10.1.1.0 [200/0] via 10.5.5.2, 00:05:33 10.0.0.0/24 is subnetted, 1 subnets C 10.3.3.0 is directly connected, FastEthernet1/0
You should be able to ping from CE1 to CE2 and vice versa.
[admin@CE1] > /ping 10.3.3.4 10.3.3.4 64 byte ping: ttl=62 time=18 ms 10.3.3.4 64 byte ping: ttl=62 time=13 ms 10.3.3.4 64 byte ping: ttl=62 time=13 ms 10.3.3.4 64 byte ping: ttl=62 time=14 ms 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 13/14.5/18 ms
A more complicated setup (changes only)
As opposed to the simplest setup, in this example, we have two customers: cust-one and cust-two.
We configure two VPNs for them, cust-one and cust-two respectively, and exchange all routes between them. (This is also called "route leaking").
Note that this could be not the most typical setup, because routes are usually not exchanged between different customers. In contrast, by default, it should not be possible to gain access from one VRF site to a different VRF site in another VPN. (This is the "Private" aspect of VPNs.) Separate routing is a way to provide privacy, and it is also required to solve the problem of overlapping IP network prefixes. Route exchange is in direct conflict with these two requirements but may sometimes be needed (e.g. temp. solution when two customers are migrating to a single network infrastructure).
CE1 Router, cust-one
/ip route add dst-address=10.4.4.0/24 gateway=10.1.1.2
CE2 Router, cust-one
/ip route add dst-address=10.4.4.0/24 gateway=10.3.3.3
CE1 Router,cust-two
/ip address add address=10.4.4.5 interface=ether1 /ip route add dst-address=10.1.1.0/24 gateway=10.3.3.3 /ip route add dst-address=10.3.3.0/24 gateway=10.3.3.3
PE1 Router
# replace the old BGP VPN with this: /routing bgp vpn add vrf=cust-one \ export.redistribute=connected \ route-distinguisher=1.1.1.1:111 \ import.route-targets=1.1.1.1:111,2.2.2.2:222 \ export.route-targets=1.1.1.1:111
PE2 Router (Cisco)
ip vrf cust-one rd 1.1.1.1:111 route-target export 1.1.1.1:111 route-target import 1.1.1.1:111 route-target import 2.2.2.2:222 exit ip vrf cust-two rd 2.2.2.2:222 route-target export 2.2.2.2:222 route-target import 1.1.1.1:111 route-target import 2.2.2.2:222 exit interface FastEthernet2/0 ip vrf forwarding cust-two ip address 10.4.4.3 255.255.255.0 router bgp 65000 address-family ipv4 vrf cust-two redistribute connected exit-address-family
Variation: replace the Cisco with another MT
PE2 Mikrotik config
/interface bridge add name=lobridge /ip address add address=10.2.2.3/24 interface=ether1 add address=10.3.3.3/24 interface=ether2 add address=10.4.4.3/24 interface=ether3 add address=10.5.5.3/32 interface=lobridge /ip vrf add name=cust-one interfaces=ether2 add name=cust-two interfaces=ether3 /mpls ldp add enabled=yes transport-address=10.5.5.3 /mpls ldp interface add interface=ether1 /routing bgp template set default as=65000 /routing bgp vpn add vrf=cust-one \ export.redistribute=connected \ route-distinguisher=1.1.1.1:111 \ import.route-targets=1.1.1.1:111,2.2.2.2:222 \ export.route-targets=1.1.1.1:111 \ add vrf=cust-two \ export.redistribute=connected \ route-distinguisher=2.2.2.2:222 \ import.route-targets=1.1.1.1:111,2.2.2.2:222 \ export.route-targets=2.2.2.2:222 \ /routing bgp connection add template=default remote.address=10.5.5.2 address-families=vpnv4 local.address=10.5.5.3 # add route to the remote BGP peer's loopback address /ip route add dst-address=10.5.5.2/32 gateway=10.2.2.2
Results
The output of /ip route print now is interesting enough to deserve detailed observation.
[admin@PE2] /ip route> print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADb 10.1.1.0/24 10.5.5.2 recurs... 20 1 ADC 10.3.3.0/24 10.3.3.3 ether2 0 2 ADb 10.4.4.0/24 20 3 ADb 10.1.1.0/24 10.5.5.2 recurs... 20 4 ADb 10.3.3.0/24 20 5 ADC 10.4.4.0/24 10.4.4.3 ether3 0 6 ADC 10.2.2.0/24 10.2.2.3 ether1 0 7 A S 10.5.5.2/32 10.2.2.2 reacha... 1 8 ADC 10.5.5.3/32 10.5.5.3 lobridge 0
The route 10.1.1.0/24 was received from a remote BGP peer and is installed in both VRF routing tables.
The routes 10.3.3.0/24 and 10.4.4.0/24 are also installed in both VRF routing tables. Each is a connected route in one table and a BGP route in another table. This has nothing to do with their being advertised via BGP. They are simply being "advertised" to the local VPNv4 route table and locally reimported after that. Import and export route-targets determine in which tables they will end up.
This can be deduced from its attributes - they don't have the usual BGP properties. (Route 10.4.4.0/24.)
[admin@PE2] /routing/route> print detail where routing-table=cust-one ...
References
RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs)
MPLS Fundamentals, chapter 7, Luc De Ghein, Cisco Press 2006
Page edited by Guntis G. - "typos"
Summary
The Cloud Router Switch series are highly integrated switches with high-performance MIPS CPU and feature-rich packet processors. The CRS switches can be designed into various Ethernet applications including unmanaged switch, Layer 2 managed switch, carrier switch, and wireless/wired unified packet processing. See Cloud Router Switch configuration examples
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 routers manual.
Features | Description |
---|---|
Forwarding |
|
Mirroring |
|
VLAN |
|
Port Isolation and Leakage |
|
Trunking |
|
Quality of Service (QoS) |
|
Shaping and Scheduling |
|
Access Control List |
|
Cloud Router Switch models
This table clarifies the main differences between Cloud Router Switch models.
Model | Switch Chip | CPU | Wireless | SFP+ port | Access Control List | Jumbo Frame (Bytes) |
CRS105-5S-FB | QCA-8511 | 400MHz | - | - | + | 9204 |
CRS106-1C-5S | QCA-8511 | 400MHz | - | - | + | 9204 |
CRS112-8G-4S | QCA-8511 | 400MHz | - | - | + | 9204 |
CRS210-8G-2S+ | QCA-8519 | 400MHz | - | + | + | 9204 |
CRS212-1G-10S-1S+ | QCA-8519 | 400MHz | - | + | + | 9204 |
CRS226-24G-2S+ | QCA-8519 | 400MHz | - | + | + | 9204 |
CRS125-24G-1S | QCA-8513L | 600MHz | - | - | - | 4064 |
CRS125-24G-1S-2HnD | QCA-8513L | 600MHz | + | - | - | 4064 |
CRS109-8G-1S-2HnD | QCA-8513L | 600MHz | + | - | - | 4064 |
Abbreviations and Explanations
CVID - Customer VLAN id: inner VLAN tag id of the IEEE 802.1ad frame
SVID - Service VLAN id: outer VLAN tag id of the IEEE 802.1ad frame
IVL - Independent VLAN learning - learning/lookup is based on both MAC addresses and VLAN IDs.
SVL - Shared VLAN learning - learning/lookup is based on MAC addresses - not on VLAN IDs.
TPID - Tag Protocol Identifier
PCP - Priority Code Point: a 3-bit field which refers to the IEEE 802.1p priority
DEI - Drop Eligible Indicator
DSCP - Differentiated services Code Point
Drop precedence - internal CRS switch QoS attribute used for packet enqueuing or dropping.
Port Switching
To set up port switching on CRS1xx/2xx series switches, check the Bridge Hardware Offloading page.
Dynamic reserved VLAN entries (VLAN4091; VLAN4090; VLAN4089; etc.) are created in the CRS switch when switched port groups are added when a hardware offloaded bridge is created. These VLANs are necessary for internal operation and have lower precedence than user-configured VLANs.
Multiple switch groups
The CRS1xx/2xx series switches allow you to use multiple bridges with hardware offloading, this allows you to easily isolate multiple switch groups. This can be done by simply creating multiple bridges and enabling hardware offloading.
Multiple hardware offloaded bridge configuration is designed as a fast and simple port isolation solution, but it limits a 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.
CRS1xx/2xx series switches can run multiple hardware offloaded bridges with (R)STP enabled, but it is not recommended since the device is not designed to run multiple (R)STP instances on a hardware level. To isolate multiple switch groups and have (R)STP enabled you should isolate port groups with port isolation profile configuration.
Global Settings
The CRS switch chip is configurable from the /interface ethernet switch
console menu.
Sub-menu: /interface ethernet switch
Property | Description |
---|---|
name (string value; Default: switch1) | Name of the switch. |
bridge-type (customer-vid-used-as-lookup-vid | service-vid-used-as-lookup-vid; Default: customer-vid-used-as-lookup-vid) | The bridge type defines which VLAN tag is used as Lookup-VID. Lookup-VID serves as the VLAN key for all VLAN-based lookups. |
mac-level-isolation (yes | no; Default: yes) | Globally enables or disables MAC level isolation. Once enabled, the switch will check the source and destination MAC address entries and their isolation-profile from the unicast forwarding table. By default, the switch will learn MAC addresses and place them into a promiscuous isolation profile. Other isolation profiles can be used when creating static unicast entries. If the source or destination MAC address is located on a promiscuous isolation profile, the packet is forwarded. If both source and destination MAC addresses are located on the same community1 or community2 isolation profile, the packet is forwarded. The packet is dropped when the source and destination MAC address isolation profile is isolated , or when the source and destination MAC address isolation profiles are from different communities (e.g. source MAC address is community1 and destination MAC address is community2 ). When MAC level isolation is globally disabled, the isolation is bypassed. |
use-svid-in-one2one-vlan-lookup (yes | no; Default: no) | Whether to use service VLAN ID for 1:1 VLAN switching lookup. |
use-cvid-in-one2one-vlan-lookup (yes | no; Default: yes) | Whether to use customer VLAN ID for 1:1 VLAN switching lookup. |
multicast-lookup-mode (dst-ip-and-vid-for-ipv4 | dst-mac-and-vid-always; Default:dst-ip-and-vid-for-ipv4) | Lookup mode for IPv4 multicast bridging.
|
unicast-fdb-timeout (time interval; Default: 5m) | Timeout for Unicast FDB entries. |
override-existing-when-ufdb-full (yes | no; Default: no) | Enable or disable to override existing entry which has the lowest aging value when UFDB is full. |
Property | Description |
---|---|
drop-if-no-vlan-assignment-on-ports (ports; Default: none) | Ports which drop frames if no MAC-based, Protocol-based VLAN assignment or Ingress VLAN Translation is applied. |
drop-if-invalid-or-src-port- -not-member-of-vlan-on-ports (ports; Default: none) | Ports that drop invalid and other port VLAN ID frames. |
unknown-vlan-lookup-mode (ivl | svl; Default: svl) | Lookup and learning mode for packets with invalid VLAN. |
forward-unknown-vlan (yes | no; Default: yes) | Whether to allow forwarding VLANs that are not members of the VLAN table. |
Property | Description |
---|---|
bypass-vlan-ingress-filter-for (protocols; Default: none) | Protocols that are excluded from Ingress VLAN filtering. These protocols are not dropped if they have invalid VLAN. (arp, dhcpv4, dhcpv6, eapol, igmp, mld, nd, pppoe-discovery, ripv1) |
bypass-ingress-port-policing-for (protocols; Default: none) | Protocols that are excluded from Ingress Port Policing. (arp, dhcpv4, dhcpv6, eapol, igmp, mld, nd, pppoe-discovery, ripv1) |
bypass-l2-security-check-filter-for (protocols; Default: none) | Protocols that are excluded from Policy rule security check. (arp, dhcpv4, dhcpv6, eapol, igmp, mld, nd, pppoe-discovery, ripv1) |
Property | Description |
---|---|
ingress-mirror0 (port | trunk,format; Default: none,modified) | The first ingress mirroring analyzer port or trunk and mirroring format:
|
ingress-mirror1 (port | trunk,format; Default: none,modified) | The second ingress mirroring analyzer port or trunk and mirroring format:
|
ingress-mirror-ratio (1/32768..1/1; Default: 1/1) | The proportion of ingress mirrored packets compared to all packets. |
egress-mirror0 (port | trunk,format; Default: none,modified) | The first egress mirroring analyzer port or trunk and mirroring format:
|
egress-mirror1 (port | trunk,format; Default: none,modified) | The second egress mirroring analyzer port or trunk and mirroring format:
|
egress-mirror-ratio (1/32768..1/1; Default: 1/1) | Proportion of egress mirrored packets compared to all packets. |
mirror-egress-if-ingress-mirrored (yes | no; Default: no) | When a packet is applied to both ingress and egress mirroring, only ingress mirroring is performed on the packet, if this setting is disabled. If this setting is enabled both mirroring types are applied. |
mirror-tx-on-mirror-port (yes | no; Default: no) | |
mirrored-packet-qos-priority (0..7; Default: 0) | Remarked priority in mirrored packets. |
mirrored-packet-drop-precedence (drop | green | red | yellow; Default: green) | Remarked drop precedence in mirrored packets. This QoS attribute is used for mirrored packet enqueuing or dropping. |
fdb-uses (mirror0 | mirror1; Default: mirror0) | Analyzer port used for FDB-based mirroring. |
vlan-uses (mirror0 | mirror1; Default: mirror0) | Analyzer port used for VLAN-based mirroring. |
Port Settings
Sub-menu: /interface ethernet switch port
Property | Description |
---|---|
vlan-type (edge-port | network-port; Default: network-port) | Port VLAN type specifies whether VLAN ID is used in UFDB learning. The network port learns VLAN ID in UFDB, edge port does not - VLAN 0. It can be observed only in IVL learning mode. |
isolation-leakage-profile-override (yes | no; Default: !isolation-leakage-profile-override) isolation-leakage-profile (0..31;) | Custom port profile for port isolation/leakage configurations.
|
learn-override (yes | no; Default: !learn-override) learn-limit (1..1023; Default: !learn-limit) | Enable or disable MAC address learning and set the MAC limit on the port. MAC learning limit is disabled by default when !learn-override and !learn-limit are set. Property learn-override is replaced with learn under /interface bridge port menu since RouterOS v6.42. |
drop-when-ufdb-entry-src-drop (yes | no; Default: yes) | Enable or disable to drop packets when UFDB entry has action src-drop. |
allow-unicast-loopback (yes | no; Default: no) | Unicast loopback on port. When enabled, it permits sending back when the source port and destination port are the same for known unicast packets. |
allow-multicast-loopback (yes | no; Default: no) | Multicast loopback on port. When enabled, it permits sending back when the source port and destination port are the same for registered multicast or broadcast packets. |
action-on-static-station-move (copy-to-cpu | drop | forward | redirect-to-cpu; Default: forward) | Action for packets when UFDB already contains a static entry with such MAC but with a different port. |
drop-dynamic-mac-move (yes | no; Default: no) | Prevents MAC relearning until UFDB timeout if MAC is already learned on another port. |
Property | Description |
---|---|
allow-fdb-based-vlan-translate (yes | no; Default: no) | Enable or disable MAC-based VLAN translation on the port. |
allow-mac-based-service-vlan-assignment-for (all-frames | none | tagged-frame-only | untagged-and-priority-tagged-frame-only; Default: none) | Frame type for which applies MAC-based service VLAN translation. |
allow-mac-based-customer-vlan-assignment-for (all-frames | none | tagged-frame-only | untagged-and-priority-tagged-frame-only; Default: none) | Frame type for which applies MAC-based customer VLAN translation. |
default-customer-pcp (0..7; Default: 0) | Default customer PCP of the port. |
default-service-pcp (0..7; Default: 0) | Default service PCP of the port. |
pcp-propagation-for-initial-pcp (yes | no; Default: no) | Enables or disables PCP propagation for initial PCP assignment on ingress.
|
filter-untagged-frame (yes | no; Default: no) | Whether to filter untagged frames on the port. |
filter-priority-tagged-frame (yes | no; Default: no) | Whether to filter tagged frames with priority on the port. |
filter-tagged-frame (yes | no; Default: no) | Whether to filter tagged frames on the port. |
Property | Description |
---|---|
egress-vlan-tag-table-lookup-key (according-to-bridge-type | egress-vid; Default: egress-vid) | Egress VLAN table (VLAN Tagging) lookup:
|
egress-vlan-mode (tagged | unmodified | untagged; Default: unmodified) | Egress VLAN tagging action on the port. |
egress-pcp-propagation (yes | no; Default: no) | Enables or disables egress PCP propagation.
|
Property | Description |
---|---|
ingress-mirror-to (mirror0 | mirror1 | none; Default: none) | Analyzer port for port-based ingress mirroring. |
ingress-mirroring-according-to-vlan (yes | no; Default: no) | |
egress-mirror-to (mirror0 | mirror1 | none; Default: none) | Analyzer port for port-based egress mirroring. |
Property | Description |
---|---|
qos-scheme-precedence (da-based | dscp-based | ingress-acl-based | pcp-based | protocol-based | sa-based | vlan-based; Default: pcp-based, sa-based, da-based, dscp-based, protocol-based, vlan-based) | Specifies applied QoS assignment schemes on the ingress of the port.
|
pcp-or-dscp-based-qos-change-dei (yes | no; Default: no) | Enable or disable PCP or DSCP based DEI change on port. |
pcp-or-dscp-based-qos-change-pcp (yes | no; Default: no) | Enable or disable PCP or DSCP based PCP change on port. |
pcp-or-dscp-based-qos-change-dscp (yes | no; Default: no) | Enable or disable PCP or DSCP based DSCP change on port. |
dscp-based-qos-dscp-to-dscp-mapping (yes | no; Default: yes) | Enable or disable DSCP to internal DSCP mapping on port. |
pcp-based-qos-drop-precedence-mapping (PCP/DEI-range:drop-precedence; Default: 0-15:green) | The new value of drop precedence for the PCP/DEI to drop precedence (drop | green | red | yellow) mapping. Multiple mappings are allowed separated by a comma e.g. "0-7:yellow,8-15:red". |
pcp-based-qos-dscp-mapping (PCP/DEI-range:DEI; Default: 0-15:0) | The new value of DSCP for the PCP/DEI to DSCP (0..63) mapping. Multiple mappings are allowed separated by a comma e.g. "0-7:25,8-15:50". |
pcp-based-qos-dei-mapping (PCP/DEI-range:DEI; Default: 0-15:0) | The new value of DEI for the PCP/DEI to DEI (0..1) mapping. Multiple mappings are allowed separated by a comma e.g. "0-7:0,8-15:1". |
pcp-based-qos-pcp-mapping (PCP/DEI-range:DEI; Default: 0-15:0) | The new value of PCP for the PCP/DEI to PCP (0..7) mapping. Multiple mappings are allowed separated by a comma e.g. "0-7:3,8-15:4". |
pcp-based-qos-priority-mapping (PCP/DEI-range:DEI; Default: 0-15:0) | The new value of internal priority for the PCP/DEI to priority (0..15) mapping. Multiple mappings are allowed separated by a comma e.g. "0-7:5,8-15:15". |
Property | Description |
---|---|
priority-to-queue (priority-range:queue; Default: 0-15:0,1:1,2:2,3:3) | Internal priority (0..15) mapping to queue (0..7) per port. |
per-queue-scheduling (Scheduling-type:Weight; Default: wrr-group0:1,wrr-group0:2,wrr-group0:4,wrr-group0:8,wrr-group0:16,wrr-group0:32, wrr-group0:64,wrr-group0:128) | Set port to use either strict or weighted round robin policy for traffic shaping for each queue group, each queue is separated by a comma. |
Property | Description |
---|---|
ingress-customer-tpid-override (yes | no; Default:!ingress-customer-tpid-override) ingress-customer-tpid (0..10000; Default: 0x8100) | Ingress customer TPID override allows accepting specific frames with a custom customer tag TPID. The default value is for the tag of 802.1Q frames. |
egress-customer-tpid-override (yes | no; Default: !egress-customer-tpid-override) | Egress customer TPID override allows custom identification for egress frames with a customer tag. The default value is for the tag of 802.1Q frames. |
ingress-service-tpid-override (yes | no; Default: !ingress-service-tpid-override) ingress-service-tpid (0..10000; Default: 0x88A8) | Ingress service TPID override allows accepting specific frames with a custom service tag TPID. The default value is for the service tag of 802.1AD frames. |
egress-service-tpid-override (yes | no; Default: !egress-service-tpid-override) | Egress service TPID override allows custom identification for egress frames with a service tag. The default value is for the service tag of 802.1AD frames. |
Property | Description |
---|---|
custom-drop-counter-includes (counters; Default: none) | Custom include to count dropped packets for switch port custom-drop-packet counter.
|
queue-custom-drop-counter0-includes (counters; Default: none) | Custom include to count dropped packets for switch port tx-queue-custom0-drop-packet and bytes for tx-queue-custom0-drop-byte counters.
|
queue-custom-drop-counter1-includes (counters; Default: none) | Custom include to count dropped packets for switch port tx-queue-custom1-drop-packet and bytes for tx-queue-custom1-drop-byte counters.
|
policy-drop-counter-includes (counters; Default: none) | Custom include to count dropped packets for switch port policy-drop-packet counter.
|
Forwarding Databases
Unicast FDB
The unicast forwarding database supports up to 16318 MAC entries.
Sub-menu: /interface ethernet switch unicast-fdb
Property | Description |
---|---|
action (action; Default: forward) | Action for UFDB entry:
|
disabled (yes | no; Default: no) | Enables or disables Unicast FDB entry. |
isolation-profile (community1 | community2 | isolated | promiscuous; Default: promiscuous) | MAC level isolation profile. |
mac-address (MAC address) | The action command applies to the packet when the destination MAC or source MAC matches the entry. |
mirror (yes | no; Default: no) | Enables or disables mirroring based on source MAC or destination MAC. |
port (port) | Matching port for the Unicast FDB entry. |
qos-group (none; Default: none) | Defined QoS group from QoS group menu. |
svl (yes | no; Default: no) | Unicast FDB learning mode:
|
vlan-id (0..4095) | Unicast FDB lookup/learning VLAN id. |
Multicast FDB
CRS125 switch-chip supports up to 1024 entries in MFDB for multicast forwarding. For each multicast packet, destination MAC or destination IP lookup is performed in MFDB. MFDB entries are not automatically learned and can only be configured.
Sub-menu: /interface ethernet switch multicast-fdb
Property | Description |
---|---|
address (X.X.X.X | XX:XX:XX:XX:XX:XX) | Matching IP address or MAC address for multicast packets. |
bypass-vlan-filter (yes | no; Default: no) | Allow to bypass VLAN filtering for matching multicast packets. |
disabled (yes | no; Default: no) | Enables or disables Multicast FDB entry. |
ports (ports) | Member ports for multicast traffic. |
qos-group (none; Default: none) | Defined QoS group from QoS group menu. |
svl (yes | no; Default: no) | Multicast FDB learning mode:
|
vlan-id (0..4095; Default: 0) | Multicast FDB lookup VLAN ID. If the VLAN learning mode is IVL, VLAN id is lookup id, otherwise VLAN id = 0. |
Reserved FDB
Cloud Router Switch supports 256 RFDB entries. Each RFDB entry can store either Layer2 unicast or multicast MAC address with specific commands.
Sub-menu: /interface ethernet switch reserved-fdb
Property | Description |
---|---|
action (copy-to-cpu | drop | forward | redirect-to-cpu; Default: forward) | Action for RFDB entry:
|
bypass-ingress-port-policing (yes | no; Default: no) | Allow to bypass Ingress Port Policer for matching packets. |
bypass-ingress-vlan-filter (yes | no; Default: no) | Allow to bypass VLAN filtering for matching packets. |
disabled (yes | no; Default: no) | Enables or disables Reserved FDB entry. |
mac-address (MAC address; Default: 00:00:00:00:00:00) | Matching MAC address for Reserved FDB entry. |
qos-group (none; Default: none) | Defined QoS group from QoS group menu. |
VLAN
VLAN Table
The VLAN table supports 4096 VLAN entries for storing VLAN member information as well as other VLAN information such as QoS, isolation, forced VLAN, learning, and mirroring.
Sub-menu: /interface ethernet switch vlan
Property | Description |
---|---|
disabled (yes | no; Default: no) | Indicate whether the VLAN entry is disabled. Only enabled entry is applied to the lookup process and forwarding decision. |
flood (yes | no; Default: no) | Enables or disables forced VLAN flooding per VLAN. If the feature is enabled, the result of the destination MAC lookup in the UFDB or MFDB is ignored, and the packet is forced to flood in the VLAN. |
ingress-mirror (yes | no; Default: no) | Enable the ingress mirror per VLAN to support the VLAN-based mirror function. |
learn (yes | no; Default: yes) | Enables or disables source MAC learning for VLAN. |
ports (ports) | Member ports of the VLAN. |
qos-group (none; Default: none) | Defined QoS group from QoS group menu. |
svl (yes | no; Default: no) | FDB lookup mode for lookup in UFDB and MFDB.
|
vlan-id (0..4095) | VLAN ID of the VLAN member entry. |
Egress VLAN Tag
Egress packets can be assigned different VLAN tag formats. The VLAN tags can be removed, added, or remained as is when the packet is sent to the egress port (destination port). Each port has dedicated control of the egress VLAN tag format. The tag formats include:
- Untagged
- Tagged
- Unmodified
The Egress VLAN Tag table includes 4096 entries for VLAN tagging selection.
Sub-menu: /interface ethernet switch egress-vlan-tag
Property | Description |
---|---|
disabled (yes | no; Default: no) | Enables or disables Egress VLAN Tag table entry. |
tagged-ports (ports) | Ports that are tagged in egress. |
vlan-id (0..4095) | VLAN ID which is tagged in egress. |
Ingress/Egress VLAN Translation
The Ingress VLAN Translation table allows for up to 15 entries for each port. One or multiple fields can be selected from the packet header for lookup in the Ingress VLAN Translation table. The S-VLAN or C-VLAN or both configured in the first matched entry are assigned to the packet.
Sub-menu: /interface ethernet switch ingress-vlan-translation
Sub-menu: /interface ethernet switch egress-vlan-translation
Property | Description |
---|---|
customer-dei (0..1; Default: none) | Matching DEI of the customer tag. |
customer-pcp (0..7; Default: none) | Matching PCP of the customer tag. |
customer-vid (0..4095; Default: none) | Matching the VLAN ID of the customer tag. |
customer-vlan-format (any | priority-tagged-or-tagged | tagged | untagged-or-tagged; Default:any) | Type of frames with customer tag for which VLAN translation rule is valid. |
disabled (yes | no; Default: no) | Enables or disables VLAN translation entry. |
new-customer-vid (0..4095; Default: none) | The new customer VLAN ID replaces the matching customer VLAN ID. If set to 4095 and ingress VLAN translation is used, then traffic is dropped. |
new-service-vid (0..4095; Default: none) | The new service VLAN ID replaces the matching service VLAN ID. |
pcp-propagation (yes | no; Default: no) | Enables or disables PCP propagation.
|
ports (ports) | Matching switch ports for VLAN translation rule. |
protocol (protocols; Default: none) | Matching Ethernet protocol. (only for Ingress VLAN Translation) |
sa-learning (yes | no; Default: no) | Enables or disables source MAC learning after VLAN translation. (only for Ingress VLAN Translation) |
service-dei (0..1; Default: none) | Matching DEI of the service tag. |
service-pcp (0..7; Default: none) | Matching PCP of the service tag. |
service-vid (0..4095; Default: none) | Matching VLAN ID of the service tag. |
service-vlan-format (any | priority-tagged-or-tagged | tagged | untagged-or-tagged; Default:any) | Type of frames with service tag for which VLAN translation rule is valid. |
Below is a table of traffic that triggers a rule that has a certain VLAN format set, note that traffic that is tagged with VLAN ID 0 is a special case that is also taken into account.
Property | Description |
---|---|
any | Accepts:
|
priority-tagged-or-tagged | Accepts:
|
tagged | Accepts:
|
untagged-or-tagged | Accepts:
|
If VLAN-format
is set to any
, then customer-vid
/
service-vid
set to 0
will trigger the switch rule with VLAN 0 traffic. In this case, the switch rule will be looking for untagged traffic or traffic with a VLAN 0 tag, and only untagged-or-tagged
will filter out VLAN 0 traffic in this case.
Protocol Based VLAN
Protocol Based VLAN table is used to assign VID and QoS attributes to related protocol packets per port.
Sub-menu: /interface ethernet switch protocol-based-vlan
Property | Description |
---|---|
disabled (yes | no; Default: no) | Enables or disables Protocol Based VLAN entry. |
frame-type (ethernet | llc | rfc-1042; Default: ethernet) | Encapsulation type of the matching frames. |
new-customer-vid (0..4095; Default: 0) | The new customer VLAN ID replaces the original customer VLAN ID for the specified protocol. If set to 4095, then traffic is dropped. |
new-service-vid (0..4095; Default: 0) | The new service VLAN ID replaces the original service VLAN ID for the specified protocol. |
ports (ports) | Matching switch ports for Protocol-based VLAN rule. |
protocol (protocol; Default: 0) | Matching protocol for Protocol-based VLAN rule. |
qos-group (none; Default: none) | Defined QoS group from QoS group menu. |
set-customer-vid-for (all | none | tagged | untagged-or-priority-tagged; Default: all) | Customer VLAN ID assignment command for different packet types. |
set-qos-for (all | none | tagged | untagged-or-priority-tagged; Default: none) | Frame type for which QoS assignment command applies. |
set-service-vid-for (all | none | tagged | untagged-or-priority-tagged; Default: all) | Service VLAN ID assignment command for different packet types. |
MAC Based VLAN
MAC Based VLAN table is used to assign VLAN based on the source MAC.
Sub-menu: /interface ethernet switch mac-based-vlan
Property | Description |
---|---|
disabled (yes | no; Default: no) | Enables or disables MAC Based VLAN entry. |
new-customer-vid (0..4095; Default: 0) | The new customer VLAN ID replaces the original service VLAN ID for matched packets. If set to 4095, then traffic is dropped. |
new-service-vid (0..4095; Default: 0) | The new service VLAN ID replaces the original service VLAN ID for matched packets. |
src-mac-address (MAC address) | Matching source MAC address for MAC based VLAN rule. |
All CRS1xx/2xx series switches support up to 1024 MAC Based VLAN table entries.
1:1 VLAN Switching
1:1 VLAN switching can be used to replace the regular L2 bridging for matched packets. When a packet hits a 1:1 VLAN switching table entry, the destination port information in the entry is assigned to the packet. The matched destination information in the UFDB and MFDB entry no longer applies to the packet.
Sub-menu: /interface ethernet switch one2one-vlan-switching
Property | Description |
---|---|
customer-vid (0..4095; Default: 0) | Matching customer VLAN id for 1:1 VLAN switching. |
disabled (yes | no; Default: no) | Enables or disables 1:1 VLAN switching table entry. |
dst-port (port) | Destination port for matched 1:1 VLAN switching packets. |
service-vid (0..4095; Default: 0) | Matching customer VLAN id for 1:1 VLAN switching. |
Port Isolation/Leakage
The CRS switches support flexible multi-level isolation features, which can be used for user access control, traffic engineering and advanced security and network management. The isolation features provide an organized fabric structure allowing user to easily program and control the access by port, MAC address, VLAN, protocol, flow, and frame type. The following isolation and leakage features are supported:
- Port-level isolation
- MAC-level isolation
- VLAN-level isolation
- Protocol-level isolation
- Flow-level isolation
- Free combination of the above
Port-level isolation supports different control schemes on the source port and destination port. Each entry can be programmed with access control for either the source port or the destination port.
- When the entry is programmed with source port access control, the entry is
applied to the ingress packets.
- When the entry is programmed with destination port access control, the entry
is applied to the egress packets.
Port leakage allows bypassing egress VLAN filtering on the port. A leaky port is allowed to access other ports for various applications such as security, network control, and management. Note: When both isolation and leakage are applied to the same port, the port is isolated.
Sub-menu: /interface ethernet switch port-isolation
Sub-menu: /interface ethernet switch port-leakage
Property | Description |
---|---|
disabled (yes | no; Default: no) | Enables or disables port isolation/leakage entry. |
flow-id (0..63; Default: none) | |
forwarding-type (bridged; routed; Default: bridged,routed) | Matching traffic forwarding type on Cloud Router Switch. |
mac-profile (community1 | community2 | isolated | promiscuous; Default: none) | Matching MAC isolation/leakage profile. |
port-profile (0..31; Default: none) | Matching Port isolation/leakage profile. |
ports (ports; Default: none) | Isolated/leaked ports. |
protocol-type (arp; nd; dhcpv4; dhcpv6; ripv1; Default: arp,nd,dhcpv4,dhcpv6,ripv1) | Included protocols for isolation/leakage. |
registration-status (known; unknown; Default: known,unknown) | Registration status for matching packets. Known are present in UFDB and MFDB, and unknown are not. |
traffic-type (unicast; multicast; broadcast; Default: unicast,multicast,broadcast) | Matching traffic type. |
type (dst | src; Default: src) | Lookup type of the isolation/leakage entry:
|
vlan-profile (community1 | community2 | isolated | promiscuous; Default: none) | Matching VLAN isolation/leakage profile. |
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. Up to 8 Trunk groups are supported with up to 8 Trunk member ports per Trunk group. CRS Port Trunking calculates transmit-hash based on all following parameters: L2 src-dst MAC + L3 src-dst IP + L4 src-dst Port.
Sub-menu: /interface ethernet switch trunk
Property | Description |
---|---|
disabled (yes | no; Default: no) | Enables or disables port trunking entry. |
member-ports (ports) | Member ports of the Trunk group. |
name (string value; Default: trunkX) | Name of the Trunk group. |
Quality of Service
Shaper
Traffic shaping restricts the rate and burst size of the flow which is transmitted out from the interface. The shaper is implemented by a token bucket. If the packet exceeds the maximum rate or the burst size, which means not enough token for the packet, the packet is stored to buffer until there is enough token to transmit it.
Sub-menu: /interface ethernet switch shaper
Property | Description |
---|---|
burst (integer; Default: 100k) | Maximum data rate which can be transmitted while the burst is allowed. |
disabled (yes | no; Default: no) | Enables or disables traffic shaper entry. |
meter-unit (bit | packet; Default: bit) | Measuring units for traffic shaper rate. |
port (port) | Physical port for traffic shaper. |
rate (integer; Default: 1M) | Maximum data rate limit. |
target (port | queueX | wrr-groupX; Default: port) | Three levels of shapers are supported on each port (including CPU port):
|
Ingress Port Policer
Sub-menu: /interface ethernet switch ingress-port-policer
Property | Description |
---|---|
burst (integer; Default: 100k) | Maximum data rate which can be transmitted while the burst is allowed. |
disabled (yes | no; Default: no) | Enables or disables ingress port policer entry. |
meter-len (layer-1 | layer-2 | layer-3; Default: layer-1) | Packet classification which sets the packet byte length for metering.
|
meter-unit (bit | packet; Default: bit) | Measuring units for traffic ingress port policer rate. |
new-dei-for-yellow (0..1 | remap; Default: none) | Remarked DEI for exceeded traffic if yellow-action is remark. |
new-dscp-for-yellow (0..63 | remap; Default: none) | Remarked DSCP for exceeded traffic if yellow-action is remark. |
new-pcp-for-yellow (0..7 | remap; Default: none) | Remarked PCP for exceeded traffic if yellow-action is remark. |
packet-types (packet-types; Default: all types from description) | Matching packet types for which ingress port policer entry is valid. |
port (port) | Physical port or trunk for ingress port policer entry. |
rate (integer) | Maximum data rate limit. |
yellow-action (drop | forward | remark; Default: drop) | Performed action for exceeded traffic. |
QoS Group
The global QoS group table is used for VLAN-based, Protocol-based, and MAC-based QoS group assignment configuration.
Sub-menu: /interface ethernet switch qos-group
Property | Description |
---|---|
dei (0..1; Default: none) | The new value of DEI for the QoS group. |
disabled (yes | no; Default: no) | Enables or disables protocol QoS group entry. |
drop-precedence (drop | green | red | yellow; Default: green) | Drop precedence is an internal QoS attribute used for packet enqueuing or dropping. |
dscp (0..63; Default: none) | The new value of DSCP for the QoS group. |
name (string value; Default: groupX) | Name of the QoS group. |
pcp (0..7; Default: none) | The new value of PCP for the QoS group. |
priority (0..15; Default: 0) | Internal priority is a local significance of priority for classifying traffic to different egress queues on a port. (1 is highest, 15 is lowest) |
DSCP QoS Map
The global DSCP to QOS mapping table is used for mapping from the DSCP of the packet to new QoS attributes configured in the table.
Sub-menu: /interface ethernet switch dscp-qos-map
Property | Description |
---|---|
dei (0..1) | The new value of DEI for the DSCP to QOS mapping entry. |
drop-precedence (drop | green | red | yellow) | The new value of Drop precedence for the DSCP to QOS mapping entry. |
pcp (0..7) | The new value of PCP for the DSCP to QOS mapping entry. |
priority (0..15) | The new value of internal priority for the DSCP to QOS mapping entry. |
DSCP To DSCP Map
The global DSCP to DSCP mapping table is used for mapping from the packet's original DSCP to the new DSCP value configured in the table.
Sub-menu: /interface ethernet switch dscp-to-dscp
Property | Description |
---|---|
new-dscp (0..63) | The new value of DSCP for the DSCP to DSCP mapping entry. |
Policer QoS Map
Sub-menu: /interface ethernet switch policer-qos-map
Property | Description |
---|---|
dei-for-red (0..1; Default: 0) | Policer DEI remapping value for red packets. |
dei-for-yellow (0..1; Default: 0) | Policer DEI remapping value for yellow packets. |
dscp-for-red (0..63; Default: 0) | Policer DSCP remapping value for red packets. |
dscp-for-yellow (0..63; Default: 0) | Policer DSCP remapping value for yellow packets. |
pcp-for-red (0..7; Default: 0) | Policer PCP remapping value for red packets. |
pcp-for-yellow (0..7; Default: 0) | Policer PCP remapping value for yellow packets. |
Access Control List
Access Control List contains of ingress policy and egress policy engines and allows configuration of up to 128 policy rules (limited by RouterOS). It is an advanced tool for wire-speed packet filtering, forwarding, shaping, and modifying based on Layer2, Layer3, and Layer4 protocol header field conditions.
See the Summary section for Access Control List supported Cloud Router Switch devices.
Due to hardware limitations, it is not possible to match broadcast/multicast traffic on specific ports. You should use port isolation, drop traffic on ingress ports, or use VLAN filtering to prevent certain broadcast/multicast traffic from being forwarded.
Sub-menu: /interface ethernet switch acl
ACL condition part for MAC-related fields of packets.
Property | Description |
---|---|
disabled (yes | no; Default: no) | Enables or disables ACL entry. |
table (egress | ingress; Default: ingress) | Selects the policy table for incoming or outgoing packets. |
invert-match (yes | no; Default: no) | Inverts the whole ACL rule matching. |
src-ports (ports,trunks) | Matching physical source ports or trunks. |
dst-ports (ports,trunks) | Matching physical destination ports or trunks. It is not possible to match broadcast/multicast traffic on the egress port due to a hardware limitation. |
mac-src-address (MAC address/Mask) | Source MAC address and mask. |
mac-dst-address (MAC address/Mask) | Destination MAC address and mask. |
dst-addr-registered (yes | no) | Defines whether to match packets with registered state - packets whose destination MAC address is in UFDB/MFDB/RFDB. Valid only in the egress table. |
mac-protocol (802.2 | arp | homeplug-av | ip | ip-or-ipv6 | ipv6 | ipx | lldp | loop-protect | mpls-multicast | mpls-unicast | non-ip | packing-compr | packing-simple | pppoe | pppoe-discovery | rarp | service-vlan | vlan or integer: 0..65535 decimal format or 0x0000-0xffff hex format) | Ethernet payload type (MAC-level protocol)
|
drop-precedence (drop | green | red | yellow) | Matching internal drop precedence. Valid only in the egress table. |
custom-fields |
ACL condition part for VLAN-related fields of packets.
Property | Description |
---|---|
lookup-vid (0..4095) | VLAN id used in lookup. It can be changed before reaching the egress table. |
service-vid (0-4095) | Matching service VLAN id. |
service-pcp (0..7) | Matching service PCP. |
service-dei (0..1) | Matching service DEI. |
service-tag (priority-tagged | tagged | tagged-or-priority-tagged | untagged) | Format of the service tag. |
customer-vid (0-4095) | Matching customer VLAN ID. |
customer-pcp (0..7) | Matching customer PCP. |
customer-dei (0..1) | Matching customer DEI. |
customer-tag (priority-tagged | tagged | tagged-or-priority-tagged | untagged) | Format of the customer tag. |
priority (0..15) | Matching internal priority. Valid only in the egress table. |
ACL condition part for IPv4 and IPv6 related fields of packets.
Property | Description |
---|---|
ip-src (IPv4/0..32) | Matching source IPv4 address. |
ip-dst (IPv4/0..32) | Matching destination IPv4 address. |
ip-protocol (tcp | udp | udp-lite | other) | IP protocol type. |
src-l3-port (0-65535) | Matching Layer3 source port. |
dst-l3-port (0-65535) | Matching Layer3 destination port. |
ttl (0 | 1 | max | other) | Matching TTL field of the packet. |
dscp (0..63) | Matching DSCP field of the packet. |
ecn (0..3) | Matching ECN field of the packet. |
fragmented (yes | no) | Whether to match fragmented packets. |
first-fragment (yes | no) | YES matches not fragmented and the first fragments, NO matches other fragments. |
ipv6-src (IPv6/0..128) | Matching source IPv6 address. |
ipv6-dst (IPv6/0..128) | Matching destination IPv6 address. |
mac-isolation-profile (community1 | community2 | isolated | promiscuous) | Matches isolation profile based on UFDB. Valid only in the egress policy table. |
src-mac-addr-state (dynamic-station-move | sa-found | sa-not-found | static-station-move) | Defines whether to match packets with registered state - packets whose destination MAC address is in UFDB/MFDB/RFDB. Valid only in the egress policy table. |
flow-id (0..63) |
ACL rule action part.
Property | Description |
---|---|
action (copy-to-cpu | drop | forward | redirect-to-cpu | send-to-new-dst-ports; Default: forward) |
|
new-dst-ports (ports,trunks) | If the action is "send-to-new-dst-ports", then this property sets which ports/trunks are the new destinations. |
mirror-to (mirror0 | mirror1) | Mirroring destination for ACL packets. |
policer (policer) | Applied ACL Policer for ACL packets. |
src-mac-learn (yes | no) | Whether to learn the source MAC of the matched ACL packets. Valid only in the ingress policy table. |
new-service-vid (0..4095) | New service VLAN ID for ACL packets. |
new-service-pcp (0..7) | New service PCP for ACL packets. |
new-service-dei (0..1) | New service DEI for ACL packets. |
new-customer-vid (0..4095) | New customer VLAN ID for ACL packets. If set to 4095, then traffic is dropped. |
new-customer-pcp (0..7) | New customer PCP for ACL packets. |
new-customer-dei (0..1) | New customer DEI for ACL packets. |
new-dscp (0..63) | New DSCP for ACL packets. |
new-priority (0..15) | New internal priority for ACL packets. |
new-drop-precedence (drop | green | red | yellow) | New internal drop precedence for ACL packets. |
new-registered-state (yes | no) | Whether to modify packet status. YES sets packet status to registered, NO - unregistered. Valid only in the ingress policy table. |
new-flow-id (0..63) |
Filter bypassing part for ACL packets.
Property | Description |
---|---|
attack-filter-bypass (yes | no; Default: no) | |
ingress-vlan-filter-bypass (yes | no; Default: no) | Allows bypassing ingress VLAN filtering in the VLAN table for matching packets. This applies only to the ingress policy table. |
egress-vlan-filter-bypass (yes | no; Default: no) | Allows bypassing egress VLAN filtering in the VLAN table for matching packets. This applies only to the ingress policy table. |
isolation-filter-bypass (yes | no; Default: no) | Allows bypassing the Isolation table for matching packets. This applies only to the ingress policy table. |
egress-vlan-translate-bypass (yes | no; Default: no) | Allows bypassing egress VLAN translation table for matching packets. |
ACL Policer
Sub-menu: /interface ethernet switch acl policer
Property | Description |
---|---|
name (string; Default: policerX) | Name of the Policer used in ACL. |
yellow-rate (integer) | Maximum data rate limit for packets with yellow drop precedence. |
yellow-burst (integer; Default: 0) | Maximum data rate which can be transmitted while the burst is allowed for packets with yellow drop precedence. |
red-rate (integer); Default: 0) | Maximum data rate limit for packets with red drop precedence. |
red-burst (integer; Default: 0) | Maximum data rate which can be transmitted while the burst is allowed for packets with red drop precedence. |
meter-unit (bit | packet; Default: bit) | Measuring units for ACL traffic rate. |
meter-len (layer-1 | layer-2 | layer-3; Default: layer-1) | Packet classification which sets the packet byte length for metering.
|
color-awareness (yes | no; Default: no) | YES makes the policer to take into account pre-colored drop precedence, NO - ignores drop precedence. |
bucket-coupling (yes | no; Default: no) | |
yellow-action (drop | forward | remark; Default: drop) | Performed action for exceeded traffic with yellow drop precedence. |
new-dei-for-yellow (0..1 | remap) | New DEI for yellow drop precedence packets. |
new-pcp-for-yellow (0..7 | remap) | New PCP for yellow drop precedence packets. |
new-dscp-for-yellow (0..63 | remap) | New DSCP for yellow drop precedence packets. |
red-action (drop | forward | remark; Default: drop) | Performed action for exceeded traffic with red drop precedence. |
new-dei-for-red (0..1 | remap) | New DEI for red drop precedence packets. |
new-pcp-for-red (0..7 | remap) | New PCP for red drop precedence packets. |
new-dscp-for-red (0..63 | remap) | New DSCP for red drop precedence packets. |
See also
Page edited by Guntis G.
- Summary
- Bridge Interface Setup
- Spanning Tree Protocol
- Bridge Settings
- Port Settings
- Hosts Table
- Multicast Table
- Bridge Hardware Offloading
- Bridge VLAN Filtering
- Fast Forward
- IGMP/MLD Snooping
- DHCP Snooping and DHCP Option 82
- Controller Bridge and Port Extender
- Bridge Firewall
- See also
Summary
Ethernet-like networks (Ethernet, Ethernet over IP, IEEE 802.11 in ap-bridge or bridge mode, WDS, VLAN) can be connected together using MAC bridges. The bridge feature allows the interconnection of hosts connected to separate LANs (using EoIP, geographically distributed networks can be bridged as well if any kind of IP network interconnection exists between them) as if they were attached to a single LAN. As bridges are transparent, they do not appear in the traceroute list, and no utility can make a distinction between a host working in one LAN and a host working in another LAN if these LANs are bridged. However, depending on the way the LANs are interconnected, latency and data rate between hosts may vary.
Network loops may emerge (intentionally or not) in complex topologies. Without any special treatment, loops would prevent the network from functioning normally, as they would lead to avalanche-like packet multiplication. Each bridge runs an algorithm that calculates how the loop can be prevented. (R/M)STP allows bridges to communicate with each other, so they can negotiate a loop-free topology. All other alternative connections that would otherwise form loops are put on standby, so that should the main connection fail, another connection could take its place. This algorithm exchanges configuration messages (BPDU - Bridge Protocol Data Unit) periodically, so that all bridges are updated with the newest information about changes in a network topology. (R/M)STP selects a root bridge which is responsible for network reconfiguration, such as blocking and opening ports on other bridges. The root bridge is the bridge with the lowest bridge ID.
Bridge Interface Setup
To combine a number of networks into one bridge, a bridge interface should be created. Later, all the desired interfaces should be set up as its ports. One MAC address from slave (secondary) ports will be assigned to the bridge interface. The MAC address will be chosen automatically, depending on the "port-number", and it can change after a reboot. To avoid unwanted MAC address changes, it is recommended to disable "auto-mac
" and manually specifying the MAC address by using "admin-mac
".
Sub-menu: /interface bridge
Property | Description | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
add-dhcp-option82 (yes | no; Default: no) | Whether to add DHCP Option-82 information (Agent Remote ID and Agent Circuit ID) to DHCP packets. Can be used together with Option-82 capable DHCP server to assign IP addresses and implement policies. This property only has an effect when dhcp-snooping is set to yes . | |||||||||||||||||||||||||||
admin-mac (MAC address; Default: none) | Static MAC address of the bridge. This property only has an effect when auto-mac is set to no . | |||||||||||||||||||||||||||
ageing-time (time; Default: 00:05:00) | How long a host's information will be kept in the bridge database. | |||||||||||||||||||||||||||
arp (disabled | enabled | local-proxy-arp | proxy-arp | reply-only; Default: enabled) | Address Resolution Protocol setting
| |||||||||||||||||||||||||||
arp-timeout (auto | integer; Default: auto) | How long the ARP record is kept in the ARP table after no packets are received from IP address. Value auto equals to the value of arp-timeout in ip/settings , default is 30s. | |||||||||||||||||||||||||||
auto-mac (yes | no; Default: yes) | Automatically select one MAC address of bridge ports as a bridge MAC address, bridge MAC will be chosen from the first added bridge port. After a device reboots, the bridge MAC can change depending on the port-number. | |||||||||||||||||||||||||||
comment (string; Default: ) | Short description of the interface. | |||||||||||||||||||||||||||
dhcp-snooping (yes | no; Default: no) | Enables or disables DHCP Snooping on the bridge. | |||||||||||||||||||||||||||
disabled (yes | no; Default: no) | Changes whether the bridge is disabled. | |||||||||||||||||||||||||||
ether-type (0x9100 | 0x8100 | 0x88a8; Default: 0x8100) | Changes the EtherType, which will be used to determine if a packet has a VLAN tag. Packets that have a matching EtherType are considered as tagged packets. This property only has an effect when vlan-filtering is set to yes . | |||||||||||||||||||||||||||
fast-forward (yes | no; Default: yes) | Special and faster case of Fast Path which works only on bridges with 2 interfaces (enabled by default only for new bridges). More details can be found in the Fast Forward section. | |||||||||||||||||||||||||||
forward-delay (time; Default: 00:00:15) | The time which is spent during the initialization phase of the bridge interface (i.e., after router startup or enabling the interface) in the listening/learning state before the bridge will start functioning normally. | |||||||||||||||||||||||||||
frame-types (admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged; Default: admit-all) | Specifies allowed frame types on a bridge port. This property only has an effect when vlan-filtering is set to yes . | |||||||||||||||||||||||||||
igmp-snooping (yes | no; Default: no) | Enables multicast group and port learning to prevent multicast traffic from flooding all interfaces in a bridge. | |||||||||||||||||||||||||||
igmp-version (2 | 3; Default: 2) | Selects the IGMP version in which IGMP membership queries will be generated when the bridge interface is acting as an IGMP querier. This property only has an effect when igmp-snooping and multicast-querier is set to yes . | |||||||||||||||||||||||||||
ingress-filtering (yes | no; Default: yes) | Enables or disables VLAN ingress filtering, which checks if the ingress port is a member of the received VLAN ID in the bridge VLAN table. By default, VLANs that don't exist in the bridge VLAN table are dropped before they are sent out (egress), but this property allows you to drop the packets when they are received (ingress). Should be used with frame-types to specify if the ingress traffic should be tagged or untagged. This property only has an effect when vlan-filtering is set to yes . The setting is enabled by default since RouterOS v7. | |||||||||||||||||||||||||||
l2mtu (read-only; Default: ) | L2MTU indicates the maximum size of the frame without a MAC header that can be sent by this interface. The L2MTU value will be automatically set by the bridge and it will use the lowest L2MTU value of any associated bridge port. This value cannot be manually changed. | |||||||||||||||||||||||||||
last-member-interval (time; Default: 1s) | When the last client on the bridge port unsubscribes to a multicast group and the bridge is acting as an active querier, the bridge will send group-specific IGMP/MLD query, to make sure that no other client is still subscribed. The setting changes the response time for these queries. In case no membership reports are received in a certain time period ( If the bridge port is configured with fast-leave, the multicast group is removed right away without sending any queries. This property only has an effect when | |||||||||||||||||||||||||||
last-member-query-count (integer: 0..4294967295; Default: 2) | How many times should last-member-interval pass until the IGMP/MLD snooping bridge stops forwarding a certain multicast stream. This property only has an effect when igmp-snooping and multicast-querier is set to yes . | |||||||||||||||||||||||||||
max-hops (integer: 6..40; Default: 20) | Bridge count which BPDU can pass in an MSTP enabled network in the same region before BPDU is being ignored. This property only has an effect when protocol-mode is set to mstp . | |||||||||||||||||||||||||||
max-message-age (time: 6s..40s; Default: 00:00:20) | Changes the Max Age value in BPDU packets, which is transmitted by the root bridge. A root bridge sends a BPDUs with Max Age set to max-message-age value and a Message Age of 0. Every sequential bridge will increment the Message Age before sending their BPDUs. Once a bridge receives a BPDU where Message Age is equal or greater than Max Age, the BPDU is ignored. This property only has an effect when protocol-mode is set to stp or rstp . | |||||||||||||||||||||||||||
membership-interval (time; Default: 4m20s) | The amount of time after an entry in the Multicast Database (MDB) is removed if no IGMP/MLD membership reports are received on a bridge port. This property only has an effect when igmp-snooping is set to yes . | |||||||||||||||||||||||||||
mld-version (1 | 2; Default: 1) | Selects the MLD version in which MLD membership queries will be generated, when the bridge interface is acting as an MLD querier. This property only has an effect when the bridge has an active IPv6 address, igmp-snooping and multicast-querier is set to yes . | |||||||||||||||||||||||||||
mtu (integer; Default: auto) | Maximum transmission unit, by default, the bridge will set MTU automatically and it will use the lowest MTU value of any associated bridge port. The default bridge MTU value without any bridge ports added is 1500. The MTU value can be set manually, but it cannot exceed the bridge L2MTU or the lowest bridge port L2MTU. If a new bridge port is added with L2MTU which is smaller than the When adding VLAN interfaces on the bridge, and when VLAN is using higher MTU than default 1500, it is recommended to set manually the MTU of the bridge. | |||||||||||||||||||||||||||
multicast-querier (yes | no; Default: no) | Multicast querier generates periodic IGMP/MLD general membership queries to which all IGMP/MLD capable devices respond with an IGMP/MLD membership report, usually a PIM (multicast) router or IGMP proxy generates these queries. By using this property you can make an IGMP/MLD snooping enabled bridge to generate IGMP/MLD general membership queries. This property should be used whenever there is no active querier (PIM router or IGMP proxy) in a Layer2 network. Without a multicast querier in a Layer2 network, the Multicast Database (MDB) is not being updated, the learned entries will timeout and IGMP/MLD snooping will not function properly. Only untagged IGMP/MLD general membership queries are generated, IGMP queries are sent with IPv4 0.0.0.0 source address, MLD queries are sent with IPv6 link-local address of the bridge interface. The bridge will not send queries if an external IGMP/MLD querier is detected (see the monitoring values This property only has an effect when | |||||||||||||||||||||||||||
multicast-router (disabled | permanent | temporary-query; Default: temporary-query) | A multicast router port is a port where a multicast router or querier is connected. On this port, unregistered multicast streams and IGMP/MLD membership reports will be sent. This setting changes the state of the multicast router for a bridge interface itself. This property can be used to send IGMP/MLD membership reports to the bridge interface for further multicast routing or proxying. This property only has an effect when igmp-snooping is set to yes .
| |||||||||||||||||||||||||||
name (text; Default: bridgeN) | Name of the bridge interface. | |||||||||||||||||||||||||||
port-cost-mode (long | short; Default: long) | Changes the port path-cost and internal-path-cost mode for bridged ports, utilizing automatic values based on interface speed. This setting does not impact bridged ports with manually configured
For bonded interfaces, the highest path-cost among all bonded member ports is applied, this value remains unaffected by the total link speed of the bonding. For virtual interfaces (such as VLAN, EoIP, VXLAN), as well as wifi, wireless, and 60GHz interfaces, a path-cost of 20,000 is assigned for long mode, and 10 for short mode. For dynamically bridged interfaces (e.g. wifi, wireless, PPP, VPLS), the path-cost defaults to 20,000 for long mode and 10 for short mode. However, this can be manually overridden by the service that dynamically adds interfaces to bridge, for instance, by using the CAPsMAN Use port monitor to observe the applied path-cost. This property has an effect when | |||||||||||||||||||||||||||
priority (integer: 0..65535 decimal format or 0x0000-0xffff hex format; Default: 32768 / 0x8000) | Bridge priority, used by R/STP to determine root bridge, used by MSTP to determine CIST and IST regional root bridge. This property has no effect when protocol-mode is set to none . | |||||||||||||||||||||||||||
protocol-mode (none | rstp | stp | mstp; Default: rstp) | Select Spanning tree protocol (STP) or Rapid spanning tree protocol (RSTP) to ensure a loop-free topology for any bridged LAN. RSTP provides a faster spanning tree convergence after a topology change. Select MSTP to ensure loop-free topology across multiple VLANs. Since RouterOS v6.43 it is possible to forward Reserved MAC addresses that are in the 01:80:C2:00:00:0X range, this can be done by setting the protocol-mode to none . | |||||||||||||||||||||||||||
pvid (integer: 1..4094; Default: 1) | Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. It applies e.g. to frames sent from bridge IP and destined to a bridge port. This property only has an effect when vlan-filtering is set to yes . | |||||||||||||||||||||||||||
querier-interval (time; Default: 4m15s) | Changes the timeout period for detected querier and multicast-router ports. This property only has an effect when igmp-snooping is set to yes . | |||||||||||||||||||||||||||
query-interval (time; Default: 2m5s) | Changes the interval on how often IGMP/MLD general membership queries are sent out when the bridge interface is acting as an IGMP/MLD querier. The interval takes place when the last startup query is sent. This property only has an effect when igmp-snooping and multicast-querier is set to yes . | |||||||||||||||||||||||||||
query-response-interval (time; Default: 10s) | The setting changes the response time for general IGMP/MLD queries when the bridge is active as an IGMP/MLD querier. This property only has an effect when igmp-snooping and multicast-querier is set to yes . | |||||||||||||||||||||||||||
region-name (text; Default: ) | MSTP region name. This property only has an effect when protocol-mode is set to mstp . | |||||||||||||||||||||||||||
region-revision (integer: 0..65535; Default: 0) | MSTP configuration revision number. This property only has an effect when protocol-mode is set to mstp . | |||||||||||||||||||||||||||
startup-query-count (integer: 0..4294967295; Default: 2) | Specifies how many times general IGMP/MLD queries must be sent when bridge interface is enabled or active querier timeouts. This property only has an effect when igmp-snooping and multicast-querier is set to yes . | |||||||||||||||||||||||||||
startup-query-interval (time; Default: 31s250ms) | Specifies the interval between startup general IGMP/MLD queries. This property only has an effect when igmp-snooping and multicast-querier is set to yes . | |||||||||||||||||||||||||||
transmit-hold-count (integer: 1..10; Default: 6) | The Transmit Hold Count used by the Port Transmit state machine to limit the transmission rate. | |||||||||||||||||||||||||||
vlan-filtering (yes | no; Default: no) | Globally enables or disables VLAN functionality for the bridge. |
Changing certain properties can cause the bridge to temporarily disable all ports. This must be taken into account whenever changing such properties on production environments since it can cause all packets to be temporarily dropped. Such properties include vlan-filtering
, protocol-mode
, igmp-snooping
, fast-forward
and others.
Example
To add and enable a bridge interface that will forward L2 packets:
[admin@MikroTik] > interface bridge add [admin@MikroTik] > interface bridge print Flags: X - disabled, R - running 0 R name="bridge1" mtu=auto actual-mtu=1500 l2mtu=65535 arp=enabled arp-timeout=auto mac-address=5E:D2:42:95:56:7F protocol-mode=rstp fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m priority=0x8000 max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no
Bridge Monitoring
To monitor the current status of a bridge interface, use the monitor
command.
Sub-menu: /interface bridge monitor
Property | Description |
---|---|
current-mac-address (MAC address) | Current MAC address of the bridge |
designated-port-count (integer) | Number of designated bridge ports |
igmp-querier (none | interface & IPv4 address) | Shows a bridge port and source IP address from the detected IGMP querier. Only shows detected external IGMP querier, local bridge IGMP querier (including IGMP proxy and PIM) will not be displayed. Monitoring value appears only when igmp-snooping is enabled. |
mld-querier (none | interface & IPv6 address) | Shows a bridge port and source IPv6 address from the detected MLD querier. Only shows detected external MLD querier, local bridge MLD querier will not be displayed. Monitoring value appears only when igmp-snooping is enabled and the bridge has an active IPv6 address. |
multicast-router (yes | no) | Shows if a multicast router is detected on the port. Monitoring value appears only when igmp-snooping is enabled. |
port-count (integer) | Number of the bridge ports |
root-bridge (yes | no) | Shows whether the bridge is the root bridge of the spanning tree |
root-bridge-id (text) | The root bridge ID, which is in form of bridge-priority.bridge-MAC-address |
root-path-cost (integer) | The total cost of the path to the root-bridge |
root-port (name) | Port to which the root bridge is connected to |
state (enabled | disabled) | State of the bridge |
[admin@MikroTik] /interface bridge monitor bridge1 state: enabled current-mac-address: CC:2D:E0:E4:B3:38 root-bridge: yes root-bridge-id: 0x8000.CC:2D:E0:E4:B3:38 root-path-cost: 0 root-port: none port-count: 2 designated-port-count: 2 fast-forward: no
Spanning Tree Protocol
RouterOS bridge interfaces are capable of running Spanning Tree Protocol to ensure a loop-free and redundant topology. For small networks with just 2 bridges STP does not bring many benefits, but for larger networks properly configured STP is very crucial, leaving STP-related values to default may result in a completely unreachable network in case of an even single bridge failure. To achieve a proper loop-free and redundant topology, it is necessary to properly set bridge priorities, port path costs, and port priorities.
In RouterOS it is possible to set any value for bridge priority between 0 and 65535, the IEEE 802.1W standard states that the bridge priority must be in steps of 4096. This can cause incompatibility issues between devices that do not support such values. To avoid compatibility issues, it is recommended to use only these priorities: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440
STP has multiple variants, currently, RouterOS supports STP, RSTP, and MSTP. Depending on needs, either one of them can be used, some devices are able to run some of these protocols using hardware offloading, detailed information about which device support it can be found in the Hardware Offloading section. STP is considered to be outdated and slow, it has been almost entirely replaced in all network topologies by RSTP, which is backward compatible with STP. For network topologies that depend on VLANs, it is recommended to use MSTP since it is a VLAN aware protocol and gives the ability to do load balancing per VLAN groups. There are a lot of considerations that should be made when designing an STP enabled network, more detailed case studies can be found in the Spanning Tree Protocol article. In RouterOS, the protocol-mode
property controls the used STP variant.
RouterOS bridge does not work with PVST and its variants. The PVST BPDUs (with a MAC destination 01:00:0C:CC:CC:CD) are treated by RouterOS bridges as typical multicast packets. In simpler terms, they undergo RouterOS bridge/switch forwarding logic and may get tagged or untagged.
By the IEEE 802.1ad standard, the BPDUs from bridges that comply with IEEE 802.1Q are not compatible with IEEE 802.1ad bridges, this means that the same bridge VLAN protocol should be used across all bridges in a single Layer2 domain, otherwise (R/M)STP will not function properly.
Per-port STP
There might be certain situations where you want to limit STP functionality on single or multiple ports. Below you can find some examples for different use cases.
Be careful when changing the default (R/M)STP functionality, make sure you understand the working principles of STP and BPDUs. Misconfigured (R/M)STP can cause unexpected behavior.
Create edge ports
Setting a bridge port as an edge port will restrict it from sending BPDUs and will ignore any received BPDUs:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether1 edge=yes add bridge=bridge1 interface=ether2
Drop received BPDUs
The bridge filter or NAT rules cannot drop BPDUs when the bridge has STP/RSTP/MSTP enabled due to the special processing of BPDUs. However, dropping received BPDUs on a certain port can be done on some switch chips using ACL rules:
On CRS3xx:
/interface ethernet switch rule add dst-mac-address=01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF new-dst-ports="" ports=ether1 switch=switch1
On CRS1xx/CRS2xx with Access Control List (ACL) support:
/interface ethernet switch acl add action=drop mac-dst-address=01:80:C2:00:00:00 src-ports=ether1
In this example all received BPDUs on ether1 are dropped.
If you intend to drop received BPDUs on a port, then make sure to prevent BPDUs from being sent out from the interface that this port is connected to. A root bridge always sends out BPDUs and under normal conditions is waiting for a more superior BPDU (from a bridge with a lower bridge ID), but the bridge must temporarily disable the new root-port when transitioning from a root bridge to a designated bridge. If you have blocked BPDUs only on one side, then a port will flap continuously.
Enable BPDU guard
In this example, if ether1 receives a BPDU, it will block the port and will require you to manually re-enable it.
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether1 bpdu-guard=yes add bridge=bridge1 interface=ether2
Enable Root guard
In this example, ether1 is configured with restricted-role=yes.
It prevented the port from becoming the root port for the CIST or any MSTI, regardless of its best spanning tree priority vector. Such a port will be selected as an Alternate Port (discarding state) and remains so as long as it continues to receive superior BPDUs. It will automatically transition to the forwarding state when it no longer detects a superior root path. Network administrators may enable this setting to safeguard against external bridges influencing the active spanning tree.
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether1 restricted-role=yes add bridge=bridge1 interface=ether2 [admin@MikroTik] /interface/bridge/port monitor [find] interface: ether1 ether2 status: in-bridge in-bridge port-number: 1 2 role: alternate-port designated-port edge-port: no yes edge-port-discovery: yes yes point-to-point-port: yes yes external-fdb: no no sending-rstp: yes yes learning: no yes forwarding: no yes actual-path-cost: 20000 20000 root-path-cost: 20000 designated-bridge: 0x7000.64:D1:54:C7:3A:6E designated-cost: 0 designated-port-number: 1 hw-offload-group: switch1 switch1
Bridge Settings
Under the bridge settings menu, it is possible to control certain features for all bridge interfaces and monitor global bridge counters.
Sub-menu: /interface bridge settings
Property | Description |
---|---|
use-ip-firewall (yes | no; Default: no) | Force bridged traffic to also be processed by prerouting, forward, and postrouting sections of IP routing (see more details on Packet Flow article). This does not apply to routed traffic. This property is required in case you want to assign Simple Queues or global Queue Tree to traffic in a bridge. Property use-ip-firewall-for-vlan is required in case bridge vlan-filtering is used. |
use-ip-firewall-for-pppoe (yes | no; Default: no) | Send bridged un-encrypted PPPoE traffic to also be processed by IP/Firewall. This property only has an effect when use-ip-firewall is set to yes . This property is required in case you want to assign Simple Queues or global Queue Tree to PPPoE traffic in a bridge. |
use-ip-firewall-for-vlan (yes | no; Default: no) | Send bridged VLAN traffic to also be processed by IP/Firewall. This property only has an effect when use-ip-firewall is set to yes . This property is required in case you want to assign Simple Queues or global Queue Tree to VLAN traffic in a bridge. |
allow-fast-path (yes | no; Default: yes) | Whether to enable a bridge Fast Path globally. |
bridge-fast-path-active (yes | no; Default: ) | Shows whether a bridge FastPath is active globally, Fast Path status per bridge interface is not displayed. |
bridge-fast-path-packets (integer; Default: ) | Shows packet count forwarded by bridge Fast Path. |
bridge-fast-path-bytes (integer; Default: ) | Shows byte count forwarded by bridge Fast Path. |
bridge-fast-forward-packets (integer; Default: ) | Shows packet count forwarded by bridge Fast Forward. |
bridge-fast-forward-bytes (integer; Default: ) | Shows byte count forwarded by bridge Fast Forward. |
In case you want to assign Simple Queues or global Queue Trees to traffic that is being forwarded by a bridge, then you need to enable the use-ip-firewall
property. Without using this property the bridge traffic will never reach the postrouting chain, Simple Queues and global Queue Trees are working in the postrouting chain. To assign Simple Queues or global Queue Trees for VLAN or PPPoE traffic in a bridge you should enable appropriate properties as well.
Port Settings
Port submenu is used to add interfaces in a particular bridge.
Sub-menu: /interface bridge port
Property | Description |
---|---|
auto-isolate (yes | no; Default: no) | When enabled, prevents a port moving from discarding into forwarding state if no BPDUs are received from the neighboring bridge. The port will change into a forwarding state only when a BPDU is received. This property only has an effect when protocol-mode is set to rstp or mstp and edge is set to no . |
bpdu-guard (yes | no; Default: no) | Enables or disables BPDU Guard feature on a port. This feature puts the port in a disabled role if it receives a BPDU and requires the port to be manually disabled and enabled if a BPDU was received. Should be used to prevent a bridge from BPDU related attacks. This property has no effect when protocol-mode is set to none . |
bridge (name; Default: none) | The bridge interface where the respective interface is grouped in. |
broadcast-flood (yes | no; Default: yes) | When enabled, bridge floods broadcast traffic to all bridge egress ports. When disabled, drops broadcast traffic on egress ports. Can be used to filter all broadcast traffic on an egress port. Broadcast traffic is considered as traffic that uses FF:FF:FF:FF:FF:FF as destination MAC address, such traffic is crucial for many protocols such as DHCP, ARP, NDP, BOOTP (Netinstall), and others. This option does not limit traffic flood to the CPU. |
edge (auto | no | no-discover | yes | yes-discover; Default: auto) | Set port as edge port or non-edge port, or enable edge discovery. Edge ports are connected to a LAN that has no other bridges attached. An edge port will skip the learning and the listening states in STP and will transition directly to the forwarding state, this reduces the STP initialization time. If the port is configured to discover edge port then as soon as the bridge detects a BPDU coming to an edge port, the port becomes a non-edge port. This property has no effect when protocol-mode is set to none .
|
fast-leave (yes | no; Default: no) | Enables IGMP/MLD fast leave feature on the bridge port. The bridge will stop forwarding multicast traffic to a bridge port when an IGMP/MLD leave message is received. This property only has an effect when igmp-snooping is set to yes . |
frame-types (admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged; Default: admit-all) | Specifies allowed ingress frame types on a bridge port. This property only has an effect when vlan-filtering is set to yes . |
ingress-filtering (yes | no; Default: yes) | Enables or disables VLAN ingress filtering, which checks if the ingress port is a member of the received VLAN ID in the bridge VLAN table. Should be used with frame-types to specify if the ingress traffic should be tagged or untagged. This property only has effect when vlan-filtering is set to yes . The setting is enabled by default since RouterOS v7. |
learn (auto | no | yes; Default: auto) | Changes MAC learning behavior on a bridge port
|
multicast-router (disabled | permanent | temporary-query; Default: temporary-query) | A multicast router port is a port where a multicast router or querier is connected. On this port, unregistered multicast streams and IGMP/MLD membership reports will be sent. This setting changes the state of the multicast router for bridge ports. This property can be used to send IGMP/MLD membership reports to certain bridge ports for further multicast routing or proxying. This property only has an effect when igmp-snooping is set to yes .
|
horizon (integer 0..429496729; Default: none) | Use split horizon bridging to prevent bridging loops. Set the same value for a group of ports, to prevent them from sending data to ports with the same horizon value. Split horizon is a software feature that disables hardware offloading. Read more about Bridge split horizon. |
hw (yes | no; Default: yes) | Allows to enable or disable hardware offloading on interfaces capable of HW offloading. For software interfaces like EoIP or VLAN this setting is ignored and has no effect. Certain bridge or port functions can automatically disable HW offloading, use the print command to see whether the "H" flag is active. |
internal-path-cost (integer: 1..200000000; Default: ) | Path cost to the interface for MSTI0 inside a region. If not manually configured, the bridge automatically determines the internal-path-cost based on the interface speed and the /interface bridge port set [find interface=sfp28-1] !internal-path-cost Use port monitor to observe the applied internal-path-cost. |
interface (name; Default: none) | Name of the interface. |
path-cost (integer: 1..200000000; Default: ) | Path cost to the interface, used by STP and RSTP to determine the best path, and used by MSTP to determine the best path between regions. If not manually configured, the bridge automatically determines the path-cost based on the interface speed and the /interface bridge port set [find interface=sfp28-1] !path-cost Use port monitor to observe the applied path-cost. |
point-to-point (auto | yes | no; Default: auto) | Specifies if a bridge port is connected to a bridge using a point-to-point link for faster convergence in case of failure. By setting this property to yes , you are forcing the link to be a point-to-point link, which will skip the checking mechanism, which detects and waits for BPDUs from other devices from this single link. By setting this property to no , you are expecting that a link can receive BPDUs from multiple devices. By setting the property to yes , you are significantly improving (R/M)STP convergence time. In general, you should only set this property to no if it is possible that another device can be connected between a link, this is mostly relevant to Wireless mediums and Ethernet hubs. If the Ethernet link is full-duplex, auto enables point-to-point functionality. This property has no effect when protocol-mode is set to none . |
priority (integer: 0..240; Default: 128) | The priority of the interface, used by STP to determine the root port, used by MSTP to determine root port between regions. |
pvid (integer 1..4094; Default: 1) | Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. This property only has an effect when vlan-filtering is set to yes . |
restricted-role (yes | no; Default: no) | Enables or disables the restricted role on a port. When enabled, it prevents the port from becoming the root port for the CIST or any MSTI, regardless of its best spanning tree priority vector. Such a port will be selected as an Alternate Port (discarding state) and remains so as long as it continues to receive superior BPDUs. It will automatically transition to the forwarding state when it no longer detects a superior root path. Network administrators may enable this setting to safeguard against external bridges influencing the active spanning tree, a feature also known as root-guard or root-protection. This property has an effect when protocol-mode is set to stp , rstp , or mstp (support for STP and RSTP is available since RouterOS v7.14). |
restricted-tcn (yes | no; Default: no) | Enables or disables topology change notification (TCN) handling on a port. When enabled, it causes the port not to propagate received topology change notifications to other ports, and any changes caused by the port itself does not result in topology change notification to other ports. This parameter is disabled by default. It can be set by a network administrator to prevent external bridges causing MAC address flushing in local network. This property has an effect when protocol-mode is set to stp , rstp , or mstp (support for STP and RSTP is available since RouterOS v7.14). |
tag-stacking (yes | no; Default: no) | Forces all packets to be treated as untagged packets. Packets on ingress port will be tagged with another VLAN tag regardless if a VLAN tag already exists, packets will be tagged with a VLAN ID that matches the pvid value and will use EtherType that is specified in ether-type . This property only has effect when vlan-filtering is set to yes . |
trusted (yes | no; Default: no) | When enabled, it allows forwarding DHCP packets towards the DHCP server through this port. Mainly used to limit unauthorized servers to provide malicious information for users. This property only has an effect when dhcp-snooping is set to yes . |
unknown-multicast-flood (yes | no; Default: yes) | Changes the multicast flood option on bridge port, only controls the egress traffic. When enabled, the bridge allows flooding multicast packets to the specified bridge port, but when disabled, the bridge restricts multicast traffic from being flooded to the specified bridge port. The setting affects all multicast traffic, this includes non-IP, IPv4, IPv6 and the link-local multicast ranges (e.g. 224.0.0.0/24 and ff02::1). Note that when When using this setting together with |
unknown-unicast-flood (yes | no; Default: yes) | Changes the unknown unicast flood option on bridge port, only controls the egress traffic. When enabled, the bridge allows flooding unknown unicast packets to the specified bridge port, but when disabled, the bridge restricts unknown unicast traffic from being flooded to the specified bridge port. If a MAC address is not learned in the host table, then the traffic is considered as unknown unicast traffic and will be flooded to all ports. MAC address is learned as soon as a packet on a bridge port is received and the source MAC address is added to the bridge host table. Since it is required for the bridge to receive at least one packet on the bridge port to learn the MAC address, it is recommended to use static bridge host entries to avoid packets being dropped until the MAC address has been learned. |
RouterOS can handle a maximum of 1024 bridged interfaces, this limit is fixed and cannot be modified. If you try to add more interfaces as bridge ports, it may lead to unpredictable behavior.
Example
To group ether1 and ether2 in the already created bridge1 interface.
[admin@MikroTik] /interface bridge port add bridge=bridge1 interface=ether1 [admin@MikroTik] /interface bridge port add bridge=bridge1 interface=ether2 [admin@MikroTik] /interface bridge port print Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON 0 ether1 bridge1 yes 100 0x80 10 10 none 1 ether2 bridge1 yes 200 0x80 10 10 none
Interface lists
Starting with RouterOS v6.41 it possible to add interface lists as a bridge port and sort them. Interface lists are useful for creating simpler firewall rules. Below is an example how to add an interface list to a bridge:
/interface list add name=LAN1 add name=LAN2 /interface list member add interface=ether1 list=LAN1 add interface=ether2 list=LAN1 add interface=ether3 list=LAN2 add interface=ether4 list=LAN2 /interface bridge port add bridge=bridge1 interface=LAN1 add bridge=bridge1 interface=LAN2
Ports from an interface list added to a bridge will show up as dynamic ports:
[admin@MikroTik] /interface bridge port> pr Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON 0 LAN1 bridge1 yes 1 0x80 10 10 none 1 D ether1 bridge1 yes 1 0x80 10 10 none 2 D ether2 bridge1 yes 1 0x80 10 10 none 3 LAN2 bridge1 yes 1 0x80 10 10 none 4 D ether3 bridge1 yes 1 0x80 10 10 none 5 D ether4 bridge1 yes 1 0x80 10 10 none
It is also possible to sort the order of lists in which they appear. This can be done using the move
command. Below is an example of how to sort interface lists:
[admin@MikroTik] > /interface bridge port move 3 0 [admin@MikroTik] > /interface bridge port print Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON 0 LAN2 bridge1 yes 1 0x80 10 10 none 1 D ether3 bridge1 yes 1 0x80 10 10 none 2 D ether4 bridge1 yes 1 0x80 10 10 none 3 LAN1 bridge1 yes 1 0x80 10 10 none 4 D ether1 bridge1 yes 1 0x80 10 10 none 5 D ether2 bridge1 yes 1 0x80 10 10 none
The second parameter when moving interface lists is considered as "before id", the second parameter specifies before which interface list should be the selected interface list moved. When moving the first interface list in place of the second interface list, then the command will have no effect since the first list will be moved before the second list, which is the current state either way.
Bridge Port Monitoring
To monitor the current status of bridge ports, use the monitor
command.
Sub-menu: /interface bridge port monitor
Property | Description |
---|---|
designated-bridge (bridge identifier) | Shows the received bridge identifier. |
designated-cost (integer) | Shows the received root-path-cost. |
designated-port-number (integer) | Shows the received port number. |
edge-port (yes | no) | Whether the port is an edge port or not. |
edge-port-discovery (yes | no) | Whether the port is set to automatically detect edge ports. |
external-fdb (yes | no) | Whether the registration table is used instead of a forwarding database. |
forwarding (yes | no) | Shows if the port is not blocked by (R/M)STP. |
hw-offload-group (switchX) | Switch chip used by the port. |
interface (name) | Interface name. |
learning (yes | no) | Shows whether the port is capable of learning MAC addresses. |
multicast-router (yes | no) | Shows if a multicast router is detected on the port. Monitoring value appears only when igmp-snooping is enabled. |
path-cost (integer: 1..200000000) | Shows the actual port path-cost. Either manually applied or automatically determined based on the interface speed and the port-cost-mode setting. |
port-number (integer 1..4095) | A port-number will be assigned in the order that ports got added to the bridge, but this is only true until reboot. After reboot, the internal port numbering will be used. |
point-to-point-port (yes | no) | Whether the port is connected to a bridge port using full-duplex (yes) or half-duplex (no). |
role (designated | root port | alternate | backup | disabled) | (R/M)STP algorithm assigned the role of the port:
|
root-path-cost (integer) | The total cost of the path to the root-bridge |
sending-rstp (yes | no) | Whether the port is using RSTP or MSTP BPDU types. A port will transit to STP type when RSTP/MSTP enabled port receives an STP BPDU. This settings does not indicate whether the BDPUs are actually sent. |
status (in-bridge | inactive) | Port status:
|
[admin@MikroTik] /interface bridge port monitor [find interface=sfp-sfpplus2] interface: sfp-sfpplus2 status: in-bridge port-number: 1 role: root-port edge-port: no edge-port-discovery: yes point-to-point-port: yes external-fdb: no sending-rstp: yes learning: yes forwarding: yes path-cost: 2000 root-path-cost: 4000 designated-bridge: 0x8000.DC:2C:6E:9E:11:1C designated-cost: 2000 designated-port-number: 2
Hosts Table
MAC addresses that have been learned on a bridge interface can be viewed in the host menu. Below is a table of parameters and flags that can be viewed.
Sub-menu: /interface bridge host
Property | Description |
---|---|
bridge (read-only: name) | The bridge the entry belongs to |
disabled (read-only: flag) | Whether the static host entry is disabled |
dynamic (read-only: flag) | Whether the host has been dynamically created |
external (read-only: flag) | Whether the host has been learned using an external table, for example, from a switch chip or Wireless registration table. Adding a static host entry on a hardware-offloaded bridge port will also display an active external flag |
invalid (read-only: flag) | Whether the host entry is invalid, can appear for statically configured hosts on already removed interface |
local (read-only: flag) | Whether the host entry is created from the bridge itself (that way all local interfaces are shown) |
mac-address (read-only: MAC address) | Host's MAC address |
on-interface (read-only: name) | Which of the bridged interfaces the host is connected to |
Monitoring
To get the active hosts table:
[admin@MikroTik] /interface bridge host print Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external # MAC-ADDRESS VID ON-INTERFACE BRIDGE 0 D B8:69:F4:C9:EE:D7 ether1 bridge1 1 D B8:69:F4:C9:EE:D8 ether2 bridge1 2 DL CC:2D:E0:E4:B3:38 bridge1 bridge1 3 DL CC:2D:E0:E4:B3:39 ether2 bridge1
Static entries
It is possible to add a static MAC address entry into the host table. This can be used to forward a certain type of traffic through a specific port. Another use case for static host entries is to protect the device resources by disabling dynamic learning and relying only on configured static host entries. Below is a table of possible parameters that can be set when adding a static MAC address entry into the host table.
Sub-menu: /interface bridge host
Property | Description |
---|---|
bridge (name; Default: none) | The bridge interface to which the MAC address is going to be assigned. |
disabled (yes | no; Default: no) | Disables/enables static MAC address entry. |
interface (name; Default: none) | Name of the interface. |
mac-address (MAC address; Default: ) | MAC address that will be added to the host table statically. |
vid (integer: 1..4094; Default: ) | VLAN ID for the statically added MAC address entry. |
For example, if it was required that all traffic destined to 4C:5E:0C:4D:12:43 is forwarded only through ether2, then the following commands can be used:
/interface bridge host add bridge=bridge interface=ether2 mac-address=4C:5E:0C:4D:12:43
Multicast Table
When IGMP/MLD snooping is enabled, the bridge will start to listen to IGMP/MLD communication, create multicast database (MDB) entries, and make forwarding decisions based on the received information. Packets with link-local multicast destination addresses 224.0.0.0/24 and ff02::1 are not restricted and are always flooded on all ports and VLANs. To see learned multicast database entries, use the print
command.
Sub-menu: /interface bridge mdb
Property | Description |
---|---|
bridge (read-only: name) | Shows the bridge interface the entry belongs to. |
group (read-only: ipv4 | ipv6 address) | Shows a multicast group address. |
on-ports (read-only: name) | Shows the bridge ports which are subscribed to the certain multicast group. |
vid (read-only: integer) | Shows the VLAN ID for the multicast group, only applies when vlan-filtering is enabled. |
[admin@MikroTik] /interface bridge mdb print Flags: D - DYNAMIC Columns: GROUP, VID, ON-PORTS, BRIDGE # GROUP VID ON-PORTS BRIDGE 0 D ff02::2 1 bridge1 bridge1 1 D ff02::6a 1 bridge1 bridge1 2 D ff02::1:ff00:0 1 bridge1 bridge1 3 D ff02::1:ff01:6a43 1 bridge1 bridge1 4 D 229.1.1.1 10 ether2 bridge1 5 D 229.2.2.2 10 ether3 bridge1 ether2 6 D ff02::2 10 ether5 bridge1 ether3 ether2 ether4
Static entries
Since RouterOS version 7.7, it is possible to create static MDB entries for IPv4 and IPv6 multicast groups.
Sub-menu: /interface bridge mdb
Property | Description |
---|---|
bridge (name; Default: ) | The bridge interface to which the MDB entry is going to be assigned. |
disabled (yes | no; Default: no) | Disables or enables static MDB entry. |
group (ipv4 | ipv6 address; Default: ) | The IPv4 or IPv6 multicast address. Static entries for link-local multicast groups 224.0.0.0/24 and ff02::1 cannot be created, as these packets are always flooded on all ports and VLANs. |
ports (name; Default: ) | The list of bridge ports to which the multicast group will be forwarded. |
vid (integer: 1..4094; Default: ) | The VLAN ID on which the MDB entry will be created, only applies when vlan-filtering is enabled. When VLAN ID is not specified, the entry will work in shared-VLAN mode and dynamically apply on all defined VLAN IDs for particular ports. |
For example, to create a static MDB entry for multicast group 229.10.10.10 on ports ether2 and ether3 on VLAN 10, use the command below:
/interface bridge mdb add bridge=bridge1 group=229.10.10.10 ports=ether2,ether3 vid=10
Verify the results with the print
command:
[admin@MikroTik] > /interface bridge mdb print where group=229.10.10.10 Columns: GROUP, VID, ON-PORTS, BRIDGE # GROUP VID ON-PORTS BRIDGE 12 229.10.10.10 10 ether2 bridge1 ether3
In case a certain IPv6 multicast group does not need to be snooped and it is desired to be flooded on all ports and VLANs, it is possible to create a static MDB entry on all VLANs and ports, including the bridge interface itself. Use the command below to create a static MDB entry for multicast group ff02::2 on all VLANs and ports (modify the ports
setting for your particular setup):
/interface bridge mdb add bridge=bridge1 group=ff02::2 ports=bridge1,ether2,ether3,ether4,ether5 [admin@MikroTik] > /interface bridge mdb print where group=ff02::2 Flags: D - DYNAMIC Columns: GROUP, VID, ON-PORTS, BRIDGE # GROUP VID ON-PORTS BRIDGE 0 ff02::2 bridge1 15 D ff02::2 1 bridge1 bridge1 16 D ff02::2 10 bridge1 bridge1 ether2 ether3 ether4 ether5 17 D ff02::2 20 bridge1 bridge1 ether2 ether3 18 D ff02::2 30 bridge1 bridge1 ether2 ether3
Bridge Hardware Offloading
It is possible to switch multiple ports together if a device has a built-in switch chip. While a bridge is a software feature that will consume CPU's resources, the bridge hardware offloading feature will allow you to use the built-in switch chip to forward packets. This allows you to achieve higher throughput if configured correctly.
In previous versions (prior to RouterOS v6.41) you had to use the master-port property to switch multiple ports together, but in RouterOS v6.41 this property is replaced with the bridge hardware offloading feature, which allows your to switch ports and use some of the bridge features, for example, Spanning Tree Protocol.
When upgrading from previous versions (before RouterOS v6.41), the old master-port configuration is automatically converted to the new Bridge Hardware Offloading configuration. When downgrading from newer versions (RouterOS v6.41 and newer) to older versions (before RouterOS v6.41) the configuration is not converted back, a bridge without hardware offloading will exist instead, in such a case you need to reconfigure your device to use the old master-port configuration.
Below is a list of devices and feature that supports hardware offloading (+) or disables hardware offloading (-):
RouterBoard/[Switch Chip] Model | Features in Switch menu | Bridge STP/RSTP | Bridge MSTP | Bridge IGMP Snooping | Bridge DHCP Snooping | Bridge VLAN Filtering | Bonding 4, 5 | Horizon 4 |
CRS3xx, CRS5xx series | + | + | + | + | + | + | + | - |
CCR2116, CCR2216 | + | + | + | + | + | + | + | - |
CRS1xx/CRS2xx series | + | + | - | + 2 | + 1 | - | - | - |
[QCA8337] | + | + | - | - | + 2 | - | - | - |
[Atheros8327] | + | + | - | - | + 2 | - | - | - |
[Atheros8316] | + | + | - | - | + 2 | - | - | - |
[Atheros8227] | + | + | - | - | - | - | - | - |
[Atheros7240] | + | + | - | - | - | - | - | - |
[IPQ-PPE] | +6 | - | - | - | - | - | - | - |
[ICPlus175D] | + | - | - | - | - | - | - | - |
[MT7621, MT7531] | + | + 3 | + 3 | - | - | + 3 | - | - |
[RTL8367] | + | + 3 | + 3 | - | - | + 3 | - | - |
[88E6393X, 88E6191X, 88E6190] | + | + | + | + | + | + 3 | + 7 | - |
Footnotes:
- The feature will not work properly in VLAN switching setups. It is possible to correctly snoop DHCP packets only for a single VLAN, but this requires that these DHCP messages get tagged with the correct VLAN tag using an ACL rule, for example,
/interface ethernet switch acl add dst-l3-port=67-68 ip-protocol=udp mac-protocol=ip new-customer-vid=10 src-ports=switch1-cpu
. DHCP Option 82 will not contain any information regarding VLAN-ID. - The feature will not work properly in VLAN switching setups.
- The HW vlan-filtering and R/M/STP was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.
- The HW offloading will be disabled only for the specific bridge port, not the entire bridge.
- Only
802.3ad
andbalance-xor
modes can be HW offloaded. Other bonding modes do not support HW offloading. - Currently, HW offloaded bridge support for the IPQ-PPE switch chip is still a work in progress. We recommend using, the default, non-HW offloaded bridge (enabled RSTP).
- The
802.3ad
mode is compatible only with R/M/STP enabled bridge.
When upgrading from older versions (before RouterOS v6.41), only the master-port configuration is converted. For each master-port a bridge will be created. VLAN configuration is not converted and should not be changed, check the Basic VLAN switching guide to be sure how VLAN switching should be configured for your device.
Bridge Hardware Offloading should be considered as port switching, but with more possible features. By enabling hardware offloading you are allowing a built-in switch chip to process packets using its switching logic. The diagram below illustrates that switching occurs before any software related action.
A packet that is received by one of the ports always passes through the switch logic first. Switch logic decides which ports the packet should be going to (most commonly this decision is made based on the destination MAC address of a packet, but there might be other criteria that might be involved based on the packet and the configuration). In most cases the packet will not be visible to RouterOS (only statistics will show that a packet has passed through), this is because the packet was already processed by the switch chip and never reached the CPU.
Though it is possible in certain situations to allow a packet to be processed by the CPU, this is usually called a packet forwarding to the switch CPU port (or the bridge interface in bridge VLAN filtering scenario). This allows the CPU to process the packet and lets the CPU to forward the packet. Passing the packet to the CPU port will give you the opportunity to route packets to different networks, perform traffic control and other software related packet processing actions. To allow a packet to be processed by the CPU, you need to make certain configuration changes depending on your needs and on the device you are using (most commonly passing packets to the CPU are required for VLAN filtering setups). Check the manual page for your specific device:
- CRS1xx/2xx series switches
- CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers
- non-CRS series switches
Certain bridge and Ethernet port properties are directly related to switch chip settings. Changing such properties can trigger a switch chip reset, temporarily disabling all Ethernet ports that are on the switch chip for the settings to take effect. This must be taken into account whenever changing properties in production environments. Such properties include DHCP Snooping, IGMP Snooping, VLAN filtering, L2MTU, Flow Control, and others. The exact settings that can trigger a switch chip reset depend on the device's model.
The CRS1xx/2xx series switches support multiple hardware offloaded bridges per switch chip. All other devices support only one hardware offloaded bridge per switch chip. Use the hw=yes/no parameter to select which bridge will use hardware offloading.
Example
Port switching with bridge configuration and enabled hardware offloading:
/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
Make sure that hardware offloading is enabled and active by checking the "H" flag:
[admin@MikroTik] /interface bridge port print Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW PVID PRIORITY PATH-COST INTERNAL-PATH-COST HORIZON 0 H ether2 bridge1 yes 1 0x80 10 10 none 1 H ether3 bridge1 yes 1 0x80 10 10 none 2 H ether4 bridge1 yes 1 0x80 10 10 none 3 H ether5 bridge1 yes 1 0x80 10 10 none
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.
Bridge VLAN Filtering
Bridge VLAN Filtering provides VLAN-aware Layer 2 forwarding and VLAN tag modifications within the bridge. This set of features makes bridge operation more similar to a traditional Ethernet switch and allows overcoming Spanning Tree compatibility issues compared to the configuration when VLAN interfaces are bridged. Bridge VLAN Filtering configuration is highly recommended to comply with STP (IEEE 802.1D), RSTP (IEEE 802.1W) standards and is mandatory to enable MSTP (IEEE 802.1s) support in RouterOS.
The main VLAN setting is vlan-filtering
which globally controls VLAN-awareness and VLAN tag processing in the bridge. If vlan-filtering=no
is configured, the bridge ignores VLAN tags, works in a shared-VLAN-learning (SVL) mode, and cannot modify VLAN tags of packets. Turning on vlan-filtering
enables all bridge VLAN related functionality and independent-VLAN-learning (IVL) mode. Besides joining the ports for Layer2 forwarding, the bridge itself is also an interface therefore it has Port VLAN ID (pvid).
Currently, CRS3xx, CRS5xx series switches, CCR2116, CCR2216 routers and RTL8367, 88E6393X, 88E6191X, 88E6190, MT7621 and MT7531 switch chips (since RouterOS v7) are capable of using bridge VLAN filtering and hardware offloading at the same time, other devices will not be able to use the benefits of a built-in switch chip when bridge VLAN filtering is enabled. Other devices should be configured according to the method described in the Basic VLAN switching guide. If an improper configuration method is used, your device can cause throughput issues in your network.
Bridge VLAN table
Bridge VLAN table represents per-VLAN port mapping with an egress VLAN tag action. The tagged
ports send out frames with a corresponding VLAN ID tag. The untagged
ports remove a VLAN tag before sending out frames. Bridge ports with frame-types
set to admit-all
or admit-only-untagged-and-priority-tagged
will be automatically added as untagged ports for the pvid
VLAN.
Sub-menu: /interface bridge vlan
Property | Description |
---|---|
bridge (name; Default: none) | The bridge interface which the respective VLAN entry is intended for. |
disabled (yes | no; Default: no) | Enables or disables Bridge VLAN entry. |
tagged (interfaces; Default: none) | Interface list with a VLAN tag adding action in egress. This setting accepts comma-separated values. e.g. tagged=ether1,ether2 . |
untagged (interfaces; Default: none) | Interface list with a VLAN tag removing action in egress. This setting accepts comma-separated values. e.g. untagged=ether3,ether4 |
vlan-ids (integer 1..4094; Default: 1) | The list of VLAN IDs for certain port configuration. This setting accepts the VLAN ID range as well as comma-separated values. e.g. vlan-ids=100-115,120,122,128-130 . |
The vlan-ids
parameter can be used to specify a set or range of VLANs, but specifying multiple VLANs in a single bridge VLAN table entry should only be used for ports that are tagged ports. In case multiple VLANs are specified for access ports, then tagged packets might get sent out as untagged packets through the wrong access port, regardless of the PVID value.
Make sure you have added all needed interfaces to the bridge VLAN table when using bridge VLAN filtering. For routing functions to work properly on the same device through ports that use bridge VLAN filtering, you will need to allow access to the bridge interface (this automatically include a switch-cpu port when HW offloaded vlan-filtering is used, e.g. on CRS3xx series switches), this can be done by adding the bridge interface itself to the VLAN table, for tagged traffic you will need to add the bridge interface as a tagged port and create a VLAN interface on the bridge interface. Examples can be found in the inter-VLAN routing and Management port sections.
When allowing access to the CPU, you are allowing access from a certain port to the actual router/switch, this is not always desirable. Make sure you implement proper firewall filter rules to secure your device when access to the CPU is allowed from a certain VLAN ID and port, use firewall filter rules to allow access to only certain services.
Improperly configured bridge VLAN filtering can cause security issues, make sure you fully understand how Bridge VLAN table works before deploying your device into production environments.
Bridge port settings
Each bridge port have multiple VLAN related settings, that can change untagged VLAN membership, VLAN tagging/untagging behavior and packet filtering based on VLAN tag presence.
Sub-menu: /interface bridge port
Property | Description |
---|---|
frame-types (admit-all | admit-only-untagged-and-priority-tagged | admit-only-vlan-tagged; Default: admit-all) | Specifies allowed ingress frame types on a bridge port. This property only has an effect when vlan-filtering is set to yes . |
ingress-filtering (yes | no; Default: yes) | Enables or disables VLAN ingress filtering, which checks if the ingress port is a member of the received VLAN ID in the bridge VLAN table. Should be used with frame-types to specify if the ingress traffic should be tagged or untagged. This property only has effect when vlan-filtering is set to yes . The setting is enabled by default since RouterOS v7. |
pvid (integer 1..4094; Default: 1) | Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. This property only has an effect when vlan-filtering is set to yes . |
tag-stacking (yes | no; Default: no) | Forces all packets to be treated as untagged packets. Packets on ingress port will be tagged with another VLAN tag regardless if a VLAN tag already exists, packets will be tagged with a VLAN ID that matches the pvid value and will use EtherType that is specified in ether-type . This property only has effect when vlan-filtering is set to yes . |
Bridge host table
Bridge host table allows monitoring learned MAC addresses. When vlan-filtering
is enabled, it shows learned VLAN ID as well (enabled independent-VLAN-learning or IVL).
[admin@MikroTik] > /interface bridge host print where !local Flags: X - disabled, I - invalid, D - dynamic, L - local, E - external # MAC-ADDRESS VID ON-INTERFACE BRIDGE 0 D CC:2D:E0:E4:B3:AA 300 ether3 bridge1 1 D CC:2D:E0:E4:B3:AB 400 ether4 bridge1
VLAN Example - Trunk and Access Ports
Create a bridge with disabled vlan-filtering
to avoid losing access to the device before VLANs are completely configured. If you need a management access to the bridge, see the Management access configuration section.
/interface bridge add name=bridge1 vlan-filtering=no
Add bridge ports and specify pvid
for access ports to assign their untagged traffic to the intended VLAN. Use frame-types
setting to accept only tagged or untagged packets.
/interface bridge port add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged add bridge=bridge1 interface=ether6 pvid=200 frame-types=admit-only-untagged-and-priority-tagged add bridge=bridge1 interface=ether7 pvid=300 frame-types=admit-only-untagged-and-priority-tagged add bridge=bridge1 interface=ether8 pvid=400 frame-types=admit-only-untagged-and-priority-tagged
Add Bridge VLAN entries and specify tagged ports in them. Bridge ports with frame-types
set to admit-only-untagged-and-priority-tagged
will be automatically added as untagged ports for the pvid
VLAN.
/interface bridge vlan add bridge=bridge1 tagged=ether2 vlan-ids=200 add bridge=bridge1 tagged=ether2 vlan-ids=300 add bridge=bridge1 tagged=ether2 vlan-ids=400
In the end, when VLAN configuration is complete, enable Bridge VLAN Filtering.
/interface bridge set bridge1 vlan-filtering=yes
Optional step is to set frame-types=admit-only-vlan-tagged
on the bridge interface in order to disable the default untagged VLAN 1 (pvid=1
).
/interface bridge set bridge1 frame-types=admit-only-vlan-tagged
VLAN Example - Trunk and Hybrid Ports
Create a bridge with disabled vlan-filtering
to avoid losing access to the router before VLANs are completely configured. If you need a management access to the bridge, see the Management access configuration section.
/interface bridge add name=bridge1 vlan-filtering=no
Add bridge ports and specify pvid
on hybrid VLAN ports to assign untagged traffic to the intended VLAN. Use frame-types
setting to accept only tagged packets on ether2.
/interface bridge port add bridge=bridge1 interface=ether2 frame-types=admit-only-vlan-tagged add bridge=bridge1 interface=ether6 pvid=200 add bridge=bridge1 interface=ether7 pvid=300 add bridge=bridge1 interface=ether8 pvid=400
Add Bridge VLAN entries and specify tagged ports in them. In this example egress VLAN tagging is done on ether6,ether7,ether8 ports too, making them into hybrid ports. Bridge ports with frame-types
set to admit-all
will be automatically added as untagged ports for the pvid
VLAN.
/interface bridge vlan add bridge=bridge1 tagged=ether2,ether7,ether8 vlan-ids=200 add bridge=bridge1 tagged=ether2,ether6,ether8 vlan-ids=300 add bridge=bridge1 tagged=ether2,ether6,ether7 vlan-ids=400
In the end, when VLAN configuration is complete, enable Bridge VLAN Filtering.
/interface bridge set bridge1 vlan-filtering=yes
Optional step is to set frame-types=admit-only-vlan-tagged
on the bridge interface in order to disable the default untagged VLAN 1 (pvid=1
).
/interface bridge set bridge1 frame-types=admit-only-vlan-tagged
You don't have to add access ports as untagged ports, because they will be added dynamically as an untagged port with the VLAN ID that is specified in pvid
, you can specify just the trunk port as a tagged port. All ports that have the same pvid
set will be added as untagged ports in a single entry. You must take into account that the bridge itself is a port and it also has a pvid
value, this means that the bridge port also will be added as an untagged port for the ports that have the same pvid
. You can circumvent this behavior by either setting different pvid
on all ports (even the trunk port and bridge itself), or to use frame-type
set to accept-only-vlan-tagged
.
VLAN Example - InterVLAN Routing by Bridge
Create a bridge with disabled vlan-filtering
to avoid losing access to the router before VLANs are completely configured. If you need a management access to the bridge, see the Management access configuration section.
/interface bridge add name=bridge1 vlan-filtering=no
Add bridge ports and specify pvid
for VLAN access ports to assign their untagged traffic to the intended VLAN. Use frame-types
setting to accept only untagged packets.
/interface bridge port add bridge=bridge1 interface=ether6 pvid=200 frame-types=admit-only-untagged-and-priority-tagged add bridge=bridge1 interface=ether7 pvid=300 frame-types=admit-only-untagged-and-priority-tagged add bridge=bridge1 interface=ether8 pvid=400 frame-types=admit-only-untagged-and-priority-tagged
Add Bridge VLAN entries and specify tagged ports in them. In this example bridge1 interface is the VLAN trunk that will send traffic further to do InterVLAN routing. Bridge ports with frame-types
set to admit-only-untagged-and-priority-tagged
will be automatically added as untagged ports for the pvid
VLAN.
/interface bridge vlan add bridge=bridge1 tagged=bridge1 vlan-ids=200 add bridge=bridge1 tagged=bridge1 vlan-ids=300 add bridge=bridge1 tagged=bridge1 vlan-ids=400
Configure VLAN interfaces on the bridge1 to allow handling of tagged VLAN traffic at routing level and set IP addresses to ensure routing between VLANs as planned.
/interface vlan add interface=bridge1 name=VLAN200 vlan-id=200 add interface=bridge1 name=VLAN300 vlan-id=300 add interface=bridge1 name=VLAN400 vlan-id=400 /ip address add address=20.0.0.1/24 interface=VLAN200 add address=30.0.0.1/24 interface=VLAN300 add address=40.0.0.1/24 interface=VLAN400
In the end, when VLAN configuration is complete, enable Bridge VLAN Filtering:
/interface bridge set bridge1 vlan-filtering=yes
Optional step is to set frame-types=admit-only-vlan-tagged
on the bridge interface in order to disable the default untagged VLAN 1 (pvid=1
).
/interface bridge set bridge1 frame-types=admit-only-vlan-tagged
Since RouterOS v7, it is possible to route traffic using the L3 HW offloading on certain devices. See more details on L3 Hardware Offloading.
Management access configuration
There are multiple ways to set up management access on a device that uses bridge VLAN filtering. Below are some of the most popular approaches to properly enable access to a router/switch. Start by creating a bridge without VLAN filtering enabled:
/interface bridge add name=bridge1 vlan-filtering=no
Untagged access without VLAN filtering
In case VLAN filtering will not be used and access with untagged traffic is desired, the only requirement is to create an IP address on the bridge interface.
/ip address add address=192.168.99.1/24 interface=bridge1
Tagged access without VLAN filtering
In case VLAN filtering will not be used and access with tagged traffic is desired, create a routable VLAN interface on the bridge and add an IP address on the VLAN interface.
/interface vlan add interface=bridge1 name=MGMT vlan-id=99 /ip address add address=192.168.99.1/24 interface=MGMT
Tagged access with VLAN filtering
In case VLAN filtering is used and access with tagged traffic is desired, additional steps are required. In this example, VLAN 99 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
For example, if you want to allow access to the device from ports ether3, ether4, sfp-sfpplus1 using tagged VLAN 99 traffic, then you must add this entry to the VLAN table. Note that the bridge1 interface is also included in the tagged port list:
/interface bridge vlan add bridge=bridge1 tagged=bridge1,ether3,ether4,sfp-sfpplus1 vlan-ids=99
After that you can enable VLAN filtering:
/interface bridge set bridge1 vlan-filtering=yes
Untagged access with VLAN filtering
In case VLAN filtering is used and access with untagged traffic is desired, the VLAN interface must use the same VLAN ID as the untagged port VLAN ID (pvid
). Just like in the previous example, start by creating a VLAN interface on the bridge and add an IP address for the VLAN.
/interface vlan add interface=bridge1 name=MGMT vlan-id=99 /ip address add address=192.168.99.1/24 interface=MGMT
For example, untagged ports ether2 and ether3 should be able to communicate with the VLAN 99 interface using untagged traffic. In order to achieve this, these ports should be configured with the pvid
that matches the VLAN ID on management VLAN. Note that the bridge1 interface is a tagged port member, you can configure additional tagged ports if necessary (see the previous example).
/interface bridge port set [find interface=ether2] pvid=99 set [find interface=ether3] pvid=99 /interface bridge vlan add bridge=bridge1 tagged=bridge1 untagged=ether2,ether3 vlan-ids=99
After that you can enable VLAN filtering:
/interface bridge set bridge1 vlan-filtering=yes
Changing untagged VLAN for the bridge interface
In case VLAN filtering is used, it is possible to change the untagged VLAN ID for the bridge interface using the pvid
setting. Note that creating routable VLAN interfaces and allowing tagged traffic on the bridge is a more flexible and generally recommended option.
First, create an IP address on the bridge interface.
/ip address add address=192.168.99.1/24 interface=bridge1
For example, untagged bridge1 traffic should be able to communicate with untagged ether2 and ether3 ports and tagged sfp-sfpplus1 port in VLAN 99. In order to achieve this, bridge1, ether2, ether3 should be configured with the same pvid
and sfp-sfpplus1 added as a tagged member.
/interface bridge set [find name=bridge1] pvid=99 /interface bridge port set [find interface=ether2] pvid=99 set [find interface=ether3] pvid=99 /interface bridge vlan add bridge=bridge1 tagged=sfp-sfpplus1 untagged=bridge1,ether2,ether3 vlan-ids=99
After that you can enable VLAN filtering:
/interface bridge set bridge1 vlan-filtering=yes
If the connection to the router/switch through an IP address is not required, then steps adding an IP address can be skipped since a connection to the router/switch through Layer2 protocols (e.g. MAC-telnet) will be working either way.
VLAN Tunneling (QinQ)
Since RouterOS v6.43 the RouterOS bridge is IEEE 802.1ad compliant and it is possible to filter VLAN IDs based on Service VLAN ID (0x88a8) rather than Customer VLAN ID (0x8100). The same principles can be applied as with IEEE 802.1Q VLAN filtering (the same setup examples can be used). Below is a topology for a common Provider bridge:
In this example, R1, R2, R3, and R4 might be sending any VLAN tagged traffic by 802.1Q (CVID), but SW1 and SW2 needs isolate traffic between routers in a way that R1 is able to communicate only with R3, and R2 is only able to communicate with R4. To do so, you can tag all ingress traffic with an SVID and only allow these VLANs on certain ports. Start by enabling the service tag 0x88a8, introduced by 802.1ad
, on the bridge. Use these commands on SW1 and SW2:
/interface bridge add name=bridge1 vlan-filtering=no ether-type=0x88a8
In this setup, ether1 and ether2 are going to be access ports (untagged), use the pvid
parameter to tag all ingress traffic on each port, use these commands on SW1 and SW2:
/interface bridge port add interface=ether1 bridge=bridge1 pvid=200 add interface=ether2 bridge=bridge1 pvid=300 add interface=ether3 bridge=bridge1
Specify tagged and untagged ports in the bridge VLAN table, use these commands on SW1 and SW2:
/interface bridge vlan add bridge=bridge1 tagged=ether3 untagged=ether1 vlan-ids=200 add bridge=bridge1 tagged=ether3 untagged=ether2 vlan-ids=300
When the bridge VLAN table is configured, you can enable bridge VLAN filtering, use these commands on SW1 and SW2:
/interface bridge set bridge1 vlan-filtering=yes
By enabling vlan-filtering you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port.
Note, that if you are using the new EtherType/TPID 0x88a8 (service tag) and you also need a VLAN interface for your Service VLAN, you will also have to apply the use-service-tag
parameter on the VLAN interface.
When ether-type=0x8100
is configured, the bridge checks the outer VLAN tag and sees if it is using EtherType 0x8100
. If the bridge receives a packet with an outer tag that has a different EtherType, it will mark the packet as untagged
. Since RouterOS only checks the outer tag of a packet, it is not possible to filter 802.1Q packets when the 802.1ad protocol is used.
Currently, only CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers are capable of hardware offloaded VLAN filtering using the Service tag, EtherType/TPID 0x88a8
.
Devices with switch chip Marvell-98DX3257 (e.g. CRS354 series) do not support VLAN filtering on 1Gbps Ethernet interfaces for other VLAN types (0x88a8
and 0x9100
).
Tag stacking
Since RouterOS v6.43 it is possible to forcefully add a new VLAN tag over any existing VLAN tags, this feature can be used to achieve a CVID stacking setup, where a CVID (0x8100) tag is added before an existing CVID tag. This type of setup is very similar to the Provider bridge setup, to achieve the same setup but with multiple CVID tags (CVID stacking) we can use the same topology:
In this example R1, R2, R3, and R4 might be sending any VLAN tagged traffic, it can be 802.1ad, 802.1Q or any other type of traffic, but SW1 and SW2 needs isolate traffic between routers in a way that R1 is able to communicate only with R3, and R2 is only able to communicate with R4. To do so, you can tag all ingress traffic with a new CVID tag and only allow these VLANs on certain ports. Start by selecting the proper EtherType, use these commands on SW1 and SW2:
/interface bridge add name=bridge1 vlan-filtering=no ether-type=0x8100
In this setup, ether1 and ether2 will ignore any VLAN tags that are present and add a new VLAN tag, use the pvid
parameter to tag all ingress traffic on each port and allow tag-stacking
on these ports, use these commands on SW1 and SW2:
/interface bridge port add interface=ether1 bridge=bridge1 pvid=200 tag-stacking=yes add interface=ether2 bridge=bridge1 pvid=300 tag-stacking=yes add interface=ether3 bridge=bridge1
Specify tagged and untagged ports in the bridge VLAN table, you only need to specify the VLAN ID of the outer tag, use these commands on SW1 and SW2:
/interface bridge vlan add bridge=bridge1 tagged=ether3 untagged=ether1 vlan-ids=200 add bridge=bridge1 tagged=ether3 untagged=ether2 vlan-ids=300
When the bridge VLAN table is configured, you can enable bridge VLAN filtering, which is required in order for the pvid parameter to have any effect, use these commands on SW1 and SW2:
/interface bridge set bridge1 vlan-filtering=yes
By enabling vlan-filtering you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port.
MVRP
Multiple VLAN Registration protocol (MVRP) is a protocol based on Multiple Registration Protocol (MRP) which allows to register attributes (VLAN IDs in case of MVRP) with other members of Bridged LAN.
An MRP application can make or withdraw declarations of attributes which result in registration or leaving of those attributes with other MRP participants.
Here's how it works.
MRP consists of two parts:
Applicant - responsible for sending declarations (or leaves). Its behavior can be configured on a per-port basis using the setting called
mvrp-applicant-state
, and per-VLAN using themvrp-forbidden
setting.Registrar - responsible for registering incoming declarations. Its configuration can be set per-port using the
mvrp-registrar-state
setting, and per-VLAN using themvrp-forbidden
setting.
Registration Propagation: Incoming registration on a bridge port dynamically makes that specific port a tagged VLAN member. Additionally, the attributes associated with this registration are spread to all active (forwarding) bridge ports as a declaration.
Declaration Operation: In case of MVRP, the configured VLAN's get declared on each port, but they will only get configured as members of those VLAN's when a declaration is received from the LAN (Registrar will register the VLAN). From the perspective of an end-station, a single declaration will be registered on each upstream port across the entire LAN. When another end-station declares the same attribute, a path of registrations will be made between the two (or more) end stations, see the picture below.
MVRP helps to dynamically propagate VLAN information throughout the bridged network and configure VLANs only on the needed ports. This makes the network efficient by avoiding unnecessary traffic flooding.
As noted before, MVRP is only active on ports that are forwarding. In case of MSTP declarations and registrations are made only if the port is forwarding in the MSTI in which VLAN is mapped.
The point-to-point ports speed up the process of registration (or leaving). Manually configuring point-to-point=yes
can be advantageous for non-Ethernet interfaces.
Property Reference
Sub-menu: /interface bridge
Property | Description |
---|---|
mvrp (yes | no; Default: no) | Enables MVRP for bridge. It ensures that the MAC address 01:80:C2:00:00:21 is trapped and not forwarded, the |
Sub-menu: /interface bridge port
The port menu enables control over the applicant and registrar settings on a per-port basis.
Property | Description |
---|---|
mvrp-applicant-state (non-participant | normal-participant; Default: normal-participant) | MVRP applicant options:
|
mvrp-registrar-state (fixed | normal; Default: normal) | MVRP registrar options:
|
To monitor the currently declared and registered VLAN IDs, use the monitor
command.
[admin@MikroTik] > interface/bridge/port monitor [find interface=sfp-sfpplus1] interface: sfp-sfpplus1 status: in-bridge port-number: 1 role: designated-port edge-port: no edge-port-discovery: yes point-to-point-port: yes external-fdb: no sending-rstp: yes learning: yes forwarding: yes actual-path-cost: 2000 hw-offload-group: switch1 declared-vlan-ids: 1,10,20-21 registered-vlan-ids: 1,10,20,30-33
Sub-menu: /interface bridge vlan
All ports that are members of static VLANs or dynamic untagged VLANs created by the port pvid
setting are treated as "fixed." Meaning the registrar disregards all MRP messages and remains registered (IN) for those VLANs.
When VLAN is neither manually configured nor created by the port pvid
setting, incoming registrations on a bridge port can dynamically designate that specific port as a tagged VLAN member. The mvrp-forbidden
feature allows creating a list of ports that are restricted from registering into a specific VLAN ID.
VLANs that are static or dynamic will be declared by the applicants unless this functionality is disabled by the port's mvrp-applicant-state
, or by VLAN's mvrp-forbidden
setting.
Property | Description |
---|---|
mvrp-forbidden (interfaces; Default: ) | Ports that ignore all MRP messages and remains Not Registered (MT), as well as disables applicant from declaring specific VLAN ID. |
Sub-menu: /interface bridge vlan mvrp
The MVRP attributes menu can be used to see internal MVRP attribute states, as specified in the IEEE 802.1Q-2011.
Property | Description |
---|---|
applicant-state | The Applicant state machine that declares attributes. Its state can be VO, VP, VN, AN, AA, QA, LA, AO, QO, AP, QP, or LO. Each state consists of two letters. The first letter indicates the state:
The second letter indicates the membership state:
For example, VP indicates "Very anxious, Passive member." |
registrar-state | The Registrar state machine that records the registration state of attributes declared by other participants. Its state can be IN, LV, or MT:
|
[admin@Mikrotik] /interface/bridge/vlan/mvrp print where vlan-id=10 Columns: BRIDGE, PORT, VLAN-ID, REGISTRAR-STATE, APPLICANT-STATE, LAST-EVENT # BRIDGE PORT VLAN-ID REGISTRAR-STATE APPLICANT-STATE LAST-EVENT 1 bridge67 sfp-sfpplus1 10 IN Quiet Active JoinIn 9 bridge67 sfp-sfpplus5 10 MT Quiet Active JoinEmpty 17 bridge67 sfp-sfpplus9 10 MT Quiet Active JoinEmpty 25 bridge67 sfp-sfpplus13 10 IN Quiet Active JoinIn
Fast Forward
Fast Forward allows forwarding packets faster under special conditions. When Fast Forward is enabled, then the bridge can process packets even faster since it can skip multiple bridge-related checks, including MAC learning. Below you can find a list of conditions that MUST be met in order for Fast Forward to be active:
- Bridge has
fast-forward
set toyes
- Bridge has only 2 running ports
- Both bridge ports support Fast Path, Fast Path is active on ports and globally on the bridge
- Bridge Hardware Offloading is disabled
- Bridge VLAN Filtering is disabled
- Bridge DHCP snooping is disabled
unknown-multicast-flood
is set toyes
unknown-unicast-flood
is set toyes
broadcast-flood
is set toyes
- MAC address for the bridge matches with a MAC address from one of the bridge slave ports
horizon
for both ports is set tonone
Fast Forward disables MAC learning, this is by design to achieve faster packet forwarding. MAC learning prevents traffic from flooding multiple interfaces, but MAC learning is not needed when a packet can only be sent out through just one interface.
Fast Forward is disabled when hardware offloading is enabled. Hardware offloading can achieve full write-speed performance when it is active since it will use the built-in switch chip (if such exists on your device), fast forward uses the CPU to forward packets. When comparing throughput results, you would get such results: Hardware offloading > Fast Forward > Fast Path > Slow Path.
It is possible to check how many packets where processed by Fast Forward:
[admin@MikroTik] /interface bridge settings> pr use-ip-firewall: no use-ip-firewall-for-vlan: no use-ip-firewall-for-pppoe: no allow-fast-path: yes bridge-fast-path-active: yes bridge-fast-path-packets: 0 bridge-fast-path-bytes: 0 bridge-fast-forward-packets: 16423 bridge-fast-forward-bytes: 24864422
If packets are processed by Fast Path, then Fast Forward is not active. Packet count can be used as an indicator of whether Fast Forward is active or not.
Since RouterOS 6.44 it is possible to monitor Fast Forward status, for example:
[admin@MikroTik] /interface bridge monitor bridge1 state: enabled current-mac-address: B8:69:F4:C9:EE:D7 root-bridge: yes root-bridge-id: 0x8000.B8:69:F4:C9:EE:D7 root-path-cost: 0 root-port: none port-count: 2 designated-port-count: 2 fast-forward: yes
Disabling or enabling fast-forward will temporarily disable all bridge ports for settings to take effect. This must be taken into account whenever changing this property on production environments since it can cause all packets to be temporarily dropped.
IGMP/MLD Snooping
The bridge supports IGMP/MLD snooping. It controls multicast streams and prevents multicast flooding on unnecessary ports. Its settings are placed in the bridge menu and it works independently in every bridge interface. Software-driven implementation works on all devices with RouterOS, but CRS3xx, CRS5xx series switches, CCR2116, CR2216 routers, and 88E6393X, 88E6191X, 88E6190 switch chips also support IGMP/MLD snooping with hardware offloading. See more details on IGMP/MLD snooping manual.
DHCP Snooping and DHCP Option 82
DHCP Snooping and DHCP Option 82 is supported by bridge. The DHCP Snooping is a Layer2 security feature, that limits unauthorized DHCP servers from providing malicious information to users. In RouterOS, you can specify which bridge ports are trusted (where known DHCP server resides and DHCP messages should be forwarded) and which are untrusted (usually used for access ports, received DHCP server messages will be dropped). The DHCP Option 82 is additional information (Agent Circuit ID and Agent Remote ID) provided by DHCP Snooping enabled devices that allow identifying the device itself and DHCP clients.
In this example, SW1 and SW2 are DHCP Snooping, and Option 82 enabled devices. First, we need to create a bridge, assign interfaces and mark trusted ports. Use these commands on SW1:
/interface bridge add name=bridge /interface bridge port add bridge=bridge interface=ether1 add bridge=bridge interface=ether2 trusted=yes
For SW2, the configuration will be similar, but we also need to mark ether1 as trusted, because this interface is going to receive DHCP messages with Option 82 already added. You need to mark all ports as trusted if they are going to receive DHCP messages with added Option 82, otherwise these messages will be dropped. Also, we add ether3 to the same bridge and leave this port untrusted, imagine there is an unauthorized (rogue) DHCP server. Use these commands on SW2:
/interface bridge add name=bridge /interface bridge port add bridge=bridge interface=ether1 trusted=yes add bridge=bridge interface=ether2 trusted=yes add bridge=bridge interface=ether3
Then we need to enable DHCP Snooping and Option 82. In case your DHCP server does not support DHCP Option 82 or you do not implement any Option 82 related policies, this option can be disabled. Use these commands on SW1 and SW2:
/interface bridge set [find where name="bridge"] dhcp-snooping=yes add-dhcp-option82=yes
Now both devices will analyze what DHCP messages are received on bridge ports. The SW1 is responsible for adding and removing the DHCP Option 82. The SW2 will limit rogue DHCP server from receiving any discovery messages and drop malicious DHCP server messages from ether3.
Currently, CRS3xx, CRS5xx series switches, CCR2116, CR2216 routers, and 88E6393X, 88E6191X, 88E6190 switch chips fully support hardware offloaded DHCP Snooping and Option 82. For CRS1xx and CRS2xx series switches it is possible to use DHCP Snooping along with VLAN switching, but then you need to make sure that DHCP packets are sent out with the correct VLAN tag using egress ACL rules. Other devices are capable of using DHCP Snooping and Option 82 features along with hardware offloading, but you must make sure that there is no VLAN-related configuration applied on the device, otherwise, DHCP Snooping and Option 82 might not work properly. See the Bridge Hardware Offloading section with supported features.
For CRS3xx, CRS5xx series switches and CCR2116, CR2216 routers DHCP snooping will not work when hardware offloading bonding interfaces are created.
Controller Bridge and Port Extender
Controller Bridge (CB) and Port Extender (PE) is an IEEE 802.1BR standard implementation in RouterOS for CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers. It allows virtually extending the CB ports with a PE device and managing these extended interfaces from a single controlling device. Such configuration provides a simplified network topology, flexibility, increased port density, and ease of manageability. See more details on Controller Bridge and Port Extender manual.
Bridge Firewall
The bridge firewall implements packet filtering and thereby provides security functions that are used to manage data flow to, from, and through the bridge.
Packet flow diagram shows how packets are processed through the router. It is possible to force bridge traffic to go through /ip firewall filter
rules (see the bridge settings).
There are two bridge firewall tables:
- filter - bridge firewall with three predefined chains:
- input - filters packets, where the destination is the bridge (including those packets that will be routed, as they are destined to the bridge MAC address anyway)
- output - filters packets, which come from the bridge (including those packets that has been routed normally)
- forward - filters packets, which are to be bridged (note: this chain is not applied to the packets that should be routed through the router, just to those that are traversing between the ports of the same bridge)
- nat - bridge network address translation provides ways for changing source/destination MAC addresses of the packets traversing a bridge. Has two built-in chains:
- srcnat - used for "hiding" a host or a network behind a different MAC address. This chain is applied to the packets leaving the router through a bridged interface
- dstnat - used for redirecting some packets to other destinations
You can put packet marks in bridge firewall (filter and NAT), which are the same as the packet marks in IP firewall configured by '/ip firewall mangle'
. In this way, packet marks put by bridge firewall can be used in 'IP firewall', and vice versa.
General bridge firewall properties are described in this section. Some parameters that differ between nat and filter rules are described in further sections.
Sub-menu: /interface bridge filter, /interface bridge nat
Property | Description |
---|---|
802.3-sap (integer; Default: ) | DSAP (Destination Service Access Point) and SSAP (Source Service Access Point) are 2 one-byte fields, which identify the network protocol entities which use the link-layer service. These bytes are always equal. Two hexadecimal digits may be specified here to match an SAP byte. |
802.3-type (integer; Default: ) | Ethernet protocol type, placed after the IEEE 802.2 frame header. Works only if 802.3-sap is 0xAA (SNAP - Sub-Network Attachment Point header). For example, AppleTalk can be indicated by the SAP code of 0xAA followed by a SNAP type code of 0x809B. |
action (accept | drop | jump | log | mark-packet | passthrough | return | set-priority; Default: ) | Action to take if the packet is matched by the rule:
|
arp-dst-address (IP address; Default: ) | ARP destination IP address. |
arp-dst-mac-address (MAC address; Default: ) | ARP destination MAC address. |
arp-gratuitous (yes | no; Default: ) | Matches ARP gratuitous packets. |
arp-hardware-type (integer; Default: 1) | ARP hardware type. This is normally Ethernet (Type 1). |
arp-opcode (arp-nak | drarp-error | drarp-reply | drarp-request | inarp-reply | inarp-request | reply | reply-reverse | request | request-reverse; Default: ) | ARP opcode (packet type)
|
arp-packet-type (integer 0..65535 | hex 0x0000-0xffff; Default: ) | ARP Packet Type. |
arp-src-address (IP address; Default: ) | ARP source IP address. |
arp-src-mac-address (MAC addres; Default: ) | ARP source MAC address. |
chain (text; Default: ) | Bridge firewall chain, which the filter is functioning in (either a built-in one, or a user-defined one). |
dst-address (IP address; Default: ) | Destination IP address (only if MAC protocol is set to IP). |
dst-address6 (IPv6 address; Default: ) | Destination IPv6 address (only if MAC protocol is set to IPv6). |
dst-mac-address (MAC address; Default: ) | Destination MAC address. |
dst-port (integer 0..65535; Default: ) | Destination port number or range (only for TCP or UDP protocols). |
in-bridge (name; Default: ) | Bridge interface through which the packet is coming in. |
in-bridge-list (name; Default: ) | Set of bridge interfaces defined in interface list. Works the same as in-bridge . |
in-interface (name; Default: ) | Physical interface (i.e., bridge port) through which the packet is coming in. |
in-interface-list (name; Default: ) | Set of interfaces defined in interface list. Works the same as in-interface . |
ingress-priority (integer 0..63; Default: ) | Matches the priority of an ingress packet. Priority may be derived from VLAN, WMM, DSCP or MPLS EXP bit. read more |
ip-protocol (dccp | ddp | egp | encap | etherip | ggp | gre | hmp | icmp | icmpv6 | idpr-cmtp | igmp | ipencap | ipip | ipsec-ah | ipsec-esp | ipv6 | ipv6-frag | ipv6-nonxt | ipv6-opts | ipv6-route | iso-tp4 | l2tp | ospf | pim | pup | rdp | rspf | rsvp | sctp | st | tcp | udp | udp-lite | vmtp | vrrp | xns-idp | xtp; Default: ) | IP protocol (only if MAC protocol is set to IPv4)
|
jump-target (name; Default: ) | If action=jump specified, then specifies the user-defined firewall chain to process the packet. |
limit (integer/time,integer; Default: ) | Restricts packet match rate to a given limit.
|
log (yes | no; Default: no) | Add a message to the system log containing the following data: in-interface, out-interface, src-mac, dst-mac, eth-protocol, ip-protocol, src-ip:port->dst-ip:port, and length of the packet. |
log-prefix (text; Default: ) | Defines the prefix to be printed before the logging information. |
mac-protocol (802.2 | arp | homeplug-av | ip | ipv6 | ipx | length | lldp | loop-protect | mpls-multicast | mpls-unicast | packing-compr | packing-simple | pppoe | pppoe-discovery | rarp | service-vlan | vlan | integer 0..65535 | hex 0x0000-0xffff; Default: ) | Ethernet payload type (MAC-level protocol). To match protocol type for VLAN encapsulated frames (0x8100 or 0x88a8), a vlan-encap property should be used.
|
new-packet-mark (string; Default: ) | Sets a new packet-mark value. |
new-priority (integer | from-ingress; Default: ) | Sets a new priority for a packet. This can be the VLAN, WMM or MPLS EXP priority Read more. This property can also be used to set an internal priori |
out-bridge (name; Default: ) | Outgoing bridge interface. |
out-bridge-list (name; Default: ) | Set of bridge interfaces defined in interface list. Works the same as out-bridge . |
out-interface (name; Default: ) | Interface that the packet is leaving the bridge through. |
out-interface-list (name; Default: ) | Set of interfaces defined in interface list. Works the same as out-interface . |
packet-mark (name; Default: ) | Match packets with a certain packet mark. |
packet-type (broadcast | host | multicast | other-host; Default: ) | MAC frame type:
|
src-address (IP address; Default: ) | Source IP address (only if MAC protocol is set to IPv4). |
src-address6 (IPv6 address; Default: ) | Source IPv6 address (only if MAC protocol is set to IPv6). |
src-mac-address (MAC address; Default: ) | Source MAC address. |
src-port (integer 0..65535; Default: ) | Source port number or range (only for TCP or UDP protocols). |
stp-flags (topology-change | topology-change-ack; Default: ) | The BPDU (Bridge Protocol Data Unit) flags. Bridge exchange configuration messages named BPDU periodically for preventing loops
|
stp-forward-delay (integer 0..65535; Default: ) | Forward delay timer. |
stp-hello-time (integer 0..65535; Default: ) | STP hello packets time. |
stp-max-age (integer 0..65535; Default: ) | Maximal STP message age. |
stp-msg-age (integer 0..65535; Default: ) | STP message age. |
stp-port (integer 0..65535; Default: ) | STP port identifier. |
stp-root-address (MAC address; Default: ) | Root bridge MAC address. |
stp-root-cost (integer 0..65535; Default: ) | Root bridge cost. |
stp-root-priority (integer 0..65535; Default: ) | Root bridge priority. |
stp-sender-address (MAC address; Default: ) | STP message sender MAC address. |
stp-sender-priority (integer 0..65535; Default: ) | STP sender priority. |
stp-type (config | tcn; Default: ) | The BPDU type:
|
tls-host (string; Default: ) | Allows matching https traffic based on TLS SNI hostname. Accepts GLOB syntax for wildcard matching. Note that matcher will not be able to match hostname if the TLS handshake frame is fragmented into multiple TCP segments (packets). |
vlan-encap (802.2 | arp | ip | ipv6 | ipx | length | mpls-multicast | mpls-unicast | pppoe | pppoe-discovery | rarp | vlan | integer 0..65535 | hex 0x0000-0xffff; Default: ) | Matches the MAC protocol type encapsulated in the VLAN frame. |
vlan-id (integer 0..4095; Default: ) | Matches the VLAN identifier field. |
vlan-priority (integer 0..7; Default: ) | Matches the VLAN priority (priority code point) |
Footnotes:
- STP matchers are only valid if the destination MAC address is
01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF
(Bridge Group address), also STP should be enabled.
- ARP matchers are only valid if mac-protocol is
arp
orrarp
- VLAN matchers are only valid for
0x8100
or0x88a8
ethernet protocols
- IP or IPv6 related matchers are only valid if mac-protocol is either set to
ip
oripv6
- 802.3 matchers are only consulted if the actual frame is compliant with IEEE 802.2 and IEEE 802.3 standards. These matchers are ignored for other packets.
Bridge Packet Filter
This section describes specific bridge filter options.
Sub-menu: /interface bridge filter
Property | Description |
---|---|
action (accept | drop | jump | log | mark-packet | passthrough | return | set-priority; Default: accept) | Action to take if the packet is matched by the rule:
|
Bridge NAT
This section describes specific bridge NAT options.
Sub-menu: /interface bridge nat
Property | Description |
---|---|
action (accept | drop | jump | mark-packet | redirect | set-priority | arp-reply | dst-nat | log | passthrough | return | src-nat; Default: accept) | Action to take if the packet is matched by the rule:
|
to-arp-reply-mac-address (MAC address; Default: ) | Source MAC address to put in Ethernet frame and ARP payload, when action=arp-reply is selected |
to-dst-mac-address (MAC address; Default: ) | Destination MAC address to put in Ethernet frames, when action=dst-nat is selected |
to-src-mac-address (MAC address; Default: ) | Source MAC address to put in Ethernet frames, when action=src-nat is selected |
See also
Page edited by Guntis G.
Summary
Allows defining a set of interfaces for easier interface management in the different interface-based configuration sections such as Neighbor Discovery, Firewall, Bridge, and Internet Detect.
Lists
Sub-menu: /interface list
This menu contains information about all interface lists available on the router. There are four predefined lists - all
(contains all interfaces), none
(contains no interfaces), dynamic
(contains dynamic interfaces), and static
(contains static interfaces). It is also possible to create additional interface lists.
Dynamic interfaces are interfaces that have a "dynamic" flag. Any interface that doesn't have a dynamic flag will be part of the static
interface list.
Property | Description |
---|---|
name (string) | Name of the interface list |
include (string) | Defines interface list which members are included in the list. It is possible to add multiple lists separated by commas |
exclude (string) | Defines interface list which members are excluded from the list. It is possible to add multiple lists separated by commas |
Members are added to the interface list in the following order:
- include members are added to the interface list
- exclude members are removed from the list
- Statically configured members are added to the list
Members
Sub-menu: /interface list member
This sub-menu contains information about statically configured interface members to each interface list. Note that dynamically added interfaces by include and exclude statements are not represented in this sub-menu.
Property | Description |
---|---|
interface (string) | Name of the interface |
list (string) | Name of the interface list |
Care must be taken when working with bridges and lists. Adding a bridge as a member is not the same as adding all its ports! And adding all slave ports as members is not the same as adding the bridge itself. This can particularly impact functionality of neighbor discovery.
Page edited by Emīls T.
Summary
Package: system
Support for Direct-IP mode type cards only. MBIM support is available in RouterOS v7 releases and MBIM driver is loaded automatically. If modem is not recognized in RouterOS v6 - Please test it in v7 releases before asking for support in RouterOS v6.
To enable access via a PPP interface instead of a LTE Interface, change direct IP mode with /port firmware set ignore-directip-modem=yes
command and a reboot. Note that using PPP emulation mode you may not get the same throughput speeds as using the LTE interface emulation type.
For RouterOS v7 ignore-direct-modem parameter renamed to "mode" and moved to /interface lte settings
menu.
LTE Client
Sub-menu: /interface lte
Properties
Property | Description |
---|---|
allow-roaming (yes | no; Default: no) | Enable data roaming for connecting to other countries data-providers. Not all LTE modems support this feature. Some modems, that do not fully support this feature, will connect to the network but will not establish an IP data connection with allow-roaming set to no. |
apn-profiles (string; Default: default) | Which APN profile to use for this interface |
band (integer list; Default: "") | LTE Frequency band used in communication LTE Bands and bandwidths |
nr-band (integer list; Default: "") | 5G NR Frequency band used in communication 5G NR Bands and bandwidths |
comment (string; Default: "") | Descriptive name of an item |
disabled (yes | no; Default: yes) | Whether interface is disabled or not. By default it is disabled. |
modem-init (string; Default: "") | Modem init string (AT command that will be executed at modem startup) |
mtu (integer; Default: 1500) | Maximum Transmission Unit. Max packet size that LTE interface will be able to send without packet fragmentation. |
name (string; Default: "") | Descriptive name of the interface. |
network-mode (3g | gsm | lte | 5g) | Select/force mode for LTE interface to operate with |
operator (integer; Default: "") | used to lock device to specific operator full PLMN number is used for lock consisting from MCC+MNC. PLMN codes |
pin (integer; Default: "") | SIM Card's PIN code. |
APN profiles
All network related settings are moved under profiles, starting from RouterOS 6.41
Sub-menu: /interface lte apn
Property | Description |
---|---|
add-default-route (yes | no) | Whether to add default route to forward all traffic over the LTE interface. |
apn (string) | Service Provider's Access Point Name |
authentication (pap | chap | none; Default: none) | Allowed protocol to use for authentication |
default-route-distance (integer; Default: 2) | Sets distance value applied to auto created default route, if add-default-route is also selected. LTE route by default is with distance 2 to prefer wired routes over LTE |
ip-type (ipv4 | auto | ipv6; Default: auto ) | Requested PDN type |
ipv6-interface (; Default: ) | Interface on which to advertise IPv6 prefix |
name (string; Default: ) | APN profile name |
number (integer; Default: ) | APN profile number |
passthrough-interface (; Default: ) | Interface to passthrough IP configuration (activates passthrough) |
passthrough-mac (MAC; Default: auto) | If set to auto, then will learn MAC from first packet |
passthrough-subnet-selection (auto / p2p; Default: auto) | "auto" selects the smallest possible subnet to be used for the passthrough interface. "p2p" sets the passthrough interface subnet as /32 and picks gateway address from 10.177.0.0/16 range. The gateway address stays the same until the apn configuration is changed. |
password (string; Default: ) | Password used if any of the authentication protocols are active |
use-network-apn (yes | no; Default: yes) | Parameter is available starting from RouterOS v7 and used only for MBIM modems. If set to yes, uses network provided APN. |
use-peer-dns (yes | no; Default: yes) | If set to yes, uses DNS recieved from LTE interface |
user (integer) | Username used if any of the authentication protocols are active |
LTE settings
LTE and router-specific LTE settings. The menu is available starting from RouterOS v7.
Sub-menu: /interface lte settings
Property | Description |
---|---|
mode (auto | mbim | serial; Default: auto) | Operation mode setting.
|
firmware-path (string) | Firmware path in host OS. Modem gobi firmware |
external-antenna (auto | both | div | main | none; Default: auto) | This setting is only available for "Chateau" routers, except for Chateau 5G versions.
|
external-antenna-selected () | This setting is only available for "Chateau" routers, except for Chateau 5G versions. Shows the currently selected antenna if "external-antenna" is set to "auto" |
sim-slot () | This setting is available for routers that have switchable SIM slots (LtAP, SXT). Selection options differ between products. |
Scanner
It is possible to scan LTE interfaces with /interface lte scan
command. Example:
[admin@MikroTik] > /interface lte scan duration=60 number=0 Columns: OPERATOR, MCC-MNC, RSSI, RSRP, RSRQ OPERATOR MCC-MNC RSSI RSRP RSRQ LMT 24701 -36dBm -63dBm -7dB
Available properties:
Property | Description |
---|---|
duration (integer) | Duration of scan in seconds |
freeze-frame-interval (integer) | time between data printout |
number (integer) | Interface number or name |
User Info command
It is possible to send special "info" command to LTE interface with /interface lte info
command. In RouterOS v7 this command is moved to /interface lte monitor
menu.
Properties (Up to 6.40)
Property | Description |
---|---|
user-command (string; Default: "") | send a command to LTE card to extract useful information, e.g. with AT commands |
user-command-only (yes | no; Default: ) |
User at-chat command
It is possible to send user defined "at-chat" command to LTE interface with /interface lte at-chat
command.
[admin@MikroTik] > /interface lte at-chat lte1 input="AT" output: OK
It is also possible to use the "wait" parameter wait=yes with the command to make "at-chat" wait for 5 seconds and return all the output instead of returning only the first received data, this is useful for some commands that return multiline output or a large block of data.
[admin@MikroTik] > interface lte at-chat lte1 input="at+qcfg=?" output: [admin@MikroTik] > interface lte at-chat lte1 input="at+qcfg=?" wait=yes output: +QCFG: "rrc",(0-5) +QCFG: "hsdpacat",(6,8,10-24) +QCFG: "hsupacat",(5,6) +QCFG: "pdp/duplicatechk",(0,1) +QCFG: "risignaltype",("respective","physical") +QCFG: "lte/bandprior",(1-43),(1-43),(1-43) +QCFG: "volte_disable",(0,1) +QCFG: "diversity/config",(4,6),(1-4),(0) +QCFG: "div_test_mode",(0,1) +QCFG: "usbspeed",("20","30") +QCFG: "data_interface",(0,1),(0,1) +QCFG: "pcie/mode",(0,1) +QCFG: "pcie_mbim",(0,1) +QCFG: "sms_control",(0,1),(0,1) +QCFG: "call_control",(0,1),(0,1) +QCFG: "usb/maxpower",(0-900) +QCFG: "efratctl",(0,1) +QCFG: "netmaskset",(0,1)[,<netmask>] +QCFG: "mmwave",ant_chip,ant_type +QCFG: "gatewayset",(0,1)[,<gateway>] +QCFG: "clat",(0,1),(0,1),<prefix>,(0,32,40,48,56,64,96),<fqdn>,(0,1),(0,1,2,4,8),(0,1),(0,1),(0,1,2),(0,1,2) +QCFG: "usage/apmem" +QCFG: "enable_gea1"[,(0,1)] +QCFG: "dhcppktfltr",(0,1) OK
You can also use "at-chat" function in scripts and assign command output to variable.
[admin@MikroTik] > :global "lte_command" [/interface lte at-chat lte1 input="AT+CEREG?" as-value ] [admin@MikroTik] > :put $"lte_command" output=+CEREG: 0,1 OK
Quick setup example
Start with network settings -
Start with network settings - Add new connection parameters under LTE apn profile (provided by network provider):
/interface lte apn add name=profile1 apn=phoneprovider.net authentication=chap password=web user=web
Select newly created profile for LTE connection:
/interface lte set [find] apn-profiles=profile1
LTE interface should appear with running (R) flag:
[admin@MikroTik] > /interface lte print Flags: X - disabled, R - running 0 R name="lte1" mtu=1500 mac-address=AA:AA:AA:AA:AA:AA
If required, add NAT Masquerade for LTE Interface to get internet to the local network:
/ip firewall nat add action=masquerade chain=srcnat out-interface=lte1
After interface is added, you can use "info" command to see what parameters client acquired (parameters returned depends on LTE hardware device):
[admin@MikroTik] > interface/lte/monitor lte1 status: connected model: EG18-EA revision: EG18EAPAR01A12M4G current-operator: LMT current-cellid: 3103242 enb-id: 12122 sector-id: 10 phy-cellid: 480 data-class: LTE session-uptime: 15m54s imei: 86981604098XXXX imsi: 24701060267XXXX uicc: 8937101122102057XXXX primary-band: B3@20Mhz earfcn: 1300 phy-cellid: 480 dl-modulation: qpsk cqi: 7 ri: 2 mcs: 1 rssi: -68dBm rsrp: -97dBm rsrq: -9dB sinr: 6dB
Passthrough Example
Starting from RouterOS v6.41 some LTE interfaces support LTE Passthrough feature where the IP configuration is applied directly to the client device. In this case modem firmware is responsible for the IP configuration and router is used only to configure modem settings - APN, Network Technologies and IP-Type. In this configuration the router will not get IP configuration from the modem. The LTE Passthrough modem can pass both IPv4 and IPv6 addresses if that is supported by modem. Some modems support multiple APN where you can pass the traffic from each APN to a specific router interface.
Passthrough will only work for one host. Router will automatically detect MAC address of the first received packet and use it for the Passthrough. If there are multiple hosts on the network it is possible to lock the Passthrough to a specific MAC. On the host on the network where the Passthrough is providing the IP a DHCP-Client should be enabled on that interface to. Note, that it will not be possible to connect to the LTE router via public lte ip address or from the host which is used by the passthrough. It is suggested to create additional connection from the LTE router to the host for configuration purposes. For example vlan interface between the LTE router and host.
To enable the Passthrough a new entry is required or the default entry should be changed in the '/interface lte apn' menu
Examples.
To configure the Passthrough on ether1:
[admin@MikroTik] > /interface lte apn add apn=apn1 passthrough-interface=ether1 [admin@MikroTik] > /interface lte set lte1 apn-profiles=apn1
To configure the Passthrough on ether1 host 00:0C:42:03:06:AB:
[admin@MikroTik] > /interface lte apn add apn=apn1 passthrough-interface=ether1 passthrough-mac=00:0C:42:03:06:AB [admin@MikroTik] > /interface lte set lte1 apn-profiles=apn1
To configure multiple APNs on ether1 and ether2:
[admin@MikroTik] > /interface lte apn add apn=apn1 passthrough-interface=ether1 [admin@MikroTik] > /interface lte apn add apn=apn2 passthrough-interface=ether2 [admin@MikroTik] > /interface lte set lte1 apn-profiles=apn1,apn2
To configure multiple APNs with the same APN for different interfaces:
[admin@MikroTik] > /interface lte apn add name=interface1 apn=apn1 [admin@MikroTik] > /interface lte apn add name=interface2 apn=apn1 passthrough-interface=ether1 [admin@MikroTik] > /interface lte set lte1 apn-profiles=interface1 [admin@MikroTik] > /interface lte set lte2 apn-profiles=interface2
Dual SIM
Boards with switchable SIM slots
RouterBoard | Modem slot | SIM slots | Switchable |
---|---|---|---|
LtAP | lower | 2 | 3 | Y |
upper | 1 | N | |
LtAP mini | up | down | Y | |
SXT R | a | b | Y |
SIM slots switching commands
- RouterOS v7
/interface lte settings set sim-slot=down
- RouterOS v6 after 6.45.1
/system routerboard modem set sim-slot=down
- RouterOS v6 pre 6.45.1:
/system routerboard sim set sim-slot=down
For more reference please see board block diagram, Quick Guide and User manual.
Usage Example
Follow this link - Dual SIM Application, to see examples of how to change SIM slot based on roaming status and in case the interface status is down with help of RouterOS scripts and scheduler.
Tips and Tricks
This paragraph contains information for additional features and usage cases.
Find device location using Cell information
On devices using R11e-LTE International version card (wAP LTE kit) some extra information is provided under info command (from 6.41rc61)
current-operator: 24701 lac: 40 current-cellid: 2514442
Property | Description |
---|---|
current-operator (integer; Default: ) | Contains MCC and MNC. For example: current-operator: 24701 breaks to: MCC=247 MNC=01 |
lac (integer; Default: ) | location area code (LAC) |
current-cellid (integer; Default: ) | Station identification number |
Values can be used to find location in databases: Cell Id Finder
Using Cell lock
It is possible to lock R11e-LTE, R11e-LTE6 and R11e-4G modems and equipped devices to exact LTE tower. LTE info command provides currently used cellular tower information:
phy-cellid: 384 earfcn: 1300 (band 3, bandwidth 20Mhz)
Property | Description |
---|---|
phy-cellid (integer; Default: ) | Physical Cell Identification (PCI) of currently used cell tower. |
earfcn (integer; Default: ) | Absolute Radio Frequency Channel Number |
Exact tower location as well as available bands and other information can be acquired from mobile carrier or by using online services:
By using those acquired variables it's possible to send AT command to modem for locking to tower in current format:
for R11e-LTE and R11e-LTE6
AT*Cell=<mode>,<NetworkMode>,<band>,<EARFCN>,<PCI> where <mode> : 0 – Cell/Frequency disabled 1 – Frequency lock enabled 2 – Cell lock enabled <NetworkMode> 0 – GSM 1 – UMTS_TD 2 – UMTS_WB 3 – LTE <band> Not in use, leave this blank <EARFCN> earfcn from lte info <PCI> phy-cellid from lte info
To lock modem at previously used tower at-chat can be used:
/interface lte at-chat lte1 input="AT*Cell=2,3,,1300,384"
For R11e-LTE all set on locks are lost after reboot or modem reset. Cell data can be also gathered from "cell-monitor".
For R11e-LTE6 cell lock works only for the primary band, this can be useful if you have multiple channels on the same band and you want to lock it to a specific earfcn. Note, that cell lock is not band-specific and for ca-band it can also use other frequency bands, unless you use band lock.
Use cell lock to set the primary band to the 1300 earfcn and use the second channel for the ca-band:
/interface lte at-chat lte1 input="AT*Cell=2,3,,1300,138"
Now it uses the earfcn: 1300 for the primary channel:
primary-band: B3@20Mhz earfcn: 1300 phy-cellid: 138 ca-band: B3@5Mhz earfcn: 1417 phy-cellid: 138
You can also set it the other way around:
/interface lte at-chat lte1 input="AT*Cell=2,3,,1417,138"
Now it uses the earfcn: 1417 for the primary channel:
primary-band: B3@5Mhz earfcn: 1417 phy-cellid: 138 ca-band: B3@20Mhz earfcn: 1300 phy-cellid: 138
For R11e-LTE6 modem cell lock information will not be lost after reboot or modem reset. To remove cell lock use at-chat command:
/interface lte at-chat lte1 input="AT*Cell=0"
for R11e-4G
AT%CLCMD=<mode>,<mode2>,<EARFCN>,<PCI>,<PLMN> AT%CLCMD=1,1,3250,244,\"24705\" where <mode> : 0 – Cell/Frequency disabled 1 – Cell lock enabled <mode2> : 0 - Save lock for first scan 1 - Always use lock (after each reset modem will clear out previous settings no matter what is used here) <EARFCN> earfcn from lte info <PCI> phy-cellid from lte info <PLMN> Mobile operator code
All PLMN codes available here this variable can be also left blank
To lock modem to the cell - modem needs to be in non operating state, easiest way for R11e-4G modem is to add CellLock line to "modem-init" string:
/interface lte set lte1 modem-init="AT%CLCMD=1,1,3250,244,\"24705\""
Multiple cells can also be added by providing list instead of one tower information in following format:
AT%CLCMD=<mode>,<mode2>,<EARFCN_1>,<PCI_1>,<PLMN_1>,<EARFCN_2>,<PCI_2>,<PLMN_2>
For example to lock to two different PCIs within same band and operator:
/interface lte set lte1 modem-init="AT%CLCMD=1,1,6300,384,\"24701\",6300,385,\"24701\""
for Chateau LTE12, Chateau 5G, LHG LTE18 and ATL LTE18
AT+QNWLOCK="common/4g",<num of cells>,[[<freq>,<pci>],...] AT+QNWLOCK=\"common/4g\",1,6300,384 where <num of cells> number of cells to cell lock <freq> earfcn from lte info <pci> phy-cellid from lte info
Single cell lock example:
/interface lte at-chat lte1 input="AT+QNWLOCK=\"common/4g\",1,3050,448"
Query current configuration:
/interface lte at-chat lte1 input="AT+QNWLOCK=\"common/4g\""
Multiple cells can also be added to the cell lock. For example to lock to two different cells:
/interface lte at-chat lte1 input="AT+QNWLOCK=\"common/4g\",2,3050,448,1574,474"
To remove the cell lock use this at-chat command:
/interface lte at-chat lte1 input="at+qnwlock=\"common/4g\",0"
for Fibocom FG621
AT+GTCELLLOCK=<mode>[,<rat>,<type>,<earfcn>[,<PCI>]]
where
< mode >: integer type; 0 Disable this function 1 Enable this function 2 Add new cell to be locked
<rat>: integer type; 0 LTE 1 WCDMA
<type>: integer type; 0 Lock PCI 1 Lock frequency
<earfcn>: integer type; the range is 0-65535.
<PCI>: integer type; If second parameter value is 0, the range is 0-503 for LTE If second parameter value is 1, the range is 0-512 for WCDMA
Example:
/interface lte at-chat lte1 input="AT+GTCELLLOCK=1,0,0,6175,176"
Cell Monitor
Cell monitor allows to scan available nearby mobile network cells:
[admin@MikroTik] > /interface lte cell-monitor lte1 PHY-CELLID BAND PSC EARFCN RSRP RSRQ RSSI SINR 49 B20 6300 -110dBm -19.5dB 272 B20 6300 -116dBm -19.5dB 374 B20 6300 -108dBm -16dB 384 B1 150 -105dBm -13.5dB 384 B3 1300 -106dBm -12dB 384 B7 2850 -107dBm -11.5dB 432 B7 2850 -119dBm -19.5dB
Gathered data can be used for more precise location detection or for Cell lock.
Troubleshooting
Enable LTE logging:
[admin@MikroTik] > /system logging add topics=lte
Check for errors in log:
[admin@MikroTik] > /log print 11:08:59 lte,async lte1: sent AT+CPIN? 11:08:59 lte,async lte1: rcvd +CME ERROR: 10
search for CME error description online,
in this case: CME error 10 - SIM not inserted
Locking band on Huawei and other modems
To lock band for Huawei modems /interface lte set lte1 band=""
option can't be used.
It is possible to use AT commands to lock to desired band manually.
To check all supported bands run at-chat command:
[admin@MikroTik] /interface lte at-chat lte1 input="AT^SYSCFGEX=\?" output: ^SYSCFGEX: ("00","03","02","01","99"),((2000004e80380,"GSM850/GSM900/GSM1800/GSM1900/WCDMA BCI/WCDMA BCII/WCDMA BCV/WCDMA BCVIII"), (3fffffff,"All Bands")),(0-2),(0-4),((800d7,"LTE BC1/LTE BC2/LTE BC3/LTE BC5/LTE BC7/LTE BC8/LTE BC20"),(7fffffffffffffff,"All Bands")) OK
Example to lock to LTE band 7:
[admin@MikroTik] /interface lte set lte1 modem-init="AT^SYSCFGEX=\"03\",3FFFFFFF,2,4,40,,"
Change last part 40 to desired band specified hexadecimal value where:
4 LTE BC3 40 LTE BC7 80000 LTE BC20 7FFFFFFFFFFFFFFF All bands etc
All band HEX values and AT commands can be found in Huawei AT Command Interface Specification guide
Check if band is locked:
[admin@MikroTik] /interface lte at-chat lte1 input="AT^SYSCFGEX\?" output: ^SYSCFGEX: "03",3FFFFFFF,0,2,40 OK
For more information check modem manufacturers AT command reference manuals.
mPCIe modems with RB9xx series devices
In case your modem is not being recognized after a soft reboot, then you might need to add a delay before the USB port is being initialized. This can be done using the following command:
/system routerboard settings set init-delay=5s
Boards with USB-A port and mPCIe
Some devices such as specific RB9xx's and the RBLtAP-2HnD share the same USB lines between a single mPCIe slot and a USB-A port. If auto switch is not taking place and a modem is not getting detected, you might need to switch manually to either use the USB-A or mini-PCIe:
/system routerboard usb set type=mini-PCIe
Modem firmware upgrade
Starting from RouterOS version 6.44beta20 it is possible to upgrade modems firmware. The firmware upgrade is also possible for the Chateau series products starting from 7.1beta1 version.
Firmware update is available only as FOTA Firmware Over The Air - firmware upgrade can only be done through working mobile connection for:
- )R11e-LTE
- )R11e-LTE-US
Firmware update available as FOTA and as well as upgrade from file for:
- )R11e-4G
- )R11e-LTE6
Firmware update available as FOTA with access to the internet over any interface:
- )EG12-EA (Chateau LTE12)
- )RG502Q-EA (Chateau 5G)
- )EG18-EA (LHG LTE18)
Firmware updates usually includes small improvements in stability or small bug fixes that can't be included into RouterOS.
Check currently used firmware version by running:
[admin@MikroTik] > /interface lte info lte1 once ----- revision: "MikroTik_CP_2.160.000_v008" -----
Check if new firmware is available:
[admin@MikroTik] > /interface lte firmware-upgrade lte1 installed: MikroTik_CP_2.160.000_v008 latest: MikroTik_CP_2.160.000_v010
Upgrade firmware:
[admin@MikroTik] > /interface lte firmware-upgrade lte1 upgrade=yes status: downloading via LTE connection (>2min)
After successful upgrade issue USB power-reset, reboot device or run AT+reset command, to update modem version readout under info command:
[admin@MikroTik] > /interface lte at-chat lte1 input="AT+reset"
if modem has issues connecting to cells after update, or there are any other unrelated issues - wipe old configuration with:
/interface lte at-chat lte1 input="AT+RSTSET"
Avoiding tethering speed throttling
Some operators (TMobile, YOTA etc.) allows unlimited data only for device SIM card is used on, all other data coming from mobile hotspots or tethering is highly limited by volume or by throughput speed. Some sources have found out that this limitation is done by monitoring TTL (Time To Live) values from packets to determinate if limitations need to be applied (TTL is decreased by 1 for each "hop" made). RouterOS allows changing the TTL parameter for packets going from the router to allow hiding sub networks. Keep in mind that this may conflict with fair use policy.
IPv4 mangle rule: /ip firewall mangle add action=change-ttl chain=postrouting new-ttl=set:65 out-interface=lte1 passthrough=yes IPv6 mangle rule: /ipv6 firewall mangle add action=change-hop-limit chain=postrouting new-hop-limit=set:65 passthrough=yes
More information: YOTA, TMobile
Unlocking SIM card after multiple wrong PIN code attempts
After locking SIM card, unlock can be done through "at-chat"
Check current PIN code status:
/interface lte at-chat lte1 input="at+cpin\?"
If card is locked - unlock it by providing:
/interface lte at-chat lte1 input="AT+CPIN=\"PUK_code\",\"NEW_PIN\""
Replace PUK_code and NEW_PIN with matching values.
The command for sim slot selection changes in v6.45.1 and again in v7. Some device models like SXT, have SIM slots named "a" and "b" instead of "up" and down"
Page edited by Guntis G. - "formatting/typos"
- Summary
- Port switching
- VLAN
- (R/M)STP
- Bonding
- Multi-chassis Link Aggregation Group
- L3 Hardware Offloading
- Port isolation
- IGMP/MLD Snooping
- DHCP Snooping and DHCP Option 82
- Controller Bridge and Port Extender
- Mirroring
- Traffic Shaping
- Traffic Storm Control
- MPLS hardware offloading
- Switch Rules (ACL)
- Port Security
- Dual Boot
- Configuring SwOS using RouterOS
- See also
Summary
The CRS3xx and CRS5xx series switches, as well as the CCR2116 and CCR2216 routers, feature highly integrated switches with high-performance CPUs and feature-rich packet processors. These devices can be used for various Ethernet applications, including unmanaged switches, Layer 2 managed switches, carrier switches, inter-VLAN routers, and wired unified packet processors.
This article applies to CRS3xx, CRS5xx series switches, and CCR2116, CCR2216 routers, and not to CRS1xx/CRS2xx series switches.
Features
Features | Description |
---|---|
Forwarding |
|
Routing |
|
Spanning Tree Protocol |
|
Mirroring |
|
VLAN |
|
Bonding |
|
Traffic Shaping |
|
Port isolation |
|
Access Control List |
|
Models
This table clarifies the main differences between Cloud Router Switch models and CCR routers.
Model | Switch Chip | CPU | Cores | 10G SFP+ | 2.5G Ethernet | 10G Ethernet | 25G SFP28 | 40G QSFP+ | 100G QSFP28 | ACL rules | Unicast FDB entries | Jumbo Frame (Bytes) |
netPower 15FR (CRS318-1Fi-15Fr-2S) | Marvell-98DX224S | 800MHz | 1 | - | - | - | - | - | - | 128 | 16,000 | 10218 |
netPower 16P (CRS318-16P-2S+) | Marvell-98DX226S | 800MHz | 1 | 2 | - | - | - | - | - | 128 | 16,000 | 10218 |
CRS310-1G-5S-4S+ (netFiber 9/IN) | Marvell-98DX226S | 800MHz | 1 | 4 | - | - | - | - | - | 128 | 16,000 | 10218 |
CRS310-8G+2S+ | Marvell-98DX226S | 800MHz | 2 | 2 | 8 | - | - | - | - | 128 | 16,000 | 10218 |
CRS326-24G-2S+ (RM/IN) | Marvell-98DX3236 | 800MHz | 1 | 2 | - | - | - | - | - | 128 | 16,000 | 10218 |
CRS328-24P-4S+ | Marvell-98DX3236 | 800MHz | 1 | 4 | - | - | - | - | - | 128 | 16,000 | 10218 |
CRS328-4C-20S-4S+ | Marvell-98DX3236 | 800MHz | 1 | 4 | - | - | - | - | - | 128 | 16,000 | 10218 |
CRS305-1G-4S+ | Marvell-98DX3236 | 800MHz | 1 | 4 | - | - | - | - | - | 128 | 16,000 | 10218 |
CRS309-1G-8S+ | Marvell-98DX8208 | 800MHz | 2 | 8 | - | - | - | - | - | 1024 | 32,000 | 10218 |
CRS317-1G-16S+ | Marvell-98DX8216 | 800MHz | 2 | 16 | - | - | - | - | - | 1024 | 128,000 | 10218 |
CRS312-4C+8XG | Marvell-98DX8212 | 650MHz | 1 | 4 (combo ports) | - | 8 + 4 (combo ports) | - | - | - | 512 | 32,000 | 10218 |
CRS326-24S+2Q+ | Marvell-98DX8332 | 650MHz | 1 | 24 | - | - | - | 2 | - | 256 | 32,000 | 10218 |
CRS354-48G-4S+2Q+ | Marvell-98DX3257 | 650MHz | 1 | 4 | - | - | - | 2 | - | 170 | 32,000 | 10218 |
CRS354-48P-4S+2Q+ | Marvell-98DX3257 | 650MHz | 1 | 4 | - | - | - | 2 | - | 170 | 32,000 | 10218 |
CRS504-4XQ (IN/OUT) | Marvell-98DX4310 | 650MHz | 1 | - | - | - | - | - | 4 | 1024 | 128,000 | 10218 |
CRS510-8XS-2XQ-IN | Marvell-98DX4310 | 650MHz | 1 | - | - | - | 8 | - | 2 | 1024 | 128,000 | 10218 |
CRS518-16XS-2XQ | Marvell-98DX8525 | 650MHz | 1 | - | - | - | 16 | - | 2 | 1024 | 128,000 | 10218 |
CCR2116-12G-4S+ | Marvell-98DX3255 | 2000MHz | 16 | 4 | - | - | - | - | - | 512 | 32,000 | 9570 |
CCR2216-1G-12XS-2XQ | Marvell-98DX8525 | 2000MHz | 16 | - | - | - | 12 | - | 2 | 1024 | 128,000 | 9570 |
For L3 hardware offloading feature support and hardware limits, please refer to Feature Support and Device Support user manuals.
Abbreviations
- FDB - Forwarding Database
- MDB - Multicast Database
- SVL - Shared VLAN Learning
- IVL - Independent VLAN Learning
- PVID - Port VLAN ID
- ACL - Access Control List
- CVID - Customer VLAN ID
- SVID - Service VLAN ID
Port switching
To set up a port switching, check the Bridge Hardware Offloading page.
Currently, it is possible to create only one bridge with hardware offloading. Use the hw=yes/no
parameter to select which bridge will use hardware offloading.
Bridge STP/RSTP/MSTP, IGMP Snooping, and VLAN filtering settings don't affect hardware offloading, Bonding interfaces are also hardware offloaded.
VLAN
The bridge provides VLAN-aware Layer 2 forwarding and VLAN tag modifications. This set of features makes bridge operation more akin to a traditional Ethernet switch, allowing it to overcome Spanning Tree compatibility issues compared to configurations where tunnel-like VLAN interfaces are bridged. Configuring Bridge VLAN Filtering is highly recommended to comply with STP (802.1D) and RSTP (802.1w) standards, and enabling MSTP (802.1s) support in RouterOS is mandatory.
VLAN Filtering
VLAN filtering is described in the Bridge VLAN Filtering section.
VLAN setup examples
Some of the most common ways how to utilize VLAN forwarding:
Port-Based VLAN
The configuration is described in the Bridge VLAN Filtering section.
MAC Based VLAN
- The Switch Rule table is used for MAC Based VLAN functionality, see this table on how many rules each device supports.
- MAC-based VLANs will only work properly between switch ports and not between switch ports and CPU. When a packet is being forwarded to the CPU, the
pvid
property of the bridge port will be always used instead ofnew-vlan-id
from ACL rules. - MAC-based VLANs will not work for DHCP packets when DHCP snooping is enabled.
Enable switching on ports by creating a bridge with enabled hw-offloading:
/interface bridge add name=bridge1 vlan-filtering=yes /interface bridge port add bridge=bridge1 interface=ether2 hw=yes add bridge=bridge1 interface=ether7 hw=yes
Add VLANs in the Bridge VLAN table and specify ports:
/interface bridge vlan add bridge=bridge1 tagged=ether2 untagged=ether7 vlan-ids=200,300,400
Add Switch rules that assign VLAN ID based on MAC address:
/interface ethernet switch rule add switch=switch1 ports=ether7 src-mac-address=A4:12:6D:77:94:43/FF:FF:FF:FF:FF:FF new-vlan-id=200 add switch=switch1 ports=ether7 src-mac-address=84:37:62:DF:04:20/FF:FF:FF:FF:FF:FF new-vlan-id=300 add switch=switch1 ports=ether7 src-mac-address=E7:16:34:A1:CD:18/FF:FF:FF:FF:FF:FF new-vlan-id=400
Protocol Based VLAN
- The Switch Rule table is utilized for Protocol-based VLAN functionality. Refer to this table to determine the number of rules each device supports.
- Protocol-based VLANs will only function correctly between switch ports and not between switch ports and the CPU. When a packet is forwarded to the CPU, the
pvid
property of the bridge port will always be used instead of thenew-vlan-id
from ACL rules. - Protocol-based VLANs will not function for DHCP packets when DHCP snooping is enabled.
Enable switching on ports by creating a bridge with enabled hw-offloading:
/interface bridge add name=bridge1 vlan-filtering=yes /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 VLANs in the Bridge VLAN table and specify ports:
/interface bridge vlan add bridge=bridge1 tagged=ether2 untagged=ether6 vlan-ids=200 add bridge=bridge1 tagged=ether2 untagged=ether7 vlan-ids=300 add bridge=bridge1 tagged=ether2 untagged=ether8 vlan-ids=400
Add Switch rules that assign VLAN ID based on MAC protocol:
/interface ethernet switch rule add mac-protocol=ip new-vlan-id=200 ports=ether6 switch=switch1 add mac-protocol=ipx new-vlan-id=300 ports=ether7 switch=switch1 add mac-protocol=0x80F3 new-vlan-id=400 ports=ether8 switch=switch1
VLAN Tunneling (Q-in-Q)
It is possible to use a provider bridge (IEEE 802.1ad) Tag Stacking VLAN filtering, and hardware offloading simultaneously. The configuration for this is outlined in the Bridge VLAN Tunneling (Q-in-Q) section.
Devices equipped with switch chip Marvell-98DX3257 (e.g. CRS354 series) do not support VLAN filtering on 1Gbps Ethernet interfaces for other VLAN types (0x88a8
and 0x9100
).
Ingress VLAN translation
It is possible to translate a certain VLAN ID to a different VLAN ID using ACL rules on an ingress port. In this example, we create two ACL rules, allowing bidirectional communication. This can be done by following these steps:
1) Create a new bridge and add ports to it with hardware offloading:
/interface bridge add name=bridge1 vlan-filtering=no /interface bridge port add interface=ether1 bridge=bridge1 hw=yes add interface=ether2 bridge=bridge1 hw=yes
2) Add ACL rules to translate a VLAN ID in each direction:
/interface ethernet switch rule add new-dst-ports=ether2 new-vlan-id=20 ports=ether1 switch=switch1 vlan-id=10 add new-dst-ports=ether1 new-vlan-id=10 ports=ether2 switch=switch1 vlan-id=20
3) Add both VLAN IDs to the bridge VLAN table:
/interface bridge vlan add bridge=bridge1 tagged=ether1 vlan-ids=10 add bridge=bridge1 tagged=ether2 vlan-ids=20
4) Enable bridge VLAN filtering:
/interface bridge set bridge1 vlan-filtering=yes
Bidirectional communication is limited only between two switch ports. Translating VLAN ID between more ports can cause traffic flooding or incorrect forwarding between the same VLAN ports.
By enabling vlan-filtering
you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port.
(R/M)STP
CRS3xx, CRS5xx series switches, CCR2116, and CCR2216 routers are capable of running STP, RSTP, and MSTP on a hardware level. For more detailed information you should check out the Spanning Tree Protocol manual page.
Bonding
CRS3xx, CRS5xx series switches, and CCR2116, CCR2216 routers support hardware offloading with bonding interfaces. Only 802.3ad
and balance-xor
bonding modes are hardware offloaded, other bonding modes will use the CPU's resources. You can find more information about the bonding interfaces in the Bonding Interface section. If 802.3ad
mode is used, then LACP (Link Aggregation Control Protocol) is supported.
To create a hardware offloaded bonding interface, you must create a bonding interface with a supported bonding mode:
/interface bonding add mode=802.3ad name=bond1 slaves=ether1,ether2
This interface can be added to a bridge alongside other interfaces:
/interface bridge add name=bridge /interface bridge port add bridge=bridge interface=bond1 hw=yes add bridge=bridge interface=ether3 hw=yes add bridge=bridge interface=ether4 hw=yes
Do not add interfaces to a bridge that are already in a bond, RouterOS will not allow you to add an interface to a bridge that is already a slave port for bonding.
Make sure that the bonding interface is hardware offloaded by checking the "H" flag:
/interface bridge port print Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload # INTERFACE BRIDGE HW 0 H bond1 bridge yes 1 H ether3 bridge yes 2 H ether4 bridge yes
With HW-offloaded bonding interfaces, the built-in switch chip will always use Layer2+Layer3+Layer4 for a transmit hash policy, changing the transmit hash policy manually will have no effect.
Multi-chassis Link Aggregation Group
MLAG (Multi-chassis Link Aggregation Group) implementation in RouterOS allows configuring LACP bonds on two separate devices, while the client device believes to be connected to the same machine. This provides a physical redundancy in case of switch failure. All CRS3xx, CRS5xx series, and CCR2116, CCR2216 devices can be configured with MLAG. Read here for more information.
L3 Hardware Offloading
Layer3 hardware offloading, also known as IP switching or HW routing, enables the offloading of certain router features onto the switch chip. This capability allows for achieving wire speeds when routing packets, a feat that would not be possible with just the CPU alone.
The offloaded feature set depends on the used chipset. For more information, please refer to the documentation provided here.
Port isolation
It is possible to create a Private VLAN setup, an example can be found in the Switch chip port isolation manual page. Hardware offloaded bonding interfaces are not included in the switch port-isolation menu, but it is still possible to configure port-isolation individually on each secondary interface of the bonding.
Port isolation can be used with a VLAN-filtering bridge and it is possible to isolate ports that are members of the same VLAN. The isolation works per port, it is not possible to isolate ports per VLAN.
IGMP/MLD Snooping
CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers can use IGMP/MLD Snooping on a hardware level. For more detailed information, you should check out the IGMP/MLD snooping manual page.
DHCP Snooping and DHCP Option 82
CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers can use DHCP Snooping with Option 82 on a hardware level. The switch will create a dynamic ACL rule to capture the DHCP packets and redirect them to the main CPU for further processing. To see more detailed information, please visit the DHCP Snooping and DHCP Option 82 manual page.
DHCP snooping will not work when hardware offloading bonding interfaces are created.
Controller Bridge and Port Extender
Controller Bridge (CB) and Port Extender (PE) is an IEEE 802.1BR standard implementation in RouterOS. It allows virtually extending the CB ports with a PE device and managing these extended interfaces from a single controlling device. Such configuration provides a simplified network topology, flexibility, increased port density, and ease of manageability. See more details on the Controller Bridge and Port Extender manual.
Mirroring
Mirroring allows the switch to intercept all traffic passing through the switch chip and send a copy of those packets to another designated port (mirror-target). This feature facilitates the creation of a tap device, enabling network traffic inspection on a traffic analyzer device. You can configure simple port-based mirroring or more complex mirroring based on various parameters. Note that the mirror-target port must belong to the same switch (you can identify which port belongs to which switch in the /interface ethernet menu). Additionally, the mirror-target port can be set to a special value 'cpu', indicating that sniffed packets will be forwarded to the switch chip's CPU port. There are several methods to mirror specific traffic, and below are some of the most common mirroring examples:
Port Based Mirroring:
/interface ethernet switch set switch1 mirror-source=ether2 mirror-target=ether3
Property mirror-source
will send an ingress and egress packet copies to the mirror-target
port. Both mirror-source
and mirror-target
are limited to a single interface.
/interface ethernet switch set switch1 mirror-source=none mirror-target=ether3 /interface ethernet switch rule add mirror=yes ports=ether1,ether2 switch=switch1
Using ACL rules, it is possible to mirror packets from multiple ports
interfaces. Only ingress packets are mirrored to mirror-target
interface.
VLAN Based Mirroring:
/interface bridge set bridge1 vlan-filtering=yes /interface ethernet switch set switch1 mirror-target=ether3 mirror-source=none /interface ethernet switch rule add mirror=yes ports=ether1 switch=switch1 vlan-id=11
By enabling vlan-filtering
you will be filtering out traffic destined for the CPU, before enabling VLAN filtering you should make sure that you set up a Management port.
MAC Based Mirroring:
/interface ethernet switch set switch1 mirror-target=ether3 mirror-source=none /interface ethernet switch rule add mirror=yes ports=ether1 switch=switch1 dst-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF add mirror=yes ports=ether1 switch=switch1 src-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF
Protocol Based Mirroring:
/interface ethernet switch set switch1 mirror-target=ether3 mirror-source=none /interface ethernet switch rule add mirror=yes ports=ether1 switch=switch1 mac-protocol=ipx
IP Based Mirroring:
/interface ethernet switch set switch1 mirror-target=ether3 mirror-source=none /interface ethernet switch rule add mirror=yes ports=ether1 switch=switch1 src-address=192.168.88.0/24 add mirror=yes ports=ether1 switch=switch1 dst-address=192.168.88.0/24
There are other options as well, check the ACL section to find out all possible parameters that can be used to match packets.
Traffic Shaping
It is possible to limit ingress traffic that matches certain parameters with ACL rules and it is possible to limit ingress/egress traffic per port basis. The policer is used for ingress traffic, the shaper is used for egress traffic. The ingress policer controls the received traffic with packet drops. Everything that exceeds the defined limit will get dropped. This can affect the TCP congestion control mechanism on end hosts and the achieved bandwidth can be actually less than defined. The egress shaper tries to queue packets that exceed the limit instead of dropping them. Eventually, it will also drop packets when the output queue gets full, however, it should allow for better utilization of the defined throughput.
Port-based traffic police and shaper:
/interface ethernet switch port set ether1 ingress-rate=10M egress-rate=5M
MAC-based traffic policer:
/interface ethernet switch rule add ports=ether1 switch=switch1 src-mac-address=64:D1:54:D9:27:E6/FF:FF:FF:FF:FF:FF rate=10M
VLAN-based traffic policer:
/interface bridge set bridge1 vlan-filtering=yes /interface ethernet switch rule add ports=ether1 switch=switch1 vlan-id=11 rate=10M
By enabling vlan-filtering
you will be filtering out traffic destined to the CPU, before enabling VLAN filtering you should make sure that you set up a Management port.
Protocol-based traffic policer:
/interface ethernet switch rule add ports=ether1 switch=switch1 mac-protocol=ipx rate=10M
There are other options as well, check the ACL section to find out all possible parameters that can be used to match packets.
The Switch Rule table is used for QoS functionality, see this table for how many rules each device supports.
Traffic Storm Control
A traffic storm can emerge when certain frames are continuously flooded on the network. For example, if a network loop has been created and no loop avoidance mechanisms are used (e.g. Spanning Tree Protocol), broadcast or multicast frames can quickly overwhelm the network, causing degraded network performance or even complete network breakdown. With CRS3xx, CRS5xx series switches and CCR2116, CCR2216 routers it is possible to limit broadcast, unknown multicast, and unknown unicast traffic. Unknown unicast traffic is considered when a switch does not contain a host entry for the destined MAC address. Unknown multicast traffic is considered when a switch does not contain a multicast group entry in the /interface bridge mdb
menu. Storm control settings should be applied to ingress ports, the egress traffic will be limited.
The storm control parameter is specified in percentage (%) of the link speed. If your link speed is 1Gbps, then specifying storm-rate
as 10
will allow only 100Mbps of broadcast, unknown multicast, and/or unknown unicast traffic to be forwarded.
Sub-menu: /interface ethernet switch port
Property | Description |
---|---|
limit-broadcasts (yes | no; Default: yes) | Limit broadcast traffic on a switch port. |
limit-unknown-multicasts (yes | no; Default: no) | Limit unknown multicast traffic on a switch port. |
limit-unknown-unicasts (yes | no; Default: no) | Limit unknown unicast traffic on a switch port. |
storm-rate (integer 0..100; Default: 100) | The amount of broadcast, unknown multicast, and/or unknown unicast traffic is limited to a percentage of the link speed. |
Devices with Marvell-98DX3236 switch chip cannot distinguish unknown multicast traffic from all multicast traffic. For example, CRS326-24G-2S+ will limit all multicast traffic when limit-unknown-multicasts
and storm-rate
is used. For other devices, for example, CRS317-1G-16S+ the limit-unknown-multicasts
parameter will limit only unknown multicast traffic (addresses that are not present in /interface bridge mdb).
For example, to limit 1% (10Mbps) of broadcast and unknown unicast traffic on ether1 (1Gbps), use the following commands:
/interface ethernet switch port set ether1 storm-rate=1 limit-broadcasts=yes limit-unknown-unicasts=yes
MPLS hardware offloading
It is possible to offload certain MPLS functions to the switch chip, the switch must be a (P)rovider router in a PE-P-PE setup in order to achieve hardware offloading. A setup example can be found in the Basic MPLS setup example manual page. The hardware offloading will only take place when LDP interfaces are configured as physical switch interfaces (e.g. Ethernet, SFP, SFP+).
Currently only CRS317-1G-16S+
and CRS309-1G-8S+
using RouterOS v6.41 and newer are capable of hardware offloading certain MPLS functions. CRS317-1G-16S+
and CRS309-1G-8S+
built-in switch chip is not capable of popping MPLS labels from packets, in a PE-P-PE setup you either have to use explicit null or disable TTL propagation in the MPLS network to achieve hardware offloading.
The MPLS hardware offloading has been removed since RouterOS v7.
Switch Rules (ACL)
Access Control List contains an ingress policy engine. See this table on how many rules each device supports. It is an advanced tool for wire-speed packet filtering, forwarding, and modifying based on Layer2, Layer3, and Layer4 protocol header field conditions.
ACL rules are checked for each received packet until a match has been found. If multiple rules can match, then only the first rule will be triggered. A rule without any action parameters is a rule to accept the packet.
It is not required to set mac-protocol
to certain IP version when using L3 or L4 matchers, however, it is recommended to set the mac-protocol=ip
or mac-protocol=ipv6
when filtering any IP packets.
When switch ACL rules are modified (e.g. added, removed, disabled, enabled, or moved), the existing switch rules will be inactive for a short time. This can cause some packet leakage during the ACL rule modifications.
Sub-menu: /interface ethernet switch rule
Property | Description |
---|---|
copy-to-cpu (no | yes; Default: no) | Clones the matching packet and sends it to the CPU. |
disabled (yes | no; Default: no) | Enables or disables ACL entry. |
dscp (0..63) | Matching the DSCP field of the packet (only applies to IPv4 packets). |
dst-address (IP address/Mask) | Matching destination IPv4 address and mask, also matches the destination IP in ARP packets. |
dst-address6 (IPv6 address/Mask) | Matching destination IPv6 address and mask. |
dst-mac-address (MAC address/Mask) | Matching destination MAC address and mask. |
dst-port (0..65535) | Matching destination protocol port number (applies to IPv4 and IPv6 packets if mac-protocol is not specified). |
flow-label (0..1048575) | Matching IPv6 flow label. |
mac-protocol (802.2 | arp | homeplug-av | ip | ipv6 | ipx | lldp | loop-protect | mpls-multicast | mpls-unicast | packing-compr | packing-simple | pppoe | pppoe-discovery | rarp | service-vlan | vlan | or 0..65535 | or 0x0000-0xffff) | Matching particular MAC protocol specified by protocol name or number |
mirror (no | yes) | Clones the matching packet and sends it to the mirror-target port. |
new-dst-ports (ports) | Changes the destination port as specified. An empty setting will drop the packet. A specified port will redirect the packet to it. When the parameter is not used, the packet will be accepted. Multiple "new-dst-ports" are not supported. |
new-vlan-id (0..4095) | Changes the VLAN ID to the specified value. Requires vlan-filtering=yes . |
new-vlan-priority (0..7) | Changes the VLAN priority (priority code point). Requires vlan-filtering=yes . |
ports (ports) | Matching ports on which will the rule apply on received traffic. |
protocol (dccp | ddp | egp | encap | etherip | ggp | gre | hmp | icmp | icmpv6 | idpr-cmtp | igmp | ipencap | ipip | ipsec-ah | ipsec-esp | ipv6 | ipv6-frag | ipv6-nonxt | ipv6-opts | ipv6-route | iso-tp4 | l2tp | ospf | pim | pup | rdp | rspf | rsvp | sctp | st | tcp | udp | udp-lite | vmtp | vrrp | xns-idp | xtp | or 0..255) | Matching particular IP protocol specified by protocol name or number. This only applies to IPv4 packets if mac-protocol is not specified. To match certain IPv6 protocols, use the mac-protocol=ipv6 setting. |
rate (0..4294967295) | Sets ingress traffic limitation (bits per second) for matched traffic. |
redirect-to-cpu (no | yes) | Changes the destination port of a matching packet to the CPU. |
src-address (IP address/Mask) | Matching source IPv4 address and mask, also matches the source IP in ARP packets. |
src-address6 (IPv6 address/Mask) | Matching source IPv6 address and mask. |
src-mac-address (MAC address/Mask) | Matching source MAC address and mask. |
src-port (0..65535) | Matching source protocol port number (applies to IPv4 and IPv6 packets if mac-protocol is not specified). |
switch (switch group) | Matching switch group on which will the rule apply. |
traffic-class (0..255) | Matching IPv6 traffic class. |
vlan-id (0..4095) | Matching VLAN ID. Requires vlan-filtering=yes . |
vlan-header (not-present | present) | Matching VLAN header, whether the VLAN header is present or not. Requires vlan-filtering=yes . |
vlan-priority (0..7) | Matching VLAN priority (priority code point). |
Action parameters:
- copy-to-cpu
- redirect-to-cpu
- mirror
- new-dst-ports (can be used to drop packets)
- new-vlan-id
- new-vlan-priority
- rate
Layer2 condition parameters:
- dst-mac-address
- mac-protocol
- src-mac-address
- vlan-id
- vlan-header
- vlan-priority
Layer3 condition parameters:
- dscp
- protocol
- IPv4 conditions:
- dst-address
- src-address
- IPv6 conditions:
- dst-address6
- flow-label
- src-address6
- traffic-class
Layer4 condition parameters:
- dst-port
- src-port
For VLAN related matchers or VLAN related action parameters to work, you need to enable vlan-filtering
on the bridge interface and make sure that hardware offloading is enabled on those ports, otherwise, these parameters will not have any effect.
When bridge interface ether-type
is set to 0x8100
, then VLAN related ACL rules are relevant to frames tagged using regular/customer VLAN (TPID 0x8100), this includes vlan-id
and new-vlan-id
. When bridge interface ether-type
is set to 0x88a8
, then ACL rules are relevant to frames tagged with 802.1ad service tag (TPID 0x88a8).
Port Security
It is possible to limit allowed MAC addresses on a single switch port. For example, to allow 64:D1:54:81:EF:8E MAC address on a switch port, start by switching multiple ports together, in this example 64:D1:54:81:EF:8E is going to be located behind ether1.
Create an ACL rule to allow the given MAC address and drop all other traffic on ether1 (for ingress traffic):
/interface ethernet switch rule add ports=ether1 src-mac-address=64:D1:54:81:EF:8E/FF:FF:FF:FF:FF:FF switch=switch1 add new-dst-ports="" ports=ether1 switch=switch1
Switch all required ports together, disable MAC learning, and disable unknown unicast flooding on ether1:
/interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether1 hw=yes learn=no unknown-unicast-flood=no add bridge=bridge1 interface=ether2 hw=yes
Add a static hosts entry for 64:D1:54:81:EF:8E (for egress traffic):
/interface bridge host add bridge=bridge1 interface=ether1 mac-address=64:D1:54:81:EF:8E
Broadcast traffic will still be sent out from ether1. To limit broadcast traffic flood on a bridge port, you can use the broadcast-flood
parameter to toggle it. Note that some protocols, such as streaming protocols and DHCP, depend on broadcast traffic.
Dual Boot
The “dual boot” feature allows you to choose which operating system you prefer to use on CRS3xx series switches, RouterOS, or SwOS. Device operating system can be changed using:
- Command-line (
/system routerboard settings set boot-os=swos
) - WinBox
- WebFig
- Serial Console
More details about SwOS are described here: SwOS manual
Configuring SwOS using RouterOS
It is possible to load, save, and reset SwOS configuration, as well as upgrade SwOS and set an IP address for the CRS3xx series switches by using RouterOS.
- Save configuration with
/system swos save-config
The configuration will be saved on the same device with "swos.config"
as the filename. Please ensure you downloaded the file from your device, as the configuration file will be removed after a reboot.
- Load configuration with
/system swos load-config
- Change password with
/system swos password
- Reset configuration with
/system swos reset-config
- Upgrade SwOS from RouterOS using
/system swos upgrade
The upgrade command will automatically install the latest available SwOS primary backup version. Ensure that your device has access to the Internet for the upgrade process to work properly. When the device is booted into SwOS, the version number will include the letter "p", indicating a primary backup version. You can then install the latest available SwOS secondary main version from the SwOS "Upgrade" menu.
Property | Description |
---|---|
address-acquisition-mode (dhcp-only | dhcp-with-fallback | static; Default: dhcp-with-fallback) | Changes address acquisition method:
|
allow-from (IP/Mask; Default: 0.0.0.0/0) | IP address or a network from which the switch is accessible. By default, the switch is accessible by any IP address. |
allow-from-ports (name; Default: ) | List of switch ports from which the device is accessible. By default, all ports are allowed to access the switch |
allow-from-vlan (integer: 0..4094; Default: 0) | VLAN ID from which the device is accessible. By default, all VLANs are allowed |
identity (name; Default: Mikrotik) | Name of the switch (used for Mikrotik Neighbor Discovery protocol) |
static-ip-address (IP; Default: 192.168.88.1) | The IP address of the switch in case address-acquisition-mode is either set to dhcp-with-fallback or static . By setting a static IP address, the address acquisition process does not change, which is DHCP with fallback by default. This means that the configured static IP address will become active only when there are no DHCP servers in the same broadcast domain |
See also
MikroTik newsletter
To follow the latest product and software news, make sure to read our newsletters in the blog section.