Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 3 Monaten
Naja .. wenn du es genau nimmst, hat die Telekom schon immer 1500.
Du musst aber die 8 Bytes vom PPPoE Header abziehen, wodurch du dann bei den 1492 Bytes rauskommst.
Wie du aber selbst aus der Schnittstellenbeschreibung gelesen hast (also das offizielle technische Dokument - was willst du also noch mehr?) darfst du beim GPON bis auf 2000 Bytes hoch.
1500 ist dennoch Default und das hat ja auch seinen Grund - du kannst nicht erwarten, dass du jedes Ziel im Netz mit Paketen größer 1500 erreichst.
0
vor 3 Monaten
Was ist denn das Problem was du mit einer Änderung der MTU auf dem WAN-Interface weg von den 1492 lösen willst? Ethernet-Ports haben ja standardmäßig die MTU=1500.
Die "interessantere" Frage für mich ist da eher, warum die Telekom immer noch PPPoE nutzt, selbst mit Glasfaser. Mit der Autorisierung über eine Line-ID hätte man auf rein DHCP umstellen können.
4
von
vor 3 Monaten
3) ich kenne keinen Router, der kein DHCP kann, keine Ahnung warum das ein Argument für PPPoE wäre
Die "interessantere" Frage für mich ist da eher, warum die Telekom immer noch PPPoE nutzt, selbst mit Glasfaser. Mit der Autorisierung über eine Line-ID hätte man auf rein DHCP umstellen können.
Was ist denn das Problem was du mit einer Änderung der MTU auf dem WAN-Interface weg von den 1492 lösen willst? Ethernet-Ports haben ja standardmäßig die MTU=1500.
Die "interessantere" Frage für mich ist da eher, warum die Telekom immer noch PPPoE nutzt, selbst mit Glasfaser. Mit der Autorisierung über eine Line-ID hätte man auf rein DHCP umstellen können.
https://telekomhilft.telekom.de/conversations/festnetz-internet/glasfaser-warum-pppoe/675559d1389f9f597b84b840?commentId=677d89bc421cf434526fae93
Zu den dort genannten Punkten:
1) wird standardmässig gar nicht genutzt, keine Ahnung warum das ein Argument für PPPoE wäre
3) ich kenne keinen Router, der kein DHCP kann, keine Ahnung warum das ein Argument für PPPoE wäre
4) GPON kann sicherlich auch das nötige QoS , keine Ahnung warum das ein Argument für PPPoE wäre
2) da kommen wir der Sache näher - kostet ja Geld, wenn man auf ein anderes System wechselt - also, die antike DSL-Verwaltung und Verbindungstechnik einfach weiternutzen. Die Telekom ist da übrigens leider nicht alleine, machen viele ISP so.
Die meisten, wenn nicht alle Speedport können nur PPPoE.
0
von
vor 3 Monaten
Die meisten, wenn nicht alle Speedport können nur PPPoE.
3) ich kenne keinen Router, der kein DHCP kann, keine Ahnung warum das ein Argument für PPPoE wäre
Die meisten, wenn nicht alle Speedport können nur PPPoE.
Interessant aber nicht weiter tragisch. ISP Routerboards werden i.d.R. bei Drittanbietern gekauft und die GUI nebst Gehäuse angepasst. Wird sich bei Bedarf freischalten lassen.
0
von
vor 3 Monaten
Zentraler Punkt ist und bleibt da der effektive ROI der Maßnahmen die durchgeführt werden müssten.
0
Uneingeloggter Nutzer
von
vor 3 Monaten
@stultitiophobia Guten Morgen!
Ich kann mich hier den Kommentaren nur anschließen. Weitere Informationen als diese Seite habe ich hier nicht vorliegen. Diese Frage von fdi möchte ich hier auch nochmal wiederholen: "Was ist denn das Problem was du mit einer Änderung der MTU auf dem WAN-Interface weg von den 1492 lösen willst?"
Ich wünsche ein wunderschönes Wochenende!
Viele Grüße
Natalie
0
0
vor 3 Monaten
Warum muss man denn immer ein "Problem" lösen wollen? Eine MTU von 1500 ist "der" Standard in den meisten Netzwerken, weshalb die Pakete oftmals fragmentiert werden müssen, wenn Services im Internet konsumiert werden.
Grundsätzlich tut das nicht weh aber der Overhead wird halt reduziert wenn die Pakete nicht fragmentiert werden müssen - schaden tut es also definitiv nicht.
Die RFC4638 wurde ja noch zum Spaß erstellt, sondern weil man damit unter anderem mehr Effizienz erreichen möchte.
2
von
vor 3 Monaten
Eine MTU von 1500 ist "der" Standard in den meisten Netzwerken, weshalb die Pakete oftmals fragmentiert werden müssen, wenn Services im Internet konsumiert werden.
Warum muss man denn immer ein "Problem" lösen wollen? Eine MTU von 1500 ist "der" Standard in den meisten Netzwerken, weshalb die Pakete oftmals fragmentiert werden müssen, wenn Services im Internet konsumiert werden.
Grundsätzlich tut das nicht weh aber der Overhead wird halt reduziert wenn die Pakete nicht fragmentiert werden müssen - schaden tut es also definitiv nicht.
Die RFC4638 wurde ja noch zum Spaß erstellt, sondern weil man damit unter anderem mehr Effizienz erreichen möchte.
Wo siehst du in der Verbindung des Telekomanschlusses irgendwo Fragmentation mit der MTU=1492 (1500 - PPP)?
Die RFC4638 wurde ja noch zum Spaß erstellt, sondern weil man damit unter anderem mehr Effizienz erreichen möchte.
Warum muss man denn immer ein "Problem" lösen wollen? Eine MTU von 1500 ist "der" Standard in den meisten Netzwerken, weshalb die Pakete oftmals fragmentiert werden müssen, wenn Services im Internet konsumiert werden.
Grundsätzlich tut das nicht weh aber der Overhead wird halt reduziert wenn die Pakete nicht fragmentiert werden müssen - schaden tut es also definitiv nicht.
Die RFC4638 wurde ja noch zum Spaß erstellt, sondern weil man damit unter anderem mehr Effizienz erreichen möchte.
8 Byte PPP-Header schränken die Effizienz ein? Nicht wirklich, oder?
Ansonsten hätte ich die Antwort vom TE erwartet.
0
von
vor 3 Monaten
8 Byte sind im Netzwerkverkehr nicht wenig aber however - haben ist aber immer besser als brauchen. Zudem bezog sich meine Aussage darauf, das man viel Fragmentation hat, wenn man per Default 1500 senden würde aber dank Auto-Tuning kommt das vermutlich nur noch für alte Systeme in Frage.
Es gibt aber Systeme die brauchen wirklich jedes Byte und jede ms, weshalb sie sogar auf TFO (TCP Fast Open) setzen, um den Netzwerkverkehr möglichst effizient zu gestalten. Bevor stultitiophobia geantwortet hat, wussten wir ja nicht, ob er ggf. dertige Systeme betreiben möchte.
Uneingeloggter Nutzer
von
vor 3 Monaten
Mir ging es tatsächlich hier auch im die Effizienz im Netz und eher um die technische Frage, ob das implementiert ist.
Es gibt immer mehr Router, bei denen das so implementiert wird.
Da die technischen Spezifikationen das so hergeben, stellt sich die Frage, ob das so funktioniert oder nicht oder ob es Erfahrungswerte oder eine (offizielle) Aussage eines technischen Kollegen dazu gibt.
0
1
von
vor 3 Monaten
Als ich mal von Gerüchten gehört habe die Telekom könnte ggf. RFC 4638 "Baby Jumbo Frames" zukünftig mal unterstützen hatte ich meinen Mikrotik Router mal testweise entsprechend Konfiguriert, bis heute wird aber weiterhin mit max. MTU 1492 die PPPoE Verbindung aufgebaut.
Entweder unterstützen es die diversen Modems/SFP Module nicht die ich in der Zwischenzeit eingesetzt habe immer zufällig nicht, oder die Telekom hat es bisher nicht implementiert.
Hätte ja z.B. auch für VPN Verbindungen den Vorteil wenn die äußere Paketgröße 8 Byte mehr Payload transportieren kann, dass man die MTU innerhalb einer VPN Verbindung auch um 8 Byte anheben könnte. Ist nicht viel aber könnte den Durchsatz von VPN Verbindungen (minimal) verbessern.
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von