Beiträge von kingpin42

    Das kann auch die Fritz!Box händeln.
    Du musst dir bei tunnelbrocker.net oder sixx.net eine IPv6 Range anlegen. Anleitungen wo du was eintragen musst in der FB gibt es genug.

    Hier Beispiel bei HE und nein nutze ich nicht, siehe Datum, nur zum Test erstellt. :P

    Die v6-Blöcke der bekannten Broker werden bei Netflix und Co. ausgesperrt. Damit hatten auch Kunden von uns Probleme die mangels nativem v6 solche Dienste in Anspruch nehmen mussten, bis ich ihnen dann einen kurzfristigen Worksround mit v6 Adressen von uns gebastelt hatte.

    Einige sind hier im Forum mit FTTH-Anschlüssen unterwegs, die zum ersten Hop im Provider-Netz anscheinend RTTs von deutlich unter 10ms, teilweise so 4-5ms haben. Bei mir sind es nie weniger als 12ms (direkt auf dem Router gemessen bzw. auch aus Interesse einmal mit direkt mit dem ONT verbundenen PC und pppoe-client).

    Das hängt vielerorts von den Standorten der PoPs und der nächsten Netzebene ab. Größere Provider mit vielen Aggregations- und Übergabestandorten wie die DTAG oder o2 sind hier natürlich im Vorteil.

    Noch dazu sieht man Vieles nicht in normalen Traces, siehe:

    Ein MPLS aware traceroute

    aber ich habe mich gefragt, wie eigentlich die Provider ihre Netze organisieren und wie das ganze technisch umgesetzt ist. Also wird z.B. direkt im PoP aggregiert bzw. wie oft und wo werden die unterschiedlichen Datenströme aggregiert, bis das Signal an irgendeinem Peering Point übergeben wird, wo steht eigentlich so ein Backbone-Router des Providers (bis dort wird ja wahrscheinlich auf Layer 2 geswitcht), was sind so übliche Anbindungen für einen PoP (10G? 40G?) usw.

    Im "Normfall" (und bei uns, also z.B. E.ON Highspeed) und aktuell (befindet sich im Wandel, Stichwort VOLTHA/vOLT): ONT -- ("U-Schnittstelle") -- OLT -- Aggregation (meist im selben PoP wie der OLT) in Form eines Metro Ethernet Knotens mit hoher Reichweite (200 km+, oft fälschlicherweise auch "MPLS-Knoten" genannt, obwohl der gar kein Label Switching betreibt) -- BNG (Carrier High-End Router mit spezieller Software/Subscription) -- ("A10-NSP oder NNI-Schnittstelle") -- Andere Carrier (via L2BSA als 802.1ad/QinQ Traffic) oder das eigene Backbone-Netz, wobei hier auch weitere Metro Ethernet Knoten bis zum eigentlichen Backbone-Router dazwischen geschaltet sein können. MEF Verbindungen bewegen sich auf Layer1/2, meist als E-Line oder E-Tree geschaltet.

    Also ja, es kann schon direkt im PoP aggregiert werden.

    Backbone-Router sind normal größere Chassis-Systeme mit entsprechenden Anforderungen an Stromversorgung und Klimatisierung, weshalb die idr. auch in Rechenzentrumsähnlichen Gebäuden zu finden sind. Der BNG kann dabei entweder auch an so einem zentralen Standort stehen, oder aber vorgelagert sein, ist jedoch idr. nicht im lokalen PoP anzutreffen.

    Übliche Anbindungen von OLTs sind n*10G, seltener n*40G oder n*100G. Die Kosten für viele 40/100G-Ports an einem BNG sind ungleich höher als die von 10G Ports.

    Darüber habe ich nirgends im Netz was gefunden, vielleicht ist das auch zu viel Insider-Wissen. Aber irgendeine Form von best practice wird es vielleicht doch geben?

    Über Metro Ethernet kennen sich auch nur wenige Leute wirklich aus, weil es eben nur einen eingeschränkten Einsatzbereich dafür gibt.

    Und irgendwoher muss der Unterschied zwischen 4ms und 12ms ja auch kommen.

    Das wurde ja hier schon von frank_m dargelegt, das man erstmal richtig messen muss, also die echte Ende-zu-Ende Latenz zum gewünschten Ziel, am Besten als UDP/TCP-Datenstrom.

    Das ist dann doch aber auch eine geschäftliche Tätigkeit mit Gewinnerzielungsabsicht. Da dürfte ja dann ein Business Anschluss Sinn machen.

    Ich persönlich habe das Gefühl das der Jitter bei einem 1:64 Splitter schon so um 0,2-0,6ms höher ist. Bei uns im Ort hat die Grundschule P2P FTTH von der DG und der Jitter liegt bei 0ms. Ich mit meinem PK Anschluss habe einen Jitter von ca 1,1ms(PON). Ein Kumpel im Nachbarort der auch GPON hat, hat einen Jitter von 0,5ms, er lebt in einem eher abgelegenen Gebiet mit 8 Häusern. Naja das merkt man jetzt im Alltagsbetrieb nicht, aber im vergleich zum GPON FTTH der Deutschen Telekom und normalem DSL ist 1-2ms Jitter schon relativ hoch, da man mit genannten Techniken meist eher 0-0,6ms Jitter hat.

    Kann ich nicht bestätigen, bei größerer Auslastung kann es natürlich zu vermehrtem Jitter kommen.

    Transit ist das Gegenteil von dem, was du meinst. Als "Transit" bezeichnet man, wenn ein Provider Daten durch sein Netz leitet, die weder aus seinem Netz stammen, noch für sein Netz bestimmt sind. Die Telekom hätte es gerne, wenn ISPs als Kunden einen Zugang zum Telekom-Netz bezahlen, anstatt diesen Zugang als Transit durch die Netze anderer Provider zu bekommen. Häufig wird vermutet, dass die Transit-Kapazitäten der Telekom etwas knapp bemessen sind, damit ein Anreiz besteht, die Telekom für einen direkten Zugang zu bezahlen

    Die Telekom verkauft kein Paid-Peering, Sie verkauft nur Transit. Du bekommst als Kunde IMMER eine Fulltable. Da darfst du gerne mal einen Sales-Rep von der DTGC-Sparte oder entsprechende Personen auf der DENOG-ML/deren NOC anfragen. Du musst das als Kunde dann natürlich nicht als Transit nutzen, das steht wieder auf einem anderen Blatt.

    Unabhängig davon stimmt es für diesen Fall natürlich, das hier augenscheinlich (und vorerst) kein vorsätzliches Unter-Peering an der niedrigeren Leistung verantwortlich ist.

    Kapazitätslimits in der Übertragung bei den Providern scheiden aus, da ja ohne VPN die erwarteten Übertragungsraten erreicht werden.

    Das stimmt, allerdings nur dieses mal. Wir haben dieselben Upstream Provider wie die DG, es gab auch Zeiten in denen man die Endkunden der Eyeball-ISP gut erreichen konnte, das kann sich jedoch auch schnell ändern. Level3,Telia und Cogent sind jedenfalls kein Garant für eine gute Konnektivität zur DTAG, das kann nur ein direkter oder indirekter Transit sein.

    Da die DG kein Transit von der DTAG bezieht, wundern mich unterirdische Datenraten eigentlich überhaupt nicht. Teste es mal mit IPv6 an beiden Enden, aber ich glaube da nicht an Besserung. Diesselbe Thematik hatten unsere Kunden auch, da hilft nur sich damit abzufinden oder als ISP Transit bei der Telekom einzukaufen.

    Aus dem Forum ist zu erkennen, das die Provisionierung im GPON von Providern, die PPPoE verwenden relativ leicht möglich ist. Die Telekom benötigt dazu lediglich die AVM Modem-ID (AVMG....), das bedeutet allerdings nicht, das es Deutsche Giganetz ebenso implementiert hat oder ohne Druck von außen willig ist das umzusetzen.

    Würde mich arg wundern wenn dem so wäre, zumindest bei Nokia ist es nicht so. Da hat das Adressvergabeverfahren keinen Einfluss auf die Provisionierung im PON. Bevor da die ersten PADI/PADO Frames über die Leitung wandern ist das ONT bereits im PLOAM State 5 und damit im PON provisioniert.

    Ich vermute (!) ebenfalls, das bei der Provisionierung im GPON mehr Parameter als tatsächlich benötigt abgefragt/berücksichtigt werden. Aus welchen Gründen auch immer. Das könnte in Folge zu der 5530/5590 Problematik führen.

    Wird beispielsweise (aus /var/log/avm_fiber_mgmt.txt) die Serial an den falschen Stellen nicht flexibel gehandhabt:

    CPE Vendor Serial Number (String)= DC15C8CH1CJ3 F!Box5530 257.07.26

    und lediglich die macdsl benötigt dabei aber auf F!Box5530 (plus HW-Version und OS-Version) verpflichtend geprüft, ist eine Provisionierung der 5590 nicht möglich. Aber wie schon geschrieben es ist alles nur eine Vermutung ohne einen Beleg dafür zu haben.

    Es ist allenfalls ein Beweis, das die Provisionierung im GPON nicht ein einfaches AEG ist. Trotzdem muss man daran arbeiten ein Auspacken - Einschalten - Geht Zustand im Sinne des bezahlenden Kunden zu erreichen.

    Eigentlich nicht, wir benötigen z.B. nur die Seriennummer des ONT:

    Interessant ist ebenfalls das Dokom21 keine nach TKG verpflichtende Schnittstellenbeschreibung für FTTH auf deren Webseiten anbietet.

    Müssen Sie auch nicht:

    Zitat von § 74 Abs. 3 Satz 1 TKG

    (3) Die Pflicht zur Veröffentlichung nach Absatz 1 ist erfüllt, wenn die Angaben im Amtsblatt der Bundesnetzagentur veröffentlicht werden. Erfolgt die Veröffentlichung an anderer Stelle, hat der Betreiber öffentlicher Telekommunikationsnetze die Fundstelle umgehend der Bundesnetzagentur mitzuteilen. In diesem Fall veröffentlicht die Bundesnetzagentur die Fundstelle in ihrem Amtsblatt oder auf ihrer Internetseite.

    Aber im Übrigen ist Sie dort wohl vorhanden (wenn auch teilweise unvollständig):

    https://www.dokom21.de/fileadmin/DOKOM21_Privatkunden/Downloads/Schnittstellenbeschreibung_Internet-Access_2022_01.pdf

    An Broadband Network Gateway (BNG) Anschlüssen weiß die Technik, über welchen Anschluss ein Router angeschlossen ist, und nutzt diese Information, um die Zugangsdaten automatisch im Router fernzukonfigurieren. Die eigentliche Internetverbindung findet dann trotzdem über PPPoE mit den Zugangsdaten statt, die der Kunde auch per Post bekommt (für den Fall, dass dieser Automatismus nicht unterstützt wird).

    Das stimmt so nicht. Der RADIUS prüft bei solchen Anschlüssen einfach nicht die Einwahlkennung, sondern matcht die Line-ID und gibt dem BNG grünes Licht. Das Kunden CPE wird da in keinster Weise berührt.

    Die Darmstädter Flexoptix hat bei den Systemhäusern einen guten Ruf, gerade wenn man nicht die Cisco Originalmodule verwenden möchte.

    Aber ja, bis jetzt habe ich tatsächlich noch nie SMF bei Servern gesehen. Irgendwie ist das im Rack bei 10GbE auch oversized....

    Noch zwei Fragen: Supported HP die Verwendung von Fremdmodulen in deren Systemen? Gibt es einen Supportcall bei HP, wenn das SFP Modul defekt ist oder nehmt ihr das auf eure Kappe?

    OEM Module sind für uns nicht sehr viel teurer als Welche von Flexoptics. Der Support bei Flexoptics in Kombination mit deren Flexbox ist jedoch genial und extrem schnell. Für wichtige Verbindungen bei denen der Support besonders wichtig ist setzen wir natürlich nur Module der Hersteller ein, bei allem Anderen Flexoptics. Es gab hier und da Geräte (Cisco ASR 900 hab ich da noch im Kopf), bei denen wollten 1000Base-T Module nicht laufen. Da mussten dann temporär Module von Cisco gesteckt werden. Der Flexiptics-Support hat uns dann jedoch eine geänderte Firmware für ihr Modul zukommen lassen, mit der hat der Router das Flexoptics-Modul dann erkannt.

    Wir setzen im RZ wie im Metro/Weitstrecken-Netz nur auf SM. Auch Kunden unseres RZ bekommen nur Cat6a und OS2 Patchfelder für die Verkabelung zwischen den Cabinets und als Uplink zur Verfügung. So müssen wir die Verkabelung nicht bei jeder neuen Geschwindigkeitsstufe tauschen. MTP/MPO Kabel sind auch um einiges teurer in entsprechenden Längen als SM LC-Duplex.

    Zu den HP-Fragen: ich glaube nicht das sie es tun, wir hatten diesbezüglich aber noch nie Probleme in dieser Art. Wenn dann war die Optik defekt und wurde gegen ein neues Flexoptics-Modul getauscht. Wir nehmen das also „auf unsere Kappe“.

    Achso okay, ich dachte es ginge nur um die Verbindung Switch/Leaf zu Spine/Backbone. Unsere Server sind meistens entweder via DAC oder AOC mit dem ToR verbunden, in Einzelfällen, wenn sie direkt mit dem Backbone verbunden werden müssen, sind es aber auch SM LC-Duplex Kabel.

    NICs ist eine Intel X710 OEM mit Flexoptics 10GBase-LR Modul:

    Die CWDM4 Transceiver sind nicht viel teurer als 100GBase-SR4, das gibt sich durch die evtl. deutlich höheren Kabelkosten im Endeffekt nix. Ich würde generell nur noch SM verlegen, haben wir in unseren DCs auch gemacht, die Kunden bekommen Cat6a + OS2 in ihren Cabinets. Ich kann da jetzt allerdings auch nur von großen Datacentern und Carrier Hotels reden, in Unternehmensnetzen ist das ja scheinbar anders.

    Da hier ja der Profi-Bereich angesprochen ist. Hat jemand von euch schon mit OM 5 Erfahrung gesammelt?

    Mir erscheint im RZ- und Access-Bereich der Wechsel von OM 4 auf OS 2 irgendwie sinnvoller als OM 5 in Planungen einzubeziehen.

    Soweit ich das von den bisherigen DENOG Stammtischen und von Präsentationen der großen Scaler erfahren hab, wird im DC nur noch Singlemode verlegt. OM5 vielleicht als Patch innerhalb eines Racks ?

    OS2 war ja schon immer sinnvoller, da es definierte Upgrade-Pfade von 1G bis 400G, und künftig auch 800G, gibt.

    Na ja, der Historie nach schon, jedoch wurde ADVA von ADTRAN übernommen. Und letztere Firma ist US-amerikanisch und war einmal eine Siemens-Tochter.

    Einerlei, das sind gut Produkte im WDM-Umfeld. Unverständlich ist es mir aber immer noch, das es bei ADVA keine 25 und 50 G Einstecktarten für die FSP 3000 Serie gibt und für alles andere Lieferzeiten von 6 Monaten und mehr.

    Ja aber erst kürzlich.

    25 und 50 G sind zumindest im Provider-Umfeld und bei den großen Hyperscalern nur spärlich vorhanden, da geht man lieber gleich auf 100G bzw. von den Leaf zum Core mit 400G. Aber soweit ich weiß sind die QSFP28 Ports auch abwärtskompatibel zu 25G.

    Die Lieferzeiten sind derzeit überall sehr lange, Cisco, Juniper und Arista ebenfalls. Bei Letzteren muss man sogar über 1 Jahr Zeit einplanen.