|
Ticket ID: SIXXS #5077773 Ticket Status: User PoP: gblon03 - Gyron Internet LTD - Limited UK Company (London)
Tunnel Downtime but all looks ok
![[gb]](/s/countries/gb.gif) Shadow Hawkins on Friday, 01 July 2011 04:19:08
JPH5-SIXXS
T71257
I am getting Tunnel Downtime emails, but it seems like only the POP cannot ping the endpoint.
I can ping 2a00:14f0:e000:56::2 and 2a00:14f0:e000:56::1 from:
AICCU tunnel with a different POP
VPS with ip6
another static tunnel with the same pop.
Also, the host running the tunnel is able to ping out to the above list, as well as ipv6.google.com.
Looking at the history there are brief drops from the 100% loss, but this is a static ip4 host that is not having any downtime.
Please help, it's killing my ISK ;)
here is an ip4 trace from the endpoint
traceroute to 212.113.147.150 (212.113.147.150), 30 hops max, 60 byte packets
1 gateway (x.x.x.x) 0.423 ms 0.729 ms 0.722 ms
2 no-dns-yet-88-98-35-222.zen.net.uk (88.98.35.222) 3.592 ms 3.967 ms 4.405 ms
3 88-98-136-205.ll.zen.net.uk (88.98.136.205) 4.785 ms 4.993 ms 5.827 ms
4 ge-2-1-0-11.cr1.wh-man.zen.net.uk (62.3.83.65) 6.217 ms 6.233 ms 6.669 ms
5 ge-3-0-0-0.cr2.th-lon.zen.net.uk (62.3.80.45) 12.809 ms 13.194 ms 13.205 ms
6 xe-0-0-3.border-1.sov.lon.uk.as29017.net (195.66.224.141) 13.590 ms 13.338 ms 13.459 ms
7 ae4.core-1.lhc.lon.uk.as29017.net (89.145.125.17) 13.450 ms 24.069 ms 24.381 ms
8 gblon03.sixxs.net (212.113.147.150) 11.378 ms 11.298 ms 11.635 ms
Tunnel Downtime but all looks ok
here is an ip4 trace from the endpoint
You obviously did not read the FAQ at all, as then you would know that the ping check is done over IPv6 and that is thus what needs to work. This shows that you can nicely at least reach the PoP over IPv4, but does not show working IPv6 at all.
Please actually read the FAQ, thanks.
Tunnel Downtime but all looks ok
Shadow Hawkins on Friday, 01 July 2011 16:18:42
I did read the faq, just missed off an ip6 trace, it was 4am!
traceroute to 2a00:14f0:e000:56::2 (2a00:14f0:e000:56::2), 30 hops max, 80 byte packets
1 gw-1131.lon-02.gb.sixxs.net (2a01:348:6:46a::1) 45.608 ms 45.765 ms 47.255 ms
2 ge-0-0-5-20.cs0.thw.uk.goscomb.net (2a01:348:0:4:0:3:0:1) 50.761 ms 50.854 ms 50.924 ms
3 xe-0-0-0.rt0.the.uk.goscomb.net (2a01:348::27:0:1) 50.082 ms 50.335 ms 50.403 ms
4 lonap.he.net (2001:7f8:17::1b1b:1) 56.997 ms 57.109 ms 57.186 ms
5 xe-0-0-3.border-1.sov.lon.uk.as29017.net (2001:7f8:4::7159:1) 51.026 ms 52.994 ms 53.226 ms
6 ae4.core-1.lhc.lon.uk.as29017.net (2a00:14f0:0:1::5) 53.307 ms 78.249 ms 26.709 ms
7 gblon03.sixxs.net (2a00:14f0:1:2::5) 20.428 ms 20.678 ms 20.764 ms
Tunnel Downtime but all looks ok
Shadow Hawkins on Friday, 01 July 2011 16:29:42
more generally, all my other ipv6 hosts can ping this one, but the POP cannot
Tunnel Downtime but all looks ok
Try a traceroute6 to the PoP endpoint of the tunnel, not some other host on the Internet which is not involved in the ping test. The FAQ states this.
Tunnel Downtime but all looks ok
Shadow Hawkins on Sunday, 03 July 2011 09:04:05
Thats what the above is. I don't understant why the only thing that doesn't work is the final hop on a trace, as pings and traffic flow freely.
I've accepted defeat and changed the tunnel to ayiya for now, but even that is not working fully:
root@rico:~# ssh jon@2a00:14f0:e000:56::2
jon@2a00:14f0:e000:56::2's password: (can log in fine)
root@rico:~# ping6 2a00:14f0:e000:56::2
PING 2a00:14f0:e000:56::2(2a00:14f0:e000:56::2) 56 data bytes
64 bytes from 2a00:14f0:e000:56::2: icmp_seq=1 ttl=52 time=33.4 ms
^C
--- 2a00:14f0:e000:56::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.423/33.423/33.423/0.000 ms
root@rico:~# traceroute6 2a00:14f0:e000:56::2
traceroute to 2a00:14f0:e000:56::2 (2a00:14f0:e000:56::2), 30 hops max, 80 byte packets
1 gw-1131.lon-02.gb.sixxs.net (2a01:348:6:46a::1) 20.749 ms 21.215 ms 21.371 ms
2 ge-0-0-5-20.cs0.thw.uk.goscomb.net (2a01:348:0:4:0:3:0:1) 22.903 ms 23.395 ms 23.204 ms
3 xe-0-0-0.rt0.the.uk.goscomb.net (2a01:348::27:0:1) 21.976 ms 24.606 ms 25.136 ms
4 lonap.he.net (2001:7f8:17::1b1b:1) 25.291 ms 25.439 ms 25.577 ms
5 xe-0-0-3.border-1.sov.lon.uk.as29017.net (2001:7f8:4::7159:1) 26.425 ms 26.563 ms 26.705 ms
6 ae4.core-1.lhc.lon.uk.as29017.net (2a00:14f0:0:1::5) 26.847 ms 22.305 ms 21.660 ms
7 gblon03.sixxs.net (2a00:14f0:1:2::5) 22.225 ms 22.390 ms 22.548 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 *^C
root@rico:~# traceroute6 2a00:14f0:e000:56::1
traceroute to 2a00:14f0:e000:56::1 (2a00:14f0:e000:56::1), 30 hops max, 80 byte packets
1 gw-1131.lon-02.gb.sixxs.net (2a01:348:6:46a::1) 22.178 ms 22.700 ms 22.853 ms
2 ge-0-0-5-20.cs0.thw.uk.goscomb.net (2a01:348:0:4:0:3:0:1) 24.415 ms 24.566 ms 24.702 ms
3 xe-0-0-0.rt0.the.uk.goscomb.net (2a01:348::27:0:1) 22.944 ms 23.079 ms 23.216 ms
4 lonap.he.net (2001:7f8:17::1b1b:1) 28.182 ms 28.683 ms 28.828 ms
5 xe-0-0-3.border-1.sov.lon.uk.as29017.net (2001:7f8:4::7159:1) 43.793 ms 43.935 ms 44.060 ms
6 ae4.core-1.lhc.lon.uk.as29017.net (2a00:14f0:0:1::5) 40.014 ms 20.288 ms 21.070 ms
7 gw-87.lon-03.gb.sixxs.net (2a00:14f0:e000:56::1) 22.173 ms 21.992 ms 22.295 ms
I suppose the lesson here is to stick to ayiya unless I know the upstream ISP is going to help me.
Any chance of an ISK boost please? this mistake has been costly and will set me back a long time, I've been very busy and have taken time away from my family for this.
Tunnel Downtime but all looks ok
Thats what the above is.
It is not. Look at it:
traceroute to 2a00:14f0:e000:56::2 (2a00:14f0:e000:56::2), 30 hops max, 80 byte packets 1 gw-1131.lon-02.gb.sixxs.net (2a01:348:6:46a::1) 45.608 ms 45.765 ms 47.255 ms
That is our SECOND london PoP (gblon02)
Then some hops to the other ISP
7 gblon03.sixxs.net (2a00:14f0:1:2::5) 20.428 ms 20.678 ms 20.764 ms
And our THIRD London PoP (gblon03)
You have four tunnels, two of which connected to gblon02, two to gblon03. T71257 is connected to gblon03, thus as you are showing gblon02 in the traceroute's first hop, the packets are not being sent over the correct tunnel and if that is the route that you reply to ICMPv6 pings from the PoP over then the PoP will not accept that. But actually, the source address will have to be wrong too as our PoPs do source address checking.
As such, that traceroute must have been from another tunnel.
I don't understant why the only thing that doesn't work is the final hop on a trace, as pings and traffic flow freely.
You are not talking about T71257 that this ticket is about.
The robot, as usual, is correct in sending you downtime messages, which now you won't get as you changed the type to AYIYA. No, you will not get any kind of ISK because you are making a mess.
Tunnel Downtime but all looks ok
Shadow Hawkins on Sunday, 03 July 2011 18:55:43
Hi,
Those are traces _to_ the problem tunnel, they happen to come from gblon02 because that's the pop I'm using from here. The fa
I'm sorry to be making a mess, I'll admit that static tunnels have cause me some problems, but this is about learning isn't it? My records from before trying statics was good I think.
for clarity here is the same thing from a VPS
ssh root@2a00:14f0:e000:56::2
The authenticity of host '2a00:14f0:e000:56::2 (2a00:14f0:e000:56::2)' can't be established.
RSA key fingerprint is e8:b3:fd:c9:a2:36:b3:0e:f3:a7:09:f9:3e:f5:62:da.
Are you sure you want to continue connecting (yes/no)?
root@synergy0:~# ping6 2a00:14f0:e000:56::2
PING 2a00:14f0:e000:56::2(2a00:14f0:e000:56::2) 56 data bytes
64 bytes from 2a00:14f0:e000:56::2: icmp_seq=1 ttl=54 time=19.4 ms
^C
--- 2a00:14f0:e000:56::2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 19.446/19.446/19.446/0.000 ms
root@synergy0:~# traceroute6 2a00:14f0:e000:56::2
traceroute to 2a00:14f0:e000:56::2 (2a00:14f0:e000:56::2), 30 hops max, 80 byte packets
1 2001:41c8:1:5895::1 (2001:41c8:1:5895::1) 0.642 ms 0.600 ms 0.583 ms
2 2001:41c8:0:858::2 (2001:41c8:0:858::2) 0.863 ms 0.965 ms 0.995 ms
3 2001:41c8:0:82::2 (2001:41c8:0:82::2) 7.330 ms 7.438 ms 7.432 ms
4 ae1.border-1.thn.lon.uk.as29017.net (2001:7f8:17::7159:2) 7.792 ms 7.788 ms 7.778 ms
5 ae4.core-2.lhc.lon.uk.as29017.net (2a00:14f0:0:1::16) 7.766 ms 7.754 ms 7.998 ms
6 gblon03.sixxs.net (2a00:14f0:1:2::5) 7.803 ms 7.787 ms 7.762 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 *^C
root@synergy0:~# traceroute6 2a00:14f0:e000:56::1
traceroute to 2a00:14f0:e000:56::1 (2a00:14f0:e000:56::1), 30 hops max, 80 byte packets
1 2001:41c8:1:5895::1 (2001:41c8:1:5895::1) 0.559 ms 0.530 ms 0.518 ms
2 2001:41c8:0:858::2 (2001:41c8:0:858::2) 0.962 ms 1.019 ms 1.187 ms
3 2001:41c8:0:82::2 (2001:41c8:0:82::2) 7.144 ms 7.201 ms 7.313 ms
4 ae1.border-1.thn.lon.uk.as29017.net (2001:7f8:17::7159:2) 7.530 ms 7.745 ms 7.744 ms
5 ae4.core-2.lhc.lon.uk.as29017.net (2a00:14f0:0:1::16) 7.735 ms 7.730 ms 7.721 ms
6 gw-87.lon-03.gb.sixxs.net (2a00:14f0:e000:56::1) 7.702 ms 7.651 ms 7.627 ms
root@synergy0:~# traceroute 212.113.147.150
traceroute to 212.113.147.150 (212.113.147.150), 30 hops max, 60 byte packets
1 89-16-173-1.no-reverse-dns-set.bytemark.co.uk (89.16.173.1) 0.430 ms 0.401 ms 0.392 ms
2 89-16-188-2.no-reverse-dns-set.bytemark.co.uk (89.16.188.2) 0.614 ms 0.675 ms 0.742 ms
3 gi5-2.cr01.sov.bytemark.co.uk (89.16.160.38) 7.065 ms 7.070 ms 7.197 ms
4 xe-0-0-3.border-1.thn.lon.uk.as29017.net (195.66.226.141) 7.116 ms 7.113 ms 7.141 ms
5 ae4.core-2.lhc.lon.uk.as29017.net (89.145.125.21) 7.143 ms 7.172 ms 7.166 ms
6 gblon03.sixxs.net (212.113.147.150) 7.160 ms 7.203 ms 7.198 ms
Tunnel Downtime but all looks ok
Shadow Hawkins on Sunday, 03 July 2011 19:03:20
To continue
The fa... The faq asks for traces _to_ the address, everthing on the OS is a copy of a working tunnel (apart from addresses of course) so other points did not seem worth commenting on initially.
The initial problem is not relevant anymore, but I'd still be gratefull for a credit boost, I'd much prefer to keep all my tunnels with sixxs
Regards
Jonathan
Tunnel Downtime but all looks ok
for clarity here is the same thing from a VPS
The Ping check is between your endpoint (<tunnel>::2) and the PoP (<tunnel>::1), nothing else.
If the PoP can't ping your endpoint, or your endpoint does not send the reply over the tunnel, then according to the test it does not respond.
See the FAQ for further details. If you are unable to follow those instructions, then we really can't help you.
Tunnel Downtime but all looks ok
Shadow Hawkins on Monday, 04 July 2011 00:31:39The Ping check is between your endpoint (<tunnel>::2) and the PoP (<tunnel>::1), nothing else.
what I dont understand, and what does not seem to be mentioned in the faq is why I can ping the endpoint from anywhere, but the pop cannot.
but anyway, thanks for you time, its not an issue anymore.
Tunnel Downtime but all looks ok
Take a small guess why I am asking you to do a traceroute from your endpoint to the PoP.
For the rest, see the FAQ which also asks for the same thing.
Tunnel Downtime but all looks ok
Shadow Hawkins on Tuesday, 05 July 2011 16:22:39
If I turn it back to a static tunnel and work out what is wrong will you give me some credits? ;)
Tunnel Downtime but all looks ok
Please note that the forum is at the location of the forum. The ticket system is for reporting operation issues.
As for credits, see FAQ: What about credits and ISK?
State change: user
The state of this ticket has been changed to user
|
![[ch]](/s/countries/ch.gif)
on Friday, 01 July 2011 09:29:29
Posting is only allowed when you are