automatische MTU bei Bridges

Bridge mit automatischer MTU

Bridges müssen nahezu immer verwendet werden, wenn mit VLANs gearbeitet wird.
Normalerweise wird eine Bridge mit einer MTU von 1500 Byte automatisch erstellt:

Wird der MTU-Wert nicht administrativ definiert (über das „MTU“-Feld), wird die MTU automatisch auf die niedrigste MTU eines jeden Mitgliedsports definiert!

 

Maximum transmission unit, by default, the bridge will set MTU automatically and it will use the lowest MTU value of any associated bridge port. The default bridge MTU value without any bridge ports added is 1500. The MTU value can be set manually, but it cannot exceed the bridge L2MTU or the lowest bridge port L2MTU. If a new bridge port is added with L2MTU which is smaller than the actual-mtu of the bridge (set by the mtu property), then manually set value will be ignored and the bridge will act as if mtu=auto is set. Quelle

 

Bei Tunnel-Interfaces wie EoIP liegt die Standard-MTU beispielsweise bei 1458 Bytes. Dieser der Wert wird dann von der Bridge übernommen.

EoIP-Interface als Mitgliedsport einer Bridge.

 

Die MTU der Bridge wird folglich auf 1458 Bytes reduziert und ist maßgebend für alle Subinterfaces dieser Bridge!

 

Problematik

Dies kann nun Auswirkungen auf IP-Verbindungen haben, die den DF-Bit (Don’t Fragment) gesetzt haben (nahezu alle IP-Pakete).

  • Die angezeigten 1492 Bytes auf Layer3 ergeben hier (PPPoE / DSL):
    1492 Bytes + 4 Bytes [VLAN] + 14 Bytes [Ethernet-Header] + 4Bytes [FCS] + 8 Bytes [PPPoE] = 1522 Bytes (Wireshark zeigt FCS und PPP-Header nicht an)
  • Bei Glasfaser wären es 1500 Bytes auf Layer3:
    1500 Bytes + 4 Bytes [VLAN] + 14 Bytes [Ethernet-Header] + 4 Bytes [FCS] = 1522 Bytes (Wireshark zeigt FCS nicht an)
  • Bei DOCSIS wären es ebenfalls 1500 Bytes auf Layer3:
    1500 Bytes + 4 Bytes [VLAN] + 14 Bytes [Ethernet-Header] + 4 Bytes [FCS] = 1522 Bytes (Wireshark zeigt FCS nicht an)

 

Die daraufhin nun korrekt vom Router versendete ICMP-Typ-3-Code-4 PMTUD-Nachricht wurde an den Server gesendet. Leider werden ICMP-Nachrichten die diesen Server betreffen von einer Firewall serverseitig gefiltert, was die Verbindung schlussendlich verhindert! Da ICMP-Nachrichten aber nicht von jeder Firewall gefiltert werden, funktionieren manche Webseiten, wohingegen andere Seiten nicht aufrufbar sind…

 

Lösung

Die Lösung des Problems: Die MTU auf der Bridge administrativ auf 1500 Bytes festlegen!

 

Mikrotik empfiehlt auch EoIP-Interfaces auf eine MTU von 1500 Bytes einzustellen:

mtu should be set to 1500 to eliminate packet refragmentation inside the tunnel (that allows transparent bridging of Ethernet-like networks, so that it would be possible to transport full-sized Ethernet frame over the tunnel). Quelle

 

Mit Bridges und eingebundenen Tunnel-Interfaces sollte die Bridge-MTU immer fest definiert werden! Andernfalls können Nebeneffekte wie IP-Fragmentierung auftreten, was an sich noch kein Problem verursachen würde (außer erhöhter CPU-Last und größeren Latenzen). Wenn jedoch die ICMP-PMTUD-Nachrichten noch irgendwo von einer Firewall gefiltert werden, schlägt die Verbindung fehlt. Da die Pakete nie verkleinert versendet und deswegen immer verworfen werden. Da nicht jede Firewall ICMP verwirft, ist das Fehlerbild diffus; Manche Webseiten sind aufrufbar – andere Seiten nicht. Dieser Effekt tritt gehäuft mit dem HTTPS-Protokoll auf, der TLS-Handshake (Server Hello) verhindert schon sehr früh eine Verbindung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert