Has Anyone Been Working WithBonding *Feeling black balled*

RouterOS General
1

I have setup two MTs to test the bonding. I followed the info here http://www.mikrotik.com/docs/ros/2.9/interface/bonding but it's not even trying to work. Need some help PLEASE!

[admin@ColoBonder] ip> address print
Flags: X - disabled, I - invalid, D - dynamic

ADDRESS NETWORK BROADCAST INTERFACE

0 172.16.2.1/24 172.16.2.0 172.16.2.255 ether5
1 172.16.1.1/24 172.16.1.0 172.16.1.255 ether4
2 206.251.xxx.xxx/29 206.251.xxx.xxx 206.251.xxx.xxx ether2
3 10.10.10.1/24 10.10.10.0 10.10.10.255 ether2
4 3.3.3.1/24 3.3.3.0 3.3.3.255 bonding1

[admin@ColoBonder] interface> print
Flags: X - disabled, D - dynamic, R - running

NAME TYPE RX-RATE TX-RATE MTU

0 X ether1 ether 0 0 1500
1 R ether2 ether 0 0 1500
2 R ether3 ether 0 0 1500
3 R ether4 ether 0 0 1500
4 R ether5 ether 0 0 1500
5 R eoip-tunnel2 eoip-tunnel 0 0 1500
6 R eoip-tunnel1 eoip-tunnel 0 0 1500
7 R bonding1 bonding 0 0 1500
[admin@ColoBonder] interface> bonding print
Flags: X - disabled, R - running
0 R name="bonding1" mtu=1500 mac-address=FE:FD:00:00:00:03 arp=enabled
slaves=eoip-tunnel1,eoip-tunnel2 mode=balance-rr primary=none
link-monitoring=none arp-interval=00:00:00.100 mii-interval=00:00:00.100
down-delay=00:00:00 up-delay=00:00:00 lacp-rate=30secs

[admin@ColoBonder] interface> eoip print
Flags: X - disabled, R - running
0 R name="eoip-tunnel2" mtu=1500 mac-address=FE:FD:00:00:00:04 arp=enabled
remote-address=172.16.2.2 tunnel-id=2

1 R name="eoip-tunnel1" mtu=1500 mac-address=FE:FD:00:00:00:03 arp=enabled
remote-address=172.16.1.2 tunnel-id=1

[admin@ClientBonder] > ip address print
Flags: X - disabled, I - invalid, D - dynamic

ADDRESS NETWORK BROADCAST INTERFACE

0 172.16.2.2/24 172.16.2.0 172.16.2.255 ether3
1 172.16.1.2/24 172.16.1.0 172.16.1.255 ether2
2 10.10.10.2/24 10.10.10.0 10.10.10.255 ether1
3 3.3.3.2/24 3.3.3.0 3.3.3.255 bonding1
[admin@ClientBonder] > interface print
Flags: X - disabled, D - dynamic, R - running

NAME TYPE RX-RATE TX-RATE MTU

0 R eoip-tunnel2 eoip-tunnel 0 0 1500
1 R eoip-tunnel1 eoip-tunnel 0 0 1500
2 R ether1 ether 0 0 1500
3 R ether2 ether 0 0 1500
4 R ether3 ether 0 0 1500
5 R bonding1 bonding 0 0 1500
[admin@ClientBonder] > interface bonding print
Flags: X - disabled, R - running
0 R name="bonding1" mtu=1500 mac-address=FE:FD:00:00:00:01 arp=enabled
slaves=eoip-tunnel1,eoip-tunnel2 mode=balance-rr primary=none
link-monitoring=none arp-interval=00:00:00.100
mii-interval=00:00:00.100 down-delay=00:00:00 up-delay=00:00:00
lacp-rate=30secs
[admin@ClientBonder] > interface eoip print
Flags: X - disabled, R - running
0 R name="eoip-tunnel2" mtu=1500 mac-address=FE:FD:00:00:00:02 arp=enabled
remote-address=172.16.2.1 tunnel-id=2

1 R name="eoip-tunnel1" mtu=1500 mac-address=FE:FD:00:00:00:01 arp=enabled
remote-address=172.16.1.1 tunnel-id=1

2

23 views and no replys. Come on people.
Is the bonding broke in 2.9.16?
It was working in 2.9.11 when Joe was working on the bonding project.

3

I just upgraded the two MTs from 2.9.16 to the 2.9.18 and it’s working now. But, I upgraded via FTP and after the reboots it still reads as 2.9.16.
As long as it’s working I don’t care.
Sorry, I’m I dumb ass. I had the FTP pointing to the wrong files. LOL

Now I need to know if it will brake the bonding if I brige the Bonding1 interface to the ether1 interface?
Going to try it anyway. I’ll let ya know!

4

Bridging is working!
Now if I can figure out the packing.

5

Winbox does not give me the option to set the slaves to EoIP, only ether ports.
This wouldn’t be a problem if I could figure out how to set the Link-Monitoring in the Terminal.
HELP!

6

if it says it’s 2.9beta16 - then it is 16 and upgrade didn’t happen. check your log (/log pri fo)

7

Sorry,
I edited my post to show what you are saying before you said it.


Could you please tell me how to edit the bonding interface in terminal or point me to the proper Doc’s so I can readup on the commands?

it’s 2:33 AM here in Louisiana so sorry if I’m not making moch since : ~

8

??? you pasted it youself:

http://www.mikrotik.com/docs/ros/2.9/interface/bonding

so what is not working, please describe your setup. what you have set up on one end, and what on the other ?

9

I am trying to change the Interface bonding link-monitor to arp. But in winbow the slaves show up as ether1 and ether1 where as the terminal show it right as eoip1 and eoip2.
So if i try to change the link-monitor seting or anything else it give me an error.
LOL, I guess what I need is for you to hold my hand and walk me thru the terminal commands on editing the bonding interface. LOL

10

the setup is simple like my; )
The bonding is working now, but I need to be able to setup the failover so if one line goes down the link to the location doesn’t go tits up.

11

Dim Light comes on!

12

save what and where ??

13

You guys are going to forse me to learn every little command in terminal arent you. LOL
I have it now, sorry for wasteing your time.

I’m hooked WinBox

14

:smiley: nice to see such quick progress

15

MEGA COOL!
I can now unplug one of the ethernet cables and the link stays up! YAHOOOO

16

I’m not the technical genius of our company, but I am the one that puts in the most time.
Joe “the tech master” gave up on the MT bonding because of some routeing problems, but me, I beleive MT can do it.

I’m going to set it up as a bridge first, and after all the bumps are hammered out I’ll try the routing.

17

Is there any way to prioritize the ACK Packet in MT?


On asymmetric Internet links like DSL and often Cable, a big upload that consumes all of the available upstream bandwidth can render the link almost unusable by producing a huge backlog in the DSL/Cable modem’s buffer, thus increasing the delay to several seconds. Because ACK packets (TCP acknowledgments) for received data are delayed or even lost as well, download speed drops, too.

This problem can be solved by prioritizing these ACK packets, so they will be sent out before any other upload packets.
Here’s how to do it with m0n0wall:

First of all, you need m0n0wall pb24 or later. Start by adding a new pipe to the traffic shaper. This is necessary because we need to move the upstream queue into m0n0wall (where the order in which packets are sent out can be changed while packets are in the queue) rather than the DSL/Cable modem. Once the packets are in the DSL/Cable modem’s output queue, there’s no way of having ACK packets sent out immediately anymore. Therefore, it is very important to set that pipe’s bandwidth to a value that is slightly below the effective upstream bandwidth of your Internet link. Don’t forget that e.g. 128 kbps ADSL line speed is only about 100 kbps effective. If you set this value too high, your modem buffer will still become full and prioritization will accomplish nothing.

When you have added that pipe, add two queues linked to that pipe with different weights, e.g. one queue with weight = 10 and one with weight = 1. The first queue becomes your high priority queue.

Now it’s time to add rules that classify upstream traffic into one of these two queues. There are loads of possibilities, e.g. prioritizing by TCP/UDP port, but for now we’ll focus on IP packet length and TCP flags. Add a new traffic shaper rule, link it to the first (high-priority) queue, interface = WAN, protocol = TCP, source = any, destination = any, direction = out, IP packet length 0-80, TCP flags: ACK = set, everything else = don’t care. It is not sufficient to classify packets into the high-priority queue based on the ACK flag only, because (big) upstream TCP data packets can have the ACK flag set as well. 0-80 is just an example to get you started. Save the rule, and add another one below it, linked to the second (low priority) queue, interface = WAN, protocol = any, source = any, destination = any, direction = out. Enable the traffic shaper if necessary, apply the changes - that’s it. Here are a few points to remember:

make sure no upstream Internet traffic can bypass the pipe
*

despite ACK prioritization, the delay will still go up, as it is not possible to stop sending a big packet mid-way. For example, a full-size (1500 bytes) packet at 100 kbps will take 120 ms
*

if you want to be able to surf the web while performing a large upload, you’ll also have to prioritize HTTP upstream traffic (i.e. destination port = 80) - otherwise, TCP SYN packets (for connection establishment) to web servers will not get prioritized, and there will be a big initial delay until a connection is established. Prioritizing DNS packets is a good idea as well.
*

If you want to find out what prioritization does for you, add a rule to classify outgoing ICMP packets into the high-priority queue and try pinging some Internet host while you’re uploading - once with the traffic shaper on, and once off. There should be a huge difference in response times.

18

me thinks you can already do it with routeros v 2.9, marking all ack packets in mangle, and then prioritizing them in queue tree. please note that no prioritization will happen if you will not mark and enqueue also everything else except the ack, so at least two mangles and at least two queues would be needed

19

What would you guys think the MTU should be set to on the packing. I’m compressing all. Please keep in mind that this is going to connect to PPPoE ADSL so the MTU is supose to be set to 1492 on the BellSouth network

20

I think I may have a problem.
Side A is a /24 and I have ether1 2 and 3 in that same subnet, so I only have one gateway.
But on side B I have ether1 being bridged over to ether1 on the A side and ether2 and 3 are on different subnets.