Unitymedia IPv6 Problem mit HE Tunnelbroker & KabelBW / Unitymedia

[rschmied]

Seit gestern (?) funktioniert mein IPv6 Tunnel zu HE nicht mehr. Nichts verändert, ich sehe auch eingehende Pakete. Aber alles, was meinen Router verlässt und nicht IP/UDP/TCP/ICMP ist (hier: IPv6inIP, IP Protokoll 41), wird *scheinbar* vom ISP weggedropped.

• Remote Tunnel-Endpunkt: ping-bar
• IPv4 address lease: erneuert (neue IP erhalten)
• IPv6 Ping von remote host: sichtbar auf meinem router mit ICMP debug (s.u.)

Bin ich ein Einzelfall? Oder gibt es noch andere, die eine ähnliche Konstellation haben und das gleiche beobachten?

Danke,

189500: May 9 09:46:55 CEST: ICMPv6: Received echo request, Src=2001:1868:XXX::XX, Dst=2001:470:XXXX:XXX::2
189501: May 9 09:46:55 CEST: ICMPv6: Sent echo reply, Src=2001:470:XXXX:XXX::2, Dst=2001:1868:XXX::XX

 

[Knifte]

Wie könnte ich das denn testen?

Bei mir sieht auf den 1. Blick alles ok aus.

 

[rschmied]

Wie könnte ich das denn testen?

Unter der Annahme, dass Du kein natives IPv6 hast und IPv6 via Tunnelbroker verwendest, solltest du via

ping6 http://www.google.com
ping6 http://www.heise.de

überprüfen können, ob deine IPv6 Verbindung funktioniert (Bei Windows 'ping -6 http://www.google.com'). Falls du allerdings eine native IPv6 Verbindung dann ist das nicht relevant.

Danke,

Host im Internet:

[rschmied@host ~]$ ping6 http://www.google.com
PING6(56=40+8+8 bytes) 2001:1868:XXX::XX --> 2607:f8b0:4010:801::1010
16 bytes from 2607:f8b0:4010:801::1010, icmp_seq=0 hlim=57 time=2.275 ms
16 bytes from 2607:f8b0:4010:801::1010, icmp_seq=1 hlim=57 time=2.362 ms
16 bytes from 2607:f8b0:4010:801::1010, icmp_seq=2 hlim=57 time=2.253 ms
16 bytes from 2607:f8b0:4010:801::1010, icmp_seq=3 hlim=57 time=2.296 ms
^C
--- http://www.google.com ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 2.253/2.296/2.362/0.041 ms

Bei mir zu Hause:

Mac-mini:~ rschmied$ ping6 http://www.heise.de
PING6(56=40+8+8 bytes) 2001:470:XXXX:XXX:591b:dd7b:e3f0:abf3 --> 2a02:2e0:3fe:1001:7777:772e:2:85
^C
--- http://www.heise.de ping6 statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss
Mac-mini:~ rschmied$

 

[Knifte]

Bin auch via HE Tunnelbroker mit IPv6 unterwegs und habe ansonsten einen reinen IPv4-Internetzugang.

Bei mir kommt folgendes raus:

>ping -6 www.google.com
Ping wird ausgeführt für www.google.com [2a00:1450:4001
Daten:
Antwort von 2a00:1450:4001:80e::1013: Zeit=12ms
Antwort von 2a00:1450:4001:80e::1013: Zeit=13ms
Antwort von 2a00:1450:4001:80e::1013: Zeit=12ms
Antwort von 2a00:1450:4001:80e::1013: Zeit=12ms
Ping-Statistik für 2a00:1450:4001:80e::1013: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 12ms, Maximum = 13ms, Mittelwert = 12ms

 

[SpaceRat]

Ping wird ausgeführt für www.google.com [2a00:1450:4001:80e::1011] mit 32 Bytes Daten:
Antwort von 2a00:1450:4001:80e::1011: Zeit=31ms
Antwort von 2a00:1450:4001:80e::1011: Zeit=18ms
Antwort von 2a00:1450:4001:80e::1011: Zeit=23ms
Antwort von 2a00:1450:4001:80e::1011: Zeit=17ms
Ping-Statistik für 2a00:1450:4001:80e::1011: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 17ms, Maximum = 31ms, Mittelwert = 22ms

Ist zwar ein SixXS-Tunnel, aber in der Heartbeat-Variante ist es letztlich auch 6in4.

 

[fear55]

Hier seit 2 bzw jetz 3 Tagen genau das selbe Problem. Lief vorher ca 1 Jahr ohne Probleme.

Tunnel-Endpoint ist pingbar, das wars.
Neue IPv4 und auch andere HE Server bereits getestet. Keine Änderung.

 

[rschmied]

OK, ich konnte das Problem mittlerweile etwas eingrenzen:

Die enkapsulierten Pakete schaffen es bis zu HE ins Rechenzentrum. KabelBW macht also erstmal nix falsch, so wie es aussieht. Entweder der Tunnelserver hat ein Problem oder aber es gibt dort irgendwas, was meine Pakete verwirft.

rtr(config-if)#
rtr(config-if)#tunnel ttl 9
rtr(config-if)#
191029: May 9 14:25:31 CEST: ICMP: time exceeded rcvd from 184.105.213.89
191030: May 9 14:25:32 CEST: ICMP: time exceeded rcvd from 184.105.213.89
191031: May 9 14:25:33 CEST: ICMP: time exceeded rcvd from 184.105.213.89
191032: May 9 14:25:34 CEST: ICMP: time exceeded rcvd from 184.105.213.89
191033: May 9 14:25:35 CEST: ICMP: time exceeded rcvd from 184.105.213.89
191034: May 9 14:25:36 CEST: ICMP: time exceeded rcvd from 184.105.213.89
191035: May 9 14:25:37 CEST: ICMP: time exceeded rcvd from 184.105.213.89
rtr(config-if)#
rtr(config-if)#tunnel ttl 10
rtr(config-if)#
rtr(config-if)#
rtr(config-if)# <--- hier ist dann Stille im Wald
rtr(config-if)#

Wie man sieht, ist das bei HE im Rechenzentrum, vorletzter Hop. Irgendwas schein da nicht in Ordnung zu sein. Muss mal schauen, ob es da ein Forum o. ae. gibt, wo man das eintueten kann... Ist ja schliesslich ein geschenkter Gaul, da werde ich kaum eine Hotline anrufen koennen

rtr(config-if)#do tracer 216.66.84.42
Type escape sequence to abort.
Tracing the route to tserv1.par1.he.net (216.66.84.42) 1 * * * 2 172.30.21.113 8 msec 12 msec 12 msec 3 172.30.21.253 8 msec 8 msec 8 msec 4 84.116.191.2 16 msec 16 msec 12 msec 5 de-fra01a-ri2-xe-5-1-1.aorta.net (84.116.133.114) 12 msec 16 msec 84.116.132.161 16 msec 6 84.116.132.186 16 msec 16 msec 12 msec 7 30gigabitethernet4-3.core1.fra1.he.net (80.81.192.172) 12 msec 16 msec 20 msec 8 100ge5-2.core1.par2.he.net (72.52.92.13) 24 msec 24 msec 24 msec 9 10ge3-1.core1.par1.he.net (184.105.213.89) 36 msec 24 msec 24 msec 10 tserv1.par1.he.net (216.66.84.42) 24 msec 20 msec 20 msec
rtr(config-if)#

 

[Knifte]

Es ist dann aber kein generelles Problem bei tunnelbroker.net, da es bei mir beim gleichen Anbieter funktioniert.

 

[NoGi]

Wie könnte ich das denn testen?

Unter der Annahme, dass Du kein natives IPv6 hast und IPv6 via Tunnelbroker verwendest, solltest du via

ping6 http://www.google.com
ping6 http://www.heise.de

überprüfen können, ob deine IPv6 Verbindung funktioniert (Bei Windows 'ping -6 http://www.google.com'). Falls du allerdings eine native IPv6 Verbindung dann ist das nicht relevant.

FB 6340 mit SIXX Tunnel

gio3:~ # ping6 -n six.heise.de
PING six.heise.de(2a02:2e0:3fe:1001:302::) 56 data bytes
64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=1 ttl=55 time=25.1 ms
64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=2 ttl=55 time=23.9 ms
64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=3 ttl=55 time=31.9 ms
64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=4 ttl=55 time=30.9 ms
64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=5 ttl=55 time=26.2 ms
64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=6 ttl=55 time=28.5 ms
64 bytes from 2a02:2e0:3fe:1001:302::: icmp_seq=7 ttl=55 time=25.1 ms
^C
--- six.heise.de ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 23.932/27.434/31.948/2.875 ms

Nun der traceroute (über den Endpunkt net-cologne)

gio3:~ # traceroute -6 six.heise.de
traceroute to six.heise.de (2a02:2e0:3fe:1001:302::), 30 hops max, 80 byte packets 1 2001:4dd0:ff00:9463:2665:11ff:fe02:4552 (2001:4dd0:ff00:9463:2665:11ff:fe02:4552) 1.522 ms 1.509 ms 1.732 ms 2 gw-5220.cgn-01.de.sixxs.net (2001:4dd0:ff00:1463::1) 22.851 ms 23.789 ms 26.542 ms 3 2001:4dd0:1234:3::42 (2001:4dd0:1234:3::42) 26.530 ms 26.519 ms 26.505 ms 4 core-eup2-ge1-22.netcologne.de (2001:4dd0:1234:3:dc40::a) 26.493 ms 26.481 ms * 5 * * * 6 * 2001:4dd0:a2b:a8:30::b (2001:4dd0:a2b:a8:30::b) 26.467 ms 29.752 ms 7 ams-ix-v6.nl.plusline.net (2001:7f8:1::a501:2306:1) 28.919 ms 28.893 ms 27.000 ms 8 te3-2.c501.f.de.plusline.net (2a02:2e0:14:6::501) 60.835 ms 56.036 ms 60.813 ms 9 te2-4.c101.f.de.plusline.net (2a02:2e0:10:3:c::1) 31.315 ms 35.991 ms *
10 * * *
11 * * 2a02:2e0:3fe:ff21:c::2 (2a02:2e0:3fe:ff21:c::2) 27.081 ms !X
gio3:~ # ^C

-NoGi

 

[rschmied]

Alles wieder im Lack. Bin von Paris nach Frankfurt umgezogen. Was mir etwas schwerfiel, da ich dadurch ja auch zu einem 're-numbering' gezwungen war. Man gewoehnt sich eben doch ein wenig an 'seinen' prefix. Angelegt 2009. Sniff.

Frage mich nun, ob das ein Konfigurationsproblem bei HE war oder aber ob HE sowas wie Geo Location implementiert hat und das Nutzen von Prefixes aus anderen Laendern nun aktiv unterbindet... Werde bei Gelegenheit mal andere, gewoehnlich gut unterrichtete Kanaele anzapfen.

Man stelle sich vor, man nutzt einen Prefix aus den Staaten und koennte damit die GEMA oder aehnliche Institutionen unterlaufen...

Danke,

P.S. hatte mich doch schon ein wenig an die franzoesische Werbung bei Google gewoehnt...