Lieber Clemens!
Am 2015-07-26 um 00:44 schrieb Clemens Hopfer:
Lieber Erich,
Am Samstag, 25. Juli 2015, 13:41:09 schrieb Erich N. Pekarek:
Lieber akku, bitte auf der LAN-Seite die MTU nicht ändern. Das verlagert die
MTU-Problematik und kann bei kaputten Firewallsettings (icmp) schnell zu
Problemen mit der path discovery führen. Sauberer ist die Lösung mit der
Tunnel-Fraqmentschwelle.
Das Setzen der MTU am LAN Interface ist korrekt,
[... wird aber nicht uneingeschränkt empfohlen ...]
wir haben seit einigen
Monaten keinen OpenVPN Tunnel mehr am brenner.
Der Traffic wird von ANW direkt von einem Eth Port am brenner uns auf einem
VLAN im VIX transparent übergeben.
Ethernet over IP?
D.h. die MTU und etwaige Fragmentierungsprobleme sollten an jeweils dem
Port, wo Connectivity gegeben ist, gelöst werden - ansonsten müssten die
Anpassungen konsequenterweise an allen Devices gemacht werden - es seit
denn es kann garantiert werden, dass im gesamten 0xFF-Netz die MTU Path
Discovery funktionert. (Bei Extern-Extern-NAT in den Defaults der
Joe-Firmware und OpenWRT i.A. etc, würde ich das nicht behaupten wollen.)
Da der Brenner nicht natten sollte, routet er nur, d.h. er sollte die
Pakete auch nicht (de-/re-)fragmentieren.
Siehe auch https://en.wikipedia.org/wiki/IP_fragmentation:
/"If a *receiving host* receives a fragmented IP packet, it *has to
reassemble the datagram* and pass it to the higher protocol layer.
*Reassembly is intended to happen in the receiving host* but in practice
it *may be done by an intermediate router*, for *example*, //network
address translation
<https://en.wikipedia.org/wiki/Network_address_translation>//(*NAT*)
//may//need to re-assemble fragments in order to translate data streams,
description provided in //RFC 2993
<https://tools.ietf.org/html/rfc2993>//.//^[3]
<https://en.wikipedia.org/wiki/IP_fragmentation#cite_note-3>" /
Ein wahrhaft transparentes Setup sollte dies mE berücksichtigen.
Interessanterweise hat der tunnelserver die MTU am VLAN richtig erkannt.
Sehe ich das richtig, dass die Brenner-Devices jetzt an einem simplen
(RB750UP, ohne OLSR) Switch hängen, (wo das Vlan dann untagged
herauskommt), der mit einem Port eines ANW-Switchs/Routers verbunden
ist, der EoIP + VLAN über eine ANW-Funkstrecke macht, VIX mit tagged VLAN?
@Akku:
Bitte probier mal MTU 1360 auf allen LAN Interfaces (nur LAN bitte), damit
sollte auch der return-path passen.
... ernsthaft?
Sind in den 1360 die 4 Byte des erweiterten Ethernet-Frames für das VLAN
schon eingerechnet?
http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP:
"EoIP tunnel adds at least 42 byte overhead (8byte GRE + 14 byte
Ethernet + 20 byte IP) "
Ich komme auf 1354 (1500-72 (layer 1 Ethernet packet) - 42 (EoIP
overhead) - 32 (VLAN overhead)), respektive 1362, wenn ich nur den layer
2 ethernet frame einrechnen muss.
Leider fehlt mir praktische Erfahrung mit EoIP-Implementierungen, aber
könnte man nicht mittels der Parameter "clamp-tcp-mss yes" und "mtu /x/"
das Problem auf der Seite des Tunnels lösen, ohne an der gesamten
LAN-Infrastruktur des Brenner herumzumurksen? (siehe mikrotik manual
hierzu).
Lg,
Clemens
[TOFU entsorgt]
Fortsetzung der Detailsdiskussion über discuss, da wien dafür bereits
off-topic ist.
LG
Erich
--
Wien mailing list
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien
