OpenWrt Forum Archive

Topic: mwan3; multi-wan policy routing (general topic)

The content of this topic has been archived between 22 May 2013 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

pier4r wrote:

Nice, thanks. Maybe we could write it on the wiki page? I didn't know it (i thought was the latest)

Suggestion: i don't know if github provides a bit of space for distribution of binaries, in the case github does not, what about a public dropbox folder o similar?

Is there a reason you can't just install from opkg or through LuCI or download the file from the OpenWrt downloads pages?

http://downloads.openwrt.org/snapshots/ … /packages/

(Last edited by arfett on 16 Apr 2015, 17:26)

arfett wrote:

Is there a reason you can't just install from opkg or through LuCI or download the file from the OpenWrt downloads pages?

http://downloads.openwrt.org/snapshots/ … /packages/

Hmm, i know that the package is very good but i didn't analyzed it thoroughly, therefore, using owrt 12.09 i don't know if i can take it from the trunk repositories.

I mean, i always used the linked provided (so the 1.4-24 version) and it worked, i'm happy and unfortunately i don't have too much time to test eventual problems (sorry). But i can understand that is already great that this package is provided for free with open source, so i just asked, i don't want to criticize smile .

At the end for personal purposes i just made a mirror on the local server.

Hi, another prospective mwan3/OpenVPN user here. Like others in this thread, I'm having trouble setting the default route metric on the tun0 interface, and have it detected by mwan3. Here's my routing table:

root@openwrt:~# ip -4 route
0.0.0.0/1 via 10.165.1.5 dev tun0 
default via 100.8.122.1 dev eth1  proto static  metric 10 
10.165.1.1 via 10.165.1.5 dev tun0  metric 20 
10.165.1.5 dev tun0  proto kernel  scope link  src 10.165.1.6 
100.8.122.0/24 dev eth1  proto static  scope link  metric 10 
108.61.57.220 via 100.8.122.1 dev eth1 
128.0.0.0/1 via 10.165.1.5 dev tun0 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 
192.168.2.0/24 dev eth0.2  proto kernel  scope link  src 192.168.2.1 

As you can see, the desired metric (20) is applied, but not to the default route.

I'm using a commercial VPN provider, and I suspect they're using 'redirect-gateway def1'.

Someone previously mentioned https://community.openvpn.net/openvpn/w … ectGateway - has anyone tried these workarounds, successfully or not?

Hi alastair,

Looking at the link you posted, i think it will work. Try adding to following lines to your OpenVPN client config:

route-nopull
route 0.0.0.0 0.0.0.0 vpn_gateway 20

If i'm not mistaken, this will set a default route towards your vpn_gateway with metric 20. Note: vpn_gateway keyword is a special build-in OpenVPN macro, so do not replace it with an ip address.

More info: https://community.openvpn.net/openvpn/w … wsAndError

Please let me know if this works, as we can then add it to the wiki

(Last edited by Adze on 27 Apr 2015, 10:41)

Adze wrote:

Hi alastair,

Looking at the link you posted, i think it will work. Try adding to following lines to your OpenVPN client config:

route-nopull
route 0.0.0.0 0.0.0.0 vpn_gateway 20

If i'm not mistaken, this will set a default route towards your vpn_gateway with metric 20. Note: vpn_gateway keyword is a special build-in OpenVPN macro, so do not replace it with an ip address.

More info: https://community.openvpn.net/openvpn/w … wsAndError

Please let me know if this works, as we can then add it to the wiki

That works just fine, thanks!

root@openwrt:/etc# ip route
default via 100.8.122.1 dev eth1  proto static  metric 10 
default via 10.166.1.9 dev tun0  metric 20 
10.166.1.9 dev tun0  proto kernel  scope link  src 10.166.1.10 
100.8.122.0/24 dev eth1  proto static  scope link  metric 10 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 
192.168.2.0/24 dev eth0.2  proto kernel  scope link  src 192.168.2.1 
darkdje wrote:

Hi Adze and thank you for mwan3

For now everything works fine when using as load balancing, but that's not my final goal here
I tried to configure it to do one thing. I have two network:

The first one is a simple internet connection than I connect to wan interface. As it's coming from my internet provider it give me
a IP: 192.168.2.0/24  // GW: 192.168.2.1  // DNS:192.168.2.1 by DHCP

The second one is a private network. It give also everything by DHCP: IP: 128.127.15.0/24 // GW: 128.127.15.1 //DNS: 172.26.101.1. This network is here to provide just a few "url" like "timing-data.aks"

So What I want to do is to force the DNS resolution of "timing-data.aks" with 172.26.101.1 DNS and show the page with the good network. All the others web access will be redirect to the internet connection.

After reading a lot of page here, I've seen "fovecifer" who wanted to do almost the same with a vpn but maybe not in DNS point of view.

1. He create an "ipset" for his particular url
As I've never configured network whitout GUI, I don't really know which file to modify with my ssh access and what to write in it.

2. I think I have to configure my DNSMasq to resolv timing-data.aks with the good DNS and write it into ipset
I think that everything as to be done in /etc/config/dhcp but I don't really know which line to add.

3. I think that here I have to configure mwan3 rules to transfer all the network to wan exept for my ipset to wan2.
This one, I think I understand how to type it  but I will see when I will succeed for 1 and 2.

Am I in the good direction to make my network working?

PS: sorry for my bad english

Adze wrote:

Hi darkdje,

What you are trying to do is pretty straightforward. First make sure you have the correct software versions running. You need dnsmasq with ipset support; ipset version 6.24 and mwan3 version 1.6-1 (or higher ofcourse). Make sure that you have a mwan3 rule configured that routes traffic towards 172.26.101.1 over correct wan.

You need to edit /etc/dnsmasq.conf and add the following lines.

#Lookup timing-data.aks at specific dns server
server=/timing-data.aks/172.26.101.1
#populate ipset timing-data with timing-data.aks resolv results 
ipset=/timing-data.aks/timing-data

After dnsmasq restart, you can use the ipset "timing-data" in your mwan3 rules. Good luck

I only try it today and unfortunatly it doesn't work

I tried a nslookup of the url trought the router and it says that their its not internaly register (not sur of the word mine is in frenche). However, if I force nslookup with 172.26.101.1 it give me the right ip adress.

In mwan3 I have:
1- Destiation dressa: 172.26.101.1/32 wan2_only
2- ipset: timing-data wan2_only
3- Source address: 0.0.0.0/0 wan_anly

maybe i have done something wrong.

When I check the ipset (ipset list timing). Their no address in it.

(Last edited by darkdje on 28 Apr 2015, 20:07)

darkdje wrote:

maybe i have done something wrong.

Show us your configs so we can look at them.

So Here is my config file. I have wan1 offline. What I tried to do is make Wan2 working, but my computer answer with DNS problem. I will add wan1 after.

Mwan Config

config policy 'wan2_only'
    list use_member 'wan2_m1_w2'
    option last_resort 'default'

config policy 'wan_only'
    list use_member 'wan_m1_w3'
    option last_resort 'default'

config policy 'balanced'
    list use_member 'wan_m1_w3'
    list use_member 'wan2_m1_w2'

config policy 'wan_wan2'
    list use_member 'wan_m1_w3'
    list use_member 'wan2_m2_w2'

config policy 'wan2_wan'
    list use_member 'wan_m2_w3'
    list use_member 'wan2_m1_w2'

config rule 'dns_alk'
    option dest_ip '172.26.101.1/32'
    option proto 'all'
    option sticky '0'
    option use_policy 'wan2_only'

config rule 'timing_data'
    option proto 'all'
    option sticky '0'
    option use_policy 'wan2_only'
    option ipset 'timing'

config rule 'cosworth_data'
    option proto 'all'
    option sticky '0'
    option ipset 'cosworth'
    option use_policy 'wan2_only'

config rule 'fiawec'
    option proto 'all'
    option sticky '0'
    option ipset 'fia'
    option use_policy 'wan2_only'

config rule 'alk_tcp_port'
    option dest_port '10011'
    option proto 'tcp'
    option sticky '0'
    option use_policy 'wan2_only'

config rule 'alk_udp_port'
    option dest_port '10011'
    option sticky '0'
    option use_policy 'wan2_only'
    option proto 'udp'

config rule 'default_rule'
    option dest_ip '0.0.0.0/0'
    option proto 'all'
    option sticky '0'
    option use_policy 'wan_wan2'

config interface 'wan'
    list track_ip '8.8.4.4'
    list track_ip '8.8.8.8'
    list track_ip '208.67.222.222'
    list track_ip '208.67.220.220'
    option reliability '2'
    option count '1'
    option timeout '2'
    option interval '5'
    option down '3'
    option up '8'
    option enabled '1'

config interface 'wan2'
    option reliability '1'
    option count '1'
    option timeout '2'
    option interval '5'
    option down '3'
    option up '8'
    option enabled '1'
    list track_ip '128.127.15.1'

config member 'wan_m1_w3'
    option interface 'wan'
    option metric '1'
    option weight '3'

config member 'wan_m2_w3'
    option interface 'wan'
    option metric '2'
    option weight '3'

config member 'wan2_m1_w2'
    option interface 'wan2'
    option metric '1'
    option weight '2'

config member 'wan2_m2_w2'
    option interface 'wan2'
    option metric '2'
    option weight '2'

Network Config

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fdf9:81e2:cf68::/48'

config interface 'lan'
    option ifname 'eth0.1'
    option force_link '1'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ipaddr '192.168.2.1'
    option gateway '192.168.2.1'
    option broadcast '192.168.2.255'

config interface 'wan'
    option ifname 'eth0.2'
    option proto 'dhcp'
    option metric '10'

config interface 'wan6'
    option ifname 'eth0.2'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'
    option mirror_source_port '0'
    option enable_vlan4k '1'
    option mirror_monitor_port '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '2 3 4 5t'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0 5t'

config switch_vlan
    option device 'switch0'
    option vlan '3'
    option ports '1 5t'

config interface 'wan2'
    option proto 'dhcp'
    option ifname 'eth0.3'
    option metric '20'

config switch_vlan
    option device 'switch0'
    option vlan '4'
    option ports '5t'

config interface 'hotspot'
    option proto 'static'
    option ifname 'eth0.4'
    option ipaddr '192.168.200.1'
    option netmask '255.255.255.0'
    option type 'bridge'
    option defaultroute '0'

Mwan Statut

Interface status:
interface wan is offline (tracking down)
interface wan2 is online (tracking active)

Policy balanced:
wan2 (100%)

Policy wan2_only:
wan2 (100%)

Policy wan2_wan:
wan2 (100%)

Policy wan_only:
default

Policy wan_wan2:
wan2 (100%)

Known networks:
192.168.2.0
127.0.0.0/8
128.127.15.1
192.168.2.255
192.168.2.1
192.168.200.0/24
192.168.2.0/24
128.127.15.0
192.168.200.255
127.255.255.255
224.0.0.0/3
127.0.0.0
192.168.200.0
128.127.15.152
128.127.15.255
192.168.200.1
128.127.15.0/24
127.0.0.1

Active rules:
  332 21196 - wan2_only  all  --  *      *       0.0.0.0/0            172.26.101.1         
    0     0 - wan2_only  all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set timing dst
    0     0 - wan2_only  all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set cosworth dst
    0     0 - wan2_only  all  --  *      *       0.0.0.0/0            0.0.0.0/0            match-set fia dst
    0     0 - wan2_only  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport sports 0:65535 multiport dports 10011
    0     0 - wan2_only  udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport sports 0:65535 multiport dports 10011
4026  437K - wan_wan2  all  --  *      *       0.0.0.0/0            0.0.0.0/0

dnsmasq.conf

# Change the following lines if you want dnsmasq to serve SRV
# records.
# You may add multiple srv-host lines.
# The fields are <name>,<target>,<port>,<priority>,<weight>

# A SRV record sending LDAP for the example.com domain to
# ldapserver.example.com port 289
#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389

# Two SRV records for LDAP, each with different priorities
#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,1
#srv-host=_ldap._tcp.example.com,ldapserver.example.com,389,2

# A SRV record indicating that there is no LDAP server for the domain
# example.com
#srv-host=_ldap._tcp.example.com

# The following line shows how to make dnsmasq serve an arbitrary PTR
# record. This is useful for DNS-SD.

# The fields are <name>,<target>
#ptr-record=_http._tcp.dns-sd-services,"New Employee Page._http._tcp.dns-sd-ser$

# Change the following lines to enable dnsmasq to serve TXT records.
# These are used for things like SPF and zeroconf.
# The fields are <name>,<text>,<text>...

#Example SPF.
#txt-record=example.com,"v=spf1 a -all"

#Example zeroconf
#txt-record=_http._tcp.example.com,name=value,paper=A4

# Provide an alias for a "local" DNS name. Note that this _only_ works
# for targets which are names from DHCP or /etc/hosts. Give host
# "bert" another name, bertrand
# The fields are <cname>,<target>
#cname=bertand,bert

#Address which look at specific DNS
server=/timing-data.aks/172.26.101.1
server=/cosworth-data.aks/172.26.101.1
server=/intranet.fiawec.com/172.26.101.1


#ipset creation with that specific rules
ipset=/timing-data.aks/timing
ipset=/cosworth-data.aks/cosworth
ipset=/intranet.fiawec.com/fia

After some hours of investigation, ti seems to work with adresse like www.URL.com but as my intranet url never work with www.timing-data.aks, but only with timing-data.aks, it seems that my DNSmasq doesn't work on them fine. I search for an option to work on that.

(Last edited by darkdje on 29 Apr 2015, 10:07)

Just wanted to say thanks so much to Adze - mwan3 is amazingly powerful, and it is is exactly the reason why I run OpenWRT in the first place. Thanks again.

darkdje wrote:

After some hours of investigation, ti seems to work with adresse like www.URL.com but as my intranet url never work with www.timing-data.aks, but only with timing-data.aks, it seems that my DNSmasq doesn't work on them fine. I search for an option to work on that.

That's pretty strange, as this is what dnsmasq example config has to say:

# Add the IPs of all queries to yahoo.com, google.com, and their
# subdomains to the vpn and search ipsets:
ipset=/yahoo.com/google.com/vpn,search

Which would suggest that it should also work without subdomain.

(Last edited by Adze on 30 Apr 2015, 20:56)

Adze wrote:
darkdje wrote:

After some hours of investigation, ti seems to work with adresse like www.URL.com but as my intranet url never work with www.timing-data.aks, but only with timing-data.aks, it seems that my DNSmasq doesn't work on them fine. I search for an option to work on that.

That's pretty strange, as this is what dnsmasq example config has to say:

# Add the IPs of all queries to yahoo.com, google.com, and their
# subdomains to the vpn and search ipsets:
ipset=/yahoo.com/google.com/vpn,search

Which would suggest that it should also work without subdomain.


Your *.timing-data.aks queries are being forwarded to a custom DNS server 172.26.101.1 . Does it respond properly?

dig @172.26.101.1 www.timing-data.aks

I am currently trying to set up mwan3, but I faced the following issue.

I have 2 WAN links, and they were tested OK, before proceeding to mwan3. Now, I am trying to test the failover feature, but it seems that it does not detect the link failure. I have a manageable switch that the router is connected to. Both ISPs are also attached to the same switch. I am imitating WAN link fault disabling the phy interface towards one of the providers, but mwan3 does not detect it.

Here are some dumps:

# The switch output first - see the interface is disabled administratively
sw1#sh int desc | i WAN
Fa0/1                          admin down     down     WAN1_ISP1_/24Mbps/
Fa0/2                          up             up       WAN2_ISP2_/45Mbps/

# eth0.2 - wan1 (that is passing via the disables port above)
# eth0.3 - wan2 (that is UP)
[root@RTR-TEST:~]# ping -c 3 -I eth0.3 4.2.2.2
PING 4.2.2.2 (4.2.2.2) from 46.249.80.XX eth0.3: 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_req=1 ttl=57 time=43.9 ms
64 bytes from 4.2.2.2: icmp_req=2 ttl=57 time=43.4 ms
^C
--- 4.2.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 43.420/43.690/43.961/0.341 ms

[root@RTR-TEST:~]# ping -c 3 -I eth0.2 4.2.2.2
PING 4.2.2.2 (4.2.2.2) from 46.40.125.XX eth0.2: 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_req=1 ttl=57 time=43.4 ms
64 bytes from 4.2.2.2: icmp_req=2 ttl=57 time=43.4 ms
64 bytes from 4.2.2.2: icmp_req=3 ttl=57 time=43.3 ms

--- 4.2.2.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 43.305/43.413/43.489/0.187 ms

# But traceroute shows:
[root@RTR-TEST:~]# traceroute -i eth0.2 4.2.2.2     
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 38 byte packets
 1  46.40.125.XX (46.40.125.XX)  2991.095 ms !H  *  995.269 ms !H
[root@RTR-TEST:~]# traceroute -i eth0.3 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 38 byte packets
 1  46-249-80-1.net1.bg (46.249.80.1)  0.486 ms  0.631 ms  0.412 ms
 2  T960-25.net1.bg (37.157.189.25)  0.793 ms  0.757 ms  0.440 ms
 3  37.157.189.1 (37.157.189.1)  0.656 ms  1.425 ms  1.261 ms
 4  37.157.189.2 (37.157.189.2)  0.921 ms  1.083 ms  0.777 ms
 5  212.162.46.121 (212.162.46.121)  1.564 ms  1.455 ms  0.971 ms
................................. (output truncated)     

# mwan3 still considers the wan1 as alive
[root@RTR-TEST:~]# mwan3 status
Interface status:
Interface wan1 is online (tracking active)
Interface wan2 is online (tracking active)

Policy balanced:
 wan2 (60%)
 wan1 (40%)

Policy wan1_only:
 wan1 (100%)

Policy wan1_wan2:
 wan1 (100%)

Policy wan2_only:
 wan2 (100%)

Policy wan2_wan1:
 wan2 (100%)

Known networks:
destination        policy             hits     
-----------------------------------------------
127.0.0.0/8        default            104      
................................. (output truncated)     

Active rules:
source             destination        proto  src-port      dest-port     policy          hits     
--------------------------------------------------------------------------------------------------
<Internal_host>      0.0.0.0/0          all                                wan1_only       98       
<Internal_host>     0.0.0.0/0          all                                wan2_only       86       
<Internal_host>      0.0.0.0/0          all                                wan1_wan2       0        
<Internal_host>     0.0.0.0/0          all                                wan2_wan1       0        
<Internal_host>     0.0.0.0/0          all                                wan2_wan1       0        
0.0.0.0/0          46.40.72.13        all                                wan1_only       130      
0.0.0.0/0          46.40.72.9         all                                wan1_only       37       
0.0.0.0/0          95.87.194.4        all                                wan2_only       2        
0.0.0.0/0          212.73.140.25      all                                wan1_wan2       0        
0.0.0.0/0          217.9.234.235      all                                wan1_wan2       0        
0.0.0.0/0          217.9.234.234      all                                wan2_wan1       0        
0.0.0.1/0.0.0.1    0.0.0.0/0          tcp    0:65535       443           wan2_wan1       31       
0.0.0.0/0          10.0.0.0/8         all                                MARK            55       
0.0.0.0/0          172.16.0.0/12      all                                MARK            0        
0.0.0.0/0          192.168.0.0/16     all                                MARK            0        
0.0.0.0/0          0.0.0.0/0          all                                balanced        568      

mwan3 is correctly configured:

[root@RTR-TEST:~]# cat /etc/config/mwan3

config interface 'wan1'
    option enabled '1'
    list track_ip '46.40.125.1'
    list track_ip '212.73.140.119'
    list track_ip '8.8.8.8'
    list track_ip '208.67.222.222'
    list track_ip '208.67.220.220'
    option reliability '3'
    option count '5'
    option timeout '2'
    option interval '20'
    option down '1'
    option up '3'

config interface 'wan2'
    option enabled '1'
    list track_ip '46.249.80.1'
    list track_ip '87.120.130.66'
    list track_ip '8.8.8.8'
    list track_ip '208.67.222.222'
    list track_ip '208.67.220.220'
    option reliability '3'
    option count '5'
    option timeout '2'
    option interval '20'
    option down '1'
    option up '3'

config member 'wan1_m10_w2'
    option interface 'wan1'
    option metric '10'
    option weight '2'

config member 'wan1_m20_w2'
    option interface 'wan1'
    option metric '20'
    option weight '2'

config member 'wan2_m10_w3'
    option interface 'wan2'
    option metric '10'
    option weight '3'

config member 'wan2_m20_w3'
    option interface 'wan2'
    option metric '20'
    option weight '3'

####################################
# POLICY:
####################################
config policy 'wan1_only'
        list use_member 'wan1_m10_w2'

config policy 'wan2_only'
        list use_member 'wan2_m10_w3'

config policy 'wan1_wan2'
        list use_member 'wan1_m10_w2'
        list use_member 'wan2_m20_w3'

config policy 'wan2_wan1'
        list use_member 'wan1_m20_w2'
        list use_member 'wan2_m10_w3'

config policy 'balanced'
        list use_member 'wan1_m10_w2'
        list use_member 'wan2_m10_w3'

####################################
# RULES:
####################################
................................. (output truncated)     

I also have to mention that I am using my own customly built firmware image in which I have swapped the busybox ping with the full package:
CONFIG_PACKAGE_iputils-ping=y
CONFIG_PACKAGE_iputils-ping6=y
The mwan3 package together with its luci module have been also integrated into the image.

I edited the Public address in the output, if you need more details, please give me an email to send them to.

p.s. missed another packages that may interfere with mwan3's operation

[root@RTR-TEST:~]# opkg list_installed | grep conntr
conntrack-tools - 1.0.0-1
iptables-mod-conntrack-extra - 1.4.21-1
kmod-ipt-conntrack - 3.10.49-1
kmod-ipt-conntrack-extra - 3.10.49-1
kmod-nf-conntrack-netlink - 3.10.49-1
libnetfilter-conntrack - 1.0.3-1

# Here is a notice while troubleshooting - seems like a mismatch in the NAT table:
[root@RTR-TEST:~]# conntrack -L | grep 8.8.8.8
icmp     1 29 src=46.249.80.XX dst=8.8.8.8 type=8 code=0 id=6210 packets=4 bytes=368 src=8.8.8.8 dst=46.249.80.XX type=0 code=0 id=6210 packets=4 bytes=368 mark=512 use=1
icmp     1 16 src=46.40.125.XX dst=8.8.8.8 type=8 code=0 id=6203 packets=5 bytes=460 src=8.8.8.8 dst=46.249.80.XX type=0 code=0 id=6203 packets=5 bytes=460 mark=512 use=1
conntrack v1.0.0 (conntrack-tools): 152 flow entries have been shown.

(Last edited by dir2cas on 10 May 2015, 21:02)

Hi dir2cas,


Your output (ping tests on eth0.2 and eth0.3) suggest that both wan interfaces are UP, as you get ping replies on both of them. Mwan3 relies on that. It is not a mwan3 problem...

Adze wrote:

Hi dir2cas,


Your output (ping tests on eth0.2 and eth0.3) suggest that both wan interfaces are UP, as you get ping replies on both of them. Mwan3 relies on that. It is not a mwan3 problem...

Yes, but it is exactly the problem. Ping was running despite the fact that the wan1 link was interrupted. It was done indirectly looking from the router's perspective, since no phy link to the router was interrupted, but the one to the ISP1 (wan1/eth0.2).

As you can see from the conntrack table output, seems like the ping -I eth0.2 somehow passes via the second wan, that was operational (eth0.3/wan2).

Actually the first issue was fixed after I modified the packet size of the ping that mwan3track is running. As I mentioned, I am using the full ping package (iputils-ping), which considers the preset mwan3track packet size as invalid (and it is actually):
-               ping -I $2 -c $4 -W $5 -s 4 -q $track_ip &> /dev/null
+              ping -I $2 -c $4 -W $5 -s 64 -q $track_ip &> /dev/null

It is good to change this value in the next version of your tool.

After fixing that, mwan3 started actually to do some real tracking and started logging some events. But here, I am facing the other issue, that was described in the previous post.

During the failover test, after the interruption of wan1 took place, some strange things started to happen:
- I can see failed ping via wan2, which is wan that was NOT interrupted
- but at the same time some of the pings passes successfully via wan1 (that is interrupted).

I will do a small modification of mwantrack in order to log the packet loss values and I will try show you the situation described.

My assumption so far, is that the issue is caused by a malfunction of the conntrack mechanism, that does not give the possibility mwan3 to detect the problem correctly, but will be glad if you can help me to further find the root cause.

(Last edited by dir2cas on 11 May 2015, 13:53)

OK, here is a dump from the 10 minutes test that I ran.

All the timestamps in the log and the switch output are 100% correct and syncronized, since the switch is also configured to send the logs to the router's syslog-ng.

1) I did a small modification of mwan3track in order to keep a track of the Packet loss towards each mwan3 trackable targets.

[root@RTR-TEST:~]# diff /rom/usr/sbin/mwan3track /usr/sbin/mwan3track 
--- /rom/usr/sbin/mwan3track
+++ /usr/sbin/mwan3track
@@ -13,15 +13,23 @@
 track_ips=$(echo $* | cut -d ' ' -f 9-99)
 host_up_count=0
 lost=0
+PLOSS_DEFAULT="100"     #Default Packet loss rate in %
+PLOSS_THRESHOLD="5"     #Packet loss rate in %, that triggers host condition change (up|down)
 
 while true; do
 
     for track_ip in $track_ips; do
-        ping -I $2 -c $4 -W $5 -s 4 -q $track_ip &> /dev/null
-        if [ $? -eq 0 ]; then
+        #ping -I $2 -c $4 -W $5 -s 4 -q $track_ip &> /dev/null
+        PING_RESULT=$($(which ping) -I $2 -c $4 -W $5 -s 64 -q $track_ip | grep "packet loss") &> /dev/null
+        PLOSS=$(echo "${PING_RESULT}" | sed -e 's/^.*received, //' -e 's/^.*errors, //' -e 's/% packet loss.*//')
+        if [ -z "${PLOSS}" ]; then PLOSS=${PLOSS_DEFAULT}; fi
+        
+        #if [ $? -eq 0 ]; then
+        if [ "${PLOSS}" -le "${PLOSS_THRESHOLD}" ]; then
             let host_up_count++
         else
             let lost++
+            logger -t mwan3track -p notice "Tracked host issue detected on Interface $1 ($2): $track_ip -> ${PLOSS}% packet loss"
         fi
     done
         
[root@RTR-TEST:~]# 

2) The mwan3 interface configuration

[root@RTR-TEST:~]# cat /etc/config/mwan3

config interface 'wan1'
    option enabled '1'
    list track_ip '46.40.125.1'
    list track_ip '212.73.140.119'
    list track_ip '8.8.8.8'
    list track_ip '208.67.222.222'
    list track_ip '208.67.220.220'
    option reliability '3'
    option count '5'
    option timeout '2'
    option interval '20'
    option down '1'
    option up '3'

config interface 'wan2'
    option enabled '1'
    list track_ip '46.249.80.1'
    list track_ip '87.120.130.66'
    list track_ip '8.8.8.8'
    list track_ip '208.67.222.222'
    list track_ip '208.67.220.220'
    option reliability '3'
    option count '5'
    option timeout '2'
    option interval '20'
    option down '1'
    option up '3'

3) Test started - the switchport facing the ISP1 is administratively disabled (switch logging can be seen in the router's log as mentioned).

sw1#
sw1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw1(config)#int fa 0/1
sw1(config-if)#shut
sw1(config-if)#^Z
sw1#sh int desc | i WAN
Fa0/1                          admin down     down     WAN1_/24Mbps/
Fa0/2                          up             up       WAN2_/45Mbps/
sw1#sh clock           
20:02:17.252 EEST Mon May 11 2015
sw1#
sw1#
sw1#conf t             
Enter configuration commands, one per line.  End with CNTL/Z.
sw1(config)#int fa 0/1
sw1(config-if)#no shut
sw1(config-if)#^Z
sw1#sh int desc | i WAN
Fa0/1                          up             up       WAN1_/24Mbps/
Fa0/2                          up             up       WAN2_/45Mbps/
sw1#sh clock           
20:08:58.666 EEST Mon May 11 2015
sw1#

4) After WAN1 interruption you can see that there are several trackable hosts that seems pingable via the disables link (wan1), but the ping failes via the operational link (wan2).
It even happened 2 times for those 10 minutes that the wan1 was detected to go UP and down again after a while. Through the whole period the switch port handling the link to ISP1 (t.e. wan1) was down, so no ping should ever pass via wan1(eth0.2).

There are several failed pings via wan2 (that fully operational at this moment) on a random bases (I suppose)

May 11 20:02:13 sw1 2001: May 11 20:02:12 EEST: %SYS-5-CONFIG_I: Configured from console by dir2cas on vty0
May 11 20:02:14 sw1 2002: May 11 20:02:13 EEST: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
May 11 20:02:15 sw1 2003: May 11 20:02:14 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
May 11 20:02:20 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 208.67.220.220 -> 100% packet loss
May 11 20:02:32 RTR-TEST mwan3track: Tracked host issue detected on Interface wan2 (eth0.3): 208.67.220.220 -> 100% packet loss
May 11 20:02:38 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:02:42 RTR-TEST mwan3track: Tracked host issue detected on Interface wan2 (eth0.3): 8.8.8.8 -> 100% packet loss
May 11 20:03:08 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 208.67.222.222 -> 100% packet loss
May 11 20:03:14 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 8.8.8.8 -> 100% packet loss
May 11 20:03:20 RTR-TEST mwan3track: Tracked host issue detected on Interface wan2 (eth0.3): 208.67.222.222 -> 100% packet loss
May 11 20:03:24 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:03:24 RTR-TEST mwan3track: Interface wan1 (eth0.2) is offline
May 11 20:03:24 RTR-TEST mwan3: ifdown interface wan1 (eth0.2)
May 11 20:03:26 RTR-TEST mwan3track: Tracked host issue detected on Interface wan2 (eth0.3): 8.8.8.8 -> 100% packet loss
May 11 20:03:28 RTR-TEST root: stopping ntpclient
May 11 20:04:10 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:04:10 RTR-TEST mwan3track: Lost 20 ping(s) on interface wan1 (eth0.2)
May 11 20:04:52 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:04:52 RTR-TEST mwan3track: Lost 5 ping(s) on interface wan1 (eth0.2)
May 11 20:05:34 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:05:34 RTR-TEST mwan3track: Lost 5 ping(s) on interface wan1 (eth0.2)
May 11 20:05:35 RTR-TEST mwan3track: Interface wan1 (eth0.2) is online
May 11 20:05:35 RTR-TEST mwan3: ifup interface wan1 (eth0.2)
May 11 20:05:38 RTR-TEST firewall: Reloading firewall due to ifup of wan1 (eth0.2)
May 11 20:05:41 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 208.67.220.220 -> 100% packet loss
May 11 20:05:52 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 212.73.140.119 -> 100% packet loss
May 11 20:05:55 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:05:56 RTR-TEST mwan3track: Interface wan1 (eth0.2) is offline
May 11 20:06:01 RTR-TEST mwan3track: Tracked host issue detected on Interface wan2 (eth0.3): 208.67.222.222 -> 100% packet loss
May 11 20:06:11 RTR-TEST mwan3track: Tracked host issue detected on Interface wan2 (eth0.3): 87.120.130.66 -> 100% packet loss
May 11 20:06:41 RTR-TEST mwan3: ifdown interface wan1 (eth0.2)
May 11 20:06:45 RTR-TEST mwan3track: Tracked host issue detected on Interface wan2 (eth0.3): 208.67.222.222 -> 60% packet loss
May 11 20:07:26 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:07:26 RTR-TEST mwan3track: Lost 20 ping(s) on interface wan1 (eth0.2)
May 11 20:08:09 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:08:09 RTR-TEST mwan3track: Lost 5 ping(s) on interface wan1 (eth0.2)
May 11 20:08:51 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:08:51 RTR-TEST mwan3track: Lost 5 ping(s) on interface wan1 (eth0.2)
May 11 20:08:51 RTR-TEST mwan3track: Interface wan1 (eth0.2) is online
May 11 20:08:51 RTR-TEST mwan3: ifup interface wan1 (eth0.2)
May 11 20:08:55 sw1 2004: May 11 20:08:54 EEST: %SYS-5-CONFIG_I: Configured from console by dir2cas on vty0
May 11 20:08:55 RTR-TEST firewall: Reloading firewall due to ifup of wan1 (eth0.2)
May 11 20:08:56 sw1 2005: May 11 20:08:55 EEST: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
May 11 20:08:56 sw1 2006: May 11 20:08:56 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
May 11 20:08:58 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 208.67.220.220 -> 100% packet loss
May 11 20:09:08 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 8.8.8.8 -> 100% packet loss
May 11 20:09:17 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 11 20:09:17 RTR-TEST mwan3track: Interface wan1 (eth0.2) is offline
May 11 20:09:25 RTR-TEST root: starting ntpclient
May 11 20:09:27 RTR-TEST mwan3: ifdown interface wan1 (eth0.2)
May 11 20:09:30 RTR-TEST root: stopping ntpclient
May 11 20:10:11 RTR-TEST mwan3track: Lost 15 ping(s) on interface wan1 (eth0.2)
May 11 20:11:31 RTR-TEST mwan3track: Interface wan1 (eth0.2) is online
May 11 20:11:32 RTR-TEST mwan3: ifup interface wan1 (eth0.2)
May 11 20:11:35 RTR-TEST firewall: Reloading firewall due to ifup of wan1 (eth0.2)
May 11 20:11:36 RTR-TEST root: starting ntpclient

5) You can see that even after the switch port towards ISP1 was brought up which should lead to a fully operational wan1, mwan3 detects a link fault and after more than 2 minutes restores the link again as it should.

As a conclusion, I am currently not able to identify the root cause. It is related either with the conntrack package/mechanism or with mwan3 marking rules.

Any ideas would be fairly helful.

BR, dir2cas

Is it possible to use mwan3 to configure 3G connection as a failover, but only for outgoing traffic coming from one specific host inside the network? Can mwan3 execute some script (event handler) when switching connections?

dir2cas wrote:

5) You can see that even after the switch port towards ISP1 was brought up which should lead to a fully operational wan1, mwan3 detects a link fault and after more than 2 minutes restores the link again as it should.

Any ideas would be fairly helful.

BR, dir2cas

As you altered the ping size in mwan3track, you should also change the lines 169, 170 and 174 in /etc/hotplug.d/iface/15-mwan3 file. You should set the length to (28 + #ping size). This is probably the reason that lines do not correctly fail back.

belliash wrote:

Is it possible to use mwan3 to configure 3G connection as a failover, but only for outgoing traffic coming from one specific host inside the network?

Yes

belliash wrote:

Can mwan3 execute some script (event handler) when switching connections?

Yes, You can place your own scripts in /etc/hotplug.d/iface/

Adze wrote:
dir2cas wrote:

5) You can see that even after the switch port towards ISP1 was brought up which should lead to a fully operational wan1, mwan3 detects a link fault and after more than 2 minutes restores the link again as it should.

Any ideas would be fairly helful.

BR, dir2cas

As you altered the ping size in mwan3track, you should also change the lines 169, 170 and 174 in /etc/hotplug.d/iface/15-mwan3 file. You should set the length to (28 + #ping size). This is probably the reason that lines do not correctly fail back.

Right.
I found it yesterday after performing the test. In fact the "ping -s 8" does the job (it produces normal ping request/reply). This corresponds to a packet length of 36 bytes.

In fact after this correction, I do not see drops on the operational wan2, but the wan1 tracking (that is interrupted) works correctly only for the wan1's gateway. The other target hosts do not get detected.

dir2cas wrote:

In fact after this correction, I do not see drops on the operational wan2, but the wan1 tracking (that is interrupted) works correctly only for the wan1's gateway. The other target hosts do not get detected.

Can you confirm with tcpdump that the ping requests do leave the correct interface?

Adze wrote:
dir2cas wrote:

In fact after this correction, I do not see drops on the operational wan2, but the wan1 tracking (that is interrupted) works correctly only for the wan1's gateway. The other target hosts do not get detected.

Can you confirm with tcpdump that the ping requests do leave the correct interface?

All the tests done so far are pointing to the same problem.

Here is the latest one, that proves it. If you want tcpdump tests, I will have to check it doing some port mirroring on the switch, because this is e test router that has no tcpdump installed and has no free space because of the custom image that is full with different stiff. I hope that iftop is enough.

1) Switch port facing ISP1 (wan1) disabled

sw1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
sw1(config)#int fa 0/1
sw1(config-if)#shu
sw1(config-if)#shutdown
sw1(config-if)#
sw1(config-if)#^Z
sw1#sh int desc | i WAN
Fa0/1                          admin down     down     WAN1_/24Mbps/
Fa0/2                          up             up       WAN2_/45Mbps/

2) Ping test using the same parameters like mwan3track (I restored the initial code). Here I used one of the host targets that is tracked only via wan1.
The purpose is that we would like the ping to be treated by mwan3 the same way as it is done by the real tracking tool (mwan3track). You can see that ping is successful, despite the wan1 link is interrupted.

[root@RTR-TEST:~]# $(which ping) -c 5 -W 1 -s 4 -I eth0.2 212.73.140.119
PING 212.73.140.119 (212.73.140.119) from 46.40.125.XX eth0.2: 4(32) bytes of data.
12 bytes from 212.73.140.119: icmp_req=1 ttl=59
12 bytes from 212.73.140.119: icmp_req=2 ttl=59
12 bytes from 212.73.140.119: icmp_req=3 ttl=59
12 bytes from 212.73.140.119: icmp_req=4 ttl=59
12 bytes from 212.73.140.119: icmp_req=5 ttl=59

--- 212.73.140.119 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms

[root@RTR-TEST:~]# $(which ping) -c 5 -W 1 -s 4 -I eth0.2 212.73.140.119
PING 212.73.140.119 (212.73.140.119) from 46.40.125.XX eth0.2: 4(32) bytes of data.
12 bytes from 212.73.140.119: icmp_req=1 ttl=59
12 bytes from 212.73.140.119: icmp_req=2 ttl=59
12 bytes from 212.73.140.119: icmp_req=3 ttl=59
12 bytes from 212.73.140.119: icmp_req=4 ttl=59
12 bytes from 212.73.140.119: icmp_req=5 ttl=59

--- 212.73.140.119 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
[root@RTR-TEST:~]# cat /etc/config/mwan3 | head -n 29

config interface 'wan1'
        option enabled '1'
        list track_ip '46.40.125.1'
        list track_ip '212.73.140.119'
        list track_ip '8.8.8.8'
        list track_ip '208.67.222.222'
        list track_ip '208.67.220.220'
        option reliability '3'
        option count '5'
        option timeout '2'
        option interval '20'
        option down '1'
        option up '3'

config interface 'wan2'
        option enabled '1'
        list track_ip '46.249.80.1'
        list track_ip '87.120.130.66'
        list track_ip '8.8.8.8'
        list track_ip '208.67.222.222'
        list track_ip '208.67.220.220'
        option reliability '3'
        option count '5'
        option timeout '2'
        option interval '20'
        option down '1'
        option up '3'

3) Iftop verifies that no traffic is passing via wan1(eth0.2) / ISP1 link, which should be correct

[root@RTR-TEST:~]# iftop -n -P -f "icmp" -i eth0.2

                           12.5kb                      25.0kb                     37.5kb                      50.0kb                62.5kb
└──────────────────────────┴───────────────────────────┴──────────────────────────┴───────────────────────────┴───────────────────────────

4) However the ping towards 212.73.140.119 is seen on wan2 (eth0.3). As seen above 212.73.140.119 is not part of the wan2 target hosts eligible for tracking.

[root@RTR-TEST:~]# iftop -n -P -f "icmp" -i eth0.3

                           12.5kb                      25.0kb                     37.5kb                      50.0kb                62.5kb
└──────────────────────────┴───────────────────────────┴──────────────────────────┴───────────────────────────┴───────────────────────────
46.249.80.XX                                            => 212.73.140.119                                           384b    256b    185b
                                                        <=                                                          384b    256b    185b
46.249.80.XX                                            => 8.8.8.8                                                    0b    128b     71b
                                                        <=                                                            0b    128b     71b
46.249.80.XX                                            => 192.58.128.30                                              0b    115b     64b
                                                        <=                                                            0b    115b     64b
46.249.80.XX                                            => 208.67.222.222                                             0b    102b     71b
                                                        <=                                                            0b    102b     57b

5) The log - mwan3 detects the fault only towards wan1's gateway, but not to the other trackable targets.

May 13 11:37:46 sw1 2066: May 13 11:37:45 EEST: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
May 13 11:37:46 sw1 2067: May 13 11:37:46 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
May 13 11:37:46 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 60% packet loss
May 13 11:38:31 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:39:14 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:39:56 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:40:42 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:41:25 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:41:31 sw1 2068: May 13 11:41:30 EEST: %SYS-5-CONFIG_I: Configured from console by dir2cas on vty0 (10.0.20.200)
May 13 11:42:05 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:42:48 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:43:33 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:44:18 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:44:59 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:45:42 RTR-TEST mwan3track: Tracked host issue detected on Interface wan1 (eth0.2): 46.40.125.1 -> 100% packet loss
May 13 11:45:44 sw1 2069: May 13 11:45:43 EEST: %SYS-5-CONFIG_I: Configured from console by dir2cas on vty0 (10.0.20.200)
May 13 11:45:46 sw1 2070: May 13 11:45:45 EEST: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
May 13 11:45:46 sw1 2071: May 13 11:45:46 EEST: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up

Hello,

thank you for mwan3, it works fine for me.

I need help. I want run openvpn client seamlessly with "float" option on server, but mwan3 keeps old session on offline interface, so ovpn client firstly do timeout-restart(a lot of seconds) and then reconnect instead hop to another IP.

Am I able to force to use preferred interface by rule?

Thanks for help.

(Last edited by kubco2 on 14 May 2015, 08:41)

Hello,

I apologize for a newbie question, but here it goes:  I have a TPLink MR3020 with Barrier Breaker installed and I'm using it to secure my network connection while I travel/visit public hotspots (think Starbucks, coworking spaces, airports, hotels, etc).  The device has one wireless radio, an ethernet port and a USB port, which currently hosts a thumb drive mounted as /boot. 

The LAN connection and wwan are both clients and can connect to an external network.  The wifi is split into the wwan client and a lan station that broadcasts its own wifi network, dhcp, etc.  I basically followed this tutorial - https://www.loganmarchione.com/2015/02/ … -mr3020-3/ to configure the box, including the openvpn connection.

When I change /etc/config/wireless to include more than one client entry, the box hangs, and I am unable to boot or connect.  As soon as I comment out all but one client configurations, it works fine.

I'm hoping to be able to set up mwan3 to support multiple configurations.  That way, if I'm in a hotel, I can connect, and I can move to Starbucks or an airport lounge (or my office) without having to drop into failsafe to make the access point config change.  Bridging multiple connections (e.g. Starbucks and xfinitywifi) would be awesome, but that's an even more specialized case...

Can you assist?  Do I need a second wifi adapter to support this? 

Thank you for your help.

(Last edited by PrivateTraveler on 16 May 2015, 05:16)

Hello,
I am using mwan3 v1.6-1 and luci-app-mwan3 v1.4-2.
I have 6 WAN everything is working fine for few hours and then most of the WAN are going OFFLINE  "tracking down".

ping -I eth0.30 google.fr are correctly responding.
Here is my configuration :


~# cat /etc/config/mwan3 

config rule 'wan1_network'
        option proto 'all'
        option sticky '0'
        option use_policy 'wan1_only'
        option dest_ip '192.168.1.0/24'

config rule 'wan2_network'
        option proto 'all'
        option sticky '0'
        option use_policy 'wan2_only'
        option dest_ip '192.168.2.0/24'

config rule 'youtube'
        option sticky '1'
        option dest_port '80,443'
        option proto 'tcp'
        option use_policy 'balanced'

config rule 'https'
        option sticky '1'
        option dest_port '443'
        option proto 'tcp'
        option use_policy 'balanced'

config rule 'default_rule'
        option dest_ip '0.0.0.0/0'
        option use_policy 'balanced'

config member 'wan1'
        option interface 'WAN1'
        option weight '8'
        option metric '1'

config member 'wan2'
        option interface 'WAN2'
        option weight '8'
        option metric '1'

config member 'wan3'
        option interface 'WAN3'
        option weight '8'
        option metric '1'

config member 'wan4'
        option interface 'WAN4'
        option weight '8'
        option metric '1'

config member 'wan5'
        option interface 'WAN5'
        option weight '8'
        option metric '1'

config member 'wan6'
        option interface 'WAN6'
        option weight '8'
        option metric '1'

config policy 'balanced'
        option last_resort 'unreachable'
        list use_member 'wan1'
        list use_member 'wan2'
        list use_member 'wan3'
        list use_member 'wan4'
        list use_member 'wan5'
        list use_member 'wan6'
config interface 'WAN1'
        option enabled '1'
        list track_ip '8.8.8.8'
        option reliability '1'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '3'

config interface 'WAN2'
        option enabled '1'
        list track_ip '8.8.4.4'
        option reliability '1'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '3'

config interface 'WAN3'
        option enabled '1'
        list track_ip '176.31.81.4'
        option reliability '1'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '3'

config interface 'WAN4'
        option enabled '1'
        list track_ip '176.31.81.4'
        option reliability '1'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '3'

config interface 'WAN5'
        option enabled '1'
        list track_ip '176.31.81.4'
        option reliability '1'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '3'

config interface 'WAN6'
        option enabled '1'
        list track_ip '8.8.8.8'
        option reliability '1'
        option count '1'
        option timeout '2'
        option interval '5'
        option down '3'
        option up '3'
config policy 'wan2_only'
        list use_member 'wan2'
        option last_resort 'unreachable'

config policy 'wan1_only'
        list use_member 'wan1'
        option last_resort 'unreachable'

I must restart mwan3 to get the WAN back to ONLINE.

How to resolv the probeme ?
Thanks for your help.

(Last edited by dinman on 17 May 2015, 23:13)

Hello!

I don't know where it's better to write, so I write here.
I try to use mwan3 with dynamic routing protocols (ospf with bird) and encountered a strange behavior.
Bird gets route to network (10.18.10.0/24) from the remote router, and adds it to the current kernel routing table. However, traffic to the announced network continues to go through the default route via eth0.101. I can see it if I run traceroute or tcpdump.

root@izh-pk-h1:~# ip route ls
default via 172.24.40.1 dev eth0.101  proto static  metric 10 
default via 217.14.207.25 dev pppoe-isp2  proto static  metric 20 
10.18.8.0/24 dev br-lan  proto kernel  scope link  src 10.18.8.1 
10.18.10.0/24 via 172.16.18.2 dev tun_h2  proto bird 
172.16.18.2 dev tun_h2  proto kernel  scope link  src 172.16.18.1 
.......

root@izh-pk-h1:~# traceroute 10.18.10.1
traceroute to 10.18.10.1 (10.18.10.1), 30 hops max, 38 byte packets
 1  172.24.40.1 (172.24.40.1)  0.552 ms  0.643 ms  0.548 ms
 2  *  *  *
 3  *  *  *

root@izh-pk-h1:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.24.40.1     0.0.0.0         UG        0 0          0 eth0.101
0.0.0.0         217.14.207.25   0.0.0.0         UG        0 0          0 pppoe-isp2
10.18.8.0       0.0.0.0         255.255.255.0   U         0 0          0 br-lan
10.18.10.0      172.16.18.2     255.255.255.0   UG        0 0          0 tun_h2
172.16.18.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun_h2
.....

Also, if I add a static route manually via “route add -net ...”, he also does not apply "on the fly". This continues for as long as I'm not reloading firewall. As soon as I restart firewall, traffic starts to go on the desired route, as expected. This behavior does not occur if mwan3 not installed and used by a single connection to the ISP. Please help to understand where I should look for a solution: in mwan3, in bird4, or in an openwrt routing in general.

p.s. Openwrt 14.07, mwan3 - 1.5-10, bird4 - 1.4.3-1

(Last edited by paramobilus on 18 May 2015, 08:46)