From owner-freebsd-net@freebsd.org Fri Dec 4 00:22:10 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92FD0A3F37A for ; Fri, 4 Dec 2015 00:22:10 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF06A1933 for ; Fri, 4 Dec 2015 00:22:09 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from moby.local ([79.107.25.109]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LtDpH-1aGIDq2j5H-012tU7 for ; Fri, 04 Dec 2015 01:22:01 +0100 From: Nikos Vassiliadis Subject: etherip (or gif) tunnel blues To: FreeBSD Net Message-ID: <5660DC8B.1090309@gmx.com> Date: Fri, 4 Dec 2015 02:21:31 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7PlXQFEFVLeFJFwYCLKHpRJW/aLuFti8uskTLVg7y7wcxPoKURy R9lysjcquSJl495eT+K5zBsAeDdip2ksf09kYLLoX5eVlW9xpX1BpczTGP0porvED9Wh4v8 o/xYEiS+hGWQ14NJGWB9CYgPlYAyVNjPzTTXnw63TqHyV9VFkQvQxrqJ2XBe+mvHsdf6Spb vyLjlDrChCObttmT2SYVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Hnz2gE98blM=:2ZP/jy+WGfxXq3H9idl1BV 4BkzAmwTZyd9htgM+2uicpDxGE0KppRwHtnIATw66iLoQYNRXlnhlYoCHDFJQ4CGXY9uhDoDC 9WqynAl3KKVKsqLxEH5+0x5s627rVCV/qku+wVdkGTiIdzMVWfX+QtMkcNUCJxRmn3hIcg0Ja ndL7F4GIrwkNa+RGuScILxATAjj22+fTb8j0qHMJjAU/3HQRq/aNWJJc+Nem9GIROXN/u0zUo Gz5AESBnRVfDc+/QsWp0ccQc9CSIQ15uZ7w2poOY36oBk5UFVoTdsrUKXExzjWdMfTv0bzzh9 1apUKDZ2NbgWo2cLQrmcCFY8tTr/Rsr4uB1JvsABVuOLV/mcUcm4k2FW5+SePuz8i9sSEpeoa SAz0luT3E2e8MlHk5ZzK1QhgYW8q84j/RynH3M9khOb3f0SqKWoNQinPbMHjdMlkUKwCJoNbK wnSMIKWnSNlPlVzO9zpp2g9Vzfwyd3iJGU9bHBLkT8Affy5awokk3mn3LFaASi+ryuSjmTSkk sReE0I2mANOpa5BJRNBvfzWDIJzC08pR5bdPmW0dv/7KzoL6G85cdX4tEsYx4gRilD8oNRB1M UqcrQf1VoH7E1A82floe+TIDPsQXzqjpIofVORKMdCmnUWmpav9CM+JwocpqoldgSTMVGqVwA FQTtOiDFZ+ecVncRd5GcFk5Kwbky+tFexXqrufBQsutkaM9Ybutb01gpFSxYKNevpJgQ9jAlH n9wQliFvdKUtCKz5UIQQ6wxg8Hy2aNOaMn7QIbm55YY1Ig93z9TmZ6QWx8sDuHnpCXhcrcurn 20WJlbh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2015 00:22:10 -0000 Hi, we use ETHERIP to connect two remote locations and we discovered something that looks like a bug. A packet of specific size cannot go through the tunnel. Correct behavior: > root@prometheus:~ # ping -s 1450 10.65.0.1 > PING 10.65.0.1 (10.65.0.1): 1450 data bytes > 1458 bytes from 10.65.0.1: icmp_seq=0 ttl=64 time=0.302 ms > 1458 bytes from 10.65.0.1: icmp_seq=1 ttl=64 time=0.267 ms > 1458 bytes from 10.65.0.1: icmp_seq=2 ttl=64 time=0.275 ms > 1458 bytes from 10.65.0.1: icmp_seq=3 ttl=64 time=0.274 ms > ^C > --- 10.65.0.1 ping statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.267/0.279/0.302/0.013 ms If size is reduced to 1449 then the problem appears: > root@prometheus:~ # ping -s 1449 10.65.0.1 > PING 10.65.0.1 (10.65.0.1): 1449 data bytes > ^C > --- 10.65.0.1 ping statistics --- > 7 packets transmitted, 0 packets received, 100.0% packet loss It's not specific to ICMP, TCP also behaves likewise and most probably UDP as well but I haven't tested that. Hung TCP connections was the reason we discovered this behavior. The behavior is *always* the same with that specific size. Larger (and smaller of course) sized packets go through the tunnel as they should. If I reduce the MTU by 1 for that route (the default route), things appear to work again! > root@prometheus:~ # route change 0/0 -mtu 1499 > change net 0 fib 0 > root@prometheus:~ # ping -s 1449 10.65.0.1 > PING 10.65.0.1 (10.65.0.1): 1449 data bytes > 1457 bytes from 10.65.0.1: icmp_seq=0 ttl=64 time=0.285 ms > 1457 bytes from 10.65.0.1: icmp_seq=1 ttl=64 time=0.288 ms > 1457 bytes from 10.65.0.1: icmp_seq=2 ttl=64 time=0.297 ms > 1457 bytes from 10.65.0.1: icmp_seq=3 ttl=64 time=0.300 ms > ^C > --- 10.65.0.1 ping statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 0.285/0.292/0.300/0.006 ms I am not sure if this affects gif tunnels as well because at the moment we need a L2 tunnel. It'd be amazing if someone could help with an idea. Or patch;) The behavior is the same on 10-STABLE and 9-STABLE. Thanks in advance, Nikos