Beiträge von kingpin42

    Es ist und bleibt ein SFP Modul.

    Erkläre mir bitte was in diesem Zusammenhang Überprovisionierung mit diesen 1070 Mbps zu tun hat. Und wie setzen sich diese 1070 Mbps zusammen?


    Im 1 Gb Ethernet werden die 8 Bit Datenwörter in 10 Bit kodiert, das bedeutet schon allein für Ethernet einen Overhead von 20% der technisch bedingt ist und nicht umgangen werden kann. Im Multigigabit Ethernet wird eine effizientere Kodierung verwendet.

    Btw: Im GPON ist die Kodierung der Datenwörter ebenfalls deutlich effizienter als die 8b/10b Kodierung, hat aber mit Ethernetgar nichts zu tun.

    Man muss hier zwischen den beiden Interface-Seiten des Moduls unterscheiden.

    Die xPON Seite erlaubt höhere Geschwindigkeiten als 1Gbit/s brutto.

    Bei den ONT SFPs hängt es jetzt davon ab, ob das Gerät mit dem SFP+ Port, diesen auch mit 2,5 Gbit/s betrieben kann. Nur dann ist es in Kombination mit einem geeigneten Modul möglich, von der Überprovisionierung mancher Provider einen Nutzen zu ziehen.


    (1G Ethernet werden auf dem physikalischen Link aufgrund der 8b/10b Kodierung ja mit 1.25 Gbps angesteuert.)

    Die im PIB angegebenen Übertragungsgeschwindigkeiten bzw. Bandbreitenkorridore werden übrigens von der BNA als Nettogeschwindigkeiten interpretiert, also ohne TCP/IP + weitere Header.

    Das ist auch der Grund der Überprovisionierung der großen Provider (und natürlich weil es ein Kriterium im Connect Test ist, und man da natürlich immer vor der Konkurrenz landen möchte).

    Ganz ehrlich: Wenn das die Strategie des Saarlandes ist, dann kann es der Atlas auch nicht retten.

    Solch abgelegenen Orte werden dann mit Fördermitteln des Landes erschlossen, nur will man erstmal dem privatwirtschaftlichen Ausbau nicht vorgreifen und ermittelt den Bedarf erst danach. Irgendwann werden diese abgelegenen Höfe also schon in den Genuss von FTTH kommen. Problematisch finde ich hier eher die ganzen lokalen Stadtwerke, die anscheinend dem Ministerium grünes Licht für einen Ausbau "irgendwann" gegeben haben. Da kenne ich leider sehr viele Negativbeispiele, da wir direkt mit solchen Stadtwerken zu tun haben beim Anschluss von Gewerbekunden.

    Deshalb wäre ich vorsichtig mit Äußerungen wie "so schnell schalten die nichts ab".

    Da die Telekom bis Ende des Jahres 2022 noch E1-Leitungen in Betrieb hatte, gehe ich sehr stark davon aus, das uns xDSL noch eine ganze Weile erhalten bleiben wird. Es gibt ohnehin Standorte, die wohl in den nächsten 10-20 Jahren nicht mit einer LWL oder durch Coax erschlossen werden können bzw. es sich absolut für keinen Anbieter lohnen würde.

    Also die FB/AVM unterstützen seit 2011 IPv6. Da gab es, glaube ich, eigentlich noch keinen großen Provider, der auch nur über IPv6 nachgedacht hat. :lol: Daher hatten sie erst einmal beides eingebaut.

    Als es dann konkreter wurde, haben sie laut IPv6_Technical_Note_de.pdf aus 2019 dieses umgestellt, dies müsse so mit Firmware 6.80, spätestens 7.10 gewesen sein. Wer dies noch nicht auf seiner FB hat, hat andere Probleme, IPS-eigene FB werden bestimmt richtig eingestellt sein.

    Genau dieses Vorgehen von AVM verwirrte den BNG, das ist auch sehr gut hier beschrieben:

    DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration
    The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating the…
    datatracker.ietf.org
    Zitat

    Es existiert faktisch keine gegenseitige Abhängigkeit von SLAAC und DHCPv6.

    In welcher RFC steht, dass nur das eine oder das andere erlaubt ist? Windows und Linux machen das ja auch nicht und holen sich über beides eine Adresse, vor allem, wenn die RAs nicht im Sekundentakt kommen.

    Linux macht bei mir in der default Config (NetworkManager), nur SLAAC, und holt sich DNS Infos via RFC6106 auch im RA. Windows weiß ich es nicht.

    Ich müsste den RFC raus suchen, jedenfalls ist beides gleichzeitig, also das gleichzeitige Senden von Router Solicitations und DHCPv6 Solicitations, sofern es sich beim Router und DHCPv6-Server um dieselbe Entität handelt (was bei einem BNG der Fall ist), problematisch.

    Ja, du musst den ONT auf jeden Fall montieren lassen. 1000BASE-FX ist nicht AON. AON wäre 1000BASE-BX.

    Auch wenn es keinen 1000Base-FX Standard gibt, bedeutet AON nicht zwingend, das es sich um einen BiDi-Standard handeln muss. Es gibt auch aktiv optische Anschlüsse, die zwei Fasern und herkömmliches 1000Base-LX/10GBase-LR oä. verwenden.

    Auch interessant dass grad mal je ein /24er Subnetz einem Ort mit 10000 Einwohnern zugeordnet ist...

    Warum IN nicht auf IPv6 setzt um dem Geschachere zu entgehen verstehe ich ehrlich gesagt nicht. Dass die IPv4 Blöcke aufgebraucht sind, war ja schon vor 10 Jahren klar. Hat jemand ne Idee,was technisch dagegen spricht?

    Weißt du, ob alle diese 10000 Einwohner Anschlüsse von IN besitzen ?

    Was technisch gegen v6 spricht ? Eigentlich gar nichts, sofern CPEs RFC-konform arbeiten. Was leider in der näheren Vergangenheit oft nicht der Fall war. Fritzboxen haben bis zu einer bestimmten FW-Version z.B. gleichzeitig versucht, via SLAAC und DHCPv6 eine Adresse zu beziehen. Das mögen BNGs, die streng nach RFC entweder das eine, oder andere Verfahren erwarten, einfach nicht. Und das ist nur ein Beispiel von vielen Fallstricken, die bis heute der Erfolgsgeschichte von IPv6 im Weg stehen.

    Es wäre wohl sinnvoller, hier auf die Core Backbone zuzugehen, da deren Maintainer-Object wohl das Falsche ist (das less Specific ist von deren Schweizer Abteilung).

    Der IP-Space wurde in der RIPE DB auch erst seit dem 02.11.2022 von der OI/CBB dokumentiert, sodass man hier den Diensteanbietern evtl. noch keinen Vorwurf machen könnte.

    Hier ist, was in der Schnittstellenbeschreibung steht:

    Wenn wir sie beim Wort nehmen, wird also eine auf Power-over-Ethernet basierende Methode für Authentisierung, Authorisation und Buchführung verwendet. Von der im Netz verwendeten DHCP Option 82 soll der Endkunde nichts merken. Vielleicht wird die also noch nicht vom ONT sondern erst vom OLT gesetzt. Warum sie das dann überhaupt in der Schnittstellenbeschreibung erwähnen, bleibt ihr Geheimnis.

    Vermutlich könnte man aber auch Kaffeesatz statt der Schnittstellenbeschreibung lesen, denn nach PoE im BNG Konzept kommt das hier:

    Also kein PPPoE, deshalb muss PPPoE im Router eingeschaltet werden. Nur den Plan DHCP Client verwenden. 8o

    Zwar ein älterer Beitrag, aber vermutlich meinte OI hier "IPoE" (eine etwas unübliche Beschreibung für IP/DHCP), mit Power over Ethernet hat AAA nichts am Hut. Macht übrigens auch die Telekom bei ihrem "Easy Login". Nur werden die zusätzlichen Teilnehmerinfos (Line-ID, Circuit-ID), dort nicht in der Option 82 gesendet, sondern im PPPoE Intermediate Agent an den BNG gesendet. Dadurch muss der RADIUS dahinter Username/Passwort nicht mehr prüfen, sondern lässt die Verbindung einfach zu, sofern ein Datenbankeintrag zur Line-ID existiert.

    Das Problem ist nicht nur die Peeringbandbreite sondern auch die Anzahl der Peeringpunkte bzw. deren geographische Lage.

    DGF (AS60294) hat laut Peeringdb nur 3 öffentliche Peeringpunkte, davon 1 x400 DECIX-FRA. EWE z.B. dagegen 5 Punkte, davon 500GBits DECIX-FRA und 100GBits DECIX-HAM, neben einigen anderen.

    Dann wäre noch die Frage wie das Peering zum Telekom-Netz aussieht! Das sind i..d.R private Peerings, die auch bezahlt werden müssen. DTAG ist bei DECIX kaum vertreten!Wir haben doppelt so hohe Laufzeiten von unseren Business DGF-Anschlüssen zu unseren Servern im Telekom-Netz als bei unseren EWE-Glasfaseranschlüssen.

    Die PeeringDB sollte man nicht überbewerten. Die DG hat sicherlich einige PNIs abseits der IX, die sind allerdings nirgends verzeichnet, bei uns sind die auch nirgends gelistet, es gibt sie aber. Das kann man allerdings mit einem Traceroute oder einem Looking-Glass (oder für die Fortgeschrittenen via RIPE Atlas) verifizieren, die IP-Ranges der hiesigen IXe sind ja bekannt, im Peering LAN werden die immer genutzt. Alternativ müsste man die gesetzten Communities kennen, die sind aber mWn. von der DG nicht öffentlich dokumentiert.

    Ich hatte es mal an anderer Stelle erwähnt, die DTAG bietet kein Peering an. Auch nicht gegen Geld. Du bekommst immer Transit angeboten und kannst es dir selbst dann zu einem Peering zurechtstutzen.

    Die DTAG ist nur aus Marketinggründen am DECIX.

    Die EWE wird vermutlich auch ein kastriertes Paid-Peering zur DTAG besitzen, zumindest nehme ich das stark an:

    Erkennbar am :

    • direkten AS-Path in Kombination mit einer AS3320 Next-Hop IP (194.25.5.167)
    • der BGP Community (65010,65003): das ist eine Community der DTAG, damit sie die empfangenen Routen von EWE nicht weiter Richtung Upstreams/Peers announced. (steht z.B. hier https://onestep.net/documents/AS33…nities_v1.1.pdf)

    Wie ihr von "Single-Stream von netzinternem Server ist langsam" auf "Peering ist schlecht" kommt, müsst ihr mir mal technisch erklären...

    Das frage ich mich auch. Das können genauso gut verstopfte Links von den OLTs Richtung BNG/Core oder wie oben schon genannt, LAG-Problematiken sein.

    Da die Telekom mit das größte Netz betreibt, ist es schon wichtig, wie das Peering dahin ausgestattet ist.

    Je nachdem in welchem Maße man sich erpressen lassen will, ja.

    Ich glaube, das nennt man heutzutage "victim blaming".

    Richtig, funktioniert aber leider manchmal. Hetzner ist vor Jahren eingeknickt, wir sind es letztes Jahr...

    Das liegt ganz häufig daran, das ein einzelner Stream nicht über eine LAG-Gruppe aufgeteilt werden kann. Nahezu jeder Provider nutzt LAGs für seine BB-Interconnects, wenn da ein einzelner Stream über einen überlasteten Link geht, siehts schlecht für dich aus. Auch von der BNA gibt es hierzu keinerlei Zusagen an garantierter Bandbreite als Singlestream, ausschlaggebend ist hier -einzig- der Speedtest der Zafaco (aka Breitbandmessung.de). Da musst du dich wohl oder übel leider damit abfinden.

    Hier die Magenta-Vorstellung der genannten Begrifflichkeiten: