Beiträge von kingpin42

Zitat von hej

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:

Zitat von frank_m

Ein MPLS aware traceroute

Zitat von hej

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.

Zitat von hej

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.

Zitat von hej

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.

Zitat von Pascal2708

VPN wäre für meine privaten Dienste auf jeden Fall eine Option.

Storj und Myst fallen dann aber wieder raus.

Storj könnte man mit einem dezentralen OneDrive/Google Drive vergleichen. Jeder der teilnimmt erhält Kryptowährungen für das Bereitstellen von Speicher und Bandbreite.

Jeder auf der ganzen Welt kann Daten in dieses Netz hochladen/runterladen.

Daher kommen leider diese tausenden IPv4 Anschlüsse...

Solange ich damit noch etwas verdienen will bin ich leider auf IPv4 angewiesen

Es scheint aktuell also wirklich keine vollwertige Lösung zu einer öffentlichen IPv4 Adresse zu geben. Hoffen wir mal das die Telekom den Anschluss nach der Mindestvertragslaufzeit mieten darf

Alles anzeigen

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

Zitat von Rxyzr

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.

Ich verweise da auch mal auf einen guten Thread aus dem HWLuxx eines Users, der sein Haus mit MM/SM-LWL auf den aktuelle Stand der Technik gebracht hat:

Zitat von alfalfa

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.

Zitat von frank_m

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.

Zitat von HubeBube

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.

Zitat von Sascha.F

VSE NET GmbH?

Zitat von HubeBube

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:

Zitat von HubeBube

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

Zitat von alfalfa

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.

Zitat von HubeBube

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“.

Das ist GPON. Ich kanns mir aber genauer anschauen wenn du mir deine Kundennummer oder die ONT Seriennummer schickst. Wenn es unsere OLTs sind kann ich auch andere ONTs provisionieren, achte dann beim Kauf darauf das sie von Alcatel/Nokia stammen.

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:

[xxx@xxx ~]# lspci -s 5d:00 -k
5d:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
        DeviceName: Embedded FlexibleLOM 1 Port 1
        Subsystem: Hewlett-Packard Company Ethernet 10Gb 2-port 562FLR-SFP+ Adapter
        Kernel driver in use: i40e
        Kernel modules: i40e
5d:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
        DeviceName: Embedded FlexibleLOM 1 Port 2
        Subsystem: Hewlett-Packard Company Ethernet 10Gb 562SFP+ Adapter
        Kernel driver in use: i40e
        Kernel modules: i40e
[xxx@xxx ~]# ethtool -i eno5
driver: i40e
version: 5.13.8-200.fc34.x86_64
firmware-version: 10.3.5
expansion-rom-version:
bus-info: 0000:5d:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
[xxx@xxx ~]# ethtool -m eno5
        Identifier                                : 0x03 (SFP)
        Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
        Connector                                 : 0x07 (LC)
        Transceiver codes                         : 0x20 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00
        Transceiver type                          : 10G Ethernet: 10G Base-LR
        Transceiver type                          : Ethernet: 1000BASE-LX
        Encoding                                  : 0x06 (64B/66B)
        BR, Nominal                               : 10300MBd
        Rate identifier                           : 0x00 (unspecified)
        Length (SMF,km)                           : 10km
        Length (SMF)                              : 10000m
        Length (50um)                             : 0m
        Length (62.5um)                           : 0m
        Length (Copper)                           : 0m
        Length (OM3)                              : 0m
        Laser wavelength                          : 1310nm
        Vendor name                               : Intel Corp
        Vendor OUI                                : 00:1b:21
        Vendor PN                                 : P.1396.10
        Vendor rev                                : A
        Option values                             : 0x00 0x1a
        Option                                    : RX_LOS implemented
        Option                                    : TX_FAULT implemented
        Option                                    : TX_DISABLE implemented
        BR margin, max                            : 0%
        BR margin, min                            : 0%
        Vendor SN                                 : XXXXXXXX
        Date code                                 : 201021

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.

Zitat von HubeBube

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.

Zitat von HubeBube

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.

Zitat

Scalable architecture enabling up to 38.4Tbit/s

duplex capacity per fiber pair.

Noch dazu ein deutscher Hersteller

Nur die Kapazitäten an öffentlichen IXen sind öffentlich, die anderen Kapazitäten kennen wir nicht.

Woran es Abends nun bei dir und den anderen Kunden mit Minderleistung klemmt, bleibt ein Rätselraten. Die einzige Option die dir bleibt, ist eine Breitbandmesskampagne durchzuführen, und dich damit bei der BNetzA zu melden. Die hat andere Hebel und Möglichkeiten als du, und idr wird auf deren Mails auch garantiert unverzüglich geantwortet. Die Antwort gibt dir die BNetzA oft ungefiltert weiter, welche Probleme dein ISP als Ursache für die Minderleistung identifiziert hat, und wie er gedenkt, diesen Mangel zu beheben.

50 Gbit/s Public Peering Kapazität bei 30t Kunden ist sogar noch gut, was dir die Rechenbeispiele für andere große ISPs zeigen. Wir peeren mit 2x 100G am DECIX für ~130t Privat- und dutzende Geschäftskunden, und diese Links sind nie zu mehr als 50 % ausgelastet.

Jetzt Mutmaßungen anzustellen, woran das liegen könnte, halte ich für wenig Zielführend, da wir die genauen Ursachen dafür nicht kennen.