[Disclaimer : I'm not a network engineer]
Hi,
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
but then I get different errors but still errors
18:50:14.491795 IP 10.111.1.1 > 10.111.1.2: GREv0, key=0x5, length 1522:
IP ceph.com.https > 10.0.3.15.57426: Flags [.], seq 1:1461, ack 239, win 54,
length 1460
18:50:14.491849 IP 10.111.1.2 > 10.111.1.1: ICMP 10.111.1.2 unreachable -
need to frag (mtu 1445), length 556
The full tinc configuration on the machines looks like:
# cat /etc/tinc/there/tinc-up
#!/bin/bash
ifconfig there 10.111.01.02 netmask 255.255.0.0
# cat /etc/tinc/there/tinc.conf
Name = bm0102there
AddressFamily = ipv4
Device = /dev/net/tun
Mode = switch
ConnectTO = bm0101there
Do you have an advice on how to fix this problem ?
Cheers
--
Lo?c Dachary, Artisan Logiciel Libre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20131210/0d634d74/attachment.sig>
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 thereThe 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. To make sure that the packets sent through the GRE tunnel do not exceed the maximum packet size, you should lower the MTU of the GRE interface, for example like so: ip link set mtu 1400 dev gre0 Raising the MTU of the VPN interface does not help in any way, and lowering the MTU of the VPN interface will make the problem worse. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20131210/d37cf507/attachment.sig>