Date: Fri, 4 Dec 2015 02:21:31 +0200 From: Nikos Vassiliadis <nvass@gmx.com> To: FreeBSD Net <freebsd-net@freebsd.org> Subject: etherip (or gif) tunnel blues Message-ID: <5660DC8B.1090309@gmx.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5660DC8B.1090309>