<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Lieber Clemens!<br>
<br>
Am 2015-07-26 um 00:44 schrieb Clemens Hopfer:<br>
</div>
<blockquote cite="mid:2146478.4Btie5xQuD@datacop-desktop"
type="cite">
<pre wrap="">Lieber Erich,
Am Samstag, 25. Juli 2015, 13:41:09 schrieb Erich N. Pekarek:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Das Setzen der MTU am LAN Interface ist korrekt, </pre>
</blockquote>
[... wird aber nicht uneingeschränkt empfohlen ...]<br>
<blockquote cite="mid:2146478.4Btie5xQuD@datacop-desktop"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
Ethernet over IP?<br>
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.)<br>
Da der Brenner nicht natten sollte, routet er nur, d.h. er sollte
die Pakete auch nicht (de-/re-)fragmentieren.<br>
<br>
Siehe auch <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/IP_fragmentation">https://en.wikipedia.org/wiki/IP_fragmentation</a>:<br>
<small><i>"If a <b>receiving host</b> receives a fragmented IP
packet, it <b>has to reassemble the datagram</b> and pass it to
the higher protocol layer. <b>Reassembly is intended to happen
in the receiving host</b> but in practice it <b>may be done
by an intermediate router</b>, for <b>example</b>, </i><i><a
href="https://en.wikipedia.org/wiki/Network_address_translation"
title="Network address translation">network address
translation</a></i><i> (<b>NAT</b>) </i><i>may</i><i> need to
re-assemble fragments in order to translate data streams,
description provided in </i><i><a class="external
mw-magiclink-rfc" rel="nofollow"
href="https://tools.ietf.org/html/rfc2993">RFC 2993</a></i><i>.</i><i><sup
id="cite_ref-3" class="reference"><a
href="https://en.wikipedia.org/wiki/IP_fragmentation#cite_note-3"><span>[</span>3<span>]</span></a>"</sup></i></small><br>
<br>
Ein wahrhaft transparentes Setup sollte dies mE berücksichtigen.<br>
<blockquote cite="mid:2146478.4Btie5xQuD@datacop-desktop"
type="cite">
<pre wrap="">
Interessanterweise hat der tunnelserver die MTU am VLAN richtig erkannt.</pre>
</blockquote>
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?<br>
<blockquote cite="mid:2146478.4Btie5xQuD@datacop-desktop"
type="cite">
<pre wrap="">
@Akku:
Bitte probier mal MTU 1360 auf allen LAN Interfaces (nur LAN bitte), damit
sollte auch der return-path passen.</pre>
</blockquote>
... ernsthaft?<br>
<br>
Sind in den 1360 die 4 Byte des erweiterten Ethernet-Frames für das
VLAN schon eingerechnet?<br>
<br>
<a class="moz-txt-link-freetext" href="http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP">http://wiki.mikrotik.com/wiki/Manual:Interface/EoIP</a>:<br>
"EoIP tunnel adds at least 42 byte overhead (8byte GRE + 14 byte
Ethernet + 20 byte IP) "<br>
<br>
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.<br>
<br>
Leider fehlt mir praktische Erfahrung mit EoIP-Implementierungen,
aber könnte man nicht mittels der Parameter "clamp-tcp-mss yes" und
"mtu <i>x</i>" das Problem auf der Seite des Tunnels lösen, ohne an
der gesamten LAN-Infrastruktur des Brenner herumzumurksen? (siehe
mikrotik manual hierzu).<br>
<blockquote cite="mid:2146478.4Btie5xQuD@datacop-desktop"
type="cite">
<pre wrap="">
Lg,
Clemens
[TOFU entsorgt]
</pre>
</blockquote>
Fortsetzung der Detailsdiskussion über discuss, da wien dafür
bereits off-topic ist. <br>
<blockquote cite="mid:2146478.4Btie5xQuD@datacop-desktop"
type="cite">
<pre wrap="">
</pre>
</blockquote>
LG<br>
Erich<br>
</body>
</html>