IPv6 Störung - extreme creepshow - bin hilflos...

PMc

Well-Known Member
Hi Leute,

heute morgen um 02:40 war mein Netzwerk plötzlich weg.
Keinerlei Konfigurations-Aktivität in letzter Zeit - ich hab, wie es sich für einen anständigen Bürger gehört ;) nur Videos geguckt und Einkäufe getätigt.

Erste Analyse ergab, dass das Problem an den VPN-Tunnels liegt, die mein Basecamp mit den externen Sites verbinden. Die laufen mit openvpn, UDP und IPv6 und verwandeln das ganze Konstrukt in ein scheinbar homogenes LAN - und da geht teilweise nichts mehr durch.
Weitere Analyse der nackten IPv6 Verbindungen ergab dann, dass bei manchen eben das UDP nicht geht, bei anderen TCP nicht geht und bei wieder anderen ping/ICMP6 nicht geht - das alles völlig random und offenbar zufallsverteilt.

Mit tcpdump kann ich sehen, dass die Pakete hier im Basecamp abgeschickt werden, ich kann sie noch sehen wenn sie in PPPoE eingepackt ins DSL-Modem gehen. Aber auf der anderen Seite im Netzwerk-Interface tauchen sie nicht auf. Also hab ich erstmal bei der Telekom angerufen, und das ergab -natürlich- nichts.
Ein cluster-weiter Neustart ergab auch keine Besserung.

Das IPv6 ist so aufgesetzt, dass das Basecamp, das wie gesagt an einem Telekom DSL hängt, den Telekom /56 Prefix nutzt, die (drei) externen Sites sind über Tunnelbroker von HurricaneElectric angeschlossen, also mit gif Interfaces.
Zwischen den externen Sites, also innerhalb des HE-Netzes, scheint soweit alles normal zu funktionieren, nur vom (Telekom) Basecamp aus gibt es die Probleme. (Einen dritten Provider zum Vergleich hab ich erstmal nicht greifbar.)

Dann hab ich mich erstmal auf den ping konzentriert und bemerkt, dass das Verhalten auch davon abhängt, welche Absender-IP verwendet wird! Die gif Anbindung des Tunnelbroker verwendet zwei IPv6 Adressen für die Brückenpfeiler (in einem extra subnet) zusätzlich zum gerouteten Subnet, und auch diese (mindestens) drei Adressen verhalten sich jeweils unterschiedlich, wenn man sie anpingt. Zum Beispiel:

Code:
destination                                     tun-1   tun-2   tun-3
from 2003:e7:171d:6eff::1                       FAIL    FAIL    FAIL
from 2003:e7:171d:6ee1:41d:92ff:fe01:104        ok      FAIL    FAIL
from 2003:e7:171d:6ee0:41d:92ff:fe01:105        ok      ok      ok
from 2003:e7:17ff:f22:41d:92ff:fe01:301         FAIL    ok      ok

Code:
ingress point                                   tun-1   tun-2   tun-3
from 2003:e7:171d:6eff::1                       FAIL    ok      FAIL
from 2003:e7:171d:6ee1:41d:92ff:fe01:104        FAIL    ok      FAIL
from 2003:e7:171d:6ee0:41d:92ff:fe01:105        ok      FAIL    ok
from 2003:e7:17ff:f22:41d:92ff:fe01:301         FAIL    FAIL    FAIL
Code:
egress point                                    tun-1   tun-2   tun-3
from 2003:e7:171d:6eff::1                       FAIL    ok      FAIL
from 2003:e7:171d:6ee1:41d:92ff:fe01:104        ok      ok      FAIL
from 2003:e7:171d:6ee0:41d:92ff:fe01:105        ok      ok      ok
from 2003:e7:17ff:f22:41d:92ff:fe01:301         FAIL    FAIL    ok

Irendjemand eine Idee, wo ich hier weitermachen könnte?
 
Ipv6 ja:

Tunnelbroker oder OpenVPN: Nein
(das wenige was ich da mache, mache ich mit wg)

Könnten die Tunnelbroker ein Problem haben?

Für mich zum verständniss:

Basecamp: Öffentliche, native ipv6 adresse über Telekom pppoe, openvpn-server per ipv6 erreichbar
Sites: Öffentliche native ipv4 adresse, dadrüber öffentliche ipv6-konnektivität per TunnelBroker, verbinden sich per ipv6 zum openvpn-server über das tunnelbroker ipv6?
 
Super, danke, ja, alles richtig verstanden!

Das openvpn kann aus dem Spiel bleiben, denn das Problem passiert auch schon mit einfachem ping6.

Könnten die Tunnelbroker ein Problem haben?

Nein, innerhalb der Tunnelbroker, also von einer Site zur anderen, auch interkontinental, gibt es soweit kein Problem.

Das Problem liegt etweder an meinem Basecamp (aber dann wüsste ich nicht wo, denn die ausgehenden Pakete sehen im PPPoE noch korrekt aus, und das DSL-Modem hab ich factory-resettet, und IPv6-Verbindungen zu google oder freebsd funktionieren korrekt), oder irgendwo zwischen Telekom (ASN 3320) und den Tunnelbrokern (ASN 6939?). Wenn letzteres, dann ist aber auch unverständlich, dass das sonst niemandem auffällt.

Ich bräuchte also im nächsten Schritt einfach ein paar cross-checks von Leuten, die IPv6 haben, sich trauen händisch ein paar IP-aliase zu setzen, und idealerweise von der Telekom versorgt sind (noch idealer über den Frankfurter exchange).

Dann braucht man nur ein paar freie Adressen als Aliase auf irgendein Interface setzen:

Code:
vtnet0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
        ether 06:1d:92:01:03:01
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:20 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:21 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:22 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:23 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:24 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:25 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:26 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:27 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:28 prefixlen 64
        inet6 2003:e7:17ff:18d8:41d:92ff:fe01:29 prefixlen 64

und dann schauen ob die Verbindung bekommen:

Code:
$ for i in 20 21 22 23 24 25 26 27 28 29
  do
  ping -q -c 1 -S 2003:e7:17ff:18d8:41d:92ff:fe01:$i \
    tunnel769899.tunnel.tserv10.par1.ipv6.he.net >/dev/null 2>&1 && \
    echo $i okay || echo $i FAIL
  done
20 FAIL
21 FAIL
22 okay
23 FAIL
24 FAIL
25 FAIL
26 okay
27 FAIL
28 FAIL
29 FAIL

Als Ziele taugen meine beiden babies (pole.daemon.contact und moon.daemon.contact), und im prinzip auch die Tunnelserver.
 
hi

mal die tunnelbroker ip addressen von aussen testen z.b. mit

ping-ipv6.google.com-ipv6.html
oder

Die funktionieren. Das pingt zwar von verschiedenen Locations aus, aber soweit ich sehe sind alle diese Locations im ASN 15169 (Google).
 
von netcologne anschluss

~ 3>doas ping6 -n -c 5 -V 7 2003:e7:17ff:18d8:41d:92ff:fe01:20
PING 2003:e7:17ff:18d8:41d:92ff:fe01:20 (2003:e7:17ff:18d8:41d:92ff:fe01:20): 56 data bytes
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:20: icmp_seq=0 hlim=57 time=19.407 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:20: icmp_seq=1 hlim=57 time=20.364 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:20: icmp_seq=2 hlim=57 time=19.181 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:20: icmp_seq=3 hlim=57 time=19.182 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:20: icmp_seq=4 hlim=57 time=55.762 ms


~ 5>doas traceroute6 -n -V 7 2003:e7:17ff:18d8:41d:92ff:fe01:20
traceroute6 to 2003:e7:17ff:18d8:41d:92ff:fe01:20 (2003:e7:17ff:18d8:41d:92ff:fe01:20), 64 hops max, 60 byte packets
1 2001:4dd0:a2a:74::4acc 7.009 ms 7.615 ms 7.204 ms
2 2001:4dd0:a2b:12d:dc30::c 26.856 ms 2001:4dd0:a2b:12b:dc40::c 7.198 ms 7.241 ms
3 2001:4dd0:a2b:21:dc30::1 7.177 ms 2001:4dd0:a2b:ea:dc31::b 6.771 ms 2001:4dd0:a2b:e9:dc31::b 7.204 ms
4 2001:4dd0:a2b:ea:dc31::b 7.184 ms 2a02:2d8:3:1800:232a:: 7.255 ms 2001:4dd0:a2b:e9:dc31::b 7.467 ms
5 2a02:2d8:3:1800:232a:: 7.215 ms 6.983 ms 7.249 ms
6 * 2a02:2d8::57f5:e0a1 54.564 ms 14.786 ms
7 * 2003:0:1309:4017::1 10.727 ms *
8 * 2003:0:8305:c000::1 10.807 ms *
9 2003:e7:17ff:18d8:41d:92ff:fe01:20 18.326 ms !P 18.483 ms !P 18.214 ms !P
 
~ 6>doas traceroute6 -n -V 7 2003:e7:17ff:18d8:41d:92ff:fe01:22
traceroute6 to 2003:e7:17ff:18d8:41d:92ff:fe01:22 (2003:e7:17ff:18d8:41d:92ff:fe01:22), 64 hops max, 60 byte packets
1 2001:4dd0:a2a:74::4acc 9.985 ms 9.899 ms 10.457 ms
2 2001:4dd0:a2b:12d:dc30::c 7.115 ms 2001:4dd0:a2b:12a:dc40::c 7.239 ms 2001:4dd0:a2b:12b:dc40::c 7.227 ms
3 2001:4dd0:a2b:20:dc30::1 7.184 ms 2001:4dd0:a2b:ea:dc31::b 9.485 ms 2001:4dd0:a2b:22:dc30::1 6.966 ms
4 2a02:2d8:3:1800:232a:: 7.694 ms 2001:4dd0:a2b:ea:dc31::b 7.249 ms 2001:4dd0:a2b:e9:dc31::b 6.984 ms
5 2a02:2d8:3:1800:232a:: 6.931 ms 2a02:2d8::57f5:e0a1 9.487 ms 9.24 ms
6 2a02:2d8::57f5:e0a1 9.951 ms * *
7 * * *
8 2003:e7:17ff:18d8:41d:92ff:fe01:22 18.211 ms !P 2003:0:8305:c000::1 15.195 ms 12.503 ms

~ 7>doas ping6 -n -c 5 -V 7 2003:e7:17ff:18d8:41d:92ff:fe01:22
PING 2003:e7:17ff:18d8:41d:92ff:fe01:22 (2003:e7:17ff:18d8:41d:92ff:fe01:22): 56 data bytes
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:22: icmp_seq=0 hlim=57 time=18.365 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:22: icmp_seq=1 hlim=57 time=19.203 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:22: icmp_seq=2 hlim=57 time=18.704 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:22: icmp_seq=3 hlim=57 time=18.705 ms
64 bytes from 2003:e7:17ff:18d8:41d:92ff:fe01:22: icmp_seq=4 hlim=57 time=18.743 ms
 
Das traceroute6 ist eine gute Idee, hab ich noch nicht probiert.

Code:
# for i in 20 21 22 23 24 25 26 27 28 29
  do
  traceroute6 -m 8 -s 2003:e7:17ff:18d8:41d:92ff:fe01:$i \
    tunnel769899.tunnel.tserv10.par1.ipv6.he.net
  done
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:20, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  6.983 ms  6.513 ms  7.955 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:21, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  9.032 ms  8.408 ms  7.652 ms
 2  *
    dtag-as3320.e0-50.switch2.fra2.he.net  10.128 ms *
 3  * * *
 4  * * *
 5  * * *
 6  tunnel769899.tunnel.tserv10.par1.ipv6.he.net  22.759 ms  22.035 ms  22.203 ms
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:22, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  6.607 ms  6.408 ms  6.750 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  tunnel769899.tunnel.tserv10.par1.ipv6.he.net  17.177 ms  16.804 ms  16.726 ms
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:23, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  7.662 ms  6.507 ms  7.778 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:24, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  7.885 ms  6.743 ms  7.781 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:25, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  8.114 ms  8.580 ms  6.640 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:26, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  7.323 ms  7.194 ms  6.957 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:27, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  7.814 ms  6.925 ms  7.210 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:28, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  10.957 ms  6.804 ms  6.720 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
traceroute6 to tunnel769899.tunnel.tserv10.par1.ipv6.he.net (2001:470:1f12:13::1) from 2003:e7:17ff:18d8:41d:92ff:fe01:29, 8 hops max, 28 byte packets
 1  2003:0:8305:c000::1  7.698 ms  7.707 ms  7.211 ms
 2  * *
    dtag-as3320.e0-50.switch2.fra2.he.net  11.491 ms
 3  * * *
 4  * * *
 5  * * *
 6  tunnel769899.tunnel.tserv10.par1.ipv6.he.net  16.876 ms  17.254 ms  17.207 ms
 
Hab zwischendurch nochmal bei das Telekom angerufen.
Diesmal hat man mir mit stark arabischem Akzent gesagt, dass die Pakete im Internet jetzt von DHL transportiert werden und ich mich an die wenden soll. Telekom ist dafür nicht zuständig.
Was erwartest du von der Privatkundenhotline aus ungeschulten Hilfskräften die 90% des Tages Omas und verzweifelten Müttern erzählen das sie den Router neustarten sollen, eine 0O im Wifi-Kennwort nicht das gleiche sind und sie kein Krebs von der frequenz der Online-LED bekommen
 
Was erwartest du von der Privatkundenhotline aus ungeschulten Hilfskräften die 90% des Tages Omas und verzweifelten Müttern erzählen das sie den Router neustarten sollen, eine 0O im Wifi-Kennwort nicht das gleiche sind und sie kein Krebs von der frequenz der Online-LED bekommen
Das scheint mir der falsche Blickwinkel.
Ich habe zwei DNS-server, die DNSSEC mit continuous-rollover machen, vollautomatisch. Wenn die hälfte der Flows nicht geht, dann bekommt durchschnittlich einer davon keine Key-updates. Und wenn ein autoritativer DNS Server keine gültigen DNSSEC keys hat, dann wird es häßlich. Sehr häßlich. Das mag auch die ICANN nicht.

Das ist Infrastruktur, das wird gebraucht. Die Omas und Alleinerziehenden werden im Internet nicht gebraucht. Die sind ohne genauso glücklich. Die brauchen nur die Geldgeier.

Die Telekom ist der teuerste Provider. Damit nicht genug, sie gieren auch noch nach Geld von meinen Cloud-Hostern, und liefern anderenfalls saumäßige Peerings. Das passt nicht zusammen mit einer "Hotline", die nicht weiss was ein network exchange point ist.
 
Das scheint mir der falsche Blickwinkel.
Ich habe zwei DNS-server, die DNSSEC mit continuous-rollover machen, vollautomatisch. Wenn die hälfte der Flows nicht geht, dann bekommt durchschnittlich einer davon keine Key-updates. Und wenn ein autoritativer DNS Server keine gültigen DNSSEC keys hat, dann wird es häßlich. Sehr häßlich. Das mag auch die ICANN nicht.

Das ist Infrastruktur, das wird gebraucht. Die Omas und Alleinerziehenden werden im Internet nicht gebraucht. Die sind ohne genauso glücklich. Die brauchen nur die Geldgeier.

Die Telekom ist der teuerste Provider. Damit nicht genug, sie gieren auch noch nach Geld von meinen Cloud-Hostern, und liefern anderenfalls saumäßige Peerings. Das passt nicht zusammen mit einer "Hotline", die nicht weiss was ein network exchange point ist.

Bei den Preisen darf man schon ein bisschen was erwarten. Zumal die ja auch kräftige Gewinne einfahren. Da darf von der Hotline schon ein bisschen mehr kommen als von DHL zu faseln. Und wenns nur ein "Ich verbinde Sie mal mit einem kompetenten Mitarbeiter" ist.

Ja, bin ich ja komplett bei euch. Es ist aber imho auch in teilen etwas unrealistisch.
Etwas OT:
Es gibt garnicht den Markt an so Mitarbeitern und einen technisch qualifizierten Engineer an der Hotline für Endkunden zu verbraten der 99% seiner zeit so basic-krams löst ist sicher sogar noch unrealistischer.

Ich fänds toll wenn man irgendwie der Hotline sagen könnte "Ich hab die und die technische Qualifikation, bitte stellen sie mich weiter zu jemand qualifizierteren" oder so.

Und ihr habt absolut recht, das was die Telekom "bietet" ist wirklich unterirdisch, ich gehe sogar soweit das die Telekom eine erhebliche Mitschuld am aktuellen Breitbandausbau-Debakel hat, zusammen mit Vodafone (Dort Kabel-Internet) und das peering-ding ist sogar noch unmöglicher. Die machen mich regelmäßiger sauer.

Man muss aber sagen, es gibt ja auch Business-Tarife wo man technisch qualifiziertere Mitarbeiter bekommt. Da hab ich mit den Telekom-Leuten auch ab und an zu tun und die sind auch nicht "gut" im engeren sinn da von der Service-Standard-Business-Hotline* - aber doch nen ganzes eckchen qualifzierter. Ist dann aber halt auch schnell doppelt so teuer. Und im Privatkundengeschäft unterscheiden sich meiner erfahrung nach die Hotline der Anbieter auch kaum.

*(Ich hab meist mit einer anderen, spezifisch für meinen Arbeitgeber geschalteten Telekom Hotline zu tun, die sind wirklich recht gut, aber das ist nochmal nen ganz anderes Ding)
 
Es gibt garnicht den Markt an so Mitarbeitern und einen technisch qualifizierten Engineer an der Hotline für Endkunden zu verbraten der 99% seiner zeit so basic-krams löst ist sicher sogar noch unrealistischer.
Ja. Deswegen hat man ja normalerweise Support-Level. Die vorderste Front kümmert sich Router-Restart-Omas etc. und das was Know-How erfordert, wird weiter gereicht.

Ich fänds toll wenn man irgendwie der Hotline sagen könnte "Ich hab die und die technische Qualifikation, bitte stellen sie mich weiter zu jemand qualifizierteren" oder so.
Eben. Könnte man ja durchaus machen. Ist nur eine Frage des Wollens. Und die Telekom ist ja nu keine kleine Klitsche.

Und im Privatkundengeschäft unterscheiden sich meiner erfahrung nach die Hotline der Anbieter auch kaum.
Ja. Es nützt also auch wenig, zur Konkurrenz zu gehen.

ich gehe sogar soweit das die Telekom eine erhebliche Mitschuld am aktuellen Breitbandausbau-Debakel hat
Und das ist noch sehr sehr wohlwollend ausgedrückt. In einem anderen Kontext würde man von "erheblicher krimineller Energie" sprechen.
 
*(Ich hab meist mit einer anderen, spezifisch für meinen Arbeitgeber geschalteten Telekom Hotline zu tun, die sind wirklich recht gut, aber das ist nochmal nen ganz anderes Ding)
Ist bei mir auch so. Wir haben einen direkten Ansprechpartner aus dem Geschaeftskundenvertrieb bei der Telekom und bei Vodafone. Der routet dann unsere Anfragen und Probleme direkt zu einem kompetenten Mitarbeiter weiter. Im Privatkundenbereich kann man glueck haben, wenn man direkt in einen Telekom-Shop geht oder jemanden bei der Telekom kennt und diese einem dann einen Kontakt vermitteln.
 
Und das ist noch sehr sehr wohlwollend ausgedrückt. In einem anderen Kontext würde man von "erheblicher krimineller Energie" sprechen.
Ja, da geh ich komplett mit.

Es bringt halt auch echt Kohle.

Wenn du ne Straße mit nur 30 Parteien hast, und da liegt noch dein 40-70 Jahre altes Kupfer Telefon oder 20-40 Jahre altes Koaxial-Fernsehkabel rum und es wird kein Glasfaser neu gezogen, dann hast du da mal schnell 10K einnahmen und nur minimale ausgaben (Etwas strom für den DSLAM, selbigen bei einzeldefekten mal reparieren.)

Das lohnt sich richtig. Bei Glasfaser hast du erstmal nur ausgaben die sich erst nach einigen Jahren rentieren. Und danach verdienst du evlt. auch nicht mehr als vorher. Da ist doch 0 Wirtschaftlicher anreiz da etwas auszubauen.
 
Um nochmal was vielleicht Hilfreiches beizutragen: Problembeschreibungen mit sauberer, gerne auch tiefer Analyse unter https://telekomhilft.telekom.de/ haben eine gewisse Chance an den richtigen Stellen Aufmerksamkeit zu erregen. Nur das leidige Thema "Die Telekom und ihr Peering" ist da nicht besonders gerne gesehen, am besten nicht erwähnen.
 
Zum Stand der Dinge: bislang keine Besserung.
Ich habe, ein paar Vorschlägen im englischen Forum folgend, noch die Netzwerkkarte und (m.o.w.) das OS ausgeschlossen - also mal nur meinen Laptop an den Router gehängt, und dann mal den Router tatsächlich routen lassen und nicht nur bridgen (also dass der Router selber das ppp und rtadv betreibt) - beides keine Änderung.

Um nochmal was vielleicht Hilfreiches beizutragen: Problembeschreibungen mit sauberer, gerne auch tiefer Analyse unter https://telekomhilft.telekom.de/ haben eine gewisse Chance an den richtigen Stellen Aufmerksamkeit zu erregen.
Das ist eine sehr gute Idee, nur leider ist die Telekom-Hilft-Community seit 15.12. wegen Renovierung geschlossen (nur noch readonly), keine Ahnung wie lang.

Es ist tatsächlich so, dass man dort kompetente Antworten in technischer Hinsicht bekommen hat, auch zB zur Konfiguration von Hardware, die nicht bei der Telekom gekauft ist, und ähnliches mehr. Andererseits ist das ja im Grunde ein Forum wie dieses hier, wo User sich gegenseitig helfen. Niemand fragt ob man tatsächlich Kunde ist, und der Support seitens Telekom ist m.o.w. auf best-effort basis. Also einerseits funktioniert das Konzept und liefert Ergebnisse (wie es solche Modelle generell tun), andererseits ist es nicht gerade das, was man als (etwas altmodischer) Kunde von seinem Lieferanten erwartet.

Nur das leidige Thema "Die Telekom und ihr Peering" ist da nicht besonders gerne gesehen, am besten nicht erwähnen.
Das ist eine interessante Stanza, die Du da formulierst. Das wusste ich so noch nicht.

Ich denke, die Telekom hat da ein strukturelles Problem. Traditionell gab es Störungen nur auf der Strecke vom Kunden zum Fernmeldeamt, und dafür gibt es die Störungsbearbeitung. Was im und zwischen den Fernmeldeämtern passiert, davon hat der Kunde kaum etwas erfahren, das braucht ihn nicht zu kümmern, und dafür gibt es Abteilungen mit Spezialisten, die keinen Kundenkontakt (ausser Großkunden) haben.
Im Internet ist das nicht mehr ganz so, da interessiert den Kunden nicht nur, wieviele MBit Videos er herunterladen kann, sondern -sobald er irgendetwas eigenes macht- auch, wie stabil die Verbindung zu seinem Cloud-Hoster ist.

Dann das Thema Peering generell - ich werde da ganz ehrlich nicht schlau draus. Was ich zu lesen bekomme, verstehe ich größtenteils nicht; das ist ein Fach-Slang eigener art. Einerseits ist da sehr anspruchsvolle Technik im Einsatz, mit der ich leider nie etwas zu tun hatte (auch wenn ich den restlichen IT-Stack recht gut zu kennen meine),
andererseits gibt es da offenbar eine Szene mit ihren ganz eigenen Spielregeln.
Nun habe ich jahrelang Consulting für Banken gemacht, und das ist auch eine Szene mit ihren ganz eigenen, sehr distinguierten Spielregeln. Und bei denen es meistens um viel Geld geht.
Beim Peering dürfte es auch um viel Geld gehen (wenn man überlegt was zB eine TATL-Leitung etwa kosten mag), aber es schlüsselt nicht. Wenn man sich zB die Website von HE anschaut (die behaupten, sie seien der weltgrößte Transit-Provider), dann ist das eine schnodderig aufgesetze (aber gut funktionierende) Seite, wie sie auch von einer Hobbyklitsche sein könnte (nichteinmal https wird erzwungen): http://he.net
 
Auch wenns nichts mit dem Thema zu tun hat (A kein OpenVPN mehr, nur noch WG, B ipV6 nur wenns nativ kommt): In Ö finde ich den "Support" der deutschen Telekom toll, da er immer noch um längen besser ist, als der, der Ö Telekom.. Damit ihr mal wisst, was wirkliches Leid bedeutet :D
 
hi

beim peering geht es um geld , um sehr viel geld ... telekom macht nicht an der stelle ohne das sie nicht
einen mehrwert davon hat , sie sind der größte peering knoten in D und einer der größten in EU.

Zahlst du zuwenig wird der traffic über die leitung runter prorisiert , was da zum nachteil deiner kunden ist
weil deren dienste schlechter / langsamer erreichbar sind.

wer glaubt das internet provider / hoster nicht in den traffic eingreifen ist naiv.

holger
 
Und die Telekom ist dabei radikal. Zahlt jemand nicht, gibt es kein direktes Peering und zu Stoßzeiten geht es dann halt in die Congestion. Für mich war das beim letzten Umzug Grund genug nach bestimmt 20 Jahren T-DSL auf den Glasfaseranschluss in der neuen Wohnung nicht wieder die Telekom zu buchen, stattdessen mit Willy Tel einen lokalen und inzwischen sogar kommunalen Provider zu nehmen. Seitdem funktionieren Dinge einfach. FreeBSDs Mirrors sind schnell, die Myriaden Dienste hinter AWS funktionieren auch Sonnabend Abend um 18 Uhr anständig, keine ewigen Probleme mit Cloudflare... Was nicht heißen soll, dass ich mit der Telekom unzufrieden war. Gemessen an den technischen Möglichkeiten von DSL über erst >2 Kilometer Überlandleitung und später im 4. Stock im Altbau von 1974 funktionierte es immer gut und der Support war nicht ganz so übel wie der Konkurrenz. Aber das Peering nervte halt.
 
Zurück
Oben