From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 10:46:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 247FB16A416 for ; Wed, 20 Dec 2006 10:46:15 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92B2643CB7 for ; Wed, 20 Dec 2006 10:46:13 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GwybC-0001oh-7d for current@freebsd.org; Wed, 20 Dec 2006 12:22:58 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gwyb8-0000ud-VO for current@freebsd.org; Wed, 20 Dec 2006 12:22:55 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Wed, 20 Dec 2006 12:22:54 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2360/Wed Dec 20 08:24:09 2006) Cc: Subject: packets duplicated *massively* on transmit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 10:46:15 -0000 Hi I have two FreeBSD routers: FreeBSD firewall1 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Wed May 17 14:27:51 SAST 2006 ianf:/usr/obj/usr/src/sys/FIREWALL i386 FreeBSD firewall2 7.0-CURRENT FreeBSD 7.0-CURRENT #8: Fri Sep 1 08:32:04 SAST 2006 ianf:/usr/obj/usr/src/sys/FIREWALL i386 In two reasonably busy datacenters. We're seeing packet loss that we traced to a packet ariving on the world-facing interface being retransmitted approximately every 10 microseconds or so for 1 to 5 seconds out of the interface the client is on. Example trace: Incoming packet on re0 1166597152.957627 00:02:85:07:32:40 > 00:30:4f:40:d9:cf, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 Outbound packet(s) on vlan17 - parent re1 1166597153.000003 00:30:4f:40:d9:ee > 00:02:b3:d8:e7:4d, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 1166597153.000013 00:30:4f:40:d9:ee > 00:02:b3:d8:e7:4d, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 1166597153.000022 00:30:4f:40:d9:ee > 00:02:b3:d8:e7:4d, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 We're seeing this on re(4) and rl(4) interfaces on firewall1 (uname above) and on em(4) interfaces on firewall2. It just transmits faster on the em(4) interfaces. Until recently, all instances I've seen so far had been SYN packets, but I've just seen the same deal with an icmp echo request. Sadly, I don't have a copy of the original packet. 1166608024.000164 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 1166608024.000166 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 1166608024.000167 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 1166608024.000169 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 Any ideas? Ian -- Ian Freislich