• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

tserv1.fra1.he.net down?

Started by falkstern, September 03, 2012, 07:54:27 AM

Previous topic - Next topic

falkstern

Hi all,

seems my v6 tunnel is no longer working.

tserv1 sends me an ICMP port unreachable.

Provider is Deutsche Telekom, OS is Linux. This tunnel was working before.

# tcpdump -n -i ppp0 host 216.66.80.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
16:51:49.297381 IP 216.66.80.30 > 93.200.118.57: ICMP 216.66.80.30 protocol 41 port 0 unreachable, length 132

cholzhauer


kasperd

Quote from: cholzhauer on September 03, 2012, 07:57:03 AMMay want to email ipv6@he.net
I did that 7½ hours ago.

Quote from: falkstern on September 03, 2012, 07:54:27 AM
# tcpdump -n -i ppp0 host 216.66.80.30
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
16:51:49.297381 IP 216.66.80.30 > 93.200.118.57: ICMP 216.66.80.30 protocol 41 port 0 unreachable, length 132

I did not get any ICMP errors from the tunnel server at the time. But AFAIK during a tunnel server restart all users will get those ICMP errors. And at the moment the connection appears to be working again:
traceroute to he.net (2001:470:0:76::2), 30 hops max, 80 byte packets
1  2a01:d0:839a:babe:d19e:266e:d66c:545c  10.188 ms  16.549 ms  16.574 ms
2  2001:470:1f0a:1e45::1  77.088 ms  77.127 ms  77.122 ms
3  2001:470:0:69::1  97.573 ms  76.916 ms  76.945 ms
4  2001:470:0:1d2::1  79.194 ms  79.237 ms  79.247 ms
5  2001:470:0:128::1  162.615 ms  142.240 ms  142.254 ms
6  2001:470:0:10e::1  206.843 ms  206.881 ms  206.874 ms
7  2001:470:0:18d::1  206.668 ms  204.410 ms  204.430 ms
8  2001:470:0:2d::1  204.571 ms  204.603 ms  204.612 ms
9  2001:470:0:76::2  204.207 ms  196.030 ms  196.040 ms

kasperd

#3
Quote from: kasperd on September 03, 2012, 08:54:06 AMAnd at the moment the connection appears to be working again
This is however a reoccurring problem. I only keep using tserv1.fra because it gives me opportunity to test how my gateway deals with a failing tunnel server, and automatically finds alternatives. I think the other tunnel servers are much more reliable.