Hello ! I have mwan3 with wan and wanb. Wan runs over another router 192.168.178.1, and wanb is over 192.168.1.1. Now, failover does work properly: if wan is available, the traffic goes over wan, if not, wanb. I checked that using traceroute. However, on the status on luci, it shows that wanb is online, and wan is disabled. I wait and reload the luci, but it always shows that way.
Could someone please tell me what's wrong? mwan3 does function as desired, so it's not that important, but it's confusing.
Are you checking in the Status/Overview page in Luci, or in Status/Load Balancing ?
I'm looking at
Status > Load balancing > Interfaces. It says
wan: disabled, wanb: online.
But currently the internet connection is through wan, not wanb.
root@OpenWrt2:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 192.168.178.1 (192.168.178.1) 0.647 ms 0.470 ms 0.464 ms
And what is the output of mwan3 status ; echo; uci export mwan3 ?
Now I see, something is wrong....
Interface status:
interface wan is error (15) and tracking is paused
interface WANb is error (8) and tracking is active
So actually "disabled" doesn't mean that wan is down, but it is not properly tracked by mwan3? Is that right?
But why error? I set up this way:
Two WANs: different VLANs.
"gateway metric" 10 and 20
DHCP: ignore
MWAN interfaces:
wan Add
click enable
Tracking 8.8.8.8, 8.8.4.4
ping: reliability 1
otherwise leave default.
wanb add
click enable online 8.8.8.8, 8.8.4.4
leave else so.
MWAN members:
name: wan_members
interface wan
metric 1, weight 1 (primary wan)
name: wanb_members
interface wanb
metric 2, weight 2 (secondary wan)
Policies: wan-to-wanb, member used: these two.
Policy: wan-to-wanb
Rules: https: policy wan-to-wamb, apply
IPv4: policy the same
Restart interfaces.
You need to check with ping -I ethX 8.8.8.8 that there is connectivity from a specific interface to that server. You can also do that from the diagnostics page of mwan3 in Luci.
For further investigation we'd need to see the output of the commands in my previous post.
O, I missed your second posting! I pasted below. As for ping, I did it and they can both ping to 8.8.8.8.
Thanks for checking in advance!
root@OpenWrt2:~# mwan3 status ; echo; uci export mwan3
Interface status:
interface wan is error (15) and tracking is paused
interface wan6 is offline and tracking is down
interface wanb6 is offline and tracking is down
interface WANb is error (8) and tracking is active
Current ipv4 policies:
Current ipv6 policies:
Directly connected ipv4 networks:
Directly connected ipv6 networks:
Active ipv4 user rules:
Active ipv6 user rules:
package mwan3
config globals 'globals'
option mmx_mask '0x3F00'
config interface 'wan'
option enabled '1'
option family 'ipv4'
option initial_state 'online'
option track_method 'ping'
option reliability '1'
option count '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option timeout '4'
option interval '10'
option failure_interval '5'
option recovery_interval '5'
option down '5'
option up '5'
list track_ip '8.8.8.8'
config interface 'wan6'
option enabled '0'
list track_ip '2001:4860:4860::8844'
list track_ip '2001:4860:4860::8888'
list track_ip '2620:0:ccd::2'
list track_ip '2620:0:ccc::2'
option family 'ipv6'
option reliability '2'
config interface 'wanb6'
option enabled '0'
list track_ip '2001:4860:4860::8844'
list track_ip '2001:4860:4860::8888'
list track_ip '2620:0:ccd::2'
list track_ip '2620:0:ccc::2'
option family 'ipv6'
option reliability '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 'wanb_m1_w2'
option interface 'wanb'
option metric '1'
option weight '2'
config member 'wanb_m2_w2'
option interface 'wanb'
option metric '2'
option weight '2'
config member 'wan6_m1_w3'
option interface 'wan6'
option metric '1'
option weight '3'
config member 'wan6_m2_w3'
option interface 'wan6'
option metric '2'
option weight '3'
config member 'wanb6_m1_w2'
option interface 'wanb6'
option metric '1'
option weight '2'
config member 'wanb6_m2_w2'
option interface 'wanb6'
option metric '2'
option weight '2'
config policy 'wan_only'
list use_member 'wan_m1_w3'
list use_member 'wan6_m1_w3'
config policy 'wanb_only'
list use_member 'wanb_m1_w2'
list use_member 'wanb6_m1_w2'
config policy 'balanced'
list use_member 'wan_m1_w3'
list use_member 'wanb_m1_w2'
list use_member 'wan6_m1_w3'
list use_member 'wanb6_m1_w2'
config policy 'wan_wanb'
list use_member 'wan_m1_w3'
list use_member 'wanb_m2_w2'
list use_member 'wan6_m1_w3'
list use_member 'wanb6_m2_w2'
config policy 'wanb_wan'
list use_member 'wan_m2_w3'
list use_member 'wanb_m1_w2'
list use_member 'wan6_m2_w3'
list use_member 'wanb6_m1_w2'
config rule 'https'
option sticky '1'
option dest_port '443'
option proto 'tcp'
option use_policy 'wan_to_wanb'
config rule 'default_rule_v4'
option dest_ip '0.0.0.0/0'
option family 'ipv4'
option proto 'all'
option sticky '0'
option use_policy 'wan_to_wanb'
config rule 'default_rule_v6'
option dest_ip '::/0'
option use_policy 'balanced'
option family 'ipv6'
config member 'wan_members'
option interface 'wan'
option metric '1'
option weight '1'
config member 'wanb_members'
option metric '2'
option weight '2'
option interface 'WANb'
config policy 'wan_to_wanb'
list use_member 'wan_members'
list use_member 'wanb_members'
option last_resort 'unreachable'
config interface 'WANb'
option enabled '1'
option initial_state 'online'
option family 'ipv4'
list track_ip '8.8.8.8'
option track_method 'ping'
option reliability '1'
option count '1'
option size '56'
option max_ttl '60'
option check_quality '0'
option timeout '4'
option interval '10'
option failure_interval '5'
option recovery_interval '5'
option down '5'
option up '5'
I would suggest to use some more tracking stations, like 1.1.1.1, 1.0.0.1, and 8.8.4.4
Also increase the option count from 1 to 3, sometimes the first ping gets lost.
Is there anything in the logs? logread -e mwan
Also let's have a look at the routing table ip -4 addr; ip -4 route list table all; ip -4 ru
Thanks for your suggestion! I checked logread -e mwan, nothing is there. And the other one: below.
One thing is, I realized that I named vlan17 for mwan failover eth0.17, instead of eth1.17. Is it bad?
root@OpenWrt2:~# ip -4 addr; ip -4 route list table all; ip -4 ru
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.178.2/24 brd 192.168.178.255 scope global eth1
valid_lft forever preferred_lft forever
8: br-12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.14.1/24 brd 192.168.14.255 scope global br-12
valid_lft forever preferred_lft forever
10: br-15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.13.1/24 brd 192.168.13.255 scope global br-15
valid_lft forever preferred_lft forever
12: br-16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.10.1/24 brd 192.168.10.255 scope global br-16
valid_lft forever preferred_lft forever
15: vpn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
inet 192.168.8.1/24 brd 192.168.8.255 scope global vpn
valid_lft forever preferred_lft forever
20: br-11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.12.1/24 brd 192.168.12.255 scope global br-11
valid_lft forever preferred_lft forever
45: eth0.17@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
inet 192.168.1.124/24 brd 192.168.1.255 scope global eth0.17
valid_lft forever preferred_lft forever
default via 192.168.178.1 dev eth1 table 1 proto static src 192.168.178.2 metric 10
192.168.178.0/24 dev eth1 table 1 proto static scope link metric 10
default via 192.168.1.1 dev eth0.17 table 4 proto static src 192.168.1.124 metric 20
192.168.1.0/24 dev eth0.17 table 4 proto static scope link metric 20
192.168.8.0/24 dev vpn table 4 proto kernel scope link src 192.168.8.1
192.168.10.0/24 dev br-16 table 4 proto kernel scope link src 192.168.10.1
192.168.12.0/24 dev br-11 table 4 proto kernel scope link src 192.168.12.1
192.168.13.0/24 dev br-15 table 4 proto kernel scope link src 192.168.13.1
192.168.14.0/24 dev br-12 table 4 proto kernel scope link src 192.168.14.1
default via 192.168.178.1 dev eth1 proto static src 192.168.178.2 metric 10
default via 192.168.1.1 dev eth0.17 proto static src 192.168.1.124 metric 20
192.168.1.0/24 dev eth0.17 proto static scope link metric 20
192.168.8.0/24 dev vpn proto kernel scope link src 192.168.8.1
192.168.10.0/24 dev br-16 proto kernel scope link src 192.168.10.1
192.168.12.0/24 dev br-11 proto kernel scope link src 192.168.12.1
192.168.13.0/24 dev br-15 proto kernel scope link src 192.168.13.1
192.168.14.0/24 dev br-12 proto kernel scope link src 192.168.14.1
192.168.178.0/24 dev eth1 proto static scope link metric 10
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 192.168.1.0 dev eth0.17 table local proto kernel scope link src 192.168.1.124
local 192.168.1.124 dev eth0.17 table local proto kernel scope host src 192.168.1.124
broadcast 192.168.1.255 dev eth0.17 table local proto kernel scope link src 192.168.1.124
broadcast 192.168.8.0 dev vpn table local proto kernel scope link src 192.168.8.1
local 192.168.8.1 dev vpn table local proto kernel scope host src 192.168.8.1
broadcast 192.168.8.255 dev vpn table local proto kernel scope link src 192.168.8.1
broadcast 192.168.10.0 dev br-16 table local proto kernel scope link src 192.168.10.1
local 192.168.10.1 dev br-16 table local proto kernel scope host src 192.168.10.1
broadcast 192.168.10.255 dev br-16 table local proto kernel scope link src 192.168.10.1
broadcast 192.168.12.0 dev br-11 table local proto kernel scope link src 192.168.12.1
local 192.168.12.1 dev br-11 table local proto kernel scope host src 192.168.12.1
broadcast 192.168.12.255 dev br-11 table local proto kernel scope link src 192.168.12.1
broadcast 192.168.13.0 dev br-15 table local proto kernel scope link src 192.168.13.1
local 192.168.13.1 dev br-15 table local proto kernel scope host src 192.168.13.1
broadcast 192.168.13.255 dev br-15 table local proto kernel scope link src 192.168.13.1
broadcast 192.168.14.0 dev br-12 table local proto kernel scope link src 192.168.14.1
local 192.168.14.1 dev br-12 table local proto kernel scope host src 192.168.14.1
broadcast 192.168.14.255 dev br-12 table local proto kernel scope link src 192.168.14.1
broadcast 192.168.178.0 dev eth1 table local proto kernel scope link src 192.168.178.2
local 192.168.178.2 dev eth1 table local proto kernel scope host src 192.168.178.2
broadcast 192.168.178.255 dev eth1 table local proto kernel scope link src 192.168.178.2
0: from all lookup local
1004: from all iif eth0.17 lookup 4
2004: from all fwmark 0x400/0x3f00 lookup 4
2061: from all fwmark 0x3d00/0x3f00 blackhole
2062: from all fwmark 0x3e00/0x3f00 unreachable
3004: from all fwmark 0x400/0x3f00 unreachable
32766: from all lookup main
32767: from all lookup default
root@OpenWrt2:~#
No one will die, but it will not work.
2 Likes
O, perhaps then that's the reason why it wasn't showing right. I wonder why it was "working" then.... I will change it and see how it looks like.
Now the status looks like in the way it is supposed to look !!! So it was the cause then.
But, with "eth0.17", there was a nice feature: while the status was not showing right, the traffic to outside world was switched back and forth properly, while I was also able to ping from one router to the other. Now, as mwan3 working properly, it is totally disabled. Is there anyway so that the function to ping through the "offline" interface to a certain IP address is still possible ?
Some interface hoping most likely, I see a lot of bridges there.
I am not sure I follow. As long as the interface is connected and up, there is a default route in the main routing table. Therefore you can always ping some destination using the -I option in the ping, or you can use the diagnostics tab of mwan3 status.
Yeah, that's the point. As mwan3 was not working properly, wanb was not totally down, while wan was alive. The traffic to the public was going through wan, but wanb was still transmitting ping (and, if I allow on firewall, I could even use luci from wanb). Now, as mwan3 is working, wanb is really "down" as long as wan is alive. So nothing goes through wanb anymore.
I think from corrections I've read the 'Regular's' post; that interface name needs to be lowercase, and the references to it should be lower case as well.
As it is now
config member 'wanb_members'
option metric '2'
option weight '2'
option interface 'WANb'
config interface 'WANb'
option enabled '1'
option initial_state 'online'
option family 'ipv4'
...
Corrected
config member 'wanb_members'
option metric '2'
option weight '2'
option interface 'wanb'
config interface 'wanb'
option enabled '1'
option initial_state 'online'
option family 'ipv4'
@Bill, Yes, I should have named it wanb instead of WANb, but when I created that interface, I didn't realize that on Luci it shows up all capital, I thought wan was WAN, so I named it WANb. It causes much confusion because on Luci it shows WANB. But it's not that it as such is a problem. I just have to remember that it's WANb, not WANB or wanb or Wanb, and copy it faithfully whenever I refer to it. It's confusing, better use just lower case, but it doesn't need to be.
Did you make the changes? It is the minutia we are looking for in the configs.
Post the results of
mwan3 status ; echo; uci export mwan3; uci export network
@Bill
Well, it's a production system, I can't change much.... I got clients, I'm afraid to change.
I think eth1.17 was it. Now there is no error, everything looks as it should. But I miss the additional feature that eth0.17 had, and I don't really understand what's wrong with naming it eth0.17 and putting it into wan-zone of the firewall.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.