Interface Bonding With Mikrotik and Cisco

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

Interface_Bonding_with_Mikrotik_and_Cisco http://localhost:3000/55.%20Interface_Bonding_with_Mi...

Home / Interface_Bonding_with_Mikrotik_and_Cisco

Interface_Bonding_with_Mikrotik_and_
Cisco
Interface Bonding 802.3ad (LACP) with Mikrotik and Cisco
Bonding (also called port trunking or link aggregation) can be configured quite easily on
RouterOS-Based devices.

Having 2 NICs (ether1 and ether2) in each router (Router1 and Router2), it is possible to get
maximum data rate between 2 routers, by aggregating port bandwidth.

To add a bonding interface on Router1 and Router2:

/interface bonding add slaves=ether1,ether2

(bonding interface needs a couple of seconds to get connectivity with its peer)

Link Monitoring: Currently bonding in RouterOS supports two schemes for monitoring a link
state of slave devices: MII and ARP monitoring. It is not possible to use both methods at a time
due to restrictions in the bonding driver.

ARP Monitoring: ARP monitoring sends ARP queries and uses the response as an indication
that the link is operational. This also gives assurance that traffic is actually flowing over the links.
If balance-rr and balance-xor modes are set, then the switch should be configured to evenly
distribute packets across all links. Otherwise all replies from the ARP targets will be received on
the same link which could cause other links to fail. ARP monitoring is enabled by setting three
properties link-monitoring, arp-ip-targets and arp-interval. Meaning of each option is described
later in this article. It is possible to specify multiple ARP targets that can be useful in a High
Availability setups. If only one target is set, the target itself may go down. Having an additional
targets increases the reliability of the ARP monitoring.

MII Monitoring: MII monitoring monitors only the state of the local interface. In RouterOS it is
possible to configure MII monitoring in two ways:

MII Type 1: device driver determines whether link is up or down. If device driver does not

Стор. 1 з 3 26.08.21, 01:21


Interface_Bonding_with_Mikrotik_and_Cisco http://localhost:3000/55.%20Interface_Bonding_with_Mi...

support this option then link will appear as always up. MII Type 2: deprecated calling sequences
within the kernel are used to determine if link is up. This method is less efficient but can be used
on all devices. This mode should be set only if MII type 1 is not supported.

Main disadvantage is that MII monitoring can’t tell if the link actually can pass the packets or not
even if the link is detected as up.

MII monitoring is configured setting desired link-monitoring mode and mii-interval.

Configuration Example: 802.3ad (LACP) with Cisco Catalyst GigabitEthernet Connection.

/inteface bonding add slaves=ether1,ether2 \


mode=802.3ad lacp-rate=30secs \
link-monitoring=mii-type1 \
transmit-hash-policy=layer-2-and-3

Other part configuration (assuming the aggregation switch is a Cisco device, usable in
EtherChannel / L3 environment):

Стор. 2 з 3 26.08.21, 01:21


Interface_Bonding_with_Mikrotik_and_Cisco http://localhost:3000/55.%20Interface_Bonding_with_Mi...

!
interface range GigabitEthernet 0/1-2
channel-protocol lacp
channel-group 1 mode active
!
interface PortChannel 1
no switchport
ip address XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
!

Or for EtherChannel / L2 environment:

!
interface range GigabitEthernet 0/1-2
channel-protocol lacp
channel-group 1 mode active
!
interface PortChannel 1
switchport
switchport mode access
swichport access vlan XX
!

Стор. 3 з 3 26.08.21, 01:21

You might also like