IPv6 routing problems today?

Started by Rachel, Jun 21, 2013, 11:13:01

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Rachel

Possibly as a hangover from yesterday; I'm finding routing to *some* IPv6 hosts isn't working, or is very very slow to establish. Others are fine. IPv4 seems fine. Also the same remote IPv6 hosts can be reached easily from an IPv6-enabled host outside my IDNet connection.

So, are there known problems with IPv6 routing through idnet right now?

Specifically, ipv6.google.com is fine, gb.archive.ubuntu.com and others are not

Steve

I guess there are some issues with IPv6 routing, the latter part of this thread indicates all maybe not well.

http://www.idnetters.co.uk/forums/index.php/topic,30912.0.html

I've not tried myself as I don't use it at present due to the lack of a IPv6 firewall on my router.
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

Bill

Both the sites you mention are fine for me (OS X 10.8), though I can't tell whether the Ubuntu one is connecting via v4 or v6. Both traceroute6 and ping6 to it are fine.

Have you tried a disconnect/re-connect?
Bill
BQMs-  IPv4  IPv6

Rachel

Quote from: Bill on Jun 21, 2013, 11:25:34
Both the sites you mention are fine for me (OS X 10.8), though I can't tell whether the Ubuntu one is connecting via v4 or v6. Both traceroute6 and ping6 to it are fine.

Have you tried a disconnect/re-connect?

I have tried a disconnect/reconnect, yes. It made no difference at all. OSX does indeed failover more aggressively than Linux (which I'm on at the moment, having troubles running software update because of this) and found hints to alter precedence settings in /etc/gai.conf seem not to actually make a difference to linux behaviour either.

However, ping6, traceroute6 should be explicit, and i'm finding the same behaviour on OSX and Linux from here, so I guess it's only affecting some, but certainly doesn't appear to be OS-specific.

Is also affecting my own dedicated server at luna.strangenoises.org hosted at hetzner.de - as in, I can't reach it from here via ipv6, only ipv4; but *from* there I have no trouble connecting to ipv6 to anywhere else that has it. But that's being quite disruptive too.

Trying to ping6 back from there to my home network I get (in case it helps as the From address looks likely to be in idnet's network):

rachel@luna:~$ ping6 twilight.strangenoises.org
PING twilight.strangenoises.org(2a02:390:6efd:0:4a5b:39ff:fe7e:7c) 56 data bytes
From 2a02:390:0:ff00:21b:21ff:fe70:869c icmp_seq=1 Destination unreachable: Address unreachable
From 2a02:390:0:ff00:21b:21ff:fe70:869c icmp_seq=2 Destination unreachable: Address unreachable
From 2a02:390:0:ff00:21b:21ff:fe70:869c icmp_seq=3 Destination unreachable: Address unreachable
From 2a02:390:0:ff00:21b:21ff:fe70:869c icmp_seq=4 Destination unreachable: Address unreachable
From 2a02:390:0:ff00:21b:21ff:fe70:869c icmp_seq=5 Destination unreachable: Address unreachable
^C
--- twilight.strangenoises.org ping statistics ---
7 packets transmitted, 0 received, +5 errors, 100% packet loss, time 6045ms

rachel@luna:~$ traceroute6 twilight.strangenoises.org
traceroute to twilight.strangenoises.org (2a02:390:6efd:0:4a5b:39ff:fe7e:7c) from 2a01:4f8:131:2482::2, 30 hops max, 24 byte packets
1  2a01:4f8:131:2480::1 (2a01:4f8:131:2480::1)  0.867 ms  0.695 ms  0.55 ms
2  hos-tr4.juniper2.rz13.hetzner.de (2a01:4f8:0:13:4:0:13:2)  0.177 ms  0.197 ms  0.166 ms
3  hos-bb2.juniper4.ffm.hetzner.de (2a01:4f8:0:2::1:4)  6.003 ms  6.03 ms  6.013 ms
4  2a02:390:0:ff00:21b:21ff:fe70:869c (2a02:390:0:ff00:21b:21ff:fe70:869c)  21.062 ms  20.631 ms  20.629 ms
5  2a02:390:0:ff00:21b:21ff:fe70:869c (2a02:390:0:ff00:21b:21ff:fe70:869c)  2756.27 ms !H  3025.42 ms !H  3030.46 ms !H


I blame 2a02:390:0:ff00:21b:21ff:fe70:869c !

Gary

Quote from: Steve on Jun 21, 2013, 11:21:50
I guess there are some issues with IPv6 routing, the latter part of this thread indicates all maybe not well.

http://www.idnetters.co.uk/forums/index.php/topic,30912.0.html

I've not tried myself as I don't use it at present due to the lack of a IPv6 firewall on my router.
I have a flavour of IPV6 that does not work with IDNet but a IPV6 firewall  ::) Seems to me more work needs to be done tuning IPV6 so its a tad more universal.
Damned, if you do damned if you don't

Steve

I could have an IPv6 firewall but I need to write it myself and I can't be bothered to work it out!
Steve
------------
This post reflects my own views, opinions and experience, not those of IDNet.

Gary

Quote from: Steve on Jun 21, 2013, 11:52:48
I could have an IPv6 firewall but I need to write it myself and I can't be bothered to work it out!
I don't blame you! Mine comes ready to go. You would think this would be sorted out for most users of all IPV6 capable routers as not many can write firewall rules themselves  :-\
Damned, if you do damned if you don't

brian_idnet

Hi,

You can try testing using:

ping -6 ipv6.idnet.net

Regards,

Brian
IDNet

Rachel

Quote from: brian_idnet on Jun 21, 2013, 13:53:51
Hi,

You can try testing using:

ping -6 ipv6.idnet.net

Regards,

Brian
IDNet

This is not a question of whether I have IPv6 working at all or not; it's been working well for me for about a year, and right now, for instance, I can ping6 not only that, but a number of ipv6 destinations out there.

But there's also whole swathes that I can't reach; like gb.archive.ubuntu.com, archive.ubuntu.com, my own server hosted at hetzner (for which ipv6 is working just fine right now) at luna.strangenoises.org.

Please take note of the traceroute I gave above. Traffic inwards is failing when it reaches 2a02:390:0:ff00:21b:21ff:fe70:869c.

Also, for the sake of completeness, trying to traceroute6 *outwards* from down here. The problem in this direction seems to be at 2a02:390:0:ff01:204:4eff:feb3:7419; meanwhile traceroute6 to ipv6.idnet.net or ipv6.google.com does route through there just fine.

Like I said, *some* IPv6 routing is not working.

rachel@octavia:~$ traceroute6 gb.archive.ubuntu.com
traceroute to gb.archive.ubuntu.com (2001:67c:1360:8c01::22) from 2a02:390:6efd:0:848a:d8b0:cdba:c488, 30 hops max, 24 byte packets
1  2a02:390:6efd:0:204:edff:fe82:53a9 (2a02:390:6efd:0:204:edff:fe82:53a9)  0.859 ms  0.523 ms  0.4 ms
2  2a02:390:ffff:ffff:ffff:ffff:ffff:fffc (2a02:390:ffff:ffff:ffff:ffff:ffff:fffc)  39.886 ms  26.494 ms  26.139 ms
3  2a02:390:0:ff01:204:4eff:feb3:7419 (2a02:390:0:ff01:204:4eff:feb3:7419)  25.813 ms  26.141 ms  25.816 ms
4  * * *
5  * * *
6  * * *
7  * * *
8  * * *
9  * * *
^C
rachel@octavia:~$ traceroute6 ipv6.idnet.net
traceroute to ipv6.idnet.net (2a02:390:1:0:20f:1fff:fe03:ca47) from 2a02:390:6efd:0:848a:d8b0:cdba:c488, 30 hops max, 24 byte packets
1  2a02:390:6efd:0:204:edff:fe82:53a9 (2a02:390:6efd:0:204:edff:fe82:53a9)  0.58 ms  0.456 ms  0.458 ms
2  2a02:390:ffff:ffff:ffff:ffff:ffff:fffc (2a02:390:ffff:ffff:ffff:ffff:ffff:fffc)  67.052 ms  26.207 ms  25.885 ms
3  2a02:390:0:ff01:204:4eff:feb3:7419 (2a02:390:0:ff01:204:4eff:feb3:7419)  25.759 ms  25.969 ms  26.11 ms
4  2a02:390:0:fffb:202:17ff:fe6a:b01b (2a02:390:0:fffb:202:17ff:fe6a:b01b)  26.042 ms  26.11 ms  25.894 ms
5  2a02:390::208:20ff:fee1:c8a8 (2a02:390::208:20ff:fee1:c8a8)  25.547 ms  25.555 ms  25.574 ms
6  2a02:390:1:0:20f:1fff:fe03:ca47 (2a02:390:1:0:20f:1fff:fe03:ca47)  25.879 ms  26.284 ms  25.754 ms
rachel@octavia:~$ traceroute6 ipv6.google.com
traceroute to ipv6.l.google.com (2a00:1450:4009:806::1011) from 2a02:390:6efd:0:848a:d8b0:cdba:c488, 30 hops max, 24 byte packets
1  2a02:390:6efd:0:204:edff:fe82:53a9 (2a02:390:6efd:0:204:edff:fe82:53a9)  0.59 ms  0.602 ms  0.71 ms
2  2a02:390:ffff:ffff:ffff:ffff:ffff:fffc (2a02:390:ffff:ffff:ffff:ffff:ffff:fffc)  26.325 ms  25.687 ms  25.629 ms
3  2a02:390:0:ff01:204:4eff:feb3:7419 (2a02:390:0:ff01:204:4eff:feb3:7419)  25.884 ms  25.993 ms  25.725 ms
4  2a02:390:0:fffb:202:17ff:fe6a:b01b (2a02:390:0:fffb:202:17ff:fe6a:b01b)  25.891 ms  25.738 ms  25.767 ms
5  2a02:390::21b:21ff:fec8:91b0 (2a02:390::21b:21ff:fec8:91b0)  25.594 ms  26.088 ms  26.138 ms
6  2001:7f8:17::3b41:1 (2001:7f8:17::3b41:1)  26.371 ms  25.759 ms  26.16 ms
7  2001:4860::1:0:15f (2001:4860::1:0:15f)  26.751 ms  26.648 ms  26.738 ms
8  2001:4860:0:1::d3 (2001:4860:0:1::d3)  27.044 ms  26.733 ms  27.002 ms
9  2a00:1450:8000:18::9 (2a00:1450:8000:18::9)  26.584 ms  26.263 ms  26.377 ms

Rachel

Seems to be resolved now; at least for those destinations I was having problems with before. Inward connections to my home net via ipv6 working now too.