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.

headless.cross wrote:
biatche wrote:

There any changelog somewhere? I'm testing your builds now.

No changelog at all from my side, these are the binaries from the latest sources. All credits to Adze/arfett.
Thus, this changelog applies: https://github.com/Adze1502/mwan/commits/master

default config:

is this normal?

http://i.imgur.com/2LWe2cH.jpg

are the "cfg0d92bd" normal/intended?

biatche wrote:

are the "cfg0d92bd" normal/intended?

This happens because the config sections are unnamed. Try to add a name after a rule (download the mwan3 config, using WinSCP, if you're a windows user or vi/nano it, if you're a linux user) and do something like this:

config rule 'name_of_rule'
       blah blah
       blah blah
       blah blah

About detailed configuration you should read the starter post (if you haven't).

#Question 7#

 
4x Track ips
   option 'reliability' '3'
    option 'count' '1'
    option 'timeout' '2'
    option 'interval' '5'
    option 'down' '3'
    option 'up' '8'

I need better understanding of this.
Does this mean each test round is every 5 seconds? Within this 5 seconds it pings once only and if it timesout (2 sec) it will attempt to ping again?
Each 5 second interval is considered UP so long as 3 of 4 track ips reply.
It goes down only if 3 consecutive intervals of 5 seconds are considered down (that means less than 3 track ips reply) thus requiring 15 seconds in total?
It goes up only if 8 consecutive intervals of 5 seconds are considered up (3 or more track ips reply normally) thus requiring 40 seconds in total?

Have i gotten this wrong?

#Question 8#

Members within one policy with a lower metric have precedence over higher metric members. Members with the same metric will load-balance. Load balancing members (with same metric) will distribute load based on those weights values.

Does this mean that rules that fall under the following policy..

config 'policy' 'wan2_pri_wan1_sec'
    list 'use_member' 'wan1_m2_w3'
    list 'use_member' 'wan2_m1_w2'

Does it mean that traffic under this policy will fall under wan2 (thus not load balanced) and if wan2 goes down, that's only when traffic under this policy will fail back to wan1?

-I do not want it to be load balancing- Just want to route all traffic of certain ports to WAN2 which has failover protection.

(Last edited by biatche on 18 Apr 2013, 17:01)

biatche wrote:

#Question 7#

 
4x Track ips
   option 'reliability' '3'
    option 'count' '1'
    option 'timeout' '2'
    option 'interval' '5'
    option 'down' '3'
    option 'up' '8'

I need better understanding of this.

This is mentioned earlier in this thread, but here goes:

reliability = how many track_ip hosts at minimum should respond to echo requests, before assuming the test successful.
count = how many echo requests should be sent to each track_ip host. At least one reply is needed for the hosts to be considered reachable
timeout = time in seconds to wait for an echo response, after an echo request has been sent.
interval = time in seconds to wait between tests
down = when interface is UP: the number of failed tests in a row, to consider this interface DOWN
up = when interface is DOWN: the number of successful tests in a row, to consider this interface UP

By one test i mean all the track_ip hosts are tested. A test result is either a succes or a fail.

biatche wrote:

#Question 8#

Members within one policy with a lower metric have precedence over higher metric members. Members with the same metric will load-balance. Load balancing members (with same metric) will distribute load based on those weights values.

Does this mean that rules that fall under the following policy..

config 'policy' 'wan2_pri_wan1_sec'
    list 'use_member' 'wan1_m2_w3'
    list 'use_member' 'wan2_m1_w2'

..will fall under wan2 (thus not load balanced) and if wan2 goes down, that's only when traffic under this policy will fail back to wan1?

Yes

Thanks

Still no time to test the binaries. I hope there will be a "time hole" this weekend to play with multiwan.

Adze,

Just to avoid confusion maybe the default rules in /etc/config/mwan3 should be named so it doesn't show up as "cfg######" on the GUI?

Even just "rule 1" "rule 2" or whatever you please.

Hi did you close your SVN?

Just a theory, is it possible to use mwan on multiple wifi sources? like relayd? if not what are the options?

(Last edited by gendouhydeist on 20 Apr 2013, 14:30)

gendouhydeist wrote:

Just a theory, is it possible to use mwan on multiple wifi sources?

That should work. If each wifi "source" has it's own network interface in /etc/config/network and a default route.

I've named my wan's abc1 and abc2 for personal reasons.

ping -c 1 -I eth0.3 google.com == timeout
ping -c 1 -I eth0.4 google.com == OK
ping -c 1 -I pppoe-abc1 google.com == OK

abc1 = pppoe-abc1 (which is pppoe off vlan3 = eth0.3)
abc2 = eth0.4

ip route show

default via 110.159.xx.xxx dev pppoe-abc1  proto static  metric 10 
default via 192.168.202.1 dev eth0.4  proto static  metric 20 
110.159.xx.xxx dev pppoe-abc1  proto kernel  scope link  src 110.159.yy.yyy 
192.168.0.0/24 dev br-lan  proto kernel  scope link  src 192.168.0.254 
192.168.21.0/24 dev wlan0-1  proto kernel  scope link  src 192.168.21.254 
192.168.202.0/24 dev eth0.4  proto static  scope link  metric 20 

ip rule show

0:    from all lookup local 
1001:    from all fwmark 0x100/0xff00 lookup 1001 
1002:    from all fwmark 0x200/0xff00 lookup 1002 
1016:    from all fwmark 0x1000/0xff00 lookup 1016 
1017:    from all fwmark 0x1100/0xff00 lookup 1017 
1018:    from all fwmark 0x1200/0xff00 lookup 1018 
1019:    from all fwmark 0x1300/0xff00 lookup 1019 
1020:    from all fwmark 0x1400/0xff00 lookup 1020 
32766:    from all lookup main 
32767:    from all lookup default 

ip rule list table #above#

1001:
default via 110.159.xx.xxx dev pppoe-abc1 
1002:
default via 192.168.202.1 dev eth0.4 
1016:
default via 110.159.xx.xxx dev pppoe-abc1  metric 1 
blackhole default  metric 1000 
1017:
default via 192.168.202.1 dev eth0.4  metric 1 
blackhole default  metric 1000 
1018:
default  metric 1 
    nexthop via 192.168.202.1  dev eth0.4 weight 2
    nexthop via 110.159.xx.xxx  dev pppoe-abc1 weight 3
blackhole default  metric 1000 
1019:
default via 110.159.xx.xxx dev pppoe-abc1  metric 1 
default via 192.168.202.1 dev eth0.4  metric 2 
blackhole default  metric 1000 
1020:
default via 192.168.202.1 dev eth0.4  metric 1 
default via 110.159.xx.xxx dev pppoe-abc1  metric 2 
blackhole default  metric 1000 

iptables -L mwan3_* -t mangle -v -n

Chain mwan3_pre (2 references)
 pkts bytes target     prot opt in     out     source               destination         
39644 5359K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore mask 0xff00 
22909 2745K mwan3_track_eth0.4  all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x8000/0x8000 
 7616 1689K MARK       all  --  eth0.4 *       0.0.0.0/0            0.0.0.0/0           MARK xset 0x8200/0xff00 
16215 1173K mwan3_track_pppoe-abc1  all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x8000/0x8000 
  276 21518 MARK       all  --  pppoe-abc1 *       0.0.0.0/0            0.0.0.0/0           MARK xset 0x8100/0xff00 
26109 1962K mwan3_default  all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x8000/0x8000 
 1894 89325 mwan3_rules  all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x0/0xff00 
Chain mwan3_post (2 references)
 pkts bytes target     prot opt in     out     source               destination         
10784  445K MARK       all  --  *      eth0.4  0.0.0.0/0            0.0.0.0/0           mark match !0x8000/0x8000 MARK xset 0x200/0xff00 
   49  3627 MARK       all  --  *      pppoe-abc1  0.0.0.0/0            0.0.0.0/0           mark match !0x8000/0x8000 MARK xset 0x100/0xff00 
21629 4635K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x8000/0x8000 MARK and 0xffff7fff 
38694 5367K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save mask 0xff00 
Chain mwan3_default (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    3    96 MARK       all  --  *      *       0.0.0.0/0            224.0.0.0/3         mark match !0x8000/0x8000 MARK or 0x8000 
    0     0 MARK       all  --  *      *       0.0.0.0/0            110.159.xx.xxx      mark match !0x8000/0x8000 MARK or 0x8000 
 4385  615K MARK       all  --  *      *       0.0.0.0/0            192.168.0.0/24      mark match !0x8000/0x8000 MARK or 0x8000 
    0     0 MARK       all  --  *      *       0.0.0.0/0            192.168.21.0/24     mark match !0x8000/0x8000 MARK or 0x8000 
    0     0 MARK       all  --  *      *       0.0.0.0/0            192.168.202.0/24    mark match !0x8000/0x8000 MARK or 0x8000 
Chain mwan3_rules (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  235 12924 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport sports 0:65535 multiport dports 10101 mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport sports 0:65535 multiport dports 12000 mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport sports 0:65535 multiport dports 19000 mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport sports 0:65535 multiport dports 30001 mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport sports 0:65535 multiport dports 12000 mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           multiport sports 0:65535 multiport dports 10002:10005 mark match 0x0/0xff00 MARK xset 0x1400/0xff00 
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x0/0xff00 MARK xset 0x1300/0xff00 

ifconfig

br-lan    Link encap:Ethernet  HWaddr F8:D1:11
          inet addr:192.168.0.254  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:31244 errors:0 dropped:11 overruns:0 frame:0
          TX packets:20580 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1654173 (1.5 MiB)  TX bytes:5399295 (5.1 MiB)

eth0      Link encap:Ethernet  HWaddr F8:D1:11
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:48201 errors:0 dropped:0 overruns:59805 frame:0
          TX packets:43197 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6757305 (6.4 MiB)  TX bytes:6892406 (6.5 MiB)
          Interrupt:4 

eth0.1    Link encap:Ethernet  HWaddr F8:D1:11
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:31256 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20587 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1664808 (1.5 MiB)  TX bytes:5399617 (5.1 MiB)

eth0.3    Link encap:Ethernet  HWaddr F8:D1:11
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:1387 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1415 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:101922 (99.5 KiB)  TX bytes:95408 (93.1 KiB)

eth0.4    Link encap:Ethernet  HWaddr F8:D1:1
          inet addr:192.168.202.254  Bcast:192.168.202.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:15401 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21194 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4115857 (3.9 MiB)  TX bytes:1223554 (1.1 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:144 errors:0 dropped:0 overruns:0 frame:0
          TX packets:144 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11625 (11.3 KiB)  TX bytes:11625 (11.3 KiB)

pppoe-abc1 Link encap:Point-to-Point Protocol  
          inet addr:110.159.yy.yyy  P-t-P:110.159.xx.xxx  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:665 errors:0 dropped:0 overruns:0 frame:0
          TX packets:688 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:60424 (59.0 KiB)  TX bytes:58347 (56.9 KiB)

wlan0     Link encap:Ethernet  HWaddr F8:D1:11:7
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3907 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:0 (0.0 B)  TX bytes:310562 (303.2 KiB)

wlan0-1   Link encap:Ethernet  HWaddr FA:D1:11:7
          inet addr:192.168.21.254  Bcast:192.168.21.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32 
          RX bytes:0 (0.0 B)  TX bytes:420 (420.0 B)
config interface 'abc1'
    option enabled '1'
#    list track_ip 'a.a.a.a'
#    list track_ip 'b.b.b.b'
    list track_ip '208.67.222.222'
    list track_ip '8.8.8.8'
    option count '1'
    option timeout '2'
    option down '3'
    option up '3'
    option reliability '2'
    option interval '5'

config interface 'abc2'
    option enabled '1'
#    list track_ip 'a.a.a.a'
#    list track_ip 'b.b.b.b'
    list track_ip '208.67.222.222'
    list track_ip '8.8.8.8'
    option count '1'
    option timeout '2'
    option down '3'
    option up '3'
    option reliability '2'
    option interval '5'

config member 'abc1_m1_w3'
    option interface 'abc1'
    option metric '1'
    option weight '3'

config member 'abc1_m2_w3'
    option interface 'abc1'
    option metric '2'
    option weight '3'

config member 'abc2_m1_w2'
    option interface 'abc2'
    option metric '1'
    option weight '2'

config member 'abc2_m2_w2'
    option interface 'abc2'
    option metric '2'
    option weight '2'

config policy 'abc1_only'
    list use_member 'abc1_m1_w3'

config policy 'abc2_only'
    list use_member 'abc2_m1_w2'

config policy 'abc1_abc2_loadbalanced'
    list use_member 'abc1_m1_w3'
    list use_member 'abc2_m1_w2'

config policy 'abc1_pri_abc2_sec'
    list use_member 'abc1_m1_w3'
    list use_member 'abc2_m2_w2'

config policy 'abc2_pri_abc1_sec'
    list use_member 'abc1_m2_w3'
    list use_member 'abc2_m1_w2'

config rule 'aaa1'
    option dest_port '11031'
    option use_policy 'abc2_pri_abc1_sec'
    option proto 'all'

config rule 'bbb2'
    option proto 'udp'
    option dest_port '12000'
    option use_policy 'abc2_pri_abc1_sec'

config rule 'ccc3'
    option proto 'udp'
    option dest_port '10002:10005'
    option use_policy 'abc2_pri_abc1_sec'

config rule 'allelse'
    option use_policy 'abc1_pri_abc2_sec'

What am I doing  wrong? ALL traffic goes to my 2nd wan : abc2


I need traffic_of_specific_destination_ports on wan2_failover_to_wan1 (so these specified traffic are always on wan2 only unless wan2 is down)
and all_other_unspecified_traffic on wan1_failover_to_wan2 (so these all_else traffic are always on wan1 only unless wan1 goes down)

nothing else. do the rules read top to bottom or bottom to top?

~~~~~~~

Is there a way to check if a WAN is tagged up or down? will help a lot in diagnosis

(Last edited by biatche on 20 Apr 2013, 18:10)

Hi Biatche,


The first rule in your config:

config rule 'aaa1'
    option dest_port '11031'
    option use_policy 'abc2_pri_abc1_sec'
    option proto 'all'

contains protocol options all. Unfortunately you cant use dest_port option with all. So dest_port 11031 makes no sense, as it does not know for what protocol. As a result your first rule always hits as it becomes an "always match" rule. Look at the counters of the mwan3_rules iptable you posted:

Chain mwan3_rules (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  235 12924 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match           MARK xset 0x1400/0xff00

As the rules are read from top to bottom, all other rules are never hit. So mwan3 does exactly what you told it to do.  wink

(Last edited by Adze on 20 Apr 2013, 18:51)

Oh, I was thinking.. ok let's make life easy. Instead of specifying tcp+udp, I'll just put all. Also, do I need to specify ips? such as 0.0.0.0/0 for ALL ips... or just leave that blank?

Also, in your example, you specified:

config 'rule'
    option 'dest_ip' '192.168.0.0/16'
    option 'proto' 'tcp'
    option 'use_policy' 'default'

Is this necessary? I'm not very smart in networking, so please explain if you can!

Update: OK, I read your thread on page 3 regarding this, so it's in a way specifying a static route. BUT... what if I have a modem on 192.168.202.1 which dmz's to openwrt at 192.168.202.254. How will the above rule affect traffic in this case? Will it actually hit?

I'm thinking to have a rule 192.168.201.0/24 to use_policy wan1_only and 192.168.202.0/24 to use_policy wan2_only and 192.168.0.0/24 to 'default'.

Is this sensible? Or would you suggest something else?

Lastly:
Is there a way to check if a WAN is tagged up or down? will help a lot in diagnosis

Thank you so far for mwan3 and your kind replies!

(Last edited by biatche on 20 Apr 2013, 20:57)

biatche wrote:

Do I need to specify ips? such as 0.0.0.0/0 for ALL ips... or just leave that blank?

Omitting src_ip or dest_ip options assumes 0.0.0.0/0. You can leave it out.

biatche wrote:

Also, in your example, you specified:

config 'rule'
    option 'dest_ip' '192.168.0.0/16'
    option 'proto' 'tcp'
    option 'use_policy' 'default'

Is this necessary? I'm not very smart in networking, so please explain if you can!

A rule that refers to the "default" policy is used for routing traffic based on the default routing table. This comes handy with eg. vpn-tunnels or other static routes. This rule is not necessary, but since 192.168.0.0/16 is not routed on the internet, i decided to put that in as an example. None of the example rules are necessary, but you need at least one rule to make mwan3 work.

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

While you were replying to my post, I edited it a bit, please suggest how I can go about things there!

biatche wrote:

What if I have a modem on 192.168.202.1 which dmz's to openwrt at 192.168.202.254. How will the above rule affect traffic in this case? Will it actually hit?

I'm thinking to have a rule 192.168.201.0/24 to use_policy wan1_only and 192.168.202.0/24 to use_policy wan2_only and 192.168.0.0/24 to 'default'.

Is this sensible? Or would you suggest something else?

All locally connected networks are marked to use the default routing table. So no need to make rules for that. Rules for locally connected networks are never hit, because they are already marked in the mwan3_default table.

biatche wrote:

Is there a way to check if a WAN is tagged up or down? will help a lot in diagnosis

In the latest 1.1-10 version the ip rules 1001 till 1015 (which corresponds to interfaces 1 till 15) are deleted when an interface goes down. So if no rule present, interface is down.

(Last edited by Adze on 20 Apr 2013, 21:10)

My LAN is 192.168.0.0/24, 192.168.201.0/24 is between openwrt and modem1, and 192.168.202.0/24 is between openwrt and modem2. does this mean to say 201 and 202 subnet are considered "locally connected networks"? hope you dont get frustrated with my inexperience. smile

if 2 interfaces (wan1, wan2) exist, how do i distinguish when whichever is down? aka wan1 and wan2. i've been accustomed to pfsense ui, so when a link goes down, it shows so on the webui.

biatche wrote:

My LAN is 192.168.0.0/24, 192.168.201.0/24 is between openwrt and modem1, and 192.168.202.0/24 is between openwrt and modem2. does this mean to say 201 and 202 subnet are considered "locally connected networks"?

Yes, All three subnets are locally connected networks. Your router has an interface directly connected in that subnet (has an ip address of this subnet configured).

biatche wrote:

if 2 interfaces (wan1, wan2) exist, how do i distinguish when whichever is down? aka wan1 and wan2. i've been accustomed to pfsense ui, so when a link goes down, it shows so on the webui.

The interfaces are (same as the rules) read from top to bottom. The first interface definition in your mwan3 config corresponds to rule number 1001, second interface to rule 1002 and so on.

biatche wrote:

Lastly:
Is there a way to check if a WAN is tagged up or down? will help a lot in diagnosis

I'm in the process of today/tomorrow creating an overview page on the mwan-luci package that will have a live up/down display.


Adze,

What other helpful commands do you think I should add to the troubleshooting page showing the output? It will allow the less experienced users to get all the information needed/requested for troubleshooting without actually running any commands.

(Last edited by arfett on 20 Apr 2013, 22:47)

-By the way, is there a possibility that if mwan3 switches to a fail-over connection (and later fail-back) to send me an email?

-Is there a possibility (i have a static ip for my main adsl line and an umts backup) to trigger a dyndns-client update once the connection is failed-over to umts?

Both solutions would be very great.

Cheers

Thomy

Thomymaster wrote:

-By the way, is there a possibility that if mwan3 switches to a fail-over connection (and later fail-back) to send me an email?

-Is there a possibility (i have a static ip for my main adsl line and an umts backup) to trigger a dyndns-client update once the connection is failed-over to umts?

Both solutions would be very great.

Cheers

Thomy

A quick fix: make a script in /etc/hotplug.d/iface to call your email/ddns app on certain interface up/down events.

(Last edited by arfett on 21 Apr 2013, 01:37)

Adze wrote:
biatche wrote:

What if I have a modem on 192.168.202.1 which dmz's to openwrt at 192.168.202.254. How will the above rule affect traffic in this case? Will it actually hit?

I'm thinking to have a rule 192.168.201.0/24 to use_policy wan1_only and 192.168.202.0/24 to use_policy wan2_only and 192.168.0.0/24 to 'default'.

Is this sensible? Or would you suggest something else?

All locally connected networks are marked to use the default routing table. So no need to make rules for that. Rules for locally connected networks are never hit, because they are already marked in the mwan3_default table.

biatche wrote:

Is there a way to check if a WAN is tagged up or down? will help a lot in diagnosis

In the latest 1.1-10 version the ip rules 1001 till 1015 (which corresponds to interfaces 1 till 15) are deleted when an interface goes down. So if no rule present, interface is down.

I don't have 1.1-10 nor know where the link is so I presume it hasn't been compiled.

I'm using 1.1-9 as of now compiled by headless.. so what happens when a wan interface goes up or down? will it automatically run the mwan3 script which recreate the rules and routes?

Mwan3 is triggered by hotplug-events. When an interface comes up it creates new routing tables and new iptables rules. A new routing table is created for each interface and for each policy. It then sets up iptables rules and uses iptables MARK to mark certain traffic. Based on ip rules the kernel determines which routing table to use. When an interface goes down, mwan3 deletes all the rules and routes to that interface in all created routing tables.

Mwan3 is not a daemon that runs in the background. Ones all the routes and rules are in place, it exits. The kernel takes care of all the routing decisions. If you want to apply a change you have made to mwan3 configuration, you have to trigger a hotplug event (replace eth0.1 and wan1 with your values):

Please bear with noob-me, so the first paragraph says 'it creates/deletes rules/routes when if goes up/down' and the second paragraph says 'not daemon, hotplug trigger is necessary'

So in case of pppoe, is this a hotplug event thus everything is automated?
and if in the case of static ip (dmz).. say i turn off the modem router... will a hotplug event be triggered?

(Last edited by biatche on 21 Apr 2013, 09:19)

mwan3track takes care of issuing hotplug events. If you have one or more track_ip configured, you don't have to do anything.

I have a preliminary interface status page completed. It shows "ONLINE" "OFFLINE" "not tracked" and "not enabled" for the interface status.

Going to pretty it up so it resembles the stock multiwan package look and post on github soon.