Das waere IMHO ein klarer Fall fuer eine Stoerungsmeldung beim ISP und wenn der nicht reagieren sollte dann wuerde ich da auch die BNetzA einschalten. Wenn das nicht beabsichtigt ist (was ich erwarte) duerfte der ISP das Problem schnell beheben, und sollte das wieder Erwarten Absicht sein, vermute ich, will die BNetzA mit Deinem ISP sprechen...
Beiträge von pufferueberlauf
-
-
Zumindest im "Access 4.0 (A4)" Projekt der Telekom wird versucht unabhängiger zu werden, betrifft jedoch nur BNG und geht einher mit Leistungsverdichtung und Reduktion der BNGs von 1700 auf unter 1000 in Deutschland
Ich meine die Wahl fuer die Hardware fiel erst mal auf die Adtran SDX 6000er Serie, interessant dass da Huawei auftaucht.
<OT>
Auch die Zahlen 1000 und 1700 finde ich interessant, bei ca. 900 BNG Standorten... bisher betreibt die Telekom ca. 25 Millionen Leitungen:
25000000/1000 = 25000 Kunden pro BNG. bei maximal 32 Kunden pro OLT macht das im Vollausbau mindestens 25000/32 = 781.25 OLTs pro BNG, das maximum pro SDX 6000 ist wohl 48 OLTs, also (25000 / 32) / 48 = 16.3 SDX chassis pro BNG
Das braucht dann 17*2.5 = 42.4 Hoeheneinheiten in Racks das passt (fast) in ein einzelnen 42RU 19-Zoll-Schrank... (das wird bestimmt nicht so dicht verbaut werden, aber der notwendige Platz sollte eigentlich ganz gut in die exitierenden BNG Standorte passen).
</OT>
-
Brauchst Du für mich nicht, ich habe den Vergleich über DGN.
Habe ich trotzdem getestet, war interessant zu sehen wie das Telefonica/O2 Routing im Vergleich arbeitet... ziemlich problemlos, trotz der relativ grossen RTT zu den Servern in Chicago.
Aber Telefonica weiss halt, dass sie in D zu wenige Kunden hat um solche Spiele spielen zu koennen
-
Ich leider schon, packages.linuxmint.com ist bei mir dauerhaft betroffen.
AS11878 kein direkter Pfad zur Telekom, nicht bei tzulo selber noch bei deren IPv4 Providern (hier AS46844 (SHARKTECH) und dann AS3257 (GTT-BACKBONE))... also exakt der Fall um den es geht beim vorsaetzlichen Unterpeering.
Werde heite abend zur Spitzenzeit mal Daten von O2 zum Vergleich posten...
-
Unter den Telekom-Resellern ist O2 recht attraktiv:
Pro:
echter Dualstack (IPv4/IPv6)
gutes Peering (d.h. keine bekannten sauerhaften Peeringengpaesse zu bestimmten Zielen)*
Contra:
Zwangstrennung der PPPoE Verbindung alle 24 Stunden
Routing immer erst mal zum zustaendigen O2-POP (gibt es ein paar in Deutschland und bei welchem man landet haengt von der Netzwerkdistanz ab, ich wohne zwischen FFM und HH, etwas naeher an FFM, werde aber ueb der PoP in HH angebunden). Das heisst O2 kauft L3-Biststromzugang bei der Telekom (L3/IP-BSA).
*) War auch mal bei der Telekom, da konnte ich das vorsaetzliche Unterpeering zu den grossen Transitanbietern zwar messen, aber in meiner normalen Nutzung fiel mir das nicht auf, d.h. ja das Unterpeering ist real aber betrifft die Kunden unterschiedlich stark.
-
dass EDT verwendet wird
Dann duerfte MSS clamping aussichtslos sein, das greift momentan nur bei TCP... und EDT baut auf UDP auf...
-
Die Frage ist warum hakt es, ich stimme Dir zu, da sieht erst mal nicht aus wie packetverlust (aber vielleicht Zeit einen der langsamen Transfers mit tcpdup/wireshark aufzuzeichnen und dann mal the tcptrace plot anschauen). Ein Punkt kann sein, dass wireguard ueber UDP geht, waehrend Deine Transfers eher TCP nutzen duerften....
-
Kannst Du die MTR tests noch zweimal wiederholen, aber ueber laengere Zeit gemessen (z.B. 100 Sekunden)?
A) mit Last in Client -> Hetzner Richtung
B) mit Last in Hetzner -> Client Richtung
-
-
Jein, die Googler sind recht deutlich, die haben befuerchtet, dass Mobil-Carrier in uebernahme alter IPv4 Konzepte Android-Smartphones nur ein /128 zuweisen wuerden und wollten genau das verhindern... (zusaetzlich scheinen die auch SLAAC Fans zu sein). So doof ich das im eigenen Netz finde, ich wuerde mich nicht wundern wenn Google/Android da richtig lag in der Einschaetzung...
-
Dagegen gibt es doch die Privacy Extensions. Du hast dann neben der abgeleiteten die temporäre IPv6-Adresse, welche per Standard genutzt wird. Wobei ich das für die öffentliche IPv6-Adresse garnicht im Sinne hatte. Verstehe aber gut, was du meinst.
Privacy Extensions sind in der Tat ganz nuetzlich, nur halt nicht wenn man selber Dienste anbieten will, und gerade da finde ich es besser nicht die MAC Adresse des Ethernetadapters in die Welt zu posaunen. Aber auch das ist letztlich kein Beinbruch.
Was iOS und Android angeht, weiss ich nur Android akzeptiert keine per DHCPv6 zugewiesene Adressen, und vermute als Root user kann man auch manuell eine Adresse festsetzen, aber dafuer muss man erst die root Rechte erlanen. Bei iOS wette ich mal, sollte DHCPv6 funktionieren...
Ach ja, EUI-64 als ULA ist unkritisch weil lokal kann man die MAC meist sowieso irgendwie sehen (zumindest in packet-captures).
-
Achsooo. Du meinst also ein statisch vergebener Interface Identifier auf dem Client. Du meinst dann sowas wie z.B. "ip token set ::AA:BB:CC:DD/64 dev eth1" (Gibt vielleicht ja noch andere Wege, nur als Beispiel gemeint)
Ja genau. Oder auch per DHCPv6 vom Router vergeben wenn einem das lieber ist und das Client OS das akzeptiert...
Was ist daran naiv? (Ernstgemeinte Frage) Ich weiß, dass irgendein RFC EUI64 als deprecated erachtet, meine ich.
Die Idee, dass es eine gute Idee waere eine EInzigartige Hardware ID mit der WEelt zu teilen... Wenn man das z.B. mit dem eigenen Notebook macht ergibt das ein 1A Tracking-Token das funktioniert egal in welchem (IPv6) Netz man sich mit dem Laptop eingelogt hat. Ein Traum fuer Werbetracker... und naiv finde ich, dass die IPv6 macher noche alle vom Guten im Internet ausgegangen sein mussten, dass ihnen diese Missbrauchssart gar nicht in den Sinn kam. Waren wohl noch unschuldigere Zeiten

-
Lass mal trippy mitlaufen wenn Du spielst (auf die Adresse vom CS Server)... allerdings sind viele Spieleserver so eingestllt, dass Sie Pakete droppen, d.h. Du siehst 100% PL
-
Gibt einen neuen Kandidaten fuer traceroutes: trippy
Codetrip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare www.heise.deMit ctrl-f friert man das Bild ein um z.B. eine Copy zu machen oder eunen Screenshot, mit c Schaltet man zwischen dem Listenmodues (wie MTR) und einer graphischen Darstellung der Latenzen aller Hops um (wie bei gping). Das einzige was etwas unschoen ist, ist die resultate hier rein zu pasten...
Code
Alles anzeigenuser@123-1234567 ~ % trip -C 10 --mode markdown --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --dns-resolve-method cloudflare www.heise.de | Hop | IPs | Addrs | Loss% | Snt | Recv | Last | Avg | Best | Wrst | StdDev | |-----|---------------|-----------------------------------------------------|-------|-----|------|------|------|------|------|--------| | 1 | 192.168.42.1 | 192.168.42.1 | 50.0 | 10 | 5 | 0.4 | 0.5 | 0.4 | 0.7 | 0.1 | | 2 | 62.52.192.112 | lo0-0.0002.prrx.01.hid.de.net.telefonica.de | 0.0 | 10 | 10 | 12.0 | 12.4 | 10.9 | 17.7 | 1.5 | | 3 | 62.53.11.176 | gi3-11.03.xmwc.99.nue.de.net.telefonica.de | 0.0 | 10 | 10 | 11.3 | 11.0 | 10.2 | 11.7 | 0.4 | | 4 | 62.53.6.180 | bundle-ether3.0003.corx.01.ham.de.net.telefonica.de | 0.0 | 10 | 10 | 18.6 | 18.5 | 17.1 | 20.0 | 0.7 | | 5 | 62.53.0.35 | ae6-0.0001.corx.01.off.de.net.telefonica.de | 0.0 | 10 | 10 | 20.3 | 19.0 | 17.8 | 20.3 | 0.7 | | 6 | 62.53.28.149 | bundle-ether2.0001.cord.02.fra.de.net.telefonica.de | 0.0 | 10 | 10 | 17.9 | 17.9 | 17.4 | 18.9 | 0.4 | | 7 | 62.53.10.51 | bundle-ether1.0002.corp.02.fra.de.net.telefonica.de | 0.0 | 10 | 10 | 18.6 | 18.4 | 17.7 | 19.3 | 0.4 | | 8 | 80.81.192.132 | ipv4.de-cix.fra.de.as12306.plusline.net | 0.0 | 10 | 10 | 17.8 | 18.3 | 17.7 | 19.5 | 0.5 | | 9 | 82.98.102.7 | 82.98.102.7 | 0.0 | 10 | 10 | 17.7 | 18.0 | 17.3 | 19.0 | 0.5 | | 10 | 212.19.61.13 | 212.19.61.13 | 0.0 | 10 | 10 | 17.5 | 17.6 | 16.8 | 18.5 | 0.4 | | 11 | 193.99.144.85 | www.heise.de | 0.0 | 10 | 10 | 18.1 | 18.1 | 17.6 | 18.9 | 0.4 | -
Ich habe einige 7590 laufen, und bisher noch bei keiner ein WLAN-Sterben erlebt.
Ich habe auch noch zwei Neue 7590 auf Reserve.
Für "Mich" immer noch die beste Box auf dem Markt.
Das sagen die Mitarbeiter von ISPs gerne, aber das BGB und die Urteile sind da eindeutig, verlangt der ISP Schadenersatz dann erlischt sein Anspruch auf Ruecksendung, der Router geht damit ins EIgentum des Kunden ueber. Ist z.B. auch bei Kabelroutern so, nur werden die dann nicht mehr Provisioniert...
-
Ich meine die duerfen nach einen relativ frischen Urteil nur den Zeitwert der Hardware berechnen, aber wenn Du da keinen Stress willst, wuerde ich das Ding zurueckschicken...
-
Mmmh, vielleicht IPv4/IPv6 Connectivity Probleme zusammen mit Happy-Eyeballs?
-
Naja, https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.1 nennt die explizit " Interface Identifiers" daher habe ich das auch getan. Heutzutage darf man die befuellen wie man moechte, also z.B. auch einfache IIDs wie "::1" (ja, da fehlt das Prefix) man muss halt sicherstellen, dass die lokal einzigartig sind. Aber SLAAC (zufaellige selbstzuweisung) oder EUI64 sind auch Optionen. (Siehe auch https://datatracker.ietf.org/doc/html/rfc7136 und https://datatracker.ietf.org/doc/html/rfc7721)
Persoenlich halte ich EUI64 fuer zu naiv, aber jeder wie er/sie moechte.
-
Hatte auch mal so ienen ISP, allerdings konnte man da die Ruecksetzung ueber eine Webseite selber anstossen, zumindest solange man noch eines der registrierten Geraete hatte

-
Na, auf dem Hoist der als Server dienen soll muss man schon manuell einen (gerne auch nur zusaetzlichen) festen IPv6 Interface-Identifier konfigurieren... damit braucht man dann nicht mehr den Umweg ueber die (ebenfalls nicht invariablen) MAC Adressen gehen zu muessen. Aber das hilft halt nur wenn die Firewall erlaubt Praefix-Bits zu ignorieren...