|
Unstable 6in4 connection over time?
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Friday, 16 August 2013 17:09:49
Hi all,
I have a 6in4 tunnel configured on my router running OpenWRT. Most of the time, it works fine, but sometimes it becomes unstable. I get packet loss and a lot of errors.
Restarting the network interface 'operating' the tunnel generally solves the problem.
Look at this graph for example:
http://home.tuxplace.nl:8282/cacti/graph.php?action=view&local_graph_id=129&rra_id=all
ifconfig
6in4-sixxs Link encap:IPv6-in-IPv4
inet6 addr: fe80::c0a8:103/128 Scope:Link
inet6 addr: 2001:610:600:9c4::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:218173 errors:159 dropped:0 overruns:0 frame:0
TX packets:81919 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:271182081 (258.6 MiB) TX bytes:7287995 (6.9 MiB)
A lot of "errors in" as you can see.
Any ideas what could cause this?
Unstable 6in4 connection over time?
inet6 addr: fe80::c0a8:103/128 Scope:Link
That indicates an RFC1918 address (192.168.16.3), how are you passing the proto-41 packets from the Internet to that address and from you to the PoP?
A lot of "errors in" as you can see.
Afaik the only error counter that Linux's kernels have is when they cannot transmit.
Do check your full setup, check your logs, do tcpdumps etc.
Unstable 6in4 connection over time?
Shadow Hawkins on Friday, 16 August 2013 17:51:32
Jeroen Massar wrote:
> inet6 addr: fe80::c0a8:103/128 Scope:Link
That indicates an RFC1918 address (192.168.16.3), how are you passing the proto-41 packets from the Internet to that address and from you to the PoP?
I am not. That link-local address is automatically assigned to each interface but it isn't used.
Look at the line under that one: inet6 addr: 2001:610:600:9c4::2/64 Scope:Global
If you are interested, this is my OpenWRT network config for that interface:
config interface 'sixxs'
option proto '6in4'
option peeraddr '192.87.102.107'
option ip6addr '2001:610:600:9c4::2/64'
option ip6prefix '2001:610:1b10::/48'
> A lot of "errors in" as you can see.
Afaik the only error counter that Linux's kernels have is when they cannot transmit.
Do check your full setup, check your logs, do tcpdumps etc.
Well why is the error shown as "RX error" and not as "TX error"?
Unstable 6in4 connection over time?
inet6 addr: fe80::c0a8:103/128 Scope:Link That indicates an RFC1918 address (192.168.16.3), how are you passing the proto-41 packets from the Internet to that address and from you to the PoP? I am not. That link-local address is automatically assigned to each interface but it isn't used.
That link-local address is generated from the configured addresses on the host. If you have one interface (which looks like it in your case) you only have 1, if you have multiple interfaces/addresses on the host, all of them will be reflected there in a similar way.
Look at the line under that one:
That is an IPv6 address; but as I state above, the link-local is generated from the IPv4 addresses, and you only seem to have 192.168.16.3 configured and thus have to be behind a NAT.
inet6 addr: 2001:610:600:9c4::2/64 Scope:Global If you are interested, this is my OpenWRT network config for that interface:
Totally irrelevant, especially as OpenWRT scripts do all kind of magic.
option ip6prefix '2001:610:1b10::/48'
That is per definition wrong btw. The /48 is a routed prefix and does not belong on a tunnel interface. Next to that, one should never (unless nullrouting) put a /48 on an interface, only /64s should be configured for RA to work.
Actual output of 'ip -6 ro show', 'ip -4 ro show", "ip -6 addr show" and "ip -4 addr show" would be useful.
A lot of "errors in" as you can see. Afaik the only error counter that Linux's kernels have is when they cannot transmit. Do check your full setup, check your logs, do tcpdumps etc. Well why is the error shown as "RX error" and not as "TX error"?
If you would be able to provide the source of the exact kernel you are running (openwrt folks love to add all kinds of odd patches) then you could check what paths might increment the error counter.
Likely though it means that the underlying interface went up/down and thus caused issues, or that there where memory/buffer issues that caused failures.
Hard to tell though. One good bet is to check those logs. ("readlog" is the command apparently, not actual files which would be useful but not feasible on a box with almost no storage)
Unstable 6in4 connection over time?
Shadow Hawkins on Friday, 16 August 2013 18:38:17
Jeroen Massar wrote:
>>> inet6 addr: fe80::c0a8:103/128 Scope:Link
I'm not sure if I understand what you are telling me. Because this is my router, I have a whole bunch of interfaces, but I only posted the relevant interface. This is the complete list:
http://pastebin.com/hR1iMsRU
That indicates an RFC1918 address (192.168.16.3), how are you passing the proto-41 packets from the Internet to that address and from you to the PoP? I am not. That link-local address is automatically assigned to each interface but it isn't used.
That link-local address is generated from the configured addresses on the host. If you have one interface (which looks like it in your case) you only have 1, if you have multiple interfaces/addresses on the host, all of them will be reflected there in a similar way.
> Look at the line under that one:
I don't know where that address (192.168.16.3) is coming from. I don't use that range anywhere in my network.
inet6 addr: 2001:610:600:9c4::2/64 Scope:Global
That is an IPv6 address; but as I state above, the link-local is generated from the IPv4 addresses, and you only seem to have 192.168.16.3 configured and thus have to be behind a NAT.
> If you are interested, this is my OpenWRT network config for that interface:
Totally irrelevant, especially as OpenWRT scripts do all kind of magic.
Are you sure? Because this is the explanation for that option:
"This is the prefix routed to you by the tunnel broker for use by clients"
So actually I want that /48 to be routed to my clients so I put it there. I don't understand why that is wrong. (BTW, it works as it should this way, so I guess it is correct)
option ip6prefix '2001:610:1b10::/48'
That is per definition wrong btw. The /48 is a routed prefix and does not belong on a tunnel interface. Next to that, one should never (unless nullrouting) put a /48 on an interface, only /64s should be configured for RA to work.
Actual output of 'ip -6 ro show', 'ip -4 ro show", "ip -6 addr show" and "ip -4 addr show" would be useful.
It seems like OpenWRT doesn't use ip:
# ip -6 ro show
-ash: ip: not found
>>> A lot of "errors in" as you can see.
Weird, on another Linux box running Debian Jessie (Linux 3.10) I got these counters (RX errors as well as TX errors) too. They are on 0, fortunately, like they should be ;)
Oh, and BTW: Thanks for helping me out :)
Afaik the only error counter that Linux's kernels have is when they cannot transmit. Do check your full setup, check your logs, do tcpdumps etc. Well why is the error shown as "RX error" and not as "TX error"?
If you would be able to provide the source of the exact kernel you are running (openwrt folks love to add all kinds of odd patches) then you could check what paths might increment the error counter.
Likely though it means that the underlying interface went up/down and thus caused issues, or that there where memory/buffer issues that caused failures.
Hard to tell though. One good bet is to check those logs. ("readlog" is the command apparently, not actual files which would be useful but not feasible on a box with almost no storage)
Unstable 6in4 connection over time?
Because this is my router, I have a whole bunch of interfaces, but I only posted the relevant interface.
Then check with 'ip tunnel show sixxs' what the local component is, it might be that if you set it to a proper local address that then the other local addresses do not show up.
I do not see any public (non-RFC1918) address below:
# ifconfig
6in4-sixxs Link encap:IPv6-in-IPv4
inet6 addr: fe80::c0a8:103/128 Scope:Link
inet6 addr: 2001:610:600:9c4::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:371109 errors:229 dropped:0 overruns:0 frame:0
TX packets:142203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:462887515 (441.4 MiB) TX bytes:11442688 (10.9 MiB)
br-lan Link encap:Ethernet HWaddr 00:23:CD:18:F3:86
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::223:cdff:fe18:f386/64 Scope:Link
inet6 addr: 2001:610:1b10:1::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1056383 errors:0 dropped:27 overruns:0 frame:0
TX packets:1329459 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:380804694 (363.1 MiB) TX bytes:916686689 (874.2 MiB)
br-restricted Link encap:Ethernet HWaddr 00:23:CD:18:F3:86
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::223:cdff:fe18:f386/64 Scope:Link
inet6 addr: 2001:610:1b10:2::1/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:256172 errors:0 dropped:0 overruns:0 frame:0
TX packets:813258 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18899872 (18.0 MiB) TX bytes:1104259285 (1.0 GiB)
eth0 Link encap:Ethernet HWaddr 00:23:CD:18:F3:86
inet6 addr: fe80::223:cdff:fe18:f386/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3438297 errors:0 dropped:21 overruns:2448 frame:0
TX packets:3432178 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2462607809 (2.2 GiB) TX bytes:2442656958 (2.2 GiB)
Interrupt:4
eth0.1 Link encap:Ethernet HWaddr 00:23:CD:18:F3:86
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1042649 errors:0 dropped:0 overruns:0 frame:0
TX packets:1317845 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:379086105 (361.5 MiB) TX bytes:905077123 (863.1 MiB)
eth0.2 Link encap:Ethernet HWaddr 00:23:CD:18:F3:86
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::223:cdff:fe18:f386/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2139075 errors:0 dropped:0 overruns:0 frame:0
TX packets:1301070 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2002678474 (1.8 GiB) TX bytes:419590367 (400.1 MiB)
eth0.3 Link encap:Ethernet HWaddr 00:23:CD:18:F3:86
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:256172 errors:0 dropped:0 overruns:0 frame:0
TX packets:813258 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18899872 (18.0 MiB) TX bytes:1104259285 (1.0 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1648 (1.6 KiB) TX bytes:1648 (1.6 KiB)
wlan0 Link encap:Ethernet HWaddr 00:23:CD:18:F3:86
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15984 errors:0 dropped:0 overruns:0 frame:0
TX packets:20594 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2647601 (2.5 MiB) TX bytes:14156775 (13.5 MiB)
wlan0-1 Link encap:Ethernet HWaddr 02:23:CD:18:F3:86
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1016 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:168772 (164.8 KiB)
It seems like OpenWRT doesn't use ip: # ip -6 ro show -ash: ip: not found
If you do not have 'ip', then what is able to configure these tunnels and show the details?
You might want to install the iproute package, that would resolve that.
Weird, on another Linux box running Debian Jessie (Linux 3.10) I got these counters (RX errors as well as TX errors) too. They are on 0, fortunately, like they should be ;)
Of course those counters are there; but now the fun question: you did not configure two tunnels with the same parameters I hope?
Unstable 6in4 connection over time?
Shadow Hawkins on Saturday, 17 August 2013 15:08:39
Jeroen Massar wrote:
> Because this is my router, I have a whole bunch of interfaces, but I only posted the relevant interface.
Then check with 'ip tunnel show sixxs' what the local component is, it might be that if you set it to a proper local address that then the other local addresses do not show up.
I do not see any public (non-RFC1918) address below:
Oh, now I get what you're meaning. ;) The router is indeed behind NAT, but it is in DMZ. So effectively all ports are open and it shouldn't cause any problems. This is because I got a router-behind-a-router-situation: My ISP forces me to use their modem/router-combination.
(ifconfig output)
As such, my statement that you are behind a NAT stands; that might be causing issues. Please check your network setup.
> It seems like OpenWRT doesn't use ip:
I don't know. I don't know what OpenWRT uses for that. There is no iproute package available and I don't feel that it's a problem.
# ip -6 ro show -ash: ip: not found
If you do not have 'ip', then what is able to configure these tunnels and show the details?
You might want to install the iproute package, that would resolve that.
> Weird, on another Linux box running Debian Jessie (Linux 3.10) I got these counters (RX errors as well as TX errors) too. They are on 0, fortunately, like they should be ;)
Of course those counters are there; but now the fun question: you did not configure two tunnels with the same parameters I hope?
No, why? I only got one tunnel :)
Unstable 6in4 connection over time?
it shouldn't cause any problems.
We have seen at a variety of setups that it does cause problems; hence why I note it, as you are having problems. Thus it is definitely something to keep in mind.
I don't know. I don't know what OpenWRT uses for that. There is no iproute package available and I don't feel that it's a problem.
It is a problem from the fact that you cannot check the actual settings of the tunnel.
Check if there is a package called 'iproute', 'iproute2' or heck even maybe just 'ip'.
Next to that, time to check your firewall rules and a lot of other things that are listed on the contact page.
Of course those counters are there; but now the fun question: you did not configure two tunnels with the same parameters I hope? No, why? I only got one tunnel :)
Then why are you making the comparison? Counters will be 0 when there are no errors when they are not configured.
Unstable 6in4 connection over time?
Shadow Hawkins on Sunday, 18 August 2013 14:56:32
Jeroen Massar wrote:
> it shouldn't cause any problems.
We have seen at a variety of setups that it does cause problems; hence why I note it, as you are having problems. Thus it is definitely something to keep in mind.
I can ask my ISP to set their modem/router to bridge mode. That way I my own router isn't behind NAT anymore. Do you think it's worth a try?
> I don't know. I don't know what OpenWRT uses for that. There is no iproute package available and I don't feel that it's a problem.
It is a problem from the fact that you cannot check the actual settings of the tunnel.
Check if there is a package called 'iproute', 'iproute2' or heck even maybe just 'ip'.
Thx, there is a package named ip
# ip -6 ro show
2001:610:600:9c4::/64 dev 6in4-sixxs proto kernel metric 256
2001:610:1b10:1::/64 dev br-lan proto kernel metric 256
2001:610:1b10:2::/64 dev br-restricted proto kernel metric 256
unreachable 2001:610:1b10::/48 dev lo proto static metric 2147483647 error -128
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev br-lan proto kernel metric 256
fe80::/64 dev br-restricted proto kernel metric 256
fe80::/64 dev eth0.2 proto kernel metric 256
# ip -4 ro show
default via 192.168.1.1 dev eth0.2 proto static
192.168.1.0/24 dev eth0.2 proto kernel scope link src 192.168.1.3
192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev br-restricted proto kernel scope link src 192.168.3.1
ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::223:cdff:fe18:f386/64 scope link
valid_lft forever preferred_lft forever
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2001:610:1b10:1::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::223:cdff:fe18:f386/64 scope link
valid_lft forever preferred_lft forever
8: br-restricted: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2001:610:1b10:2::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::223:cdff:fe18:f386/64 scope link
valid_lft forever preferred_lft forever
10: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 fe80::223:cdff:fe18:f386/64 scope link
valid_lft forever preferred_lft forever
16: 6in4-sixxs: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480
inet6 2001:610:600:9c4::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::c0a8:103/128 scope link
valid_lft forever preferred_lft forever
# ip -4 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 192.168.2.1/24 brd 192.168.2.255 scope global br-lan
valid_lft forever preferred_lft forever
8: br-restricted: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 192.168.3.1/24 brd 192.168.3.255 scope global br-restricted
valid_lft forever preferred_lft forever
10: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0.2
valid_lft forever preferred_lft forever
Next to that, time to check your firewall rules and a lot of other things that are listed on the contact page.
Just a comparison between the tunnel interface and a normal (eth0) interface.
Of course those counters are there; but now the fun question: you did not configure two tunnels with the same parameters I hope? No, why? I only got one tunnel :)
Then why are you making the comparison? Counters will be 0 when there are no errors when they are not configured.
Unstable 6in4 connection over time?
Shadow Hawkins on Friday, 16 August 2013 18:40:00
Jeroen Massar wrote:
Hard to tell though. One good bet is to check those logs. ("readlog" is the command apparently, not actual files which would be useful but not feasible on a box with almost no storage)
I can't find any relevant info in the logs (checked both system log and kernel log).
|
![[ch]](/s/countries/ch.gif)
on Friday, 16 August 2013 17:33:02
Posting is only allowed when you are