From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 03:31:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09B98106566C for ; Sun, 8 Jul 2012 03:31:37 +0000 (UTC) (envelope-from js@alien8.de) Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:120:8448::d00d]) by mx1.freebsd.org (Postfix) with ESMTP id 80FA48FC0A for ; Sun, 8 Jul 2012 03:31:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTP id 5192E1D9C1B for ; Sun, 8 Jul 2012 05:31:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1341718295; bh=0UciiogJvU2Qes5gJ69twSLwNVmCzPOC86du/iAPvLY=; h=Message-ID:Subject:From:To:Date:Content-Type:Mime-Version; b=FMPD e8CJ0F9GqrClnksDdgwV5u4q9xQmpgpkgDhkGg4UAzbv+zY4S/A8aJQCCLvUtjXZ24J 9j8K/BfFy+zrjvWp89CkMlPLzONRH/KdgE3Vz99/zIo+M4QUHQga/xS5GswMiyFbUz6 5T7nGOzXYWZMIM9Udp2xeFABL43LYmDp8= X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s4+XsZDGRY8f for ; Sun, 8 Jul 2012 05:31:35 +0200 (CEST) Received: from [192.168.0.14] (unknown [108.161.21.76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 9B3091D9C19 for ; Sun, 8 Jul 2012 05:31:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1341718295; bh=0UciiogJvU2Qes5gJ69twSLwNVmCzPOC86du/iAPvLY=; h=Message-ID:Subject:From:To:Date:Content-Type:Mime-Version; b=FMPD e8CJ0F9GqrClnksDdgwV5u4q9xQmpgpkgDhkGg4UAzbv+zY4S/A8aJQCCLvUtjXZ24J 9j8K/BfFy+zrjvWp89CkMlPLzONRH/KdgE3Vz99/zIo+M4QUHQga/xS5GswMiyFbUz6 5T7nGOzXYWZMIM9Udp2xeFABL43LYmDp8= Message-ID: <1341718291.13585.15.camel@tabernacle> From: Julian Stecklina To: freebsd-net@freebsd.org Date: Sat, 07 Jul 2012 20:31:31 -0700 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+3FaDmg5ZfGCNABLG5C7" X-Mailer: Evolution 3.2.3 Mime-Version: 1.0 Subject: TCP Regression Test Suite X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 03:31:37 -0000 --=-+3FaDmg5ZfGCNABLG5C7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, do you know of a TCP regression test suite with IPv6 support? Regards, Julian --=-+3FaDmg5ZfGCNABLG5C7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAk/4/xMACgkQ2EtjUdW3H9k0zACePzc10EMLe24Hgl99fuLw0ilO Cl8AmwU3sYB8vVuKXqbNFXc2kuivLgIA =pJ+X -----END PGP SIGNATURE----- --=-+3FaDmg5ZfGCNABLG5C7-- From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 08:30:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 042721065672 for ; Sun, 8 Jul 2012 08:30:30 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id B708E8FC15 for ; Sun, 8 Jul 2012 08:30:29 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id EE80A25D39FD; Sun, 8 Jul 2012 08:30:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Sun, 8 Jul 2012 08:30:27 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: To: xenophon\+freebsd X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: IPSec woes coming from OpenBSD to Free X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 08:30:30 -0000 On 6. Jul 2012, at 22:12 , xenophon+freebsd wrote: > Chris Benesch writes: > >> Looking at the manual, it says to create a gif interface with the >> other end. > > Are you referring to chapter 15.9 in the FreeBSD Handbook? I don't > know why it starts with tunneling over a GIF (IP-in-IP) interface. Because it's old and rusty and needs to be updated and patches are more than welcome. There was a GCIN (or what's it called) task but I am not sure if it was done. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 14:11:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD5E1065672 for ; Sun, 8 Jul 2012 14:11:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0168FC12 for ; Sun, 8 Jul 2012 14:11:09 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id 6C1BB25D3891 for ; Sun, 8 Jul 2012 14:11:08 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 8 Jul 2012 14:11:07 +0000 Message-Id: <037704F6-0211-4942-9277-0CB001615B15@lists.zabbadoz.net> To: FreeBSD Networking Mailing List Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: CFT/CFR: IPv6 scope locking X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 14:11:09 -0000 Hey, I have a patch here that reduces the scope of scope6 locking and I'd love to get review/feedback for it. More details at the beginning of the file. http://people.freebsd.org/~bz/20120502-04-scope6.diff /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 14:34:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA114106566B; Sun, 8 Jul 2012 14:34:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id AA48C8FC12; Sun, 8 Jul 2012 14:34:08 +0000 (UTC) Received: from dhcp-128-232-132-170.eduroam.csx.cam.ac.uk (dhcp-128-232-132-170.eduroam.csx.cam.ac.uk [128.232.132.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id B50BE25D37D1; Sun, 8 Jul 2012 14:34:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: "Bjoern A. Zeeb" Date: Sun, 8 Jul 2012 14:34:06 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: To: FreeBSD-Stable ML X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Networking Mailing List Subject: Disturbance in IPv6 force in stable/9 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: FreeBSD Networking Mailing List List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 14:34:09 -0000 Hey, after some back and forth and quite a few people asking me for it and = having asked re@ I have merged the IPv6 offload changes to stable/9 today = rather than after 9.1 as I had planned. I did not merge driver changes and I am expecting that one or two might = follow-up, as will SCTP be following most likely. I'd be very happy if people = could test this the next days (this week) if using IPv6 to make sure nothing = breaks for them. The changes have been in HEAD for more than a month but who = knows:) In case you find something broke due to these MFCs please yell at me, = loudly! Thanks, Bjoern --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 19:03:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F23D106564A for ; Sun, 8 Jul 2012 19:03:55 +0000 (UTC) (envelope-from xenophon+freebsd@irtnog.org) Received: from mx1.irtnog.org (bge0-1.edge1.cincinnati.irtnog.org [IPv6:2001:470:c445::1]) by mx1.freebsd.org (Postfix) with ESMTP id 39F548FC0C for ; Sun, 8 Jul 2012 19:03:55 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id A0E48182D for ; Sun, 8 Jul 2012 15:03:47 -0400 (EDT) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDsJGxcsEQgC for ; Sun, 8 Jul 2012 15:03:20 -0400 (EDT) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Sun, 8 Jul 2012 15:03:20 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jul 2012 15:01:48 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSec woes coming from OpenBSD to Free thread-index: Ac1c5AqdWGkpCTAyQXaZjPHh1z0oCAAVerbQ References: From: "xenophon\\+freebsd" To: Subject: RE: IPSec woes coming from OpenBSD to Free X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 19:03:55 -0000 Bjoern A. Zeeb writes: > Because it's old and rusty and needs to be updated and patches > are more than welcome. There was a GCIN (or what's it called) > task but I am not sure if it was done. If I have some time, I'll look into updating it. It'd be nice if it covered topics like NAT traversal and remote access VPNs, too.=20 --=20 I FIGHT FOR THE USERS From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 20:14:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A510A106566C for ; Sun, 8 Jul 2012 20:14:11 +0000 (UTC) (envelope-from chris.benesch@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5BAAA8FC0C for ; Sun, 8 Jul 2012 20:14:11 +0000 (UTC) Received: by ghbz22 with SMTP id z22so11094278ghb.13 for ; Sun, 08 Jul 2012 13:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=x2sSdFe92DdIWAgDYfg4w29ywczCbkoMjhVrLf11P5o=; b=lhHz5O/LUPeVpLdvqjUz5db3LYIKQdhxHpyqRgCGft1RYwXWMjHTtvsiJ62NX35AUM xjckzcaap38jyIEb4fDQm052uRoQAohaNVq4NcxYcnIB14ibzFcZ8odZquf22R6050cW uoSIOYINi98XG6M0Y0Lhpy/r8G7zPW3XEYEx1aFWgq2+vQ/JKiZyfjrB9Gcg3bq6EPZW OZMaVx+UMYEC1TneTlAP5iXQQR0i5O2C3DwTft974xr+w7+DAkd+hNLLBmqYyPaTPqbm eL2aYglrs3JR5rm7KtO9w9bhFMCKny2j9FR9+ji39oPZi9j162TkPHGF9jJp3pnRsoeF Mj2g== MIME-Version: 1.0 Received: by 10.42.66.2 with SMTP id n2mr19049494ici.32.1341778450447; Sun, 08 Jul 2012 13:14:10 -0700 (PDT) Received: by 10.231.26.150 with HTTP; Sun, 8 Jul 2012 13:14:10 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Jul 2012 13:14:10 -0700 Message-ID: From: Chris Benesch To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: IPSec woes coming from OpenBSD to Free X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 20:14:11 -0000 Now that I have the rest of the system set up, I was going to write a blog to help out other users /admins. Some of the error messages have misleading symptoms to say the least LOL. Actually I still dont have IPV6 working, but I can address that in another thread. From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 21:40:08 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B63810656D8 for ; Sun, 8 Jul 2012 21:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 86C288FC16 for ; Sun, 8 Jul 2012 21:40:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q68Le8oA054538 for ; Sun, 8 Jul 2012 21:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q68Le8sI054537; Sun, 8 Jul 2012 21:40:08 GMT (envelope-from gnats) Date: Sun, 8 Jul 2012 21:40:08 GMT Message-Id: <201207082140.q68Le8sI054537@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Terrence Koeman" Cc: Subject: Re: kern/138407: [gre] gre(4) interface does not come up after reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Terrence Koeman List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 21:40:08 -0000 The following reply was made to PR kern/138407; it has been noted by GNATS. From: "Terrence Koeman" To: "bug-followup@FreeBSD.org" , "nkritsky@mail.ru" Cc: Subject: Re: kern/138407: [gre] gre(4) interface does not come up after reboot Date: Sun, 08 Jul 2012 23:33:29 +0200 I can confirm that this problem still exists: FreeBSD sanshou.mediamonks.net 8.3-STABLE FreeBSD 8.3-STABLE #14: Sun Jul = 8 08:35:04 CEST 2012 gre0: flags=3D9011 metric 0 mtu 1300 tunnel inet 77.95.x.x --> 78.86.x.x inet x.64.1.2 --> x.64.1.1 netmask 0xfffffffc No 'RUNNING' after reboot and as said by the reporter, issuing an 'up' or r= unning tcpdump on the interface brings it up. -- Regards, T. Koeman, MTh/BSc/BPsy; Chief Technical Monk MediaMonks B.V. (www.mediamonks.com) Please quote relevant replies in correspondence. From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 22:03:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED369106566C for ; Sun, 8 Jul 2012 22:03:43 +0000 (UTC) (envelope-from chris.benesch@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A36B18FC08 for ; Sun, 8 Jul 2012 22:03:43 +0000 (UTC) Received: by yenl8 with SMTP id l8so11121030yen.13 for ; Sun, 08 Jul 2012 15:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6C08JOfLGf3rBj/kHsIIH6PKhksS1NWQ3CsbDweEsLQ=; b=jzo5VXNoYe0YA+dAK1dyTqjt3F08rGAcCl0zNfhr0k/c7E+eTs9nrdjS4aV86bOp4w 04oAV6Acw6LtjluL3ehzpwYxDFanN1eVeVLYDbs/u8PDJWaezv8kG7rbUz2NtcKZnAkk KpdTz5AuS4JaPIvUDse3B4mPwCnmho+nnWMwH7vDB7rPKYEZhpQKAJbvek2iIO5wK/zE W4pkm/wHOa8W7FWnDU1C8vMnd20ey5k/sz/cU39KRS2KXJnQ1oL2THHHugYhYmWCBXpo uxDeDpG03LFzCe4K5+rYkFjdESpMTd058PkvynCTV+xb4GeSXH65ULtnmoJps7+N3uj5 EOKw== MIME-Version: 1.0 Received: by 10.50.160.202 with SMTP id xm10mr7073977igb.10.1341785016884; Sun, 08 Jul 2012 15:03:36 -0700 (PDT) Received: by 10.231.26.150 with HTTP; Sun, 8 Jul 2012 15:03:36 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Jul 2012 15:03:36 -0700 Message-ID: From: Chris Benesch To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: IPSec woes coming from OpenBSD to Free X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 22:03:44 -0000 http://copamadman.blogspot.com/2012/07/freebsd-90-how-to-set-up-ipsec-vpn.html From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 02:29:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E92981065673 for ; Mon, 9 Jul 2012 02:29:50 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id BC6078FC16 for ; Mon, 9 Jul 2012 02:29:50 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:54131 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1So3jS-0007kH-0Z; Sun, 08 Jul 2012 22:29:50 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <1341718291.13585.15.camel@tabernacle> Date: Sun, 8 Jul 2012 22:29:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <1341718291.13585.15.camel@tabernacle> To: Julian Stecklina X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: freebsd-net@freebsd.org Subject: Re: TCP Regression Test Suite X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 02:29:51 -0000 On Jul 7, 2012, at 23:31 , Julian Stecklina wrote: > Hello, > > do you know of a TCP regression test suite with IPv6 support? > Alas, not a good one. Best George From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 08:12:35 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BDA4106566C for ; Mon, 9 Jul 2012 08:12:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id DC0798FC1F for ; Mon, 9 Jul 2012 08:12:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q698CQPI084777; Mon, 9 Jul 2012 12:12:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q698CPBY084776; Mon, 9 Jul 2012 12:12:25 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 9 Jul 2012 12:12:25 +0400 From: Gleb Smirnoff To: Przemyslaw Frasunek Message-ID: <20120709081225.GJ21957@glebius.int.ru> References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4FF7F2C6.5070401@freebsd.lublin.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Mike Tancsa , Ryan Stone , Eugene Grosbein , bzeeb-lists@lists.zabbadoz.net Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 08:12:35 -0000 On Sat, Jul 07, 2012 at 10:26:46AM +0200, Przemyslaw Frasunek wrote: P> > After reenabling IPv6, the crash occurred within 6 hours. This time, crashdump P> > was properly saved (thanks to patch suggested by Eugene). P> P> My PPPoE BRAS was stable for 17 days. This morning, it crashed in another way: P> P> current process = 2762 (mpd5) P> trap number = 9 P> panic: general protection fault P> cpuid = 5 P> KDB: stack backtrace: P> #0 0xffffffff803a04a6 at kdb_backtrace+0x66 P> #1 0xffffffff8036dfde at panic+0x1ce P> #2 0xffffffff80503300 at trap_fatal+0x290 P> #3 0xffffffff80503851 at trap+0x111 P> #4 0xffffffff804ea5d4 at calltrap+0x8 P> #5 0xffffffff8041d314 at lltable_prefix_free+0x74 P> #6 0xffffffff8044c014 at in_ifscrub+0x2c4 P> #7 0xffffffff8044d3f3 at in_control+0x793 P> #8 0xffffffff80418d2d at ifioctl+0xccd P> #9 0xffffffff803b6842 at kern_ioctl+0x92 P> #10 0xffffffff803b6aa0 at ioctl+0xf0 P> #11 0xffffffff80502ab2 at amd64_syscall+0x302 P> #12 0xffffffff804ea8cc at Xfast_syscall+0xfc P> Uptime: 17d7h18m38s This looks very much related to a known race in ARP code. See this email and related thread: http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031865.html Ryan didn't check in any patches since, and I failed to follow on this problem due to ENOTIME. I've added Ryan to Cc. Ryan, what's the status of the problem at your side? Did you come to any solution? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 09:49:16 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14851065670 for ; Mon, 9 Jul 2012 09:49:15 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA308FC22 for ; Mon, 9 Jul 2012 09:49:14 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q699nBsS091614 for ; Mon, 9 Jul 2012 16:49:11 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FFAA917.8020700@rdtc.ru> Date: Mon, 09 Jul 2012 16:49:11 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: ip_reass() fails to reassemble fragmented out-of-order traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 09:49:16 -0000 Hi! For long time I suffer from RELENG_8's inability to reassemble several types of incoming fragmented packets when they arrive of-of-order. For example: my gif(4) interface has MTU=1500, so it gets fragmented when it goes out to the Internet. For some reason, in this setup 80% get reordered while traveling the Internet. tcpdump shows me that at receiving side. While I send these packets, sysctl net.inet.ip.fragpackets increases at receiving side. No one reordered packet get reassembled. Some packet's fragments arrive in order and those get reassembled just fine and tcpdump shows them at receiving gif interface, and only them. Note, there is no such problem for ICMP fragmented packets in this setup, IPIP fragments are affected only. Please help. Eugene Grosbein. From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 11:07:16 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E909106566C for ; Mon, 9 Jul 2012 11:07:16 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 37EE48FC18 for ; Mon, 9 Jul 2012 11:07:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q69B7G5k075501 for ; Mon, 9 Jul 2012 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q69B7FXT075499 for freebsd-net@FreeBSD.org; Mon, 9 Jul 2012 11:07:15 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Jul 2012 11:07:15 GMT Message-Id: <201207091107.q69B7FXT075499@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:07:16 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 406 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 11:13:57 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 312711065670 for ; Mon, 9 Jul 2012 11:13:57 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4E68FC1A for ; Mon, 9 Jul 2012 11:13:56 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q69BDrVU092449 for ; Mon, 9 Jul 2012 18:13:53 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FFABCF1.6070403@rdtc.ru> Date: Mon, 09 Jul 2012 18:13:53 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" References: <4FFAA917.8020700@rdtc.ru> In-Reply-To: <4FFAA917.8020700@rdtc.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Subject: Re: ip_reass() fails to reassemble fragmented out-of-order traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 11:13:57 -0000 09.07.2012 16:49, Eugene Grosbein ÐÉÛÅÔ: > Hi! > > For long time I suffer from RELENG_8's inability to reassemble several types > of incoming fragmented packets when they arrive of-of-order. > > For example: my gif(4) interface has MTU=1500, so it gets fragmented > when it goes out to the Internet. For some reason, in this setup 80% get reordered > while traveling the Internet. tcpdump shows me that at receiving side. > > While I send these packets, sysctl net.inet.ip.fragpackets increases at receiving side. > > No one reordered packet get reassembled. Some packet's fragments arrive in order > and those get reassembled just fine and tcpdump shows them at receiving gif interface, > and only them. > > Note, there is no such problem for ICMP fragmented packets in this setup, > IPIP fragments are affected only. For some reason, ICMP fragments just pass without reordering. I've captured all two fragments of one packet at sending side and at receiving side and put them online here: http://www.grosbein.net/freebsd/reorder/ tcpdump shows no errors in fragment's checksums. Still, they were not reassembled. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 20:25:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 264C31065670; Mon, 9 Jul 2012 20:25:34 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 796988FC0C; Mon, 9 Jul 2012 20:25:33 +0000 (UTC) Received: by weyx56 with SMTP id x56so461598wey.13 for ; Mon, 09 Jul 2012 13:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yV77FD0MW0GFu12xRLkzmo9uQeqTcXjqIGvSyWjuLB0=; b=c4x4C8N6SgazCMT65hMSvx22h+dvbk413YoB+4E9IoYk9CDLRpDpyus7gqU42i8aeU 0Ib4UnoHfECvHP+g64Q5ywOowjCA5HXQ4sLsbCIvV4RAFFD6CAtBhksoqOzqF/DR1WKc 3SOYd7ettDYk65FCCafiVgY1OuDSoch/7DvfUk0t0lbIHNCmC3x6Uak7RXQsZN0W5Q3E to9UXSG6UpadxVdWSkq956YQObYcmeUYXoN3qKcKTx9Xjuyvk8WKA0n5VB791Whf97EK VjcpW9x2pg1LHVPC7kousfzn2K1LqRkCvGiYSxviWBlxj7p1C6O/lzP3EMt/rVuDTRRW ytRg== MIME-Version: 1.0 Received: by 10.216.2.132 with SMTP id 4mr4649508wef.208.1341865532379; Mon, 09 Jul 2012 13:25:32 -0700 (PDT) Received: by 10.180.103.137 with HTTP; Mon, 9 Jul 2012 13:25:32 -0700 (PDT) In-Reply-To: <20120709081225.GJ21957@glebius.int.ru> References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> Date: Mon, 9 Jul 2012 16:25:32 -0400 Message-ID: From: Ryan Stone To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: bzeeb-lists@lists.zabbadoz.net, Przemyslaw Frasunek , Mike Tancsa , Eugene Grosbein , freebsd-net@freebsd.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:25:34 -0000 On Mon, Jul 9, 2012 at 4:12 AM, Gleb Smirnoff wrote: > This looks very much related to a known race in ARP code. > > See this email and related thread: > > http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031865.html > > Ryan didn't check in any patches since, and I failed to follow on this > problem due to ENOTIME. > > I've added Ryan to Cc. Ryan, what's the status of the problem at your > side? Did you come to any solution? Unfortunately I was never able to come to a satisfactory solution. As I recall, in the end I ran headlong into problems with making the locking sane. The big problem was with arpresolve. At one point it calls callout_reset to schedule the LLE's la_timer. In my patch this would have to be done with a write lock help on the afdata lock. However, this acquisition would have to be done before taking the LLE_LOCK to prevent a LOR, and in the end you conclude that you have to take a write lock on the ifnet's afdata lock for every packet that goes through arpresolve, which was a non-starter. That's the point that I reached before I got distracted by other things at $WORK. As I recall, the in6 case was even worse, as the in6 equivalent of arptimer is significantly more complicated and likes to do crazy things like dropping locks. From owner-freebsd-net@FreeBSD.ORG Mon Jul 9 20:30:31 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00982106566B; Mon, 9 Jul 2012 20:30:31 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 4926E8FC08; Mon, 9 Jul 2012 20:30:30 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q69KUBMe014546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 05:30:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q69KUAf4075857; Tue, 10 Jul 2012 05:30:11 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 10 Jul 2012 05:30:02 +0900 (JST) Message-Id: <20120710.053002.914215153752773154.hrs@allbsd.org> To: melifaro@FreeBSD.org, net@FreeBSD.org From: Hiroki Sato In-Reply-To: <4FFA9723.5000301@FreeBSD.org> References: <4FFA894D.9050104@FreeBSD.org> <20120709.170813.339720376082380726.hrs@allbsd.org> <4FFA9723.5000301@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Jul_10_05_30_02_2012_869)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 10 Jul 2012 05:30:22 +0900 (JST) X-Spam-Status: No, score=-96.8 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, RCVD_IN_RP_RNBL, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r238277 - in head: etc/defaults etc/rc.d sbin/ipfw share/man/man5 sys/netinet/ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: net@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:30:31 -0000 ----Security_Multipart(Tue_Jul_10_05_30_02_2012_869)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Alexander V. Chernikov" wrote in <4FFA9723.5000301@FreeBSD.org>: me> On 09.07.2012 12:08, Hiroki Sato wrote: me> > "Alexander V. Chernikov" wrote me> > in<4FFA894D.9050104@FreeBSD.org>: me> > me> > I meant there was no strong objection. I am sorry for not commenting me> > your implementation, but at least for ipfw0 it is difficult to me> > decouple ifnet and bpf because the primary consumer is tcpdump(8), me> > which depends on NET_RT_IFLIST to find the target. Probably your me> tcpdump -i still works with interface name supplied. me> > solution can be used for usbdump(8). The reason why I committed the me> > patch now is there are reports that these pseudo interfaces made some me> > applications confused and/or caused some performance degradation on me> > 9.0R, and wanted to fix it in some way. me> Do you plan to take this to 9.1 ? Originally I thought of it but I think it was too late. It should be polished in -CURRENT for a while also in terms of how to hide the interfaces. me> > I am still open for more sophisticated implementation and have no me> > objection to replace mine with it. Do you have an idea about me> > converting it with a loadable module? me> Personally I think that the right way is to add user<>kernel interface me> for requesting interface list since this is the most major stopper for me> doing BPF-only providers. However this should be discussed with me> rpaulo@ and delphij@ (so most probably this skips 9.1). Adding a sysctl to list all of the struct bpf_if including ones with a fake ifp? Hm, my goal was just to hide usbusN and ipfw0 *by default* but there was no problem with having ipfw0 with an ifnet. I thought having ifnet was tolerable if its consumer was tcpdump-like one because there are a lot of packet dump utilities which obtain interface names from the system's network interface list. Hiding the interface is rather confusing from user's perspective. I do not stick to the committed code and have no objection about adding a new API if it is useful. Well, please let me check if I understand your idea correctly. Given that we add a new API to enumerate the interfaces including bpf-only providers with fake ifnets, which providers/utilities should be converted to use it? IMO usbusN would be a reasonable target but others still need a real ifnet. In my understanding, the advantage of using a fake ifnet is just to prevent it from appearing as an interface. Is it correct? me> And, as fallback solution we can probably add separate ipfwlog module me> which is quite easy but much less clean. I think whether having it as a kernel module or not is orthogonal to hiding the interface. If we support multiple instances of the pseudo interface (typical in a system with vnet), cloning capability is needed in any way. -- Hiroki ----Security_Multipart(Tue_Jul_10_05_30_02_2012_869)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk/7P0oACgkQTyzT2CeTzy3nFgCgi4rHRHX7M2iRk+1Fex+xjvuY uzQAnRZ5OgQKnlB+CkF2fnZOYae/SuVF =oK8F -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Jul_10_05_30_02_2012_869)---- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 00:38:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E8C106566B for ; Tue, 10 Jul 2012 00:38:38 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by mx1.freebsd.org (Postfix) with ESMTP id C319D8FC08 for ; Tue, 10 Jul 2012 00:38:37 +0000 (UTC) Received: from mail36-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Jul 2012 00:36:14 +0000 Received: from mail36-va3 (localhost [127.0.0.1]) by mail36-va3-R.bigfish.com (Postfix) with ESMTP id 0883E1C034F for ; Tue, 10 Jul 2012 00:36:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzc85fhzz1202hzz8275bh8275dh74efjz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail36-va3: domain of qlogic.com designates 198.70.193.64 as permitted sender) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail36-va3 (localhost.localdomain [127.0.0.1]) by mail36-va3 (MessageSwitch) id 1341880571285400_23475; Tue, 10 Jul 2012 00:36:11 +0000 (UTC) Received: from VA3EHSMHS037.bigfish.com (unknown [10.7.14.254]) by mail36-va3.bigfish.com (Postfix) with ESMTP id 42465100065 for ; Tue, 10 Jul 2012 00:36:11 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by VA3EHSMHS037.bigfish.com (10.7.99.47) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Jul 2012 00:36:11 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Mon, 9 Jul 2012 17:38:27 -0700 From: Adarsh Joshi To: "freebsd-net@freebsd.org" Date: Mon, 9 Jul 2012 17:38:24 -0700 Thread-Topic: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance Thread-Index: Ac1eMxngSmrEDoCLScCHz4wKHSkMkg== Message-ID: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 00:38:38 -0000 Hi, I am trying to configure lacp lagg interfaces with 2 systems connected back= to back as follows: Ifconfig lagg0 create Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netma= sk 255.255.255.0 Sometimes, the lag interface comes up correctly but sometimes the laggport = flags do not show properly. Instead of 1c, = it shows values of 18. I have seen similar issues reported on various forum= s with no solution. Looking at the lagg driver code and reading the standard, I thought the lag= gport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in fil= e ieee8023ad_lacp.h. But the following ifconfig -v output does not make any= sense to me. My concern is that when all the interfaces show flags as 1c, the traffic is= distributed across both the interfaces uniformly and I get aggregated thro= ughput. If not, the traffic flows only on 1 interface. Is this a bug? How do I solve this? Or am I doing something wrong? I am using Free-BSD 9.0 release. System 1: # ifconfig -v lagg0 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D13b ether 00:0e:1e:08:05:20 inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] laggport: ql1 flags=3D18 state=3D7D [(8000,00-0E-1E-08-05-20,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D1c state=3D3D [(8000,00-0E-1E-08-05-20,0213,8000,000E), (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] System 2: # ifconfig -v lagg0 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D13b ether 00:0e:1e:04:2c:f0 inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: ql1 flags=3D1c state=3D7D [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D18 state=3D3D [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), (8000,00-0E-1E-08-05-20,0213,8000,000E)] thanks Adarsh ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 05:03:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E1421065674; Tue, 10 Jul 2012 05:03:44 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id D1B888FC1D; Tue, 10 Jul 2012 05:03:43 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q6A53akx098164; Tue, 10 Jul 2012 12:03:37 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FFBB7A8.90201@rdtc.ru> Date: Tue, 10 Jul 2012 12:03:36 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ryan Stone References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: bzeeb-lists@lists.zabbadoz.net, Przemyslaw Frasunek , Mike Tancsa , freebsd-net@freebsd.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 05:03:44 -0000 10.07.2012 03:25, Ryan Stone ÐÉÛÅÔ: > On Mon, Jul 9, 2012 at 4:12 AM, Gleb Smirnoff wrote: >> This looks very much related to a known race in ARP code. >> >> See this email and related thread: >> >> http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031865.html >> >> Ryan didn't check in any patches since, and I failed to follow on this >> problem due to ENOTIME. >> >> I've added Ryan to Cc. Ryan, what's the status of the problem at your >> side? Did you come to any solution? > > Unfortunately I was never able to come to a satisfactory solution. As > I recall, in the end I ran headlong into problems with making the > locking sane. The big problem was with arpresolve. At one point it > calls callout_reset to schedule the LLE's la_timer. In my patch this > would have to be done with a write lock help on the afdata lock. > However, this acquisition would have to be done before taking the > LLE_LOCK to prevent a LOR, and in the end you conclude that you have > to take a write lock on the ifnet's afdata lock for every packet that > goes through arpresolve, which was a non-starter. That's the point > that I reached before I got distracted by other things at $WORK. > > As I recall, the in6 case was even worse, as the in6 equivalent of > arptimer is significantly more complicated and likes to do crazy > things like dropping locks. It seems, Przemyslaw Frasunek uses proxyarp? I have no such problems but I do not use proxyarp. Could you get rid of it, Przemyslaw? Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 05:29:34 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E3D0106566B for ; Tue, 10 Jul 2012 05:29:34 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 92B3F8FC08 for ; Tue, 10 Jul 2012 05:29:33 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q6A5TV9J093813; Tue, 10 Jul 2012 09:29:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q6A5TVM4093812; Tue, 10 Jul 2012 09:29:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 10 Jul 2012 09:29:31 +0400 From: Gleb Smirnoff To: Eugene Grosbein Message-ID: <20120710052931.GV21957@glebius.int.ru> References: <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4FFBB7A8.90201@rdtc.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bzeeb-lists@lists.zabbadoz.net, Przemyslaw Frasunek , Mike Tancsa , Ryan Stone , freebsd-net@FreeBSD.org Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 05:29:34 -0000 On Tue, Jul 10, 2012 at 12:03:36PM +0700, Eugene Grosbein wrote: E> 10.07.2012 03:25, Ryan Stone ÐÉÛÅÔ: E> > On Mon, Jul 9, 2012 at 4:12 AM, Gleb Smirnoff wrote: E> >> This looks very much related to a known race in ARP code. E> >> E> >> See this email and related thread: E> >> E> >> http://lists.freebsd.org/pipermail/freebsd-net/2012-March/031865.html E> >> E> >> Ryan didn't check in any patches since, and I failed to follow on this E> >> problem due to ENOTIME. E> >> E> >> I've added Ryan to Cc. Ryan, what's the status of the problem at your E> >> side? Did you come to any solution? E> > E> > Unfortunately I was never able to come to a satisfactory solution. As E> > I recall, in the end I ran headlong into problems with making the E> > locking sane. The big problem was with arpresolve. At one point it E> > calls callout_reset to schedule the LLE's la_timer. In my patch this E> > would have to be done with a write lock help on the afdata lock. E> > However, this acquisition would have to be done before taking the E> > LLE_LOCK to prevent a LOR, and in the end you conclude that you have E> > to take a write lock on the ifnet's afdata lock for every packet that E> > goes through arpresolve, which was a non-starter. That's the point E> > that I reached before I got distracted by other things at $WORK. E> > E> > As I recall, the in6 case was even worse, as the in6 equivalent of E> > arptimer is significantly more complicated and likes to do crazy E> > things like dropping locks. E> E> It seems, Przemyslaw Frasunek uses proxyarp? E> I have no such problems but I do not use proxyarp. E> Could you get rid of it, Przemyslaw? I'm not sure this is related. The race happens w/o proxy arp as well. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 06:24:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7223A106566B; Tue, 10 Jul 2012 06:24:37 +0000 (UTC) (envelope-from venglin@freebsd.lublin.pl) Received: from lagoon.freebsd.lublin.pl (lagoon.freebsd.lublin.pl [IPv6:2a02:2928:a::3]) by mx1.freebsd.org (Postfix) with ESMTP id F02698FC17; Tue, 10 Jul 2012 06:24:36 +0000 (UTC) Received: from [192.168.1.102] (vlan-179-255.nesebar-lan.net [84.54.179.255]) by lagoon.freebsd.lublin.pl (Postfix) with ESMTPSA id 466A8239456; Tue, 10 Jul 2012 08:24:32 +0200 (CEST) Message-ID: <4FFBCA96.3000605@freebsd.lublin.pl> Date: Tue, 10 Jul 2012 08:24:22 +0200 From: Przemyslaw Frasunek Organization: frasunek.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eugene Grosbein References: <20110513162311.GK95084@glebius.int.ru> <4DD298AD.2060905@frasunek.com> <20110517184613.GN74366@glebius.int.ru> <4FDB1D71.6050908@freebsd.lublin.pl> <20120615203142.GW28613@glebius.int.ru> <4FDBAFD7.9020606@freebsd.lublin.pl> <4FDF2F81.6030307@sentex.net> <4FDF3097.6080701@freebsd.lublin.pl> <4FE0EE62.5070905@freebsd.lublin.pl> <4FF7F2C6.5070401@freebsd.lublin.pl> <20120709081225.GJ21957@glebius.int.ru> <4FFBB7A8.90201@rdtc.ru> In-Reply-To: <4FFBB7A8.90201@rdtc.ru> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ryan Stone , Mike Tancsa , bzeeb-lists@lists.zabbadoz.net Subject: Re: mpd5/Netgraph issues after upgrading to 7.4 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 06:24:37 -0000 > It seems, Przemyslaw Frasunek uses proxyarp? > I have no such problems but I do not use proxyarp. > Could you get rid of it, Przemyslaw? No, I don't use proxy ARP. I have about 300 PPPoE ng interfaces and 10 VLANs with plain IP traffic. ARP table has only < 50 entries, all of them are dynamic. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 07:10:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19A5F106566B for ; Tue, 10 Jul 2012 07:10:16 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A97788FC17 for ; Tue, 10 Jul 2012 07:10:15 +0000 (UTC) Received: by ggnm2 with SMTP id m2so12609577ggn.13 for ; Tue, 10 Jul 2012 00:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=Yrxrz70WqBEtArNBG/eRbNrxvhdSqocZ5B5zzaS9G9M=; b=LaVFObOhJCBITtlTWrjqG1DcWw/ifseVEgQm8yO5C+wBeA6+8Pn7FRtche2YD0q8aa nfAlxn7ZuHboN8KpNv7lNH1DIbLbrjFc4FPg2k3uHcqXVEfdSTBO6aUemito7NjERfrW 6zYqQEMLQPB0AkyDlohAJ1TCpvttLu0ZqGrpY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=Yrxrz70WqBEtArNBG/eRbNrxvhdSqocZ5B5zzaS9G9M=; b=cGJY3zL2nbLYtq62HZ53JjsmZC6JdhyAt9YU2tTwNu2pRP+ntA8ULCek5pZfGyHAP4 /ZGRUgZLxFTo/YwM/HJ/a+M1h1y2orsyVM/xJ2peDNEIiF3YRz3MvH8MRDUI1GX49dLg NM3os25POtXQy345OAg32kZhwD2WablUZExrnqhCGaY4MTGR/uQns8LioL995I0V7J7k 1+O0zi3sajZAwZwCOsH3co4g+CLCcULIKEVFHOAUW4PpLD86VLJcCGtGR/b7EcxsBGYh HZw0mTrvLlrV2YUBVTYs8H0W4RZFQf9xgk8gbDJ1ufWaIhlIOoJEPPMoJHa0JuTtu8TK Wqfg== Received: by 10.50.41.201 with SMTP id h9mr604487igl.37.1341904214979; Tue, 10 Jul 2012 00:10:14 -0700 (PDT) Received: from DataIX.net (adsl-99-181-136-60.dsl.klmzmi.sbcglobal.net. [99.181.136.60]) by mx.google.com with ESMTPS id if4sm11032084igc.10.2012.07.10.00.10.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 00:10:14 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6A7ABSW094638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 03:10:12 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6A7ABfH094637; Tue, 10 Jul 2012 03:10:11 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Tue, 10 Jul 2012 03:10:11 -0400 From: Jason Hellenthal To: Adarsh Joshi Message-ID: <20120710071011.GB91639@DataIX.net> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> X-Gm-Message-State: ALoCoQnIWrAibjDkdSfJSInEf33XrfLVsIIKJdS3dYfiJkiQukDWsUuz2kbdLf2DoELnhA0C5s3+ Cc: "freebsd-net@freebsd.org" Subject: Re: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 07:10:16 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 09, 2012 at 05:38:24PM -0700, Adarsh Joshi wrote: > Hi, >=20 > I am trying to configure lacp lagg interfaces with 2 systems connected ba= ck to back as follows: >=20 > Ifconfig lagg0 create > Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 net= mask 255.255.255.0 >=20 > Sometimes, the lag interface comes up correctly but sometimes the laggpor= t flags do not show properly. Instead of 1c= , it shows values of 18. I have seen similar issues reported on various for= ums with no solution. > Looking at the lagg driver code and reading the standard, I thought the l= aggport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in f= ile ieee8023ad_lacp.h. But the following ifconfig -v output does not make a= ny sense to me. >=20 > My concern is that when all the interfaces show flags as 1c, the traffic = is distributed across both the interfaces uniformly and I get aggregated th= roughput. If not, the traffic flows only on 1 interface. >=20 > Is this a bug? How do I solve this? Or am I doing something wrong? >=20 > I am using Free-BSD 9.0 release. >=20 > System 1: > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 mtu = 1500 > options=3D13b > ether 00:0e:1e:08:05:20 > inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), > (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > laggport: ql1 flags=3D18 state=3D7D > [(8000,00-0E-1E-08-05-20,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D1c state=3D= 3D > [(8000,00-0E-1E-08-05-20,0213,8000,000E), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] >=20 > System 2: >=20 > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 mtu = 1500 > options=3D13b > ether 00:0e:1e:04:2c:f0 > inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql1 flags=3D1c state=3D= 7D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D18 state=3D3D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,0213,8000,000E)] >=20 >=20 Just for reference ... (stable/8 @ r238264) lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D80048 ether 00:0c:41:21:1d:b5 inet 192.168.XX.X netmask 0xffffff00 broadcast 192.168.XX.XXX media: Ethernet autoselect status: active groups: lagg=20 laggproto lacp lagghash l2,l3,l4 lag id: [(8000,00-0C-41-21-1D-B5,00E6,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: dc1 flags=3D1c state=3D7D [(8000,00-0C-41-21-1D-B5,00E6,8000,0002), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: dc0 flags=3D1c state=3D7D [(8000,00-0C-41-21-1D-B5,00E6,8000,0001), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] They have had flags =3D 1c for quite some time and state =3D 7D And just to show the variation ... dc0: yesterday 8.53 MiB / 2.61 MiB / 11.14 MiB today 693 KiB / 156 KiB / 849 KiB dc1: yesterday 19.00 MiB / 1.79 MiB / 20.78 MiB today 496 KiB / 103 KiB / 599 KiB lagg0: yesterday 27.53 MiB / 3.71 MiB / 31.24 MiB today 1.16 MiB / 172 KiB / 1.33 MiB I believe (know) there has been some changes in the LAgg code in stable/9 and stable/8 recently so you may want to check into that. Given this is LAgg and LACP you will see some variation regardless but I recall a point that it seemed like one interface was being favored over the other quite repeatedly or obsessively that had me second guessing whether it was doing the right thing. LACP in Cisco is quite different than how we treat it here in FreeBSD as it tends to use the interfaces quite evenly all the time so that also has me second guessing whether the right thing is happening here. ( in PAgP and LACP modes ). These tunables (sysctl)'s may also lead you in direction you want to look in. net.link.lagg.default_use_flowid: 1 net.link.lagg.failover_rx_all: 0 net.link.lagg.0.use_flowid: 1 -rxcsum & -txcsum for lo0 and ql0 ql1 might be of benefit too though I only turn them off on lo0. Good luck --=20 - (2^(N-1)) --huq684BweRXVnRxX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP+9VSAAoJEBSh2Dr1DU7WHzEH/2PBC6Iz1BOoL8PPAEfzb/Mz llMEDATV45W+JVWyAeWaG2GH+o7KaQPfp/Z5qTH/dcgqA3r7fiCqrRZpd61DhbGF GlzryhUJKY9V/FDJXCSaevyhFdjtosvZQ8qEchA18FsDGEX2wA/4dXv/BZs1YQQx yhXgVd3gIjrqa7bt0sqOqWdngizVHaEt7oDyFvl2I4kpTbd1TETUOCXT2IMEGNPQ uVghGx3sQSiAePXV1IjizMcW0QGOTX+bUmJLlvQXSOPjxkXIRYnn2xSIh8WGMZT+ iK2UiuvzY8mIPBTVw+yvst954pxrscWPNXPhH8nqAudp3SHpSlWPszEJwxN3Ypo= =pvae -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 08:29:12 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4B4D106566C for ; Tue, 10 Jul 2012 08:29:12 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 418308FC08 for ; Tue, 10 Jul 2012 08:29:05 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q6A8MX7O008318 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 10:22:33 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q6A8MWNY017764; Tue, 10 Jul 2012 10:22:32 +0200 (MEST) Date: Tue, 10 Jul 2012 10:22:32 +0200 From: Daniel Hartmeier To: Eugene Grosbein Message-ID: <20120710082232.GA9145@insomnia.benzedrine.cx> References: <4FFAA917.8020700@rdtc.ru> <4FFABCF1.6070403@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFABCF1.6070403@rdtc.ru> User-Agent: Mutt/1.5.12-2006-07-14 Cc: "net@freebsd.org" Subject: Re: ip_reass() fails to reassemble fragmented out-of-order traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:29:12 -0000 On Mon, Jul 09, 2012 at 06:13:53PM +0700, Eugene Grosbein wrote: > tcpdump shows no errors in fragment's checksums. > Still, they were not reassembled. I fed your two fragments (with libdnet) to ip_input.c ip_reass() with debug printfs added, it reassembles them fine, even when in reversed order: Jul 10 09:06:03 testA kernel: ip_reass() called ip_id 0x87EE Jul 10 09:06:03 testA kernel: ip_reass: no queue Jul 10 09:06:03 testA kernel: ip_reass: IP_MF clear Jul 10 09:06:03 testA kernel: ip_reass: created queue Jul 10 09:06:03 testA kernel: ip_reass: returning NULL Jul 10 09:06:03 testA kernel: ip_reass() called ip_id 0x87EE Jul 10 09:06:03 testA kernel: ip_reass: found queue Jul 10 09:06:03 testA kernel: ip_reass: IP_MF set Jul 10 09:06:03 testA kernel: ip_reass: no previous segment Jul 10 09:06:03 testA kernel: ip_reass: complete? ip_off 0, next 0 Jul 10 09:06:03 testA kernel: ip_reass: complete? ip_off 1480, next 1480 Jul 10 09:06:03 testA kernel: ip_reass: complete! Jul 10 09:06:03 testA kernel: ip_reass: concated Jul 10 09:06:03 testA kernel: ip_reass: m_fixhdr() 1500 -> 1501 Jul 10 09:06:03 testA kernel: ip_reass: returning non-NULL, m_len 1500, ip_len 1501 Jul 10 09:06:03 testA kernel: mbuf: 0xc4bb3c00 len: 1500, next: 0xc4fdb000, 803, Jul 10 09:06:03 testA kernel: mbuf: 0xc4fdb000 len: 1, next: 0, 3 Jul 10 09:06:03 testA kernel: ip_input: ip_reass returned m_len 1500, ip_len 1501, hlen 20 And I see the ping with tcpdump on gif0 testA# ifconfig gif0 create testA# ifconfig gif0 tunnel outer-me outer-peer testA# ifconfig gif0 inet 192.168.50.10 192.168.50.9 netmask 255.255.255.0 up testA# tcpdump -s 1600 -nvvvi gif0 tcpdump: listening on gif0, link-type NULL (BSD loopback), capture size 1600 bytes 10:12:14.028436 IP (tos 0x0, ttl 128, id 61059, offset 0, flags [DF], proto ICMP (1), length 1481) 192.168.50.10 > 192.168.50.9: ICMP echo request, id 39570, seq 0, length 1461 ^C netstat -s diff: - 4 fragments received + 6 fragments received - 2 packets reassembled ok + 3 packets reassembled ok Input histogram: - echo: 1 - 1 message response generated + echo: 2 + 2 message responses generated Output histogram: - echo reply: 1 + echo reply: 2 Are any netstat -s counters increasing that show an error (fragments dropped, smaller than minimum)? Do you have lots of fragments in flight at the same time, hitting the fragment cache limit? testA# sysctl -a | grep maxfrag net.inet.ip.maxfragpackets: 800 net.inet.ip.maxfragsperpacket: 16 Are you running any pfil consumers (ipfilter, ipfw, pf), maybe unintentionally (with empty ruleset)? If so, can you try disabling them? Daniel From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 08:35:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2ABB106564A for ; Tue, 10 Jul 2012 08:35:19 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 36F158FC0C for ; Tue, 10 Jul 2012 08:35:19 +0000 (UTC) Received: by eabm6 with SMTP id m6so4805259eab.13 for ; Tue, 10 Jul 2012 01:35:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=z876bEE4+CxbrwwIP8AYrQOqbaXgJH8QuaCDVhfXoDE=; b=iC7quxPLcjSTH+dDrTjiLXg6UCowbeQZMn1m6xoGCb+rWdOHK0Shy3ILK7ev3Py7JL EKqqqP9nsqCDxH0h/dDourO5OpsuIC07lgxZpb9a0Jq3YzL2li7JM/ZkDgRauJgpyTM0 355DPqKb1XMb69FrVb0xkeNs9W+zaBoRfUUpQr/faPFsnd6rPGv5Dx1398t0vQERxGfg e1VISBDDRaPko+4aPMg2B3q5Mcb0HBRmOz8clB1SqfLnH5tpfg7hO0xO0axHualzbjm4 XGXmCWIbBGQx3FypCZcnDZMQ+PIIVrTjLr4R/Z1khjmeOR9mhS2+mLmGE6nBZu2Gtz8w Ek/g== Received: by 10.14.94.204 with SMTP id n52mr10306484eef.200.1341909311500; Tue, 10 Jul 2012 01:35:11 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id q53sm100458608eef.8.2012.07.10.01.35.10 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 01:35:10 -0700 (PDT) Message-ID: <4FFBE93C.3080808@my.gd> Date: Tue, 10 Jul 2012 10:35:08 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> <20120710071011.GB91639@DataIX.net> In-Reply-To: <20120710071011.GB91639@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlguwduqvlMRgQ8buY253rBr2CfrKpMcE4ldOufj8HjizX9cpiy7wUdzRnZXSlnDIDqiMY+ Subject: Re: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:35:19 -0000 On 7/10/12 9:10 AM, Jason Hellenthal wrote: > > > On Mon, Jul 09, 2012 at 05:38:24PM -0700, Adarsh Joshi wrote: >> Hi, >> >> I am trying to configure lacp lagg interfaces with 2 systems connected back to back as follows: >> >> Ifconfig lagg0 create >> Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netmask 255.255.255.0 >> >> Sometimes, the lag interface comes up correctly but sometimes the laggport flags do not show properly. Instead of 1c, it shows values of 18. I have seen similar issues reported on various forums with no solution. >> Looking at the lagg driver code and reading the standard, I thought the laggport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in file ieee8023ad_lacp.h. But the following ifconfig -v output does not make any sense to me. >> >> My concern is that when all the interfaces show flags as 1c, the traffic is distributed across both the interfaces uniformly and I get aggregated throughput. If not, the traffic flows only on 1 interface. >> >> Is this a bug? How do I solve this? Or am I doing something wrong? >> >> I am using Free-BSD 9.0 release. >> >> System 1: >> # ifconfig -v lagg0 >> lagg0: flags=8843 metric 0 mtu 1500 >> options=13b >> ether 00:0e:1e:08:05:20 >> inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 >> nd6 options=29 >> media: Ethernet autoselect >> status: active >> groups: lagg >> laggproto lacp >> lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), >> (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] >> laggport: ql1 flags=18 state=7D >> [(8000,00-0E-1E-08-05-20,0213,8000,000F), >> (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] >> laggport: ql0 flags=1c state=3D >> [(8000,00-0E-1E-08-05-20,0213,8000,000E), >> (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] >> >> System 2: >> >> # ifconfig -v lagg0 >> lagg0: flags=8843 metric 0 mtu 1500 >> options=13b >> ether 00:0e:1e:04:2c:f0 >> inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 >> nd6 options=29 >> media: Ethernet autoselect >> status: active >> groups: lagg >> laggproto lacp >> lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), >> (FFFF,00-00-00-00-00-00,0000,0000,0000)] >> laggport: ql1 flags=1c state=7D >> [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), >> (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] >> laggport: ql0 flags=18 state=3D >> [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), >> (8000,00-0E-1E-08-05-20,0213,8000,000E)] >> >> > > Just for reference ... (stable/8 @ r238264) > > lagg0: flags=8843 metric 0 mtu 1500 > options=80048 > ether 00:0c:41:21:1d:b5 > inet 192.168.XX.X netmask 0xffffff00 broadcast 192.168.XX.XXX > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp lagghash l2,l3,l4 > lag id: [(8000,00-0C-41-21-1D-B5,00E6,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: dc1 flags=1c state=7D > [(8000,00-0C-41-21-1D-B5,00E6,8000,0002), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: dc0 flags=1c state=7D > [(8000,00-0C-41-21-1D-B5,00E6,8000,0001), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > > > They have had flags = 1c for quite some time and state = 7D > > And just to show the variation ... > > > dc0: > yesterday 8.53 MiB / 2.61 MiB / 11.14 MiB > today 693 KiB / 156 KiB / 849 KiB > > dc1: > yesterday 19.00 MiB / 1.79 MiB / 20.78 MiB > today 496 KiB / 103 KiB / 599 KiB > > lagg0: > yesterday 27.53 MiB / 3.71 MiB / 31.24 MiB > today 1.16 MiB / 172 KiB / 1.33 MiB > > > I believe (know) there has been some changes in the LAgg code in > stable/9 and stable/8 recently so you may want to check into that. > > Given this is LAgg and LACP you will see some variation regardless but I > recall a point that it seemed like one interface was being favored over > the other quite repeatedly or obsessively that had me second guessing > whether it was doing the right thing. > > LACP in Cisco is quite different than how we treat it here in FreeBSD as > it tends to use the interfaces quite evenly all the time so that also > has me second guessing whether the right thing is happening here. ( in > PAgP and LACP modes ). > Note that you can configure the way the switch load balances traffic thus: switch(config)#port-channel load-balance ? dst-ip Dst IP Addr dst-mac Dst Mac Addr src-dst-ip Src XOR Dst IP Addr src-dst-mac Src XOR Dst Mac Addr src-ip Src IP Addr src-mac Src Mac Addr You may also run simulations on the switch to see what interface from a port-channel would be used: switch#test etherchannel load-balance interface po48 ip 10.1.2.3 88.190.45.1 Would select Te1/1/2 of Po48 switch#test etherchannel load-balance interface po48 ip 10.1.2.3 88.190.45.9 Would select Te2/1/2 of Po48 switch#test etherchannel load-balance interface po48 ip 10.1.2.3 88.190.45.10 Would select Te2/1/2 of Po48 Hope this helps. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 08:45:28 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B353106566C for ; Tue, 10 Jul 2012 08:45:28 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id D7ABF8FC0A for ; Tue, 10 Jul 2012 08:45:27 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q6A8jLYe003069; Tue, 10 Jul 2012 15:45:21 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4FFBEBA1.9000706@rdtc.ru> Date: Tue, 10 Jul 2012 15:45:21 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Daniel Hartmeier References: <4FFAA917.8020700@rdtc.ru> <4FFABCF1.6070403@rdtc.ru> <20120710082232.GA9145@insomnia.benzedrine.cx> In-Reply-To: <20120710082232.GA9145@insomnia.benzedrine.cx> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: "net@freebsd.org" Subject: Re: ip_reass() fails to reassemble fragmented out-of-order traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 08:45:28 -0000 10.07.2012 15:22, Daniel Hartmeier ÐÉÛÅÔ: > Are you running any pfil consumers (ipfilter, ipfw, pf), maybe > unintentionally (with empty ruleset)? If so, can you try disabling them? No problems with netstat -s, but you were right about pfil - I direct all incoming traffic to ipfw nat. I passed ipencap packets without ipfw nat processing and the problem has disappeared. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 12:56:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3EBA106566C for ; Tue, 10 Jul 2012 12:56:45 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (50-73-27-109-cpennsylvania.hfc.comcastbusiness.net [50.73.27.109]) by mx1.freebsd.org (Postfix) with ESMTP id 985E98FC14 for ; Tue, 10 Jul 2012 12:56:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id A82D7480662; Tue, 10 Jul 2012 08:56:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqAFofp7THnd; Tue, 10 Jul 2012 08:56:41 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id 60933480653; Tue, 10 Jul 2012 08:56:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) From: Andrew Boyer In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> Date: Tue, 10 Jul 2012 08:56:36 -0400 Message-Id: <4C5FC147-2F49-4AE0-ADF3-C5381DE6580F@averesystems.com> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> To: Adarsh Joshi X-Mailer: Apple Mail (2.1278) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: Re: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 12:56:45 -0000 On Jul 9, 2012, at 8:38 PM, Adarsh Joshi wrote: > Hi, >=20 > I am trying to configure lacp lagg interfaces with 2 systems connected = back to back as follows: >=20 > Ifconfig lagg0 create > Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 = netmask 255.255.255.0 >=20 > Sometimes, the lag interface comes up correctly but sometimes the = laggport flags do not show properly. Instead of = 1c, it shows values of 18. I have seen = similar issues reported on various forums with no solution. > Looking at the lagg driver code and reading the standard, I thought = the laggport flags ( defined in if_lagg.h) are based on the = LACP_STATE_BITS in file ieee8023ad_lacp.h. But the following ifconfig -v = output does not make any sense to me. >=20 > My concern is that when all the interfaces show flags as 1c, the = traffic is distributed across both the interfaces uniformly and I get = aggregated throughput. If not, the traffic flows only on 1 interface. >=20 > Is this a bug? How do I solve this? Or am I doing something wrong? >=20 > I am using Free-BSD 9.0 release. >=20 > System 1: > # ifconfig -v lagg0 > lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), > (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > laggport: ql1 flags=3D18 state=3D7D > [(8000,00-0E-1E-08-05-20,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D1c = state=3D3D > [(8000,00-0E-1E-08-05-20,0213,8000,000E), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] >=20 > System 2: >=20 > # ifconfig -v lagg0 > lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql1 flags=3D1c = state=3D7D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D18 state=3D3D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,0213,8000,000E)] >=20 >=20 > thanks > Adarsh >=20 I don't think you have a port flags problem per se; the flags are = correctly displaying the state of the lagg. Your problem is that your = systems aren't negotiating the correct lagg configuration. Each tuple = after the laggport represents the [(actor state),(partner state)]. = Ports ql0 have been able to talk to their partners (each other). = Neither ql1 port has seen a response from a partner, though. You could try restarting the state machine on one box with 'ifconfig = lagg0 laggproto lacp'. To see the negotiation you'll need to rebuild = your kernel with '#define LACP_DEBUG 1' added to the top of = sys/net/ieee802.3ad_lacp.c. Or upgrade to a newer stable snapshot that = has the net.lacp_debug sysctl and turn it on. Or just turn off LACP. What does it get you in this configuration? Hope this helps, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 13:40:06 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0218106566B; Tue, 10 Jul 2012 13:40:05 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 739ED8FC08; Tue, 10 Jul 2012 13:40:05 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q6ADe44I098633; Tue, 10 Jul 2012 17:40:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q6ADe438098632; Tue, 10 Jul 2012 17:40:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 10 Jul 2012 17:40:04 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20120710134004.GE21957@FreeBSD.org> References: <4FFA894D.9050104@FreeBSD.org> <20120709.170813.339720376082380726.hrs@allbsd.org> <4FFA9723.5000301@FreeBSD.org> <20120710.053002.914215153752773154.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20120710.053002.914215153752773154.hrs@allbsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, melifaro@FreeBSD.org Subject: Re: svn commit: r238277 - in head: etc/defaults etc/rc.d sbin/ipfw share/man/man5 sys/netinet/ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:40:06 -0000 Hiroki, On Tue, Jul 10, 2012 at 05:30:02AM +0900, Hiroki Sato wrote: H> Given that we add a new API to H> enumerate the interfaces including bpf-only providers with fake H> ifnets, which providers/utilities should be converted to use it? IMO H> usbusN would be a reasonable target but others still need a real H> ifnet. In my understanding, the advantage of using a fake ifnet is H> just to prevent it from appearing as an interface. Is it correct? IMO, neither ipfwlog0 nor pflog0 nor pfsync0 need 'struct ifnet'. They are pure providers for tcpdump only. (pfsync0 also consumes if_ioctl to configure itself, but this can be axed and configuring should be done via /dev/pf as all other parts of pf.) As soon as Alexander comes with API that makes it possible to create BPF "dumping points" in kernel that aren't tied to 'struct ifnet', I'd be happy to remove pfsync/pflog/ipfwlog as interfaces. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 17:15:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C6B106564A for ; Tue, 10 Jul 2012 17:15:41 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by mx1.freebsd.org (Postfix) with ESMTP id 286038FC14 for ; Tue, 10 Jul 2012 17:15:40 +0000 (UTC) Received: from mail82-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Jul 2012 17:13:20 +0000 Received: from mail82-va3 (localhost [127.0.0.1]) by mail82-va3-R.bigfish.com (Postfix) with ESMTP id DBE7B42008C; Tue, 10 Jul 2012 17:13:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:198.70.193.61; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zz98dI9371I542M1432I1447I853kzz1202hzz8275dh74efjz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail82-va3: domain of qlogic.com designates 198.70.193.61 as permitted sender) client-ip=198.70.193.61; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail82-va3 (localhost.localdomain [127.0.0.1]) by mail82-va3 (MessageSwitch) id 1341940399772526_27550; Tue, 10 Jul 2012 17:13:19 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.240]) by mail82-va3.bigfish.com (Postfix) with ESMTP id B79514E0051; Tue, 10 Jul 2012 17:13:19 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Jul 2012 17:13:17 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Tue, 10 Jul 2012 10:15:34 -0700 From: Adarsh Joshi To: Jason Hellenthal Date: Tue, 10 Jul 2012 10:15:32 -0700 Thread-Topic: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance Thread-Index: Ac1eaxJj5XIwqx19SUajOXKTV+ranwAVBkpw Message-ID: <5E4F49720D0BAD499EE1F01232234BA877435B2F38@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> <20120710071011.GB91639@DataIX.net> In-Reply-To: <20120710071011.GB91639@DataIX.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Cc: "freebsd-net@freebsd.org" Subject: RE: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:15:41 -0000 Jason, Thanks for the reply. Why do you say - " Given this is LAgg and LACP you will see some variation = regardless " Can you please throw some more light on this? I understand if there is a slight variation in the throughput when LAGG and= LACP is configured but in my case, I do not see a single packet on 1 of th= e interface except for LACPDUs and other LACP control packets. Thanks Adarsh -----Original Message----- From: Jason Hellenthal [mailto:jhellenthal@dataix.net] Sent: Tuesday, July 10, 2012 12:10 AM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance On Mon, Jul 09, 2012 at 05:38:24PM -0700, Adarsh Joshi wrote: > Hi, > > I am trying to configure lacp lagg interfaces with 2 systems connected ba= ck to back as follows: > > Ifconfig lagg0 create > Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 > netmask 255.255.255.0 > > Sometimes, the lag interface comes up correctly but sometimes the laggpor= t flags do not show properly. Instead of 1c= , it shows values of 18. I have seen similar issues reported on various for= ums with no solution. > Looking at the lagg driver code and reading the standard, I thought the l= aggport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in f= ile ieee8023ad_lacp.h. But the following ifconfig -v output does not make a= ny sense to me. > > My concern is that when all the interfaces show flags as 1c, the traffic = is distributed across both the interfaces uniformly and I get aggregated th= roughput. If not, the traffic flows only on 1 interface. > > Is this a bug? How do I solve this? Or am I doing something wrong? > > I am using Free-BSD 9.0 release. > > System 1: > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 mtu = 1500 > options=3D13b > ether 00:0e:1e:08:05:20 > inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), > (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] > laggport: ql1 flags=3D18 state=3D7D > [(8000,00-0E-1E-08-05-20,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D1c state=3D= 3D > [(8000,00-0E-1E-08-05-20,0213,8000,000E), > (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] > > System 2: > > # ifconfig -v lagg0 > lagg0: flags=3D8843 metric 0 mtu = 1500 > options=3D13b > ether 00:0e:1e:04:2c:f0 > inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 > nd6 options=3D29 > media: Ethernet autoselect > status: active > groups: lagg > laggproto lacp > lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), > (FFFF,00-00-00-00-00-00,0000,0000,0000)] > laggport: ql1 flags=3D1c state=3D= 7D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), > (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] > laggport: ql0 flags=3D18 state=3D3D > [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), > (8000,00-0E-1E-08-05-20,0213,8000,000E)] > > Just for reference ... (stable/8 @ r238264) lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D80048 ether 00:0c:41:21:1d:b5 inet 192.168.XX.X netmask 0xffffff00 broadcast 192.168.XX.XXX media: Ethernet autoselect status: active groups: lagg laggproto lacp lagghash l2,l3,l4 lag id: [(8000,00-0C-41-21-1D-B5,00E6,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: dc1 flags=3D1c state=3D7D [(8000,00-0C-41-21-1D-B5,00E6,8000,0002), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: dc0 flags=3D1c state=3D7D [(8000,00-0C-41-21-1D-B5,00E6,8000,0001), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] They have had flags =3D 1c for quite some time and state =3D 7D And just to show the variation ... dc0: yesterday 8.53 MiB / 2.61 MiB / 11.14 MiB today 693 KiB / 156 KiB / 849 KiB dc1: yesterday 19.00 MiB / 1.79 MiB / 20.78 MiB today 496 KiB / 103 KiB / 599 KiB lagg0: yesterday 27.53 MiB / 3.71 MiB / 31.24 MiB today 1.16 MiB / 172 KiB / 1.33 MiB I believe (know) there has been some changes in the LAgg code in stable/9 and stable/8 recently so you may want to check into that. Given this is LAgg and LACP you will see some variation regardless but I re= call a point that it seemed like one interface was being favored over the o= ther quite repeatedly or obsessively that had me second guessing whether it= was doing the right thing. LACP in Cisco is quite different than how we treat it here in FreeBSD as it= tends to use the interfaces quite evenly all the time so that also has me = second guessing whether the right thing is happening here. ( in PAgP and LA= CP modes ). These tunables (sysctl)'s may also lead you in direction you want to look i= n. net.link.lagg.default_use_flowid: 1 net.link.lagg.failover_rx_all: 0 net.link.lagg.0.use_flowid: 1 -rxcsum & -txcsum for lo0 and ql0 ql1 might be of benefit too though I only= turn them off on lo0. Good luck -- - (2^(N-1)) This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 17:23:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6B9E1065670 for ; Tue, 10 Jul 2012 17:23:26 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by mx1.freebsd.org (Postfix) with ESMTP id 5C9848FC25 for ; Tue, 10 Jul 2012 17:23:26 +0000 (UTC) Received: from mail10-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Jul 2012 17:05:56 +0000 Received: from mail10-va3 (localhost [127.0.0.1]) by mail10-va3-R.bigfish.com (Postfix) with ESMTP id C65F52A031D; Tue, 10 Jul 2012 17:05:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:198.70.193.61; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zz98dI9371Ic89bhc85dh1447I328cMzz1202hzz8275bh8275dh74efjz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail10-va3: domain of qlogic.com designates 198.70.193.61 as permitted sender) client-ip=198.70.193.61; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail10-va3 (localhost.localdomain [127.0.0.1]) by mail10-va3 (MessageSwitch) id 1341939952606608_17899; Tue, 10 Jul 2012 17:05:52 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.245]) by mail10-va3.bigfish.com (Postfix) with ESMTP id 807244E0128; Tue, 10 Jul 2012 17:05:52 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Jul 2012 17:05:49 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Tue, 10 Jul 2012 10:08:07 -0700 From: Adarsh Joshi To: Andrew Boyer Date: Tue, 10 Jul 2012 10:08:05 -0700 Thread-Topic: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance Thread-Index: Ac1em3iDmAWR/fFfTBmYMQ9wIwfjmAAINpAg Message-ID: <5E4F49720D0BAD499EE1F01232234BA877435B2F2E@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> <4C5FC147-2F49-4AE0-ADF3-C5381DE6580F@averesystems.com> In-Reply-To: <4C5FC147-2F49-4AE0-ADF3-C5381DE6580F@averesystems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: RE: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 17:23:26 -0000 Andrew, Thanks for the reply. The reason for my suspicion on the portflags is thus (extracted from the if= config output in my previous mail): System 1: Laggport: ql1 flags =3D 18 state =3D 7D Laggport: ql0 flags =3D 1c state =3D 3D System 2: Laggport: ql1 flags =3D 1c state =3D 7D Laggport: ql0 flags =3D 18 state =3D 3D I should have explained my setup to you before. Here it is. Both the ql0 interfaces of the 2 systems are connected using a single cable= and ql1 interfaces of the 2 systems are connected using a single cable. System 1 System 2 ql0 <=3D=3D=3D=3D=3D=3D=3D> ql0 ql1 <=3D=3D=3D=3D=3D=3D=3D> ql1 With this setup, I don't think it is possible for ports ql0 to talk to thei= r partners (each other) and ql1 ports not getting a response from their par= tner and still get the lagg configuration I have posted. I thought the portflags are dependent on the LACP state. But I see differen= t flags for the same LACP state (For the state 7D, ql1 on system 1 shows fl= ags =3D 18 and ql1 on system 2 shows flags =3D 1c). Or is my understanding totally wrong? I will send the LACP_DEBUG logs within the hour. Thanks Adarsh From: Andrew Boyer [mailto:aboyer@averesystems.com] Sent: Tuesday, July 10, 2012 5:57 AM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance On Jul 9, 2012, at 8:38 PM, Adarsh Joshi wrote: Hi, I am trying to configure lacp lagg interfaces with 2 systems connected back= to back as follows: Ifconfig lagg0 create Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netma= sk 255.255.255.0 Sometimes, the lag interface comes up correctly but sometimes the laggport = flags do not show properly. Instead of 1c, = it shows values of 18. I have seen similar issues reported on various forum= s with no solution. Looking at the lagg driver code and reading the standard, I thought the lag= gport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in fil= e ieee8023ad_lacp.h. But the following ifconfig -v output does not make any= sense to me. My concern is that when all the interfaces show flags as 1c, the traffic is= distributed across both the interfaces uniformly and I get aggregated thro= ughput. If not, the traffic flows only on 1 interface. Is this a bug? How do I solve this? Or am I doing something wrong? I am using Free-BSD 9.0 release. System 1: # ifconfig -v lagg0 lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] laggport: ql1 flags=3D18 state=3D7D [(8000,00-0E-1E-08-05-20,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D1c state=3D3D [(8000,00-0E-1E-08-05-20,0213,8000,000E), (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] System 2: # ifconfig -v lagg0 lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: ql1 flags=3D1c state=3D7D [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D18 state=3D3D [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), (8000,00-0E-1E-08-05-20,0213,8000,000E)] thanks Adarsh I don't think you have a port flags problem per se; the flags are correctly= displaying the state of the lagg. Your problem is that your systems aren'= t negotiating the correct lagg configuration. Each tuple after the laggpor= t represents the [(actor state),(partner state)]. Ports ql0 have been able= to talk to their partners (each other). Neither ql1 port has seen a respo= nse from a partner, though. You could try restarting the state machine on one box with 'ifconfig lagg0 = laggproto lacp'. To see the negotiation you'll need to rebuild your kernel= with '#define LACP_DEBUG 1' added to the top of sys/net/ieee802.3ad_lacp.c= . Or upgrade to a newer stable snapshot that has the net.lacp_debug sysctl= and turn it on. Or just turn off LACP. What does it get you in this configuration? Hope this helps, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 18:53:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A74C106566B for ; Tue, 10 Jul 2012 18:53:42 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by mx1.freebsd.org (Postfix) with ESMTP id B2BB78FC14 for ; Tue, 10 Jul 2012 18:53:41 +0000 (UTC) Received: from mail15-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 10 Jul 2012 17:50:48 +0000 Received: from mail15-am1 (localhost [127.0.0.1]) by mail15-am1-R.bigfish.com (Postfix) with ESMTP id C4BEDC02A9; Tue, 10 Jul 2012 17:50:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:198.70.193.61; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub1.qlogic.com; EFVD:NLI X-SpamScore: -17 X-BigFish: VPS-17(zz98dI9371I936eI542M1453M1447I328cMzz1202hzz8275bh8275dh74efjz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail15-am1: domain of qlogic.com designates 198.70.193.61 as permitted sender) client-ip=198.70.193.61; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail15-am1 (localhost.localdomain [127.0.0.1]) by mail15-am1 (MessageSwitch) id 1341942646270170_7499; Tue, 10 Jul 2012 17:50:46 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.237]) by mail15-am1.bigfish.com (Postfix) with ESMTP id 3FF5C2C004E; Tue, 10 Jul 2012 17:50:46 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.61) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 10 Jul 2012 17:50:44 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub1.qlogic.org ([::1]) with mapi; Tue, 10 Jul 2012 10:53:03 -0700 From: Adarsh Joshi To: Andrew Boyer Date: Tue, 10 Jul 2012 10:53:00 -0700 Thread-Topic: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance Thread-Index: Ac1em3iDmAWR/fFfTBmYMQ9wIwfjmAAINpAgAAHAncA= Message-ID: <5E4F49720D0BAD499EE1F01232234BA877435B2F66@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> <4C5FC147-2F49-4AE0-ADF3-C5381DE6580F@averesystems.com> <5E4F49720D0BAD499EE1F01232234BA877435B2F2E@AVEXMB1.qlogic.org> In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA877435B2F2E@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Cc: "freebsd-net@freebsd.org" Subject: RE: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:53:42 -0000 Andrew, Here are the logs with LACP_DEBUG defined in ieee802.3ad_lacp.c, after typing Ifconfig lagg0 create ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netma= sk 255.255.255.0 I compiled it as a standalone driver by the way. System 1: # ifconfig -v lagg0 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D13b ether 00:0e:1e:08:05:20 inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-08-05-20,01D3,0000,0000), (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] laggport: ql1 flags=3D18 state=3D7D [(8000,00-0E-1E-08-05-20,01D3,8000,000D), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D1c state=3D3D [(8000,00-0E-1E-08-05-20,01D3,8000,000C), (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] System 2: # ifconfig -v lagg0 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D13b ether 00:0e:1e:04:2c:f0 inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: ql1 flags=3D1c state=3D7D [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D18 state=3D3D [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), (8000,00-0E-1E-08-05-20,01D3,8000,000C)] System 1 logs : Jul 10 10:38:49 bsd-14 kernel: lacp_attach[738] : lacp attached Jul 10 10:38:49 bsd-14 kernel: lacp_attach[740] : lacp_defined Jul 10 10:38:49 bsd-14 kernel: lagg0: link state changed to UP Jul 10 10:38:49 bsd-14 kernel: ql0: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 Jul 10 10:38:49 bsd-14 kernel: ql0: -> UNSELECTED Jul 10 10:38:49 bsd-14 kernel: ql1: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 Jul 10 10:38:49 bsd-14 kernel: ql1: -> UNSELECTED Jul 10 10:38:49 bsd-14 kernel: lacp_select_tx_port: no active aggregator Jul 10 10:38:50 bsd-14 kernel: ql1: port lagid=3D[(8000,00-0E-1E-08-05-20,0= 1D3,8000,000D),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator created Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-08-0= 5-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql1: mux_state 0 -> 1 Jul 10 10:38:50 bsd-14 kernel: ql0: port lagid=3D[(8000,00-0E-1E-08-05-20,0= 1D3,8000,000C),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator created Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-08-0= 5-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql0: mux_state 0 -> 1 Jul 10 10:38:51 bsd-14 kernel: ql1: lacpdu transmit Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0D) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D85 Jul 10 10:38:51 bsd-14 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu transmit Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0C) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D85 Jul 10 10:38:51 bsd-14 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 Jul 10 10:38:51 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D85 Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:51 bsd-14 kernel: ql0: old pstate 2 Jul 10 10:38:51 bsd-14 kernel: ql0: new pstate 5 Jul 10 10:38:51 bsd-14 kernel: ql0: partner timeout changed Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 Jul 10 10:38:51 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D85 Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:52 bsd-14 kernel: ql1: lacp_sm_rx_timer: EXPIRED -> DEFAULTED Jul 10 10:38:52 bsd-14 kernel: ql1: partner timeout changed Jul 10 10:38:52 bsd-14 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], p= ending 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql1: collecting disabled Jul 10 10:38:52 bsd-14 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-0E= -1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], refc= nt 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql1: mux_state 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql1: lacpdu transmit Jul 10 10:38:52 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0D) Jul 10 10:38:52 bsd-14 kernel: actor.state=3D45 Jul 10 10:38:52 bsd-14 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 10:38:52 bsd-14 kernel: partner.state=3D3c Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:52 bsd-14 kernel: ql0: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], p= ending 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql0: collecting disabled Jul 10 10:38:52 bsd-14 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-0E= -1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], refc= nt 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql0: mux_state 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql0: lacpdu transmit Jul 10 10:38:52 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0C) Jul 10 10:38:52 bsd-14 kernel: actor.state=3D5 Jul 10 10:38:52 bsd-14 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 10:38:52 bsd-14 kernel: partner.state=3D5 Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:53 bsd-14 kernel: ql1: port lagid=3D[(8000,00-0E-1E-08-05-20,0= 1D3,8000,000D),(FFFF,00-00-00-00-00-00,0000,FFFF,0000)] Jul 10 10:38:53 bsd-14 kernel: ql1: aggregator created Jul 10 10:38:53 bsd-14 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-08-0= 5-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:53 bsd-14 kernel: ql1: mux_state 0 -> 1 Jul 10 10:38:53 bsd-14 kernel: ql0: port lagid=3D[(8000,00-0E-1E-08-05-20,0= 1D3,8000,000C),(8000,00-0E-1E-04-2C-F0,0213,8000,000E)] Jul 10 10:38:53 bsd-14 kernel: ql0: aggregator created Jul 10 10:38:53 bsd-14 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-08-0= 5-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000,0000)] Jul 10 10:38:53 bsd-14 kernel: ql0: mux_state 0 -> 1 Jul 10 10:38:54 bsd-14 kernel: ql0: lacpdu receive Jul 10 10:38:54 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 10:38:54 bsd-14 kernel: actor.state=3Dd Jul 10 10:38:54 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:54 bsd-14 kernel: partner.state=3D5 Jul 10 10:38:54 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:54 bsd-14 kernel: ql0: old pstate 5 Jul 10 10:38:54 bsd-14 kernel: ql0: new pstate d Jul 10 10:38:55 bsd-14 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)], p= ending 1 -> 0 Jul 10 10:38:55 bsd-14 kernel: ql1: collecting disabled Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 1 -> 2 Jul 10 10:38:55 bsd-14 kernel: ql1: collecting enabled Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 2 -> 3 Jul 10 10:38:55 bsd-14 kernel: ql1: enable distributing on aggregator [(800= 0,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)= ], nports 0 -> 1 Jul 10 10:38:55 bsd-14 kernel: lacp_select_active_aggregator: Jul 10 10:38:55 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FF= FF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 10:38:55 bsd-14 kernel: active aggregator changed Jul 10 10:38:55 bsd-14 kernel: old (none) Jul 10 10:38:55 bsd-14 kernel: new [(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:55 bsd-14 kernel: Set table 1 with 1 ports Jul 10 10:38:55 bsd-14 kernel: lacp_suppress_distributing Jul 10 10:38:55 bsd-14 kernel: ql1: marker transmit, port=3D13, sys=3D00:0e= :1e:08:05:20, id=3D1 Jul 10 10:38:55 bsd-14 kernel: ql0: marker transmit, port=3D12, sys=3D00:0e= :1e:08:05:20, id=3D1 Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 3 -> 4 Jul 10 10:38:55 bsd-14 kernel: ql1: lacpdu transmit Jul 10 10:38:55 bsd-14 kernel: ql0: marker response, port=3D12, sys=3D00:0e= :1e:08:05:20, id=3D1 Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0D) Jul 10 10:38:55 bsd-14 kernel: actor.state=3D7d Jul 10 10:38:55 bsd-14 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 10:38:55 bsd-14 kernel: partner.state=3D3c Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:55 bsd-14 kernel: ql0: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000,0000)], p= ending 1 -> 0 Jul 10 10:38:55 bsd-14 kernel: ql0: collecting disabled Jul 10 10:38:55 bsd-14 kernel: ql0: mux_state 1 -> 2 Jul 10 10:38:55 bsd-14 kernel: ql0: collecting enabled Jul 10 10:38:55 bsd-14 kernel: ql0: mux_state 2 -> 3 Jul 10 10:38:55 bsd-14 kernel: ql0: lacpdu transmit Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0C) Jul 10 10:38:55 bsd-14 kernel: actor.state=3D1d Jul 10 10:38:55 bsd-14 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 10:38:55 bsd-14 kernel: partner.state=3Dd Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:55 bsd-14 kernel: ql0: lacpdu receive Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 10:38:55 bsd-14 kernel: actor.state=3D3d Jul 10 10:38:55 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:55 bsd-14 kernel: partner.state=3D1d Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:55 bsd-14 kernel: ql0: old pstate d Jul 10 10:38:55 bsd-14 kernel: ql0: new pstate 3d Jul 10 10:38:56 bsd-14 kernel: ql0: enable distributing on aggregator [(800= 0,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ], nports 0 -> 1 Jul 10 10:38:56 bsd-14 kernel: lacp_select_active_aggregator: Jul 10 10:38:56 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FF= FF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 10:38:56 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(80= 00,00-0E-1E-04-2C-F0,0213,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 10:38:56 bsd-14 kernel: active aggregator changed Jul 10 10:38:56 bsd-14 kernel: old [(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:56 bsd-14 kernel: new [(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(8000,00-0E-1E-04-2C-F0,0213,0000,0000)] Jul 10 10:38:56 bsd-14 kernel: Set table 0 with 1 ports Jul 10 10:38:56 bsd-14 kernel: lacp_suppress_distributing Jul 10 10:38:56 bsd-14 kernel: ql1: marker transmit, port=3D13, sys=3D00:0e= :1e:08:05:20, id=3D2 Jul 10 10:38:56 bsd-14 kernel: ql0: marker transmit, port=3D12, sys=3D00:0e= :1e:08:05:20, id=3D2 Jul 10 10:38:56 bsd-14 kernel: ql0: mux_state 3 -> 4 Jul 10 10:38:56 bsd-14 kernel: ql0: marker response, port=3D12, sys=3D00:0e= :1e:08:05:20, id=3D2 Jul 10 10:38:59 bsd-14 kernel: lacp_transit_expire ^C System 2 logs : Jul 10 02:38:24 bsd-15 kernel: lacp_attach[738] : lacp attached Jul 10 02:38:24 bsd-15 kernel: lacp_attach[740] : lacp_defined Jul 10 02:38:24 bsd-15 kernel: lagg0: link state changed to UP Jul 10 02:38:24 bsd-15 kernel: ql0: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 Jul 10 02:38:24 bsd-15 kernel: ql0: -> UNSELECTED Jul 10 02:38:24 bsd-15 kernel: ql1: media changed 0x0 -> 0x100033, ether = =3D 1, fdx =3D 1, link =3D 1 Jul 10 02:38:24 bsd-15 kernel: ql1: -> UNSELECTED Jul 10 02:38:24 bsd-15 kernel: lacp_select_tx_port: no active aggregator Jul 10 02:38:25 bsd-15 kernel: ql1: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0= 213,8000,000F),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql1: aggregator created Jul 10 02:38:25 bsd-15 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-04-2= C-F0,0213,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql1: mux_state 0 -> 1 Jul 10 02:38:25 bsd-15 kernel: ql0: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0= 213,8000,000E),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql0: aggregator created Jul 10 02:38:25 bsd-15 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-04-2= C-F0,0213,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql0: mux_state 0 -> 1 Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu receive Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0C) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D85 Jul 10 02:38:26 bsd-15 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:26 bsd-15 kernel: ql0: lacp_sm_rx_update_ntt: assert ntt Jul 10 02:38:26 bsd-15 kernel: ql0: old pstate 2 Jul 10 02:38:26 bsd-15 kernel: ql0: new pstate 85 Jul 10 02:38:26 bsd-15 kernel: ql0: partner timeout changed Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu transmit Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 Jul 10 02:38:26 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D85 Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:26 bsd-15 kernel: ql1: lacpdu transmit Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0F) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D85 Jul 10 02:38:26 bsd-15 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:26 bsd-15 kernel: ql0: collecting disabled Jul 10 02:38:26 bsd-15 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-0E= -1E-04-2C-F0,0213, 0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], ref= cnt 1 -> 0 Jul 10 02:38:26 bsd-15 kernel: ql0: mux_state 1 -> 0 Jul 10 02:38:26 bsd-15 kernel: ql0: lacpdu transmit Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 Jul 10 02:38:26 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D85 Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:27 bsd-15 kernel: ql0: lacpdu receive Jul 10 02:38:27 bsd-15 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0C) Jul 10 02:38:27 bsd-15 kernel: actor.state=3D5 Jul 10 02:38:27 bsd-15 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 02:38:27 bsd-15 kernel: partner.state=3D5 Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:27 bsd-15 kernel: ql0: old pstate 85 Jul 10 02:38:27 bsd-15 kernel: ql0: new pstate 5 Jul 10 02:38:27 bsd-15 kernel: ql1: lacp_sm_rx_timer: EXPIRED -> DEFAULTED Jul 10 02:38:27 bsd-15 kernel: ql1: partner timeout changed Jul 10 02:38:27 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-04-2C-F0, 0213,0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], = pending 1 -> 0 Jul 10 02:38:27 bsd-15 kernel: ql1: collecting disabled Jul 10 02:38:27 bsd-15 kernel: lacp_aggregator_delref: lagid=3D[(8000,00-0E= -1E-04-2C-F0,0213, 0000,0000),(0000,00-00-00-00-00-00,0000,0000,0000)], ref= cnt 1 -> 0 Jul 10 02:38:27 bsd-15 kernel: ql1: mux_state 1 -> 0 Jul 10 02:38:27 bsd-15 kernel: ql1: lacpdu transmit Jul 10 02:38:27 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0F) Jul 10 02:38:27 bsd-15 kernel: actor.state=3D45 Jul 10 02:38:27 bsd-15 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 02:38:27 bsd-15 kernel: partner.state=3D3c Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:27 bsd-15 kernel: ql0: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0= 213,8000,000E),(8000,00-0E-1E-08-05-20,01D3,8000,000C)] Jul 10 02:38:27 bsd-15 kernel: ql0: aggregator created Jul 10 02:38:27 bsd-15 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-04-2= C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,0000)] Jul 10 02:38:27 bsd-15 kernel: ql0: mux_state 0 -> 1 Jul 10 02:38:28 bsd-15 kernel: ql1: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0= 213,8000,000F),(FFFF,00-00-00-00-00-00,0000,FFFF,0000)] Jul 10 02:38:28 bsd-15 kernel: ql1: aggregator created Jul 10 02:38:28 bsd-15 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-04-2= C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:28 bsd-15 kernel: ql1: mux_state 0 -> 1 Jul 10 02:38:29 bsd-15 kernel: ql0: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-04-2C-F0, 0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,0000)], = pending 1 -> 0 Jul 10 02:38:29 bsd-15 kernel: ql0: collecting disabled Jul 10 02:38:29 bsd-15 kernel: ql0: mux_state 1 -> 2 Jul 10 02:38:29 bsd-15 kernel: ql0: lacpdu transmit Jul 10 02:38:29 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 02:38:29 bsd-15 kernel: actor.state=3Dd Jul 10 02:38:29 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:29 bsd-15 kernel: partner.state=3D5 Jul 10 02:38:29 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:30 bsd-15 kernel: ql0: lacpdu receive Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,00= 0C) Jul 10 02:38:30 bsd-15 kernel: actor.state=3D1d Jul 10 02:38:30 bsd-15 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 02:38:30 bsd-15 kernel: partner.state=3Dd Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:30 bsd-15 kernel: ql0: old pstate 5 Jul 10 02:38:30 bsd-15 kernel: ql0: new pstate 1d Jul 10 02:38:30 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-04-2C-F0, 0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)], = pending 1 -> 0 Jul 10 02:38:30 bsd-15 kernel: ql1: collecting disabled Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 1 -> 2 Jul 10 02:38:30 bsd-15 kernel: ql1: collecting enabled Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 2 -> 3 Jul 10 02:38:30 bsd-15 kernel: ql1: enable distributing on aggregator [(800= 0,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)= ], nports 0 -> 1 Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FF= FF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 02:38:30 bsd-15 kernel: active aggregator changed Jul 10 02:38:30 bsd-15 kernel: old (none) Jul 10 02:38:30 bsd-15 kernel: new [(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ,(FFFF,00-00-00 00-00-00,0000,0000,0000)] Jul 10 02:38:30 bsd-15 kernel: Set table 1 with 1 ports Jul 10 02:38:30 bsd-15 kernel: lacp_suppress_distributing Jul 10 02:38:30 bsd-15 kernel: ql1: marker transmit, port=3D15, sys=3D00:0e= :1e:04:2c:f0, id=3D1 Jul 10 02:38:30 bsd-15 kernel: ql0: marker transmit, port=3D14, sys=3D00:0e= :1e:04:2c:f0, id=3D1 Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state 3 -> 4 Jul 10 02:38:30 bsd-15 kernel: ql1: lacpdu transmit Jul 10 02:38:30 bsd-15 kernel: ql0: marker response, port=3D14, sys=3D00:0e= :1e:04:2c:f0, id=3D1 Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0F) Jul 10 02:38:30 bsd-15 kernel: actor.state=3D7d Jul 10 02:38:30 bsd-15 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 02:38:30 bsd-15 kernel: partner.state=3D3c Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:30 bsd-15 kernel: ql0: collecting enabled Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 2 -> 3 Jul 10 02:38:30 bsd-15 kernel: ql0: enable distributing on aggregator [(800= 0,00-0E-1E-04-2C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ], nports 0 -> 1 Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggregator: Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(80= 00,00-0E-1E-08-05-20,01D3,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FF= FF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 02:38:30 bsd-15 kernel: active aggregator not changed Jul 10 02:38:30 bsd-15 kernel: new [(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ,(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 3 -> 4 Jul 10 02:38:30 bsd-15 kernel: ql0: lacpdu transmit Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,00= 0E) Jul 10 02:38:30 bsd-15 kernel: actor.state=3D3d Jul 10 02:38:30 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:30 bsd-15 kernel: partner.state=3D1d Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:33 bsd-15 kernel: lacp_transit_expire ^C Let me know if you need more info. Thanks Adarsh -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Adarsh Joshi Sent: Tuesday, July 10, 2012 10:08 AM To: Andrew Boyer Cc: freebsd-net@freebsd.org Subject: RE: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance Andrew, Thanks for the reply. The reason for my suspicion on the portflags is thus (extracted from the if= config output in my previous mail): System 1: Laggport: ql1 flags =3D 18 state =3D 7D Laggport: ql0 flags =3D 1c state =3D 3D System 2: Laggport: ql1 flags =3D 1c state =3D 7D Laggport: ql0 flags =3D 18 state =3D 3D I should have explained my setup to you before. Here it is. Both the ql0 interfaces of the 2 systems are connected using a single cable= and ql1 interfaces of the 2 systems are connected using a single cable. System 1 System 2 ql0 <=3D=3D=3D=3D=3D=3D=3D> ql0 ql1 <=3D=3D=3D=3D=3D=3D=3D> ql1 With this setup, I don't think it is possible for ports ql0 to talk to thei= r partners (each other) and ql1 ports not getting a response from their par= tner and still get the lagg configuration I have posted. I thought the portflags are dependent on the LACP state. But I see differen= t flags for the same LACP state (For the state 7D, ql1 on system 1 shows fl= ags =3D 18 and ql1 on system 2 shows flags =3D 1c). Or is my understanding totally wrong? I will send the LACP_DEBUG logs within the hour. Thanks Adarsh From: Andrew Boyer [mailto:aboyer@averesystems.com] Sent: Tuesday, July 10, 2012 5:57 AM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance On Jul 9, 2012, at 8:38 PM, Adarsh Joshi wrote: Hi, I am trying to configure lacp lagg interfaces with 2 systems connected back= to back as follows: Ifconfig lagg0 create Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netma= sk 255.255.255.0 Sometimes, the lag interface comes up correctly but sometimes the laggport = flags do not show properly. Instead of 1c, = it shows values of 18. I have seen similar issues reported on various forum= s with no solution. Looking at the lagg driver code and reading the standard, I thought the lag= gport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in fil= e ieee8023ad_lacp.h. But the following ifconfig -v output does not make any= sense to me. My concern is that when all the interfaces show flags as 1c, the traffic is= distributed across both the interfaces uniformly and I get aggregated thro= ughput. If not, the traffic flows only on 1 interface. Is this a bug? How do I solve this? Or am I doing something wrong? I am using Free-BSD 9.0 release. System 1: # ifconfig -v lagg0 lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] laggport: ql1 flags=3D18 state=3D7D [(8000,00-0E-1E-08-05-20,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D1c state=3D3D [(8000,00-0E-1E-08-05-20,0213,8000,000E), (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] System 2: # ifconfig -v lagg0 lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: ql1 flags=3D1c state=3D7D [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D18 state=3D3D [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), (8000,00-0E-1E-08-05-20,0213,8000,000E)] thanks Adarsh I don't think you have a port flags problem per se; the flags are correctly= displaying the state of the lagg. Your problem is that your systems aren'= t negotiating the correct lagg configuration. Each tuple after the laggpor= t represents the [(actor state),(partner state)]. Ports ql0 have been able= to talk to their partners (each other). Neither ql1 port has seen a respo= nse from a partner, though. You could try restarting the state machine on one box with 'ifconfig lagg0 = laggproto lacp'. To see the negotiation you'll need to rebuild your kernel= with '#define LACP_DEBUG 1' added to the top of sys/net/ieee802.3ad_lacp.c= . Or upgrade to a newer stable snapshot that has the net.lacp_debug sysctl= and turn it on. Or just turn off LACP. What does it get you in this configuration? Hope this helps, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Tue Jul 10 19:16:37 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23E1E106564A for ; Tue, 10 Jul 2012 19:16:37 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id EE7BF8FC08 for ; Tue, 10 Jul 2012 19:16:36 +0000 (UTC) Received: from [209.249.190.124] (port=54692 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SofvI-00039D-Jz for net@freebsd.org; Tue, 10 Jul 2012 15:16:36 -0400 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jul 2012 15:16:36 -0400 Message-Id: To: net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1280) X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Subject: Anyone working on RFC 4821, TCP Packetization Layer Path MTU Discovery? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 19:16:37 -0000 Howdy, I just got an off list question about this RFC and haven't had time to = dive into it, but wondered if anyone had already looked at this in the context of our = TCP stack. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 02:27:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A54831065678 for ; Wed, 11 Jul 2012 02:27:05 +0000 (UTC) (envelope-from chris.benesch@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5E82E8FC0C for ; Wed, 11 Jul 2012 02:27:05 +0000 (UTC) Received: by ghbz22 with SMTP id z22so820860ghb.13 for ; Tue, 10 Jul 2012 19:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wtJrg9zi7+Hccn3mTg/nrjQKTFopRpFsGDHzxj5Ptfg=; b=B/KtNiw7rvLN2ftBvsqnwJ2PWsbkwf57RX2wIj5hHqEgUMGJbLjc7gU+WuOnTmAFb4 zQTsmwCfum69oIO2jKBzxAxXSZn0X2KYcSp7gckNTBJnKutV+kt5qrNjl4H4xDhzXGVU yfYPcQE8SvU8FQX1UH4hnYwsFgfdG38BS7v2Dv9C0wmITL/1c9wUR8tV313tjShoFl3y fsXXlb2eUiqpyWddN7BlopkRtMC5W1Sh9mNnbXY/5wBCNzUxgbZWWftuVt28q6mvY5c3 EP7IEntire/XRS2yVMkdbNTZtlLBDe7UpJO2wwfLUCur1DWIC229GYwL8q/oAEjN3tx0 Q+fQ== MIME-Version: 1.0 Received: by 10.50.187.228 with SMTP id fv4mr13258710igc.10.1341973624391; Tue, 10 Jul 2012 19:27:04 -0700 (PDT) Received: by 10.231.26.150 with HTTP; Tue, 10 Jul 2012 19:27:04 -0700 (PDT) Date: Tue, 10 Jul 2012 19:27:04 -0700 Message-ID: From: Chris Benesch To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: GIF tunnel doesnt like fragmented packets? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 02:27:05 -0000 So I'm trying to set up a tunnel with Hurricane Electric. Works great on OpenBSD BTW, took only a minute or two. So heres rc.conf ipv6_gateway_enable="YES" gif_interfaces="gif0" gifconfig_gif0="198.168.0.2 64.62.134.130" ipv6_network_interfaces="rl0 em0 gif0 lo0" ifconfig_gif0_ipv6="inet6 2001:470:66:3a3::2 2001:470:66:3a3::1 prefixlen 128" ipv6_defaultrouter="2001:470:66:3a3::1" And I am running pf on the box. # macros ext_if="rl0" int_if="em0" if_6="gif0" tcp_services="{ 22,25,80 }" udp_services="{ 500 }" icmp_types="echoreq" workstation="192.168.231.15" # options set optimization normal set block-policy return set skip on { lo gif0 } # scrub scrub in no-df # nat/rdr nat on $ext_if inet from !($ext_if) -> ($ext_if:0) # filter rules block in log on rl0 pass out quick flags S/SA keep state pass in quick on $int_if flags S/SA keep state allow-opts pass in quick from 192.168.231.1 to 192.168.231.1 pass in log from 64.62.134.130 to any antispoof quick for { lo } pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services pass in on $if_6 inet6 proto tcp from any to ($if_6) port $tcp_services pass in on $ext_if inet proto udp from any to ($ext_if) port $udp_services pass in on $if_6 inet6 proto udp from any to ($if_6) port $udp_services pass in inet6 proto icmp6 from any to any pass in inet proto icmp from any to any Ok, so now thats out of the way. Basically I see packets going out, but none coming back, and they clearly are coming back on the internet facing interface. I've ran a dump on pflog and nothing its not dropping it. Here is a dump for a couple pings from the outside interface: 18:53:09.462410 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 30, id 35752, offset 0, flags [none], proto IPv6 (41), length 76) 192.168.0.2 > 64.62.134.130: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, echo request, length 16, seq 0 18:53:09.507572 00:24:7b:c8:f1:70 > 00:11:09:01:c8:26, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 248, id 0, offset 0, flags [DF], proto IPv6 (41), length 76) 64.62.134.130 > 192.168.0.2: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 0 18:53:09.507598 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 247, id 0, offset 0, flags [none], proto IPv6 (41), length 76) 192.168.0.2 > 198.168.0.2: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 0 18:53:10.462714 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 30, id 35756, offset 0, flags [none], proto IPv6 (41), length 76) 192.168.0.2 > 64.62.134.130: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, echo request, length 16, seq 1 18:53:10.509347 00:24:7b:c8:f1:70 > 00:11:09:01:c8:26, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 248, id 0, offset 0, flags [DF], proto IPv6 (41), length 76) 64.62.134.130 > 192.168.0.2: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 1 18:53:10.509366 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 (0x0800), length 90: (tos 0x0, ttl 247, id 0, offset 0, flags [none], proto IPv6 (41), length 76) 192.168.0.2 > 198.168.0.2: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 1 You get the picture there is back and forth And here is gif0 [root@maricopacomputer ~]# tcpdump -lenvvvvi gif0 tcpdump: WARNING: gif0: no IPv4 address assigned tcpdump: listening on gif0, link-type NULL (BSD loopback), capture size 65535 bytes 18:52:34.975121 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, echo request, length 16, seq 0 18:52:35.975701 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, echo request, length 16, seq 1 18:52:36.975684 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, echo request, length 16, seq 2 18:52:37.975689 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, echo request, length 16, seq 3 18:52:39.974653 AF IPv6 (28), length 68: (hlim 255, next-header ICMPv6 (58) payload length: 24) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2001:470:66:3a3::1 18:52:40.974653 AF IPv6 (28), length 68: (hlim 255, next-header ICMPv6 (58) payload length: 24) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2001:470:66:3a3::1 18:52:41.974652 AF IPv6 (28), length 68: (hlim 255, next-header ICMPv6 (58) payload length: 24) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2001:470:66:3a3::1 The only thing I notice is that the ones coming from HE have the DF flag set? Am I on the wrong path? Have no idea how to get this to work. From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 07:14:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32E3C106564A for ; Wed, 11 Jul 2012 07:14:06 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA6A28FC0A for ; Wed, 11 Jul 2012 07:14:05 +0000 (UTC) Received: by qcsg15 with SMTP id g15so636248qcs.13 for ; Wed, 11 Jul 2012 00:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=n7vwEiC474eTFWM9fAP2UhXDxa+Y7OOq7Pxp4inDHpU=; b=hbbnjibgQGlMwJiVD8cjQb1/RdZ6FvnqnUAYCEG8yxIZUeLVuw76hi700K1x4e7OD2 I7BuZhjTtIRYyVmMo1apLjGks57bjVwiF2yfuEB+3neeO6aF9d8+Nu43FENg/H5jrSpf Tl7pxkAbyJ/Nw0RXLn7v68DjaCFGwi+Og1yrY9+vDoRYyDL4U6JPcuXPLIKVLW66fmRB WQuhxM0pZlrkw/TmP+PYNzEvG6J5iSNUglECxzFmfXqkhgQOivIgt80Sn14afqnoloXV yNzbWWcm3/WLn0ajYgP+hqc8tGsKzhHJKnjx256Fs/bJgq3KBBOl3XGdbwSneavqx4Mz MqWw== MIME-Version: 1.0 Received: by 10.229.137.11 with SMTP id u11mr25177644qct.53.1341990845069; Wed, 11 Jul 2012 00:14:05 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.229.222.194 with HTTP; Wed, 11 Jul 2012 00:14:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jul 2012 09:14:05 +0200 X-Google-Sender-Auth: FTwwQr_GtMKms7EAGq_bSxOake4 Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Chris Benesch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: GIF tunnel doesnt like fragmented packets? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 07:14:06 -0000 On Wed, Jul 11, 2012 at 4:27 AM, Chris Benesch wr= ote: > So I'm trying to set up a tunnel with Hurricane Electric. =A0Works great = on > OpenBSD BTW, took only a minute or two. > There is no support for fragmented ipv6 packets in pf(4) for FreeBSD. > So heres rc.conf > > ipv6_gateway_enable=3D"YES" > gif_interfaces=3D"gif0" > gifconfig_gif0=3D"198.168.0.2 64.62.134.130" > ipv6_network_interfaces=3D"rl0 em0 gif0 lo0" > ifconfig_gif0_ipv6=3D"inet6 2001:470:66:3a3::2 2001:470:66:3a3::1 prefixl= en > 128" > ipv6_defaultrouter=3D"2001:470:66:3a3::1" > > And I am running pf on the box. > > # macros > ext_if=3D"rl0" > int_if=3D"em0" > if_6=3D"gif0" > > tcp_services=3D"{ 22,25,80 }" > udp_services=3D"{ 500 }" > icmp_types=3D"echoreq" > > workstation=3D"192.168.231.15" > > # options > set optimization normal > set block-policy return > set skip on { lo gif0 } > > # scrub > scrub in no-df > > # nat/rdr > nat on $ext_if inet from !($ext_if) -> ($ext_if:0) > > > # filter rules > block in log on rl0 > pass out quick flags S/SA keep state > pass in quick on $int_if flags S/SA keep state allow-opts > pass in quick from 192.168.231.1 to 192.168.231.1 > pass in log from 64.62.134.130 to any > > antispoof quick for { lo } > > pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_service= s > pass in on $if_6 inet6 proto tcp from any to ($if_6) port $tcp_services > pass in on $ext_if inet proto udp from any to ($ext_if) port $udp_service= s > pass in on $if_6 inet6 proto udp from any to ($if_6) port $udp_services > > pass in inet6 proto icmp6 from any to any > pass in inet proto icmp from any to any > > Ok, so now thats out of the way. > > Basically I see packets going out, but none coming back, and they clearly > are coming back on the internet facing interface. =A0I've ran a dump on p= flog > and nothing its not dropping it. > > Here is a dump for a couple pings from the outside interface: > > 18:53:09.462410 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 > (0x0800), length 90: (tos 0x0, ttl 30, id 35752, offset 0, flags [none], > proto IPv6 (41), length 76) > =A0 =A0 192.168.0.2 > 64.62.134.130: (hlim 64, next-header ICMPv6 (58) pa= yload > length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6= , > echo request, length 16, seq 0 > 18:53:09.507572 00:24:7b:c8:f1:70 > 00:11:09:01:c8:26, ethertype IPv4 > (0x0800), length 90: (tos 0x0, ttl 248, id 0, offset 0, flags [DF], proto > IPv6 (41), length 76) > =A0 =A0 64.62.134.130 > 192.168.0.2: (hlim 64, next-header ICMPv6 (58) pa= yload > length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6= , > echo reply, length 16, seq 0 > 18:53:09.507598 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 > (0x0800), length 90: (tos 0x0, ttl 247, id 0, offset 0, flags [none], pro= to > IPv6 (41), length 76) > =A0 =A0 192.168.0.2 > 198.168.0.2: (hlim 64, next-header ICMPv6 (58) payl= oad > length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6= , > echo reply, length 16, seq 0 > 18:53:10.462714 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 > (0x0800), length 90: (tos 0x0, ttl 30, id 35756, offset 0, flags [none], > proto IPv6 (41), length 76) > =A0 =A0 192.168.0.2 > 64.62.134.130: (hlim 64, next-header ICMPv6 (58) pa= yload > length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum ok] ICMP6= , > echo request, length 16, seq 1 > 18:53:10.509347 00:24:7b:c8:f1:70 > 00:11:09:01:c8:26, ethertype IPv4 > (0x0800), length 90: (tos 0x0, ttl 248, id 0, offset 0, flags [DF], proto > IPv6 (41), length 76) > =A0 =A0 64.62.134.130 > 192.168.0.2: (hlim 64, next-header ICMPv6 (58) pa= yload > length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6= , > echo reply, length 16, seq 1 > 18:53:10.509366 00:11:09:01:c8:26 > 00:24:7b:c8:f1:70, ethertype IPv4 > (0x0800), length 90: (tos 0x0, ttl 247, id 0, offset 0, flags [none], pro= to > IPv6 (41), length 76) > =A0 =A0 192.168.0.2 > 198.168.0.2: (hlim 64, next-header ICMPv6 (58) payl= oad > length: 16) 2001:470:66:3a3::1 > 2001:470:66:3a3::2: [icmp6 sum ok] ICMP6= , > echo reply, length 16, seq 1 > > You get the picture there is back and forth > > And here is gif0 > > [root@maricopacomputer ~]# tcpdump -lenvvvvi gif0 > tcpdump: WARNING: gif0: no IPv4 address assigned > tcpdump: listening on gif0, link-type NULL (BSD loopback), capture size > 65535 bytes > 18:52:34.975121 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58= ) > payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum o= k] > ICMP6, echo request, length 16, seq 0 > 18:52:35.975701 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58= ) > payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum o= k] > ICMP6, echo request, length 16, seq 1 > 18:52:36.975684 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58= ) > payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum o= k] > ICMP6, echo request, length 16, seq 2 > 18:52:37.975689 AF IPv6 (28), length 60: (hlim 64, next-header ICMPv6 (58= ) > payload length: 16) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum o= k] > ICMP6, echo request, length 16, seq 3 > 18:52:39.974653 AF IPv6 (28), length 68: (hlim 255, next-header ICMPv6 (5= 8) > payload length: 24) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum o= k] > ICMP6, neighbor solicitation, length 24, who has 2001:470:66:3a3::1 > 18:52:40.974653 AF IPv6 (28), length 68: (hlim 255, next-header ICMPv6 (5= 8) > payload length: 24) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum o= k] > ICMP6, neighbor solicitation, length 24, who has 2001:470:66:3a3::1 > 18:52:41.974652 AF IPv6 (28), length 68: (hlim 255, next-header ICMPv6 (5= 8) > payload length: 24) 2001:470:66:3a3::2 > 2001:470:66:3a3::1: [icmp6 sum o= k] > ICMP6, neighbor solicitation, length 24, who has 2001:470:66:3a3::1 > > The only thing I notice is that the ones coming from HE have the DF flag > set? =A0Am I on the wrong path? =A0Have no idea how to get this to work. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 09:49:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3171106566C for ; Wed, 11 Jul 2012 09:49:40 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 8A91F8FC0C for ; Wed, 11 Jul 2012 09:49:40 +0000 (UTC) Received: from c0246.aw.cl.cam.ac.uk (c0246.aw.cl.cam.ac.uk [128.232.100.246]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPSA id AC18125D3A0F for ; Wed, 11 Jul 2012 09:49:39 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: "Bjoern A. Zeeb" In-Reply-To: Date: Wed, 11 Jul 2012 09:49:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: FreeBSD Networking Mailing List X-Mailer: Apple Mail (2.1084) Subject: Re: GIF tunnel doesnt like fragmented packets? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 09:49:41 -0000 On 11. Jul 2012, at 07:14 , Ermal Lu=E7i wrote: > On Wed, Jul 11, 2012 at 4:27 AM, Chris Benesch = wrote: >> So I'm trying to set up a tunnel with Hurricane Electric. Works = great on >> OpenBSD BTW, took only a minute or two. >>=20 > There is no support for fragmented ipv6 packets in pf(4) for FreeBSD. It's wrong to say it like that. There is no support for transparent = reassembly and checking in FreeBSD but we can happily filter on IPv6 = fragments and allow or block them. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 11:02:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BC321065687 for ; Wed, 11 Jul 2012 11:02:00 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 169CC8FC1A for ; Wed, 11 Jul 2012 11:01:59 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id q6BB1rMO013469 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 13:01:53 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id q6BB1qce030075; Wed, 11 Jul 2012 13:01:52 +0200 (MEST) Date: Wed, 11 Jul 2012 13:01:52 +0200 From: Daniel Hartmeier To: Chris Benesch Message-ID: <20120711110152.GE9145@insomnia.benzedrine.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12-2006-07-14 Cc: freebsd-net@freebsd.org Subject: Re: GIF tunnel doesnt like fragmented packets? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:02:00 -0000 On Tue, Jul 10, 2012 at 07:27:04PM -0700, Chris Benesch wrote: > The only thing I notice is that the ones coming from HE have the DF flag > set? Am I on the wrong path? Have no idea how to get this to work. The problem isn't fragmentation (those DF packets are not large enough to require fragmentation), but the fact that you're not answering the neighbor solicitation queries from the peer. > ifconfig_gif0_ipv6="inet6 2001:470:66:3a3::2 2001:470:66:3a3::1 prefixlen 128" See http://www.tunnelbroker.net/forums/index.php?topic=1191.0 Daniel From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 11:29:34 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31420106564A for ; Wed, 11 Jul 2012 11:29:34 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailhost.dlr.de (mailhost.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id BCBB78FC08 for ; Wed, 11 Jul 2012 11:29:33 +0000 (UTC) Received: from DLREXHUB01.intra.dlr.de (172.21.152.130) by dlrexedge01.dlr.de (172.21.163.100) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 13:29:08 +0200 Received: from KNOP-BEAGLE.kn.op.dlr.de (129.247.178.136) by smtp.dlr.de (172.21.152.151) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 13:29:10 +0200 Date: Wed, 11 Jul 2012 13:29:11 +0200 From: Hartmut Brandt X-X-Sender: brandt_h@KNOP-BEAGLE.kn.op.dlr.de To: Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" X-Originating-IP: [129.247.178.136] Cc: Subject: VNET and IPv6 multicast routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 11:29:34 -0000 Is $subj supposed to work in -current? When I set MFC entries in a second jails the ones installed from the first jail get destroyed or mixed up. harti From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 15:51:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6549A106564A for ; Wed, 11 Jul 2012 15:51:33 +0000 (UTC) (envelope-from chris.benesch@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0578FC16 for ; Wed, 11 Jul 2012 15:51:33 +0000 (UTC) Received: by yenl8 with SMTP id l8so1567375yen.13 for ; Wed, 11 Jul 2012 08:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dRw5II2jYBSAYRi9rXXOHgPl9DXpq7p/UgzRZm7DA3E=; b=M0+6C0btkzo200JG977Vn8o7iH+b5J+HGtaZ0aR7v4iNmPRaIARwpIJjbtcAgbEpch ct1pbN3CgR0Z874VyiP/m/RludxUlXcNxXcP64Z9ojNJPUlSRczxwuMrgC8TkcuF43Ft Xf5C9x0EQevwNZ0GzS9H4G6qG/PzBy4jJbCci1KH3bK4hN1G/xP2ERCTFOUuZeXUPk0D DnRht33u9Uu5WVCk2oyIXX8kH0kRSivPZjmgB3xIyGGOugLsWXNzWqVkSJdeYTmYDpmE aoeCe0VkarlE6kCSB7grQjDZCO4PAhRAG0NS5Pchqz9UCZ2RKiBTCgPQgRSwZ07WnuIK wv7A== MIME-Version: 1.0 Received: by 10.50.187.228 with SMTP id fv4mr15030146igc.10.1342021892252; Wed, 11 Jul 2012 08:51:32 -0700 (PDT) Received: by 10.231.26.150 with HTTP; Wed, 11 Jul 2012 08:51:32 -0700 (PDT) In-Reply-To: <20120711110152.GE9145@insomnia.benzedrine.cx> References: <20120711110152.GE9145@insomnia.benzedrine.cx> Date: Wed, 11 Jul 2012 08:51:32 -0700 Message-ID: From: Chris Benesch To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: GIF tunnel doesnt like fragmented packets? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 15:51:33 -0000 OMG I am so stupid gifconfig_gif0="192.168.0.2 64.62.134.130" << works gifconfig_gif0="198.168.0.2 64.62.134.130" << what it was before, doesnt work Sorry to waste everyones time From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 18:14:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B17410656DF for ; Wed, 11 Jul 2012 18:14:59 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by mx1.freebsd.org (Postfix) with ESMTP id B1E748FC16 for ; Wed, 11 Jul 2012 18:14:58 +0000 (UTC) Received: from mail231-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 11 Jul 2012 17:57:26 +0000 Received: from mail231-ch1 (localhost [127.0.0.1]) by mail231-ch1-R.bigfish.com (Postfix) with ESMTP id 99AC817C02D7; Wed, 11 Jul 2012 17:57:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI X-SpamScore: -17 X-BigFish: VPS-17(zz98dI9371I936eI542M1453M1447I328cMzz1202hzz8275bh8275dh74efjz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail231-ch1: domain of qlogic.com designates 198.70.193.64 as permitted sender) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail231-ch1 (localhost.localdomain [127.0.0.1]) by mail231-ch1 (MessageSwitch) id 134202944455249_1049; Wed, 11 Jul 2012 17:57:24 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail231-ch1.bigfish.com (Postfix) with ESMTP id 0B6CA20045; Wed, 11 Jul 2012 17:57:24 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 11 Jul 2012 17:57:22 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Wed, 11 Jul 2012 10:59:43 -0700 From: Adarsh Joshi To: Andrew Boyer Date: Wed, 11 Jul 2012 10:59:42 -0700 Thread-Topic: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance Thread-Index: Ac1em3iDmAWR/fFfTBmYMQ9wIwfjmAAINpAgAAHAncAAMtwkkA== Message-ID: <5E4F49720D0BAD499EE1F01232234BA8774378F76D@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA877435B2E28@AVEXMB1.qlogic.org> <4C5FC147-2F49-4AE0-ADF3-C5381DE6580F@averesystems.com> <5E4F49720D0BAD499EE1F01232234BA877435B2F2E@AVEXMB1.qlogic.org> <5E4F49720D0BAD499EE1F01232234BA877435B2F66@AVEXMB1.qlogic.org> In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA877435B2F66@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Cc: "freebsd-net@freebsd.org" Subject: RE: lacp lagg port flags do not show correctly resulting in poor traffic distribution/performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:14:59 -0000 I tried to configure lagg with the latest source from SVN head and it did n= ot help. Regards Adarsh -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Adarsh Joshi Sent: Tuesday, July 10, 2012 10:53 AM To: Andrew Boyer Cc: freebsd-net@freebsd.org Subject: RE: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance Andrew, Here are the logs with LACP_DEBUG defined in ieee802.3ad_lacp.c, after typing Ifconfig lagg0 create ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netma= sk 255.255.255.0 I compiled it as a standalone driver by the way. System 1: # ifconfig -v lagg0 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D13b ether 00:0e:1e:08:05:20 inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-08-05-20,01D3,0000,0000), (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] laggport: ql1 flags=3D18 state=3D7D [(8000,00-0E-1E-08-05-20,01D3,8000,000D), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D1c state=3D3D [(8000,00-0E-1E-08-05-20,01D3,8000,000C), (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] System 2: # ifconfig -v lagg0 lagg0: flags=3D8843 metric 0 mtu 15= 00 options=3D13b ether 00:0e:1e:04:2c:f0 inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255 nd6 options=3D29 media: Ethernet autoselect status: active groups: lagg laggproto lacp lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: ql1 flags=3D1c state=3D7D [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D18 state=3D3D [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), (8000,00-0E-1E-08-05-20,01D3,8000,000C)] System 1 logs : Jul 10 10:38:49 bsd-14 kernel: lacp_attach[738] : lacp attached Jul 10 10:3= 8:49 bsd-14 kernel: lacp_attach[740] : lacp_defined Jul 10 10:38:49 bsd-14 = kernel: lagg0: link state changed to UP Jul 10 10:38:49 bsd-14 kernel: ql0:= media changed 0x0 -> 0x100033, ether =3D 1, fdx =3D 1, link =3D 1 Jul 10 1= 0:38:49 bsd-14 kernel: ql0: -> UNSELECTED Jul 10 10:38:49 bsd-14 kernel: ql= 1: media changed 0x0 -> 0x100033, ether =3D 1, fdx =3D 1, link =3D 1 Jul 10= 10:38:49 bsd-14 kernel: ql1: -> UNSELECTED Jul 10 10:38:49 bsd-14 kernel: = lacp_select_tx_port: no active aggregator Jul 10 10:38:50 bsd-14 kernel: ql= 1: port lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000D),(0000,00-00-00-00-= 00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql1: aggregator created Jul 10 10:38:50 bsd-= 14 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql1: mux_state 0 -> 1 Jul 10 10:38:50 bsd-14= kernel: ql0: port lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000C),(0000,0= 0-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql0: aggregator created Jul 10 10:38:50 bsd-= 14 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:50 bsd-14 kernel: ql0: mux_state 0 -> 1 Jul 10 10:38:51 bsd-14= kernel: ql1: lacpdu transmit Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,= 00-0E-1E-08-05-20,01D3,8000,000D) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D85 Jul 10 10:38:51 bsd-14 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 Jul 10 10:38:51 b= sd-14 kernel: maxdelay=3D0 Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu trans= mit Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D85 Jul 10 10:38:51 bsd-14 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D2 Jul 10 10:38:51 b= sd-14 kernel: maxdelay=3D0 Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu recei= ve Jul 10 10:38:51 bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000= ,000E) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 Jul 10 10:38:51 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D85 Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:51 bsd-14 kernel: = ql0: old pstate 2 Jul 10 10:38:51 bsd-14 kernel: ql0: new pstate 5= Jul 10 10:38:51 bsd-14 kernel: ql0: partner timeout = changed Jul 10 10:38:51 bsd-14 kernel: ql0: lacpdu receive Jul 10 10:38:51 = bsd-14 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) Jul 10 10:38:51 bsd-14 kernel: actor.state=3D5 Jul 10 10:38:51 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:51 bsd-14 kernel: partner.state=3D85 Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:52 bsd-14 kernel: = ql1: lacp_sm_rx_timer: EXPIRED -> DEFAULTED Jul 10 10:38:52 bsd-14 kernel: = ql1: partner timeout changed Jul 10 10:38:52 bsd-14 kernel: ql1: lacp_sm_mu= x_timer: aggregator [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00= -00-00-00,0000,0000,0000)], pending 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: q= l1: collecting disabled Jul 10 10:38:52 bsd-14 kernel: lacp_aggregator_delr= ef: lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,00-00-00-00-00-0= 0,0000,0000,0000)], refcnt 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql1: mux_s= tate 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql1: lacpdu transmit Jul 10 10:3= 8:52 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000D) Jul 10 10:38:52 bsd-14 kernel: actor.state=3D45 Jul 10 10:38:52 bsd-14 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 10:38:52 bsd-14 kernel: partner.state=3D3c Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:52 bsd-14 kernel: = ql0: lacp_sm_mux_timer: aggregator [(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(0000,00-00-00-00-00-00,0000,0000,0000)], pending 1 -> 0 Jul 10 10:38:52 b= sd-14 kernel: ql0: collecting disabled Jul 10 10:38:52 bsd-14 kernel: lacp_= aggregator_delref: lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000),(0000,0= 0-00-00-00-00-00,0000,0000,0000)], refcnt 1 -> 0 Jul 10 10:38:52 bsd-14 ker= nel: ql0: mux_state 1 -> 0 Jul 10 10:38:52 bsd-14 kernel: ql0: lacpdu trans= mit Jul 10 10:38:52 bsd-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,800= 0,000C) Jul 10 10:38:52 bsd-14 kernel: actor.state=3D5 Jul 10 10:38:52 bsd-14 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 10:38:52 bsd-14 kernel: partner.state=3D5 Jul 10 10:38:52 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:53 bsd-14 kernel: = ql1: port lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000D),(FFFF,00-00-00-0= 0-00-00,0000,FFFF,0000)] Jul 10 10:38:53 bsd-14 kernel: ql1: aggregator created Jul 10 10:38:53 bsd-= 14 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:53 bsd-14 kernel: ql1: mux_state 0 -> 1 Jul 10 10:38:53 bsd-14= kernel: ql0: port lagid=3D[(8000,00-0E-1E-08-05-20,01D3,8000,000C),(8000,0= 0-0E-1E-04-2C-F0,0213,8000,000E)] Jul 10 10:38:53 bsd-14 kernel: ql0: aggregator created Jul 10 10:38:53 bsd-= 14 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(8000,00-0E-1E-04-2C-F0,0213,0000,0000)] Jul 10 10:38:53 bsd-14 kernel: ql0: mux_state 0 -> 1 Jul 10 10:38:54 bsd-14= kernel: ql0: lacpdu receive Jul 10 10:38:54 bsd-14 kernel: actor=3D(8000,0= 0-0E-1E-04-2C-F0,0213,8000,000E) Jul 10 10:38:54 bsd-14 kernel: actor.state=3Dd Jul 10 10:38:54 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:54 bsd-14 kernel: partner.state=3D5 Jul 10 10:38:54 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:54 bsd-14 kernel: = ql0: old pstate 5 Jul 10 10:38:54 bsd-14 kernel: ql0:= new pstate d Jul 10 10:38:55 bsd-14 kernel: ql1= : lacp_sm_mux_timer: aggregator [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(F= FFF,00-00-00-00-00-00,0000,0000,0000)], pending 1 -> 0 Jul 10 10:38:55 bsd-= 14 kernel: ql1: collecting disabled Jul 10 10:38:55 bsd-14 kernel: ql1: mux= _state 1 -> 2 Jul 10 10:38:55 bsd-14 kernel: ql1: collecting enabled Jul 10= 10:38:55 bsd-14 kernel: ql1: mux_state 2 -> 3 Jul 10 10:38:55 bsd-14 kerne= l: ql1: enable distributing on aggregator [(8000,00-0E-1E-08-05-20,01D3,000= 0,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)], nports 0 -> 1 Jul 10 10:3= 8:55 bsd-14 kernel: lacp_select_active_aggregator: Jul 10 10:38:55 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FF= FF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul = 10 10:38:55 bsd-14 kernel: active aggregator changed Jul 10 10:38:55 bsd-14= kernel: old (none) Jul 10 10:38:55 bsd-14 kernel: new [(8000,00-0E-1E-08-0= 5-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 10:38:55 bsd-14 kernel: Set table 1 with 1 ports Jul 10 10:38:55 bsd= -14 kernel: lacp_suppress_distributing Jul 10 10:38:55 bsd-14 kernel: ql1: = marker transmit, port=3D13, sys=3D00:0e:1e:08:05:20, id=3D1 Jul 10 10:38:55= bsd-14 kernel: ql0: marker transmit, port=3D12, sys=3D00:0e:1e:08:05:20, i= d=3D1 Jul 10 10:38:55 bsd-14 kernel: ql1: mux_state 3 -> 4 Jul 10 10:38:55 = bsd-14 kernel: ql1: lacpdu transmit Jul 10 10:38:55 bsd-14 kernel: ql0: mar= ker response, port=3D12, sys=3D00:0e:1e:08:05:20, id=3D1 Jul 10 10:38:55 bs= d-14 kernel: actor=3D(8000,00-0E-1E-08-05-20,01D3,8000,000D) Jul 10 10:38:55 bsd-14 kernel: actor.state=3D7d Jul 10 10:38:55 bsd-14 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 10:38:55 bsd-14 kernel: partner.state=3D3c Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:55 bsd-14 kernel: = ql0: lacp_sm_mux_timer: aggregator [(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(8000,00-0E-1E-04-2C-F0,0213,0000,0000)], pending 1 -> 0 Jul 10 10:38:55 b= sd-14 kernel: ql0: collecting disabled Jul 10 10:38:55 bsd-14 kernel: ql0: = mux_state 1 -> 2 Jul 10 10:38:55 bsd-14 kernel: ql0: collecting enabled Jul= 10 10:38:55 bsd-14 kernel: ql0: mux_state 2 -> 3 Jul 10 10:38:55 bsd-14 ke= rnel: ql0: lacpdu transmit Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-= 0E-1E-08-05-20,01D3,8000,000C) Jul 10 10:38:55 bsd-14 kernel: actor.state=3D1d Jul 10 10:38:55 bsd-14 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 10:38:55 bsd-14 kernel: partner.state=3Dd Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:55 bsd-14 kernel: = ql0: lacpdu receive Jul 10 10:38:55 bsd-14 kernel: actor=3D(8000,00-0E-1E-0= 4-2C-F0,0213,8000,000E) Jul 10 10:38:55 bsd-14 kernel: actor.state=3D3d Jul 10 10:38:55 bsd-14 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 10:38:55 bsd-14 kernel: partner.state=3D1d Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:55 bsd-14 kernel: = ql0: old pstate d Jul 10 10:38:55 bsd-14 kernel:= ql0: new pstate 3d Jul 10 10:38:56 bsd-14 kernel: ql0: enable distributing on aggregator [(800= 0,00-0E-1E-08-05-20,01D3,0000,0000),(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ], nports 0 -> 1 Jul 10 10:38:56 bsd-14 kernel: lacp_select_active_aggregat= or: Jul 10 10:38:56 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FF= FF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul = 10 10:38:56 bsd-14 kernel: [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(8000,0= 0-0E-1E-04-2C-F0,0213,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 1= 0:38:56 bsd-14 kernel: active aggregator changed Jul 10 10:38:56 bsd-14 ker= nel: old [(8000,00-0E-1E-08-05-20,01D3,0000,0000),(FFFF,00-00-00-00-00-00,0= 000,0000,0000)] Jul 10 10:38:56 bsd-14 kernel: new [(8000,00-0E-1E-08-05-20,01D3,0000,0000)= ,(8000,00-0E-1E-04-2C-F0,0213,0000,0000)] Jul 10 10:38:56 bsd-14 kernel: Set table 0 with 1 ports Jul 10 10:38:56 bsd= -14 kernel: lacp_suppress_distributing Jul 10 10:38:56 bsd-14 kernel: ql1: = marker transmit, port=3D13, sys=3D00:0e:1e:08:05:20, id=3D2 Jul 10 10:38:56= bsd-14 kernel: ql0: marker transmit, port=3D12, sys=3D00:0e:1e:08:05:20, i= d=3D2 Jul 10 10:38:56 bsd-14 kernel: ql0: mux_state 3 -> 4 Jul 10 10:38:56 = bsd-14 kernel: ql0: marker response, port=3D12, sys=3D00:0e:1e:08:05:20, id= =3D2 Jul 10 10:38:59 bsd-14 kernel: lacp_transit_expire ^C System 2 logs : Jul 10 02:38:24 bsd-15 kernel: lacp_attach[738] : lacp attached Jul 10 02:3= 8:24 bsd-15 kernel: lacp_attach[740] : lacp_defined Jul 10 02:38:24 bsd-15 = kernel: lagg0: link state changed to UP Jul 10 02:38:24 bsd-15 kernel: ql0:= media changed 0x0 -> 0x100033, ether =3D 1, fdx =3D 1, link =3D 1 Jul 10 0= 2:38:24 bsd-15 kernel: ql0: -> UNSELECTED Jul 10 02:38:24 bsd-15 kernel: ql= 1: media changed 0x0 -> 0x100033, ether =3D 1, fdx =3D 1, link =3D 1 Jul 10= 02:38:24 bsd-15 kernel: ql1: -> UNSELECTED Jul 10 02:38:24 bsd-15 kernel: = lacp_select_tx_port: no active aggregator Jul 10 02:38:25 bsd-15 kernel: ql= 1: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000F),(0000,00-00-00-00-= 00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql1: aggregator created Jul 10 02:38:25 bsd-= 15 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ,(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql1: mux_state 0 -> 1 Jul 10 02:38:25 bsd-15= kernel: ql0: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000E),(0000,0= 0-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql0: aggregator created Jul 10 02:38:25 bsd-= 15 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ,(0000,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:25 bsd-15 kernel: ql0: mux_state 0 -> 1 Jul 10 02:38:26 bsd-15= kernel: ql0: lacpdu receive Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,0= 0-0E-1E-08-05-20,01D3,8000,000C) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D85 Jul 10 02:38:26 bsd-15 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 Jul 10 02:38:26 b= sd-15 kernel: maxdelay=3D0 Jul 10 02:38:26 bsd-15 kernel: ql0: lacp_sm_rx_u= pdate_ntt: assert ntt Jul 10 02:38:26 bsd-15 kernel: ql0: old pstate 2 Jul 10 02:38:26 bsd-15 kernel: ql0: new pstate 85 Jul 10 02:38:26 bsd-15 kernel: ql0: partner timeout changed Jul 1= 0 02:38:26 bsd-15 kernel: ql0: lacpdu transmit Jul 10 02:38:26 bsd-15 kerne= l: actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000E) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 Jul 10 02:38:26 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D85 Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:26 bsd-15 kernel: = ql1: lacpdu transmit Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,00-0E-1E-= 04-2C-F0,0213,8000,000F) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D85 Jul 10 02:38:26 bsd-15 kernel: partner=3D(0000,00-00-00-00-00-00,0000,0000,= 0000) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D2 Jul 10 02:38:26 b= sd-15 kernel: maxdelay=3D0 Jul 10 02:38:26 bsd-15 kernel: ql0: collecting d= isabled Jul 10 02:38:26 bsd-15 kernel: lacp_aggregator_delref: lagid=3D[(80= 00,00-0E-1E-04-2C-F0,0213, 0000,0000),(0000,00-00-00-00-00-00,0000,0000,000= 0)], refcnt 1 -> 0 Jul 10 02:38:26 bsd-15 kernel: ql0: mux_state 1 -> 0 Jul 10 02:38:26 bsd-15= kernel: ql0: lacpdu transmit Jul 10 02:38:26 bsd-15 kernel: actor=3D(8000,= 00-0E-1E-04-2C-F0,0213,8000,000E) Jul 10 02:38:26 bsd-15 kernel: actor.state=3D5 Jul 10 02:38:26 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:26 bsd-15 kernel: partner.state=3D85 Jul 10 02:38:26 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:27 bsd-15 kernel: = ql0: lacpdu receive Jul 10 02:38:27 bsd-15 kernel: actor=3D(8000,00-0E-1E-0= 8-05-20,01D3,8000,000C) Jul 10 02:38:27 bsd-15 kernel: actor.state=3D5 Jul 10 02:38:27 bsd-15 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 02:38:27 bsd-15 kernel: partner.state=3D5 Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:27 bsd-15 kernel: = ql0: old pstate 85 Jul 10 02:38:27 bsd-15 ker= nel: ql0: new pstate 5 Jul 10 02:38:27 bsd-15 kernel:= ql1: lacp_sm_rx_timer: EXPIRED -> DEFAULTED Jul 10 02:38:27 bsd-15 kernel:= ql1: partner timeout changed Jul 10 02:38:27 bsd-15 kernel: ql1: lacp_sm_m= ux_timer: aggregator [(8000,00-0E-1E-04-2C-F0, 0213,0000,0000),(0000,00-00-= 00-00-00-00,0000,0000,0000)], pending 1 -> 0 Jul 10 02:38:27 bsd-15 kernel:= ql1: collecting disabled Jul 10 02:38:27 bsd-15 kernel: lacp_aggregator_de= lref: lagid=3D[(8000,00-0E-1E-04-2C-F0,0213, 0000,0000),(0000,00-00-00-00-0= 0-00,0000,0000,0000)], refcnt 1 -> 0 Jul 10 02:38:27 bsd-15 kernel: ql1: mux_state 1 -> 0 Jul 10 02:38:27 bsd-15= kernel: ql1: lacpdu transmit Jul 10 02:38:27 bsd-15 kernel: actor=3D(8000,= 00-0E-1E-04-2C-F0,0213,8000,000F) Jul 10 02:38:27 bsd-15 kernel: actor.state=3D45 Jul 10 02:38:27 bsd-15 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 02:38:27 bsd-15 kernel: partner.state=3D3c Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:27 bsd-15 kernel: = ql0: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000E),(8000,00-0E-1E-0= 8-05-20,01D3,8000,000C)] Jul 10 02:38:27 bsd-15 kernel: ql0: aggregator created Jul 10 02:38:27 bsd-= 15 kernel: ql0: aggregator lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ,(8000,00-0E-1E-08-05-20,01D3,0000,0000)] Jul 10 02:38:27 bsd-15 kernel: ql0: mux_state 0 -> 1 Jul 10 02:38:28 bsd-15= kernel: ql1: port lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,8000,000F),(FFFF,0= 0-00-00-00-00-00,0000,FFFF,0000)] Jul 10 02:38:28 bsd-15 kernel: ql1: aggregator created Jul 10 02:38:28 bsd-= 15 kernel: ql1: aggregator lagid=3D[(8000,00-0E-1E-04-2C-F0,0213,0000,0000)= ,(FFFF,00-00-00-00-00-00,0000,0000,0000)] Jul 10 02:38:28 bsd-15 kernel: ql1: mux_state 0 -> 1 Jul 10 02:38:29 bsd-15= kernel: ql0: lacp_sm_mux_timer: aggregator [(8000,00-0E-1E-04-2C-F0, 0213,= 0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,0000)], pending 1 -> 0 Jul 10 = 02:38:29 bsd-15 kernel: ql0: collecting disabled Jul 10 02:38:29 bsd-15 ker= nel: ql0: mux_state 1 -> 2 Jul 10 02:38:29 bsd-15 kernel: ql0: lacpdu trans= mit Jul 10 02:38:29 bsd-15 kernel: actor=3D(8000,00-0E-1E-04-2C-F0,0213,800= 0,000E) Jul 10 02:38:29 bsd-15 kernel: actor.state=3Dd Jul 10 02:38:29 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:29 bsd-15 kernel: partner.state=3D5 Jul 10 02:38:29 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:30 bsd-15 kernel: = ql0: lacpdu receive Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,00-0E-1E-0= 8-05-20,01D3,8000,000C) Jul 10 02:38:30 bsd-15 kernel: actor.state=3D1d Jul 10 02:38:30 bsd-15 kernel: partner=3D(8000,00-0E-1E-04-2C-F0,0213,8000,= 000E) Jul 10 02:38:30 bsd-15 kernel: partner.state=3Dd Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:30 bsd-15 kernel: = ql0: old pstate 5 Jul 10 02:38:30 bsd-15 kernel: ql0:= new pstate 1d Jul 10 02:38:30 bsd-15 kernel: ql1: lacp_sm_mux_timer: aggregator [(8000,00= -0E-1E-04-2C-F0, 0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,0000,0000)], = pending 1 -> 0 Jul 10 02:38:30 bsd-15 kernel: ql1: collecting disabled Jul = 10 02:38:30 bsd-15 kernel: ql1: mux_state 1 -> 2 Jul 10 02:38:30 bsd-15 ker= nel: ql1: collecting enabled Jul 10 02:38:30 bsd-15 kernel: ql1: mux_state = 2 -> 3 Jul 10 02:38:30 bsd-15 kernel: ql1: enable distributing on aggregato= r [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-00,0000,000= 0,0000)], nports 0 -> 1 Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_a= ggregator: Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FF= FF,00-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul = 10 02:38:30 bsd-15 kernel: active aggregator changed Jul 10 02:38:30 bsd-15= kernel: old (none) Jul 10 02:38:30 bsd-15 kernel: new [(8000,00-0E-1E-04-2= C-F0,0213,0000,0000),(FFFF,00-00-00 00-00-00,0000,0000,0000)] Jul 10 02:38:= 30 bsd-15 kernel: Set table 1 with 1 ports Jul 10 02:38:30 bsd-15 kernel: l= acp_suppress_distributing Jul 10 02:38:30 bsd-15 kernel: ql1: marker transm= it, port=3D15, sys=3D00:0e:1e:04:2c:f0, id=3D1 Jul 10 02:38:30 bsd-15 kerne= l: ql0: marker transmit, port=3D14, sys=3D00:0e:1e:04:2c:f0, id=3D1 Jul 10 = 02:38:30 bsd-15 kernel: ql1: mux_state 3 -> 4 Jul 10 02:38:30 bsd-15 kernel= : ql1: lacpdu transmit Jul 10 02:38:30 bsd-15 kernel: ql0: marker response,= port=3D14, sys=3D00:0e:1e:04:2c:f0, id=3D1 Jul 10 02:38:30 bsd-15 kernel: = actor=3D(8000,00-0E-1E-04-2C-F0,0213,8000,000F) Jul 10 02:38:30 bsd-15 kernel: actor.state=3D7d Jul 10 02:38:30 bsd-15 kernel: partner=3D(FFFF,00-00-00-00-00-00,0000,FFFF,= 0000) Jul 10 02:38:30 bsd-15 kernel: partner.state=3D3c Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:30 bsd-15 kernel: = ql0: collecting enabled Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 2 -> = 3 Jul 10 02:38:30 bsd-15 kernel: ql0: enable distributing on aggregator [(8= 000,00-0E-1E-04-2C-F0,0213,0000,0000),(8000,00-0E-1E-08-05-20,01D3,0000,000= 0)], nports 0 -> 1 Jul 10 02:38:30 bsd-15 kernel: lacp_select_active_aggreg= ator: Jul 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(80= 00,00-0E-1E-08-05-20,01D3,0000,0000)], speed=3D10000000000, nports=3D1 Jul = 10 02:38:30 bsd-15 kernel: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,0= 0-00-00-00-00-00,0000,0000,0000)], speed=3D10000000000, nports=3D1 Jul 10 0= 2:38:30 bsd-15 kernel: active aggregator not changed Jul 10 02:38:30 bsd-15= kernel: new [(8000,00-0E-1E-04-2C-F0,0213,0000,0000),(FFFF,00-00-00-00-00-= 00,0000,0000,0000)] Jul 10 02:38:30 bsd-15 kernel: ql0: mux_state 3 -> 4 Jul 10 02:38:30 bsd-15= kernel: ql0: lacpdu transmit Jul 10 02:38:30 bsd-15 kernel: actor=3D(8000,= 00-0E-1E-04-2C-F0,0213,8000,000E) Jul 10 02:38:30 bsd-15 kernel: actor.state=3D3d Jul 10 02:38:30 bsd-15 kernel: partner=3D(8000,00-0E-1E-08-05-20,01D3,8000,= 000C) Jul 10 02:38:30 bsd-15 kernel: partner.state=3D1d Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:33 bsd-15 kernel: = lacp_transit_expire ^C Let me know if you need more info. Thanks Adarsh -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of Adarsh Joshi Sent: Tuesday, July 10, 2012 10:08 AM To: Andrew Boyer Cc: freebsd-net@freebsd.org Subject: RE: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance Andrew, Thanks for the reply. The reason for my suspicion on the portflags is thus (extracted from the if= config output in my previous mail): System 1: Laggport: ql1 flags =3D 18 state =3D 7D Laggport: ql0 flags =3D 1c state =3D 3D System 2: Laggport: ql1 flags =3D 1c state =3D 7D Laggport: ql0 flags =3D 18 state =3D 3D I should have explained my setup to you before. Here it is. Both the ql0 interfaces of the 2 systems are connected using a single cable= and ql1 interfaces of the 2 systems are connected using a single cable. System 1 System 2 ql0 <=3D=3D=3D=3D=3D=3D=3D> ql0 ql1 <=3D=3D=3D=3D=3D=3D=3D> ql1 With this setup, I don't think it is possible for ports ql0 to talk to thei= r partners (each other) and ql1 ports not getting a response from their par= tner and still get the lagg configuration I have posted. I thought the portflags are dependent on the LACP state. But I see differen= t flags for the same LACP state (For the state 7D, ql1 on system 1 shows fl= ags =3D 18 and ql1 on system 2 shows flags =3D 1c). Or is my understanding totally wrong? I will send the LACP_DEBUG logs within the hour. Thanks Adarsh From: Andrew Boyer [mailto:aboyer@averesystems.com] Sent: Tuesday, July 10, 2012 5:57 AM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: lacp lagg port flags do not show correctly resulting in poor t= raffic distribution/performance On Jul 9, 2012, at 8:38 PM, Adarsh Joshi wrote: Hi, I am trying to configure lacp lagg interfaces with 2 systems connected back= to back as follows: Ifconfig lagg0 create Ifconfig lagg0 laggproto lacp laggport ql0 laggport ql1 192.168.100.1 netma= sk 255.255.255.0 Sometimes, the lag interface comes up correctly but sometimes the laggport = flags do not show properly. Instead of 1c, = it shows values of 18. I have seen similar issues reported on various forum= s with no solution. Looking at the lagg driver code and reading the standard, I thought the lag= gport flags ( defined in if_lagg.h) are based on the LACP_STATE_BITS in fil= e ieee8023ad_lacp.h. But the following ifconfig -v output does not make any= sense to me. My concern is that when all the interfaces show flags as 1c, the traffic is= distributed across both the interfaces uniformly and I get aggregated thro= ughput. If not, the traffic flows only on 1 interface. Is this a bug? How do I solve this? Or am I doing something wrong? I am using Free-BSD 9.0 release. System 1: # ifconfig -v lagg0 lag id: [(8000,00-0E-1E-08-05-20,0213,0000,0000), (8000,00-0E-1E-04-2C-F0,0213,0000,0000)] laggport: ql1 flags=3D18 state=3D7D [(8000,00-0E-1E-08-05-20,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D1c state=3D3D [(8000,00-0E-1E-08-05-20,0213,8000,000E), (8000,00-0E-1E-04-2C-F0,0213,8000,000E)] System 2: # ifconfig -v lagg0 lag id: [(8000,00-0E-1E-04-2C-F0,0213,0000,0000), (FFFF,00-00-00-00-00-00,0000,0000,0000)] laggport: ql1 flags=3D1c state=3D7D [(8000,00-0E-1E-04-2C-F0,0213,8000,000F), (FFFF,00-00-00-00-00-00,0000,FFFF,0000)] laggport: ql0 flags=3D18 state=3D3D [(8000,00-0E-1E-04-2C-F0,0213,8000,000E), (8000,00-0E-1E-08-05-20,0213,8000,000E)] thanks Adarsh I don't think you have a port flags problem per se; the flags are correctly= displaying the state of the lagg. Your problem is that your systems aren'= t negotiating the correct lagg configuration. Each tuple after the laggpor= t represents the [(actor state),(partner state)]. Ports ql0 have been able= to talk to their partners (each other). Neither ql1 port has seen a respo= nse from a partner, though. You could try restarting the state machine on one box with 'ifconfig lagg0 = laggproto lacp'. To see the negotiation you'll need to rebuild your kernel= with '#define LACP_DEBUG 1' added to the top of sys/net/ieee802.3ad_lacp.c= . Or upgrade to a newer stable snapshot that has the net.lacp_debug sysctl= and turn it on. Or just turn off LACP. What does it get you in this configuration? Hope this helps, Andrew -------------------------------------------------- Andrew Boyer aboyer@averesystems.com ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 20:31:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89D0B106566C; Wed, 11 Jul 2012 20:31:49 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 23BB68FC08; Wed, 11 Jul 2012 20:31:49 +0000 (UTC) Received: by obbun3 with SMTP id un3so2589110obb.13 for ; Wed, 11 Jul 2012 13:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1/SA2SGFY1rvuuH8yybgis1k39f981yziuNpMkDWuEs=; b=KSLdC+tK84tbE+q0yjSiQujhQ1XsfXEovaaqHX+YCD4R5VWals7T1MBebIBe0FIeFH yuDQyUI4RxMtf5KYiC/D6JEJjGIUJgLmuJqm/GQ7u48QyCtQqGFigbFwfjc6wujF3VwG TaOH20K4ukTj3St29uCrw6fNZlE00lPBuQAi9Pb8Tu3U925VOX4y+vXSG3YPGYv+jFPm eHvHL8mqBzx66RbVOp6MCRMhLUAau8wPSuJlLE0VjZklt0fkqdvR3pScTXsChw7sYbRB NhDmeIcJQtKAqZ3ciT8jq6qlhuRDeWmRfAuyFXQfcjmd4DJpD+L91Kf6tfHJl8xWoeVm fLpQ== MIME-Version: 1.0 Received: by 10.182.52.38 with SMTP id q6mr46444570obo.8.1342038708797; Wed, 11 Jul 2012 13:31:48 -0700 (PDT) Received: by 10.182.124.101 with HTTP; Wed, 11 Jul 2012 13:31:48 -0700 (PDT) Date: Wed, 11 Jul 2012 23:31:48 +0300 Message-ID: From: Sami Halabi To: freebsd-net@freebsd.org, freebsd-isp@freebsd.org, freebsd-performance@freebsd.org, Jack Vogel , Alexander Motin , "Bjoern A. Zeeb" , Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ating 100Gbit transfer rate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 20:31:49 -0000 Hi, We have several boxes using 10G cards and using most of the bandwidth. as a future vision i would like to ask if someone ever combined hardware with freebsd/linux to saturate 100Gbit of traffic. what hardware (server, NICs, platform) and software do you recommend that would allow me to acheive my goal? Is it possible with servers ? or i need dedicated hardware (cisco/juniper/other?) if dedicated hardware needed, i would be glad to hear from your experience what do you recommend in terms of performance and price. Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 21:29:08 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE6991065674 for ; Wed, 11 Jul 2012 21:29:08 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8FCC18FC16 for ; Wed, 11 Jul 2012 21:29:08 +0000 (UTC) Received: from [209.249.190.124] (port=16652 helo=punk.neville-neil.com.neville-neil.com) by vps.hungerhost.com with esmtpa (Exim 4.77) (envelope-from ) id 1Sp4Sz-0000QF-HR for net@freebsd.org; Wed, 11 Jul 2012 17:29:01 -0400 Date: Wed, 11 Jul 2012 17:30:33 -0400 Message-ID: <86liiqrnnq.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/23.4 (amd64-portbld-freebsd10.0) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Subject: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 21:29:08 -0000 Howdy, Does anyone know the reason for this particular check in ip_output.c? if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { /* * This case can happen if the user changed the MTU * of an interface after enabling IP on it. Because * most netifs don't keep track of routes pointing to * them, there is no way for one to update all its * routes when the MTU is changed. */ if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) rte->rt_rmx.rmx_mtu = ifp->if_mtu; mtu = rte->rt_rmx.rmx_mtu; } else { mtu = ifp->if_mtu; } To my mind the > ought to be != so that any change, up or down, of the interface MTU is eventually reflected in the route. Also, this code does not check if it is both a HOST route and UP, but only if it is one other the other, so don't be fooled by that, this check happens for any route we have if it's up. My proposed change is this: Index: ip_output.c =================================================================== --- ip_output.c (revision 225561) +++ ip_output.c (working copy) @@ -320,7 +320,7 @@ * them, there is no way for one to update all its * routes when the MTU is changed. */ - if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) + if (rte->rt_rmx.rmx_mtu != ifp->if_mtu) rte->rt_rmx.rmx_mtu = ifp->if_mtu; mtu = rte->rt_rmx.rmx_mtu; } else { Please let me know what y'all think. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Jul 11 21:57:31 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 395C9106564A; Wed, 11 Jul 2012 21:57:31 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0442B8FC08; Wed, 11 Jul 2012 21:57:30 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so2944313pbb.13 for ; Wed, 11 Jul 2012 14:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7jPWbZ3elujSuvZtHUxoh8MnkO7EmIA0Z5r2deVsstA=; b=c3HW2bqTMLhqCP6ysEjx8dbTDNV4tJjx67aDTeLrkhh7yK2Rje2GfyvGNCf1qggD2f qjxHOZchfT1w5rcuDzONN2/uOY0R1abKiTLQVPzHYcWSiAZ+npNeO83TbHfIZ8cuD5fL ijAPVsEzPA2YmA2toGTmIPIKhwr6+wUvEP2Ph9j0nK/rLCgQT2XO337KkNgW0FgUawyi vb5NtGXpK3Rodm76MUAi+oC0HWNrMrLaEFlK8B1faGpw/kGlMvfMUrQFacsrZNDP3Kle 2gGo/SV+u4Pi7JP30w1tZQyAh4hTA7gX10dKClE9hJXP6KjHGumSPSeYZHigi4eNbZ7t VFfQ== Received: by 10.68.226.137 with SMTP id rs9mr80812137pbc.114.1342043850546; Wed, 11 Jul 2012 14:57:30 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id jv6sm2439377pbc.40.2012.07.11.14.57.28 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 14:57:29 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <4FFDF6C7.3030301@FreeBSD.org> Date: Wed, 11 Jul 2012 14:57:27 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120705 Thunderbird/13.0.1 MIME-Version: 1.0 To: gnn@freebsd.org References: <86liiqrnnq.wl%gnn@neville-neil.com> In-Reply-To: <86liiqrnnq.wl%gnn@neville-neil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 21:57:31 -0000 On 07/11/12 14:30, gnn@freebsd.org wrote: > Howdy, > > Does anyone know the reason for this particular check in > ip_output.c? > > if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { > /* > * This case can happen if the user changed the MTU > * of an interface after enabling IP on it. Because > * most netifs don't keep track of routes pointing to > * them, there is no way for one to update all its > * routes when the MTU is changed. > */ > if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) > rte->rt_rmx.rmx_mtu = ifp->if_mtu; > mtu = rte->rt_rmx.rmx_mtu; > } else { > mtu = ifp->if_mtu; > } > > To my mind the > ought to be != so that any change, up or down, of the > interface MTU is eventually reflected in the route. Also, this code > does not check if it is both a HOST route and UP, but only if it is > one other the other, so don't be fooled by that, this check happens > for any route we have if it's up. I believe rmx_mtu could be low due to some intermediate node between this host and the final destination. An increase in the MTU of the local interface should not increase the path MTU if the limit was due to someone else along the route. Regards, Navdeep > > My proposed change is this: > > Index: ip_output.c > =================================================================== > --- ip_output.c (revision 225561) > +++ ip_output.c (working copy) > @@ -320,7 +320,7 @@ > * them, there is no way for one to update all its > * routes when the MTU is changed. > */ > - if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) > + if (rte->rt_rmx.rmx_mtu != ifp->if_mtu) > rte->rt_rmx.rmx_mtu = ifp->if_mtu; > mtu = rte->rt_rmx.rmx_mtu; > } else { > > Please let me know what y'all think. > > Best, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 03:43:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33452106566C; Thu, 12 Jul 2012 03:43:15 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3A57A8FC0A; Thu, 12 Jul 2012 03:43:14 +0000 (UTC) Received: by weyx56 with SMTP id x56so1736663wey.13 for ; Wed, 11 Jul 2012 20:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0NrhpCgkcuTKBje9LzoGx58zGA0FpKbgrrelbyYP63E=; b=B5LDv4j4oUZUZe5owDi3/776qHWNbnR1NBDS9FlklYgY54u34g4idbRcaxwlBntMAs llvv0UfkkiDyMAKD1U3Ujj11WGex4rJR2sztbc4F/+HwUH7CqnaMFk8iDtLGX/JaqdUj paCncL0V1yFBUzav/QCJ4guwVrJEuaOJM28FJQLugv2Tf7F14SDZOLZsEl9DgX3zPica kuJvCBxNaxdDyttEfOkSSLNhrnFT/JIWdsE+2vnKKhu8vunNzlKwsoSqaRLdTByfGV1N uKHG/LlZ8Ef0EQf50p1W0M/rwE1097YJ9FHvZb8t2kIa3AYItQtzkW/Lf8Z//CH8nKpe 3L0A== MIME-Version: 1.0 Received: by 10.180.78.99 with SMTP id a3mr52169001wix.15.1342064592894; Wed, 11 Jul 2012 20:43:12 -0700 (PDT) Received: by 10.223.88.217 with HTTP; Wed, 11 Jul 2012 20:43:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 Jul 2012 20:43:12 -0700 Message-ID: From: Kevin Oberman To: Sami Halabi Content-Type: text/plain; charset=UTF-8 Cc: Luigi Rizzo , freebsd-net@freebsd.org, Alexander Motin , freebsd-isp@freebsd.org, Jack Vogel , "Bjoern A. Zeeb" , freebsd-performance@freebsd.org Subject: Re: ating 100Gbit transfer rate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 03:43:15 -0000 On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi wrote: > Hi, > > We have several boxes using 10G cards and using most of the bandwidth. > as a future vision i would like to ask if someone ever combined hardware > with freebsd/linux to saturate 100Gbit of traffic. > what hardware (server, NICs, platform) and software do you recommend that > would allow me to acheive my goal? > > Is it possible with servers ? or i need dedicated hardware > (cisco/juniper/other?) if dedicated hardware needed, i would be glad to > hear from your experience what do you recommend in terms of performance and > price. I don't know of any 100GE hardware for any PC, but I may be a bit behind on the times. The way we saturate a 100GE with a FreeBSD (or Linux) system is using a 10G transmission stream and loop the data stream over the net using MPLS. Works quite well, though no end system ever sees more than about 9.9G, the routers do. We are using Alcatel-Lucent routers at this time for our national test network. It is available for research by educational, commercial and research organizations for a little longer as a federally funded testbed for 100G research. When the funding for that project runs out, most of the hardware will be re-purposed and will no longer be available for research. gnn@ mentioned it about a year ago and suggested that some FreeBSD people might want to submit proposals, but I sw no responses. We have tested with Juniper and they will work, too. All 100G hardware is just a mite pricey, though it has dropped tremendously over the past year and a half and I expect it will continue to do so. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 04:45:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BBF11065670; Thu, 12 Jul 2012 04:45:45 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C68898FC0A; Thu, 12 Jul 2012 04:45:44 +0000 (UTC) Received: by obbun3 with SMTP id un3so3238591obb.13 for ; Wed, 11 Jul 2012 21:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nCZl6uaVK0wGgQLi6TSaW/VE9LE6xmKj8i2X8IMTUvQ=; b=abkmCC7dhVj4Sq9+JM32A3NzfDuIo6Sl2OLV5Xo7hY9yk8ZoFfD53pH05gir3ny+Fd 4TdC6C2wObUeQCBVy75iMxsL3ghtrWrph0SOh9mPws7ld6T5vD7BFmqZR04xvJyZPD95 8DmbA1QUYr16KGpbT66iDj77uKurvSsPQV7zvYZGgG7d7BDzkoryvx54/jDzbhP2xVAQ GjPaz7YXHzxoZKkWD6+kEXCmeWaSmd8l84vQ19fpHh1UbwK9bOzZeKNpw96Rf5nKx7pF U1IeS6P8M5fiflwf8EzqljJTrSwnl6lYQpMWuLtXBUEL3X8yY73Ycda3F8qO2fncijQv hJrg== MIME-Version: 1.0 Received: by 10.60.168.230 with SMTP id zz6mr53120029oeb.11.1342068344110; Wed, 11 Jul 2012 21:45:44 -0700 (PDT) Received: by 10.182.124.101 with HTTP; Wed, 11 Jul 2012 21:45:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 07:45:43 +0300 Message-ID: From: Sami Halabi To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Luigi Rizzo , freebsd-net@freebsd.org, Alexander Motin , freebsd-isp@freebsd.org, Jack Vogel , "Bjoern A. Zeeb" , freebsd-performance@freebsd.org Subject: Re: ating 100Gbit transfer rate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 04:45:45 -0000 Hi, Thank your for your response. i have 2 questions: 1. can you explain the looping method that allowed you to reach 100GB ? 2. Alcatel-Lucent is routers are givven for research internationally ? or its locally? what routers we are talking about here and what link do they have? i appreciatre if you explain more how do these routers saturate 100GB. Thanks, Sami On Thu, Jul 12, 2012 at 6:43 AM, Kevin Oberman wrote: > On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi wrote: > > Hi, > > > > We have several boxes using 10G cards and using most of the bandwidth. > > as a future vision i would like to ask if someone ever combined hardware > > with freebsd/linux to saturate 100Gbit of traffic. > > what hardware (server, NICs, platform) and software do you recommend > that > > would allow me to acheive my goal? > > > > Is it possible with servers ? or i need dedicated hardware > > (cisco/juniper/other?) if dedicated hardware needed, i would be glad to > > hear from your experience what do you recommend in terms of performance > and > > price. > > I don't know of any 100GE hardware for any PC, but I may be a bit > behind on the times. > > The way we saturate a 100GE with a FreeBSD (or Linux) system is using > a 10G transmission stream and loop the data stream over the net using > MPLS. Works quite well, though no end system ever sees more than about > 9.9G, the routers do. > > We are using Alcatel-Lucent routers at this time for our national test > network. It is available for research by educational, commercial and > research organizations for a little longer as a federally funded > testbed for 100G research. When the funding for that project runs out, > most of the hardware will be re-purposed and will no longer be > available for research. gnn@ mentioned it about a year ago and > suggested that some FreeBSD people might want to submit proposals, but > I sw no responses. We have tested with Juniper and they will work, > too. All 100G hardware is just a mite pricey, though it has dropped > tremendously over the past year and a half and I expect it will > continue to do so. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 14:55:21 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F01C106567B; Thu, 12 Jul 2012 14:55:21 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 241C18FC0C; Thu, 12 Jul 2012 14:55:21 +0000 (UTC) Received: from [209.249.190.124] (port=63600 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SpKnR-00058T-FH; Thu, 12 Jul 2012 10:55:17 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: <4FFDF6C7.3030301@FreeBSD.org> Date: Thu, 12 Jul 2012 10:55:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> To: Navdeep Parhar X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org Cc: net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 14:55:21 -0000 On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote: > On 07/11/12 14:30, gnn@freebsd.org wrote: >> Howdy, >>=20 >> Does anyone know the reason for this particular check in >> ip_output.c? >>=20 >> if (rte !=3D NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { >> /* >> * This case can happen if the user changed the MTU >> * of an interface after enabling IP on it. Because >> * most netifs don't keep track of routes pointing to >> * them, there is no way for one to update all its >> * routes when the MTU is changed. >> */ >> if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) >> rte->rt_rmx.rmx_mtu =3D ifp->if_mtu; >> mtu =3D rte->rt_rmx.rmx_mtu; >> } else { >> mtu =3D ifp->if_mtu; >> } >>=20 >> To my mind the > ought to be !=3D so that any change, up or down, of = the >> interface MTU is eventually reflected in the route. Also, this code >> does not check if it is both a HOST route and UP, but only if it is >> one other the other, so don't be fooled by that, this check happens >> for any route we have if it's up. >=20 > I believe rmx_mtu could be low due to some intermediate node between = this host and the final destination. An increase in the MTU of the = local interface should not increase the path MTU if the limit was due to = someone else along the route. Yes, it turns out to be complex. We have several places that store the = MTU. There is the interface, which knows the MTU of the directly connected link, a route, and the = host cache. All three of these are used to determine the maximum segment size (MSS) of a TCP packet. = The route and the interface determine the maximum MTU that the MSS can have, but, if there is an = entry in the host cache then it is preferred over either of the first two. See tcp_update_mss() = in tcp_input.c to see what I'm talking about. I believe that the quoted code above has been wrong from the day it was = written, in that what it really says is "if the route is up" and not "if the route is up and is a = host route" which is what I believe people to read that as. If the belief is that this code = is really only there for hosts routes, then the proper fix is to make the sense of the first if = match that belief and, again, to change the > to !=3D so that when the administrator of = the box bumps the MTU in either direction that the route reflects this. It is not possible for = PMTU on a single link to a host route to bump the number down if the interface says it's not = to be bumped. And, even so, any host cache entry will override and avoid this code. Best, George From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 16:04:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9278C106566C; Thu, 12 Jul 2012 16:04:59 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD198FC0C; Thu, 12 Jul 2012 16:04:58 +0000 (UTC) Received: by weyx56 with SMTP id x56so2388641wey.13 for ; Thu, 12 Jul 2012 09:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OasibeoZE5t3aAlLHBP002THGK6vqv47092vHuH/Wp0=; b=Utc7PhHe1kcp+i7I9ZBNwtS7Ruku8IZlDIzZ/ygjkXrTEyjiAx59Z77pxDotGb0JYX XDNCGsoQoSzTYhjvh0MdCstA9PGpkw+AmuSjvSfo7lls7FyDdzl22aZQmUS92WsavqSY Da/j6ChYmc28JN+j9J9Akq9UlBQA97xYsZXxiq9gBlDq4RjtXQQoDYMtYW6RvRU6onIz hOMyPil9851+V6F2IFceQ8KHfGVSxue9QhZfXrHm5a2Og4Nc3mQ9MZJ7MIUdtM1oOo/t uy4Z1XxHC/IHIgeI0pwVAM0ki35Yvs7bt+n5whmUMzpC86jcazArbC6vyKVU6oVb7LJp CRrA== MIME-Version: 1.0 Received: by 10.216.4.146 with SMTP id 18mr15911156wej.83.1342109097156; Thu, 12 Jul 2012 09:04:57 -0700 (PDT) Received: by 10.223.88.217 with HTTP; Thu, 12 Jul 2012 09:04:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 09:04:57 -0700 Message-ID: From: Kevin Oberman To: Sami Halabi Content-Type: text/plain; charset=UTF-8 Cc: Luigi Rizzo , freebsd-net@freebsd.org, Alexander Motin , freebsd-isp@freebsd.org, Jack Vogel , "Bjoern A. Zeeb" , freebsd-performance@freebsd.org Subject: Re: ating 100Gbit transfer rate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:04:59 -0000 On Wed, Jul 11, 2012 at 9:45 PM, Sami Halabi wrote: > Hi, > Thank your for your response. > > i have 2 questions: > 1. can you explain the looping method that allowed you to reach 100GB ? > 2. Alcatel-Lucent is routers are given for research internationally ? or > its locally? what routers we are talking about here and what link do they > have? i appreciatre if you explain more how do these routers saturate 100GB. Sure. You create an LSP with a vrf (routing-instance in Juniper-ese) to place the traffic onto it. The LSP is manually configured at each hop to traverse to the far end router and that one then points back at the input router where it is again reversed back towards the destination. Loop as often as required to saturate the link. (I was tempted to just say "rinse and repeat, but that might not be clear to those not in the U.S.) For information on ANI (and I am not sure if new proposals are being accepted), see: http://www.es.net/RandD/advanced-networking-initiative/ > On Thu, Jul 12, 2012 at 6:43 AM, Kevin Oberman wrote: >> >> On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi wrote: >> > Hi, >> > >> > We have several boxes using 10G cards and using most of the bandwidth. >> > as a future vision i would like to ask if someone ever combined hardware >> > with freebsd/linux to saturate 100Gbit of traffic. >> > what hardware (server, NICs, platform) and software do you recommend >> > that >> > would allow me to acheive my goal? >> > >> > Is it possible with servers ? or i need dedicated hardware >> > (cisco/juniper/other?) if dedicated hardware needed, i would be glad to >> > hear from your experience what do you recommend in terms of performance >> > and >> > price. >> >> I don't know of any 100GE hardware for any PC, but I may be a bit >> behind on the times. >> >> The way we saturate a 100GE with a FreeBSD (or Linux) system is using >> a 10G transmission stream and loop the data stream over the net using >> MPLS. Works quite well, though no end system ever sees more than about >> 9.9G, the routers do. >> >> We are using Alcatel-Lucent routers at this time for our national test >> network. It is available for research by educational, commercial and >> research organizations for a little longer as a federally funded >> testbed for 100G research. When the funding for that project runs out, >> most of the hardware will be re-purposed and will no longer be >> available for research. gnn@ mentioned it about a year ago and >> suggested that some FreeBSD people might want to submit proposals, but >> I sw no responses. We have tested with Juniper and they will work, >> too. All 100G hardware is just a mite pricey, though it has dropped >> tremendously over the past year and a half and I expect it will >> continue to do so. >> -- >> R. Kevin Oberman, Network Engineer >> E-mail: kob6558@gmail.com > > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 16:55:20 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F915106566C for ; Thu, 12 Jul 2012 16:55:20 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 653CD8FC1A for ; Thu, 12 Jul 2012 16:55:13 +0000 (UTC) Received: by ghbz22 with SMTP id z22so3034292ghb.13 for ; Thu, 12 Jul 2012 09:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=u6n7adTerRVvLG1GvIxyg3OdcphKYsCsKXacw2lleIU=; b=Y8tyFV9Bj0KGGJfx9s6b4S/BNw5fff5ThF8ven0ax0PIOpBvusUxSNZdC+2lCy6qOh L5LF8DtqVHPpekqenesTR5CjR5VLzDxDHZxFXRiXUNLmzohHQvnsS/0kjj3QX2vQLrIj tuDLE4L8jex79xoLG3grsVNTb9JFFq8FDeUDE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=u6n7adTerRVvLG1GvIxyg3OdcphKYsCsKXacw2lleIU=; b=T4gP9YQKC+Et0wwfgse4U1D6GOAQipExOv7cnm/kzxjbX67/vPD4BJ7LsAj5jqQwnK T0gRgZKVUsB21hrtiLDkGd8fXqDSd/I+jjhkPXFq5VeP+4sWNgFScIGQuiFcOQlB4sWg ausc2XxxpfTaKPXZwK6pFDZ9k1eopAT05/WWItSmn4Xt23WJcJP2v41Gf6SwYH0YOizS Kth+Ar7nVfiE0MJ6VZW0enJiELyvH/gj1v8ajd9+f+dlNbWGCjOiJaHBodcxxQWuoY+i emNf1N0CT0391PfZkMKwi6/ZouSAGIkysqjWMY8s8jytq1RUZJ0RVA+qSXV48RI9atwP 9ALA== Received: by 10.50.163.70 with SMTP id yg6mr17914896igb.70.1342112106232; Thu, 12 Jul 2012 09:55:06 -0700 (PDT) Received: from DataIX.net ([99.109.125.25]) by mx.google.com with ESMTPS id ud8sm9264023igb.4.2012.07.12.09.55.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 09:55:05 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6CGt2I3070513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 12:55:03 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6CGt2j9070512; Thu, 12 Jul 2012 12:55:02 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Thu, 12 Jul 2012 12:55:02 -0400 From: Jason Hellenthal To: George Neville-Neil Message-ID: <20120712165502.GA61341@DataIX.net> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Gm-Message-State: ALoCoQny+qi2hh9jdVDeJutUWqRY7Qe/0rNOET5weGAD941sPNjg91rL/Hqtd8RnpD/QO5Y1LpjA Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:55:20 -0000 On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote: > > On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote: > > > On 07/11/12 14:30, gnn@freebsd.org wrote: > >> Howdy, > >> > >> Does anyone know the reason for this particular check in > >> ip_output.c? > >> > >> if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { > >> /* > >> * This case can happen if the user changed the MTU > >> * of an interface after enabling IP on it. Because > >> * most netifs don't keep track of routes pointing to > >> * them, there is no way for one to update all its > >> * routes when the MTU is changed. > >> */ > >> if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) > >> rte->rt_rmx.rmx_mtu = ifp->if_mtu; > >> mtu = rte->rt_rmx.rmx_mtu; > >> } else { > >> mtu = ifp->if_mtu; > >> } > >> > >> To my mind the > ought to be != so that any change, up or down, of the > >> interface MTU is eventually reflected in the route. Also, this code > >> does not check if it is both a HOST route and UP, but only if it is > >> one other the other, so don't be fooled by that, this check happens > >> for any route we have if it's up. > > > > I believe rmx_mtu could be low due to some intermediate node between this host and the final destination. An increase in the MTU of the local interface should not increase the path MTU if the limit was due to someone else along the route. > > Yes, it turns out to be complex. We have several places that store the MTU. There is the interface, > which knows the MTU of the directly connected link, a route, and the host cache. All three of these > are used to determine the maximum segment size (MSS) of a TCP packet. The route and the interface > determine the maximum MTU that the MSS can have, but, if there is an entry in the host cache > then it is preferred over either of the first two. See tcp_update_mss() in tcp_input.c to > see what I'm talking about. > > I believe that the quoted code above has been wrong from the day it was written, in that what it > really says is "if the route is up" and not "if the route is up and is a host route" which is > what I believe people to read that as. If the belief is that this code is really only there for > hosts routes, then the proper fix is to make the sense of the first if match that belief > and, again, to change the > to != so that when the administrator of the box bumps the MTU in > either direction that the route reflects this. It is not possible for PMTU on a single link > to a host route to bump the number down if the interface says it's not to be bumped. And, > even so, any host cache entry will override and avoid this code. > Something else to look into ... # ifconfig lagg0 mtu 1492 ifconfig: ioctl (set mtu): Invalid argument This is on stable/8 r238264 when the interface was up/up and down/down Also attempted on the member interfaces dc0 and dc1 -- - (2^(N-1)) From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 18:26:10 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EA7BC106566B; Thu, 12 Jul 2012 18:26:10 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from mail.averesystems.com (50-73-27-109-cpennsylvania.hfc.comcastbusiness.net [50.73.27.109]) by mx1.freebsd.org (Postfix) with ESMTP id B4CBC8FC08; Thu, 12 Jul 2012 18:26:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.averesystems.com (Postfix) with ESMTP id F32B848067A; Thu, 12 Jul 2012 14:26:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.averesystems.com Received: from mail.averesystems.com ([127.0.0.1]) by localhost (mail.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1Qj8uHikfVI; Thu, 12 Jul 2012 14:26:13 -0400 (EDT) Received: from riven.arriad.com (206.193.225.214.nauticom.net [206.193.225.214]) by mail.averesystems.com (Postfix) with ESMTPSA id 0268148028B; Thu, 12 Jul 2012 14:26:12 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: <20120712165502.GA61341@DataIX.net> Date: Thu, 12 Jul 2012 14:26:08 -0400 Content-Transfer-Encoding: 7bit Message-Id: <1AD62103-2ABF-4F07-B9EE-AD3EBF7024D5@averesystems.com> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> <20120712165502.GA61341@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1278) Cc: George Neville-Neil , Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 18:26:11 -0000 On Jul 12, 2012, at 12:55 PM, Jason Hellenthal wrote: > Something else to look into ... > > # ifconfig lagg0 mtu 1492 > ifconfig: ioctl (set mtu): Invalid argument > > This is on stable/8 r238264 when the interface was up/up and down/down > > Also attempted on the member interfaces dc0 and dc1 It's disabled by default, but I don't know why. This seems to work for us. -Andrew Index: sys/net/if_lagg.c =================================================================== --- sys/net/if_lagg.c (revision 238402) +++ sys/net/if_lagg.c (working copy) @@ -752,8 +752,18 @@ break; case SIOCSIFMTU: - /* Do not allow the MTU to be changed once joined */ - error = EINVAL; + LAGG_WLOCK(sc); + SLIST_FOREACH(lp, &sc->sc_ports, lp_entries) { + if (!error) { + /* Call the base ioctl for each port */ + error = (*lp->lp_ioctl)(lp->lp_ifp, cmd, data); + } + } + if (!error) { + /* Update the aggregate MTU */ + sc->sc_ifp->if_mtu = ifr->ifr_mtu; + } + LAGG_WUNLOCK(sc); break; default: -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 18:28:20 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 88C9B106566B; Thu, 12 Jul 2012 18:28:19 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 67B5014F981; Thu, 12 Jul 2012 18:28:18 +0000 (UTC) Message-ID: <4FFF1742.9010906@FreeBSD.org> Date: Thu, 12 Jul 2012 11:28:18 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Neville-Neil References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 18:28:20 -0000 While y'all are looking at MTU (which is an increasingly important topic as we move into a Gig+ world) I'm wondering what our support is for https://tools.ietf.org/html/rfc4821 ?? I asked this a while back and never got an answer. This method of PMTUD is really important given the massive (stupid) brokenness of people routinely blocking all of ICMPv4. Doug From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 20:41:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AF991065752 for ; Thu, 12 Jul 2012 20:41:46 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 32E818FC08 for ; Thu, 12 Jul 2012 20:41:46 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q6CKfdgn037093 for ; Thu, 12 Jul 2012 13:41:39 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4FFF3683.7020107@rawbw.com> Date: Thu, 12 Jul 2012 13:41:39 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120702 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:41:46 -0000 I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in /etc/rc.conf. When the system boots, it gets connected fine. Now, I disconnect my laptop and connect it to another network. When cable is disconnected, IP address of this interface stays the same, old one is not removed. When I plug it into another network, the same IP address stays. New IP doesn't get set. This is bad. So I have to manually do 'ifconfig re0 down && remove && ifconfig re0 up'. I believe, once interface is set as "DHCP", all those things should happen automatically. dhclient should drop the old IP when cable is unplugged, and should set it up anew when cable is plugged back. Is my system misconfigured in some way, or this is the way how it works in FreeBSD? Yuri From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 20:49:29 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3E59106566C; Thu, 12 Jul 2012 20:49:29 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 62B2E8FC19; Thu, 12 Jul 2012 20:49:29 +0000 (UTC) Received: from [209.249.190.124] (port=52002 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SpQK9-0005CN-6B; Thu, 12 Jul 2012 16:49:23 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20120712165502.GA61341@DataIX.net> Date: Thu, 12 Jul 2012 16:49:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <096E1D9F-6F88-4063-B59C-34E94E17138D@freebsd.org> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> <20120712165502.GA61341@DataIX.net> To: Jason Hellenthal X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:49:29 -0000 On Jul 12, 2012, at 12:55 , Jason Hellenthal wrote: >=20 >=20 > On Thu, Jul 12, 2012 at 10:55:16AM -0400, George Neville-Neil wrote: >>=20 >> On Jul 11, 2012, at 17:57 , Navdeep Parhar wrote: >>=20 >>> On 07/11/12 14:30, gnn@freebsd.org wrote: >>>> Howdy, >>>>=20 >>>> Does anyone know the reason for this particular check in >>>> ip_output.c? >>>>=20 >>>> if (rte !=3D NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { >>>> /* >>>> * This case can happen if the user changed the MTU >>>> * of an interface after enabling IP on it. Because >>>> * most netifs don't keep track of routes pointing to >>>> * them, there is no way for one to update all its >>>> * routes when the MTU is changed. >>>> */ >>>> if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) >>>> rte->rt_rmx.rmx_mtu =3D ifp->if_mtu; >>>> mtu =3D rte->rt_rmx.rmx_mtu; >>>> } else { >>>> mtu =3D ifp->if_mtu; >>>> } >>>>=20 >>>> To my mind the > ought to be !=3D so that any change, up or down, = of the >>>> interface MTU is eventually reflected in the route. Also, this = code >>>> does not check if it is both a HOST route and UP, but only if it is >>>> one other the other, so don't be fooled by that, this check happens >>>> for any route we have if it's up. >>>=20 >>> I believe rmx_mtu could be low due to some intermediate node between = this host and the final destination. An increase in the MTU of the = local interface should not increase the path MTU if the limit was due to = someone else along the route. >>=20 >> Yes, it turns out to be complex. We have several places that store = the MTU. There is the interface, >> which knows the MTU of the directly connected link, a route, and the = host cache. All three of these >> are used to determine the maximum segment size (MSS) of a TCP packet. = The route and the interface >> determine the maximum MTU that the MSS can have, but, if there is an = entry in the host cache >> then it is preferred over either of the first two. See = tcp_update_mss() in tcp_input.c to >> see what I'm talking about. >>=20 >> I believe that the quoted code above has been wrong from the day it = was written, in that what it >> really says is "if the route is up" and not "if the route is up and = is a host route" which is >> what I believe people to read that as. If the belief is that this = code is really only there for >> hosts routes, then the proper fix is to make the sense of the first = if match that belief >> and, again, to change the > to !=3D so that when the administrator of = the box bumps the MTU in >> either direction that the route reflects this. It is not possible = for PMTU on a single link >> to a host route to bump the number down if the interface says it's = not to be bumped. And, >> even so, any host cache entry will override and avoid this code. >>=20 >=20 > Something else to look into ...=20 >=20 > # ifconfig lagg0 mtu 1492 > ifconfig: ioctl (set mtu): Invalid argument >=20 > This is on stable/8 r238264 when the interface was up/up and down/down >=20 > Also attempted on the member interfaces dc0 and dc1 >=20 Can you file a bug on that one? Best, George From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 20:50:52 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BBE81065679; Thu, 12 Jul 2012 20:50:52 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5468FC16; Thu, 12 Jul 2012 20:50:52 +0000 (UTC) Received: from [209.249.190.124] (port=52005 helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SpQLa-0006hW-JB; Thu, 12 Jul 2012 16:50:50 -0400 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=iso-8859-1 From: George Neville-Neil In-Reply-To: <4FFF1742.9010906@FreeBSD.org> Date: Thu, 12 Jul 2012 16:50:53 -0400 Content-Transfer-Encoding: 7bit Message-Id: <4C0DD966-6B60-4ADF-8476-D3C0CB3FC1C3@freebsd.org> References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> <4FFF1742.9010906@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:50:52 -0000 On Jul 12, 2012, at 14:28 , Doug Barton wrote: > While y'all are looking at MTU (which is an increasingly important topic > as we move into a Gig+ world) I'm wondering what our support is for > https://tools.ietf.org/html/rfc4821 ?? I asked this a while back and > never got an answer. > > This method of PMTUD is really important given the massive (stupid) > brokenness of people routinely blocking all of ICMPv4. We do not support that RFC and support in other OSs is quite limited. It does not seem to be have been taken up by the Internet community in general. That being said, it is an interesting mechanism. Probably not a bad idea for a wish list item. Best, George From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 20:52:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF24106564A for ; Thu, 12 Jul 2012 20:52:01 +0000 (UTC) (envelope-from chris.benesch@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 930EA8FC0C for ; Thu, 12 Jul 2012 20:52:01 +0000 (UTC) Received: by ggnm2 with SMTP id m2so3354060ggn.13 for ; Thu, 12 Jul 2012 13:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IaI1AuvUQuy4YgF5oCrWZ4nMp5u0xQcYEUgAPocUBSQ=; b=ud0MsZCSJ4fYe/v1l3cw6/Vx/wvNiyTkNiTYZrx9e34//BcVPLv3/gG8IHAcAESPQl gsO1M5smd44B2TKHlshf9qfIXuoLo46RDsIcTFyXXWg0BI5C1BW9Ruzj74br1avC5gGE WvDdp2pVSPY9g0Ixx5BPcEuDAwPwT2gX5qRsdU7+xSlP6AcRZQFfsd/sHVv7lw+6Vtst zW9QuXkXHAHHpMKyyuuPS0qiUVc6M/P1S+yk8ZvrOAux3vem+oa2xDme53XBgPwpM36c Oc5WfgWk0XJsWQuO7MGgUTbWDhHcic0oLqmM09pehOxUBkEGGdeCs2b/7MY2Q6+Jg+gt nd0Q== MIME-Version: 1.0 Received: by 10.50.220.129 with SMTP id pw1mr18899345igc.29.1342126320987; Thu, 12 Jul 2012 13:52:00 -0700 (PDT) Received: by 10.231.26.150 with HTTP; Thu, 12 Jul 2012 13:52:00 -0700 (PDT) In-Reply-To: <4FFF3683.7020107@rawbw.com> References: <4FFF3683.7020107@rawbw.com> Date: Thu, 12 Jul 2012 13:52:00 -0700 Message-ID: From: Chris Benesch To: Yuri Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:52:01 -0000 Thats pretty standard for BSD and most Unixes. DHCP hands out leases for a specified period of time, so unless there is a reason to reset it, it wont. Windows does that, but it is designed more as a client / user facing OS whereas BSD is designed to run in the background silently serving you content and directing traffic. I can save you some steps though, ps -ax | grep dhclient You will get a list, on the one that is dhclient or /sbin/dhclient, take the number at the far left, thats the process ID kill dhclient re0 That will force it to acquire a new address. On Thu, Jul 12, 2012 at 1:41 PM, Yuri wrote: > I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in > /etc/rc.conf. > > When the system boots, it gets connected fine. > > Now, I disconnect my laptop and connect it to another network. > When cable is disconnected, IP address of this interface stays the same, > old one is not removed. > When I plug it into another network, the same IP address stays. New IP > doesn't get set. This is bad. > So I have to manually do 'ifconfig re0 down && remove && ifconfig > re0 up'. > > I believe, once interface is set as "DHCP", all those things should happen > automatically. dhclient should drop the old IP when cable is unplugged, and > should set it up anew when cable is plugged back. > > Is my system misconfigured in some way, or this is the way how it works in > FreeBSD? > > Yuri > ______________________________**_________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org > " > From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 21:00:04 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 32FAC106566C; Thu, 12 Jul 2012 21:00:04 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9C81E14FD80; Thu, 12 Jul 2012 21:00:03 +0000 (UTC) Message-ID: <4FFF3AD3.50703@FreeBSD.org> Date: Thu, 12 Jul 2012 14:00:03 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: George Neville-Neil References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org> <4FFF1742.9010906@FreeBSD.org> <4C0DD966-6B60-4ADF-8476-D3C0CB3FC1C3@freebsd.org> In-Reply-To: <4C0DD966-6B60-4ADF-8476-D3C0CB3FC1C3@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Navdeep Parhar , net@freebsd.org Subject: Re: Interface MTU question... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 21:00:04 -0000 On 07/12/2012 01:50 PM, George Neville-Neil wrote: > > On Jul 12, 2012, at 14:28 , Doug Barton wrote: > >> While y'all are looking at MTU (which is an increasingly important topic >> as we move into a Gig+ world) I'm wondering what our support is for >> https://tools.ietf.org/html/rfc4821 ?? I asked this a while back and >> never got an answer. >> >> This method of PMTUD is really important given the massive (stupid) >> brokenness of people routinely blocking all of ICMPv4. > > We do not support that RFC and support in other OSs is quite limited. > It does not seem to be have been taken up by the Internet community > in general. > > That being said, it is an interesting mechanism. Probably not a bad idea > for a wish list item. Thanks for the response. Doug From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 21:01:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C95E1065722 for ; Thu, 12 Jul 2012 21:01:53 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id BE6AD8FC16 for ; Thu, 12 Jul 2012 21:01:52 +0000 (UTC) Received: by lbon10 with SMTP id n10so4674586lbo.13 for ; Thu, 12 Jul 2012 14:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=56M+gULvHOt/X0rlaMMkStr6bwpXV1JLoxSw+0N3sqg=; b=rbtkWfLsB69xIMRoVpRt500/mgsKPwUgXU1HdDEJ+MuGWGARQvGJ4kkCDGYcjk0Y3m nfXwC8hARgjb8Zl50kUGDFXtH1Gup7ZwRDaDCb7OEcn3X+FxTOH7jP49vKaRjGOsS/BR MprK41XfM2Ok+veECVzTnujO6Fgs8M2W2h5qqyi/8XjUO1Ci6H47dsLPqcWfkArzShDy SNZ+LOmrxQVg27plup/at0bdik7vTNz9m4vPm5ol12eSmAOJrWsrG218ARjTvOyXgMDc KWZjEesZOhxzAE/WV7XMbOO3EG+3Sai76hen/JQFox/Yxs9H5dPu687yVaUXbGL1HBS6 fm8w== MIME-Version: 1.0 Received: by 10.112.42.41 with SMTP id k9mr1852516lbl.90.1342126911563; Thu, 12 Jul 2012 14:01:51 -0700 (PDT) Received: by 10.114.37.74 with HTTP; Thu, 12 Jul 2012 14:01:51 -0700 (PDT) In-Reply-To: References: <4FFF3683.7020107@rawbw.com> Date: Thu, 12 Jul 2012 14:01:51 -0700 Message-ID: From: Freddie Cash To: Chris Benesch Content-Type: text/plain; charset=UTF-8 Cc: Yuri , freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 21:01:53 -0000 On Thu, Jul 12, 2012 at 1:52 PM, Chris Benesch wrote: > Thats pretty standard for BSD and most Unixes. DHCP hands out leases for a > specified period of time, so unless there is a reason to reset it, it > wont. Windows does that, but it is designed more as a client / user facing > OS whereas BSD is designed to run in the background silently serving you > content and directing traffic. > > I can save you some steps though, > > ps -ax | grep dhclient > > You will get a list, on the one that is dhclient or /sbin/dhclient, take > the number at the far left, thats the process ID > > kill > dhclient re0 pkill dhclient dhclient re0 Saves a few more steps. :) There's also: service netif restart re0 -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 21:08:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 45FFF1065673 for ; Thu, 12 Jul 2012 21:08:25 +0000 (UTC) (envelope-from chris.benesch@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EF9548FC0A for ; Thu, 12 Jul 2012 21:08:24 +0000 (UTC) Received: by ggnm2 with SMTP id m2so3373202ggn.13 for ; Thu, 12 Jul 2012 14:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RHudipzh/hW9e/+6CV0b9u8LS2yHDrfQHNtMNu20Vb4=; b=tye46rGrJzMZZyzRbZREOnIMI9Mu7QmW4uGXdL6iZ1AWTlg5Z8uFzhuLmeBQnxrd// xGbApjDTfb+XWEiKBAFTSLNWkaKPWxjg9t5HLQesdqfMqPxhqVgktKQT9mpe5x/PO4UX IoPTUi1rYl/lOtR0Sl0adXBmcd/J6K0hR9vR4WV6lGs11xQSUMJ9c2B+Pr7GIc+aLCg5 eASVNaKqHo4HB/kgVhlkcYP/YiEsXViDqZ0Bb1RGjUaGrAUhX/DkbiTn0B8nlwitc7wW fWq5Jx1lOvKeGWXlDbY6luDXedDTQMWx97d4FGD+Uz4P1m8NbBNh/cMX5tOmJ4o/u71L z0Ow== MIME-Version: 1.0 Received: by 10.50.169.73 with SMTP id ac9mr18925922igc.29.1342127304032; Thu, 12 Jul 2012 14:08:24 -0700 (PDT) Received: by 10.231.26.150 with HTTP; Thu, 12 Jul 2012 14:08:23 -0700 (PDT) In-Reply-To: References: <4FFF3683.7020107@rawbw.com> Date: Thu, 12 Jul 2012 14:08:23 -0700 Message-ID: From: Chris Benesch To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Yuri , freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 21:08:25 -0000 I work with an old version of AIX all day, there are no shortcuts :( On Thu, Jul 12, 2012 at 2:01 PM, Freddie Cash wrote: > On Thu, Jul 12, 2012 at 1:52 PM, Chris Benesch > wrote: > > Thats pretty standard for BSD and most Unixes. DHCP hands out leases > for a > > specified period of time, so unless there is a reason to reset it, it > > wont. Windows does that, but it is designed more as a client / user > facing > > OS whereas BSD is designed to run in the background silently serving you > > content and directing traffic. > > > > I can save you some steps though, > > > > ps -ax | grep dhclient > > > > You will get a list, on the one that is dhclient or /sbin/dhclient, take > > the number at the far left, thats the process ID > > > > kill > > dhclient re0 > > pkill dhclient > dhclient re0 > > Saves a few more steps. :) > > There's also: > > service netif restart re0 > > -- > Freddie Cash > fjwcash@gmail.com > From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 21:49:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DDB2106564A for ; Thu, 12 Jul 2012 21:49:05 +0000 (UTC) (envelope-from reichert@numachi.com) Received: from away.numachi.com (away.numachi.com [66.228.38.138]) by mx1.freebsd.org (Postfix) with SMTP id B5B828FC08 for ; Thu, 12 Jul 2012 21:49:04 +0000 (UTC) Received: (qmail 27819 invoked from network); 12 Jul 2012 21:42:22 -0000 Received: from unknown (HELO meisai.numachi.com) (72.71.241.47) by away.numachi.com with SMTP; 12 Jul 2012 21:42:22 -0000 Received: (qmail 40525 invoked by uid 1001); 12 Jul 2012 21:19:59 -0000 Date: Thu, 12 Jul 2012 17:19:59 -0400 From: Brian Reichert To: Freddie Cash Message-ID: <20120712211959.GG20201@numachi.com> References: <4FFF3683.7020107@rawbw.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Cc: Yuri , Chris Benesch , freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 21:49:05 -0000 On Thu, Jul 12, 2012 at 02:01:51PM -0700, Freddie Cash wrote: > There's also: > > service netif restart re0 Does devfs expose loss-of-link events? If so, one would think that one could script something that watches for link-up notifications... (I don't know about devfs anywhere near as much as I want to.) > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Brian Reichert BSD admin/developer at large From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 22:25:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D7171065673 for ; Thu, 12 Jul 2012 22:25:09 +0000 (UTC) (envelope-from chris.benesch@gmail.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id C14A78FC16 for ; Thu, 12 Jul 2012 22:25:08 +0000 (UTC) Received: by ghbz22 with SMTP id z22so3440903ghb.13 for ; Thu, 12 Jul 2012 15:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9xPwX7kFhS+WAmIHrzees5gkm7ADuEZ5XSvqESDR/7o=; b=rr8j59I1IcUgtUMKxPiWM/4Ty2kGhMDpKTSOFs9S49Ce2IK7QdwXyAnh2YsqLJylEO phgSqYnkVqiPN/2UseUe4ni2MUExbcLXlK5rhoAZEgTK5ovaEegaG7zFkzk6RJJHlz4E e9zxjUoDoG7NyJE7W7f4QEmsjJ5uEF1FyGTiFHW6pFBzLd52neCChLT5MUAyAEIhNI2E xy6flbR5nczwuADx1K4xINYkt3Wf4nX4QgiJG60eGU7YPTVe2FP4ARM7MJJnZk3EqBaw Pi94o6fYPvd0GBqEh40TsY9FCiPWD6ZSpwJCoRWnhxWvHHAfDbzIWYoda0ir7R0d/nOw Wfuw== MIME-Version: 1.0 Received: by 10.50.189.234 with SMTP id gl10mr19091378igc.59.1342131907996; Thu, 12 Jul 2012 15:25:07 -0700 (PDT) Received: by 10.231.26.150 with HTTP; Thu, 12 Jul 2012 15:25:07 -0700 (PDT) In-Reply-To: <20120712211959.GG20201@numachi.com> References: <4FFF3683.7020107@rawbw.com> <20120712211959.GG20201@numachi.com> Date: Thu, 12 Jul 2012 15:25:07 -0700 Message-ID: From: Chris Benesch To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 22:25:09 -0000 Maybe another option to dhclient to have it poll the interface every 2-3 seconds to see if it has lost a link and if so, set the lease timer to be expired, and wait for it to come back and once it does, it will acquire a new address. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 22:31:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DDDF106566C for ; Thu, 12 Jul 2012 22:31:29 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ03.datapipe-corp.net (exfesmq03.datapipe.com [64.27.120.67]) by mx1.freebsd.org (Postfix) with ESMTP id 37F4C8FC0C for ; Thu, 12 Jul 2012 22:31:27 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ03.datapipe-corp.net (192.168.128.28) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 12 Jul 2012 18:30:17 -0400 Date: Thu, 12 Jul 2012 17:30:37 -0500 From: "Paul A. Procacci" To: Chris Benesch Message-ID: <20120712223037.GD1907@nat.myhome> References: <4FFF3683.7020107@rawbw.com> <20120712211959.GG20201@numachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 22:31:29 -0000 On Thu, Jul 12, 2012 at 03:25:07PM -0700, Chris Benesch wrote: > Maybe another option to dhclient to have it poll the interface every 2-3 > seconds to see if it has lost a link and if so, set the lease timer to be > expired, and wait for it to come back and once it does, it will acquire a > new address. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" The Operating system should generate a devd event. Something like the following in /usr/local/etc/devd.conf should do the tric= k, though I haven't tested the below with anything other than carp interfaces. I suspect it works just the same. ###################################################### notify 30 { match "system" "IFNET"; match "subsystem" "em0_or_whatever"; match "type" "LINK_UP"; action "/usr/local/sbin/script_to_do_something.sh up"; }; notify 30 { match "system" "IFNET"; match "subsystem" "em0_or_whatever"; match "type" "LINK_DOWN"; action "/usr/local/sbin/script_to_do_something.sh down"; }; ###################################################### ~Paul ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 22:39:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6FD31065679 for ; Thu, 12 Jul 2012 22:39:41 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B0C458FC21 for ; Thu, 12 Jul 2012 22:39:41 +0000 (UTC) Received: by obbun3 with SMTP id un3so4788910obb.13 for ; Thu, 12 Jul 2012 15:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=R7KnRbXIE/exyjUUeLn27dhIBFgLRQm7W7C8pzPMpVE=; b=CIZj8EWxg5Cv0UppuBFI4td6XW3uabrf3ipOfZIpbChGqxOsAx1TSSjZ0C5AuwaPEs iJreG9oVreQC5gFLm3oPj85xSvEqyPSnK6JOAP3vK+3QObZ351ocge5Q0DLpZDBR1oMo ZHPLO4vVga3osqki6lledrI56VXi3+WJhMMshgqYVWKcnANYWqC1TS2CP781ofEZKcws n1FKHEVztaJvobixyzmu/M2Z/yiu/1LOsf5UWFECK7Kwc+ZJLRlYPZdOCpO02rs82/ll 67AEhwLUuJdHhvesXkgTVGyzEyNq5wxEzTIz5CHKk/0RpmCTNnXg/uQFgP3Jx/0lw/Jo ojCA== MIME-Version: 1.0 Received: by 10.182.47.9 with SMTP id z9mr20434294obm.58.1342132781352; Thu, 12 Jul 2012 15:39:41 -0700 (PDT) Received: by 10.182.73.232 with HTTP; Thu, 12 Jul 2012 15:39:41 -0700 (PDT) Date: Thu, 12 Jul 2012 15:39:41 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Broadcom NetXtreme BCM5719 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 22:39:42 -0000 Hi, I have an HP ProLiant DL360p Gen8 server in my possession for testing, and it appears the Broadcom NetXtreme BCM5719 doesn't yet have support. I noticed someone asking about server support on freebsd-questions last month, but it didn't garner much attention. Played around with 8.3-RELEASE, 8-STABLE and 9.1-BETA1 trees from yesterday and poked around the commits to ensure I wasn't missing anything. Everything appears to be functioning fine except for the NIC. bge0: mem 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq 32 at device 0.0 on pci3 bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E miibus0: on bge0 bge0: Ethernet Address: xx:xx:xx:xx:xx:xx ... bge0: watchdog timeout -- resetting bge0: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN bge0: link state changed to UP bge0: link state changed to DOWN ... bge0@pci:0:3:0:0: class=0x020000 card=0x169d103c chip=0x165714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' class = network subclass = ethernet Anything in the pipe on this one, or any access I can provide that might assist us? Jason From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 00:21:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57943106564A for ; Fri, 13 Jul 2012 00:21:57 +0000 (UTC) (envelope-from ihsan@grep.my) Received: from svc02-kul.b.n3labs.my (svc02-kul.b.n3labs.my [IPv6:2400:3700:10::61]) by mx1.freebsd.org (Postfix) with ESMTP id CDCC68FC0C for ; Fri, 13 Jul 2012 00:21:56 +0000 (UTC) Received: from [IPv6:2400:3700:49::9413:20ad:64e7:e873] (unknown [IPv6:2400:3700:49:0:9413:20ad:64e7:e873]) by svc02-kul.b.n3labs.my (Postfix) with ESMTPSA id 4CEEAC60230; Fri, 13 Jul 2012 08:21:54 +0800 (MYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ihsan Junaidi Ibrahim In-Reply-To: Date: Fri, 13 Jul 2012 08:21:31 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0FF9D20C-4D88-484F-AEB9-E6F10094E018@grep.my> References: <3AC8C112-A80B-4D8F-89DA-DA38E4AB524F@grep.my> To: Jack Vogel X-Mailer: Apple Mail (2.1278) Cc: freebsd-net@freebsd.org Subject: Re: Enable LRO by default on igb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 00:21:57 -0000 I did a quick file download test on the LRO-enabled device (forwarding = is turned on) and there's no perceive drop-off in forwarding = performance. The test is very unscientific (over the Internet) as I don't have access = to a local test bed where I can do more in-depth testing. Sysctl LRO stats gave me these: dev.igb.0.queue0.lro_queued: 53 dev.igb.0.queue0.lro_flushed: 53 dev.igb.0.queue1.lro_queued: 121 dev.igb.0.queue1.lro_flushed: 120 dev.igb.0.queue2.lro_queued: 14895 dev.igb.0.queue2.lro_flushed: 8200 dev.igb.0.queue3.lro_queued: 77 dev.igb.0.queue3.lro_flushed: 76 Just curious on why flushed and queued numbers did not seem to match. ihsan On Jul 8, 2012, at 12:26 AM, Jack Vogel wrote: > Because of problems with forwarding when it was turned on, however = this has > recently been fixed supposedly, if someone using the driver in an > environment > with forwarding could verify that there is no problem with it enabled = I'd > be happy > to change it to be on by default. >=20 > Jack >=20 >=20 > On Sat, Jul 7, 2012 at 9:01 AM, Ihsan Junaidi Ibrahim = wrote: >=20 >> Hi folks, >>=20 >> Just curious is there a reason why LRO isn't turned on by default for >> igb(4) like for other capabilities? >>=20 >> I have a couple of 82575EB igb devices and LRO had to be turned on >> manually. >>=20 >> Thanks._______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 01:42:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B848A106566C for ; Fri, 13 Jul 2012 01:42:57 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 384D08FC08 for ; Fri, 13 Jul 2012 01:42:56 +0000 (UTC) Received: from [127.0.0.1] (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id q6D1ghFH033275; Fri, 13 Jul 2012 09:42:44 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <1342143769.2250.3.camel@nsl> From: Kevin Lo To: Yuri Date: Fri, 13 Jul 2012 09:42:49 +0800 In-Reply-To: <4FFF3683.7020107@rawbw.com> References: <4FFF3683.7020107@rawbw.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 01:42:57 -0000 Yuri wrote: > I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in > /etc/rc.conf. > > When the system boots, it gets connected fine. > > Now, I disconnect my laptop and connect it to another network. > When cable is disconnected, IP address of this interface stays the same, > old one is not removed. > When I plug it into another network, the same IP address stays. New IP > doesn't get set. This is bad. > So I have to manually do 'ifconfig re0 down && remove && > ifconfig re0 up'. > > I believe, once interface is set as "DHCP", all those things should > happen automatically. dhclient should drop the old IP when cable is > unplugged, and should set it up anew when cable is plugged back. > > Is my system misconfigured in some way, or this is the way how it works > in FreeBSD? Add the following lines to /etc/devd.conf: notify 0 { match "system" "IFNET"; match "type" "LINK_DOWN"; media-type "ethernet"; action "/etc/rc.d/dhclient quietstop $subsystem; ifconfig $subsystem inet 0.0.0.0"; }; Then restart devd(8). > Yuri Kevin From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 06:02:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63C6F1065672 for ; Fri, 13 Jul 2012 06:02:58 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0F00F8FC08 for ; Fri, 13 Jul 2012 06:02:57 +0000 (UTC) Received: from bsdrookie.norma.com. ([IPv6:fd00::7fc]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q6D62r9d071170 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 13 Jul 2012 12:02:55 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4FFFBA0D.7080505@norma.perm.ru> Date: Fri, 13 Jul 2012 12:02:53 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0) Gecko/20111001 Thunderbird/7.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Fri, 13 Jul 2012 12:02:55 +0600 (YEKT) X-Spam-Status: No hits=-97.8 bayes=0.5 testhits RDNS_NONE=1.274, SPF_SOFTFAIL=0.972,USER_IN_WHITELIST=-100 autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: Broadcom NetXtreme BCM5719 support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 06:02:58 -0000 Hi. On 13.07.2012 04:39, Jason Wolfe wrote: > bge0: mem > 0xf6bf0000-0xf6bfffff,0xf6be0000-0xf6beffff,0xf6bd0000-0xf6bdffff irq > 32 at device 0.0 on pci3 > bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > miibus0: on bge0 > bge0: Ethernet Address: xx:xx:xx:xx:xx:xx > ... > bge0: watchdog timeout -- resetting > bge0: link state changed to UP > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: link state changed to DOWN > bge0: link state changed to UP > bge0: link state changed to DOWN > ... > > > bge0@pci:0:3:0:0: class=0x020000 card=0x169d103c chip=0x165714e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme BCM5719 Gigabit Ethernet PCIe' > class = network > subclass = ethernet > > Anything in the pipe on this one, or any access I can provide that > might assist us? > I got a BMC5722 chip (and IBM x3250 mX systems), but same stuff with timeout/resets. I can say 8.1/8.2 were more stable concerning bge(4). You could try to switch off tso and vlanhwtso, at least it did the trick for me (did it ? not sure though. I was having problems one a month on 8.1/8.2, after upgrading to 8.3-STABLE I start having problems with it every day, literally, after ifconfig bge0 -tso -vlanhwtso it's running for 5 day now.) Eugene. From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 06:35:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 459D5106564A for ; Fri, 13 Jul 2012 06:35:32 +0000 (UTC) (envelope-from js@alien8.de) Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:120:8448::d00d]) by mx1.freebsd.org (Postfix) with ESMTP id BFEC78FC08 for ; Fri, 13 Jul 2012 06:35:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTP id 43EF81D9C1C; Fri, 13 Jul 2012 08:35:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1342161330; bh=nzYLmyTyMRrfaEGI3bAJiwj0fFM83iIV52p6BcR8Hfk=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=NG R+ow8XqC5LDHBhp57Uc8ObLfSOOxcOPgReFDSmk7WlfAxVusdz9053jrOmqQaZ/pMum wvDfs2ewih96DtfH7WyecVowhGK2d3u7V4STL9Ao4rVPX7wMR87Oz0ZA2MpvqL0SBR1 PbtT6lBXQp1SalF+z0TGRxkAJocF+R0QKdQ= X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 70-cP-CyiNoi; Fri, 13 Jul 2012 08:35:30 +0200 (CEST) Received: from [192.168.0.13] (unknown [108.161.21.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 49A851D9C1A; Fri, 13 Jul 2012 08:35:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1342161330; bh=nzYLmyTyMRrfaEGI3bAJiwj0fFM83iIV52p6BcR8Hfk=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:CC:Message-ID; b=NG R+ow8XqC5LDHBhp57Uc8ObLfSOOxcOPgReFDSmk7WlfAxVusdz9053jrOmqQaZ/pMum wvDfs2ewih96DtfH7WyecVowhGK2d3u7V4STL9Ao4rVPX7wMR87Oz0ZA2MpvqL0SBR1 PbtT6lBXQp1SalF+z0TGRxkAJocF+R0QKdQ= User-Agent: Kaiten Mail In-Reply-To: References: <1341718291.13585.15.camel@tabernacle> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Julian Stecklina Date: Thu, 12 Jul 2012 23:35:22 -0700 To: George Neville-Neil Message-ID: <1aab1c9f-5e09-47dd-91c3-cac1b6750e76@email.android.com> Cc: freebsd-net@freebsd.org Subject: Re: TCP Regression Test Suite X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 06:35:32 -0000 George Neville-Neil wrote: > >On Jul 7, 2012, at 23:31 , Julian Stecklina wrote: > >> Hello, >> >> do you know of a TCP regression test suite with IPv6 support? >> > >Alas, not a good one. And bad ones? ;-) -- Sent from my phone. Please excuse my brevity. From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 07:57:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23BDD106564A for ; Fri, 13 Jul 2012 07:57:57 +0000 (UTC) (envelope-from yerenkow@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id A399A8FC15 for ; Fri, 13 Jul 2012 07:57:57 +0000 (UTC) Received: by obbun3 with SMTP id un3so5545974obb.13 for ; Fri, 13 Jul 2012 00:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cWrIWuE2/SucDUf2Gt8nA5r7U0TW0GuEEfFLRtYugYM=; b=arNRLX4yNd5N6VZfU8ZWcUeepdcTTGb26RyoNNBXDvHbTxyv5UYIa3CfNf+AiKnc4W qUYIk4zCPPBMgCWkzKC0C1bLuaZRZEQhKsIq75b3tzhMcjnFTJdiLwNErO5Jjm8TTKWb Y4YpkEd9Oviu2NA6wZIjLMRaqgsmwBwVCOwTGbcVafERbBOevgfCM05vzXGm439KSyOm m3tPvX7qwRxdzOTvvaVw0pri2BDfBtG9unSjPrafZKDB7t/yC7SHnvjQRpRvfsXB6Dkc hfMbNKFmlbVfRZn5d2eXl9eeC2yaDiZCY7R7gkM8ppgS3JjAw1QeblRaGhH93H1w144Y srKQ== MIME-Version: 1.0 Received: by 10.182.207.39 with SMTP id lt7mr117208obc.67.1342166277127; Fri, 13 Jul 2012 00:57:57 -0700 (PDT) Received: by 10.182.32.234 with HTTP; Fri, 13 Jul 2012 00:57:57 -0700 (PDT) In-Reply-To: <1342143769.2250.3.camel@nsl> References: <4FFF3683.7020107@rawbw.com> <1342143769.2250.3.camel@nsl> Date: Fri, 13 Jul 2012 10:57:57 +0300 Message-ID: From: Alexander Yerenkow To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 07:57:58 -0000 > > Add the following lines to /etc/devd.conf: > > notify 0 { > match "system" "IFNET"; > match "type" "LINK_DOWN"; > media-type "ethernet"; > action "/etc/rc.d/dhclient quietstop $subsystem; ifconfig > $subsystem inet 0.0.0.0"; > }; > > Then restart devd(8). > 1. Is this rule will do nothing if interface wasn't configured as DHCP? 2. Can such primer be added (but commented) to /etc/devd.conf in CURRENT, so FreeBSD will be a bit more flexible for all kind of users? -- Regards, Alexander Yerenkow From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 09:48:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 805F11065670 for ; Fri, 13 Jul 2012 09:48:41 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 109358FC0C for ; Fri, 13 Jul 2012 09:48:40 +0000 (UTC) Received: from server.rulingia.com (c220-239-248-69.belrs5.nsw.optusnet.com.au [220.239.248.69]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q6D9mbK8043249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Jul 2012 19:48:38 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q6D9mVZ7084509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jul 2012 19:48:31 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q6D9mU0N084508; Fri, 13 Jul 2012 19:48:30 +1000 (EST) (envelope-from peter) Date: Fri, 13 Jul 2012 19:48:30 +1000 From: Peter Jeremy To: Yuri Message-ID: <20120713094830.GA83006@server.rulingia.com> References: <4FFF3683.7020107@rawbw.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <4FFF3683.7020107@rawbw.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 09:48:41 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Jul-12 13:41:39 -0700, Yuri wrote: >I have the simplest possible DHCP setup: ifconfig_re0=3D"DHCP" in=20 >/etc/rc.conf. > >When the system boots, it gets connected fine. > >Now, I disconnect my laptop and connect it to another network. >When cable is disconnected, IP address of this interface stays the same,= =20 >old one is not removed. >When I plug it into another network, the same IP address stays. New IP=20 >doesn't get set. This is bad. >So I have to manually do 'ifconfig re0 down && remove &&=20 >ifconfig re0 up'. This is a bug in dhclient - see PR bin/166656, which includes a fix. --=20 Peter Jeremy --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk//7u4ACgkQ/opHv/APuIf4qgCfQpqwfKmBkg0mI8mZAWdH1IMd R9gAn1WjcuJ3IBIaLpVgJq3xLJXZVNWX =hKmm -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 12:44:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B094106564A; Fri, 13 Jul 2012 12:44:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E43518FC0C; Fri, 13 Jul 2012 12:44:20 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4ED68B94A; Fri, 13 Jul 2012 08:44:20 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Fri, 13 Jul 2012 08:41:23 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <4FFF3683.7020107@rawbw.com> <20120713094830.GA83006@server.rulingia.com> In-Reply-To: <20120713094830.GA83006@server.rulingia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207130841.23528.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 13 Jul 2012 08:44:20 -0400 (EDT) Cc: Yuri , Brooks Davis , Peter Jeremy Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 12:44:21 -0000 [ Adding Brooks, IIRC, he imported the current dhclient ] On Friday, July 13, 2012 5:48:30 am Peter Jeremy wrote: > On 2012-Jul-12 13:41:39 -0700, Yuri wrote: > >I have the simplest possible DHCP setup: ifconfig_re0="DHCP" in > >/etc/rc.conf. > > > >When the system boots, it gets connected fine. > > > >Now, I disconnect my laptop and connect it to another network. > >When cable is disconnected, IP address of this interface stays the same, > >old one is not removed. > >When I plug it into another network, the same IP address stays. New IP > >doesn't get set. This is bad. > >So I have to manually do 'ifconfig re0 down && remove && > >ifconfig re0 up'. > > This is a bug in dhclient - see PR bin/166656, which includes a fix. I think this is the correct answer. Brooks, can you look at the PR and patch? If you are busy I can commit it if you give the ok. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 17:54:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD5A81065670 for ; Fri, 13 Jul 2012 17:54:50 +0000 (UTC) (envelope-from reese@myri.com) Received: from myri.com (rrcs-24-43-81-194.west.biz.rr.com [24.43.81.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9618FC0C for ; Fri, 13 Jul 2012 17:54:50 +0000 (UTC) Received: from ssl-tls.localdomain (ssl-tls.myri-local.com [172.31.0.162]) by myri.com (8.13.7+Sun/8.13.7) with ESMTP id q6DHsoaG028159 for ; Fri, 13 Jul 2012 10:54:50 -0700 (PDT) Received: from [172.31.195.150] (unknown [172.31.195.150]) by ssl-tls.localdomain (Postfix) with ESMTP id 34DEDD0D6CD for ; Fri, 13 Jul 2012 10:54:50 -0700 (PDT) Message-ID: <500060DB.3090407@myri.com> Date: Fri, 13 Jul 2012 10:54:35 -0700 From: Reese Faucette User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4FFF9E48.6000403@myri.com> In-Reply-To: <4FFF9E48.6000403@myri.com> X-Forwarded-Message-Id: <4FFF9E48.6000403@myri.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: question in tcp_do_segment() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 17:54:50 -0000 Hi, freebsd-net- I don't have a testcase for this at the moment, but there's a test in tcp_do_segment that looks backwards to me... http://svnweb.freebsd.org/base/release/9.0.0/sys/netinet/tcp_input.c?view=markup line 2398 - if (!tcp_timer_active(tp, TT_REXMT) || th->th_ack != tp->snd_una) tp->t_dupacks = 0; says "If we get a DUP ack and the retransmit timer is NOT fired, then ignore it and reset DUP ACK count." Isn't that exactly backwards? I could see ignoring the DUP ACK if we know the retransmit timer HAS fired, and we don't want to interfere with its retransmission efforts. The way the code is written now, as far as I can see, completely defeats retransmission based on DUP acks. I accidentally ran across this by breaking the timer, so that the retransmit timer never fires, and my streams get stuck, even with plenty of DUP ACKs. Am I missing something, or should that "!" go ? Thanks, Reese Faucette Myricom, Inc. From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 18:20:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13ED106566B for ; Fri, 13 Jul 2012 18:20:39 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id AF9AE8FC0A for ; Fri, 13 Jul 2012 18:20:39 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q6DIKbb1006540; Fri, 13 Jul 2012 11:20:39 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <500066F4.2030102@rawbw.com> Date: Fri, 13 Jul 2012 11:20:36 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120702 Thunderbird/13.0.1 MIME-Version: 1.0 To: Peter Jeremy References: <4FFF3683.7020107@rawbw.com> <20120713094830.GA83006@server.rulingia.com> In-Reply-To: <20120713094830.GA83006@server.rulingia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 18:20:40 -0000 On 07/13/2012 02:48, Peter Jeremy wrote: > This is a bug in dhclient - see PR bin/166656, which includes a fix. I think this PR addresses part of the problem: dhclient doesn't exit when the link goes down. But even if it exits, it leaves the IP address that it has set, which is wrong. This IP address survives through the next DHCP setup process and ends up being the second IP address. Should be very easy to on exit remove any IP address that was set during dhclient process lifetime. Yuri From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 18:23:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C66106566B; Fri, 13 Jul 2012 18:23:14 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8898FC0A; Fri, 13 Jul 2012 18:23:14 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id q6DILw4E013639; Fri, 13 Jul 2012 13:21:58 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id q6DILu8x013638; Fri, 13 Jul 2012 13:21:56 -0500 (CDT) (envelope-from brooks) Date: Fri, 13 Jul 2012 13:21:56 -0500 From: Brooks Davis To: John Baldwin Message-ID: <20120713182156.GB89895@lor.one-eyed-alien.net> References: <4FFF3683.7020107@rawbw.com> <20120713094830.GA83006@server.rulingia.com> <201207130841.23528.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <201207130841.23528.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, Peter Jeremy , Yuri Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jul 2012 18:23:14 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 13, 2012 at 08:41:23AM -0400, John Baldwin wrote: > [ Adding Brooks, IIRC, he imported the current dhclient ] >=20 > On Friday, July 13, 2012 5:48:30 am Peter Jeremy wrote: > > On 2012-Jul-12 13:41:39 -0700, Yuri wrote: > > >I have the simplest possible DHCP setup: ifconfig_re0=3D"DHCP" in=20 > > >/etc/rc.conf. > > > > > >When the system boots, it gets connected fine. > > > > > >Now, I disconnect my laptop and connect it to another network. > > >When cable is disconnected, IP address of this interface stays the sam= e,=20 > > >old one is not removed. > > >When I plug it into another network, the same IP address stays. New IP= =20 > > >doesn't get set. This is bad. > > >So I have to manually do 'ifconfig re0 down && remove &&=20 > > >ifconfig re0 up'. > >=20 > > This is a bug in dhclient - see PR bin/166656, which includes a fix. >=20 > I think this is the correct answer. Brooks, can you look at the PR and p= atch? =20 > If you are busy I can commit it if you give the ok. That seems fine to me. Feel free to commit. -- Brooks --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFQAGdEXY6L6fI4GtQRAlMpAJ9slvaJFgUMRdBCLtcf8oM2lawaZQCgnTUC fFwHK3lPMuJq5b+c2G5fIUI= =5cwz -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 07:51:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2807E1065741 for ; Sat, 14 Jul 2012 07:51:33 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id DE6598FC08 for ; Sat, 14 Jul 2012 07:51:32 +0000 (UTC) Received: by yhfs35 with SMTP id s35so5074741yhf.13 for ; Sat, 14 Jul 2012 00:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=12hSALWjFP1E7DYHhVbuh/BDGLPh3fUUXBqCil81vbw=; b=GzN5RTVOsJVhnDxYrO76jNZNG7USiesZr78CJ08wigSNjkdbjYoxryMiMnum/OnboX 5Bd2rQGEzIayKAYC16AfARvnII7qiUSbco/sJcJhZW2M4Lr5aGufij2DcxUSVGi0B7A1 g1kHxUTn2ohY6bNDYtpAtoV5rLnZeLcZwOuUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=12hSALWjFP1E7DYHhVbuh/BDGLPh3fUUXBqCil81vbw=; b=VDyfrS78/H4M0E9B9bYA4vbP9KvyVIPcTI5Lhe3rq0044UZR8jxQdMCwjNrTHuH0gw CqPrOJGU3/jEFnx9nrFSeXUOuT2RUe5UUFuU38PbslcMjZHq3/3JSYM6aJtzxjr87pb3 NMyymfrUNsHfgN5Rmpn3xSOJXQIV7mxnEaEdF3onoLilgWcnD1JrpjXyfZo3GI1sPSvH 5gYcVLXYkOCvj3UsSS3klS1mYftgFMRMPy4ne5/8spDAvDd+g3XcuvYDa4bu73jg+o2N oa56bqr3uqY/qY7EkGXPXXk/a9vefhwql3jH9Vgsw3yV5Y0I3aGtZ1M0d7wTfKYktNOI bW/Q== Received: by 10.42.146.6 with SMTP id h6mr2407538icv.53.1342252291907; Sat, 14 Jul 2012 00:51:31 -0700 (PDT) Received: from DataIX.net ([99.109.124.107]) by mx.google.com with ESMTPS id z7sm3461633igb.3.2012.07.14.00.51.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 Jul 2012 00:51:31 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q6E7pSig000992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2012 03:51:28 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jh@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q6E7pQXi000991; Sat, 14 Jul 2012 03:51:26 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Sat, 14 Jul 2012 03:51:25 -0400 From: Jason Hellenthal To: Yuri Message-ID: <20120714075125.GA566@DataIX.net> References: <4FFF3683.7020107@rawbw.com> <20120713094830.GA83006@server.rulingia.com> <500066F4.2030102@rawbw.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <500066F4.2030102@rawbw.com> X-Gm-Message-State: ALoCoQl+YlQill4nI3RmBetbz9vi9wjeAcOWOripeV1ygegmEUbIneTh6nxr4ZNUQsxF9cPU2FK5 Cc: freebsd-net@freebsd.org, Peter Jeremy Subject: Re: System doesn't detect unplugged network cable and doesn't set interface up properly with DHCP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 07:51:36 -0000 On Fri, Jul 13, 2012 at 11:20:36AM -0700, Yuri wrote: > On 07/13/2012 02:48, Peter Jeremy wrote: > > This is a bug in dhclient - see PR bin/166656, which includes a fix. > > I think this PR addresses part of the problem: dhclient doesn't exit when the link goes down. To the best of my knowledge this is the correct way to handle this. Why not reuse whats already been set if the link was to be brought back up ? ofcourse it should obviously change to the correct IP if another was negotiated but that is rarely the case. > But even if it exits, it leaves the IP address that it has set, which is wrong. This IP address survives through the next DHCP setup process and ends up being the second IP address. > Should be very easy to on exit remove any IP address that was set during dhclient process lifetime. I couldnt agree more. Interface tear down is definately needed here. -- - (2^(N-1)) From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 15:02:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 350DB1065674; Sat, 14 Jul 2012 15:02:56 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BBD5B8FC17; Sat, 14 Jul 2012 15:02:55 +0000 (UTC) Received: by obbun3 with SMTP id un3so8132919obb.13 for ; Sat, 14 Jul 2012 08:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VryotWPWr1mHddqTVJXypVik/91q3EenXa4jfNbX4VA=; b=nTk29Fw9C4B6Dky8616T7AbHCKLffPJiMoIifp+smK5w60W7Jd21zUcjdRioY4+329 zUeIlrU5nJVoPC36HWdh6roU2dZiZLXZ42IvAU1LBQTEG6CnRCunh9vOW9axuN/sg8JG y0ICbF+HYp4BatiZH3UaMlbKIuzsBXs/zHN0oQtKV6EhsHIRABBhhk6o5UXdA/yD9L+X wKY+itAtkwb0bLVZPB04GTtad3nQxy8Bho6ZwY3/JJeV6QozJLlKfJe9rqMCEOGLHuM3 woV7zJnyKaRF67YY6oJCnc0OnkInnzC04Otroa93n5AQmqai4q5yYwln/nxt4jNbOLLn QLPA== MIME-Version: 1.0 Received: by 10.182.232.101 with SMTP id tn5mr7122525obc.49.1342278175309; Sat, 14 Jul 2012 08:02:55 -0700 (PDT) Received: by 10.182.124.101 with HTTP; Sat, 14 Jul 2012 08:02:55 -0700 (PDT) In-Reply-To: References: Date: Sat, 14 Jul 2012 18:02:55 +0300 Message-ID: From: Sami Halabi To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Luigi Rizzo , freebsd-net@freebsd.org, Alexander Motin , freebsd-isp@freebsd.org, Jack Vogel , "Bjoern A. Zeeb" , freebsd-performance@freebsd.org Subject: Re: ating 100Gbit transfer rate X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 15:02:56 -0000 Thank you kevin. Is there anybody with suggestions also? Thanks in advance, Sami On Thu, Jul 12, 2012 at 7:04 PM, Kevin Oberman wrote: > On Wed, Jul 11, 2012 at 9:45 PM, Sami Halabi wrote: > > Hi, > > Thank your for your response. > > > > i have 2 questions: > > 1. can you explain the looping method that allowed you to reach 100GB ? > > 2. Alcatel-Lucent is routers are given for research internationally ? or > > its locally? what routers we are talking about here and what link do they > > have? i appreciatre if you explain more how do these routers saturate > 100GB. > > Sure. You create an LSP with a vrf (routing-instance in Juniper-ese) > to place the traffic onto it. The LSP is manually configured at each > hop to traverse to the far end router and that one then points back at > the input router where it is again reversed back towards the > destination. Loop as often as required to saturate the link. (I was > tempted to just say "rinse and repeat, but that might not be clear to > those not in the U.S.) > > For information on ANI (and I am not sure if new proposals are being > accepted), see: > http://www.es.net/RandD/advanced-networking-initiative/ > > > On Thu, Jul 12, 2012 at 6:43 AM, Kevin Oberman > wrote: > >> > >> On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi > wrote: > >> > Hi, > >> > > >> > We have several boxes using 10G cards and using most of the bandwidth. > >> > as a future vision i would like to ask if someone ever combined > hardware > >> > with freebsd/linux to saturate 100Gbit of traffic. > >> > what hardware (server, NICs, platform) and software do you recommend > >> > that > >> > would allow me to acheive my goal? > >> > > >> > Is it possible with servers ? or i need dedicated hardware > >> > (cisco/juniper/other?) if dedicated hardware needed, i would be glad > to > >> > hear from your experience what do you recommend in terms of > performance > >> > and > >> > price. > >> > >> I don't know of any 100GE hardware for any PC, but I may be a bit > >> behind on the times. > >> > >> The way we saturate a 100GE with a FreeBSD (or Linux) system is using > >> a 10G transmission stream and loop the data stream over the net using > >> MPLS. Works quite well, though no end system ever sees more than about > >> 9.9G, the routers do. > >> > >> We are using Alcatel-Lucent routers at this time for our national test > >> network. It is available for research by educational, commercial and > >> research organizations for a little longer as a federally funded > >> testbed for 100G research. When the funding for that project runs out, > >> most of the hardware will be re-purposed and will no longer be > >> available for research. gnn@ mentioned it about a year ago and > >> suggested that some FreeBSD people might want to submit proposals, but > >> I sw no responses. We have tested with Juniper and they will work, > >> too. All 100G hardware is just a mite pricey, though it has dropped > >> tremendously over the past year and a half and I expect it will > >> continue to do so. > >> -- > >> R. Kevin Oberman, Network Engineer > >> E-mail: kob6558@gmail.com > > > > > > > > > > -- > > Sami Halabi > > Information Systems Engineer > > NMS Projects Expert > > FreeBSD SysAdmin Expert > > > > > > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sat Jul 14 18:43:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40D62106566B for ; Sat, 14 Jul 2012 18:43:44 +0000 (UTC) (envelope-from launspachontwerp@vhostlin3.jkit.nl) Received: from vhostlin3.jkit.nl (vhostlin3.jkit.nl [83.96.177.125]) by mx1.freebsd.org (Postfix) with ESMTP id 01B978FC14 for ; Sat, 14 Jul 2012 18:43:44 +0000 (UTC) Received: by vhostlin3.jkit.nl (Postfix, from userid 10073) id 92D6B9022B6; Sat, 14 Jul 2012 20:25:27 +0200 (CEST) To: freebsd-net@freebsd.org X-PHP-Originating-Script: 7005:mailer2012.php From: Linda Joe MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20120714183116.92D6B9022B6@vhostlin3.jkit.nl> Date: Sat, 14 Jul 2012 20:25:27 +0200 (CEST) Subject: About Your Pending Funds X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lindajoe00@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 18:43:44 -0000 I am Engr Linda Joe. A computer scientist with central bank of Nigeria. I am 30 years old, just started work with C.B.N. I came across your file which was marked X and your released disk painted RED, I took time to study it and found out that you have paid VIRTUALLY all fees and certificate but the fund has not been release to you. The most annoying thing is that they cannot tell you the truth that on no account will they ever release the fund to you. Please this is like a Mafia setting in Nigeria; you may not understand it because you are not a Nigerian. The only thing I will need to release this fund is a special HARD DISK we call it HD120 GIG. I will buy two of it, recopy your information, destroy the previous one, and punch the computer to reflect in your bank within 24 bank Trus Plus@};- :x: banking hours. I will clean up the tracer and destroy your file, after which I will run away from Nigeria to meet with you. If you are interested. Do get in touch with me immediately, You should send to me your convenient tell/fax numbers for easy communications and also re confirm your banking details, so that there won't be any mistake, Get back to me as soon as possible. Regards, Engr:Ms Linda Joe