Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Das beweist ja auch die Telekom selbst mit ihrem "EasyConfiguration", dass man die PPPoE-Zugangsdaten überhaupt nicht braucht, um zu wissen, um welchen Anschluss/Kunden es geht.
Fuer die eigenen Kunden braucht die Telekom halt auch keinen Tunnel.... wobei das vor BNG schon auch nuetzlich war um zu den PoPs zu kommen... Der Punkt mit dem Tunneln ist halt auch, dass der Betreiber-ISP fuer die IP-Adressvergabe zustaendig ist/sein soll, theoretisch koennte man so etwas auch ueber spezielles Routing regeln, aber das erscheint mir jetzt ziemlich aufwendig weil jetzt Telekom un Reseller individuelles Routing per IP Adresse durchfuehren muessten... Da erscheint ein Tunnel pro Reseller (oder auch eine Handvoll pro Reseller) deutlich einfacher zu konfigurieren und warten, oder?
Fuer die eigenen Kunden braucht die Telekom halt auch keinen Tunnel.... wobei das vor BNG schon auch nuetzlich war um zu den PoPs zu kommen... Der Punkt mit dem Tunneln ist halt auch, dass der Betreiber-ISP fuer die IP-Adressvergabe zustaendig ist/sein soll, theoretisch koennte man so etwas auch ueber spezielles Routing regeln, aber das erscheint mir jetzt ziemlich aufwendig weil jetzt Telekom un Reseller individuelles Routing per IP Adresse durchfuehren muessten... Da erscheint ein Tunnel pro Reseller (oder auch eine Handvoll pro Reseller) deutlich einfacher zu konfigurieren und warten, oder?
Und dem Reseller die Information vorzuenthalten, von welchem Anschluss welches Datenpaket kommt? Klar, gibt der Telekom den USP der EasyConfiguration, die so kein Reseller seinen Kunden bieten kann...
Du laesst die Frage offen welche alternative Tunneltechnik besser waere....
Und ignorierst auch dass der PPP Teil von PPPoE seit 1989 spezifiziert war: https://datatracker.ietf.org/doc/html/rfc1134. Und das ist halt durchaus eine erprobte bekannte Tunneltechnik.
Der Regulierer, das muss man sich halt klar machen, erwartet, dass Reseller Netzzugang unter gleichen technischen Bedingungen erhaelt wie die IAS-Sparte eines TAL Betreibers, weshalb es fuer die Telekom der Weg des geringsten Widerstandes ist PPPoE schlicht immer einzusetzen. Und im Vergleich zu Tunneling auf IPv4/6 Ebene ist PPPoE mit 8 Byte erfrischend schlank...
IMHO muss man PPPoE nicht lieben um zu erkennen warum dessen Weiternutzung durch die Telekom durchaus rational ist.
Kannst Du mich villeicht daran erinnern, wie VF und O2 ihr aehnliches Problem beim DOCSIS-Reselling loesen, und hast Du eine Idee ob/wie viele Kundenanschluesse so realisiert werden?
Ergänzung ()
robert_s schrieb:
Und dem Reseller die Information vorzuenthalten, von welchem Anschluss welches Datenpaket kommt?
Der weiss aber bereits, dass sie Pakete von/zu einem Anschluss gehen, dessen Nutzer eine korrekte Nutzernamen und Passwort-Kombination konfiguriert hat...
Die Telekom identifiziert Resellerkunden anhand des PPPoE realms und "kippt" deren Pakete dann in dem jeweils entsprechen konfigurierten Tunnel zum Reselleruebergabepunkt.
Bezueglich der Line-ID sagt der BSA-Gate Standardvertrag:
Code:
2.3 Information über Sessions
Die Sessiondaten stellt die Telekom dem Kunden auf einem durch Passwort geschützten WWW- Server zur Abholung bereit.
Die Telekom protokolliert jede vom Endkunden generierte Session, die sie am Übergabeanschluss an den Kunden übergibt. Sie stellt dem Kunden insbesondere folgende Informationen täglich jeweils zwei Werktage nach dem jeweiligen Logout-Datum zur Verfügung:
• UserName (Endkunde)
• Logout-Datum (Stop_Date_Stamp; TT:MM:JJJJ)
• Logout-Time (Stop_Time_Stamp; HH:MM:SS)
• Duration (Acct_Session_Time; sekundengenau)
• Bytes In (Acct_Input_Octets; Volumen, das vom Endkunden zum Kunden übertragen wird)
• Bytes Out (Acct_Output_Octets; Volumen, das vom Kunden zum Endkunden übertragen wird)
• Kennzeichen für PoP-Art
• ONKZ des Breitband-PoP Standorts
• Bruttobitrate der IP-BSA-Access-Teilleistung
• [B]Line-ID (sofern technisch verfügbar)[/B]
• Reservefeld
Die einzelnen Felder werden durch Tab (=X'09') getrennt.
Die Sessions eines Tages stellt die Telekom in einer ASCII-Datei (Tagesdatenfile) bereit. Es werden maximal die letzten sieben Tage gleichzeitig vorgehalten. Am achten Tag wird die älteste Datei mit den neuen Werten überschrieben. Am Monatsende wird zusätzlich eine Datei mit Sessions des ab- gelaufenen Monats bereitgestellt (Monatsdatenfile) und mit Ablauf des Folgemonats mit neuen Daten überschrieben.
Grundsätzlich fasst die Telekom im Monatsdatenfile alle Sessions mit dem Endezeitstempel des Abrechnungsmonats zusammen. Bedingt durch Pufferspeicher auf der Erfassungsplattform kann eine geringe Anzahl Sessions mit einem Endezeitstempel des Folgemonats bereits im Monatsda- tenfile des Abrechnungsmonats erscheinen. Diese bereits übermittelten Sessiondatensätze über- mittelt die Telekom im Monatsdatenfile des Folgemonats nicht erneut.
d.h. der Reseller duerfte die Line-ID mit akzeptabler Verzoegerung sehen (die Linie-ID wird IMHO vom MSAN/DSLAM-Port abgeleitet und ist deshalb extrem statisch, da muss schon ein Techniker Draehte rangieren damit die sich aendert).
robert_s schrieb:
Klar, gibt der Telekom den USP der EasyConfiguration, die so kein Reseller seinen Kunden bieten kann...
Weil Easy-Logon auch das "Killerfeature" ist auf Grund dessen die Telekom den Resellern Kunden abspenstig machen wuerde.... Bei O2 ist es so, dass nur Kunden mit eigenem Router sich auf die Ebene von Nutzernamen und Passwort herablassen muessen, die grosse Mehrheit gibt (wenn ich mich recht erinnere) gibt eine PIN in die Easybox ein und gut ist es, und das gerade einmal bei ersten Inbetriebnahme des Routers. Wenn das das Niveau an "Innovation" ist die wir durch regulatorische Festlegung auf PPPoE verlieren, dann halte ich den Verlust fuer "verschmerzbar"/irrelevant.
P.S.: Bei L2-BSA wird die Line-ID direkt mit uebertragen...
Mh, sicher? Kann zeitlich durchaus sein, aber 1&1 hat ja auch DSL-"Anschlüsse" zum Telekom-Telefonvertrag verkauft (damals, als das noch zwei verschiedene Sachen waren).
Die Telekom identifiziert Resellerkunden anhand des PPPoE realms und "kippt" deren Pakete dann in dem jeweils entsprechen konfigurierten Tunnel zum Reselleruebergabepunkt.
Nach der Ausbaugebietsänderung bei Nummer 17 hier zwei Konkretisierungen:
20: "Praunheim" zu "Siedlung Praunheim West"
22: "Fechenheim" zu "Fechenheim Nord"
@rezzler, mal eine andere Frage: Wie weit kommt man eigentlich in einem 7mm Mikrorohr? Ich habe die Aussage, dass 1-2km durchaus drin seien. Eine andere Aussage spricht von max. 600 Metern.
@rezzler, mal eine andere Frage: Wie weit kommt man eigentlich in einem 7mm Mikrorohr? Ich habe die Aussage, dass 1-2km durchaus drin seien. Eine andere Aussage spricht von max. 600 Metern.
Kommt auf die Verlegung und die Strecke drauf an. Ich hab da auch schon 1,4km geschafft, das war dann aber 1,35km einfach fast gerade aus und leicht bergab eine Straße entlang. Im städtischen Bereich mit vielen relativ engen Kurven sind teilweise die 600m schon optimistisch. Und wenn der Tiefbauer Mist gebaut hat (kein Sand, irgendwo Rohr gequetscht) können auch auch 100m schon anstrengend bis unmöglich werden...
Kommt auf die Verlegung und die Strecke drauf an. Ich hab da auch schon 1,4km geschafft, das war dann aber 1,35km einfach fast gerade aus und leicht bergab eine Straße entlang. Im städtischen Bereich mit vielen relativ engen Kurven sind teilweise die 600m schon optimistisch. Und wenn der Tiefbauer Mist gebaut hat (kein Sand, irgendwo Rohr gequetscht) können auch auch 100m schon anstrengend bis unmöglich werden...
Was macht man denn, wenn die Glasfaser nicht ins Rohr will? Verwendet man dann Werkzeuge zur Inspektion und soweit möglich Schadensbehebung (z.B. ein Endoskop und vielleicht einen Blasebalg, um das Rohr in Form zu bringen), oder wird das einfach pauschal zurück an den Tiefbauer gegeben a la "Aufreißen, nochmal machen!"...?
Was macht man denn, wenn die Glasfaser nicht ins Rohr will? Verwendet man dann Werkzeuge zur Inspektion und soweit möglich Schadensbehebung (z.B. ein Endoskop und vielleicht einen Blasebalg, um das Rohr in Form zu bringen), oder wird das dann pauschal zurück zum Tiefbau gegeben a la "Aufreißen, nochmal machen!"...?
Da gibts Möglichkeiten und hier haben verschiedene Monteure verschiedene Mittel, auf die sie jeweils schwören. Klassisch wird erstmal probiert, vom anderen Ende aus einzublasen. Ist bei FTTH im Keller ohne Fenster natürlich erstmal schwierig...
Inspiziert wird da nichts, man (bzw. der Einbläser) wertet in der Regel die Daten aus, die man beim Einblasvorgang gewinnt. Erfahrung ist da eine große Hilfe, aber halt auch subjektiv. Wir (als Firma) sind inzwischen schon auch soweit, das man bei Problemfällen erstmal einen zweiten/anderen Einblastrupp hinschickt um den Fehler zu reproduzieren, einzugrenzen oder es halt auch zu schaffen. Den Fall hatte ich letztens bei 2 Häusern von mir.
Rohr in Form bringen durch aufblasen/Druck drauf geben ist für mich erstmal eine Art Märchen. Man gibt ja bis 15 Bar drauf und selbst wenn man da am Ende das Rohr abdichtet dürfte der Effekt sehr gering sein. Wenn so eine Engstelle kurz vorm Haus ist kann man aber durchaus probieren, mit einem Fädelband ins Rohr zu stochern und das evtl. ausreichend aufzuweiten.
Offensichtliche Fehler (kein Durchgang/keine Luft, also falsch verbunden) gehen natürlich direkt zum Tiefbau.
Wir (als Firma) sind inzwischen schon auch soweit, das man bei Problemfällen erstmal einen zweiten/anderen Einblastrupp hinschickt um den Fehler zu reproduzieren, einzugrenzen oder es halt auch zu schaffen.
Danke @rezzler. Ich frag, weil ein Kunde einen DCIP bekommen soll. Ein Großteil der Strecke (ca. 700m) ist ein von der Kommune verlegter SNRV, in dem angeblich nur 7mm Röhrchen vorhanden sind. Die Telekom kennt die Daten, dennoch hat der Einblastrupp abgebrochen bzw. es gar nicht erst probiert, wobei die Strecke zum Kunden einigermaßen gerade, dafür bergauf verläuft. Ich bin gespannt, wie es weiter geht.
Das Problem wäre dann bei uns bestenfalls schlechte Einstellung/Wartung vom Gerät. Wir haben in der Firma für Mikrokabel inzwischen nur noch einen Typ von Einblasgerät.
Mettwurscht schrieb:
Danke @rezzler. Ich frag, weil ein Kunde einen DCIP bekommen soll. Ein Großteil der Strecke (ca. 700m) ist ein von der Kommune verlegter SNRV, in dem angeblich nur 7mm Röhrchen vorhanden sind. Die Telekom kennt die Daten, dennoch hat der Einblastrupp abgebrochen bzw. es gar nicht erst probiert, wobei die Strecke zum Kunden einigermaßen gerade, dafür bergauf verläuft. Ich bin gespannt, wie es weiter geht.
Naja, wenn du nicht gerade 100% Steigung hast würd ich mir darüber weniger Gedanken machen und eher um die Qualität der Verlegung. Ich hab mit meinem vorherigen Einblasgerät bei 500m Strecke auch schon einiges an Höhenmeter überwunden und es ging damals problemlos, was mich selbst etwas überrascht hat.
Ansonsten halt vom Haus aus probieren (sofern zugänglich) oder schlimmstenfalls beim Haus am Abzweig vom Verband eine Grube machen und in zwei Richtungen blasen. Wäre natürlich die aufwändigste Lösung.
Und dem Reseller die Information vorzuenthalten, von welchem Anschluss welches Datenpaket kommt? Klar, gibt der Telekom den USP der EasyConfiguration, die so kein Reseller seinen Kunden bieten kann...
Als Reseller kannst du auch darauf verzichten, die Zugangsdaten zu prüfen. Der Kunde muss aber in jedem Fall den korrekten Realm mitschicken.
Das wäre vielleicht dann eine „EasyConfiguration-Lite“
Warum ist das notwending? Die Telekom weiß doch, an welchen Reseller die Leitung vermietet ist. Warum muss der Kunde ihr eine Information geben, die sie selbst schon hat?
Weil bei L3-BSA die Telekom die Packete basierend auf dem Realm dem Kunden (also dem Mitbewerber) zuordnet. Bei L2-BSA wo der Mitbewerber ja eigene Ports im/am BNG haben muss kann auf PPPoE verzichtet werden (die Zuordnung erfolgt hier wenn ich das recht verstehe per S-VLAN):
2 Leistungsbeschreibung L2-BSA-Transport
Der L2-BSA-Transport umfasst die Übertragung des Datenverkehrs, den ein Endkunde über den Kunden abwickelt, zwischen der Anschalteeinrichtung beim Endkunden und einem L2-BSA-Übergabeanschluss (nähere technische Beschreibung siehe Ziffer 9).
2.1 Datenübertragung
Die Daten des Endkunden-Anschlusses werden als Ethernet-Verkehr mit den in den nachfolgenden beiden Absätzen beschriebenen Einschränkungen transparent, also ohne Veränderung von der U-SSt zum L2-BSA- Übergabeanschluss übertragen. In dem transportierten Ethernet-Datenstrom kann der Kunde die zu nutzenden C- VLAN selber festlegen. In jedem C-VLAN kann PPPoE, DHCP/IPoE oder beides gleichzeitig übertragen werden.
Im Upstream (von der U-SSt. zur A10-NSP) wird von der Telekom das S-VLAN eingefügt. Für den Datenverkehr des Endkunden wird dynamisch jeweils eine S-VLAN-ID entsprechend Ziffer 9.1 vergeben. Diese S-VLAN-ID kann sich ändern, ggf. bei jeder DSL-Synchronisation. Der Kunde kann dabei mittels weiterer von ihm zu realisierender technischer Maßnahmen die Zuordnung des Endkunden zur dynamisch vergebenen S-VLAN-ID bei jedem neuen Sessionaufbau herstellen, da die dem Endkunden zugeordnete Line-ID jeweils mit den in Ziffer 2.3.3 beschriebenen Verfahren an der A10-NSP-Schnittstelle im S-VLAN übergeben wird. Im Verlauf der bestehenden Session kann der Kunde Datenpakete im Up- und Downstream zum Endkunden in diesem S-VLAN transportieren.
In den PPPoE- und DHCP-Session-Control-Frames werden dem Kunden in einem definierten C-VLAN-Bereich weitere Informationen übermittelt (z. B. Anschlusstyp, synchronisierte RAM-Geschwindigkeit, Line-ID – siehe Ziffer 2.4)
Bei L3-BSA (BSA_Gate) kann der Mitbewerber ueber das verwendet Realm den Transportweg vom T-Netz ins eigene Netz beeinflussen. Die Standardvertraege zu den BSAs sind da relativ aufschlussreich.
