[Wien] Knoten Gatt12 / Brenner, [off-topic]: EoIP

[Erich N. Pekarek]

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
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20150726/162191dc/attachment.htm>