Linksys E3000 Running Tomato Shibby build 108 No IPv6 Internet Connection

[RLH1985]

I have a tunnel from HE and it worked just fine for me for quite some time however, I didn't have home internet service for a few months after I moved and after I got hooked up with my new ISP, my tunnel isn't working at all.  I'm a bit rusty on this setup since I only did it once and I'd like to make sure that I'm doing it right even though I never removed the ipv6 tunnel settings from my router while it was disconnected from the internet.

The attached image is my Basic->IPv6 router settings.

At this point I'm quite confused since these settings used to work just fine but they aren't working now.  So, thank you for any assistance you can provide.

EDIT: I thought that I should add a bit more detail on exactly what I'm experiencing.  I can use IPv6 to ping my router however, I cannot ping any IPv6 addresses beyond my router including the IPv6 address of the HE end of my tunnel.  Also, using telnet since the GUI doesn't like IPv6 addresses, I've tried pinging various IPv6 addresses (including my tunnels server end and ipv6.google.com) from the router itself and also got nothing.

[kasperd]

The tunnel server need to know the IPv4 address of your router. Having moved to another ISP, that address must have changed. If your router isn't configured to update this on tunnelbroker.net automatically, you will need to do it manually through the website. It is possible that your tunnel was deleted, because it was inactive for too long. Once you log in on that page, you will find out if your tunnel is still there.

[RLH1985]

The tunnel server need to know the IPv4 address of your router. Having moved to another ISP, that address must have changed. If your router isn't configured to update this on tunnelbroker.net automatically, you will need to do it manually through the website. It is possible that your tunnel was deleted, because it was inactive for too long. Once you log in on that page, you will find out if your tunnel is still there.

I've checked and my tunnel is still active. Also, I have DDNS set up to automatically update HE with my new IP address once a day.  Upon checking it, the IP that HE has does match my current public facing IPv4 address.  I was going to post a picture of my DDNS settings screen as well but, since it says 'update successful' and HE has the correct IPv4 address for my router I thought that it would be a bit superfluous.  Thanks for the suggestion though.

[kasperd]

I don't see an obvious explanation for the problem. Could you try temporarily changing the router configuration to use server address 80.167.222.169 instead and then try to ping 2001:470:28:940:793b:aa03:518b:23c8. That IPv4 address is not a real tunnel server, but it will be able to reach that one IPv6 address.

[RLH1985]

I don't see an obvious explanation for the problem. Could you try temporarily changing the router configuration to use server address 80.167.222.169 instead and then try to ping 2001:470:28:940:793b:aa03:518b:23c8. That IPv4 address is not a real tunnel server, but it will be able to reach that one IPv6 address.

I don't get anything with that either.  I get a "Request timed out." message on my Windows 8 Pro x64 desktop and I get this:

Code Select Expand

root@Yggdrasil:/tmp/home/root# ping -6 -c 5 2001:470:28:940:793b:aa03:518b:23c8
PING 2001:470:28:940:793b:aa03:518b:23c8 (2001:470:28:940:793b:aa03:518b:23c8): 56 data bytes

--- 2001:470:28:940:793b:aa03:518b:23c8 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
when I telnet to my router and try to ping that address.

Could my ISP be blocking tunneling?  Is that even possible without deep packet inspection?

[kasperd]

Could my ISP be blocking tunneling?

They could, but I would not consider doing so deliberately to be acceptable. A more likely explanation would be that the packets are going through a NAT, which cannot handle protocol 41.

Is that even possible without deep packet inspection?

Yes, the protocol number is right there in the IPv4 header. It is easy to block specific protocol numbers. Blocking specific port numbers (on either IP version) will in fact require deeper inspection than blocking tunnelling.

You should try a few things. First of all find out what the external IP address of your router is. You want to know, if there is any NAT involved. Secondly compare traceroute using different protocols. For example try traceroute 209.51.181.2 and traceroute -P 41 209.51.181.2

[RLH1985]

Could my ISP be blocking tunneling?

They could, but I would not consider doing so deliberately to be acceptable. A more likely explanation would be that the packets are going through a NAT, which cannot handle protocol 41.

Is that even possible without deep packet inspection?

Yes, the protocol number is right there in the IPv4 header. It is easy to block specific protocol numbers. Blocking specific port numbers (on either IP version) will in fact require deeper inspection than blocking tunnelling.

You should try a few things. First of all find out what the external IP address of your router is. You want to know, if there is any NAT involved. Secondly compare traceroute using different protocols. For example try traceroute 209.51.181.2 and traceroute -P 41 209.51.181.2

*sigh* it looks like the second problem is the case.  Both a standard traceroute and a type of service specific traceroute reach the tunnel but my router is behind two different NAT's.  My router's external IP address is 192.168.6.14, the modem in my place has an IP address of 192.168.6.1, and it connects to a system with an IP of 172.18.254.132.  Only the next jump has a publicly routable IP address and that is the one the internet sees as mine.
One would hope that an ISP who is in the situation of having to double NAT their customers would try to build out IPv6 quickly but apparently that is either not the case or their upstream provider is dragging their feet as well.

Just in case I managed to foul something up, here's the results of both traceroute's:

Code Select Expand

Tomato v1.28.0000 MIPSR2-108 K26 USB Big-VPN
root@Yggdrasil:/tmp/home/root# traceroute 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 38 byte packets
1  192.168.6.1 (192.168.6.1)  0.727 ms  0.659 ms  0.685 ms
2  172.18.254.132 (172.18.254.132)  18.225 ms  18.994 ms  35.566 ms
3  vqwireless.com (71.89.156.145)  26.968 ms  26.640 ms  26.836 ms
4  dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184)  18.228 ms  dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180)  22.496 ms  dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184)  23.053 ms
5  *  *  crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187)  18.706 ms
6  bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58)  26.559 ms  25.170 ms  16.223 ms
7  bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54)  19.477 ms  33.030 ms  35.183 ms
8  bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99)  36.424 ms  34.662 ms  33.981 ms
9  prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9)  39.308 ms  43.636 ms  31.413 ms
10  v201.core1.chi1.he.net (216.66.73.241)  35.162 ms  19.786 ms  38.216 ms
11  tserv1.chi1.he.net (209.51.181.2)  28.010 ms  36.156 ms  34.665 ms

Code Select Expand

root@Yggdrasil:/tmp/home/root# traceroute -t 41 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 38 byte packets
1  192.168.6.1 (192.168.6.1)  1.003 ms  0.733 ms  0.698 ms
2  172.18.254.132 (172.18.254.132)  18.492 ms  37.928 ms  38.839 ms
3  vqwireless.com (71.89.156.145)  43.609 ms  35.734 ms  37.151 ms
4  dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180)  36.245 ms  dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184)  44.485 ms  dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180)  36.455 ms
5  crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135)  46.043 ms  crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187)  30.222 ms  crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135)  35.708 ms
6  bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58)  16.166 ms  20.351 ms  16.620 ms
7  bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54)  25.877 ms  41.196 ms  27.994 ms
8  bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99)  31.304 ms  34.590 ms  35.177 ms
9  prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9)  31.066 ms  45.537 ms  34.771 ms
10  v201.core1.chi1.he.net (216.66.73.241)  51.062 ms  64.767 ms  55.206 ms
11  tserv1.chi1.he.net (209.51.181.2)  56.123 ms  34.208 ms  42.317 ms

[kasperd]

Both a standard traceroute and a type of service specific traceroute reach the tunnel

This is not consistent with the previous results. When you tried to ping my IP, the packets did not reach me. That means either some middelbox is mangling the packets in some way that still leave them recognizable for traceroute, but not valid ICMPv6 packets when decapsulated, or your traceroute wasn't actually testing protocol 41 packets.

but my router is behind two different NAT's.  My router's external IP address is 192.168.6.14, the modem in my place has an IP address of 192.168.6.1, and it connects to a system with an IP of 172.18.254.132.

This doesn't tell us much about the number of layers of NAT. Of course we can deduce that your router is doing NAT, and that there is another layer of NAT, since the external IP of your router is not a global address. That means at least two layers of NAT.

There is no particular reason to think, there is more than two layers of NAT involved. Also there is no way to know from the traceroute alone, where the next layer of NAT is.

The ICMP time exceeded messages from the intermediate routers, which is what traceroute is displaying, could originate from local or global addresses regardless of which side of the NAT they are on.

Only the next jump has a publicly routable IP address and that is the one the internet sees as mine.

Hang on. This is an unusual configuration. Usually routers have different IP addresses on their interfaces, and the IP address your traceroute would display for the NAT is for the interface facing towards you. The IP the outside world would see for you, would be the IP address of the interface facing away from you.

If 71.89.156.145 really is the external IP address of the CGN, that could still be explained in a few ways. It is possible the NAT has been configured with the same IP address on all interfaces. It is also possible it is simply using a pool of IP addresses, which include all of those assigned to each of its interfaces. It is also possible the NAT has only one interface and packets are routed back and forth over the same interface, but in that case the router that interface is connected to would need unusual routing rules. It is also possible the NAT is NATing the ICMP time exceeded errors sent to you, though I can't imagine what sort of NAT configuration would do that.

One would hope that an ISP who is in the situation of having to double NAT their customers would try to build out IPv6 quickly

They definitely should. Customers should not accept carrier-grade-NAT unless they are getting native IPv6 as well. If I had experienced that, I would have called them and told them I am not getting the service, I signed up for.

traceroute -t 41 209.51.181.2

Which traceroute version is that? On the traceroute version I have on this machine, the -t option sets the TOS, not the protocol number.

[RLH1985]

Only the next jump has a publicly routable IP address and that is the one the internet sees as mine.

Hang on. This is an unusual configuration. Usually routers have different IP addresses on their interfaces, and the IP address your traceroute would display for the NAT is for the interface facing towards you. The IP the outside world would see for you, would be the IP address of the interface facing away from you.

If 71.89.156.145 really is the external IP address of the CGN, that could still be explained in a few ways. It is possible the NAT has been configured with the same IP address on all interfaces. It is also possible it is simply using a pool of IP addresses, which include all of those assigned to each of its interfaces. It is also possible the NAT has only one interface and packets are routed back and forth over the same interface, but in that case the router that interface is connected to would need unusual routing rules. It is also possible the NAT is NATing the ICMP time exceeded errors sent to you, though I can't imagine what sort of NAT configuration would do that.

You're right here, it looks like that address is simply one of a pool of addresses.  The IP that I'm seen at has been 71.89.156.145 in the past but right now it's 71.89.156.147.  (I checked to make sure that my tunnel was updated with the change but it seems as though the DDNS service on my router already updated it.)

traceroute -t 41 209.51.181.2

Which traceroute version is that? On the traceroute version I have on this machine, the -t option sets the TOS, not the protocol number.
[/quote]

Here I seem to have made a mistake, it looks like the version of traceroute on my router doesn't support the -P switch.  It only seems to support -p which sets the port and I'm guessing that's also incorrect.  (I did however try it and the traceroute on port 41 worked just fine.)

So, I loaded up a Linux Live CD that I had around and tried the two traceroutes again.  Here are the results for the test without the protocol flag:

Code Select Expand

root@kali:~# traceroute 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1  Yggdrasil (192.168.2.1)  0.640 ms  0.523 ms  0.404 ms
2  192.168.6.1 (192.168.6.1)  1.683 ms  1.980 ms  2.049 ms
3  172.18.254.131 (172.18.254.131)  31.314 ms  31.135 ms  30.980 ms
4  vqwireless.com (71.89.156.145)  30.837 ms  30.686 ms  30.548 ms
5  dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180)  48.203 ms dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184)  48.635 ms dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180)  48.701 ms
6  crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135)  50.810 ms crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187)  63.904 ms crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135)  63.862 ms
7  bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58)  63.908 ms  64.648 ms  64.562 ms
8  bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54)  72.998 ms  62.933 ms  62.782 ms
9  bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99)  68.541 ms  68.712 ms  68.683 ms
10  prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9)  58.060 ms  58.053 ms  57.918 ms
11  v201.core1.chi1.he.net (216.66.73.241)  67.126 ms  67.241 ms  107.637 ms
12  tserv1.chi1.he.net (209.51.181.2)  99.313 ms  99.105 ms  95.353 ms
Here are the results with the protocol flag set.

Code Select Expand

root@kali:~# traceroute -P 41 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1  Yggdrasil (192.168.2.1)  0.551 ms  0.397 ms  0.345 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

It looks like the modem is killing my connection here.  I see the router but nothing past it when using protocol 41.  Is this something I can fix from here or am I going to have to contact my ISP?

[kasperd]

I did however try it and the traceroute on port 41 worked just fine.

Right, but protocol 41 and port 41 are two completely different and totally unrelated things.

It looks like the modem is killing my connection here.  I see the router but nothing past it when using protocol 41.

From this output you can only deduce that the packets are dropped by 192.168.2.1 or 192.168.6.1.

There are routers, which can NAT protocol 41 traffic out of the box. There are other routers where it requires an explicit forwarding configuration. And there are routers, which cannot NAT protocol 41 traffic at all.

You know your router supports operation as a tunnel endpoint using protocol 41. I can tell you that simultaneously being a protocol 41 tunnel endpoint and NATing protocol 41 traffic is tricky. I don't know if there is any router, which supports it. In addition it is a more straightforward implementation, if decrementing the TTL is done before any consideration of NATing of the traffic. Which means it would be likely that the router, which is not capable of forwarding the traffic would still show up in the traceroute.

Based on that my best guess is that your own router is dropping the protocol 41 packets in the traceroute you just posted. So the easiest way to test what your ISP does to protocol 41 traffic is to connect that computer directly to the modem without the router in between (spoofing the MAC of the modem, if necessary), and then running the same two traceroute commands again.

[RLH1985]

Based on that my best guess is that your own router is dropping the protocol 41 packets in the traceroute you just posted. So the easiest way to test what your ISP does to protocol 41 traffic is to connect that computer directly to the modem without the router in between (spoofing the MAC of the modem, if necessary), and then running the same two traceroute commands again.

Here are the results for the test without the protocol flag:

Code Select Expand

root@kali:~# traceroute 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1  192.168.6.1 (192.168.6.1)  4.617 ms  3.819 ms  3.740 ms
2  172.18.254.131 (172.18.254.131)  35.906 ms  38.575 ms  39.305 ms
3  vqwireless.com (71.89.156.145)  42.036 ms  44.871 ms  45.597 ms
4  dtr01dvsnmi-tge-0-1-0-1.dvsn.mi.charter.com (96.34.32.184)  87.743 ms  106.493 ms dtr01dvsnmi-tge-0-1-0-0.dvsn.mi.charter.com (96.34.32.180)  107.502 ms
5  crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187)  108.355 ms crr02sgnwmi-tge-0-7-0-7.sgnw.mi.charter.com (96.34.33.135)  108.284 ms crr02sgnwmi-tge-0-7-0-6.sgnw.mi.charter.com (96.34.32.187)  111.751 ms
6  bbr01sgnwmi-bue-2.sgnw.mi.charter.com (96.34.2.58)  112.533 ms  52.329 ms  57.907 ms
7  bbr01aldlmi-tge-0-1-0-6.aldl.mi.charter.com (96.34.0.54)  60.871 ms  28.838 ms  29.312 ms
8  bbr01chcgil-bue-4.chcg.il.charter.com (96.34.0.99)  43.694 ms  43.552 ms  44.208 ms
9  prr01chcgil-bue-2.chcg.il.charter.com (96.34.3.9)  40.186 ms  40.800 ms  41.368 ms
10  v201.core1.chi1.he.net (216.66.73.241)  64.044 ms  41.839 ms  35.311 ms
11  tserv1.chi1.he.net (209.51.181.2)  35.886 ms  36.505 ms  30.759 ms
Here are the results with the protocol flag set.

Code Select Expand

root@kali:~# traceroute -P 41 209.51.181.2
traceroute to 209.51.181.2 (209.51.181.2), 30 hops max, 60 byte packets
1  192.168.6.1 (192.168.6.1)  1.323 ms  1.020 ms  1.301 ms
2  172.18.254.131 (172.18.254.131)  15.164 ms  20.631 ms  19.416 ms
3  * * *
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

So, I guess my router was dropping the packets.  However, now they're being dropped by another device up the line.

[kasperd]

So, I guess my router was dropping the packets.

Yep. But that is not a problem, since you wanted the router to be a tunnel endpoint, so you didn't need it to forward the protocol 41 packets in the first place.

However, now they're being dropped by another device up the line.

This is what we expected to see. We needed these two traceroute outputs to confirm the guess.

This is a problem. You should contact the ISP and let them know, that you are not satisfied. There are three different ways the ISP could solve your problem.

• Give you native IPv6, such that you don't need a tunnel.
• Give you access to a tunnel server within their own network, such that the tunnel does not have to go through their carrier grade NAT. Either 6in4 or 6rd could work for this tunnel.
• Give you a public IPv4 address, such that you can setup a tunnel to HE.

If you live in an area with competition between ISPs, you should consider switching to a better ISP, if they don't fix the problem, when you call them. If you are unfortunate enough to live in an area with no competition, you may need to consider other options. You can look into other tunnel protocols, which can work through NAT devices.

Unfortunately the beta which HE did with another protocol was discontinued. So you'd have to use another tunnel provider. SixXS supposedly support the widest range of protocols. They also have an infamous bureaucracy, which means signups are randomly rejected. It is worth a try, you may get lucky.

You could also pay for a dual stack VPS somewhere and set up your own tunnel server with whatever protocol is suitable for you. If you do this, make sure you get a VPS with a routed IPv6 prefix (preferably /63 or shorter).

[RLH1985]

So, I guess my router was dropping the packets.

Yep. But that is not a problem, since you wanted the router to be a tunnel endpoint, so you didn't need it to forward the protocol 41 packets in the first place.

However, now they're being dropped by another device up the line.

This is what we expected to see. We needed these two traceroute outputs to confirm the guess.

This is a problem. You should contact the ISP and let them know, that you are not satisfied. There are three different ways the ISP could solve your problem.

• Give you native IPv6, such that you don't need a tunnel.
• Give you access to a tunnel server within their own network, such that the tunnel does not have to go through their carrier grade NAT. Either 6in4 or 6rd could work for this tunnel.
• Give you a public IPv4 address, such that you can setup a tunnel to HE.

If you live in an area with competition between ISPs, you should consider switching to a better ISP, if they don't fix the problem, when you call them. If you are unfortunate enough to live in an area with no competition, you may need to consider other options. You can look into other tunnel protocols, which can work through NAT devices.

Unfortunately the beta which HE did with another protocol was discontinued. So you'd have to use another tunnel provider. SixXS supposedly support the widest range of protocols. They also have an infamous bureaucracy, which means signups are randomly rejected. It is worth a try, you may get lucky.

You could also pay for a dual stack VPS somewhere and set up your own tunnel server with whatever protocol is suitable for you. If you do this, make sure you get a VPS with a routed IPv6 prefix (preferably /63 or shorter).

Thanks for your help, I'll try talking to my ISP and see if they can help me out a bit from their end.  If I can't get anything from there, unfortunately I'm under contract for a year, I'll try SixXS.  I actually still have a tunnel through them, though I disabled it when I moved to HE.  My main issue with them was that the setup was quite a bit more difficult than HE's.  I'm a bit more knowledgeable now than I was when I first tried setting that one up 18 months ago though so it may be worth it to try.

[kasperd]

unfortunately I'm under contract for a year

Is the contract binding, if they cannot deliver the service, you signed up for? If they called the product an Internet connection, I would say an IP address is part of the service you were promised, unless the conditions didn't clearly stated otherwise.

A reasonable minimum to expect today is either one public IPv4 address, or NATed IPv4 access plus a static routed IPv6 prefix.

Before you try to get out of the contract, you should of course ensure that you can get better service somewhere else. If you consider switching to another ISP, ask the new ISP about what addresses they will give you.

It might even be that your current ISP fixes the problem once you call them. Giving NATed access by default and a public address to anybody who ask for it would make sense for an ISP, as that would probably reduce their usage of IP addresses significantly. If they additionally give only one public address to those who ask for one, but multiple local addresses to those going through carrier grade NAT, then those who don't ask for a public address don't have to buy their own router.

I'll try SixXS.  I actually still have a tunnel through them, though I disabled it when I moved to HE.  My main issue with them was that the setup was quite a bit more difficult than HE's.

Supporting different protocols will of course add to the complexity. Though it could be setting up SixXS access is more complicated than it needed to be.

Please update this thread and let us know how it turns out, both with your ISP and with SixXS configuration, if you give it a try.

[kasperd]

The IP that I'm seen at has been 71.89.156.145 in the past but right now it's 71.89.156.147.

For the record, I did a traceroute to each of those IPs, and this is what I saw.

Code Select Expand

traceroute to 71.89.156.145 (71.89.156.145), 30 hops max, 60 byte packets
1  10.9.255.254  8.338 ms  8.348 ms  8.407 ms
2  212.10.10.1  8.459 ms  8.497 ms  12.154 ms
3  194.255.53.29  12.896 ms  13.315 ms  13.768 ms
4  * * 213.248.66.146  15.683 ms
5  213.248.66.145  15.450 ms  15.416 ms  15.411 ms
6  80.91.253.244  14.855 ms 80.91.254.222  10.816 ms 213.155.130.96  11.165 ms
7  80.91.254.89  96.838 ms 213.155.134.52  107.497 ms 213.248.64.22  97.596 ms
8  213.155.136.19  127.407 ms 80.91.249.110  126.429 ms 80.91.246.166  126.696 ms
9  62.115.14.42  133.588 ms  132.438 ms  132.122 ms
10  96.34.0.98  140.557 ms  140.514 ms  140.040 ms
11  96.34.2.11  137.133 ms  137.272 ms  134.050 ms
12  96.34.36.16  144.003 ms  134.582 ms  135.368 ms
13  96.34.34.9  141.022 ms  140.383 ms  134.445 ms
14  96.34.38.165  134.256 ms  138.718 ms  134.275 ms
15  96.34.33.134  130.251 ms  130.719 ms  131.677 ms
16  96.34.32.185  136.249 ms 96.34.32.181  131.499 ms *

Code Select Expand

traceroute to 71.89.156.147 (71.89.156.147), 30 hops max, 60 byte packets
1  10.9.255.254  7.836 ms  12.008 ms  12.600 ms
2  212.10.10.1  12.660 ms  12.759 ms  12.783 ms
3  194.255.53.29  12.935 ms  13.573 ms  14.112 ms
4  * * *
5  213.248.66.145  15.036 ms  15.485 ms  15.469 ms
6  213.155.130.96  15.433 ms  11.022 ms 213.155.135.182  10.534 ms
7  213.155.134.52  106.029 ms 80.91.254.89  95.195 ms 213.155.134.50  98.141 ms
8  80.91.249.110  126.350 ms 80.91.246.164  128.110 ms  127.092 ms
9  213.248.104.198  139.108 ms  137.691 ms 62.115.14.42  127.828 ms
10  96.34.0.98  131.669 ms  132.149 ms  140.643 ms
11  96.34.2.11  133.231 ms  132.057 ms  132.390 ms
12  96.34.32.26  144.327 ms  143.692 ms  142.343 ms
13  96.34.32.99  129.364 ms  139.045 ms  134.630 ms
14  96.34.32.55  140.475 ms  135.006 ms  146.366 ms
15  96.34.32.186  134.191 ms  135.972 ms  135.143 ms
16  96.34.32.181  134.722 ms 96.34.32.185  162.567 ms  155.093 ms
17  71.89.156.147  134.538 ms  135.427 ms  137.000 msOne could try to figure out a bit more about the network from this. But whatever we make from these, it won't change your situation.