MTU issue when using GRE over tinc

[Michael Tokarev]

10.12.2013 13:38, Guus Sliepen wrote:
> On Tue, Dec 10, 2013 at 10:08:37AM +0100, Loic Dachary wrote:
> 
>> In a setup where OpenVSwitch is used with GRE tunels on top of an interface provided by tinc, I'm experiencing MTU problems and I'm not sure how to fix them. The manifestation of the problem is, from the user point of view, communication hang. And using "tcpdump -i there" displays lines such as :
>>	
>>     18:54:00.345666 IP 10.111.1.1 > 10.111.1.2: GREv0, key=0x5, length 1438: IP ceph.com.https > 10.0.3.15.57429: Flags [P.], seq 4917:6293, ack 658, win 71, length 1376
>>     18:54:00.345746 IP 10.111.1.2 > 10.111.1.1: ICMP 10.111.1.2 unreachable - need to frag (mtu 1445), length 556
>>
>> My actual use case very much ressembles what is described here http://blog.csdn.net/lynn_kong/article/details/9140659
>>
>> and I tried to change the MTU on hte tinc provided interfaces on the machines that have 10.111.1.2 and 10.111.1.1 bound to them:
>>
>>     ip link set mtu 1546 dev there
> 
> The problem is that the GRE tunnel sets the DF bit in its headers, meaning that
> tinc should not fragment the GRE packets, but instead reply with an ICMP error
> message when the packets are too large. This is exactly what tinc does. The
> problem is that GRE doesn't handle those ICMP packets at all.


This might be the most effective and correct place to attack this issue - why
your GRE tunnel does not handle these ICMP packets correctly (or at all).

One _possible_ explanation might be on the tinc side actually - the fact that
it sends ICMP "error" replies "from" the destination address.  That's no more
than a rumor, -- I heard that "some" routers dislike this.

But ofcourse there might be other issues here as well.  If you can, please try
following the ICMP "need to frag" packets back to the sending tunnel side.

Thanks,

/mjt