Peering und Routing gehören unzertrennlich zusammen.
Nein. Ein Provider kann ein hervorragendes Peering haben, und den Traffic von Düsseldorf nach Frankfurt trotzdem über Amsterdam leiten. Das hat nun wirklich gar nichts miteinander zu tun.
Peering und Routing gehören unzertrennlich zusammen.
Nein. Ein Provider kann ein hervorragendes Peering haben, und den Traffic von Düsseldorf nach Frankfurt trotzdem über Amsterdam leiten. Das hat nun wirklich gar nichts miteinander zu tun.
Hat aber absolut gar nichts mit dem Peering zu tun, sondern mit dem Routing des Providers.
Ein paar Tests mit mehreren anderen parallel arbeitenden Gegenstellen und einem Live Linux wären jetzt noch wünschenswert, um PC und Speedtest als Ursache auszuschließen.
Peering hat nur dann Einfluss auf die Paketlaufzeit, wenn die Knoten überlastet sind. Aber wenn das der Fall ist, machen sich weit früher andere Probleme bemerkbar, wie Paketverluste und Geschwindigkeitseinbußen.
Aus der Paketlaufzeit allein kann man nicht aufs Peering zu schließen, das ist nicht aussagekräftig.
Gut, bei GPON muss man onboarden. Das ist tausendfach auch hier im Forum nachzulesen und deshalb nicht wirklich eine Überraschung. Mich wundert, dass du Workarounds wie Werksreset im Netz findest, aber keinen Hinweis aufs Onboarding.
Ebenfalls auch hier im Forum die dringende Empfehlung, den Anschluss immer mit dem vom Provider empfohlenen Equipment in Betrieb zu nehmen. Du hast jetzt Glück gehabt, aber hätte es an deinem Anschluss eine Störung gegeben, hättest du Monate darauf warten können, dass sich jemand darum kümmert, weil es immer alle auf deine nicht unterstützte Box geschoben hätten. Danach kann man dann auf sein bevorzugtes Equipment wechseln, weil dann auch Technologien etc. klar sind, und sich Fragen nach entsprechenden SFP Modulen gar nicht mehr stellen.
Im Grunde bist du in Anbetracht der Umstände sehr problemlos an deinen Anschluss gekommen. Vor allem der Umstand, dass seitens des Providers zurückgerufen wurde, ist vorbildlich. Darüber würden andere sich freuen.
... Provider im Hintergrund offenbar 1&1, in Kooperation mit Telekom (deshalb 0800-330....).
Woher weißt du das mit 1&1 und der Telekom?
Genau. Frag mal die Leute, die EA Online Games zocken wollen, zur Peering Politik der Telekom. Achte aber auf genug Sicherheitsabstand.
Gerade das Peering ist doch das größte Argument gegen einen Telekom Anschluss.
Führt das Vorhandensein von Provider Extensions immer zu einer neuen Artikelnummer?
Meines Wissens ist die Möglichkeit, manuell Software-Updates zu installieren, nicht gegeben.
Ich kenne auch nur ONTs, die per Patchkabel verbunden werden.
Ich kenne keinen Einzigen. Wenn man sich z.B. Fibertwist Installationen ansieht, wo aktive oder passive Aufsätze auf die Bodenplatte geschraubt werden und wie dort die Glasfaser eingeführt ist: Das ist ausschließlich für die Wandmontage geeignet. Alles andere hätte den sofortigen Tod der Faser zur Folge.
Ich würde es nicht machen, gerade nicht bei diesen dünnen gelben Kabeln. Einmal falsch angeditscht, und das wars.
Ja, die Faser ist das Problem. Für die Verbindung vom HÜP zum ONT sieht der Provider ja keine Patchkabel vor, wie sie z.B. einer Fritzbox beiliegen, wie sich auf den Fotos ja einfach verifizieren lässt. Die ist nicht für den "mobilen" Einsatz ausgelegt, und wird im ONT ja häufig auch nicht gesteckt, sondern ist gespleißt. Wenn die im Schrank liegt, in den Bücher, BlueRays und sonstwas rein und rausgeschoben werden und die bekommt jedes Mal einen Stoß mit, dann ist die im Handumdrehen abgeknickt.
Die Frage ist nicht ernst gemeint, oder? Da führt ein Glasfaserkabel rein. Lebenserwartung im Schrank kleiner 1 Minute.
ZitatIn Gebieten mit sehr viel Glasfaser nehme die Telekom Linecards für die Kupferanschlüsse außer Betrieb, was auch Strom spare.
Was nicht so wirklich klar wird: Machen sie das nur in Gebieten, wo sie selber Glasfaser anbieten, oder auch in Gebieten, wo andere Provider ausgebaut haben?
Hmm. Kannst du irgendwie Statusinformationen aus den Dingern rausholen? Und sei es nur anhand von LEDs? Oder über eine Weboberfläche?
Meine Vermutung ist, dass die Verbindung vielleicht bröckelig ist.
Ja, super.
Ist im Grunde auch logisch. In deinem ersten Versuch hatte der VPS zwei VPN Gegenstellen, die beide das gesamte Netz 10.0.0.0/24 für sich reklamierten. Wohin jetzt ein Paket an z.B. 10.0.0.3 schicken? An den ersten oder an den zweiten? Offenbar hat sich der VPS für den falschen entschieden.
Nun ist es klar: 10.0.0.3 geht auf den ersten VPN Eintrag, 10.0.0.4 auf den zweiten. Keine Missverständnisse mehr.
Ich werde oft dafür kritisiert, wenn ich Subnetzmasken stark einschränke, auch im Adress-Feld der VPN Konfigurationen mache ich das gern. Oft macht es tatsächlich keinen Unterschied, aber manchmal halt doch.
welche allowed ips bekommt der peer in der server config?
Nur seine Adresse im Transportnetz (10.0.0.5/32 oder sowas reicht).
und welche allowed ips trag ich in der client config ein?
Das Transportnetz und das Heimnetz (10.0.0.0/24, 192.168.178.0/24).
Die Routen sehen gut aus. Wenn die Pings trotzdem nicht wie erwartet funktionieren, dann ist es vermutlich ein Firewall Thema.
Ok, das ist der VPS. Der sieht gut aus. Bleibt der Raspi und die zugehörige statische Route im Router.
Da die Pings vom VPS ins Heimnetz funktionieren, bedeutet das entweder, dass MASQUERADING noch aktiv ist, oder dass die Routen stimmen.
Wir nutzen Cookies und ähnliche Technologien für den Betrieb der Seite, Reichweitenmessung und Werbung. Du entscheidest, was Du erlaubst. Details in unserer Datenschutzerklärung. Deine Auswahl kannst Du jederzeit über den Link „Cookie-Einstellungen“ im Fußbereich ändern.
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