Mit dem physischen Link meinst Du jetzt die elektrische Seite des Modules?
Ja, genau.
Mit dem physischen Link meinst Du jetzt die elektrische Seite des Modules?
Ja, genau.
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.
Ich habe nicht behauptet, das das im Saarland ist.
Achso ok, das hat dann aber mit dem Thread hier nicht mehr viel gemeinsam.
150T Einwohner: eher nicht verfügbar ...
Und welche Stadt im Saarland soll das sein ?
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.
Das saarländische Wirtschaftsministerium hat einen nützlichen Gigabit-Atlas auf dessen Webseite veröffentlich, der für Interessierte von Nutzen sein könnte:
Hier wird in jedem Ortsteil/Stadt die aktuelle Ausbauplanung samt auszubauendem Unternehmen angezeigt.
An der Hotline wirst du da nicht weiter kommen…
Kannst mir mal per PN die SN vom originalen ONT geben ?
Hat der Transceiver der Fritzbox keinen LC/UPC Anschluss ? Du bräuchtest dann, je nach APL Typ, ein LC/APC oder SC/APC auf LC/UPC Kabel.
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.
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:
ZitatCode Alles anzeigen[...] 3. Behavior Ambiguity Analysis The ambiguity of the flags definition means that when interpreting the same messages, different hosts might behave differently. The ambiguity space is analyzed as the following aspects. 1) Dependency between DHCPv6 and RA In standards, behavior of DHCPv6 and Neighbor Discovery protocols is specified respectively. But it is not clear that whether there should be any dependency between them. More specifically, it is unclear whether RA (with M=1) is required to trigger DHCPv6; in other words, It is unclear whether hosts should initiate DHCPv6 by themselves if there are no RAs at all. [...]
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.
Alles anzeigenIch habe gerade noch mal ein bisschen recherchiert, und dieser Fall ist geradezu ein Paradebeispiel dafür, warum die IP Geolokalisierung in heutigen Zeiten einfach nur noch Unsinn ist.
Die Internetnord GmbH scheint zu einer schwedischen Firma zu gehören ("Internet bolaget Sverige AB"). Die haben Niederlassungen in Deutschland, Schweden und Norwegen. Aber: Sie trennen die Aktivitäten vorbildlich und kündigen auch jedes ihrer IPv4 Subnetze im jeweiligen Land sauber an:
Da ist auch euer berühmtes 2.59.28.0/24 Netz, schön sauber in Deutschland verortet. Soweit, so gut.
Wenn man dann ein bisschen weiter forscht, stellt man fest, dass die Internetnord GmbH für Transit Dienstleistungen offenbar auf die Dienste einer Firma namens "Core-Backbone GmbH" zurückgreifen. Die sind Transit-Dienstleister im großen Stil und verbinden etliche kleine, regionale Internetanbieter mit der großen weiten Welt. Dafür verfügen sie nicht nur über Niederlassungen in mehreren europäischen Ländern, sondern auch über etliche IP-Subnetze, die sie ihren Kunden zur Verfügung stellen.
Das 2.59er Netz, über das ihr klagt, gehört ursprünglich zur Core Backbone GmbH. Sie haben in dem Bereich einen deutlich größeren Block, nämlich 2.59.28.0/22, also alle Adressen von 2.59.28.0 bis 2.59.31.255. Die höheren Subnetze (2.59.29.0 bis 2.59.31.255) werden aktuell offenbar nicht von Kunden genutzt. Das Problem: Das übergeordnete /22 Netz ist für die Schweizer Tochter der Core Backbone GmbH, der "Core-Backbone Schweiz GmbH, registriert.
https://bgp.he.net/net/2.59.28.0/24#_netinfo
Und schwupps verorten euch einige Lokalisierungsdienste in der Schweiz. Obwohl - wie auch im Link von HE deutlich zu sehen ist - die Aufteilung des Netzes deutlich und richtig kommuniziert wird. Aber die Lokalisierungsienste sind zu faul oder haben Bugs in ihre Software oder was auch immer - sie ignorieren die Aufteilung und melden die Information des übergeordneten Netzes.
Wie ich oben schon schrieb: Dieses Vorgehen ist in der Form komplett überholt. Bin gespannt, wie lange es noch dauert, bis DAZN und Konsorten das endlich mal merken.
Ihr dürft diesen Beitrag gern mal an die Inhalteanbieter senden, die sich querstellen, damit sich deren Support selber von der Unsinnigkeit ihres Vorgehens überzeugen kann.
Ach, übrigens: auch die 185er Adressen gehören ursprünglich der Core Backbone GmbH, sind allerdings der deutschen Niederlassung zugeordnet. Auch da ist es also jederzeit denkbar, dass die plötzlich mal woanders liegen, wenn die Core Backbone GmbH z.B. aus steuerlichen Gründen auf die Idee kommt, die Adressen in ein anderes Land zu verschieben.
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.
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.
Was soll daran nicht funktionieren ?
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 :
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.
Alles anzeigenHier die offizielle Begriffserklärung des FTTH Councils:
“Homes Passed” is the potential number of Premises which a Service Provider has capability to connect to an FTTH/FTTB network in a service area. Typically new service activation will require the installation and/or connection of a drop cable from the homes passed point (e.g. fiber-pedestal, manhole, chamber, utility-pole) to the Premises, and the installation of subscriber Premises equipment at the Premises. This definition excludes Premises that cannot be connected without further installation of substantial fibre plant such as feeder and distribution cables (fiber) to reach the area in which a potential new subscriber is located.
“Homes Connected” is the number of Premises which are connected to a network and are already subscribers or can be turned into a subscriber without further installation work.
“Premises” is a home or place of business. In a multi-dwelling unit [1] each apartment is therefore counted as one Premises.
“Subscriber” is a Premises that is connected [2] to a network and uses at least one service on this connection under a commercial contract.
[1] Multi-tenant unit in some countries.
[2] Implies a service termination point.
Hier die Magenta-Vorstellung der genannten Begrifflichkeiten: