Hetzner ping ipv4 ipv6 Telekom

[CEW4]

Hallo,

ich verfolge gerade ein wirklich merkwürdiges Problem: Es geht um einen Server bei Hetzner.

- per IPv6 kann ich ihn pingen von überall

- per IPv4 kann ich ihn NICHT pingen von dem einem DSL-Anschluss (Telekom) aus, von einem anderen (m-net) aus dagegen schon

- traceroute (IPv4) von beiden Anschlüssen aus geht bis zu einem Hetzner-Server "ex9k2.dc12.fsn1.hetzner.com", als nächster Hop kommt dann der Zielserver oder eben nicht

- der Hetzner-Server "ex9k2" erscheint in den Traceroutes mit unterschiedlichen IPv4:
213.239.203.194 -> dann geht's weiter zum Zielserver
213.239.254.126 -> danach geht's NICHT weiter zum Zielserver

- Vom m-net-DSL-Anschluss aus wird offenbar über DE-CIX geroutet, im Traceroute taucht ein Server "decix-gw.hetzner.com" auf. Vom Telekom-Anschluss aus steht an dieser Stelle ein unbekannter Server (IPv4 62.157.248.241).

Was ist denn hier los? Handelt es sich um ein Peering-Problem zwischen Hetzner und Telekom? Meine einzige Erklärung ist, daß der Hetzner-Server die Antwort auf meinen Ping fälschlicherweise über die DE-CIX-Route an mich zurückschicken will, obwohl die Telekom über eine andere Route verbindet.

Der Fehler existiert seit genau 22:12 Uhr am 13.08., vorher war alles in Ordnung.

Hat sowas schon einmal jemand beobachtet?

 

[d4f]

Anmerkung Vorweg:
Hetzner und Telekon haben/hatten immer wieder Diskussionen über Peering. Grund ist dass Telekom sich sowohl vom Kunden als auch dem Netzwerkpartner bezahlen lassen will und skrupellos vorgeht/vorging (angeblich gewollt unzureichende öffentliche Peering-Kapazitäten am DECIX/AMSIX/...)
Ich denke aber nicht dass Peering hier dein Problem ist.

Meine einzige Erklärung ist, daß der Hetzner-Server die Antwort auf meinen Ping fälschlicherweise über die DE-CIX-Route an mich zurückschicken will, obwohl die Telekom über eine andere Route verbindet.

Es ist durchaus möglich dass Pakete unterschiedliche Routen auf Hin- und Rückweg nehmen, die Wahl wird jeweils von den Routern auf dem Weg getroffen, u.a. um Kosten, Last oder Latenz zu optimisieren

Ist der Server nicht pingbar oder nicht erreichbar? Ping kann auch u.A. durch DDoS-Schutzsysteme gedroppt werden.
Meine Empfehlung wäre ein Tcpdump über ICMP-Pakete auf dem Server (tcpdump -s 0 -i any -w /tmp/dump.pcap icmp), dann lokal in Wireshark laden um zu sehen ob dein Paket beim Server ankommt und wenn ja ob er es beantwortet.

 

[CEW4]

Der betreffende Server gehört nicht mir, ich kann also nur von aussen arbeiten. (Ich habe selbst auch einen Server bei Hetzner, bei dem ist alles ok.)

Ja, es geht um Erreichbarkeit, nicht nur um Ping-Response: Der darauf laufende Webserver ist genauso (d.h. nur über IPv6) erreichbar. Außerdem antwortet die Maschine ja durchaus auf IPv4-Ping - nur eben nicht auf den Ping vom Telekom-Anschluss, dort nur auf IPv6.

Ich kann mir einfach keinen Reim darauf machen:

- Wenn es ein Peering-Problem wäre, dann würde es doch IPv4 und IPv6 betreffen.
- Wenn es am Server liegen würde, dann würde er entweder auf alle IPv4-Pings antworten oder auf gar keine.
- Und wenn es eine absichtliche Konfiguration (block Ping) wäre, dann müsste der Webserver trotzdem antworten.

 

[marce]

- Wenn es ein Peering-Problem wäre, dann würde es doch IPv4 und IPv6 betreffen.

Da liegst Du leider falsch - ich habe hier gerade auch einen nettes Problem, dass ich einen Dienst via IPv4 problemlos erreiche, mit IPv6 aber massive Probleme habe (extreme Latenzen bis zum kompletten Paketverlust) - liegt in dem Fall auch am Peering zweier Netzbetreiber.

 

[CEW4]

Seit gestern Nachmittag (21.08. um 15:43 Uhr) ist das Problem verschwunden, ebenso unangekündigt wie es eine gute Woche zuvor aufgetreten war.

Merkwürdige Sache.

 

[dataforest]

Es ist durchaus möglich dass Pakete unterschiedliche Routen auf Hin- und Rückweg nehmen, die Wahl wird jeweils von den Routern auf dem Weg getroffen, u.a. um Kosten, Last oder Latenz zu optimisieren

Nicht nur möglich sondern sogar absolut normal.

Da liegst Du leider falsch - ich habe hier gerade auch einen nettes Problem, dass ich einen Dienst via IPv4 problemlos erreiche, mit IPv6 aber massive Probleme habe (extreme Latenzen bis zum kompletten Paketverlust) - liegt in dem Fall auch am Peering zweier Netzbetreiber.

Ebenso normal, die Routingtabellen eines Routers für IPv4 und IPv6 haben erstmal nichts miteinander zu tun. Wenn entsprechendes Traffic Engineering identisch für beide Protokolle konfiguriert ist oder vererbt wird (wir vermeiden abweichende Policy-Statements für v4 und v6 sondern haben normalerweise eine BGP-Gruppe pro Upstream / Peering / Kunde) kann es weniger Unterschiede geben, aber das hängt immer noch davon ab, ob der jeweilige Neighbor überhaupt eine entsprechende Route anbietet respektive diese dieselbe Routingentscheidung wie beim anderen Protokoll auslöst.

 

[marce]

naja, massiv erhöhte Latenzen und massiver Paketverlust ist nicht normal - ich wollte damit nur sagen "Verhalten ipv4 und ipv6 ist nicht vergleichbar und das eine hat mit dem anderen nichts zu tun"

 

[dataforest]

Ja, ich auch
Natürlich ist Packet Loss nicht normal, aber dass v4 und v6 unterschiedlich geroutet wird eben schon. Sollte nichts sein was man mit dem zuständigen NOC auf einer der Seiten nicht gelöst bekommt.