Glasfaser FTTH: 1&1 Versatel erhält Zugriff auf Glasfaser der Telekom

[KernelMaker]

Wie hast du als Privatkunde einen Glasfaseranschluss von Versatel bekommen?

häää

Hab ich doch gar nicht. Das ist ein 1&1 FTTH über Telekom.
Und dieser kostet halt aktuell im Durchschnitt auf 24 Monate etwa 40€. Was ist daran so schwer zu verstehen?

 

[FTTH]

Trolle soll man nicht füttern.

 

[FTTC]

Habe ich richtig verstanden, dass es aktuell noch keine FTTH-Anschlüsse gibt, bei denen 1&1 über das Versatel-Netz geroutet wird?

"Mein" Ort wird nächstes Jahr mit Glasfaser von GlasfaserPlus ausgebaut, sodass auch 1&1 verfügbar sein wird. Aktuell bin ich mit dem Versatel-Netz mehr als zufrieden. Leider ist das Peering im T-Netz bei Weitem nicht so gut. Glasfaser wäre super, will mich da auch nicht beschweren, aber wenn ich zurück ins T-Netz fallen würde, wäre das schon ein Rückschritt. Wobei der Anschluss frühestens in 1 - 1 1/2 Jahren geschaltet wird. Bis dahin kann sich ja noch Einiges ändern.

 

[pufferueberlauf]

Habe ich richtig verstanden, dass es aktuell noch keine FTTH-Anschlüsse gibt, bei denen 1&1 über das Versatel-Netz geroutet wird?

Jein, bisher ist es so, dass noch kein T-FTTH-Anschluss der von 1&1 vermarktet wurde hier nachweislich anders als ueber die Telekom WIA-Plattform realisiert wurde. Das zeigt sich zum einen daran welcher "Besitzer" fuer die öffentlichen IP Adresse(n) eines Anschlusses genannt wird (z.B. per whois-Abfrage oder Abfrage beim RIPE) zum anderen am Routing (z.B. per traceroute/mtr zu bekanntem Lookingglas Server in einem Drittnetz, Lookingglas Server damit man auch den Reverse Traceroute/mtr durchführen kann; bei L2-BSA muss quasi zwingend in jeder Route ein/mehrere 1&1/Versatel Hops auftauchen). Aber insgesamt ist die Menge solcher Anschlüssen noch recht überschaubar, da kann es auch Zufall sein, dass bisher schlicht nur Anschlüsse an BNG-Standorten ohne 1&1/Versatel L2-Erschliessung betrachtet/beschrieben wurden.

 

[FTTC]

@pufferueberlauf
Danke für die Antwort! Dann wollen wir hoffe, dass auch der Zugriff über das Versatel-Netz ermöglicht wird. Versatel hat erst letztes Jahr an "meinem" Knotenpunkt, nur wenige Kilometer entfernt, einen neuen Breitband-PoP errichtet. Seitdem läuft es wirklich sehr gut und performant mit geringen Latenzen

 

[KernelMaker]

Hoffentlich kommt das noch. Das Peering wäre für mich der primäre Grund für einen Wechsel. Der Preis ist erstmal sekundär (wenn wir mal von den 10€ Differenz ausgehen).
Mein Anschluss kommt wohl am 03.05. Bin sehr gespannt.

EDIT: Gerade schon mal testweise ein gretap mit bonding aufgesetzt. Mal gucken wie das bei 2x FTTH läuft und, ob ein Single TCP Stream dann auch 2Gbit erreicht.

 

[pufferueberlauf]

Mal gucken wie das bei 2x FTTH läuft und, ob ein Single TCP Stream dann auch 2Gbit erreicht.

Dafuer waere dann WIA wahrscheinlich besser als L2-BSA, zumindest wenn ein Link bei der Telekom selber bleiben sollte, bonding ueber grob unterschiedlich geroutete Links stelle ich mir ansonsten ambitioniert vor (wahrscheinlich weil ich zu wenig Ahnung habe).

 

[robert_s]

Hoffentlich kommt das noch.

Würde ich doch annehmen, dass WIA nur eine Zwischenlösung ist, deren vorrangiger Zweck vielleicht ist, Kunden, die in FTTH-only Gebiete ziehen, künftig nicht mehr kündigen zu müssen. Erst mal Kunden halten, später optimieren.

EDIT: Gerade schon mal testweise ein gretap mit bonding aufgesetzt. Mal gucken wie das bei 2x FTTH läuft und, ob ein Single TCP Stream dann auch 2Gbit erreicht.

Bonding mit 2 WAN IP-Adressen, auf die dann auch ein einzelner TCP-Stream aufgeteilt wird? Das hätte ich auch gerne. Wie geht das?

 

[KernelMaker]

Das ist leider richtig. Wenn die Laufzeiten nicht ähnlich sind, kriegt man Spaß mit Out-of-Order Packets. Ein bisschen Tuning ist möglich, aber komplett kriegt man das nicht gelöst. Deshalb die Hoffnung, dass es bei "gleichen" Links besser geht.

Meine aktuellen Tests mit FTTH + Telekom 5G liefen aber schon ganz gut. Da kam so 150-160% statt 200% bei raus.

Multipath TCP wäre noch ein anderer Ansatz. Aber geht natürlich dann nur bei TCP.

Würde ich doch annehmen, dass WIA nur eine Zwischenlösung ist, deren vorrangiger Zweck vielleicht ist, Kunden, die in FTTH-only Gebiete ziehen, künftig nicht mehr kündigen zu müssen. Erst mal Kunden halten, später optimieren.

Bonding mit 2 WAN IP-Adressen, auf die dann auch ein einzelner TCP-Stream aufgeteilt wird? Das hätte ich auch gerne. Wie geht das?

Das geht mit einem beliebigen Layer 2 Tunnel z.B. gretap (wenig overhead) und einem bonding interface darüber. Das Bonding läuft dann mit balance-rr = round robin.
Braucht natürlich einen Server auf der anderen Seite, der die Pakete wieder zusammenschubst mit > 2G Uplink. Habe dazu einen 10G Dedicated Server angemietet.

Übrigens nutzt auch Huawei eine getunte Variante von GRE für den Hybrid Tunnel. Das wäre also auch ein Ansatz. Habe ich aber noch nicht weiter verfolgt.

Ansonsten wie gesagt das hier: https://www.openmptcprouter.com
Anderer Ansatz mit Multipath TCP. Läuft deutlich stabiler.

 

[pufferueberlauf]

Multipath TCP wäre noch ein anderer Ansatz. Aber geht natürlich dann nur bei TCP.

Gibt bei der IETF Bestrebungen auch MultiPath-Varianten fuer Nicht-TCP Protokolle (z.B. fuer DCCP) zu spezifizieren.

Würde ich doch annehmen, dass WIA nur eine Zwischenlösung ist, deren vorrangiger Zweck vielleicht ist, Kunden, die in FTTH-only Gebiete ziehen, künftig nicht mehr kündigen zu müssen. Erst mal Kunden halten, später optimieren.

Kann sein, andererseits kann man auch spekulieren, dass es interessant ist, dass gerade mal der Reseller der auch WIA im Program hat, T-FTTH anbieten kann, waehrend die beiden anderen die IMHO ueber L3-/L2-BSA arbeiten bisher keine T-FTTH Anschluesse vermarkten obwohl da IIRC auch schon Absichtserklaerungen abgegeben wurden. Wie gesagt, kann Zufall sein, oder aber daran liegen, dass vielleicht die Telekom bisher nur einen akzeptablen Prozess fuer WIA bereitstellt... Wie gesagt Spekulatius... das sollte sich auch klaeren, wenn die ersten 1&1 Anschluesse beschrieben werden die nachweislich in von 1&1 per L2 erschlossenen BNG-Standorten produziert werden; nutzen die BSA spricht viel fuer Zufall, bleiben die bei WIA dann dürfte es technische/wirtschaftliche Gründe haben.

 

[KernelMaker]

Woher sieht man das denn? Gibts da interne Infos oder sogar eine Karte?
Vielleicht kann Andreas dann helfen?

 

[0-8-15 User]

Wenn die Laufzeiten nicht ähnlich sind, kriegt man Spaß mit Out-of-Order Packets.

Übrigens nutzt auch Huawei eine getunte Variante von GRE für den Hybrid Tunnel.

Ja, bei Hybrid wird das Problem offenbar dadurch gelöst, dass die Reihenfolge, mit der die Pakete in die Tunnel geschubst werden, auf beiden Enden durch nachträgliches Umsortieren wiederhergestellt wird (siehe: Huawei's GRE Tunnel Bonding Protocol: 4.4. Traffic Recombination).

 

[KernelMaker]

Genau, das müsste doch eigentlich gar nicht so schwer sein.
Angenommen man markiert jedes Paket aufsteigend.
1 -> WAN1
2 -> WAN2
4 ...
6
8

Wenn das dann falsch ankommt z.B.
2
4
1
6
8
Dann weiß doch das System wie es wieder zusammensetzen soll.


Was dem Linux Bonding leider auch fehlt ist eine Verteilung nach Link-Geschwindigkeit
Also bei unterschiedlichen WAN Links z.B. 1000 und 200, müsste man einstellen können, dass 5x so viele Pakete durch WAN1 gehen.
Auch das hat Huawei implementiert.

 

[pufferueberlauf]

Woher sieht man das denn?

Was denn genau?

Gibts da interne Infos oder sogar eine Karte?

Auch wenn ich nicht genau weis was Du meinst, kann ich klar verneinen interne Infos oder Karten zu kennen.

Vielleicht kann Andreas dann helfen?

Wäre in der Tat interessant von Andreas zu hören ob T-FTTH-Resale heute schon über die BSAs realisiert werden kann, aber bin nicht sicher ob er sich zu solchen Fragen äußern will/darf/soll?

 

[KernelMaker]

Was denn genau?

Sorry, das war nicht ganz klar
Also ob 1&1 an meinem (BNG) Standort vertreten ist oder halt nicht.

 

[pufferueberlauf]

Was TCP

Angenommen man markiert jedes Paket aufsteigend.

Was TCP (das mit Abstand am Re-Ordering sensitivste Protokoll) ja schon im Header eingebaut hat... die Sequence number. IMHO ist das Problem bei solchen Re-Ordering Spielchen, dass wenn Paketverluste auftreten der Re-Order sich überlegen muss wie lange er maximal warten will, und das führt dann zu Jitter und oft noch schlimmer zu bursty Transmission aller Pakete die bereits out-of-order angekommen waren.... klar kann man statt der Protokoll-Sequenznummer einen eigenen Zähler im Tunnel-Header verwenden, aber das Problem mit verlorenen Paketen loest man damit auch nicht zumindest nict wenn die auf der getunnelten Strecke floeten gehen.

Ergänzung (22. April 2022)

Also ob 1&1 an meinem (BNG) Standort vertreten ist oder halt nicht.

Ak, okay. Keine Ahnung, aber wenn Du einen FTTC-Anschluss von 1&1 auf FTTH upgradest, würde ich erstmal erwarten, dass das PON am selben BNG-Standort terminiert wird wie die FTTC Strecke und dann sollte sich am WIA/BSA Status nichts ändern. Und den Status sollte man empirisch ueber traceroutes herausfinden koennen.

Ergänzung (22. April 2022)

Also 1&1 hat da bestimmt Karten und weis wo BSA gemacht wird und wo WIA, vielleicht kann da das 1&1 Forum weiterhelfen, entweder offiziell oder durch Finden eines FTTC-Kunden an gleichen BNG?

 

[KernelMaker]

Was TCP (das mit Abstand am Re-Ordering sensitivste Protokoll) ja schon im Header eingebaut hat... die Sequence number. IMHO ist das Problem bei solchen Re-Ordering Spielchen, dass wenn Paketverluste auftreten der Re-Order sich überlegen muss wie lange er maximal warten will

Genau, und das geht natürlich bei gleichen Links am besten. Die Wartezeit lässt sich über die sys options ändern. Dann wirds auch etwas stabiler. Naja ich werde berichten.

Zumindest hatte ich das früher auch mal lokal mit 2x 1G Ethernet ausprobiert und zusammen mit MTU 9000 auch wirklich 200% rausbekommen.

Ak, okay. Keine Ahnung, aber wenn Du einen FTTC-Anschluss von 1&1 auf FTTH upgradest, würde ich erstmal erwarten, dass das PON am selben BNG-Standort terminiert wird wie die FTTC Strecke und dann sollte sich am WIA/BSA Status nichts ändern. Und den Status sollte man empirisch ueber traceroutes herausfinden koennen.

Die Info kriege ich leider nicht weil es ja ein Neuanschluss ist. Von den Nachbarn hat natürlich auch leider keiner 1&1. macht ja auch keinen Sinn, wenn es hier FTTH im Haus gibt. Müsste ich wenn dann ein paar Häuser weiter erfragen.

 

[kingpin42]

Genau, das müsste doch eigentlich gar nicht so schwer sein.
Angenommen man markiert jedes Paket aufsteigend.
1 -> WAN1
2 -> WAN2
4 ...
6
8

Wenn das dann falsch ankommt z.B.
2
4
1
6
8
Dann weiß doch das System wie es wieder zusammensetzen soll.


Was dem Linux Bonding leider auch fehlt ist eine Verteilung nach Link-Geschwindigkeit
Also bei unterschiedlichen WAN Links z.B. 1000 und 200, müsste man einstellen können, dass 5x so viele Pakete durch WAN1 gehen.
Auch das hat Huawei implementiert.

Einer der Lösungsansätze dafür wäre in OSS/proprietären SD-WAN Lösungen zu suchen, also die Kombination mehrerer Access-Technologien zur Steigerung des Durchsatzes bzw Erhöhung der Ausfallsicherheit (Letzteres geht aber auch fast immer mit Bordmitteln wie einer zusätzlichen Defaultroute mit höherer Metrik).

 

[robert_s]

Was TCP (das mit Abstand am Re-Ordering sensitivste Protokoll) ja schon im Header eingebaut hat... die Sequence number.

Ich denke mal, für TCP ist das auch nicht primär gedacht, denn das hat ja die Mechanismen für out-of-order Empfang bereits eingebaut. Da würde ich solche Spielereien sogar eher lassen, denn die könnten das Ergebnis auch verschlechtern.

IMHO ist das Problem bei solchen Re-Ordering Spielchen, dass wenn Paketverluste auftreten der Re-Order sich überlegen muss wie lange er maximal warten will, und das führt dann zu Jitter und oft noch schlimmer zu bursty Transmission aller Pakete die bereits out-of-order angekommen waren....

Ich sehe die Anwendung eher bei Protokollen, die keinen inhärenten Reordering Mechanismus haben, also ICMP oder UDP, sprich: Ping und Online-Gaming. Wobei es zumindest auch beim letzteren zu einer Beeinträchtigung ggü. evtl. im Spiel vorhandenen Mechanismen führen kann.

 

[pufferueberlauf]

Ich denke mal, für TCP ist das auch nicht primär gedacht, denn das hat ja die Mechanismen für out-of-order Empfang bereits eingebaut. Da würde ich solche Spielereien sogar eher lassen, denn die könnten das Ergebnis auch verschlechtern.

Jein, TCP ist getuned fuer das geringe Niveau an Re-Ordering das halt passiert, aber ISPs wuerden gerne verstaerkt parallele Pfade nutzen (aka Bonding) aber das geht nur wenn dadurch das Re-order-Niveau nicht zu stark erhoeht wird... 3 DupACKs und TCP vermutet Packetloss und tritt auf die Bremse... d.h. re-odering Buffer sind gerade fuer TCP wichtig, machen aber halt auch den Vorteil von Bonding zunichte (zumindest fuer ISPs bei BackBone Links).

Ich sehe die Anwendung eher bei Protokollen, die keinen inhärenten Reordering Mechanismus haben, also ICMP

ICMP echos verwenden eine Sequenznummer...

oder UDP,

UDP hat in der Tat keine Sequenznummer.... wenn die Applikation so etwas braucht muss sie das halt selber in der Payload implementieren, aber dann haben Middleboxen (wie Bonding-Endpunkte, bei einer nicht-end-to-end Bonding Strecke) halt ohne zusaetzlichen Header keine Moeglichkeit die Reihenfolge wieder herzustellen.

Ping und Online-Gaming. Wobei es zumindest auch beim letzteren zu einer Beeinträchtigung ggü. evtl. im Spiel vorhandenen Mechanismen führen kann.

Ja, wobei viele Spiele in Bursts (z.B. alle 17ms) senden/empfangen und Re-odering innerhalb der Pakete eines Bursts duerften sich noch ausklamuesern lassen; wenn gleich gar die Bursts vermischt werden, dann duerfte das groesse Problem sein, dass Pakete die zu Burst 1 gehoeren aber erst mit Burst 2 geliefert werden wahrscheinlich zu alt sind um noch sinnvoll ausgewertet zu werden. Habe aber von Spiele Traffic wenig Ahnung.