Einfache Policer (ohne Burst-Toleranz) sind halt garstig zu klassischem TCP... das faellt bei Datentransfers ueber etwas laengere RTTs schnell auf.
Bursten können die Juniper Policer, längere RTTs hat man ja oft nicht. Selbst der am weitesten entfernte WLP von uns mit RTT von ~25-27 ms hat damit keine Probleme. TCP stellt sich darauf ja relativ schnell ein und passt die Windowsize entsprechend an.
Einfache Policer (ohne Burst-Toleranz) sind halt garstig zu klassischem TCP... das faellt bei Datentransfers ueber etwas laengere RTTs schnell auf. Verwendet Ihr echt noch Policer um Kunden auf ihre Vertragsraten zu begrenzen, oder habe ich nur ein veraltetes Bild dessen was einen Policer auszeichnet?
Das dürfte in den meisten Fällen so sein, jedenfalls dort, wo Nokia/Cisco/Juniper BNGs zum Einsatz kommen. Die haben dort alle ein Ressourcenlimit und können nicht für ein paar 100k Kunden all ihre Sessions shapen.
OT: wir policen am OLT, nur L3/L2BSA Vorleistungen anderer Provider außer Vitroconnect policen wir am BNG.
Ja so wie es aussieht haben die eine Gigabit und eine 10Gigabit Loesung im Angebot, d.h. bei den meisten Tarifen kommt ein normaler Traffic-Shaper zum Einsatz. Was per se nichts schlimmes ist.
Dürften Policer sein, sind nicht so ressourcenhungrig wie Shaper.
Genau deshalb sind die mit Abstand meisten Geschäftskunden mit ihrem Festnetzanschluss bei der Telekom.
Mein Provider Easybell bietet gar keine ONTs an. Aus den o. g. Gründen setze ich am Glasfasernetz der Telekom natürlich einen ONT der Telekom ein, der aus Sicht des TKG aber mein eigener ist, da ich als Privatkunde gar keine Geschäftsbeziehung mit der Telekom unterhalte.
Die Telekom als einer der wenigen Vertreter der Endgerätewahlfreiheit bietet ihren ONT nämlich preisgünstig zum Kauf an. Wenn ich an meinem Glasfasernetz vorrangig vorrangig Hardware aus eigenem Haus haben möchte, kann ich Endkunden auch anders als mit Gesetzesbrüchen oder Widersprüchen gegen behördliche Anordnungen motivieren, genau diese einzusetzen. In meinem Fall hat das funktioniert.
Wir reden meine ich von völlig verschiedenen Geschäftskundenanschlüssen. SoHo ist hier explizit nicht gemeint. Wenn dir die Telekom einen Company Connect Anschluss stellt, bestimmt sie auch das Demarkationsgerät. Da ist dann auch bei der Telekom Schluss mit Endgerätefreiheit. Indes kenne ich auch keinen einzigen Geschäftskunden, der auf einen eigenen ONT pochte. Die wollen, wie bereits gesagt, möglichst viel Schuld im Fehlerfall auf den ISP übertragen können. Das widerspricht sich mit einem eigenen Endgerät.
Ich würde meinen, damit ist GPON gemeint. - Weil eben ein Signal reingepumpt wird, und erst der ONT beim Endkunden filtert die Daten dann wieder.
Wenn das so ist, dann ja. Also zumindest wir schalten gewisse Bandbreiten auch über (G)PON, meistens dann, wenn keine durchgehenden Reservefasern zum PoP mehr frei sind. Diese Kunden bekommen dann aber eine garantierte Leistung, werden also vor etwaigen (wenn es welche in deren Gebiet geben sollte) Privatkunden priorisiert, sodass die ihre Bandbreite immer haben. Da gehen dann natürlich auch weitere Businessanschluss-Merkmale, wie geroutete v4-Netze in diversen Größen.
Da kam aber noch kein Kunde auf die Idee, einen eigenen ONT einsetzen zu wollen. Die möchten möglichst viel auf den Provider abwälzen können, im Problemfall. Da wäre ein eigener ONT eher schlecht.
Was sind denn passive FTTH Anschlüsse ?
Ich habe die Einstellungen bei aktivierter Dualstack Option exakt so und erhalte nachwievor keine IP via IPCP (PPPoE). Hatte nun auch den ONT nochmal mehrere Stunden vom Stromnetz, bringt keine Besserung. Anruf bei der Hotline, ja Dualstack sei aktiv und ja sie sehen meine Auth Anmeldungen aber danach käme kein Traffic.
Beim Telekom DSL PPPoE sieht das Log so aus. Per IPCP erhalte ich erst die Gateway IP und danach dann einen ähnlichen IPCP Block für meine DSL IP
Code[opt1] IPCP: SendConfigReq #1 [opt1] IPADDR 0.0.0.0 [opt1] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [opt1] IPCP: rec'd Configure Request #129 (Req-Sent) [opt1] IPADDR 62.155.246.1 [opt1] 62.155.246.1 is OK [opt1] IPCP: SendConfigAck #129 [opt1] IPADDR 62.155.246.1 [opt1] IPCP: state change Req-Sent --> Ack-SentBeim DGN PPPoE erhalte ich sofort ein IPCP rejected zurück
Code[opt2] IPCP: SendConfigReq #1 [opt2] IPADDR 0.0.0.0 [opt2] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid [opt2_link0] LCP: rec'd Protocol Reject #198 (Opened) [opt2_link0] LCP: protocol IPCP was rejected [opt2] IPCP: protocol was rejected by peer [opt2] IPCP: state change Req-Sent --> Stopped [opt2] IPCP: LayerFinishMuss ich noch irgendwas in den PPPoE advanced Options einstellen? Habe es so belassen wie beim DSL PPPoE:
Versuch mal die ganzen Compressions auszuschalten.
Roger. Welche Groessenordnung hat den der Stromverbrauch an den Betriebskosten (ganz grob)?
Höre ich bei uns mal nach, weiß ich aus dem Stehgreif leider auch nicht.
und die gehoeren ja IMHO auch der Telekom und helfen daher anderen ausbauenden ISPs nur bedingt weiter.
…die Telekom rührt für konkurrierende ISP nicht einen müden Finger, eher wirft sie dir KFZ-Große Felsbrocken vor die Füße und macht dir das Leben extra schwer. Können davon leider ein Lied singen, noch zu Zeiten des Vectoringausbaus.
Leider alles nur für einen überschaubaren Kundenstamm überhaupt buchbar.
Wuerde das nicht so ernst nehmen... je nach dem wie man den Stromverbrauch berechnet, ist AON sogar guenstiger als PON... und die Stromkosten machen nur einen kleinen Teil der Betriebskosten aus...
Das stimmt aber nur bei einem sehr sehr kleinen PoP. Bei den Üblichen 4-8 Slot Chassis, die gut und gerne auch mal >4000 Teilnehmer versorgen ist es das genaue Gegenteil. Da kommt das Gutachten, Pro-PtMP hin oder her, auch ganz gut an unsere Praxiserfahrungen ran.
Der PtMP-Ausbau ist vornehmlich wegen der fehlenden Akzeptanz in Kommunen/Städten geschuldet, Garagengroße PoPs (oder noch größere Bauten) in zentralen Lagen zu dulden. Bei AON müsste man mehr PoPs setzen, die allesamt natürlich auch einen Stromanschluss (der ja schon pauschal Geld kostet, ohne das Strom drüber fließt) benötigen. Evtl. würde das auch zu einer komplexeren Trassenplanung oder Mehrbedarf an Trassen führen, was natürlich auch Preistreiber ist.
Es gehören gesetzliche Vorgaben wie bei DSL her. Da gibt es richtiges "OpenAccess" weil alles gesetzlich geregelt ist.
Allerdings glaube ich auch dass bei solchen Vorgaben sich der Ausbau verlangsamen wird. Deswegen sollte einfach noch paar Jahre fleißig weiter ausgebaut werden und dann sollte eingegriffen werden.
Die Vorleistungspreise wären die meisten Kunden wohl nicht mehr bereit, zu zahlen. Evtl ändert sich jetzt was mit der neuen Regierung und den Vorgaben für betriebliche Abschreibungen. Erst müssen sich die gebauten Netze amortiesiert haben, dann kann man über regulatorische Eingriffe und einheitliche Vorleistungspreise sprechen.
Welcher T1 ist schon gänzlich unproblematisch gewesen in den vergangenen 10-15 Jahren 
Die Disputes mit HE sind ja schon fast älter als das Internet, mit NTT ist wohl an mir vorbei gegangen, hatten aber nie Probleme mit deren Support und nur wenig Probleme mit der allgemeinen Qualität an Routen die sie uns propagieren. Das können andere Transits auch deutlich schlechter, selbst DTAG bei regulierten A10 NSP Übergabeschnittstellen, wo man statt L2TP aus DTAG internen Netzen plötzlich mit Traffic von Amazon geflutet wird.
Wenn man selbst sehr latenzsensible Kunden hat, sollte man sich imho allgemein nicht auf andere Provider verlassen, sondern die Strecken selbst betreiben.
Das mit den Salestaktiken ist natürlich ärgerlich, insbesondere wenn dann eigentlich für andere Zwecke vorgesehene admin/tech-c Mailadressen für Angebotsbombing benutzt werden. Das kennen wir aber auch von ein paar osteuropäischen IXPs so, weswegen wir dort erst Recht keinen Port buchen werden. So oft registriere ich aber auch keine neuen ASNs, daher kann ich da nicht mitreden 
Lief Cogent <-> DTAG jemals richtig gut ? Zahlen hier leider auch zähneknirschend den hohen Faustpfand an die Telekom.
Wohlgemerkt in anderen Ländern hat ein einziger Haushalt einen 10Gbit/s-Anschluss, nicht eine komplette Region.
Und hängen dann trotzdem oft an max. n*10G im Backhaul.
MSANs der DTAG hängen auch in den allermeisten Fällen an 1G Schnittstellen, und das reicht dann auch aus. Würde dem Ganzen jetzt wenig Bedeutung zumessen.
Jetzt moechte ich anmerken, dass Cogent nicht ganz unproblematisch ist als Transitprovider
Wie kommst du da drauf ? Wir haben Cogent seit 20 Jahren im Transitmix und gerade in den letzten Jahren positiv überrascht, sowohl von der Qualität der Routen als auch dem Support.
Erfreuliche Nachrichten für Kunden, die daheim eine pfSense CPE einsetzen, und sich über eine schnelle Glasfaseranbindung via PPPoE einwählen müssen:
Der neue if_pppoe Treiber ermöglicht endlich Multi-Gigabit Speed durch die Nutzung von Multithreading im Packet Processing und Codeoptimierung.
Ich werde das mal mit unserer Carriergegenstelle testen und hier dann berichten, was für einen Unterschied das genau aus macht.
O2 kauft L3-BSA bei der Telekom ein, da muss O2 klar sagen wohin der Traffic getunnelt werden soll, also zu welchem POP und dann geht aller Traffic darueber, weil die Telekom gar nicht auf die weiteren Header guckt..
Ist zwar OT aber der Korrektheit halber:
o2 sagt der Telekom nicht, wohin der Traffic gehen soll. Die Telekom vergibt den Resellern LNS-Loopback-Adressen aus ihrem Range, und an diese Adressen verteilt sie die Sessions im Round-Robin Verfahren direkt von ihren LAC-IPs, für die jeweils ausgemachten und fest definierten Realms. Dazu muss man auf den Übergaberoutern/LNS auch >2000 statische Routen zu den Telekom LACs anlegen. Von dynamischem Routing hält die Telekom an diesen regulatorisch definierten Übergabeschnittstellen leider nicht viel.
Nein, ich meinte schon die UGG Infrastruktur. Es dürfte sehr ungewöhnlich sein, dass ein DSLAM der DTAG auf mehrere BNGs/LACs geschaltet wird. Bei der UGG könnte ich mir das vorstellen. Daher die Frage nach dem Ergebnis eines AC Sniffings.
Wenn die UGG bald anfängt bei meinen Eltern zu graben, könnte ich dazu auch selbst auf die Suche gehen. Bis dahin wird aber noch viel Wasser den Rhein runter fließen.
Wenn die Verbindung via PPPoE aufgebaut wird, könnt ihr mal versuchen, die Access Concentratoren zu „ersniffen“. Es gibt Router, bei denen man angeben kann, zu welchem Access Concentrator man sich verbinden möchte. Mikrotik und OpenWRT können das zB.
Dieser Thread ist wirklich die beste Glasfaserbuden-Antiwerbung, die man vorstellen kann.
Es ist sprichwörtlich alles teurer, schwieriger, komplizierter und mehr Scherereien verbunden als anderswo.
Und diese Glasfaserfritzen fragen sich immer noch, warum die Verbraucher lieber DSL nehmen...
Ich glaube du lebst in einer Traumwelt. Zu Glauben, dass bei der DTAG alle Prozesse reibungslos implementiert sind, oder das damit jede Eventualität abgedeckt ist, weils ja der Marktführer macht, ist Absurd und an der Realität vorbei.
Wir reden aneinander vorbei. Die DG moechte nicht dass Endnutzer die Credentials sehen koennen, ansonsten wuerden diese entweder per Brief oder im Kubdencenter mitgeteilt werden. Der Umstand, dass hier ein Endkunde diese Credentials relativ einfach hat mitschneiden koennen ist IMHO kein Zeichen von Kompetenz.
Ich wär mir da gar nicht so sicher, dass die DG das absichtlich macht. Ich glaube da viel eher an nicht implementierte Prozesse für das Anzeigen der SIP Daten im Kundenportal, bei gleichzeitiger Verwendung/Miete eines DG Routers mit fernkonfigurierten SIP-Daten.
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
