Beiträge von pufferueberlauf

Zitat von Edding

Andere Länder zeigen schön das es selbst mit 64er Splits funktioniert jedem Kunden die volle Kapazität in einem XGS-PON netz zur Verfügung zu stellen.

Jain, in anderen Laendern gibt es oft auch nur wenig belastbare vertragliche "bis zu" Zusagen... im Gegensatz zu den Werten im Produktinformationsblatt, die belastbare Zusagen machen deren Einhaltung mit den Tools der BNetzA ueberprueft werden kann und (deren Nicht-Einhaltung) zu Minderungs- oder Kuendigungs-Anspruechen fuehren kann...

Soll heissen anderswo ist es weniger wichtig ob ide beworbenen 10Gbps auch tatsaechlich beim Kunden ankommen... Ist bei uns halt anders, und im UK auch, da wird i.d.R. mehr geschaltet als beworben, anderswo halt mehr beworben als geschaltet

Zitat von Edding

Das es bei DOCSIS immer wider mal zu Problemen kommt ist der Größe geschuldet wo sich gut und gerne mal +-1000 CPE in einem Segment befanden.

Vodafone scheint momentan zu splitten wenn Segmente im Mittel 500 Anschluesse haben.

Zitat von e16

In Asien läuft GPON auch mit 128er Splits.

Asien ist ein Kontinent mit so vielen unterschiedlichen Laendern mit jeweils unterschiedlichen Implementationen, dass es IMHO immer problematisch ist davon auszugehen, als sei Asien eine homogene Gruppe... (da ist Europa detlich homogener, aber schon hier wird oft in West- und Ost-Europa getrennt).

Jain... momentan ist es so, dass einzelne Anschluesse im Mittel waehrend der Primetime etwa eine Durchschnittslast von 10 Mbps in Downloadrichtung erzeugen (in Uploadrichtung eher nur 2 Mbps) und da hat GPON mit realistisch nutzbaren 2.2/1.1 Gbps (immer noch brutto) ausreichend Reserven und auch kurze gleichzeitige Burst der Nutzer mit akzeptabler Latenz auszuliefern. Aber das haengt von den Nutzern im Segment ab... wenn da bei Dir 3 Torrent Spezialisten sitzen die staendig die Leitung am Anschlag halten kann es auch heute schon eng werden, aber sonderlich wahrscheinlich ist das nicht...

Mmmmh, beim MTR gegen dns.google ist es eigenartig, dass der Worst Wert mit 15 ms nur knapp ueber dem Durchschnitt liegt und weit unter den mehreren 100 der meisten andererr Hops. Das passt nicht ganz zu einer simplen CG-NAT Gateway Erklaerung, andererseits zeigt es auch, dass Dein Computer und Dein Router wohl auch nicht an den Verzoegerungen schuld sein sollten.

Ich denke Du wirst nicht um IPv6 Tests, bzw. IPv6 VPN Tests rum kommen aber selbst dann ist es IMHO unwahrscheinlich, dass Deine Meldung bei den richtigen Mitarbeitern der DG ankommt. Wuerde mich freuen, wenn Du Dich nach Wechsel zu VF hier noch mal mit neuen Traces melden wuerdest... vielleicht weckt so ei Post ja Neugierde bei der DG Technik wenn denn VF das Problem nicht aufweist.

Oder Du trennst Modem vom Router und Router vom AP, und SIP-Basis vom Router, dann kannst Du auf jeder Position jeweils optimieren... (aber in der Summe wird das eher teurer als ein All-in-one und duerfte wohl auch mehr Strom verbrauchen). Die Herausforderung bei diesem Ansatz ist, dass es reine Modems nur noch selten gibt, und wenn sind das meist Router die sich Dumm-stellen koennen

(Ich habe z.B. eine FB7520 als bridged-DSL Modem laufen, die musste ich erst ueberzeugen sich dumm zu stellen, und das ging auch nur gut, weil die 7520 unter OpenWrt mit DSL betrieben werden kann, und damit lassen sich Interface schnell bridgen.)

Zitat von wandler

Bei wechselndem Präfix wird eh neu nummeriert, was für einen Unterschied macht es da, wenn der Interface-Identifier dann sich auch ändert?

Easy, ich meine ich hatte das bereits erwaehnt, ich moechte nicht alle 224 Stunden meine Firewallregeln anpassen, und schon gleich gar nicht will Gruetze wie UPNP/PCP auf meiner Firewall aktivieren.

Zitat von wandler

Discovery läuft eh über mDNS, DynDNS o. ä. und mit zufällig abbrechenden Sessions muss jeder Dienst für Privatkunden sowieso klar kommen.

Ja, aber das ist nicht mein Problem.

Zitat von wandler

Mit Zero Trust networking macht niemand "Löcher in die Firewall". Und wer noch ein anderes Modell als Zero Trust hat, hat eh viel größere Probleme.

Mei, Dein Netz, Deine Regeln, mein Netz meine Regeln... Ich gehe nicht davon aus, dass mein Heimnetz ein sicherer Ort ist und aktiviere bei allen System die individuellen Firewalls, dennoch betreibe ich auch eine Firewall im Internetgateway... Zwiebelprinzip und so. Musst Du weder gut finden noch nachvollziehen koennen...

Was passiert wenn Du auf das blaue "Ändern" hinter der 1000/500 Anzeige klickst?

Ach ja, auch wenn es bisher kein RFC geworden ist, Ubuntu/Linux unterstuetzt das natuerlich:

Ubuntu Manpage: ip-token - tokenized interface identifier support

Jain, bei IPv4 ist NAT44 die Regel nicht die Ausnahme, d.h. die Firewall-Freigabe fuer interner Server-IPs und Ports bleibt unberuehrt von IP-Renumbering... Klar dynamisches DNS funktioniert sowohl bei IPv4 als auch bei IPv6, aber dann muss man jedesmal nach Prefixchange die IPv6 Freigabe fuer die Server GUA anpassen* und das ist IMHO Gruetze. Die "Loesung" die F. Gont da vorschwebt ist PCP also dem Server erlauben selber neue Loecher in die Firewall zu machen, aber IMHO ist PCP (und UPNP) eine schlechte Idee fuer IPv4 oder IPv6...

*) OpenWrt kann Freigaben anhand der IID festlegen, so dass das Prefix ignoriert wird und solche Freigaben daher Renumbering einfach ueberleben.

Zitat von ::1

Das sehe ich nicht so. Ich unterstelle der IETF keine (durch welche Zielvorstellungen auch immer begründete) Agenda, mit der sie "Nutzer umerziehen" will. Schon gar nicht die Idee, ULA am CPE-Router via NPTv6 (RFC6296, falls du das mit "NET66" gemeint hast) auf GUA zu übersetzen. Btw.: Die Bedeutung des mir bisher unbekannten Begriffs "Bike-Shedding" musste ich erst mal nachlesen, danke für das Schließen dieser meiner Bildungslücke.

Oh, ich lese die IPv6 discussions listen der IETF (zumindest einige) Nutzer umerziehen ist da sehr wohl ein Bestreben zumindest von einigen (unter anderem dem Autor von RFC7217), manchmal aus guten Gruenden, manchmal aus weniger guten Gruenden.

Na ja, ich meint den Austausch des Prefixes per NAT, fuer mich ist das ein Spezialfall von generellem NAPT. Und nein diese Form von NAT66 ist nichts was die IETF sehen moechte, IMHO ist das eine Konsequenz daraus, dass die IETF seit Jahren einige (ihr selbst) offensichtliche IPv6 Probleme nicht ordentlich geloest hat (Hotfail zwischen verschiedenen IPv6 Uplinks, bei denen die IPv6 Routen eines ploetzlich verschwundenen Links noch lange in den Endpunkten aktiv bleiben und genutzt werden was zu Konnektibvitaetsproblemen fuehrt, NAT66 ist da eine echte Loesung wenn auch weder elegant noch im Geiste von IPv6).

Zitat von ::1

Es sollen nur temporäre IPv6-Adressen (IPv6 privacy extensions) gemäß RFC8981 verwendet werden, weil das Gerät keine Services anbietet, also ausschließlich als Client genutzt wird. Eine permanente/stable IPv6-Adresse wird nicht benötigt. Zielgruppe: Vor allem mobile, drahtlose Endgeräte, die sich zu wechselnden WLANs verbinden.

Jai, eine ULA waere schon schoen da stimmen wir ueber ein... aber hier geht es um ULAs?

Zitat von ::1

Man möchte ausschließlich oder zusätzlich zu temporären Adressen auch permanente/stable IPv6-Adressen verwenden (muss einstellbar sein), weil das Endgerät auch (bzw. hauptsächlich) Services anbietet. Hier sollte man dann wählen können, welche Methode zu ihrer Generierung zum Einsatz kommen soll: Man sollte die moderne Methode gemäß RFC7217 wählen können (Zielgruppe: Server in IPv6-Netz mit festem IPv6-Präfix) oder auch weiterhin auf die Ur-Methode "Modified EUI-64" (Anhang A in RFC4291) zurückgreifen können (Zielgruppe: Server in IPv6-Netz mit wechselndem ISP-Präfix).

Auch hier Jain...ich bin da mehr ein ein Fan von https://datatracker.ietf.org/doc/id/draft-c…ntifiers-02.txt RFC7217 und Modified EUI-64 sind IMHO beide fuer Heimnetze nicht gut geeignet.

Zitat

Die Motivation, Serverdienste in SOHO-Netzen an ISP-Privatanschlüssen möglichst zu unterbinden, liegt eher bei den ISP. Denn die möchten dafür gerne ihre deutlich höherpreisigen Business-Tarife mit festem IPv6-Präfix verkaufen.

Das werfe ich der IETF auch gar nicht vor, deren Ziel ist da echte end2end Kommunikation, also natuerlich auch das Anbieten von Diensten/Servern.

Zitat von ::1

Schließlich noch zu "lokal mit stabilen ULAs arbeiten": Das nutze ich zusätzlich in meinem LAN seit eh und je, ist doch sehr sinnvoll, sich für die rein LAN-interne Kommunikation wenigsten darauf verlassen zu können, wenn der ISP mal wieder den GUA-Präfix wechselt oder ggf. auch mal gar keinen liefert (das soll bei DG ja ab und zu mal vorkommen).

+1

Vielleicht Corning Clear Track?

Ich war wohl zu subtil und vorsichtig, ich bin kein Fan von RFC7217 weil ich nicht glaube, dass es richtige Problem loest...

Zitat

since temporary addresses [RFC4941] do not eliminate the use of fixed identifiers for server-like functions, they only partially mitigate host-tracking and activity correlation across networks

Das ist fuer den Fall um den es hier geht ein "stabiles" Netz mit haeufig wechselndem Prefix halt nicht die richtige Loesung... die Grundannahme ist, wenn das Prefix wechselt, wechselt das Netz und das macht in Heimnetzen halt fuer Serverdienste nur wenig Sinn.

Was die IETF damit foerdert ist dass Endnutzer GUAs ignorieren, lokal mit stabilen ULAs arbeiten und diese dann mit NET66 mit dem jeweils aktivem Prefix versehen... Aber gerade bei den IPv6 RFC sehe schon mal Bike-Shedding und Versuche Nutzer umzuerziehen.

In der GUI kann man nur die ganze IPv6 Adresse manipulieren. Ob das Praefix beim Renumbering automatisch angepasst wird habe ich nicht ausprobiert, der Rest meiner Familie ist kein Fan von vermeidbaren Netzwerkunterbrechungen waehrend des WEs

Persoenlich bin ich kein Fan von RFC7217 zumindest nicht im Kontext von Heimnetzwerken mit haeufigem Prefix-Wechsel, aber vielleicht ist mir nur nicht klar welches Bedrohungsmodell dem RFC zugrunde liegt.

Unter macos (gestestet mit 15.5) kann man die IPv6 auch manuell setzen, dann verschwinden allerdings die privacy extension Adressen sofort, und ich habe nicht getestet was bei einem Praefix-Wechsel passiert.

Ich wuerde ja naiverweise erwarten, dass ein ISP so etwas in seiner Schnittstellenbeschreibung dokumentieren muesste... aber ich vermute, die BNetzA duerfte das anders sehen...

Der Arm A9 ist ein erstaunlich gutes Design... ja, "nur" 32bit aber ziemlich punchy und oft besser als der 64bit A53. Der typische Unterschied zwischen der Performance (Out-of-order A9) und der Efficiency Kategorie (in-order A53) von Arm Kernen halt...

Wuerde niemandem empfehlen heute noch eine Omnia zu kaufen (zumindest nicht vor der Einfuehrung des neuen Models)

Mal als Beispiel wie gut sich der A9 gegen den A53 schlaegt: (Quelle hier

Also der SFP-Kaefig der Omnia unterstuetzt bis zu 2.5 Gbps... aber nicht mit jedem Modul...

Schau mal hier:

Supported SFP modules [Turris wiki]

Zitat

SFP⚓︎

All of those, which fulfill the SFP standard, work on 100Mbps / 1Gbps / 2.5Gbps / SGMII. Some others work, too, despite not fulfilling the standard, if supported and worked by the Linux kernel.

We manufacture our own Turris SFP+ Copper module (RJ45) supported under Turris OS.

Du solltest in der Lage sein den SFP Port einfach mit einem der LAN ports zu bridgen... dann dient die Omnia letztlich nur ein fancy Medienkonverter

Zitat von n1ete

Ansonsten habe ich noch einen Turris Omnia (openwrt) mit sfp port hier rumfliegen...evtl werde ich diesen als dediziertes dmz/modem gerät verwenden, bin mir aber nicht sicher ob ich mit der ARM CPU 1Gb ausreizen kann.....

'Haengt davon ab was Du machen moechtest... SQM mit bidirektionalem Traffic ist beim Omnia bei ca. 500 Mbps am Ende, aber normales Routing/firewalling sollte bis ca. 1 Gbps skalieren.

Zitat von mbo77

Hier kannst du dir ein unabhängiges Bild über die Leistungen der Provider machen: https://www.connect.de/vergleich/fest…st-3206265.html

Zur Qualitaet des Connect Tests habe ich einige Bemerkungen gemacht:

Thema

Kommentar zum Crowdsourcingteil des Connect Festnetztests (2024)

Mmmmh, hier die Beschreibung des Crowdsourcing Teils des Connect Tests:

https://www.connect.de/vergleich/fest…06265-9989.html

Das ist letztlich ein WLAN Test:

[…]

Das ist schlimmer/schlechter als ich gedacht hatte...

a) "So werden zum Beispiel auffällig langsame Anschlüsse ausgefiltert" das ist ein naheliegender Gedanke, aber wenn es um Durchsatzmessungen geht, dann darf mann so eine Filterung nicht basierend auf dem Kriteriumn Durchsatz vornehmen, sondern braucht zusaetzliche Kriterien, ansonsten…

pufferueberlauf

5. Januar 2025 um 12:41

Und zur Frage wie man der Peering/Uebergabe-Qualitaet eines ISPs auf den Zahn fuehlen kann hier:

Thema

Peering/Transit - wie gut verbindet Dein ISP Dich mit dem Rest des Internets

Liebes Forum,

Transit/Peering/Interconnect ist ein Thema das letztlich fuer alle ISP unabhaengig der Zugangstechnologie theoretisch relevant ist. I.d.R. ist der Zustand des Interconnects bei vielen ISPs befriedigend bis gut, so dass man da praktisch wenig Gedanken dran verschwenden muss. Aber nichts desto trotz ist das einer der Punkte in dem sich ISP unterscheiden und daher ist es hilfreich das selber fuer den eigenen ISP abschaetzen zu koennen.

Erst mal zur Terminologie, Peering bezeichnet…

pufferueberlauf

17. April 2025 um 11:44

Tl;dr: Der Zweck des Connect Test ist IMHO hauptsaechlich, dass Connect auf Basis nominell objektiver Kriterien Gewinner praesentieren kann; man sollte sich die Kriterien genau ansehen bevor man die Gewinner der Connect fraglos als "beste ISPs" akzeptiert.