9
Frage zu MTU Werten auf allen Interfaces mit Multi WAN (Kabel und DSL Internet)
Hallo zusammen,
ich nutze eine PFSense auf einem kleinen Mini PC mit 4 Lan Ports.
Auf 2 Ports hängen die beiden Modems auf den anderen zweien ein LAGG zu meinem Switch (Netgear GS110EMX).
Ich stelle mir gerade folgende Fragen, mit der Bitte um kurze Beantwortung
Folgende Interfaces habe ich
WAN_Telekom ist mein Interface für die DSL Verbindung (Vigor165) über PPPoE - hier ist der MTU auf 1492 eingestellt.
WAN_Unitymedia ist mein Interface an welches das TC4400 angeschlossen ist - hier steht der MTU auf 1500.
LAN ist mein LAGG - hier ebenfalls MTU 1500.
Telekom_Modem ist mein virtuelles Interface für die Verbindung zur Weboberfläche zum Vigor165 - Hier ist MTU1492.
Meine Fragen:
-Muss ich beim Telekom Interface die MTU auf 1492 stellen, oder wird dies schon vorher durch die PFSense gemacht - da bei Network Port ja bereits die von mir erstellte PPPOE Verbindung genutzt wird:
-Muss ich theoretisch die MTU auf allen Interfaces auf das kleinste gemeinsame bringen? Ich habe natürlich schon versucht im Internet schlau zu werden. Aber mit den MultiWan Geschichten komm ich nicht so ganz klar, welche Einstellungen hier am besten sind.
Gefühlt läuft alles super. Aber ich möchte gerne das beste Ergebnis erreichen (auch wenn es nur im Nachkommabereich ist ;)).
-Ich nehme an Jumbo Frames machen hier keinen Sinn oder? Die PFsense müsste es können, mein Switch auch, mein PC z.B. auch. Aber ich habe noch weitere Geräte am Switch die damit nichts anfangen können. Macht also keinen Sinn oder?
Danke euch
Grüße
ich nutze eine PFSense auf einem kleinen Mini PC mit 4 Lan Ports.
Auf 2 Ports hängen die beiden Modems auf den anderen zweien ein LAGG zu meinem Switch (Netgear GS110EMX).
Ich stelle mir gerade folgende Fragen, mit der Bitte um kurze Beantwortung
Folgende Interfaces habe ich
WAN_Telekom ist mein Interface für die DSL Verbindung (Vigor165) über PPPoE - hier ist der MTU auf 1492 eingestellt.
WAN_Unitymedia ist mein Interface an welches das TC4400 angeschlossen ist - hier steht der MTU auf 1500.
LAN ist mein LAGG - hier ebenfalls MTU 1500.
Telekom_Modem ist mein virtuelles Interface für die Verbindung zur Weboberfläche zum Vigor165 - Hier ist MTU1492.
Meine Fragen:
-Muss ich beim Telekom Interface die MTU auf 1492 stellen, oder wird dies schon vorher durch die PFSense gemacht - da bei Network Port ja bereits die von mir erstellte PPPOE Verbindung genutzt wird:
-Muss ich theoretisch die MTU auf allen Interfaces auf das kleinste gemeinsame bringen? Ich habe natürlich schon versucht im Internet schlau zu werden. Aber mit den MultiWan Geschichten komm ich nicht so ganz klar, welche Einstellungen hier am besten sind.
Gefühlt läuft alles super. Aber ich möchte gerne das beste Ergebnis erreichen (auch wenn es nur im Nachkommabereich ist ;)).
-Ich nehme an Jumbo Frames machen hier keinen Sinn oder? Die PFsense müsste es können, mein Switch auch, mein PC z.B. auch. Aber ich habe noch weitere Geräte am Switch die damit nichts anfangen können. Macht also keinen Sinn oder?
Danke euch
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 614789
Url: https://administrator.de/contentid/614789
Ausgedruckt am: 19.11.2024 um 15:11 Uhr
9 Kommentare
Neuester Kommentar
Die MTUs sind immer rein Interface bezogen. Auf dem PPPoE Interface musst du die MTU setzen. 1492 ist falsch, denn damit hast du den VLAN Tag unterschlagen der bei VDSL zwingend mit dazu muss.
Du hast also 1488 Bytes als korrekten Wert dort ! Ansonsten gerätst du in Gefahr das größere Ethernet Frames verworfen werden. Siehe auch:
https://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
Kabel TV nutzt keinerlei Encapsulation Protokoll deshalb gilt dort weiter der Standard von 1500.
Siehe auch:
https://baturin.org/tools/encapcalc/
Die Endgeräte handeln das je nachdem ob sie es können oder nicht immer mit einer MTU Path Negotiation/Discovery vor Sessionaufbau aus. Auf dem Switch schadet es also nicht es zu aktivieren, im Gegenteil.
Du hast also 1488 Bytes als korrekten Wert dort ! Ansonsten gerätst du in Gefahr das größere Ethernet Frames verworfen werden. Siehe auch:
https://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
Kabel TV nutzt keinerlei Encapsulation Protokoll deshalb gilt dort weiter der Standard von 1500.
Siehe auch:
https://baturin.org/tools/encapcalc/
Ich nehme an Jumbo Frames machen hier keinen Sinn oder?
Ja, das ist bei einem Router sinnfrei. Das macht nur Sinn im Layer 2 auf einem Switch. Dort sollte man es immer aktivieren wenn der Switch diese Option bietet.Die Endgeräte handeln das je nachdem ob sie es können oder nicht immer mit einer MTU Path Negotiation/Discovery vor Sessionaufbau aus. Auf dem Switch schadet es also nicht es zu aktivieren, im Gegenteil.
Hey aqui,
danke für die Antwort. Stimmt das VLAN7 hatte ich garnicht auf dem Schirm. Danke dir!
Habs so eingestellt. Besten dank
danke für die Antwort. Stimmt das VLAN7 hatte ich garnicht auf dem Schirm. Danke dir!
Habs so eingestellt. Besten dank
Zitat von @aqui:
1492 ist falsch, denn damit hast du den VLAN Tag unterschlagen der bei VDSL zwingend mit dazu muss.
Du hast also 1488 Bytes als korrekten Wert dort !
1492 ist falsch, denn damit hast du den VLAN Tag unterschlagen der bei VDSL zwingend mit dazu muss.
Du hast also 1488 Bytes als korrekten Wert dort !
Der VLAN-Tag wird doch im Header des Ethernet-Frames gesetzt. Dadurch wird der Frame länger, aber nicht der Payload kleiner. Der bleibt auch mit VLAN-Tag bei 1500, der PPPoE-Header hat 8 Byte. Somit passt 1492 auch mit VLAN-Tag.
Hmmm,
was stimmt dann nun? Macht es einen Unterschied ob die PFSense das VLAN Tagging macht oder das Modem direkt in Bezug auf den MTU Wert?
was stimmt dann nun? Macht es einen Unterschied ob die PFSense das VLAN Tagging macht oder das Modem direkt in Bezug auf den MTU Wert?
M.E. ist es schon wichtig. Wie oben schon steht wird der Ethernet Frame an sich um 4 Byte länger und dazu kommt dadrüber dann noch der PPPoE Header der diesen Ethernet Header mit den 4 Byte komplett einkapselt. Die Gesamtlänge wird also größer, folglich muss der MTU Wert kleiner werden.
Sieht man sich entsprechende Einträge in der Cisco, Juniper Knowledgebase und anderer Hersteller an findet man dort immer den Wert 1488 also PPPoE 8 Bytes inklusive der 4 Byte .1q Header on top.
Sieht man sich entsprechende Einträge in der Cisco, Juniper Knowledgebase und anderer Hersteller an findet man dort immer den Wert 1488 also PPPoE 8 Bytes inklusive der 4 Byte .1q Header on top.
Zitat von @aqui:
und dazu kommt dadrüber dann noch der PPPoE Header der diesen Ethernet Header mit den 4 Byte komplett einkapselt. Die Gesamtlänge wird also größer, folglich muss der MTU Wert kleiner werden.
und dazu kommt dadrüber dann noch der PPPoE Header der diesen Ethernet Header mit den 4 Byte komplett einkapselt. Die Gesamtlänge wird also größer, folglich muss der MTU Wert kleiner werden.
Es heißt doch PPP over Ethernet, das PPPoE-Paket wird im Ethernet-Frame transportiert:
Die Praxis sieht aber anders aus:
https://www.ziggymania.de/index.php/tutos/45-firewall/173-telekom-bng-an ...
https://kb.pocnet.net/wiki/Cisco-Router_am_Telekom_BNG-Anschluss
usw. usw.
Logisch ist das ja auch verständlich. Im Ethernet Frame ist als Payload ein PPP Frame enthalten. (Da hat die Zeichnung übrigens einen Fehler oben !) Siehe dazu auch das [https://tools.ietf.org/html/rfc2516 RFC_2516) im Kapitel 4. "Payloads".
Um diesen PPP Frame (unten im grauen Payload) kommt dann der Ethernet Frame. Dieser ist aber durch das angehängte VLAN Tag insgesamt um 4 Byte länger:
Folglich ist der gesamte PPPoE Frame damit um diese 4 Byte länger und entsprechend kleiner wird die MTU.
https://www.ziggymania.de/index.php/tutos/45-firewall/173-telekom-bng-an ...
https://kb.pocnet.net/wiki/Cisco-Router_am_Telekom_BNG-Anschluss
usw. usw.
Logisch ist das ja auch verständlich. Im Ethernet Frame ist als Payload ein PPP Frame enthalten. (Da hat die Zeichnung übrigens einen Fehler oben !) Siehe dazu auch das [https://tools.ietf.org/html/rfc2516 RFC_2516) im Kapitel 4. "Payloads".
Um diesen PPP Frame (unten im grauen Payload) kommt dann der Ethernet Frame. Dieser ist aber durch das angehängte VLAN Tag insgesamt um 4 Byte länger:
Zitat von @aqui:
Im Ethernet Frame ist als Payload ein PPP Frame enthalten. (Da hat die Zeichnung übrigens einen Fehler oben !)
Wo hat die Zeichnung da einen Fehler?Im Ethernet Frame ist als Payload ein PPP Frame enthalten. (Da hat die Zeichnung übrigens einen Fehler oben !)
Im Payload des Ethernet-Frames wird der PPPoE-Header übertragen (8 Byte)
Wie dein Bild zeigt, ist der Payloadbereich des Ethernet-Frames mit und ohne VLAN-Tag max 1500 Bytes groß:
Wo hat die Zeichnung da einen Fehler?
In einem PPPoE Frame ist ja niemals selber wieder ein vollständiger PPPoE Frame (Frame mit Ethernet Header) als Payload encapsuliert. Wäre ja Unsinn und doppelt gemoppelt. Es hängt allerdings davon ab wie man den Terminus "PPPoE" dann syntaktisch auslegt im Verständnis.Da ist es sicherer sich an den RFC bzw. seine Nomenklatur zu halten, denn der sagt klar das da ein PPP Frame (ohne Ethernet Header) encapsuliert ist was m.E. auch logischer ist. Wie immer... Ansichtssache.
