Unitymedia MTU IPv6

[rv112]

Ja das hilft immer für eine Zeit, doch leider nicht lange. Aus welchem Bundesland kommst Du und was für ein Prefix forderst Du an?

 

[JurgenS]

Aus NRW. Ich fordere gar keinen Präfix an (jedenfalls nicht bewußt) und bekomme von UM per DHCP6 einen /59. Die pfSense verteilt dann /64 weiter. Also eigentlich nichts Besonderes erkennbar.

LG Jürgen

 

[tux1337]

Die Gateway Gruppe kann nicht die Ursache sein, ich habe keine und die Probleme trotzdem.

Ich hatte eben wieder Probleme, jedoch kein Packet Loss zu sehen und die Latenzen halten sich im Rahmen.
Ich werde heute Nacht mal eine E2E Messung aufsetzen die alle 5 Minuten läuft und die IPv6 Funktionalitat protokolliert.
Ich hoffe das ich es reproduzieren kann


Es tritt bei mir immer nur abends auf. Wenn ich wild spekulieren darf, konnte ich mir vorstellen, das die Peering Kapazität erschöpft ist und daher ein throttle bzw. Packet queuing greift. Daher kein Durchsatz mehr und stockendes Laden.

 

[rv112]

Aus NRW. Ich fordere gar keinen Präfix an (jedenfalls nicht bewußt) und bekomme von UM per DHCP6 einen /59. Die pfSense verteilt dann /64 weiter. Also eigentlich nichts Besonderes erkennbar.

LG Jürgen

Achja? Wenn ich kein 56/ anfordere, bekomm ich irgendwas woraus die pfSense dann kein /64 macht.

 

[tux1337]

Ich hab jetzt mal im Abstand von 5 Minuten 100MB heruntergeladen und den Speed gemessen. Ipv6 only natürlich.
Das schwankt extrem obwohl die Leitung idle ist.

Das allein ist nun nicht aussagekräftig, habe es daher abgewandelt, das zuerst v6 dann v4 gemessen wird. Lass ich jetzt mal ne Weile laufen, dann sieht man ob es Unterschiede zwischen den Protokollen gibt und auch in welchen Zeiten.

<i>
</i>Di 5. Jun 22:55:01 CEST 2018 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 20.2M 0 0:00:04 0:00:04 --:--:-- 22.5M
Di 5. Jun 23:00:02 CEST 2018 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 10.9M 0 0:00:09 0:00:09 --:--:-- 11.2M
Di 5. Jun 23:05:01 CEST 2018 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 5738k 0 0:00:17 0:00:17 --:--:-- 7448k
Di 5. Jun 23:10:01 CEST 2018 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 7835k 0 0:00:13 0:00:13 --:--:-- 9109k
Di 5. Jun 23:15:01 CEST 2018 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 8978k 0 0:00:11 0:00:11 --:--:-- 16.8M
Di 5. Jun 23:20:01 CEST 2018 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed
100 100M 100 100M 0 0 12.5M 0 0:00:07 0:00:07 --:--:-- 12.1M

 

[rv112]

Ich hatte die Tage das gleiche Phänomen. Ich teste heute noch mal nachdem ich jetzt über Nacht sogut wie kein Paketloss mehr hatte.

 

[rv112]

Leute es wird immer interessanter. Nachdem es nun über Nacht einwandfrei lief, fing es heute plötzlich um 14:10 Uhr wieder an:

Kurze Zeit später sah es dann so aus, dass der Ping nicht mehr bis ganz zu heise.de durch kam!

Um das ganze dann zu krönen, ging es kurz danach plötzlich wieder, allerdings mit anderem Routing und 10ms mehr! IPv4 bliebt unverändert. Pfuscht UM denn nun am IPv6 Routing und sind das unsere Probleme?

 

[sch4kal]

Leute es wird immer interessanter. Nachdem es nun über Nacht einwandfrei lief, fing es heute plötzlich um 14:10 Uhr wieder an:

Kurze Zeit später sah es dann so aus, dass der Ping nicht mehr bis ganz zu heise.de durch kam!

Um das ganze dann zu krönen, ging es kurz danach plötzlich wieder, allerdings mit anderem Routing und 10ms mehr! IPv4 bliebt unverändert. Pfuscht UM denn nun am IPv6 Routing und sind das unsere Probleme?

Das geht ja im zweiten Bild über Amsterdam :shock:

 

[rv112]

Also vermutlich in Frankfurt was ausgefallen? Aufs Forum hier komme ich über IPv6 auch nicht mehr.

 

[Dragon]

Um das ganze dann zu krönen, ging es kurz danach plötzlich wieder, allerdings mit anderem Routing und 10ms mehr! IPv4 bliebt unverändert. Pfuscht UM denn nun am IPv6 Routing und sind das unsere Probleme?

Wie man auf den Screenshots eindeutig sieht, ändert sich das Routing am Übergang zwischen Hurricane Electric und Plusline. Da kann UM nun wirklich nichts für.

 

[rv112]

Mein IPv6 läuft nun seit gestern Abend so gut wie gar nicht mehr. Auch ein Neustart der pfSense bringt nix mehr. Packetloss immer bei 50-80%.

 

[tux1337]

Ich habe in den letzten Tagen einige Tests gemacht:

- 24h Downloadtest IPv4 und IPv6, alle 5 Minuten 100MB von belwue
Keine Auffälligkeiten, sowohl IPv4 und IPv6 schwankend, jedoch immer mindestens 70% meiner zugesicherten Bandbreite, alle Downloads erfolgreich.

- 20h ping test zu facebook in IPv4 und IPv6,
Keine Auffälligkeiten, sowohl IPv4 und IPv6 kein Packet loss. Latenz bewegt sich zwischen 20-40ms bei beiden IP Protokollen

- Ich habe nun mtr angeworfen um die komplette Strecke zu monitoren. Auffällig ist hier, dass ein Router, der noch bei Unitymedia steht leichten packet loss zeigt. Alle weiteren Pakete kommen durch. Könnte ggf. auch ein DDOS Schutz sein.
Nicht verwirren lassen vom jeweils 2. Eintrag, das ist die olle Connectbox. Die antwortet konsequent nicht.

 

[rv112]

So ich habe nun mein komplettes IPv6 Setup über den Haufen geschmissen und alles von vorne "verdrahtet". Bis jetzt sieht es deutlich besser aus!

Nochmal kurz zur Erinnerung:

Bisher hatte ich IPv6 via DHCPv6 am WAN Interface angefordert, sowie ein /56 Prefix. Das habe ich mittels "Track Interface WAN" auf das LAN Interface verteilt. Dadurch entstand am WAN ein /56 Prefix und am LAN ein /64 Prefix. Dieses wurde dann via RA an die Clients verteilt. Hier kam es völlig random zu Paketloss bis dass gar keine Verbindung ins Internet und aus dem Internet auf die Clients möglich war. Bis zum WAN Interface konnte ich vom LAN aus pingen, ebenfalls konnte ich vom Internet aus bis zum LAN pingen. Hier wurde jedoch nicht sauber geroutet, wieso auch immer!

Nun fordere ich auf dem WAN via DHCPv6 ein /64 Prefix an und habe die Option "Only request an IPv6 prefix, do not request an IPv6 address" gesetzt. Dadurch erhält mein WAN Interface nur noch eine Linklocal Adresse. LAN steht noch immer auf "Track Interface WAN" und erhält dadurch ein /56 Prefix von UM. (Ich denke ich kann am WAN auch ein /56 anfordern, da UM in BW immer ein /56 verteilt, aber ich teste es erst mal so da es gerade läuft). Da ein /56 Prefix am LAN jedoch Mist ist, muss ich mit DHCPv6 im LAN arbeiten und dadurch an meine Clients IPv6 Adressen verteilen. Dieser erhalten dadurch als Standardgateway nicht mehr die fe80 Adresse des WAN Interface, sondern die Global. Ob das das Problem war dass UM hier nicht sauber zurückfindet?

Jedenfalls kann ich nun IPv6 super nutzen und auch sämtliche IPv6 Dienste laufen deutlich schneller. Google Maps und Youtube keine Probleme mehr :radio: Ich hoffe dass es so bleibt! Wieso ich hier völlig anders vorgehen muss als bei der Telekom erschließt sich mir jedoch noch nicht.

 

[rv112]

Hm Mist. Ein Nachteil hat es: SLAAC geht nicht mehr und damit keine Privacy Extensions.

 

[tux1337]

SLAAC sollte gehen, deine pfsense sollte für das LAN RA senden. Unabhängig vom Prefix.... Hast du RA im Abschnitt DHCPv6 & RA konfiguriert?

 

[rv112]

Steht auf assisted. Aber ich bekomm keine Privacy Extensions auf den Clients zugeteilt und Android Geräte keine IPv6. Soweit ich weiß brauchen die zwingend SLAAC.

 

[Menano]

Google Maps und Youtube keine Probleme mehr :radio:

In einem anderen Thread schreibst du 10 Minutwn später dass du immernoch Probleme hast mit Youtube. Was denn nun?

 

[rv112]

Die Seiten haben teilweise nicht geladen. Unabhängig von den Videos. Das Youtubeproblem besteht noch immer. Etwas blöd ausgedrückt, sorry.

 

[rv112]

Steht auf assisted. Aber ich bekomm keine Privacy Extensions auf den Clients zugeteilt und Android Geräte keine IPv6. Soweit ich weiß brauchen die zwingend SLAAC.

Problem solved. Ich habe nun ein /56 angefordert aber lediglich als Prefix, keine IP. Die pfSense hat sich dann ein /64 auf dem LAN erstellt. Nun geht auch SLAAC. Allerdings braucht mein iPhone nun plötzlich bis es IPv6 nutzt. Irgendwas ist immer :streber:

 

[Wechseler]

Wieso ich hier völlig anders vorgehen muss als bei der Telekom erschließt sich mir jedoch noch nicht.

Ich weiß nicht, was du da machst, aber die Standardmethode ist, vom ISP ein /56-Prefix anzufordern und dann im LAN ein oder mehrere /60er-Prefixe daraus weiterzuverteilen. Damit funktionieren dann sowohl SLAAC als auch Prefix Delegation via DHCPv6.

 

[rv112]

So hatte ich es auch. Dadurch kam es jedoch zu diesem seltsamen Paketloss. Im Internet finden sich vereinzelt Leute mit dem gleichen Problem. Diese haben es entweder nie gelöst, oder einen Tunnelbroker genommen.

Ich habe nun auch SLAAC wieder am laufen und seit gestern Abend kein Paketloss mehr.

 

[Andreas1969]

So hatte ich es auch. Dadurch kam es jedoch zu diesem seltsamen Paketloss. Im Internet finden sich vereinzelt Leute mit dem gleichen Problem. Diese haben es entweder nie gelöst, oder einen Tunnelbroker genommen.

Ich habe nun auch SLAAC wieder am laufen und seit gestern Abend kein Paketloss mehr.

Sei froh, daß wenigstens IPV4 mäßig alles rund läuft.
Bei mir ist es nämlich genau andersherum, IPV6 macht absolut keine Probleme, dafür klemmt´s aber mächtig bei IPV4. Dummerweise laufen die meisten Sachen, die ich nutze nur auf IPV4.

 

[rv112]

Ich bin froh dass nun beides stabil läuft! Hoffe das bleibt so.

 

[Andreas1969]

Ich bin froh dass nun beides stabil läuft! Hoffe das bleibt so.

Na, wenn es in Deiner Macht steht, es noch selbst zu lösen, dann ist ja alles gut.

In meinem Fall kann ich das leider nicht lösen und bin absolut vom Provider abhängig.
Hab da keinen Einfluss drauf, was der an meinem Anschluss zaubert, das Routing kann ich ja nicht selbst verändern :traurig:

 

[Andreas1969]

Jedenfalls musste ich gestern Abend feststellen, daß bei mir der Anschluss mit DSLITE deutlich flüssiger läuft.
Die Reaktionszeit und das laden von Webseiten lief deutlich flüssiger, das Routing ist deutlich besser, die Datenrate im DS wird wieder voll erreicht, Ping hat sich halbiert usw.
Sogar die Telefonie zu den V4 SIP Servern lief über´s AFTR anstandslos weiter.

Das KO Kriterium war natürlich, daß mein Anschluß nicht mehr erreichbar war und die Playstation vom Sohnemann nicht mehr lief (keine Verbindung zum PSN), daher musste ich nach 1 Stunde wieder auf DS zurückstellen.