This article describes supported add-on peripherals for RouterBOARD hardware devices.

Cellular modems

RouterOS v7 supported cellular modems:

• MikroTik modems
• 3rd party modems supported by device class/type:
  
  • MBIM class USB interface 
  • USB-CDC class USB interface
  • RNDIS type USB interface
• 3rd party modem with added support, see modem table below

Please note:

• not all modems are listed in the supported modem table, some may work because modem manufacturers re-use the same hardware IDs and vice versa
  
• customized, localized and locked units may have compatibility issues
• 3rd party modem may require a modem configuration adjustment before it can be used with RouterOS
• mini-PCIe modems with USB3.0 interface installed in mini-PCIe PCIe/USB2.0 enabled slot USB speed must be limited to USB2.0 speed or mini-PCIe shared PCIe/USB3.0 pins isolated. See the picture below table

Cellular modems

/interface lte set [find] modem-init="AT+QSIMDET=0,1"

For some modems with USB3.0 support in some cases USB3.0 pins need to be isolated to ensure correct initialization:

SFP modules

SFP+ modules

• Introduction
  • DNS configuration
  • DNS Cache
  • DNS Static
• DNS over HTTPS (DoH)
  • Known compatible/incompatible DoH services
• Adlist
• Configuration examples:
  • URL based adlist:
  • Locally hosted adlist:

Introduction

Domain Name System (DNS) usually refers to the Phonebook of the Internet. In other words, DNS is a database that links strings (known as hostnames), such as www.mikrotik.com to a specific IP address, such as 159.148.147.196.

A MikroTik router with a DNS feature enabled can be set as a DNS cache for any DNS-compliant client. Moreover, the MikroTik router can be specified as a primary DNS server under its DHCP server settings. When the remote requests are enabled, the MikroTik router responds to TCP and UDP DNS requests on port 53.

When both static and dynamic servers are set, static server entries are preferred, however, it does not indicate that a static server will always be used (for example, previously query was received from a dynamic server, but static was added later, then a dynamic entry will be preferred).

There are several options on how you can manage DNS functionality on your LAN - use public DNS, use the router as a cache, or do not interfere with DNS configuration. Let us take as an example the following setup: Internet service provider (ISP) → Gateway (GW) → Local area network (LAN). The GW is RouterOS based device with the default configuration:

• You do not configure any DNS servers on the "GW" DHCP server network configuration - the device will forward the DNS server IP address configuration received from `ISP` to `LAN` devices;
• You configure DNS servers on the "GW" DHCP server network configuration - the device will give configured DNS servers to `LAN` devices (also "/ip dns set allow-remote-requests=yes" must be enabled);
• "dns-none" configured under DNS servers on "GW" DHCP server network configuration - the device will not forward any of the dynamic DNS servers to `LAN` devices;

DNS configuration

DNS facility is used to provide domain name resolution for the router itself as well as for the clients connected to it.

[admin@MikroTik] > ip dns print         
                      servers: 
              dynamic-servers: 10.155.0.1
               use-doh-server: 
              verify-doh-cert: no
   doh-max-server-connections: 5
   doh-max-concurrent-queries: 50
                  doh-timeout: 5s
        allow-remote-requests: yes
          max-udp-packet-size: 4096
         query-server-timeout: 2s
          query-total-timeout: 10s
       max-concurrent-queries: 100
  max-concurrent-tcp-sessions: 20
                   cache-size: 2048KiB
                cache-max-ttl: 1d
                   cache-used: 48KiB

Dynamic DNS servers are obtained from different facilities available in RouterOS, for example, DHCP client, VPN client, IPv6 Router Advertisements, etc. 

Servers are processed in a queue order - static servers as an ordered list, dynamic servers as an ordered list. When DNS cache has to send a request to the server, it tries servers one by one until one of them responds. After that this server is used for all types of DNS requests. Same server is used for any types of DNS requests, for example, A and AAAA types. If you use only dynamic servers, then the DNS returned results can change after reboot, because servers can be loaded into IP/DNS settings in a different order due to a different speeds on how they are received from facilities mentioned above.

If at some point the server which was being used becomes unavailable and can not provide DNS answers, then the DNS cache restarts the DNS server lookup process and goes through the list of specified servers once more.

DNS Cache

This menu provides two lists with DNS records stored on the server:

• "/ip dns cache": this menu provides a list with cache DNS entries that RouterOS cache can reply with to client requests ;
• "/ip dns cache all": This menu provides a complete list with all cached DNS records stored including also, for example, PTR records.

DNS Static

The MikroTik RouterOS DNS cache has an additional embedded DNS server feature that allows you to configure multiple types of DNS entries that can be used by the DNS clients using the router as their DNS server. This feature can also be used to provide false DNS information to your network clients. For example, resolving any DNS request for a certain set of domains (or for the whole Internet) to your own page.

[admin@MikroTik] /ip dns static add name=www.mikrotik.com address=10.0.0.1

The server is also capable of resolving DNS requests based on POSIX basic regular expressions so that multiple requests can be matched with the same entry. In case an entry does not conform with DNS naming standards, it is considered a regular expression. The list is ordered and checked from top to bottom. Regular expressions are checked first, then the plain records.

Use regex to match DNS requests:

[admin@MikroTik] /ip dns static add regexp="[*mikrotik*]" address=10.0.0.2

If DNS static entries list matches the requested domain name, then the router will assume that this router is responsible for any type of DNS request for the particular name. For example, if there is only an "A" record in the list, but the router receives an "AAAA" request, then it will reply with an "A" record from the static list and will query the upstream server for the "AAAA" record. If a record exists, then the reply will be forwarded, if not, then the router will reply with an "ok" DNS reply without any records in it. If you want to override domain name records from the upstream server with unusable records, then you can, for example, add a static entry for the particular domain name and specify a dummy IPv6 address for it "::ffff".

List all of the configured DNS entries as an ordered list:

[admin@MikroTik] /ip/dns/static/print 
Columns: NAME, REGEXP, ADDRESS, TTL
# NAME             REGEXP       ADDRESS   TTL
0 www.mikrotik.com               10.0.0.1  1d 
1                  [*mikrotik*]  10.0.0.2  1d

DNS over HTTPS (DoH)

Starting from RouterOS version v6.47 it is possible to use DNS over HTTPS (DoH). DoH uses HTTPS protocol to send and receive DNS requests for better data integrity. The main goal is to provide privacy by eliminating "man-in-the-middle" attacks (MITM). 

Watch our video about this feature. 

There are various ways to find out what root CA certificate is necessary. The easiest way is by using your WEB browser, navigating to the DoH site, and checking the security of the website. You can download the certificate straight from the browser or fetch the certificate from a trusted source. 

Download the certificate, upload it to your router and import it: 

/certificate import file-name=CertificateFileName

Configure the DoH server: 

/ip dns set use-doh-server=DoH_Server_Query_URL verify-doh-cert=yes

Note that you need at least one regular DNS server configured for the router to resolve the DoH hostname itself. If you do not have any dynamical or static DNS server configured, add a static DNS entry for the DoH server domain name like this: 

/ip dns set servers=1.1.1.1

If you do not have any dynamical or static DNS server configured, add a static DNS entry for the DoH server domain name like this: 

/ip dns static add address=IP_Address name=Domain_Name

Known compatible/incompatible DoH services

Compatible DoH services:

• Cloudflare

• Google

• NextDNS

• OpenDNS

Incompatible DoH services:

• Mullvad

• Yandex

Adlist 

Adlist is an integral component of network-level ad blocking, comprising a curated collection of domain names known for serving advertisements. This feature operates by utilizing Domain Name System (DNS) resolution to intercept requests to these domains. When a client device queries a DNS server for a domain listed on the adlist, the DNS resolution process is altered. Instead of returning the actual IP address of the ad-serving domain, the DNS server responds with the IP address 0.0.0.0. This effectively null-routes the request, as 0.0.0.0 is a non-routable meta-address used to denote an invalid, unknown, or non-applicable target. By redirecting ad-related requests in this manner, the adlist feature ensures that advertisement content is not loaded, enhancing network performance and improving the user experience by reducing unwanted ad traffic.

Configuration examples:

URL based adlist:

/ip/dns/adlist add url=https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts ssl-verify=no

To see how many domain names are present and matched, you can run:

/ip/dns/adlist/print 
Flags: X - disabled 
0 url="https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts" ssl-verify=no match-count=122 name-count=164769

Locally hosted adlist:

To create your adlist, you can create a Txt file with the domains. Example:

0.0.0.0 example1.com
0.0.0.0 eu1.example.com
0.0.0.0 ex.com
0.0.0.0 com.example.com

To add file to adlist :

/ip/dns/adlist/add file=host.txt

/ip/dns/adlist/print 
Flags: X - disabled 
 0   file=host.txt match-count=0 name-count=4 

Scripting language manual

This manual provides an introduction to RouterOS's built-in powerful scripting language.

Scripting host provides a way to automate some router maintenance tasks by means of executing user-defined scripts bounded to some event occurrence.

Scripts can be stored in the Script repository or can be written directly to the console. The events used to trigger script execution include, but are not limited to the System Scheduler, the Traffic Monitoring Tool, and the Netwatch Tool generated events.

If you are already familiar with scripting in RouterOS, you might want to see our Tips & Tricks.

Line structure

The RouterOS script is divided into a number of command lines. Command lines are executed one by one until the end of the script or until a runtime error occurs.

Command-line

The RouterOS console uses the following command syntax:

[prefix] [path] command [uparam] [param=[value]] .. [param=[value]]

• [prefix] - ":" or "/" character which indicates if a command is ICE or path. It may not be required.
• [path] - relative path to the desired menu level. It may not be required.
• command - one of the commands available at the specified menu level.
• [uparam] - unnamed parameter, must be specified if the command requires it.
• [params] - a sequence of named parameters followed by respective values

The end of the command line is represented by the token “;” or NEWLINE. Sometimes “;” or NEWLINE is not required to end the command line.

Single command inside (), [] or {} does not require any end-of-command character. The end of the command is determined by the content of the whole script

:if ( true ) do={ :put "lala" }

Each command line inside another command line starts and ends with square brackets "[ ]" (command concatenation).

:put [/ip route get [find gateway=1.1.1.1]]; 

Notice that the code above contains three command lines:

• :put
• /ip route get
• find gateway=1.1.1.1

Command-line can be constructed from more than one physical line by following line joining rules.

Physical Line

A physical line is a sequence of characters terminated by an end-of-line (EOL) sequence. Any of the standard platform line termination sequences can be used:

• Unix – ASCII LF;
• Windows – ASCII CR LF;
• mac – ASCII CR;

Standard C conventions for newline characters can be used ( the \n character).

Comments

The following rules apply to a comment:

• A comment starts with a hash character (#) and ends at the end of the physical line.
• RouterOS does not support multiline comments.
• If a # character appears inside the string it is not considered a comment.

Example

# this is a comment 
# next line comment
:global a; # another valid comment

:global myStr "part of the string # is not a comment"

Line joining

Two or more physical lines may be joined into logical lines using the backslash character (\).

The following rules apply to using backslash as a line-joining tool:

• A line ending in a backslash cannot carry a comment.
• A backslash does not continue a comment.
• A backslash does not continue a token except for string literals.
• A backslash is illegal elsewhere on a line outside a string literal.

Example

:if ($a = true \
	and $b=false) do={ :put "$a $b"; } 
:if ($a = true \ # bad comment 
	and $b=false) do={ :put "$a $b"; }
# comment \
	continued - invalid (syntax error)

Whitespace between tokens

Whitespace can be used to separate tokens. Whitespace is necessary between two tokens only if their concatenation could be interpreted as a different token. Example:

{  
	:local a true; :local b false;
# whitespace is not required 
	:put (a&&b); 
# whitespace is required  
	:put (a and b); 
}

Whitespace characters are not allowed

• between '<parameter>='
• between 'from=' 'to=' 'step=' 'in=' 'do=' 'else='

Example:

#incorrect: 
:for i from = 1 to = 2 do = { :put $i } 
#correct syntax: 
:for i from=1 to=2 do={ :put $i } 
:for i from= 1 to= 2 do={ :put $i } 

#incorrect 
/ip route add gateway = 3.3.3.3 
#correct 
/ip route add gateway=3.3.3.3

Scopes

Variables can be used only in certain regions of the script called scopes. These regions determine the visibility of the variable. There are two types of scopes - global and local. A variable declared within a block is accessible only within that block and blocks enclosed by it, and only after the point of declaration.

Global scope

Global scope or root scope is the default scope of the script. It is created automatically and can not be turned off.

Local scope

User can define their own groups to block access to certain variables, these scopes are called local scopes. Each local scope is enclosed in curly braces ("{ }").

{  
	:local a 3;
	{  
		:local b 4;  
		:put ($a+$b); 
	} #line below will show variable b in light red color since it is not defined in scope  
	:put ($a+$b); 
}

In the code above variable, b has local scope and will not be accessible after a closing curly brace.

So for example, the defined local variable will not be visible in the next command line and will generate a syntax error

[admin@MikroTik] > :local myVar a;
[admin@MikroTik] > :put $myVar
syntax error (line 1 column 7)

Note that even variable can be defined as global, it will be available only from its scope unless it is not referenced to be visible outside of the scope.

{  
	:local a 3; 
	{  
		:global b 4; 
	}  
	:put ($a+$b); 
}

The code above will output 3, because outside of the scope b is not visible. 

The following code will fix the problem and will output 7:

{  
	:local a 3; 
	{  
		:global b 4; 
	}
	:global b;  
	:put ($a+$b); 
}

Keywords

The following words are keywords and cannot be used as variable and function names:

and       or       in

Delimiters

The following tokens serve as delimiters in the grammar:

()  []  {}  :   ;   $   / 

Data types

RouterOS scripting language has the following data types:

Constant Escape Sequences

Following escape sequences can be used to define certain special characters within a string:

Example

:put "\48\45\4C\4C\4F\r\nThis\r\nis\r\na\r\ntest";

which will show on the display
HELLO
This
is
a
test


Operators

Arithmetic Operators

Usual arithmetic operators are supported in the RouterOS scripting language

Note: for the division to work you have to use braces or spaces around the dividend so it is not mistaken as an IP address

Relational Operators

Logical Operators

Bitwise Operators

Bitwise operators are working on number, IP, and IPv6 address data types.

Calculate the subnet address from the given IP and CIDR Netmask using the "&" operator:

{ 
:local IP 192.168.88.77; 
:local CIDRnetmask 255.255.255.0; 
:put ($IP&$CIDRnetmask); 
}

Get the last 8 bits from the given IP addresses:

 :put (192.168.88.77&0.0.0.255);

Use the "|" operator and inverted CIDR mask to calculate the broadcast address:

{ 
:local IP 192.168.88.77; 
:local Network 192.168.88.0; 
:local CIDRnetmask 255.255.255.0; 
:local InvertedCIDR (~$CIDRnetmask); 
:put ($Network|$InvertedCIDR) 
}

Concatenation Operators

It is possible to add variable values to strings without a concatenation operator:

:global myVar "world"; 

:put ("Hello " . $myVar); 
# next line does the same as above 
:put "Hello $myVar";

By using $[] and $() in the string it is possible to add expressions inside strings:

:local a 5; 
:local b 6; 
:put " 5x6 = $($a * $b)"; 

:put " We have $[ :len [/ip route find] ] routes";

Other Operators

[admin@x86] >:global aaa {a=1;b=2}
[admin@x86] > :put ($aaa->"a")
1
[admin@x86] > :put ($aaa->"b")
2

Variables

The scripting language has two types of variables:

• global - accessible from all scripts created by the current user, defined by global keyword;
• local - accessible only within the current scope, defined by local keyword.

There can be undefined variables. When a variable is undefined, the parser will try to look for variables set, for example, by DHCP lease-script or Hotspot on-login

Every variable, except for built-in RouterOS variables, must be declared before usage by local or global keywords. Undefined variables will be marked as undefined and will result in a compilation error. Example:

# following code will result in compilation error, because myVar is used without declaration 
:set myVar "my value"; 
:put $myVar

Correct code:

:local myVar; 
:set myVar "my value"; 
:put $myVar;

The exception is when using variables set, for example, by DHCP lease-script

/system script 
add name=myLeaseScript policy=\ 
	ftp,reboot,read,write,policy,test,winbox,password,sniff,sensitive,api \ 
	source=":log info \$leaseActIP\r\ 
	\n:log info \$leaseActMAC\r\ 
	\n:log info \$leaseServerName\r\ 
	\n:log info \$leaseBound" 

/ip dhcp-server set myServer lease-script=myLeaseScript

Valid characters in variable names are letters and digits. If the variable name contains any other character, then the variable name should be put in double quotes. Example:

#valid variable name 
:local myVar; 
#invalid variable name 
:local my-var; 
#valid because double quoted 
:global "my-var";

If a variable is initially defined without value then the variable data type is set to nil, otherwise, a data type is determined automatically by the scripting engine. Sometimes conversion from one data type to another is required. It can be achieved using data conversion commands. Example:

#convert string to array 
:local myStr "1,2,3,4,5"; 
:put [:typeof $myStr]; 
:local myArr [:toarray $myStr]; 
:put [:typeof $myArr]

Variable names are case-sensitive.

:local myVar "hello" 
# following line will generate error, because variable myVAr is not defined 
:put $myVAr 
# correct code 
:put $myVar

Set command without value will un-define the variable (remove from environment, new in v6.2)

#remove variable from environment 
:global myVar "myValue" 
:set myVar;

Use quotes on the full variable name when the name of the variable contains operators. Example:

:local "my-Var";
:set "my-Var" "my value";
:put $"my-Var";

Reserved variable names

All built-in RouterOS properties are reserved variables. Variables that will be defined the same as the RouterOS built-in properties can cause errors. To avoid such errors, use custom designations.

For example, the following script will not work:

{ 
:local type "ether1"; 
/interface print where name=$type; 
}

But will work with different defined variables:

 { 
:local customname "ether1"; 
/interface print where name=$customname; 
}

Commands

Global commands

Every global command should start with the ":" token, otherwise, it will be treated as a variable.

{
:local j [:execute {/interface print follow where [:log info ~Sname~]}];
:delay 10s;
:do { /system script job remove $j } on-error={}
}

:if ([/system script job print count-only as-value where script=[:jobname] ] > 1) do={
  :error "script instance already running"
  }

[admin@MikroTik] > :put [:pick "abcde" 1 3]
bc

:retry command={abc} delay=1 max=2 on-error={:put "got error"}
got error

:put [:serialize value=a,b,c to=json]                 
["a","b","c"]

:local test {a=(1,2,3);b=(4,5,6);c=(7,"text",9)}; :put [ :serialize to=dsv delimiter=";" value=$test order=("c","a","b") ]     
c;a;b
7;1;4
text;2;5
9;3;6

:put [:deserialize from=json value="[\"a\",\"b\",\"c\"]"]
a;b;c

[admin@MikroTik] > :put [:timestamp]
2735w21:41:43.481891543
or
[admin@MikroTik] > :put [:timestamp]
2735w1d21:41:43.481891543
with the day offset

Menu specific commands

Common commands

The following commands are available from most sub-menus:

import

The import command is available from the root menu and is used to import configuration from files created by an export command or written manually by hand.

print parameters

Several parameters are available for print command:

More than one parameter can be specified at a time, for example, /ip route print count-only interval=1 where interface="ether1"

Loops and conditional statements

Loops

Conditional statement

Example:

{  
	:local myBool true;  
	:if ($myBool = false) do={ :put "value is false" } else={ :put "value is true" } 
}

Functions

Scripting language does not allow you to create functions directly, however, you could use :parse command as a workaround.

Starting from v6.2 new syntax is added to easier define such functions and even pass parameters. It is also possible to return function value with :return command.

See examples below:

#define function and run it
:global myFunc do={:put "hello from function"}
$myFunc

output:
hello from function

#pass arguments to the function
:global myFunc do={:put "arg a=$a"; :put "arg '1'=$1"} 
$myFunc a="this is arg a value" "this is arg1 value"

output:
arg a=this is arg a value
arg '1'=this is arg1 value

Notice that there are two ways how to pass arguments:

• pass arg with a specific name ("a" in our example)
• pass value without arg name, in such case arg "1", "2" .. "n" is used.

Return example

:global myFunc do={ :return ($a + $b)} 
:put [$myFunc a=6 b=2] 

output: 
8

You can even clone an existing script from the script environment and use it as a function.

#add script
/system script add name=myScript source=":put \"Hello $myVar !\""

:global myFunc [:parse [/system script get myScript source]]
$myFunc myVar=world

output:
Hello world !

For example:

:global my2 "123" 

:global myFunc do={ :global my2; :put $my2; :set my2 "lala"; :put $my2 } 
$myFunc my2=1234 
:put "global value $my2"

The output will be:

1234
lala
global value 123

Nested function example

Note: to call another function its name needs to be declared (the same as for variables)

:global funcA do={ :return 5 } 
:global funcB do={  
	:global funcA;  
	:return ([$funcA] + 4) 
} 
:put [$funcB] 

Output: 
9

Catch run-time errors

Starting from v6.2 scripting has the ability to catch run-time errors.

For example, the [code]:reslove[/code] command if failed will throw an error and break the script.

[admin@MikroTik] > { :put [:resolve www.example.com]; :put "lala";}
failure: dns name does not exist

Now we want to catch this error and proceed with our script:

:do {  
	:put [:resolve www.example.com]; 
} on-error={ :put "resolver failed"}; 
:put "lala" 

output: 

resolver failed 
lala

Operations with Arrays

Warning: Key name in the array contains any character other than a lowercase character, it should be put in quotes

For example:

[admin@ce0] > {:local a { "aX"=1 ; ay=2 }; :put ($a->"aX")} 
1

Loop through keys and values

"foreach" command can be used to loop through keys and elements:

[admin@ce0] > :foreach k,v in={2; "aX"=1 ; y=2; 5} do={:put ("$k=$v")} 

0=2 
1=5 
aX=1 
y=2

If the "foreach" command is used with one argument, then the element value will be returned:

[admin@ce0] > :foreach k in={2; "aX"=1 ; y=2; 5} do={:put ("$k")} 

2 
5 
1 
2

Note: If the array element has a key then these elements are sorted in alphabetical order, elements without keys are moved before elements with keys and their order is not changed (see example above).

Change the value of a single array element

[admin@MikroTik] > :global a {x=1; y=2}
[admin@MikroTik] > :set ($a->"x") 5 
[admin@MikroTik] > :environment print 
a={x=5; y=2}

Script repository

Sub-menu level: /system script

Contains all user-created scripts. Scripts can be executed in several different ways:

• on event - scripts are executed automatically on some facility events ( scheduler, netwatch, VRRP)
• by another script - running script within the script is allowed
• manually - from console executing a run command or in winbox

Note: Only scripts (including schedulers, netwatch, etc) with equal or higher permission rights can execute other scripts.

Read-only status properties:

Menu specific commands

Environment

Sub-menu level:

• /system script environment
• /environment

Contains all user-defined variables and their assigned values.

[admin@MikroTik] > :global example;
[admin@MikroTik] > :set example 123
[admin@MikroTik] > /environment print  
"example"=123

Read-only status properties:

Job

Sub-menu level: /system script job

Contains a list of all currently running scripts.
Read-only status properties:

See also

• Scripting Examples
• Manual: Scripting Tips and Tricks

MikroTik SFP/SFP+/SFP28/QSFP+/QSFP28 compatibility

This article shows the compatibility of MikroTik devices with SFP, SFP+, SFP28, QSFP+, and QSFP28 transceivers. It features detailed compatibility tables that provide valuable insights into which transceivers are suitable for use with MikroTik devices. Additionally, some practical configuration examples are provided using the RouterOS CLI to set different data transmission rates. For more detailed descriptions of properties, please refer to the Ethernet user manual.

1G SFP

10G SFP+/25G SFP28

40G QSFP+

100G QSFP28

S-RJ01

Table that states in what link rates if mounted in specific MikroTik devices S-RJ01 module will be able to work. Use these modules only with auto-negotiation enabled, forced link speeds are not supported. They will negotiate to correct duplex and highest possible rate.

10 Gigabit Ethernet

S+RJ10

Use these modules only in 10G SFP+ ports with auto-negotiation enabled, forced link speeds and configurable link speed advertisements are not supported. They will negotiate to correct duplex and highest possible rate. For proper S+RJ10 module installation and recommended use case scenarios, please read S+RJ10 General Guidance.

The latest revision of S+RJ10 contains "/r2" by the end of serial number. It comes with following improvements:

• Jumbo frames up to 10218 Bytes at 2.5G, 5G and 10G speeds;
• Actual link speed reporting;
• DDM monitoring (Supply Voltage, Module temperature).

CRS312-4C+8XG

10GE ports maximum supported cable length.

SFP interface compatibility with 100M optical transceivers

SFP interface on the listed devices is compatible with fast ethernet fiber links.

Compatible devices (interface):

• CCR1009-7G-1C (combo1)
• CCR1009-7G-1C-1S+ (combo1)
• CRS106-1C-5S (combo1)
• CRS328-4C-20S-4S+ (combo1 - combo4 and SFP1 - SFP20)
• LHG XL 52 ac
• RBD22/D23/mANTBox 52 15s/NetMetal ac²

SFP+ interface compatibility with 1G optical transceivers

For MikroTik devices with SFP+ interface that support both 10G and 1G link rate, following settings must be set on both linked devices for required interfaces. These settings only relate when optical SFP transceivers are used. In order to get them working in 1G link rate, use the following configuration:

# Since RouterOS v7.12
/interface ethernet set sfp-sfpplus1 auto-negotiation=no speed=1G-baseX

# Older RouterOS
/interface ethernet set sfp-sfpplus1 auto-negotiation=no speed=1Gbps full-duplex=yes 

• auto-negotiation disabled
• port speed 1G
• full-duplex

Devices which SFP+ ports support 1G links:

• CCR2004-1G-12S+2XS - All SFP+ interfaces can be used in 1G mode if required.
• CCR2004-16G-2S+ - All SFP+ interfaces can be used in 1G mode if required.
• CCR1072-1G-8S+ - All SFP+ interfaces can be used in 1G mode if required.
• CCR1036-8G-2S+ - All SFP+ interfaces can be used in 1G mode if required.
• CCR1009-8G-1S-1S+ - All SFP+ interfaces can be used in 1G mode if required.
• CCR1009-7G-1C-1S+ - All SFP+ interfaces can be used in 1G mode if required.
• CSS326-24G-2S+RM - All SFP+ interfaces can be used in 1G mode if required.
• CRS3xx series switches - All SFP+ interfaces can be used in 1G mode if required.
• RB5009 series - SFP+1 interface can be used in 1G mode if required.
• RB4011 series - SFP+1 interface can be used in 1G mode if required.
• CRS226-24G-2S+ - Only SFP+1 supports 1G link speed, SFP+2 is for 10G links only.
• CRS210-8G-2S+ - Only SFP+1 supports 1G link speed, SFP+2 is for 10G links only.
• CSS610 series switches - All SFP+ interfaces can be used in 1G mode if required.

Devices which SFP+ interfaces can be used only for 10G links:

• CCR1016-12S-1S+
• CRS212-1G-10S-1S+

SFP+ interface compatibility with 10G/25G optical transceivers

MikroTik devices with SFP+ ports can establish 10G links using 10G/25G optical fiber transceivers, however additional SFP Rate Select setting must be configured to avoid data corruption during transmission. The following settings are required on the SFP+ interface:

# Since RouterOS v7.12
/interface ethernet set sfp-sfpplus1 auto-negotiation=no speed=10G-baseSR-LR sfp-rate-select=low

# Older RouterOS
/interface ethernet set sfp-sfpplus1 auto-negotiation=no speed=10Gbps full-duplex=yes sfp-rate-select=low

This requirement applies to MikroTik 10G/25G modules:

• XS+31LC10D
• XS+2733LC15D

SFP+/SFP28 interface compatibility with 2.5G transceivers

The 2.5G link rate support is implemented since RouterOS v7.3. MikroTik devices with SFP+ and SFP28 interfaces that support 2.5G link rate require following settings to be set on both linked device interfaces.

# Since RouterOS v7.12
/interface ethernet set sfp-sfpplus1 auto-negotiation=no speed=2.5G-baseX

# Older RouterOS
/interface ethernet set sfp-sfpplus1 auto-negotiation=no speed=2.5Gbps full-duplex=yes

• auto-negotiation disabled
• port speed 2.5G
• full-duplex

Devices which support 2.5G links in SFP/SFP+/SFP28 ports:

• CRS3xx series switches - All SFP+ interfaces can be used in 2.5G mode if required.
• CCR2004-1G-12S+2XS - All SFP+ and SFP28 interfaces can be used in 2.5G mode if required.
• CCR2116-12G-4S+ - All SFP+ interfaces can be used in 2.5G mode if required.
• CRS518-16XS-2XQ - All SFP28 interfaces can be used in 2.5G mode if required.
• CCR2216-1G-12XS-2XQ - All SFP28 interfaces can be used in 2.5G mode if required.
• RB5009 series - SFP+ interface can be used in 2.5G mode if required.
• L009 series - SFP interface can be used in 2.5G mode if required.
• L23 series - SFP interface can be used in 2.5G mode if required.
• RB4011 - SFP interface can be used in 2.5G mode if required.

QSFP+/QSFP28 interface supported link rates

In RouterOS, every QSFP+ and QSFP28 physical interface is divided into four subinterfaces. These subinterfaces correspond to the four transmission lines necessary for the operation of QSFP+ or QSFP28. The first digit after "qsfpplus" or "qsfp28-" indicates the numbering of the QSFP+ or QSFP28 physical interface. The second digit, ranging from 1 to 4, indicates each of the individual lines. Here are some examples of QSFP+ and QSFP28 interface printouts for better understanding:

/interface ethernet print 
Flags: R - RUNNING
Columns: NAME, MTU, MAC-ADDRESS, ARP, SWITCH
 #   NAME            MTU  MAC-ADDRESS        ARP      SWITCH 
 1   qsfpplus1-1    1500  48:8F:5A:B6:09:8C  enabled  switch1
 2   qsfpplus1-2    1500  48:8F:5A:B6:09:8D  enabled  switch1
 3   qsfpplus1-3    1500  48:8F:5A:B6:09:8E  enabled  switch1
 4   qsfpplus1-4    1500  48:8F:5A:B6:09:8F  enabled  switch1

/interface ethernet print 
Flags: R - RUNNING
Columns: NAME, MTU, MAC-ADDRESS, ARP, SWITCH
 #   NAME         MTU  MAC-ADDRESS        ARP      SWITCH 
 1   qsfp28-1-1  1500  DC:2C:6E:9E:11:14  enabled  switch1
 2   qsfp28-1-2  1500  DC:2C:6E:9E:11:15  enabled  switch1
 3   qsfp28-1-3  1500  DC:2C:6E:9E:11:16  enabled  switch1
 4   qsfp28-1-4  1500  DC:2C:6E:9E:11:17  enabled  switch1

The configuration and monitoring of each of these subinterfaces can vary based on factors such as auto-negotiation, advertise, speed configuration and transceiver type (e.g. break-out cable or single fiber). Further paragraphs describes in more detail the QSFP+ and QSFP28 supported rates and correct configuration.

QSFP+ interfaces of MikroTik CRS3xx series devices support following link speeds.

• 1x 40G
• 4x 10G
• 4x 1G

40G links can be established either with autonegotiation or forced 40G speed.
4x 10G and 4x 1G links can be established only with forced speeds and disabled autonegotiation.
In a single link mode only the first QSFP+ subinterface needs to be configured, although rest of the subinterfaces should remain enabled.

Example of forced 1x 40G speed with disabled autonegotiation. Starting from RouterOS version 7.12, in addition to choosing the right transmission rate, it's important to specify the correct link mode. For example, you might use CR4 for Direct Attach Copper (DAC) or SR4-LR4 for an optical module:

# Since RouterOS v7.12
/interface ethernet set qsfpplus1-1 auto-negotiation=no speed=40G-baseCR4
/interface ethernet set qsfpplus2-1 auto-negotiation=no speed=40G-baseSR4-LR4

# Older RouterOS
/interface ethernet set qsfpplus1-1 auto-negotiation=no speed=40Gbps full-duplex=yes

In four link mode all four QSFP+ subinterfaces support configuration of different speeds.

Example of forced 4x 10G speed with disabled autonegotiation:

# Since RouterOS v7.12
/interface ethernet set qsfpplus1-1 auto-negotiation=no speed=10G-baseCR
/interface ethernet set qsfpplus1-2 auto-negotiation=no speed=10G-baseCR
/interface ethernet set qsfpplus1-3 auto-negotiation=no speed=10G-baseCR
/interface ethernet set qsfpplus1-4 auto-negotiation=no speed=10G-baseCR 

# Older RouterOS
/interface ethernet set qsfpplus1-1 auto-negotiation=no speed=10Gbps full-duplex=yes
/interface ethernet set qsfpplus1-2 auto-negotiation=no speed=10Gbps full-duplex=yes
/interface ethernet set qsfpplus1-3 auto-negotiation=no speed=10Gbps full-duplex=yes
/interface ethernet set qsfpplus1-4 auto-negotiation=no speed=10Gbps full-duplex=yes 

QSFP28 interfaces of MikroTik CRS5xx series and CCR2216 devices support following link speeds.

• 1x 100G
• 2x 50G (since RouterOS v7.12)
• 1x 40G
• 4x 25G
• 4x 10G
• 4x 1G

Not supported: 1x 50G, 2x 40G

100G links can be established either with autonegotiation or forced 100G speed.
2x 50G, 1x 40G, 4x 25G, 4x 10G and 4x 1G links can be established only with forced speeds and disabled autonegotiation.
In a single link mode only the first QSFP28 subinterface needs to be configured, although rest of the subinterfaces should remain enabled.

Example of forced 1x 40G speed with disabled autonegotiation. Starting from RouterOS version 7.12, in addition to choosing the right transmission rate, it's important to specify the correct link mode. For example, you might use CR4 for Direct Attach Copper (DAC) or SR4-LR4 for an optical module:

# Since RouterOS v7.12
/interface ethernet set qsfp28-1-1 auto-negotiation=no speed=40G-baseCR4
/interface ethernet set qsfp28-2-1 auto-negotiation=no speed=40G-baseSR4-LR4

# Older RouterOS
/interface ethernet set qsfp28-1-1 auto-negotiation=no speed=40Gbps full-duplex=yes

In four link mode all four QSFP28 subinterfaces support configuration of different speeds.

Example of forced 4x 25G speed with disabled autonegotiation:

# Since RouterOS v7.12
/interface ethernet set qsfp28-1-1 auto-negotiation=no speed=25G-baseCR
/interface ethernet set qsfp28-1-2 auto-negotiation=no speed=25G-baseCR
/interface ethernet set qsfp28-1-3 auto-negotiation=no speed=25G-baseCR
/interface ethernet set qsfp28-1-4 auto-negotiation=no speed=25G-baseCR

# Older RouterOS
/interface ethernet set qsfp28-1-1 auto-negotiation=no speed=25Gbps full-duplex=yes
/interface ethernet set qsfp28-1-2 auto-negotiation=no speed=25Gbps full-duplex=yes
/interface ethernet set qsfp28-1-3 auto-negotiation=no speed=25Gbps full-duplex=yes
/interface ethernet set qsfp28-1-4 auto-negotiation=no speed=25Gbps full-duplex=yes

QSFP+ interface compatibility with QSFP+ to SFP+ breakout cables

MikroTik devices can establish links between QSFP+ and SFP+ ports using breakout cable when following settings are configured on the QSFP+ interface:

# Since RouterOS v7.12
/interface ethernet set qsfpplus1-1 auto-negotiation=no speed=10G-baseCR
/interface ethernet set qsfpplus1-2 auto-negotiation=no speed=10G-baseCR
/interface ethernet set qsfpplus1-3 auto-negotiation=no speed=10G-baseCR
/interface ethernet set qsfpplus1-4 auto-negotiation=no speed=10G-baseCR

# Older RouterOS
/interface ethernet set qsfpplus1-1 auto-negotiation=no speed=10Gbps full-duplex=yes
/interface ethernet set qsfpplus1-2 auto-negotiation=no speed=10Gbps full-duplex=yes
/interface ethernet set qsfpplus1-3 auto-negotiation=no speed=10Gbps full-duplex=yes
/interface ethernet set qsfpplus1-4 auto-negotiation=no speed=10Gbps full-duplex=yes

• auto-negotiation disabled
• port speed 10G
• full-duplex

Summary

Sub-menu: /interface ethernet poe

This page describes how PoE-Out (Power over Ethernet) feature can be used on MikroTik devices with at least one PoE-Out interface. MikroTik uses RJ45 mode B pinout for power distribution, where the PoE is passed trough pins 4,5 (+) and 7,8 (-). If a device supports powering other devices using PoE-out, then it is recommended to use at least 18V as the input voltage, except for devices that support multiple output voltages (e.g. CRS112-8P-4S-IN, CRS328-24P-4S+RM, CRS354-48P-4S+2Q+RM).

MikroTik supported PoE-Out standards

MikroTik devices can support some or all of the following PoE standards:

• Passive PoE-Out up to 30 V - PoE standard, which does not require negotiation between PSE (Power Sourcing Equipment) and PD (Powered Device). PoE-out uses the same voltage as supplied to the PSE (Power Sourcing Equipment). PoE-Out Standard for devices that supports input voltage up to 30 V. PD resistance should have ranged from 3kΩ to 26.5kΩ. (e.g. hEX PoE lite, RB3011UiAS-RM, RB2011iL-IN.)

• Passive PoE-Out up to 57 V - Works the same as low voltage (up to 30 V) PoE-Out, but is also capable to deliver high voltage over PoE ports. The output voltage depends on the power source connected to PSE. Can power up af/at compatible devices, which accepts power over 4,5 (+) and 7,8 (-), and does not require PoE negotiation. PD resistance should have ranged from 3kΩ to 26.5kΩ. (e.g. cAP ac, hAP ac, wsAP ac lite.)

• IEEE Standards 802.3af/at - Also called PoE Type 1/PoE+ Type 2, are PoE standards Defined by the IEEE. The aim of these standards is to reduce incompatibility between vendors. MikroTik PSE with af/at support is capable of powering both a Type 1 and a Type 2 PD. Valid PD should have PoE-In resistance from 23.75kΩ to 26.25kΩ. MikroTik devices that support af/at standard can also switch to Passive PoE-Out mode. (e.g. CRS112-8P-4S-IN, CRS328-24P-4S+RM, CRS354-48P-4S+2Q+RM.)

Each PoE-Out implementation supports overload and short-circuits detection.

How to choose your PoE PSE

This table can help you choose which PSE device is best suitable for your needs.