0% found this document useful (0 votes)

393 views

Mikrotik - Part2

Here are the key steps to detect cable problems on an Ethernet interface: 1. Check the link status using "/interface ethernet monitor <interface>" and ensure there is "no-link". Cable test will only work if the cable is unplugged on the other end. 2. Run the command "/interface ethernet cable-pairs <interface>" to detect any problems. 3. The output will indicate if any of the cable pairs (1, 2, 3, 4, 5, 6, 7, 8) are damaged or broken at a certain length. 4. It will also specify if the problem is a short (cable conductors touching) or open (conductors not connected). 5. This

Uploaded by

Amin Nadaf

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

393 views

Mikrotik - Part2

Uploaded by

Amin Nadaf

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 206

Mikrotik-2013-12-19

General-Featuers

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.
PDF generated at: Thu, 19 Dec 2013 18:53:21 CET

Contents
Articles
Manual:Interface

Manual:Interface/Ethernet

Manual:Interface/Bridge

Manual:Interface/VRRP

Manual:Bonding Examples

Manual:VRRP-examples

Manual:Switch Chip Features

Manual:Maximum Transmission Unit on RouterBoards

Manual:Interface/Wireless

Manual:Wireless AP Client

Manual:Wireless Station Modes

Manual:Nv2

Manual:WMM

Manual:Spectral scan

Manual:Wireless Advanced Channels

Manual:Interface/HWMPplus

Manual:Making a simple wireless AP

106

Manual:Wireless FAQ

109

Manual:Wireless Debug Logs

113

Manual:Interface/VLAN

117

Manual:IP/IPsec

123

Manual:Interface/EoIP

145

Manual:Interface/Gre

148

Manual:Interface/IPIP

150

Manual:Interface/PPP

152

Manual:Interface/PPPoE

153

Manual:Interface/PPTP

164

Manual:Interface/L2TP

170

Manual:Interface/SSTP

177

Manual:Interface/OVPN

187

Manual:BCP bridging (PPP tunnel bridging)

190

Manual:MLPPP over single and multiple links

198

References

Article Sources and Contributors

201

Image Sources, Licenses and Contributors

202

Manual:Interface

Manual:Interface
Applies to RouterOS: v3, v4 +

Sub Categories
List of reference sub-pages

Case studies

List of examples

<splist showparent=yes />

Summary
Sub-menu: /interface
MikroTik RouterOS supports a variety of Network Interface Cards as well as virtual interfaces (like Bonding,
Bridge, VLAN etc.). Each of them has its own submenu, but common properties of all interfaces can be configured
and read in general interface menu.

Properties
Property

Description

l2mtu (integer; Default: ) Layer2 Maximum transmission unit. Note that this property can not be configured on all interfaces. Read more>>
mtu (integer; Default: )

Layer3 Maximum transmission unit

name (string; Default: )

Name of an interface

Read-only properties
Property

Description

bytes (integer/integer)

Total received and transmitted bytes by interface since startup. Read more>>

drops (integer/integer)

packets not sent/received because interface queue is full (no free descriptors), dma engine overrun/underrun. Read
more>>

dynamic (yes|no)

Whether interface is dynamically created

errors (integer/integer) Packets received with some kind of error or not transimitted because of some error. Read more>>
packets
(integer/integer)

Total count of packets on interface since startup. Read more>>

running (yes|no)

Whether interface is running. Note that some interface does not have running check and they are always reported as
"running"

slave (yes|no)

Whether interface is configured as a slave of another interface (for example Bonding)

dynamic (yes|no)

Whether interface is dynamically created

type (string)

Type of an interface (ethernet, wireless, etc.)

Manual:Interface

Traffic monitor
The traffic passing through any interface can be monitored using following command:
/interface monitor-traffic [id | name]
For example monitor ether2 and aggregate traffic. Aggregate is used to monitor total ammount of traffic handled
by the router:
[maris@maris_main] > /interface monitor-traffic ether2,aggregate
rx-packets-per-second: 9
14
rx-drops-per-second: 0
0
rx-errors-per-second: 0
0
rx-bits-per-second: 6.6kbps 10.2kbps
tx-packets-per-second: 9
12
tx-drops-per-second: 0
0
tx-errors-per-second: 0
0
tx-bits-per-second: 13.6kbps 15.8kbps

Stats
RouterOS v3.22 introduces a new command:
/interface print stats
This command prints total packets, bytes, drops and errors.
All interfaces that support this feature will be displayed. Some interfaces are not supporting Error and Drop counters
at the moment (RB4XX except RB450G ether 2-5), these devices will not display these counters.
Traffic monitor now also displays errors per second, in addition to the usual stats:
/interface monitor-traffic
/interface ethernet print stats will display all kinds of other statistics if the interface is supporting
them (currently only RB450G ether2-ether5 and also RB750 ether2-ether5).
[ Top | Back to Content ]

Manual:Interface/Ethernet

Manual:Interface/Ethernet
Applies to RouterOS: v3, v4+

Summary
Sub-menu: /interface ethernet
Standards: IEEE 802.3 [1]
MikroTik RouterOS supports various types of Ethernet interfaces.

Properties
Property

Description

arp (disabled | enabled | proxy-arp |

reply-only; Default: enabled)

Address Resolution Protocol mode

auto-negotiation (yes | no; Default:

yes)

When enabled, the interface "advertises" its maximum capabilities to achieve the best connection
possible.
Note: Auto-negotiation must be disabled on both ends, otherwise Ethernets may not work properly.
Note2: Gigabit link cannot work with auto-negotiation disabled.

bandwidth (integer/integer; Default:

unlimited/unlimited)

Sets max rx/tx bandwidth that will be handled by an interface.

cable-setting (default | short |

standard; Default: default)

changes the cable length setting (only applicable to NS DP83815/6 cards)

disable-running-check (yes | no;

Default: yes)

Disable running check. If this value is set to 'no', the router automatically detects whether the NIC is
connected with a device in the network or not. By default value is 'yes' because older NICs does not
support it. (only applicable to x86)

full-duplex (yes | no; Default: yes)

Defines whether the transmission of data appears in two directions simultaneously

l2mtu (integer; Default: )

Layer2 Maximum transmission unit. Read more>>

mac-address (MAC; Default: )

Media Access Control number of an interface.

master-port (name | none; Default:

none)

Sets switch group master interface

mdix-enable (yes | no; Default: )

Whether the MDI/X auto crosscable correction feature is enabled for the port

mtu (integer; Default: 1500)

Layer3 Maximum transmission unit

name (string; Default: )

Name of an interface

speed (10Mbps | 100Mbps | 1Gbps;

Default: max available)

Sets the data transmission speed of the interface. By default, this value is the maximal data rate
supported by the interface

poe-out (auto-on | forced-on | off;

Default: off)

Poe Out settings. Read more >>

Manual:Interface/Ethernet

Property

Description

running (yes | no)

Whether interface is running. Note that some interface does not have running check and they are always reported as
"running"

rx-1024-1518 (integer)

Total count of received 1024 to 1518 byte packets

rx-128-255 (integer)

Total count of received 128 to 255 byte packets

rx-1519-max (integer)

Total count of received packets larger than 1519 bytes

rx-256-511 (integer)

Total count of received 256 to 511 byte packets

rx-512-1023 (integer)

Total count of received 512 to 1023 byte packets

rx-64 (integer)

Total count of received 64 byte packets

rx-65-127 (integer)

Total count of received 65 to 127 byte packets

rx-align-error
(integer)

Total count of received align error messages

rx-broadcast (integer)

Total count of received broadcast packets

rx-bytes (integer)

Total count of received bytes

rx-fcs-error (integer)

Total count of received frames with incorrect checksum

rx-fragment (integer)

Total count of received fragmented frames

rx-multicast (integer)

Total count of received multicast packets

rx-overflow (integer)
rx-pause (integer)

Amount of received pause frames

rx-runt (integer)

Amount of received frames shorter than the minimum 64 bytes but with a valid CRC

rx-too-long (integer)
slave (yes | no)

Whether interface is configured as a slave of another interface (for example Bonding)

switch (integer)

ID to which switch chip interface belongs to.

tx-1024-1518 (integer)
tx-128-255 (integer)
tx-1519-max (integer)
tx-256-511 (integer)
tx-512-1023 (integer)
tx-64 (integer)
tx-65-127 (integer)
tx-align-error
(integer)
tx-broadcast (integer)
tx-bytes (integer)
tx-fcs-error (integer)
tx-fragment (integer)
tx-multicast (integer)
tx-overflow (integer)
tx-pause (integer)
tx-runt (integer)

Manual:Interface/Ethernet

tx-too-long (integer)

Menu specific commands

Property

Description

blink ([id, name])

Blink Ethernet leds

monitor ([id, name])

Monitor ethernet status. Read more>>

reset-counters ([id, name]) Reset stats counters. Read more>>

reset-mac ([id, name])

Reset MAC address to manufacturers default.

cable-pairs (string)

Shows detected problems with cable pairs. Read More >>

Monitor
/interface ethernet monitor command prints out current link, rate and duplex status of an interface.
Properties:
Property
auto-negotiation (done | incomplete)

Description
Current auto negotiation status:

done-negotiation completed
incomplete-negotiation failed or not yet completed

default-cable-settings (short | standard) Default cable length setting (only applicable to NS DP83815/6 cards)

short-support short cables

standard-support standard cables

full-duplex (yes | no)

Whether transmission of data occurs in two directions simultaneously

rate (10Mbps | 100Mbps | 1Gbps)

Actual data rate of the connection.

status (link-ok | no-link | unknown)

Current link status of an interface

phy-regs ()

link-ok-the card is connected to the network

no-link-the card is not connected to the network
unknown-the connection is not recognized (if the card does not report connection status)

List of Ethernet PHY registers

Example output of ethernet status:

[admin@MikroTik] /interface ethernet> monitor ether1
status: link-ok
auto-negotiation: done
rate: 1Gbps
full-duplex: yes

Manual:Interface/Ethernet

Detect Cable Problems

In RouterOS v6rc4 and newer releases there is ability to see if there are any problems with connected cables. Cable
test can detect problems or measure the cable length only if cable is unplugged on the other end and there is
"no-link". RouterOS will tell:
which cable pair is damaged
at what length is the cable broken
how is the cable broken - shorted or torn
This also works if the other end is simply unplugged - in that case, simply the cable length will be shown.
This works on SXT-G, SXT Lite, RB711G, RB2011, RB750 series and other devices with the same switch chips,
and also the Cloud Core series devices.
Here is example output:
[admin@CCR] > interface ethernet cable-test ether1
name: ether1
status: no-link
cable-pairs: open:4,open:4,open:4,open:4
In the above example, cable is not shorted but cut open at 4 meters length, all cable pairs equally at same location.

Stats
RouterOS v3.22 introduces a new command:
/interface ethernet print stats
This command will display all kinds of other statistics if the interface is supporting them (currently only RB450G
ether2-ether5, RB750 ether2-ether5, RB750G ether1-ether5 and also RB1100 ether1-ether10). Complete list of
properties can be found in section above
For example, output of ethernet stats on RB450G:
[admin@MikroTik] /interface ethernet> print stats
name: ether1-gateway ether2-local ether3-local ether4-local ether5-local
rx-broadcast:

3666

rx-pause:

rx-multicast:

1423

rx-fcs-error:

rx-align-error:

rx-runt:

rx-fragment:

rx-64:

rx-65-127:

21598

rx-128-255:

rx-256-511:

2245

28926

7649

371938

24476

rx-1024-1518:

rx-1519-max:

rx-too-long:

rx-overflow:

15337844

4063737

199738064

12975401

rx-512-1023:

rx-bytes:

Manual:Interface/Ethernet

tx-broadcast:

1496

tx-underrun:

tx-64:

tx-pause:
tx-multicast:

2992

tx-128-255:

tx-65-127:

tx-256-511:

tx-512-1023:

tx-1024-1518:

tx-1519-max:

tx-too-long:

tx-collision:

tx-excessive-collision:

tx-multiple-collision:

tx-single-collision:

tx-excessive-deferred:

tx-deferred:

tx-late-collision:

2561

294712

1576

tx-bytes:

Switch
Sub-menu: /interface ethernet switch
This submenu allows to configure certain RouterBoard switch chip feature. Read more >>.

PoE out
PoE out settings are only available on RouterBOARD devices that have this hardware feature present.
See more here: PoE-Out
[ Top | Back to Content ]

References
[1] http:/ / grouper. ieee. org/ groups/ 802/ 3/

Manual:Interface/Bridge

Manual:Interface/Bridge
Applies to RouterOS: v3, v4+

Summary
Sub-menu: /interface bridge
Standards: IEEE802.1D [1]
Ethernet-like networks (Ethernet, Ethernet over IP, IEEE802.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 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 (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 network from functioning normally, as they would lead to avalanche-like packet multiplication. Each bridge
runs an algorithm which calculates how the loop can be prevented. STP and RSTP 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 to standby, so that should the main connection fail, another connection could take its place. This
algorithm exchange configuration messages (BPDU - Bridge Protocol Data Unit) periodically, so that all bridges
would be updated with the newest information about changes in network topology. (R)STP selects root bridge which
is responosible for network reconfiguration, such as blocking and opening ports of the other bridges. The root bridge
is the bridge with lowest bridge ID.

Bridge Interface Setup

Sub-menu: /interface bridge
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 will be assigned to all the bridged interfaces (the smallest
MAC address will be chosen automatically).
Property

Description

admin-mac (MAC address; Default: ) Static MAC address of the bridge (takes effect if auto-mac=no)
ageing-time (time; Default:
00:05:00)

How long a host information will be kept in the bridge database

arp (disabled | enabled | proxy-arp |

reply-only; Default: enabled)

Address Resolution Protocol setting

auto-mac (yes | no; Default: yes)

Automatically select the smallest MAC address of bridge ports as a bridge MAC address

forward-delay (time; Default:

00:00:15)

Time which is spent during the initialization phase of the bridge interface (i.e., after router startup or
enabling the interface) in listening/learning state before the bridge will start functioning normally

l2mtu (integer; read-only)

Layer2 Maximum transmission unit. read more

Manual:Interface/Bridge

max-message-age (time; Default:

00:00:20)

How long to remember Hello messages received from other bridges

mtu (integer; Default: 1500)

Maximum Transmission Unit

name (text; Default: bridgeN)

Name of the bridge interface

priority (integer: 0..65535;

Default: 32768)

Spanning tree protocol priority for bridge interface. Bridge with the smallest (lowest) bridge ID becomes a
Root-Bridge. Bridge ID consists of two numbers - priority and MAC address of the bridge. To compare
two bridge IDs, the priority is compared first. If two bridges have equal priority, then the MAC addresses
are compared.

protocol-mode (none | rstp | stp;

Default: none)

Select Spanning tree protocol (STP) or Rapid spanning tree protocol (RSTP) to ensure a loop-free
topology for any bridged LAN. RSTP provides provides for faster spanning tree convergence after a
topology change.

transmit-hold-count (integer:
1..10; Default: 6)

The Transmit Hold Count used by the Port Transmit state machine to limit transmission rate

http://en.wikipedia.org/wiki/Spanning_Tree_Protocol [2]
To add and enable a bridge interface that will forward all the protocols:
[admin@MikroTik] /interface bridge> add
[admin@MikroTik] /interface bridge> print
Flags: X - disabled, R - running
0 R name="bridge1" mtu=1500 l2mtu=65535 arp=enabled
mac-address=00:00:00:00:00:00 protocol-mode=none priority=0x8000
auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s
forward-delay=15s transmit-hold-count=6 ageing-time=5m
[admin@MikroTik] /interface bridge>

Bridge Settings
Sub-menu: /interface bridge settings
Property

Description

allow-fast-path (yes | no; Default: yes)

Allows fast path

use-ip-firewall (yes | no; Default: no)

Makes bridged traffic to be processed through IP firewall

use-ip-firewall-for-pppoe (yes | no;

Default: no)

Makes bridged un-encrypted PPPoE traffic to be processed through IP firewall (requires

use-ip-firewall=yes to work)

use-ip-firewall-for-vlan (yes | no;

Default: no)

Makes bridged VLAN traffic to be processed through IP firewall (requires

use-ip-firewall=yes to work)

Port Settings
Sub-menu: /interface bridge port
Port submenu is used to enslave interfaces in a particular bridge interface.

Manual:Interface/Bridge

Property

Description

bridge (name; Default: none)

The bridge interface the respective interface is grouped in

edge (auto | no | no-discover |

yes | yes-discover; Default: auto)

Set port as edge port or non-edge port, or enable automatic detection. Edge ports are connected to LAN that
has no other bridges attached. 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.

external-fdb (auto | no | yes; Whether to use wireless registration table to speed up bridge host learning
Default: auto)
horizon (none | integer
0..429496729; Default: none)

Use split horizon bridging to prevent bridging loops. read more

interface (name; Default:

none)

Name of the interface

path-cost (integer: 0..65535;

Default: 10)

Path cost to the interface, used by STP to determine the "best" path

priority (integer: 0..255;

Default: 128)

The priority of the interface in comparison with other going to the same subnet

To group ether1 and ether2 in the already created bridge1 bridge

[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
#
INTERFACE
BRIDGE
PRIORITY PATH-COST HORIZON
0
ether1
bridge1
0x80
10
none
1
ether2
bridge1
0x80
10
none
[admin@MikroTik] /interface bridge port>

Bridge Monitoring
Sub-menu: /interface bridge monitor
Used to monitor the current status of a bridge.
Property

Description

current-mac-address (MAC address) Current MAC address of the bridge

designated-port-count (integer)

Number of designated bridge ports

port-count (integer)

Number of the bridge ports

root-bridge (yes | no)

Shows whether 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

To monitor a bridge:
[admin@MikroTik] /interface bridge> monitor bridge1
state: enabled
current-mac-address: 00:0C:42:52:2E:CE

Manual:Interface/Bridge
root-bridge:
root-bridge-id:
root-path-cost:
root-port:
port-count:
designated-port-count:

11
yes
0x8000.00:00:00:00:00:00
0
none
2
0

[admin@MikroTik] /interface bridge>

Bridge Port Monitoring

Sub-menu: /interface bridge port monitor
Statistics of an interface that belongs to a bridge.
Property

Description

edge-port-discovery (yes | no)

Whether port to automatically detects edge ports

external-fdb (yes | no)

Shows whether registration table is used instead of forwarding data base

forwarding (yes | no)

Port state

learning (yes | no)

Port state

port-number (integer 1..4095)

Port identifier

role (designated | root port | alternate | backup |

disabled)

(R)STP algorithm assigned role of the port:

Disabled port - not strictly part of STP, a network administrator can manually disable
a port
Root port a forwarding port that is the best port from Nonroot-bridge to Rootbridge
Alternative port an alternate path to the root bridge. This path is different than using
the root port
Designated port a forwarding port for every LAN segment
Backup port a backup/redundant path to a segment where another bridge port
already connects.

sending-rstp (yes | no)

Whether the port is sending BPDU messages

status (in-bridge | inactive)

Port status

To monitor a bridge port:

[admin@MikroTik] /interface bridge port> monitor 0
status: in-bridge
port-number: 1
role: designated-port
edge-port: no
edge-port-discovery: yes
point-to-point-port: no
external-fdb: no
sending-rstp: no
learning: yes
forwarding: yes
[admin@MikroTik] /interface bridge port>

Manual:Interface/Bridge

Bridge Host Monitoring

Sub-menu: /interface bridge host
Property

Description

age (read-only: time)

The time since the last packet was received from the host

bridge (read-only: name)

The bridge the entry belongs to

external-fdb (read-only: flag)

Whether the host was learned using wireless registration table

local (read-only: flag)

Whether the host entry is of 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

To get the active host table:

[admin@MikroTik] /interface bridge host> print
Flags: L - local, E - external-fdb
BRIDGE
MAC-ADDRESS
ON-INTERFACE
bridge1
00:00:00:00:00:01 ether2
bridge1
00:01:29:FF:1D:CC ether2
L bridge1
00:0C:42:52:2E:CF ether2
bridge1
00:0C:42:52:2E:D0 ether2
bridge1
00:0C:42:5C:A5:AE ether2
[admin@MikroTik] /interface bridge host>

AGE
3s
0s
0s
3s
0s

Bridge Firewall
Sub-menu: /interface bridge filter, /interface bridge nat
The bridge firewall implements packet filtering and thereby provides security functions that are used to manage data
flow to, from and through bridge.
Packet flow diagram shows how packets are processed through router. It is possible to force bridge traffic to go
through /ip firewall filter rules (see: Bridge Settings)
There are two bridge firewall tables:
filter - bridge firewall with three predefined chains:
input - filters packets, which destination is the bridge (including those packets that will be routed, as they are
anyway destined to the bridge MAC address)
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 pakets to another destinations
You can put packet marks in bridge firewall (filter and NAT), which are the same as the packet marks in IP firewall
put by mangle. So 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.

Manual:Interface/Bridge
Property802.3-sap
(integer)802.3-type
(integer)arp-dst-address
(IP
address;
default:
)arp-dst-mac-address
(MAC address; default: )arp-gratuitous
(yes | no; default:
)arp-hardware-type (integer; default: 1)arp-opcode (arp-nak | drarp-error | drarp-reply | drarp-request |
inarp-reply | inarp-request | reply | reply-reverse | request | request-reverse)arp-src-address (IP address;
default: )arp-src-mac-address (MAC address; default: )chain (text)dst-address (IP address;
default: )dst-mac-address (MAC address; default: )dst-port (integer 0..65535)in-bridge
(name)in-interface (name)ingress-priority (integer 0..63)ip-protocol (ddp | ggp | icmp | igmp |
ipsec-ah | ospf | rdp | tcp | vrrp | egp | gre | icmpv6 | ipencap | ipsec-esp | pim | rspf | udp | xns-idp | encap | hmp |
idpr-cmtp | ipip | iso-tp4 | pup | st | vmtp | xtp)jump-target
(name)limit
(integer/time,integer)log-prefix (text)mac-protocol (arp | ip | ipv6 | ipx | length | pppoe | pppoe-discovery |
rarp | vlan)out-bridge (name)out-interface (name)packet-mark (name)packet-type (broadcast
| host | multicast | other-host)src-address (IP address; default: )src-mac-address (MAC address;
default:
)src-port
(integer
0..65535)stp-flags
(topology-change
|
topology-change-ack)stp-forward-delay
(time
0..65535)stp-hello-time
(time
0..65535)stp-max-age
(time
0..65535)stp-msg-age
(time
0..65535)stp-port
(integer
0..65535)stp-root-address (MAC address)stp-root-cost (integer 0..65535)stp-root-priority
(integer
0..65535)stp-sender-address
(MAC
address)stp-sender-priority
(integer
0..65535)stp-type (config | tcn)vlan-encap (arp | ip | ipv6 | ipx | length | pppoe | pppoe-discovery | rarp |
vlan )vlan-id (integer 0..4095)vlan-priority (integer 0..7)DescriptionDSAP (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 byteEthernet 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 SAP code of
0xAA followed by a SNAP type code of 0x809BARP destination addressARP destination MAC addressMatches
ARP gratuitous packetsARP hardware type. This normally Ethernet (Type 1) ARP opcode (packet type)
arp-nak - negative ARP reply (rarely used, mostly in ATM networks)
drarp-error - Dynamic RARP error code, saying that an IP address for the given MAC address can not be
allocated
drarp-reply - Dynamic RARP reply, with a temporaty IP address assignment for a host
drarp-request - Dynamic RARP request to assign a temporary IP address for the given MAC address
inarp-reply inarp-request reply - standard ARP reply with a MAC address
reply-reverse - reverse ARP (RARP) reply with an IP address assigned
request - standard ARP request to a known IP address to find out unknown MAC address
request-reverse - reverse ARP (RARP) request to a known MAC address to find out unknown IP address
(intended to be used by hosts to find out their own IP address, similarly to DHCP service)
ARP source addressARP source MAC addressBridge firewall chain, which the filter is functioning in (either a
built-in one, or a user defined)Destination IP address (only if MAC protocol is set to IPv4)Destination MAC
addressDestination port number or range (only for TCP or UDP protocols)Bridge interface through which the packet
is coming inPhysical interface (i.e., bridge port) through which the packet is coming inMatches ingress priority of
the packet. Priority may be derived from VLAN, WMM or MPLS EXP bit. read more IP protocol (only if MAC
protocol is set to IPv4)
ipsec-ah - IPsec AH protocol
ipsec-esp - IPsec ESP protocol
ddp - datagram delivery protocol
egp - exterior gateway protocol

Manual:Interface/Bridge

ggp - gateway-gateway protocol

gre - general routing encapsulation
hmp - host monitoring protocol
idpr-cmtp - idpr control message transport
icmp - internet control message protocol
icmpv6 igmp - internet group management protocol
ipencap - ip encapsulated in ip
encap - ip encapsulation
ipip - ip encapsulation
iso-tp4 - iso transport protocol class 4
ospf - open shortest path first
pim - protocol independent multicast
pup - parc universal packet protocol
rspf - radio shortest path first
rdp - reliable datagram protocol
st - st datagram mode

tcp - transmission control protocol

udp - user datagram protocol
vmtp - versatile message transport
vrrp xns-idp - xerox ns idp
xtp xpress transfer protocol

If action=jump specified, then specifies the user-defined firewall chain to process the packet Restricts packet
match rate to a given limit.
count - maximum average packet rate, measured in packets per second (pps), unless followed by Time option
time - specifies the time interval over which the packet rate is measured
burst - number of packets to match in a burst
Defines the prefix to be printed before the logging informationEthernet payload type (MAC-level protocol)Outgoing
bridge interfaceInterface via packet is leaving the bridgeMatch packets with certain packet mark MAC frame type:

broadcast - broadcast MAC packet

host - packet is destined to the bridge itself
multicast - multicast MAC packet
other-host - packet is destined to some other unicast address, not to the bridge itself

Source IP address (only if MAC protocol is set to IPv4)Source MAC addressSource port number or range (only for
TCP or UDP protocols) The BPDU (Bridge Protocol Data Unit) flags. Bridge exchange configuration messages
named BPDU peridiocally for preventing from loop
topology-change - topology change flag is set when a bridge detects port state change, to force all other bridges
to drop their host tables and recalculate network topology
topology-change-ack - topology change acknowledgement flag is sen in replies to the notification packets
Forward delay timerSTP hello packets timeMaximal STP message ageSTP message ageSTP port identifierRoot
bridge MAC addressRoot bridge costRoot bridge prioritySTP message sender MAC addressSTP sender priority The
BPDU type:
config - configuration BPDU
tcn - topology change notification

Manual:Interface/Bridge

the MAC protocol type encapsulated in the VLAN frameVLAN identifier fieldThe user priority field
STP matchers are only valid if 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 or rarp
VLAN matchers are only valid for vlan ethernet protocol
IP-related matchers are only valid if mac-protocol is set as ipv4
802.3 matchers are only consulted if the actual frame is compliant with IEEE 802.2 and IEEE 802.3 standards
(note: it is not the industry-standard Ethernet frame format used in most networks worldwide!). These matchers
are ignored for other packets.

Bridge Packet Filter

Sub-menu: /interface bridge filter
This section describes bridge packet filter specific filtering options, which were omitted in the general firewall
description.
Property

Description

action (accept | drop | jump | log | mark-packet

| passthrough | return | set-priority)

accept - accept the packet. No action, i.e., the packet is passed through without undertaking
any action, and no more rules are processed in the relevant list/chain
drop - silently drop the packet (without sending the ICMP reject message)
jump - jump to the chain specified by the value of the jump-target argument
log - log the packet
mark - mark the packet to use the mark later
passthrough - ignore this rule and go on to the next one. Acts the same way as a disabled
rule, except for ability to count packets
return - return to the previous chain, from where the jump took place
set-priority

Bridge NAT
Sub-menu: /interface bridge nat
This section describes bridge NAT options, which were omitted in the general firewall description.
Property

Description

Manual:Interface/Bridge

action (accept | drop | jump | mark-packet | redirect | set-priority

accept - accept the packet. No action, i.e., the packet is passed through
without undertaking any action, and no more rules are processed in the
relevant list/chain
arp-reply - send a reply to an ARP request (any other packets will be
ignored by this rule) with the specified MAC address (only valid in
dstnat chain)
drop - silently drop the packet (without sending the ICMP reject
message)
dst-nat - change destination MAC address of a packet (only valid in
dstnat chain)
jump - jump to the chain specified by the value of the jump-target
argument
log - log the packet
mark - mark the packet to use the mark later
passthrough - ignore this rule and go on to the next one. Acts the same
way as a disabled rule, except for ability to count packets
redirect - redirect the packet to the bridge itself (only valid in dstnat
chain)
return - return to the previous chain, from where the jump took place
set-priority
src-nat - change source MAC address of a packet (only valid in srcnat
chain)

to-arp-reply-mac-address (MAC address)

Source MAC address to put in Ethernet frame and ARP payload, when
action=arp-reply is selected

to-dst-mac-address (MAC address)

Destination MAC address to put in Ethernet frames, when

action=dst-nat is selected

to-src-mac-address (MAC address)

Source MAC address to put in Ethernet frames, when action=src-nat

is selected

[ Top | Back to Content ]

References
[1] http:/ / standards. ieee. org/ getieee802/ download/ 802. 1D-2004. pdf
[2] http:/ / en. wikipedia. org/ wiki/ Spanning_Tree_Protocol

Manual:Interface/VRRP

Manual:Interface/VRRP
Applies to RouterOS: v3, v4, v5

Summary
Sub-menu level: /interface vrrp
Standards: RFC 5798, RFC 3768
This chapter describes the Virtual Router Redundancy Protocol (VRRP) support in RouterOS.
Mostly on larger LANs dynamic routing protocols ( OSPF or RIP) are used, however there are number of factors that
may make undesirable to use dynamic routing protocols. One alternative is to use static routing, but if statically
configured first hop fails, then host will not be able to communicate with other hosts.
In IPv6 networks, hosts learn about routers by receiving Router Advertisements used by Neighbor Discovery (ND)
protocol. ND already has built in mechanism to determine unreachable routers. However it can take up to 38seconds
to detect unreachable router. It is possible to change parameters and make detection faster, but it will increase
overhead of ND traffic especially if there are a lot of hosts. VRRP allows to detect unreachable router within
3seconds without additional traffic overhead.
Virtual Router Redundancy Protocol (VRRP) provides a solution by combining number of routers into logical group
called Virtual Router (VR). VRRP implementation in RouterOS is compliant to VRRPv2 RFC 3768 and VRRPv3
RFC 5798.

Manual:Interface/VRRP

Protocol Overview
The purpose of the VRRP is to
communicate to all VRRP routers
associated with the Virtual Router ID
and support router redundancy through
a prioritized election process among
them.
All messaging is done by IPv4 or IPv6
multicast packets. Destination address
of IPv4 packet is 224.0.0.12 and for
IPv6 it is FF02:0:0:0:0:0:0:12. Source
address of the packet is always the
primary IP address of an interface from
which the packet is being sent. In IPv6
networks source address is link-local
address of an interface.
These packets are always sent with
TTL=255 and are not forwarded by the
router. If for any reason router receives
a packet with lower TTL, packet is
discarded.

Simple VRRP example

Each VR node has a single assigned

MAC address. This MAC address is used as a source for all periodic messages sent by Master.
Virtual Router is defined by VRID and mapped set of IPv4 or IPv6 addresses. Master router is said to be the owner
of mapped IPv4/IPv6 addresses. There are no limits to use the same VRID for IPv4 and IPv6, however these will be
two different Virtual Routers.
Only Master router is sending periodic Advertisement messages to minimize the traffic. Backup will try to preempt
the Master only if it has the higher priority and preemption is not prohibited.
All VRRP routers belonging to the same VR must be configured with the same advertisement interval. If
interval does not match router will discard received advertisement packet.

Virtual Router (VR)

A Virtual Router (VR) consists of one Owner router and one or more backup routers belonging to the same network.
VR includes:
VRID configured on each VRRP router
the same virtual IP on each router
Owner and Backup configured on each router. On a given VR there can be only one Owner.

Manual:Interface/VRRP

Virtual MAC address

VRRP automatically assigns MAC address to VRRP interface based on standard MAC prefix for VRRP packets and
VRID number. First five octets are 00:00:5E:00:01 and last octet is configured VRID. For example, Virtual Routers
VRID is 49, then virtual MAC address will be 00:00:5E:00:01:31.
Note: Virtual mac address can not be manually set or edited.

Owner
An Owner router for a VR is default
Master router and operates as the
Owner for all subnets included in the
VR. As mentioned before priority on
an owner router must be the highest
value (255). In example network R1 is
an Owner. It's priority is set to 255 and
virtual IP is the same as real IP (owns
the virtual IP address).
All Virtual Router members can be
configured so that virtual IP is not the
same as physical IP. Such Virtual
address can be called floating or pure virtual IP address.

VRRP without Owner

Advantage of this setup is flexibility given to the administrator. Since the virtual IP address is not the real address of
any one of the participant routers, the administrator can change these physical routers or their addresses without any
need to reconfigure the virtual router itself.
Note: RouterOS can not be configured as Owner. Pure virtual IP configuration is the only valid configuration
unless non-RouterOS device is set as owner.

Master
Master router in a VR operates as the physical gateway for the network for which it is configured.
Selection of the Master is controlled by priority value. Master state describes behavior of Master router. In example
network R1 is the Master router. When R1 is no longer available R2 becomes master.

Manual:Interface/VRRP

Backup
VR must contain at least one Backup router. Backup router must be configured with the same virtual IP as Master for
that VR. Default priority for Backup routers is 100. When current master router is no longer available, backup router
with highest priority will become current master. Every time when router with higher priority becomes available it is
switched to master. Sometimes this behavior is not necessary. To override it preemption mode should be disabled.

Virtual Address
Virtual IP associated with VR must be identical and set on all VR nodes. On Owner router Virtual IP must be the
same as real IP. For example on Owner router real IP and virtual IP is 192.168.1.1, on Backup router virtual IP is
192.168.1.1, but real IP is 192.168.1.2. All virtual and real addresses should be from the same network.
If the Master of VR is associated with multiple IP addresses, then Backup routers belonging to the same VR must
also be associated with the same set of virtual IP addresses. If virtual address on the Master is not also on Backup a
misconfiguration exists and VRRP advertisement packets will be discarded.
Note: It is not recommended to set up Mikrotik router as an Owner router. VRRP address and real IP address
should not be the same.

In IPv6 networks first address is always link-local address associated to VR. If multiple IPv6
addresses are configured, then they are added in advertisement packet after the link-local address.

IPv4 ARP
The Master for a given VR responds to ARP requests with the VR's assigned MAC address. Virtual MAC address is
also used as the source MAC address for advertisement packets sent by the Master. To ARP requests for non-virtual
IP addresses router responds with the system MAC address. Backup routers are not responding to ARP requests for
Virtual IPs.

IPv6 ND
As you already know there are no ARP in IPv6 networks, routers are discovered by Neighbor Discovery protocol.
When router becomes the Master, unsolicited ND Neighbor Advertisement with the Router Flag is sent for each IPv6
address associated with the virtual router.

Manual:Interface/VRRP

VRRP state machine

As you can see from diagram, each
VRRP node can be in one of three
states:
Init state
Backup state
Master state

Init state
The purpose of this state is to wait for
a Startup event. When this event is
received, then following actions are
taken:
if priority is 255,
* for IPv4 send advertisement
VRRP state transition flow
packet and broadcast ARP requests
* for IPv6 send an unsolicited ND Neighbor Advertisement for each IPv6 address associated with the virtual
router and set target address to link-local address associated with VR.
* transit to MASTER state;
else transit to BACKUP state.

Backup state
When in backup state,
in IPv4 networks, node is not responding to ARP requests and is not forwarding traffic for the IP associated with
the VR.
in IPv6 networks, node is not responding to ND Neighbor Solicitation messages and is not sending ND Router
Advertisement messages for VR associated IPv6 addresses.
Routers main task is to receive advertisement packets and check if master node is available.
Backup router will transit itself to master state in two cases:
If priority in advertisement packet is 0;
When Preemption_Mode is set to no, or Priority in the ADVERTISEMENT is greater than or equal to the local
Priority
After transition to Master state node is:
in IPv4 broadcasts gratuitous ARP request;
in IPv6 sends an unsolicited ND Neighbor Advertisement for every associated IPv6 address.
In other cases advertisement packets will be discarded. When shutdown event is received, transit to Init state.
Note: Preemption mode is ignored if Owner router becomes available.

Master state
When MASTER state is set, node functions as a forwarding router for IPv4/IPv6 addresses
associated with the VR.
In IPv4 networks Master node responds to ARP requests for the IPv4 address associated with the VR. In IPv6
networks Master node:

Manual:Interface/VRRP
responds to ND Neighbor Solicitation message for the associated IPv6 address;
sends ND Router Advertisements for the associated IPv6 addresses.
If advertisement packet is received by master node:
If priority is 0, send advertisement immediately;
If priority in advertisement packet is greater than nodes priority then transit to backup state
If priority in advertisement packet is equal to nodes priority and primary IP Address of the sender is greater than
the local primary IP Address, then transit to backup state
Ignore advertisement in other cases
When shutdown event is received, send advertisement packet with priority=0 and transit to Init state.

Configuring VRRP
IPv4
Setting up Virtual Router is quite easy, only two actions are required - create vrrp interface and set Virtual Routers
IP address.
For example, add vrrp to ether1 and set VRs address to 192.168.1.1
/interface vrrp add name=vrrp1 interface=ether1
/ip address add address=192.168.1.1/32 interface=vrrp1
Notice that only 'interface' parameter was specified when adding vrrp. It is the only parameter required to be set
manually, other parameters if not specified will be set to their defaults: vrid=1, priority=100 and
authentication=none.
Note: address on VRRP interface must have /32 netmask.

Before VRRP can operate correctly correct IP address is required on ether1. In this example it is
192.168.1.2/24
VRRP Examples section contains several configuration examples.

IPv6
To make VRRP work in IPv6 networks, several additional options must be enabled - v3 support is required and
protocol type should be set to IPv6:
/interface vrrp add name=vrrp1 interface=ether1 version=3 v3-protocol=ipv6
Now when VRRP interface is set, we can add global address and enable ND advertisement:
/ipv6 address add address=FEC0:0:0:FFFF::1/64 advertise=yes interface=vrrp1
No additional address configuration is required as it is in IPv4 case. IPv6 uses link-local addresses to communicate
between nodes.

Manual:Interface/VRRP

Property reference
Sub-menu: /interface vrrp
Property

Description

arp (disabled | enabled | proxy-arp | ARP resolution protocol mode

reply-only; Default: enabled)
authentication (ah | none |
simple; Default: none)

Authentication method to use for VRRP advertisement packets.

none - should be used only in low security networks (e.g., two VRRP nodes on LAN).
ah - IP Authentication Header. This algorithm provides strong protection against configuration errors,
replay attacks and packet corruption/modification. Recommended when there is limited control over the
administration of nodes on a LAN.
simple - uses clear text password. Protects against accidental misconfiguration of routers on local
network.

interface (string; Default: )

Interface name on which VRRP instance will be running

interval (time [10ms..4m15s];

Default: 1s)

VRRP update interval in seconds. Defines how often master sends advertisement packets.

mtu (integer; Default: 1500)

Layer3 MTU size

name (string; Default: )

VRRP interface name

on-backup (string; Default: )

Script to execute when the node is switched to backup state

on-master (string; Default: )

Script to execute when the node is switched to master state

password (string; Default: )

Password required for authentication. Can be ignored if authentication is not used.

preemption-mode (yes | no;

Default: yes)

Whether master node always has the priority. When set to 'no' backup node will not be elected to be a master
until the current master fails, even if the backup node has higher priority than the current master. This
setting is ignored if Owner router becomes available

priority (integer: 1..254; Default: Priority of VRRP node used in Master election algorithm. Higher number means higher priority. '255' is
100)
reserved to Router that owns VR IP and '0' is reserved for Master router to indicate that it is releasing
responsibility.
v3-protocol (ipv4 | ipv6;
Default: ipv4)

Protocol that will be used by VRRPv3. Valid only if version is 3

version (integer [2, 3]; Default: 3) Which VRRP version to use.

vrid (integer: 1..255; Default: 1)

Virtual Router identifier. Each Virtual router must have unique id number

There are two ways to add scripts to on-backup and on-master

specify scripts name added to script repository
write script directly by putting it in scopes '{ }'.

See more
VRRP-examples
[ Top | Back to Content ]

Manual:Bonding Examples

Manual:Bonding Examples
Bonding EoIP tunnels over two wireless links
This is an example of aggregating multiple network interfaces into a single pipe. In particular, it is shown how to
aggregate multiple virtual (EoIP) interfaces to get maximum throughput (MT) with emphasis on availability.

Network Diagram
Two routers R1 and R2 are interconnected via multihop wireless links. Wireless interfaces on both sides have
assigned IP addresses.

Getting started
Bonding could be used only on OSI layer 2 (Ethernet level) connections. Thus we need to create EoIP interfaces on
each of the wireless links. This is done as follows:
on router R1:
[admin@MikroTik] > /interface eoip add remote-address=10.0.1.1/24 tunnel-id=1
[admin@MikroTik] > /interface eoip add remote-address=10.0.2.1/24 tunnel-id=2
and on router R2
[admin@MikroTik] > /interface eoip add remote-address=10.1.1.1/24 tunnel-id=1
[admin@MikroTik] > /interface eoip add remote-address=10.2.2.1/24 tunnel-id=2
The second step is to add bonding interface and specify EoIP interfaces as slaves:
R1:
[admin@MikroTik] > / interface bonding add slaves=eoip-tunnel1,eoip-tunnel2 mode=balance-rr

R2
[admin@MikroTik] > / interface bonding add slaves=eoip-tunnel1,eoip-tunnel2 mode=balance-rr

The last step is to add IP addresses to the bonding interfaces:

R1:
[admin@MikroTik] > / ip address add address 192.168.0.1/24 interface=bonding1
R2
[admin@MikroTik] > / ip address add address 192.168.0.2/24 interface=bonding1

Manual:Bonding Examples

Test the configuration

Now two routers are able to reach each other using addresses from the 192.168.0.0/24 network. To verify bonding
interface functionality, do the following:
R1:
[admin@MikroTik] > /interface monitor-traffic eoip-tunnel1,eoip-tunnel2
R2
[admin@MikroTik] > /tool bandwidth-test 192.168.0.1 direction=transmit
You should see that traffic is distributed equally across both EoIP interfaces:
[admin@MikroTik] > /int monitor-traffic eoip-tunnel1,eoip-tunnel2
received-packets-per-second: 685
685
received-bits-per-second: 8.0Mbps 8.0Mbps
sent-packets-per-second: 21
20
sent-bits-per-second: 11.9kbps 11.0kbps
received-packets-per-second: 898
899
received-bits-per-second: 10.6Mbps 10.6Mbps
sent-packets-per-second: 20
21
sent-bits-per-second: 11.0kbps 11.9kbps
received-packets-per-second: 975
975
received-bits-per-second: 11.5Mbps 11.5Mbps
sent-packets-per-second: 22
22
sent-bits-per-second: 12.4kbps 12.3kbps
received-packets-per-second: 980
980
received-bits-per-second: 11.6Mbps 11.6Mbps
sent-packets-per-second: 21
21
sent-bits-per-second: 11.9kbps 11.8kbps
received-packets-per-second: 977
977
received-bits-per-second: 11.6Mbps 11.5Mbps
sent-packets-per-second: 21
21
sent-bits-per-second: 11.9kbps 11.8kbps
-- [Q quit|D dump|C-z pause]
[admin@MikroTik] >

Link Monitoring
It is easy to notice that with the configuration above as soon as any of individual link fails, the bonding interface
throughput collapses. That's because no link monitoring is performed, consequently, the bonding driver is unaware
of problems with the underlying links. Enabling link monitoring is a must in most bonding configurations. To enable
ARP link monitoring, do the following:
R1:
[admin@MikroTik] > / interface bonding set bonding1 link-monitoring=arp arp-ip-targets=192.168.0.2

R2
[admin@MikroTik] > / interface bonding set bonding1 link-monitoring=arp arp-ip-targets=192.168.0.1

Manual:Bonding Examples

Bonding Multiple P2P wireless links

Consider following setup:

Manual:VRRP-examples
Applies to RouterOS: v3, v4

VRRP Configuration Examples

This section contains several useful VRRP configuration examples

Basic Setup
This is the basic VRRP configuration example.

According to this configuration, as long as the master, R1, is functional, all traffic destined to the external network
gets directed to R1. But as soon as R1 fails, R2 takes over as the master and starts handling packets forwarded to the
interface associated with IP(R1). In this setup Router R2 is completely idle during Backup period.

Manual:VRRP-examples
Configuration
R1 configuration:
/ip address add address=192.168.1.1/24 interface=ether1
/interface vrrp add interface=ether1 vrid=49 priority=254
/ip address add address=192.168.1.254/32 interface=vrrp1
R2 configuration:
/ip address add address=192.168.1.2/24 interface=ether1
/interface vrrp add interface=ether1 vrid=49
/ip address add address=192.168.1.254/32 interface=vrrp1
Testing
First of all check if both routers have correct flags at vrrp interfaces. On router R1 it should look like this
/interface vrrp print
0

RM name="vrrp1" mtu=1500 mac-address=00:00:5E:00:01:31 arp=enabled interface=ether1 vrid=49

priority=254 interval=1 preemption-mode=yes authentication=none password="" on-backup=""
on-master=""

and on router R2:

/interface vrrp print
0

B name="vrrp1" mtu=1500 mac-address=00:00:5E:00:01:31 arp=enabled interface=ether1 vrid=49

priority=100 interval=1 preemption-mode=yes authentication=none password=""
on-backup="" on-master="

As you can see vrrp interface mac addresses are identical on both routers. Now to check if vrrp is working correctly,
try to ping virtual address from client and check arp entries:
[admin@client] > /ping 192.168.1.254
192.168.1.254 64 byte ping: ttl=64 time=10 ms
192.168.1.254 64 byte ping: ttl=64 time=8 ms
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 8/9.0/10 ms
[admin@client] /ip arp> print
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic
#
ADDRESS
MAC-ADDRESS
INTERFACE
...
1 D 192.168.1.254
00:00:5E:00:01:31 bridge1
Now unplug ether1 cable on router R1. R2 will become VRRP master, ARP table on client will not change but
traffic will start to flow over R2 router.

Load sharing
In basic configuration example R2 is completely idle during Backup state. This behavior may be considered as waste
of valuable resources. In such circumstances R2 router can be set as gateway for some clients.
The obvious advantage of this configuration is the establishment of a load-sharing scheme. But by doing so R2
router is not protected by current VRRP setup.
To make this setup work we need two virtual routers.

Manual:VRRP-examples

Configuration for V1 virtual router will be identical to configuration in basic example - R1 is the Master and R2 is
Backup router. In V2 Master is R2 and Backup is R1.
With this configuration, we establish a load-sharing between R1 and R2; moreover, we create protection setup by
having two routers acting as backups for each other.
Configuration
R1 configuration:
/ip address add
/interface vrrp
/interface vrrp
/ip address add
/ip address add

address=192.168.1.1/24 interface=ether1
add interface=ether1 vrid=49 priority=254
add interface=ether1 vrid=77
address=192.168.1.253/32 interface=vrrp1
address=192.168.1.254/32 interface=vrrp2

R2 configuration:
/ip address add
/interface vrrp
/interface vrrp
/ip address add
/ip address add

address=192.168.1.2/24 interface=ether1
add interface=ether1 vrid=49
add interface=ether1 vrid=77 priority=254
address=192.168.1.253/32 interface=vrrp1
address=192.168.1.254/32 interface=vrrp2

Manual:VRRP-examples

VRRP without Preemption

Each time when router with higher priority becomes available it becomes Master router. Sometimes it is not desired
behavior which can be turned off by setting preemption-mode=no in vrrp configuration.
Configuraton
We will be using the same setup as in basic example. Only difference is during configuration set
preemption-mode=no. It can be done easily modifying existing configuration:
/interface vrrp set [find] preemption-mode=no
Testing
Try turning off R1 router, R2 will become Master router because it has highest priority among available routers.
Now turn R1 router on and you will see that R2 router continues to be Master even if R1 has higher priority.

VRRP and scripts

See Also
VRRP
Scripting
[ Top | Back to Content ]

Manual:Switch Chip Features

Applies to RouterOS: v4.0 +

Introduction
There are several types of switch chips on Routerboards and they have a different set of features. Most of them (from
now on "Other") have only basic "Port Switching" feature, but there are few with more features:
Capabilities of switch chips:
Feature

Atheros8327 Atheros8316 Atheros8227 Atheros7240 ICPlus175D Other

Port Switching yes

yes

Port Mirroring yes

yes

Host table

2048 entries

1024 entries

2048 entries

Vlan table

4096 entries

16 entries

Rule table

92 rules

32 rules

Atheros8316 is present on RB493G(ether1+ether6-ether9, ether2-ether5), RB1200(ether1-ether5), RB450G(all

ports with ether1 optional[more [1]]), RB435G(all ports with ether1 optional[more [1]]), RB750G and
RB1100(ether1-ether5, ether6-ether10).

Manual:Switch Chip Features

Atheros8327 is present on RB2011 series(ether1-ether5+sfp1) RB750GL, RB751G-2HnD, RB951G-2HnD and

RB1100AH, RB1100AHx2(ether1-ether5, ether6-ether10).
Atheros8227 is present on RB2011 series(ether6-ether10).
Atheros7240 is present on RB750(ether2-ether5), RB750UP(ether2-ether5), RB751U-2HnD(ether2-ether5),
RB951-2n(ether2-ether5) and RB951Ui-2HnD(ether2-ether5).
ICPlus175D is present on newest versions of RB450(ether2-ether5) and RB433 series(ether2-ether3).
ICPlus175C is present on some RB450(ether2-ether5) and some RB433 series(ether2-ether3).
ICPlus178C is present on RB493 series(ether2-ether9) and RB816.
Command line config is under /interface ethernet switch menu. This menu contains a list of all switch
chips present in system, and some sub-menus as well. /interface ethernet switch menu list item
represents a switch chip in system:
[admin@MikroTik] /interface ethernet switch> print
Flags: I - invalid
#
NAME
TYPE
MIRROR-SOURCE
MIRROR-TARGET
0
switch1 Atheros-8316 ether2
none
Depending on switch type there might be available or not available some configuration capabilities.
Atheros8316 packet flow diagram [2]

Features
Port Switching
Switching feature allows wire speed traffic passing among a group of ports, like the ports were a regular ethernet
switch. You configure this feature by setting a "master-port" property to one ore more ports in /interface
ethernet menu. A 'master' port will be the port through which the RouterOS will communicate to all ports in the
group. Interfaces for which the 'master' port is specified become inactive - no traffic is received on them and no
traffic can be sent out.
For example consider a router with five ethernet interfaces:
[admin@MikroTik] > interface ethernet print
Flags: X - disabled, R - running, S - slave
#
NAME
MTU
MAC-ADDRESS
ARP
0 R ether1
1500 00:0C:42:3E:5D:BB enabled
1
ether2
1500 00:0C:42:3E:5D:BC enabled
2
ether3
1500 00:0C:42:3E:5D:BD enabled
3
ether4
1500 00:0C:42:3E:5D:BE enabled
4 R ether5
1500 00:0C:42:3E:5D:BF enabled

MASTER-PORT

SWITCH

none
none
none
none

switch1
switch1
switch1
switch1

And you configure a switch containing three ports ether3, ether4 and ether5:
[admin@MikroTik] /interface ethernet> set ether4,ether5 master-port=ether3
[admin@MikroTik] /interface ethernet> print
Flags: X - disabled, R - running, S - slave
#
NAME
MTU
MAC-ADDRESS
ARP
MASTER-PORT
SWITCH
0 R ether1
1500 00:0C:42:3E:5D:BB enabled
1
ether2
1500 00:0C:42:3E:5D:BC enabled
none
switch1
2 R ether3
1500 00:0C:42:3E:5D:BD enabled
none
switch1

Manual:Switch Chip Features

3 S ether4
4 RS ether5

1500
1500

31
00:0C:42:3E:5D:BE enabled
00:0C:42:3E:5D:BF enabled

ether3
ether3

switch1
switch1

ether3 is now the master port of the group. Note: you can see that previously a link was detected only on ether5, but
now as the ether3 is a 'master' the running flag is propagated to master port.

In essence this configuration is the same as if you had a RouterBoard with 3 ethernet interfaces with ether3
connected to ethernet switch that has 4 ports:

A more general diagram of RouterBoard with switch chip that has 5 port switch chip:

Manual:Switch Chip Features

Here you can see that, a packet that gets received by one of the ports always passes through the switch logic at first.
Switch logic decides to which ports the packet should be going to. Passing packet 'up' or giving it to RouterOS is
also called sending it to switch chips 'cpu' port. That means that at the point switch forwards the packet to cpu port
the packet starts to get processed by RouterOS as some interfaces incoming packet. While the packet does not have
to go to cpu port it is handled entirely by switch logic and does not require any cpu cycles and happen at wire speed
for any frame size.
Ether1 port on RB450G has a feature that allows it to be removed/added to the default switch group. By default
ether1 port will be included in the switch group. This configuration can be changed with /interface
ethernet switch set switch1 switch-all-ports=no
switch-all-ports=yes/no "yes" means ether1 is part of switch and supports switch grouping, and all other advanced Atheros8316 features
including extended statistics (/interface ethernet print stats).
"no" means ether1 is not part of switch, effectivly making it as stand alone ethernet port, this way increasing its
troughtput to other ports in bridged, and routed mode, but removing the switching possibility on this port.

Manual:Switch Chip Features

Port Mirroring
Port mirroring lets switch 'sniff' all traffic that is going in and out of one port (mirror-source) and send a copy of
those packets out of some other port (mirror-target). This feature can be used to easily set up a 'tap' device that
receives all traffic that goes in/out of some specific port. Note that mirror-source and mirror-target ports have to
belong to same switch. (See which port belong to which switch in /interface ethernet switch port
menu). Also mirror-target can have a special 'cpu' value, which means that 'sniffed' packets should be sent out of
switch chips cpu port. Port mirroring happens independently of switching groups that have or have not been set up.

Host Table
Basically the table represents switch chips 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 certain port, it adds the packets source mac address X and port it received the packet from to
host table, so when a packet comes in with destination mac address X it knows to which port it should forward the
packet. If the destination mac address is not present in host table 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
switch group. So you won't see dynamic entries if you have not specified some 'master-ports'. Also you can add
static entries that take over dynamic if dynamic entry with same mac-address already exists. Also by adding a static
entry you get access to some more functionality that is controlled via following params:

copy-to-cpu=yes/no - a packet can be cloned and sent to cpu port

redirect-to-cpu=yes/no - a packet can be redirected to cpu port
mirror=yes/no - a packet can be cloned and sent to mirror-target port configured in "/interface ethernet switch"
drop=yes/no - a packet with certain mac address coming from certain ports can be dropped

copy-to-cpu, redirect-to-cpu, mirror actions are performed for packets which destination mac matches mac address
specified in entry drop action is performed for packets which source mac address matches mac address specified in
entry
Another possibility for static entries is that mac address can be mapped to more that one port, including 'cpu' port.

Vlan Table
Vlan tables specifies certain forwarding rules for packets that have specific 802.1q tag. Those rules are of higher
priority than switch groups configured using 'master-port' property. Basically the table contains entries that map
specific vlan tag ids to a group of one or more ports. Packets with vlan tags leave switch chip through one or more
ports that are set in corresponding table entry. The exact logic that controls how packets with vlan tags are treated is
controlled by vlan-mode parameter that is changeable per switch port in /interface ethernet switch
port menu. Vlan-mode can take following values:
disabled - ignore vlan table, treat packet with vlan tags just as if they did not contain a vlan tag;
fallback - the default mode - handle packets with vlan tag that is not present in vlan table just like packets without
vlan tag. Packets with vlan tags that are present in vlan table, but incoming port does not match any port in vlan
table entry does not get dropped.
check - drop packets with vlan tag that is not present in vlan table. Packets with vlan tags that are present in vlan
table, but incoming port does not match any port in vlan table entry does not get dropped.
secure - drop packets with vlan tag that is not present in vlan table. Packets with vlan tags that are present in vlan
table, but incoming port does not match any port in vlan table entry get dropped.
Vlan tag id based forwarding also take into account the mac addresses learned or manually added in host table.
Packets without vlan tag are treated just like if they had a vlan tag with vlan id = 0. This means that if
"vlan-mode=check or secure" to be able to forward packets without vlan tags you have to add a special entry to vlan

Manual:Switch Chip Features

table with vlan id set to 0.
Vlan-header option (configured in /interface ethernet switch port) sets the VLAN tag mode on
egress port. Starting from RouterOS version 6 this option works with AR8316, AR8327, AR8227 and AR7240
switch chips and takes the following values:
leave-as-is - packet remains unchanged on egress port;
always-strip - if VLAN header is present it is removed from the packet;
add-if-missing - if VLAN header is not present it is added to the packet.

Rule Table
Rule table is very powerful tool allowing wire speed packet filtering, forwarding and vlan tagging based on
L2,L3,L4 protocol header field condition.
Each rule contains a conditions part and an action part. Action part is controlled by following parameters:
copy-to-cpu=yes/no - clones matching packets and sends them to cpu port;
redirect-to-cpu=yes/no - redirects matching packets to cpu port;
mirror=yes/no - clones matching packets and send them to mirror-target port;
new-dst-ports - if set forces the destination port to be as specified, multiple ports allowed, including cpu port.
Non obvious feature of this parameter is to pass empty list of ports to drop matching packets;
new-vlan-id (only applies to Atheros8316) - if specified changes the vlan tag id, or add new vlan tag if one was
not present;
new-vlan-priority - if specified changes the vlan tag priority bits;
rate (only applies to Atheros8327) - Sets limitation (bits per second) for all matched traffic. Can only be applied
to first 32 rule slots.
Conditions part is controlled by rest of parameters:
ports - match port that packet came in from (multiple ports allowed);
mac layer conditions

dst-mac-address - match by destination mac address and mask;

src-mac-address - ...;
vlan-header - match by vlan header presence;
vlan-id (only applies to Atheros8316) - match by vlan tag id;
vlan-priority (only applies to Atheros8316) - match by priority in vlan tag;
mac-protocol - match by mac protocol (skips vlan tags if any);

ip conditions

dst-address - match by destination ip and mask;

src-address - match by source ip and mask;
dscp - match by ip dscp field;
protocol - match by ip protocol;

ipv6 conditions

dst-address6 - match by destination ip and mask;

src-address6 - match by source ip and mask;
flow-label - match by ipv6 flow label;
traffic-class - match by ipv6 traffic class;
protocol - match by ip protocol;

L4 conditions
src-port - match by tcp/udp source port range;

Manual:Switch Chip Features

dst-port - match by tcp/udp destination port range;
IPv4 and IPv6 specific conditions cannot be present in same rule. Menu contains ordered list of rules just like in
/ip firewall filter. Due to the fact that the rule table is processed entirely in switch chips hardware there is
limitation to how many rules you may have. Depending on the amount of conditions (MAC layer, IP layer, IPv6, L4
layer) you use in your rules the amount of active rules may vary from 8 to 32 for Atheros8316 switch chip and from
24 to 96 for Atheros8327 switch chip. You can always do /interface ethernet switch rule print
after modifying your rule set to see that no rules at the end of the list are 'invalid' which means those rules did not fit
into the switch chip.

Example - 802.1Q Trunking with Atheros switch chip in RouterOS v6

Routerboards with Atheros switch chips can be used for 802.1Q Trunking. This
feature in RouterOS version 6 is supported on AR8316, AR8327, AR8227 and
AR7240 switch chips. In this example ether2,ether3 and ether4 interfaces are
access ports, while ether5 is trunk port. VLAN IDs for each access port: ether2 200, ether3 - 300, ether4 - 400.
Create a group of switched ports.

/interface
set ether3
set ether4
set ether5

ethernet
master-port=ether2
master-port=ether2
master-port=ether2

Assign "vlan-mode" and "vlan-header" mode for each port and "default-vlan-id" on ingress for each access port.
Set "vlan-mode=secure" to ensure strict use of VLAN table. Set "vlan-header=always-strip" for access ports - it
removes VLAN header from frame when it leaves the switch chip. Set "vlan-header=add-if-missing" for trunk
port - it adds VLAN header to untagged frames. "Default-vlan-id" specifies what VLAN ID is added for ingress
traffic of the access port.
/interface
set ether2
set ether3
set ether4
set ether5

ethernet switch port

vlan-mode=secure vlan-header=always-strip default-vlan-id=200
vlan-mode=secure vlan-header=always-strip default-vlan-id=300
vlan-mode=secure vlan-header=always-strip default-vlan-id=400
vlan-mode=secure vlan-header=add-if-missing

Manual:Switch Chip Features

Add VLAN table entries to allow frames with specific VLAN IDs between ports.
/interface ethernet switch vlan
add ports=ether2,ether5 switch=switch1 vlan-id=200
add ports=ether3,ether5 switch=switch1 vlan-id=300
add ports=ether4,ether5 switch=switch1 vlan-id=400

Management IP Configuration
This example will show one of the possible management IP address configurations. Management IP will be
accessible only through trunk port and it will have a separate VLAN with ID 99.
Configure the port which connects switch-chip with CPU, set "vlan-header=leave-as-is" because management
traffic already should be tagged.
/interface ethernet switch port
set switch1_cpu vlan-mode=secure vlan-header=leave-as-is
Add VLAN table entry to allow management traffic through switch-cpu port and the trunk port.
/interface ethernet switch vlan
add ports=ether5,switch1_cpu switch=switch1 vlan-id=99
Add VLAN 99 and assign IP address to it. Since the master-port receives all the traffic coming from switch-cpu
port, VLAN has to be configured on master-port, in this case "ether2" port.
/interface vlan
add name=vlan99 vlan-id=99 interface=ether2
/ip address
add address=192.168.88.1/24 interface=vlan99 network=192.168.88.0

References
[1] http:/ / wiki. mikrotik. com/ wiki/ Manual:Switch_Chip_Features#switch-all-ports
[2] http:/ / wiki. mikrotik. com/ wiki/ Manual:Packet_flow_through_Atheros8316

Manual:Maximum Transmission Unit on RouterBoards

Manual:Maximum Transmission Unit on

RouterBoards
Background
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be
successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a
way that packet sizes does not exceed the capabilities of network equipment.
Originally MTU was introduced because of the high error rates and low speed of communications. Fragmentation of
the data stream gives ability to correct corruption errors only by resending corrupted fragment, not the whole stream.
Also on low speed connections such as modems it can take too much time to send a big fragment, so in this case
communication is possible only with smaller fragments.
But in present days we have much lower error rates and higher speed of communication, this opens a possibility to
increase the value of MTU. By increasing value of MTU we will result in less protocol overhead and reduce CPU
utilization mostly due to interrupt reduction.
This way some non-standard frames started to emerge:
Giant or Jumbo frames - frames that are bigger than standard (IEEE) Ethernet MTU
Baby Giant or Baby Jumbo frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for
granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with
Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully
implement some application that will produce this big Ethernet frames, switch must also support forwarding such
frames.

MTU on RouterOS
Mikrotik RouterOS recognizes several types
of MTU:
IP/Layer-3/L3 MTU
MPLS/Layer-2.5/L2.5 MTU
MAC/Layer-2/L2 MTU
Full frame MTU

Full frame MTU

Full frame MTU indicates the actual size of
the frame that are sent by particular
interface. Frame Checksum is not included
as it is removed by Ethernet driver as soon as frame reach its destination.

Manual:Maximum Transmission Unit on RouterBoards

MAC/Layer-2/L2 MTU
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface.
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all
Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support
configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same
as Routerboard Ethernets.
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN
and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.
This table shows max-l2mtu supported by Mikrotik RouterBoards (Starting from the RouterOS v5.3 also available in
"/interface print" menu as value of read-only "max-l2mtu" option):
Integrated Solutions
RouterBoard

MTU description

RB Groove series

ether1:2028

RB Metal series

ether1:2028

RB SXT series

ether1:2028