kpv,
option up '8'
This setting seems a little extreme to me for anything other than some specialized server/datacenter application.
Try '2'
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.
Page 29 of 65
Judging by the tcpdump log, it would seem like my OpenWRT test system has no default routes when WANs go down:
laptop bin # tcpdump -i eth0 -n src host xxx.yy.zz.206 and host not xxx.yy.zz.202
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:53:41.932863 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:53:42.927894 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:53:43.927897 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:53:43.938707 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
20:53:44.937915 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
20:53:45.937893 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
20:53:50.949208 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:53:51.947894 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:53:52.947888 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:53:52.954804 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
20:53:53.948018 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
20:53:54.947883 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
20:53:59.965325 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:54:00.957884 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:54:01.957886 ARP, Request who-has 208.67.220.220 tell xxx.yy.zz.206, length 46
20:54:01.970979 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
20:54:02.967915 ARP, Request who-has 8.8.8.8 tell xxx.yy.zz.206, length 46
^C
17 packets captured
17 packets received by filter
0 packets dropped by kernel
laptop bin #
7187 root 1360 S {mwan3track} /bin/sh /usr/sbin/mwan3track wan eth0.2 1 1 2 5 3 8 208.67.222.222 8.8.4.
8198 root 1360 S {mwan3track} /bin/sh /usr/sbin/mwan3track wan2 eth0.3 1 1 2 5 3 8 208.67.220.220 8.8.8
8736 root 0 SW [kworker/0:0]
9411 root 0 SW [kworker/0:3]
9592 root 1348 S sleep 5
9593 root 1352 S ping -I eth0.3 -c 1 -W 2 8.8.8.8
9594 root 1356 R ps
27210 nobody 976 S /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k
30072 root 1476 S /sbin/netifd
30178 root 1368 S udhcpc -p /var/run/udhcpc-eth0.2.pid -s /lib/netifd/dhcp.script -f -t 0 -i eth0.2 -C
30180 root 1368 S udhcpc -p /var/run/udhcpc-eth0.3.pid -s /lib/netifd/dhcp.script -f -t 0 -i eth0.3 -CWhen a WAN goes down on my OpenWRT system, its custom route table (ip route list table 1, 2 etc) apprently gets cleared (see below). Is this normal?
Not working (both WANs down), custom route tables empty:
root@OpenWrt:~# ip route list table 1
root@OpenWrt:~# ip route list table 2
root@OpenWrt:~# ip rule
0: from all lookup local
2254: from all fwmark 0xfe00/0xff00 unreachable
32766: from all lookup main
32767: from all lookup default
root@OpenWrt:~#Working system:
root@OpenWrt:~# mwan3 restart
root@OpenWrt:~# ip route list table 1
default via xxx.yy.zz.31 dev eth0.2
root@OpenWrt:~# ip route list table 2
default via xxx.yy.zz.31 dev eth0.3
root@OpenWrt:~# ip rule
0: from all lookup local
1001: from all iif eth0.2 lookup main
1002: from all iif eth0.3 lookup main
2001: from all fwmark 0x100/0xff00 lookup 1
2002: from all fwmark 0x200/0xff00 lookup 2
2254: from all fwmark 0xfe00/0xff00 unreachable
32766: from all lookup main
32767: from all lookup default
root@OpenWrt:~#In either case, the main routing table remains unchanged:
root@OpenWrt:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 xxx.yy.zz.31 0.0.0.0 UG 10 0 0 eth0.2
0.0.0.0 xxx.yy.zz.31 0.0.0.0 UG 20 0 0 eth0.3
192.168.100.0 0.0.0.0 255.255.252.0 U 0 0 0 br-lan
xxx.yy.zz.0 0.0.0.0 255.255.255.0 U 10 0 0 eth0.2
xxx.yy.zz.0 0.0.0.0 255.255.255.0 U 20 0 0 eth0.3kpv wrote:
When a WAN goes down on my OpenWRT system, its custom route table (ip route list table 1, 2 etc) apprently gets cleared (see below). Is this normal?
Yes
To follow up yesterday's posts, the issue was solved in the latest mwan3 v1.4-16
Kudos to Adze!
Latest recommended releases:
mwan3 1.4-17
mwan3-luci 1.2-19
I'm not likely to be adding any new functionality to the luci application for some time. If I notice anything that could visually look better I will make minor updates.
If you think you have a great idea for a new feature or changing the existing ones let me know.
(Last edited by arfett on 3 May 2014, 18:17)
Hi, thanks for your work.
I'm using this with dual wan setup and openvpn tunel for vpn and internet failover - works ok.
One thing: I can't ping router openvpn tunel ip address after starting mwan3.
Looks like tun0 iface local ip needs handling in mwan3_connected chain.
It might be the case for other p2p ifaces like ppp too.
?
At least for me a setup with two OpenVPN client doesn't work.I got managed to change both VPN WANs green in mwan3, but only after applying a lot of changes like removing the pushed routes and setting static default gateways for both VPN WANs.
But even after doing these changes mwan3 did not work the desired way, so it seems that this project is not suitable for dynamic VPN connections.It doesn't make any sense to use this when it requires so much manual intervention.I really would like to see a solution for dynamic vpn connections ( mwan3 however works great for other WANs like dynamic IP & 3G )
twelvekit wrote:
At least for me a setup with two OpenVPN client doesn't work.I got managed to change both VPN WANs green in mwan3, but only after applying a lot of changes like removing the pushed routes and setting static default gateways for both VPN WANs.
But even after doing these changes mwan3 did not work the desired way, so it seems that this project is not suitable for dynamic VPN connections.It doesn't make any sense to use this when it requires so much manual intervention.I really would like to see a solution for dynamic vpn connections ( mwan3 however works great for other WANs like dynamic IP & 3G )
Do you care to elaborate on how "mwan3 did not work the desired way"?
Perhaps Adze could respond if you provided anything at all.
twelvekit wrote:
At least for me a setup with two OpenVPN client doesn't work.I got managed to change both VPN WANs green in mwan3, but only after applying a lot of changes like removing the pushed routes and setting static default gateways for both VPN WANs.
That is exactly what you have have to do to make it work. Create a default route for each VPN tunnel and remove any more specific routes.
twelvekit wrote:
But even after doing these changes mwan3 did not work the desired way, so it seems that this project is not suitable for dynamic VPN connections.It doesn't make any sense to use this when it requires so much manual intervention.I really would like to see a solution for dynamic vpn connections ( mwan3 however works great for other WANs like dynamic IP & 3G )
I'm sorry to hear that, but i think your conclusion is incorrect. I have made a setup with 2 physical wans and and 4 openvpn tunnels and i could load-balance all traffic exactly how i wanted it. I'm agreeing with you on the complexity it brings to configure this correctly.
(Last edited by Adze on 10 May 2014, 08:54)
Adze wrote:
I'm sorry to hear that, but i think your conclusion is incorrect. I have made a setup with 2 physical wans and and 4 openvpn tunnels and i could load-balance all traffic exactly how i wanted it. I'm agreeing with you on the complexity it brings to configure this correctly.
Some more details about how to configure VPN tunnel fail-over with mwan3 would be most helpful.
Are there any (known) limitations to be aware of?
kpv wrote:
Some more details about how to configure VPN tunnel fail-over with mwan3 would be most helpful.
Are there any (known) limitations to be aware of?
I don't have this setup running anymore, so no direct examples, but here is how you could do it. Example setup with two physical wans and two vpn wans, where internet traffic is load-balanced through the vpn wans:
- First create a mwan3 configuration with only two physical wans, like normal, with the exception that you don't create a default traffic rule (yet).
- Create rules for load-balancing vpn traffic. In below example i use a.a.a.a and b.b.b.b as my vpn endpoints.
- Setup your vpn connection with e.g. openvpn and don't accept any pushed routes from peer vpn endpoint.
- Create a wan interface in your network config for each vpn tunnel with proto set to none.
- Create a route for each vpn wan interface in your network config with an unique metric higher then the physical wans.
- Create correct firewall rules to allow vpn traffic.
- Edit your mwan3 config and add the two vpn wans.
- Create members, policies and rules for the vpn wans and you are done.
Something would look like this:
config interface 'wan'
option enabled '1'
config interface 'wan2'
option enabled '1'
config interface 'vpn1'
option enabled '1'
config interface 'vpn2'
option enabled '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'
config member 'vpn1_m3_w3'
option interface 'vpn1'
option metric '3'
option weight '3'
config member 'vpn2_m3_w2'
option interface 'vpn2'
option metric '3'
option weight '2'
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 policy 'balanced'
list use_member 'wan_m1_w3'
list use_member 'wan2_m1_w2'
config policy 'vpn_balance'
list use_member 'vpn1_m3_w3'
list use_member 'vpn2_m3_w2'
config rule 'dns'
option dest_port '53'
option proto 'udp'
option use_policy 'balance'
config rule 'vpn_endpoint1'
option dest_ip 'a.a.a.a'
option dest_port '1194'
option proto 'udp'
option use_policy 'wan_wan2'
config rule 'vpn_endpoint2'
option dest_ip 'b.b.b.b'
option dest_port '1194'
option proto 'udp'
option use_policy 'wan2_wan'
config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option use_policy 'vpn_balance'(Last edited by Adze on 10 May 2014, 20:35)
Does mwan3 support ipv6 tunnel forcing traffic to go through certain interface?
alphasparc wrote:
Does mwan3 support ipv6 tunnel forcing traffic to go through certain interface?
Yes, based upon your configured rules.
I have some troubles with mwan3 and gre tunnels.
I have router with two isp connections and failover with mwan3 works fine. But I also have few gre tunnels with ospf routing over them, couple of tunnels for each remote site - one per isp on my router.
Tunnels work as expected when mwan3 is disabled, but only I have activated mwan3 traffic flow to remote site stopped. Ospf traffic goes without any troubles, routes are propagated.
I tryed a lot of variants of settings, also tryed to isolate local subnet of remote site from mwan3 processing with rules like this:
config rule 'vserver01'
option dest_ip '192.168.122.0/24'
option use_policy 'default'But hadn't got success.
Configs (I show data only for one site, rest have the same configuration):
/etc/config/network
config interface 'lan'
option ifname 'eth0.1'
option type 'bridge'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
config interface 'wan'
option ifname 'eth0.10'
option proto 'static'
option ipaddr 'X.X.X.26'
option netmask '255.255.255.252'
option gateway 'X.X.X.25'
option metric '10'
option dns '213.160.128.3 213.160.134.23'
config interface 'wanfailover'
option ifname 'eth0.11'
option proto 'dhcp'
option metric '20'
config interface 'vserver011'
option proto 'tunnel'
option ifname 'vserver011'
option tunnel_start 'X.X.X.26'
option tunnel_end 'X.X.X.216'
option local_address '192.168.251.1'
option remote_address '192.168.251.2/30'
option mtu '1476'
option mode 'gre'
config interface 'vserver012'
option proto 'tunnel'
option ifname 'vserver012'
option tunnel_start 'X.X.X.82'
option tunnel_end 'X.X.X.216'
option local_address '192.168.251.5'
option remote_address '192.168.251.6/30'
option mtu '1476'
option mode 'gre'/etc/config/mwan3
config interface 'wan'
option enabled '1'
list track_ip 'X.X.X.25'
option reliability '1'
option count '3'
option timeout '2'
option interval '5'
option down '3'
option up '8'
config interface 'wanfailover'
option enabled '1'
list track_ip 'X.X.X.1'
option reliability '1'
option count '3'
option timeout '2'
option interval '5'
option down '3'
option up '8'
config member 'wan1'
option interface 'wan'
option metric '10'
option weight '3'
config member 'wan2'
option interface 'wanfailover'
option metric '20'
option weight '3'
config policy 'wan_failover'
list use_member 'wan1'
list use_member 'wan2'
config rule 'vserver01'
option dest_ip '192.168.122.0/24'
option use_policy 'default'
config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option use_policy 'wan_failover'Diagnostic:
root@gate:~# ip ru li
0: from all lookup local
1001: from all iif eth0.10 lookup main
1002: from all iif eth0.11 lookup main
2001: from all fwmark 0x100/0xff00 lookup 1
2002: from all fwmark 0x200/0xff00 lookup 2
2254: from all fwmark 0xfe00/0xff00 unreachable
32765: from 77.120.245.82 lookup wanfailover_policy
32766: from all lookup main
32767: from all lookup defaultroot@gate:~# ip ro li
default via X.X.X.25 dev eth0.10 proto static
default via X.X.X.1 dev eth0.11 proto static metric 20
X.X.X.0/23 dev eth0.11 proto static scope link metric 20
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
192.168.122.0/24 via 192.168.251.2 dev vserver011 proto zebra metric 20
192.168.251.0/30 dev vserver011 proto kernel scope link src 192.168.251.1
192.168.251.4/30 dev vserver012 proto kernel scope link src 192.168.251.5
X.X.X.24/30 dev eth0.10 proto static scope link metric 10
root@gate:~# ip ro li table 1
default via X.X.X.25 dev eth0.10
root@gate:~# ip ro li table 2
default via X.X.X.1 dev eth0.11 On the router:
root@gate:~# ping -I 192.168.1.1 192.168.122.101 >/dev/null 2>&1 &
root@gate:~# tcpdump -i vserver011 -annv proto 1
tcpdump: listening on vserver011, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
21:08:58.540903 IP (tos 0x0, ttl 64, id 27334, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 2751, seq 5, length 64
21:08:59.541217 IP (tos 0x0, ttl 64, id 27335, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 2751, seq 6, length 64
21:09:00.541525 IP (tos 0x0, ttl 64, id 27336, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 2751, seq 7, length 64No any packets on other side of tunnel. Tcpdump show no GRE encpsulated packets with ping on the first wan (eth0.10), but on the second (eth0.11) I see:
root@gate:~# tcpdump -i eth0.11 -annv host X.X.X.216
21:13:26.619141 IP (tos 0x0, ttl 255, id 34247, offset 0, flags [DF], proto GRE (47), length 108)
X.X.X.26 > X.X.X.216: GREv0, Flags [none], length 88
IP (tos 0x0, ttl 64, id 27602, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 2751, seq 273, length 64
21:13:27.619426 IP (tos 0x0, ttl 255, id 34254, offset 0, flags [DF], proto GRE (47), length 108)
X.X.X.26 > X.X.X.216: GREv0, Flags [none], length 88
IP (tos 0x0, ttl 64, id 27603, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 2751, seq 274, length 64
21:13:28.619737 IP (tos 0x0, ttl 255, id 34261, offset 0, flags [DF], proto GRE (47), length 108)
X.X.X.26 > X.X.X.216: GREv0, Flags [none], length 88
IP (tos 0x0, ttl 64, id 27604, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 2751, seq 275, length 64As you can see - source address is from first interface, but packets are sent via second one...
I need some help from community to identify the causes of such behavior. Tnk
PS. Sorry for my English.
Hi mkolomiets,
I see something strange in your "ip rule list" output. What does rule 32765 do?
Could you also post output "mwan3 status"?
I see that you have configured two tunnels to the same remote site. Is that correct? If you wish to have gre tunnel 1 traverse wan 1 and tunnel 2 wan 2, then you need rules for them as well. Please try below config:
config interface 'wan'
option enabled '1'
list track_ip 'X.X.X.25'
option reliability '1'
option count '3'
option timeout '2'
option interval '5'
option down '3'
option up '8'
config interface 'wanfailover'
option enabled '1'
list track_ip 'X.X.X.1'
option reliability '1'
option count '3'
option timeout '2'
option interval '5'
option down '3'
option up '8'
config member 'wan1'
option interface 'wan'
option metric '10'
option weight '3'
config member 'wan2'
option interface 'wanfailover'
option metric '20'
option weight '3'
config policy 'wan_failover'
list use_member 'wan1'
list use_member 'wan2'
config policy 'wan1_only'
list use_member 'wan1'
config policy 'wan2_only'
list use_member 'wan2'
config rule 'tunnel1'
option proto 'gre'
option src_ip 'x.x.x.26'
option dest_ip 'x.x.x.216'
option use_policy 'wan1_only'
config rule 'tunnel2'
option proto 'gre'
option src_ip 'x.x.x.82'
option dest_ip 'x.x.x.216'
option use_policy 'wan2_only'
config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option use_policy 'wan_failover'(Last edited by Adze on 11 May 2014, 20:25)
Hi, Adze!
Thanks for reply!
Adze wrote:
I see something strange in your "ip rule list" output. What does rule 32765 do?
It is mine. This is policy for reply on incoming traffic on wan2. I have tryed to disable this policy, nothing was changed.
root@gate:~# ip ro li table wanfailover_policy
default via 77.120.244.1 dev eth0.11 Could you also post output "mwan3 status"?
I lost, sorry. Here it.
root@gate:~# mwan3 status
Interface status:
Interface wan is online (tracking active)
Interface wanfailover is online (tracking active)
Policy wan_failover:
wan (100%)
Local connected networks:
destination policy hits
------------------------------------------------
127.0.0.0/8 default 41
224.0.0.0/3 default 1571
X.X.X.0/23 default 901
192.168.1.0/24 default 862
192.168.122.0/24 default 31
192.168.122.1 default 0
192.168.123.0/24 default 4
192.168.123.1 default 0
192.168.123.2 default 0
192.168.124.0/24 default 3
192.168.124.1 default 0
192.168.200.0/24 default 3
192.168.200.1 default 0
192.168.250.0/30 default 0
192.168.250.4/30 default 4
192.168.251.0/30 default 1
192.168.251.4/30 default 4
192.168.252.0/30 default 0
192.168.252.4/30 default 4
192.168.253.0/30 default 0
192.168.253.4/30 default 0
X.X.X.24/30 default 901
Active rules:
source destination proto src-port dest-port policy hits
---------------------------------------------------------------------------------------------------
0.0.0.0/0 192.168.200.0/24 all MARK 0
0.0.0.0/0 192.168.122.0/24 all MARK 0
0.0.0.0/0 192.168.123.0/24 all MARK 0
0.0.0.0/0 192.168.124.0/24 all MARK 0
0.0.0.0/0 0.0.0.0/0 all wan_failover 1902 I see that you have configured two tunnels to the same remote site. Is that correct?
Exactly. Those tunnels have different route cost for ospf.
If you wish to have gre tunnel 1 traverse wan 1 and tunnel 2 wan 2, then you need rules for them as well. Please try below config:
This is new mwan3 config:
config interface 'wan'
option enabled '1'
list track_ip '213.160.139.25'
option reliability '1'
option count '3'
option timeout '2'
option interval '5'
option down '3'
option up '8'
config interface 'wanfailover'
option enabled '1'
list track_ip '77.120.244.1'
option reliability '1'
option count '3'
option timeout '2'
option interval '5'
option down '3'
option up '8'
config member 'wan1'
option interface 'wan'
option metric '10'
option weight '3'
config member 'wan2'
option interface 'wanfailover'
option metric '20'
option weight '3'
config policy 'wan_failover'
list use_member 'wan1'
list use_member 'wan2'
config policy 'wan1_only'
list use_member 'wan1'
config policy 'wan2_only'
list use_member 'wan2'
config rule 'vserver011'
option proto 'gre'
option src_ip 'X.X.X.26'
option dest_ip 'X.X.X.216'
option use_policy 'wan1_only'
config rule 'vserver012'
option proto 'gre'
option src_ip 'X.X.X.82'
option dest_ip 'X.X.X.216'
option use_policy 'wan2_only'
config rule 'default_rule'
option dest_ip '0.0.0.0/0'
option use_policy 'wan_failover'Nothing changed - gre packets with source address of first wan interface, are outcoming via second wan interface. Some mystique there;)
Status w/new config, counters for new rules are empty...
Interface status:
Interface wan is online (tracking active)
Interface wanfailover is online (tracking active)
Policy wan1_only:
wan (100%)
Policy wan2_only:
wanfailover (100%)
Policy wan_failover:
wan (100%)
Local connected networks:
destination policy hits
------------------------------------------------
127.0.0.0/8 default 41
224.0.0.0/3 default 310
X.X.X.0/23 default 111
192.168.1.0/24 default 110
192.168.122.0/24 default 2
192.168.122.1 default 0
192.168.123.0/24 default 0
192.168.123.1 default 0
192.168.123.2 default 0
192.168.124.0/24 default 0
192.168.124.1 default 0
192.168.200.0/24 default 0
192.168.200.1 default 0
192.168.250.0/30 default 0
192.168.250.4/30 default 0
192.168.251.0/30 default 0
192.168.251.4/30 default 0
192.168.252.0/30 default 0
192.168.252.4/30 default 0
192.168.253.0/30 default 0
192.168.253.4/30 default 0
X.X.X.24/30 default 111
Active rules:
source destination proto src-port dest-port policy hits
---------------------------------------------------------------------------------------------------
X.X.X.26 X.X.X.216 all wan1_only 0
X.X.X.82 X.X.X.216 all wan2_only 0
0.0.0.0/0 0.0.0.0/0 all wan_failover 655Dump for second wan. Not native packets still are there.
root@gate:~# tcpdump -i eth0.11 -annv host X.X.X.26 and host X.X.X.216
tcpdump: listening on eth0.11, link-type EN10MB (Ethernet), capture size 65535 bytes
23:37:07.822965 IP (tos 0x0, ttl 255, id 41032, offset 0, flags [DF], proto GRE (47), length 108)
X.X.X.26 > X.X.X.216: GREv0, Flags [none], length 88
IP (tos 0x0, ttl 64, id 24095, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 3191, seq 2, length 64
23:37:08.823275 IP (tos 0x0, ttl 255, id 41039, offset 0, flags [DF], proto GRE (47), length 108)
X.X.X.26 > X.X.X.216: GREv0, Flags [none], length 88
IP (tos 0x0, ttl 64, id 24096, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.1.1 > 192.168.122.101: ICMP echo request, id 3191, seq 3, length 64There is some question there. Why ospf packets walk as expected? There are dumps for both wan interfaces:
eth0.10
22:51:54.050544 IP (tos 0x0, ttl 255, id 10257, offset 0, flags [DF], proto GRE (47), length 92)
X.X.X.26 > X.X.X.216: GREv0, Flags [none], length 72
IP (tos 0xc0, ttl 1, id 58484, offset 0, flags [none], proto OSPF (89), length 68)
192.168.251.1 > 224.0.0.5: OSPFv2, Hello, length 48
Router-ID 192.168.1.1, Backbone Area, Authentication Type: none (0)
Options [External]
Hello Timer 0s, Dead Timer 1s, Mask 255.255.255.252, Priority 1
Designated Router 192.168.251.2, Backup Designated Router 192.168.251.1
Neighbor List:
192.168.122.1
22:51:54.151773 IP (tos 0x0, ttl 241, id 0, offset 0, flags [DF], proto GRE (47), length 92)
X.X.X.216 > X.X.X.26: GREv0, Flags [none], length 72
IP (tos 0xc0, ttl 1, id 64135, offset 0, flags [none], proto OSPF (89), length 68)
192.168.251.2 > 224.0.0.5: OSPFv2, Hello, length 48
Router-ID 192.168.122.1, Backbone Area, Authentication Type: none (0)
Options [External]
Hello Timer 0s, Dead Timer 1s, Mask 255.255.255.252, Priority 1
Designated Router 192.168.251.2, Backup Designated Router 192.168.251.1
Neighbor List:
192.168.1.1eth0.11
22:58:24.051083 IP (tos 0x0, ttl 255, id 12993, offset 0, flags [DF], proto GRE (47), length 92)
X.X.X.82 > X.X.X.216: GREv0, Flags [none], length 72
IP (tos 0xc0, ttl 1, id 57181, offset 0, flags [none], proto OSPF (89), length 68)
192.168.251.5 > 224.0.0.5: OSPFv2, Hello, length 48
Router-ID 192.168.1.1, Backbone Area, Authentication Type: none (0)
Options [External]
Hello Timer 0s, Dead Timer 1s, Mask 255.255.255.252, Priority 1
Designated Router 192.168.251.6, Backup Designated Router 192.168.251.5
Neighbor List:
192.168.122.1
22:58:24.259344 IP (tos 0x88, ttl 241, id 0, offset 0, flags [DF], proto GRE (47), length 92)
X.X.X.216 > X.X.X.82: GREv0, Flags [none], length 72
IP (tos 0xc0, ttl 1, id 59041, offset 0, flags [none], proto OSPF (89), length 68)
192.168.251.6 > 224.0.0.5: OSPFv2, Hello, length 48
Router-ID 192.168.122.1, Backbone Area, Authentication Type: none (0)
Options [External]
Hello Timer 0s, Dead Timer 1s, Mask 255.255.255.252, Priority 1
Designated Router 192.168.251.6, Backup Designated Router 192.168.251.5
Neighbor List:
192.168.1.1(Last edited by mkolomiets on 12 May 2014, 04:40)
Hi mkolomiets,
Hmmm. I'm not sure what's wrong, but i have a hunch. Can you confirm that when you stop mwan3 "mwan3 stop", that all traffic passes the correct gre tunnels? Outgoing as well as incomming?!?
The reason i ask this is because there is no reason for mwan3 to route traffic out of the second wan, unless a packet from a session is received on the second wan. When a packet from a related or established session is received on a wan interface, all packets for that sessions will be marked to leave that particular wan interface. I suspect that the very first gre tunnel packet traversed the first wan, a reply was sent back to the second wan and all subsequent packets are now marked for second wan.
Is it possible i could get access to your router and troubleshoot some more?
Thnx!
Hi
Adze wrote:
Hmmm. I'm not sure what's wrong, but i have a hunch. Can you confirm that when you stop mwan3 "mwan3 stop", that all traffic passes the correct gre tunnels? Outgoing as well as incomming?!?
Yes, pings between sites have gone as only I stopped mwan3 service. But I didn't see those packets on second interface which I showed earlier after I started mwan3 service again.
The reason i ask this is because there is no reason for mwan3 to route traffic out of the second wan, unless a packet from a session is received on the second wan. When a packet from a related or established session is received on a wan interface, all packets for that sessions will be marked to leave that particular wan interface. I suspect that the very first gre tunnel packet traversed the first wan, a reply was sent back to the second wan and all subsequent packets are now marked for second wan.
For verify this sentence it is need to disable ospf because it makes a lot of packets. It is possible to define static routes between sites. I'll test it in the evening today.
Is it possible i could get access to your router and troubleshoot some more?
Yes, it is. But I need to reconcile maintenance time - it is production system. What time is acceptable for you?
Would be better if that wont in workhours, after 20:00 and until 08:00, GMT+3h. But in any case, I think that it is possible to find another time if need.
Thank you!
(Last edited by mkolomiets on 12 May 2014, 12:31)
Hi Adze!
Adze wrote:
Hmmm. I'm not sure what's wrong, but i have a hunch. Can you confirm that when you stop mwan3 "mwan3 stop", that all traffic passes the correct gre tunnels? Outgoing as well as incomming?!?
I have upgraded router with latest firmware and problem has gone:)
Thank you!
How do you configure a 6in4 tunnel with 1 normal uplink?
Hi Adze!
I think that the protocol selector was lost in this row, isn't it?
/etc/hotplug.d/iface/15-mwan3
mwan3_set_user_rules_iptables()
{
local proto src_ip src_port dest_ip dest_port use_policy
...
*)
iptables -A mwan3_rules -t mangle -s $src_ip -d $dest_ip -m mark --mark 0/0xff00 -m comment --comment "$1" -j $use_policy &> /dev/null
;;
...
}(Last edited by mkolomiets on 13 May 2014, 14:19)
mkolomiets wrote:
I have upgraded router with latest firmware and problem has gone:)
Thank you!
Do you mean latest mwan3 package v1.4-17, or the latest OpenWRT (e.g. Barrier Breaker r40700+) ?
Hi!
kpv wrote:
mkolomiets wrote:I have upgraded router with latest firmware and problem has gone:)
Thank you!
Do you mean latest mwan3 package v1.4-17, or the latest OpenWRT (e.g. Barrier Breaker r40700+) ?
Latest OpenWrt. There was a Barrier Breaker 405xx, I have upgraded it to r40749.
Mwan3 was latest in both cases.
alphasparc wrote:
How do you configure a 6in4 tunnel with 1 normal uplink?
I don't know, but you don't need mwan3 for that...
mkolomiets wrote:
Hi Adze!
I think that the protocol selector was lost in this row, isn't it?
You're right! I fixed it in version 1.4-18. Thnx!
Sorry, posts 726 to 725 are missing from our archive.
Page 29 of 65