Community discussions

MikroTik App
 
kenknight
just joined
Topic Author
Posts: 15
Joined: Tue Mar 12, 2013 3:03 pm

Dual WAN bonding works ... sorta

Mon Apr 07, 2014 11:49 pm

Hi all,

We have two pipes here in our office, one is a fiber (20x20) and the secondary is a cabel modem (60x5). I recently implemented what I believe is labeled as bonding failover (probably incorrect). And it has worked well with a few exceptions. We have some remote users that take advantage of VoIP, RDP and VPN. They seem to having some issues keeping connections and I'm guessing it has something to do with the routing of the packets. Below is the exact code I implemented:
/ip firewall mangle


add chain=input in-interface=WAN1 action=mark-connection new-connection-mark=WAN1_conn
add chain=input in-interface=WAN2 action=mark-connection new-connection-mark=WAN2_conn


add chain=output connection-mark=WAN1_conn action=mark-routing new-routing-mark=to_WAN1
add chain=output connection-mark=WAN2_conn action=mark-routing new-routing-mark=to_WAN2


add chain=prerouting dst-address=192.168.105.0/24 action=accept in-interface=bridge-local
add chain=prerouting dst-address=MORE subnets action=accept in-interface=bridge-local


add chain=prerouting dst-address-list=!local in-interface=bridge-local per-connection-classifier=both-addresses-and-ports:2/0 action=mark-connection new-connection-mark=WAN1_conn passthrough=yes
add chain=prerouting dst-address-list=!local in-interface=bridge-local per-connection-classifer=both-addresses-and-ports:2/1 action=mark-connection new-connection-mark=WAN2_conn passthrough=yes

// Change the packets that have a mark of WANx_conn to handle the routing to the appropriate WAN port.
add chain=prerouting connection-mark=WAN1_conn in-interface=bridge-local action=mark-routing new-routing-mark=to_WAN1
add chain=prerouting connection-mark=WAN2_conn in-interface=bridge-local action=mark-routing new-routing-mark=to_WAN2


/ip route
add dst-address=0.0.0.0/0 gateway=xx.xx.xx.xx routing-mark=to_WAN1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=xx.xx.xx.xx routing-mark=to_WAN2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=xx.xx.xx.xx distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=xx.xx.xx.xx distance=2 check-gateway=ping


There is a video on youtube that details all this for wireless backhaul links: https://www.youtube.com/watch?v=ECqntLlhaz8
The thing that concerns me are the additional route entries found in the routes table that are automatically added by the OS.
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          204.116.xx.xx            1
 1   S  0.0.0.0/0                          192.168.44.1              1
 2 A S  0.0.0.0/0                          204.116.xx.xx            1
 3   S  0.0.0.0/0                          192.168.44.1              2
 4 X S  0.0.0.0/0                          204.116.xx.xx            1
 5 ADC  192.168.105.0/24   192.168.105.1   bridge-local              0
 6 ADC  204.116.xx.xx/29  204.116.xx.xx  ether1-spirit             0

ip route
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\
    204.116.xx.xx routing-mark=to_WAN1 scope=30 target-scope=10
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\
    192.168.44.1 routing-mark=to_WAN2 scope=30 target-scope=10
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\
    204.116.xx.xx scope=30 target-scope=10
add check-gateway=ping disabled=no distance=2 dst-address=0.0.0.0/0 gateway=\
    192.168.44.1 scope=30 target-scope=10
add disabled=yes distance=1 dst-address=0.0.0.0/0 gateway=204.116.xx.xx \
    scope=30 target-scope=10
So the question is could be caused by the double nat'ing of the cable modem (comes in on a 194.168.44.x and gets nat'd to 192.168.105.x) or are the additional routes that are automatically added by the OS causing some kind of packet confusion?

Any suggestions would be greatly appreciated.

Thanks,
Ken
 
nerdtron
Member Candidate
Member Candidate
Posts: 123
Joined: Sat Nov 30, 2013 7:49 am

Re: Dual WAN bonding works ... sorta

Wed Apr 09, 2014 2:51 pm

Yes, I think you'll have a problem using VOIP, RDP and VPN since they need a fixed connection while PCC will tend to shoot the packets on different wan paths.
You can try to change the you per-connection-classifier to source address only or destination address only.
Or you can also create dedicated mangle marks on the IP block of users of VOIP RDP and VPN and then direct their traffic to only one path.
 
whoknew
Member Candidate
Member Candidate
Posts: 145
Joined: Wed Oct 13, 2010 8:51 pm

Re: Dual WAN bonding works ... sorta

Wed Apr 23, 2014 12:02 am

Are the inputs to mark the new-connection set to passthrough?
Are the outputs to add the new-routing-marks set to passthrough?
Are the prerouting accepts set to passthrough?
Are the prerouting to add the new-routing-marks set to passthrough?

Are they supposed to be?
 
kenknight
just joined
Topic Author
Posts: 15
Joined: Tue Mar 12, 2013 3:03 pm

Re: Dual WAN bonding works ... sorta

Thu Oct 23, 2014 7:04 pm

I'm am just getting back on this (after several months).

I worked on this again this morning and got everything work. The key was taking nerdtron's advice and putting in a prerouting mangle rule just above where the PCC takes place that goes ahead and marks connections on specific ports to use WAN1. Then in the normal PCC rules, I only do the PCC on packets that do NOT have the WAN1 mark already.

Hopefully this will help someone else.

Regards,
Ken

Who is online

Users browsing this forum: Bing [Bot], chaigeo, mlaz, nocivo, saathiyabneha, safik and 62 guests