Oder du stellst auf 1und1 und das VLAN wird (für dich nicht sichtbar) auch auf VLAN 7 gestellt.
Mmmh, das ist so eine Zwitter-Loesung:
Ja, schoen dem Endkunden das Einstellen des VLAN Nummer abzunehmen.
Nein, die automatisch gewaehlte VLAN-Nummer gar nicht mehr anzuzeigen ist nicht optimal und laesst den Nutzer im Unklaren.
Ja, muss man halt entscheiden ob man den Mobilfunkmarkt als effizient ansieht, oder nicht. Persoenlich faellt es mir schwer da Hueh oder Hott zu sagen, ich finde den Wettbewerb jetzt nicht so prickelnd, aber komplett versagt er halt auch nicht...
Aber ganz realistisch 3-4 unabhaengige Fasern werden im Festnetz nur die aller wenigsten zur Auswahl haben... (und beim Mobilnetz sieht man ja auch, dass die Anbieter eigentlich zufrieden sind, weitere Atnennenstandorte auf dem Land kommen eher langsam und zoegerlich, weil die vollmundige Zusagen gemacht haben die sie irgendwann erfuellen muessen).
Das war allerdings weniger Anfang der 1980er Jahre...
Und wie immer in diesem Fall: Da kann sich der Kunde ein Ei drauf backen und einige Jahre nicht angerufen werden, bis er das durchgesetzt hat. Paragraphenhengst vs. Lösung.
Stimme Dir in so weit zu, als man da zweigleisig fahren sollte... nur auf die BNetzA zu setzen bevor man alle Dinge ausprobiert hat die man sinnvoller Weise probieren kann ist nur fuer Leute mit vieeeeel Geduld eine Option. 
Wenn ich das in der Box abschalte, ganz sicher. Und das kann der Provider nicht wissen, da er die Daten bei Vertragsabschluß zu liefern hat und überhaupt nicht wissen kann, welches Endgerät ich einsetzen werde!
Jain, wenn direkt ein Mietrouter beauftragt wurde, kann der ISP zumindest der BNetzA gegenueber argumentieren, er wuerde sich per Fernwartung um die Details kuemmern. Vor einigen Jahren hatte z.B. die Telekom bei Mietroutern argumentiert TR069/369 duerfe gar nicht deaktiviert werden.... (aber das ist laaaange her, keine Ahnung wie das heute gehandhabt wird).
Wenn ich mich richtig erinnere ist bei Telcos Glasfaser zuerst im Backbone-Netz verwendet worden...
Wenn da durch home-passed/connected zu homes-activated wird würde ich sagen klares ja.
Aber der Preis darf dadurch halt nicht steigen.
Aus Endkundensicht, klar. Aber da es die ISPs sind die Geld in die Hand nehmen muessen fuer den Ausbau, werden die den Ausbau halt zu ihren Gunsten optimieren. Mr ging es um die Fragen die ein ISP mit den ihm, durch normales Monitoring vorliegenden, Nutzungsdaten seiner Kunden beantworten kann.
Das kommt wiederum darauf an wie die Hoheit des Netzes das interpretiert.
Engpass in form eine Anwendung funktioniert nicht oder Zeitersparniss beim Bulk Transfer.
Mein Punkte sollte sein, ein ISP kann genau wissen welche seiner Kunden z.B. zur Spitzenlastzeit haeufiger ans Down- oder Upload Limit gehen und kann daraus schliessen wie viele Kunden tatsaechlich hoehere Kapazitaeten spueren wuerden (und auch welchen Kunden man Informationen ueber breitere Tarife schicken koennte).
Mmn haben die viel zu viel zu melden auf ihren Monopolnetzen.
Mei, das mit dem ueber das eigene Eigentum grosse Kontrolle zu haben ist ja ueblich in unserem Wirtschaftssystem... was die Monopolstellung angeht, da fordert die BNetzA ja gerade neue regulatorische Handhabe... Wird halt auch dem Regulierer klar, dass selbst ein extrem optmistisch interpretierter Infrastrukturwettbewerb mindestens zwei aehnlich leistungsfaehige Netze braucht (realistisch mehr, wenn man sub-optimale Duo- oder Oligopole vermeiden will, in denen Markt oft mehr schlecht als recht funktioniert)) aber es halt Gegenden gibt in denen sich Ueberbau schlicht nicht lohnt.
aber in Belgien für 20€ und bei uns zwischen 100 € und 140 €
LWLCom schon vergessen? Die machen wohl 8-10 Gbps und geben noch feste IPv4 Addresse und IPv6 Prefix dazu...
und außerdem ist 10-Gbit/s-Glasfaser für Privatkunden da bereits Realität und flächendeckend im Ausbau.
So, wo kann man das denn in Belgien bekommen? Nicht vergessen, die sind beim FTTH Ausbau noch hinter Deutschland.
Es wurde doch sogar gesagt, Belgien hatte auch ein gut ausgebautes Kupferbestandsnetz, und trotzdem sind die so günstig beim 10Gbit-FTTH-Internet
Und darum gibt es in Belgien, wie bei uns FTTH auch nur an ausgesuchten Adressen.
Unterschied ist aber: Belgien hat billigeres Fiber(wo es verfügbar ist)
Wo ist digi.be denn verfuegbar? Weil LWLCom ist auch relativ guenstig (fuer das was sie bieten, aber halt sehr sehr lokal...
10 Gbps 20€
(digi-belgium)
Sind halt keine 10G... egal wie die das bewerben...
Warum ist es da so günstig?
Weil Digi damit seine Kosten decken kann und ausreichend hohen Ueberschuss erzielt? Oder weil digi bereit ist temporaer Verluste zu akzeptieren und fuer spaeter andere Plaene fuer die Verwertung hat. Ich kann da nur spekulieren. Besser waere es, wenn es Dich denn interessiert, bei digi selber nachzufragen.
Anders wo klappt es doch auch mit der Finanzierung..
Na ja, wenn man mit geringeren Baukosten (z.B. weil weniger Tiefbau) und hoeherer Nachfrage (z.B. weil der Status Quo ADSL mit bestenfalls ca. 20 Mbps ist) zu einer Zeit anfaengt in der die Zinsen niedrig sind und Anleger auf der Suche nach Plaetzen fuer Ihr Geld die auch nur geringe Rendite versprechen... arbeitet, dann laeuft das halt geschmeidiger als wenn man:
Muss ja einen Grund das es nur in Deutschland hapert.
Ich finde Du bist da zu harsch, und zu selektiv... so liegt z.B. Belgien beim FTTH AUsbau noch hinter Deutschland (aus aehnlichen Gruenden, auch in Belgien gab es wohl ein relativ gut ausgebautes Kupferbestandsnetz von dem sich die Nutzer ausreichend versorgt fuehlten).
Ich hab jedenfalls noch nie gesehen, dass ein Netzbetreiber in einem Anschlussbereich einen Tarif mit Downstream 723 MBit/s und Upstream 184 MBit/s angeboten hätte, weil die Analyse ergeben hat, dass es dem Nutzungsverhalten der Kunden in dem Anschlussbereich entspricht.
Oh, mMn. geht es eher um de Fragen:
A) Waere es ausreichend lukrativ Tarife mit hoeheren Kapazitaeten anzubieten
B) Ist der aktuelle Engpass eher der Down- oder der Upload
damit man informiert neue Tarife schnitzen oder es bleiben lassen kann. Dabei erwarte ich keine krummen Zahlen, aber halt eine Antwort darauf ob es sich schon lohnen kann, z.B. XGS-PON auszurollen... (in D bei Bestandsnetzen vermutlich aktuell eher nicht, bei neuem Ausbau vielleicht eher schon, immerhin soll das ja ein paar Jahre gut ausreichen).
Was war die Frage jetzt gleich noch mal? Ein ISP kann natuerlich, wenn er will, den Datendurchsatz pro Anschluss aufzeichnen und auswerten. D.h. der kann nicht nur wissen welche Last in einem Segment im Mittel auftritt, sondern auch welchen Anteil daran jeder einzelne Anschluss hat.
D.h. das Nutzungsverhalten ist eine messbare Groesse, da muss nicht orakelt werden. Und ich vermute die mittlere Last (ueber alle Anschluesse eines Segments) laesst sich vermutlich auch gut vorhersagen... Aber wenn ein ISP wissen will ob hoeherer Upload moeglicherweise ein fuer seine Kunden attraktives Feature waere kann er schlicht gucken wie haeufig seine Nutzer ihren Upload voll ausschoepfen... die die das haeufig tun waeren Kandidaten die eventuell mehr fuer hoeheren Upload zahlen wuerden, d.h. die koennten die Einfuehrung eines Tarifs mit hoeherem Upload motivieren... wobei der ISP halt auch sehen kann, dass wenn der Kunde fuer X Euro mehr einen Tarif mit mehr Down und mehr Upload buchen koennte das aber nicht tut, der Kunde wohl auch nicht mehr als 
Euro fuer einen Tarif mit nur mehr Upload zahlen wuerde. Man muss sich vor Augen halten, dass ISPs mit ihrer Dienstleistung halt auch Geld verdienen wollen/muessen.
Na, da hat er schon ein bisschen mehr untersucht.
Erm, was den Ursprung der Ueberlast angeht hat er exakt ein MTR Trace ausgewertet, und zwar auf die von mir beschriebene Art wie man es nicht machen soll.
Gut, willst du nicht akzeptieren, dann ist die Diskussion hier auch am Ende. Hatten wir schon ein paar mal, da kommen wir nicht weiter.
Aber ich bin ehrlich: Mir sind komplexere Analysen wichtiger als tatsächlich Spekulation und Geunke.
Warum bist Du dann mit der praesentierten unter-komplexen Analyse des Ueberlast-Ortes einverstanden? Ganz im Ernst, es macht tatsaechlich wenig Sinn weiter zu diskutieren, da Du erkennbar der Meinung bist das vorsaetzliche Unterpeering der Telekom waere irrelevant oder existierte gar nicht.
Klar, kann man sich in Summe ansehen. Wenn aber der Pfad Telekom zu Cloudflare zu ist, spielt die (asymmetrische) andere Richtung nur eine kleinere Rolle. ACK kommen einfach nicht mehr verlässlich an. Das war es dann mit der Kommunikation.
Es gibt im referenzierten Post nur halt keine belastbaren Indizien dafuer, dass der Pfad von der Telekom zu Cloudflare "zu" waere. Nochmal, Du kannst aus einem MTR-Trace in nur einer Richtung nur bedingt Rueckschluesse auf den Ort einer Stoerung machen. Hier sehen wir gerade mal, dass alle Cloudflare zugeordneten Hops massiv erhoehte Maximal-RTT zeigen (und Paketverlust), aber nicht ob diese Latenzerhoehung bei den Cloudflare Servern selber entsteht, oder irgendwo auf dem Rueckweg von den Cloudflare Servern zur Telekom, das kann z.B. bei der Uebergabe von Cloudflare zur Telekom sein, also exakt die erwartete Auswirkung des vorsaetzlichen Unterpeerings der Telekom. (Es laesst sich noch nichtmal ausschliessen, dass das Problem zwischen 1299 und Cloudflare liegt, aber wahrscheinlich ist das nicht).
Bzgl. traceroute gebe ich dir nur bedingt recht. Einzelne Ausreißer kann man ignorieren. Mehrere Hops in Folge verwerfen nicht jedes, aber viele Pakete? Das ist schon eine andere Hausnummer.
Ein Missverstaendnis meiner Argumentation, mein Argument ist, dass wir aus dem Trace nicht ansatzweise schliessen koennen, der Engpass laege bei Cloudflare, mein Argument ist nicht es gaebe da keine Probleme. Ich will gar nichts ignorieren, ich will nur vermeiden dass wir den MTR-Trace ueberinterpretieren.
Habe ich irgendwo ausgeschlossen, dass die Telekom hier ein unschönes Spiel spielt? Noch nie. Weise ich darauf hin, dass die Situation komplex ist? Eben dies. Und damit reagiere ich allergisch, wenn immer noch Vodafone, Telekom etc. die Schuldigen sind. Zur Kommunikation braucht es immer beide Partner. Welches Spiel spielt also Cloudflare? Offenbar wird da ja auch sehr aktiv gesteuert.
Unklar, aber klar jeder Anbieter steuert Datenfluesse, dafuer ist BGP ja da, das ist nicht ehrenruehrig, und es ist nicht direkt das Problem der Telekom wenn Cloudflare ueber London oder Ashburn servieren will, aber was die beobachtet Ueberlast angeht, da ist die Telekom halt immer noch unter den Verdaechtigen. Zumindest fuer die unter uns die Traceroutes lesen und interpretieren koennen
Aber damit will ich hier Schluss machen, ist ja hier im Thread eher OT.
Erklaerung, mtr/traceroute koennen immer nur die Hops des Vorwaertspfades identifizieren aber Jitter und Paketverlust koennen durchaus bei spaeteren Hops auf dem Rueckweg entstehen, aber werden als Verlust am Vorwaertshop dargestellt... Etwas erstaunlich, dass der Reddit BGP-Versteher bei der MTR Interpretation so vorschnell vorgeht.
Wenn wir auf den MTR vom Anfang schauen sieht man, dass zwischen der Telekom und Arelion (Hop 4 und 5) alles in Ordnung ist – danach, also schon nach der Übergabe von Arelion an Cloudflare, setzen erst hohe Latenz und Packetloss ein, der Engpass liegt also bei Cloudflare.
Ja, das mag naheliegend erscheinen, ist aber eine typische Fehlinterpretation von Traceroute/MTR.
Ein aehnliches Problem ergibt sich auch fuer BGP, auch da fehlt die Analyse was die Telekom an Cloudflare announced. Die Annahme Internetpfade waeren symmetrisch in beiden Richtungen ist zu optimistisch, ja es gibt auch mal symmetrische Pfade aber asymmetrische halt auch und das muss man bei Analysen beruecksichtigen. Dazu Slide 38 hier: https://archive.nanog.org/sites/default/…_Traceroute.pdf
Zumindest im untersuchten Fall lag die Überlast beim propagierten Router in London.
Unklar, es gab da wenn ich mich recht erinnere, wie so oft keinerlei belastbare Einsicht in den Lastpfad von Cloudglare in London zu den Nutzern... was gezeigt wurde ist, die Wahl des Standortes London liess sich mit BGP Announcements von Cloudflare erklaeren, der Rest war Spekulation.
Es sieht also sehr danach aus, als wenn Cloudflare den Traffic (nicht nur) der Telekom absichtlich zu bestimmten Routern und Peerings lenkt. Das ist ja erstmal ganz OK dass sie das machen, aber in dem Fall schicken Sie den Traffic mehr oder weniger absichtlich irgendwohin, wo sie nicht genug Kapazitäten haben.
Das ist halt Spekulation weil er nicht weiss wo der Endpass ist und ob Cloudflare andere nicht ueberlastete Uebergaben zur Verfuegung haette.
Die Datenraten stehen bei diesem Test ganz klar nicht im Vordergrund... dafuer versucht er aber auch nicht die ueblichen absurden zeitaufgeloesten maximal-Raten zu zeigen.
Der Test zeigt in der Zeitserie jetzt auch den Down- und Upload-Durchsatz an.
Und wo ist die Referenz zum Cloud Flare Routing?
In wie fern ist das relevant? Mit der Frage wie breitbandmessung.de die Peeringqualitaet von ISPs messen koennte hat das nichts zu tun. Und auch mit dem vorsaetzlichen Unterpeering der Telekom hat das wenig zu tun. Das ist gerade mal interessant wenn man sich fragt warum die RTT zu Cloudflares free Tier bei der Telekom hoeher ist als bei vielen Mitbewerbern.
Die Auswirkungen der Unterpeerings sind jedoch andere: erhoehter Paketverlust und Jitter sowie verringerter Durchsatz in der Spitzenlastzeit, das hat mit der path RTT selber nichts zu tun.
Dass Cloud Flare den Traffic von der Telekom gezielt nach London leitet, ist doch wohl unstrittig, oder?
Keine Ahnung ob das aktuell noch so ist, das ging ja auch mal ueber die Ostkueste der USA. Die Frage ist bei der Konstruktion, warum macht Cloudflare das (ich neige kingpin42s Interpretation) und wenn es dabei zu Ueberlast kommt, liegt das an vorsaetzlich unterdimensionierten Uebergaben der Telekom?
BGP announcements sind jetzt nicht so geheim.
BGP announcements sind nicht geheim, aber erzaehlen halt nicht die ganze Geschichte... Hier eine Praesentation dazu die zeigt warum BGP keine ausreichende Loesung ist (hier im Kontext von Ingress-Point Detection):
https://ripe89.ripe.net/presentations/52-20241028_IPD_Presentation.pdf
"BGP announcement go towards the traffic source
Traffic Flows form the source towards the announcement
Requirement:
● Do not use BGP Prefix sizes"
BENOCS ist ein Spin-off der Deutschen Telekom... Ingress-Point Detection ist uebrigens sehr nuetzlich wenn man vorsaetzliches Unterpeering mit begrenzten Nebenwirkungen umsetzen will...
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
