|
Ticket ID: SIXXS #1094706 Ticket Status: User PoP: dedus01 - SpeedPartner GmbH (Duesseldorf)
dedus01 does not accept protocol 41 (IPv6 in IPv4) packets during short intervals (10 minutes)
![[de]](/s/countries/de.gif) Shadow Hawkins on Friday, 22 May 2009 19:45:29
I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there:
Hello,
I'm running an aiccu based tunnel from an ADSL internet connection. Aiccu runs on the machine which has the public IPv4 address (no NAT involved that is). Today I wanted to browse python.org, and found out that it didn't work because my SixXS tunnel dedus01 did not work.
Below is the tcpdump output from the machine on which aiccu is running (felicitas is the name of the machine), along with some comments from my side.
NIC handle MHD2-SIXXS, Tunnel T17742. The client is OpenWRT based (Linux 2.4.34 mips). See below for an IPv4 traceroute to dedus01.
dudus01 is IPv4 91.184.37.98, my machine is IPv4 85.181.254.119. All times are UTC.
At this time, the tunnel should have been up and working, but doesn't reply:
root@felicitas:~# tcpdump -ni ppp0 host 91.184.37.98
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:12:10.587018 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 24, length 64
17:12:11.587013 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 25, length 64
17:12:12.587017 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 26, length 64
17:12:13.814666 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
I killed aiccu and started it again:
17:12:25.502166 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:12:25.502887 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:12:31.626800 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:12:32.627015 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 1, length 64
17:12:33.627014 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 2, length 64
...
17:12:56.627016 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 25, length 64
17:12:57.627007 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 26, length 64
No responses to the IPv6 packets so far. Suddenly IPv4 ICMP unreachable messages are sent back:
17:12:58.627009 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 27, length 64
17:12:58.650600 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 unreachable, length 132
17:12:59.627103 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 28, length 64
17:12:59.648603 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 unreachable, length 132
...
17:13:05.627017 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 34, length 64
17:13:05.650604 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
No changes. Killing aiccu and starting it once again doesn't help either:
17:13:23.627016 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 52, length 64
17:13:23.650731 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:13:24.627015 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 53, length 64
17:13:24.648735 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:13:25.507369 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:13:25.627024 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 54, length 64
17:13:25.648739 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:13:26.188840 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:13:26.210745 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:13:27.187018 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 1, length 64
17:13:27.210749 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:13:28.187026 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 2, length 64
17:13:28.210754 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:13:33.934295 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:13:33.935016 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:13:41.515985 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:13:41.538824 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:13:42.517025 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 1, length 64
17:13:42.540828 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
Heartbeats appear to be sent, but no IPv6 communication:
17:14:33.517015 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 52, length 64
17:14:33.541097 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:14:33.937415 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:14:34.517010 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 53, length 64
17:14:34.541102 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
Killed and restarted aiccu once again:
17:15:39.699190 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:15:39.723469 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:16:10.020045 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:16:10.041606 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
17:16:17.714727 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:16:17.715448 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:16:18.945817 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:16:18.967653 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 port 0 unreachable, length 132
Some IPv4 ICMP communication:
17:18:20.194134 IP 85.181.254.119 > 91.184.37.98: ICMP echo request, id 28701, seq 0, length 64
17:18:20.216281 IP 91.184.37.98 > 85.181.254.119: ICMP echo reply, id 28701, seq 0, length 64
17:18:21.186981 IP 85.181.254.119 > 91.184.37.98: ICMP echo request, id 28701, seq 1, length 64
17:18:21.208276 IP 91.184.37.98 > 85.181.254.119: ICMP echo reply, id 28701, seq 1, length 64
Another aiccu restart, this time with tic.sixxs.net traffic included. Likely not very useful:
root@felicitas:~# tcpdump -ni ppp0 host 91.184.37.98 or host 213.204.193.2 or host 193.109.122.244
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:20:37.449217 IP 85.181.254.119.1116 > 213.204.193.2.3874: S 2970395692:2970395692(0) win 5808 <mss 1452,nop,nop,sackOK,nop,wscale 0>
17:20:37.485004 IP 213.204.193.2.3874 > 85.181.254.119.1116: S 1547404572:1547404572(0) ack 2970395693 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 10>
17:20:37.485242 IP 85.181.254.119.1116 > 213.204.193.2.3874: . ack 1 win 5808
17:20:37.625025 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 1:70(69) ack 1 win 6
17:20:37.625255 IP 85.181.254.119.1116 > 213.204.193.2.3874: . ack 70 win 5808
17:20:37.625894 IP 85.181.254.119.1116 > 213.204.193.2.3874: P 1:59(58) ack 70 win 5808
17:20:37.662977 IP 213.204.193.2.3874 > 85.181.254.119.1116: . ack 59 win 6
17:20:37.670983 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 70:99(29) ack 59 win 6
17:20:37.671392 IP 85.181.254.119.1116 > 213.204.193.2.3874: P 59:72(13) ack 99 win 5808
17:20:37.710980 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 99:114(15) ack 72 win 6
17:20:37.711451 IP 85.181.254.119.1116 > 213.204.193.2.3874: P 72:92(20) ack 114 win 5808
17:20:37.752992 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 114:162(48) ack 92 win 6
17:20:37.753425 IP 85.181.254.119.1116 > 213.204.193.2.3874: P 92:106(14) ack 162 win 5808
17:20:37.792991 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 162:199(37) ack 106 win 6
17:20:37.793934 IP 85.181.254.119.1116 > 213.204.193.2.3874: P 106:156(50) ack 199 win 5808
17:20:37.837016 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 199:289(90) ack 156 win 6
17:20:37.837544 IP 85.181.254.119.1116 > 213.204.193.2.3874: P 156:175(19) ack 289 win 5808
17:20:37.895016 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 289:331(42) ack 175 win 6
17:20:37.926845 IP 85.181.254.119.1116 > 213.204.193.2.3874: . ack 331 win 5808
17:20:37.935120 IP 213.204.193.2.3874 > 85.181.254.119.1116: P 331:684(353) ack 175 win 6
17:20:37.935402 IP 85.181.254.119.1116 > 213.204.193.2.3874: . ack 684 win 6432
17:20:37.937618 IP 85.181.254.119.1116 > 213.204.193.2.3874: P 175:191(16) ack 684 win 6432
17:20:37.937952 IP 85.181.254.119.1116 > 213.204.193.2.3874: F 191:191(0) ack 684 win 6432
17:20:37.976997 IP 213.204.193.2.3874 > 85.181.254.119.1116: F 684:684(0) ack 192 win 6
17:20:37.977223 IP 85.181.254.119.1116 > 213.204.193.2.3874: . ack 685 win 6432
17:20:38.438976 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:20:38.439833 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:20:40.997107 IP 85.181.254.119.1082 > 91.184.37.98.3740: UDP, length 87
17:20:44.290595 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:200:244::2 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:20:45.287091 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:200:244::2 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 1, length 64
17:20:46.287095 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:200:244::2 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 2, length 64
No responses to IPv6 traffic either, though.
Some moments later, and after another aiccu restart, it suddenly starts to work again:
root@felicitas:~# tcpdump -ni ppp0 host 91.184.37.98
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:21:28.477539 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 0, length 64
17:21:28.511274 IP 91.184.37.98 > 85.181.254.119: IP6 2001:838:1:1:210:dcff:fe20:7c7c > 2a01:198:20f:1000::1: ICMP6, echo reply, seq 0, length 64
17:21:29.477019 IP 85.181.254.119 > 91.184.37.98: IP6 2a01:198:20f:1000::1 > 2001:838:1:1:210:dcff:fe20:7c7c: ICMP6, echo request, seq 1, length 64
17:21:29.511276 IP 91.184.37.98 > 85.181.254.119: IP6 2001:838:1:1:210:dcff:fe20:7c7c > 2a01:198:20f:1000::1: ICMP6, echo reply, seq 1, length 64
I am aware that from 17:12 to 17:21 there are only 9 minutes of downtime (external monitoring suggests 17:09 to 17:21 of the tunnel not working, not much difference).
I'm posting this because this is the second time that I noticed this exact symptom (no responses to IPv6, then IPv4 ICMP unreachable replies, then works again) within the last couple of days, therefore I thought I'd post it anyway. Maybe it helps.
There were no configuration changes on my side, only restarts of aiccu. The only settings I changed were from verbose=false, daemonize=true (default setup) to verbose=true, daemonize=false for testing. Somehow this coincided again with the time that the tunnel started working again, but I don't think it should have caused it..?
IPv4 traceroute to dedus01:
traceroute to dedus01.sixxs.net (91.184.37.98), 30 hops max, 38 byte packets
1 lo1.br50.dus.de.hansenet.net (213.191.64.29) 21.010 ms 21.429 ms 21.618 ms
2 ge-1-1-0-252.prju02.dus.de.hansenet.net (62.109.68.130) 21.574 ms 21.503 ms 21.624 ms
3 opencarrier.dus.ecix.net (194.146.118.29) 21.592 ms 21.599 ms 21.040 ms
4 oc-dus.speedpartner.de (194.54.95.14) 22.178 ms 20.859 ms 21.015 ms
5 dedus01.sixxs.net (91.184.37.98) 22.130 ms 22.869 ms 21.017 ms
Regards,
Milan Holzpfel
State change: user
The state of this ticket has been changed to user
dedus01 does not accept protocol 41 (IPv6 in IPv4) packets during short intervals (10 minutes)
17:12:58.650600 IP 91.184.37.98 > 85.181.254.119: ICMP 91.184.37.98 protocol 41 unreachable, length 132
You have an OpenWRT based host, mips, thus most likely a realish WRT. You do realize that these are very bad in keeping time, and that when the PoP does not receive a valid heartbeat packet it deconfigures the tunnel?
Killing aiccu and starting it once again doesn't help either:
What would it resolve?
I am aware that from 17:12 to 17:21 there are only 9 minutes of downtime (external monitoring suggests 17:09 to 17:21 of the tunnel not working, not much difference).
What kind of "monitoring" are you performing?
There were no configuration changes on my side, only restarts of aiccu. The only settings I changed were from verbose=false, daemonize=true (default setup) to verbose=true, daemonize=false for testing. Somehow this coincided again with the time that the tunnel started working again, but I don't think it should have caused it..?
No heartbeat packets == no tunnel.
dedus01 does not accept protocol 41 (IPv6 in IPv4) packets during short intervals (10 minutes)
Shadow Hawkins on Saturday, 23 May 2009 01:09:47
I just compared the system time on the WRT box with a freshly NTP sync'ed system time and with a radio wall clock and the offset was < 5 seconds. I think the WRT box is NTP-synced every time it has to re-establish its PPP connection, which is every 24 hours. I will keep an eye on the system time though if the problem should occur again.
I didn't know what kind of problem I was trying to solve. I suspected a POP problem, so I restarted aiccu. (Of course I forgot that the maximum time offset is ~ 120 seconds (?) and didn't check the system time...)
As the tunnel came back to live without a time sync of the WRT box, I'm led to believe time problems haven't been the issue today.
The monitoring are plain ICMPv6 Pings from another SixXS based tunnel. I just wanted state that the problem really only occured during a short timeframe (SixXS ping stats actually would have been better).
I will try to look for heartbeats and system time if the problem comes back and report the results. Thanks for your suggestions.
|
![[ch]](/s/countries/ch.gif)
on Friday, 22 May 2009 20:36:56
Posting is only allowed when you are