From owner-freebsd-net@FreeBSD.ORG Sun Jul 8 03:31:37 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>;
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 <freebsd-net@freebsd.org>; 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 <js@alien8.de>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <bzeeb-lists@lists.zabbadoz.net>
In-Reply-To: <BABF8C57A778F04791343E5601659908236C45@cinip100ntsbs.irtnog.net>
Date: Sun, 8 Jul 2012 08:30:27 +0000
Content-Transfer-Encoding: 7bit
Message-Id: <EE9FC3AF-6A69-48AC-977F-00AB913AB25E@lists.zabbadoz.net>
References: <CAPKwmM1heXCRviB5nQ-YCDYsTTLMa2UNDG4sAfj1xeeft63RNQ@mail.gmail.com>
<BABF8C57A778F04791343E5601659908236C45@cinip100ntsbs.irtnog.net>
To: xenophon\+freebsd <xenophon+freebsd@irtnog.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Sun, 8 Jul 2012 14:11:08 +0000 (UTC)
From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
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 <freebsd-net@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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" <bzeeb-lists@lists.zabbadoz.net>
Date: Sun, 8 Jul 2012 14:34:06 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <F52489CF-ABC9-4C43-AAFE-21F7B42698A2@lists.zabbadoz.net>
To: FreeBSD-Stable ML <freebsd-stable@freebsd.org>
X-Mailer: Apple Mail (2.1084)
Cc: FreeBSD Networking Mailing List <freebsd-net@freebsd.org>
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 <freebsd-net@freebsd.org>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>;
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 <freebsd-net@freebsd.org>; 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: <BABF8C57A778F04791343E5601659908236C46@cinip100ntsbs.irtnog.net>
In-Reply-To: <EE9FC3AF-6A69-48AC-977F-00AB913AB25E@lists.zabbadoz.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: IPSec woes coming from OpenBSD to Free
thread-index: Ac1c5AqdWGkpCTAyQXaZjPHh1z0oCAAVerbQ
References: <CAPKwmM1heXCRviB5nQ-YCDYsTTLMa2UNDG4sAfj1xeeft63RNQ@mail.gmail.com>
<BABF8C57A778F04791343E5601659908236C45@cinip100ntsbs.irtnog.net>
<EE9FC3AF-6A69-48AC-977F-00AB913AB25E@lists.zabbadoz.net>
From: "xenophon\\+freebsd" <xenophon+freebsd@irtnog.org>
To: <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Sun, 8 Jul 2012 20:14:11 +0000 (UTC)
Received: by ghbz22 with SMTP id z22so11094278ghb.13
for <freebsd-net@freebsd.org>; 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: <BABF8C57A778F04791343E5601659908236C46@cinip100ntsbs.irtnog.net>
References: <CAPKwmM1heXCRviB5nQ-YCDYsTTLMa2UNDG4sAfj1xeeft63RNQ@mail.gmail.com>
<BABF8C57A778F04791343E5601659908236C45@cinip100ntsbs.irtnog.net>
<EE9FC3AF-6A69-48AC-977F-00AB913AB25E@lists.zabbadoz.net>
<BABF8C57A778F04791343E5601659908236C46@cinip100ntsbs.irtnog.net>
Date: Sun, 8 Jul 2012 13:14:10 -0700
Message-ID: <CAPKwmM0c0jt-veeiGxhRcgWPd0ro510vhM4ettOhGTDg9XpCbw@mail.gmail.com>
From: Chris Benesch <chris.benesch@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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" <terrence@mediamonks.net>
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 <terrence@mediamonks.net>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <terrence@mediamonks.net>
To: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>,
"nkritsky@mail.ru" <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<UP,POINTOPOINT,LINK0,MULTICAST> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Sun, 8 Jul 2012 22:03:43 +0000 (UTC)
Received: by yenl8 with SMTP id l8so11121030yen.13
for <freebsd-net@freebsd.org>; 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: <CAPKwmM0c0jt-veeiGxhRcgWPd0ro510vhM4ettOhGTDg9XpCbw@mail.gmail.com>
References: <CAPKwmM1heXCRviB5nQ-YCDYsTTLMa2UNDG4sAfj1xeeft63RNQ@mail.gmail.com>
<BABF8C57A778F04791343E5601659908236C45@cinip100ntsbs.irtnog.net>
<EE9FC3AF-6A69-48AC-977F-00AB913AB25E@lists.zabbadoz.net>
<BABF8C57A778F04791343E5601659908236C46@cinip100ntsbs.irtnog.net>
<CAPKwmM0c0jt-veeiGxhRcgWPd0ro510vhM4ettOhGTDg9XpCbw@mail.gmail.com>
Date: Sun, 8 Jul 2012 15:03:36 -0700
Message-ID: <CAPKwmM1hq1YMRYsdXxCSpNGeiVNGJsxgK_L90p8vEjvuDtYJWQ@mail.gmail.com>
From: Chris Benesch <chris.benesch@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <gnn@neville-neil.com>)
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 <gnn@neville-neil.com>
In-Reply-To: <1341718291.13585.15.camel@tabernacle>
Date: Sun, 8 Jul 2012 22:29:49 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <BA85507D-8BEC-41EC-BBA4-765D4B5E373F@neville-neil.com>
References: <1341718291.13585.15.camel@tabernacle>
To: Julian Stecklina <js@alien8.de>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <glebius@FreeBSD.org>
To: Przemyslaw Frasunek <venglin@freebsd.lublin.pl>
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 <mike@sentex.net>,
Ryan Stone <rysto32@gmail.com>, Eugene Grosbein <egrosbein@rdtc.ru>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <egrosbein@rdtc.ru>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <bugmaster@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <ipv6_addr> -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 <host> -iface <nic> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <egrosbein@rdtc.ru>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAFMmRNydo=Bci=WM5mODS0vhiv8+2Oj39XKTXkEymYOJunhPxg@mail.gmail.com>
From: Ryan Stone <rysto32@gmail.com>
To: Gleb Smirnoff <glebius@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bzeeb-lists@lists.zabbadoz.net,
Przemyslaw Frasunek <venglin@freebsd.lublin.pl>,
Mike Tancsa <mike@sentex.net>,
Eugene Grosbein <egrosbein@rdtc.ru>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 20:25:34 -0000
On Mon, Jul 9, 2012 at 4:12 AM, Gleb Smirnoff <glebius@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <hrs@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <melifaro@FreeBSD.org> wrote
in <4FFA9723.5000301@FreeBSD.org>:
me> On 09.07.2012 12:08, Hiroki Sato wrote:
me> > "Alexander V. Chernikov"<melifaro@FreeBSD.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>;
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
<freebsd-net@freebsd.org>; 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 <adarsh.joshi@qlogic.com>
To: "freebsd-net@freebsd.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<ACTIVE,COLLECTING,DISTRIBUTING>, =
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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
ether 00:0e:1e:08:05:20
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
ether 00:0e:1e:04:2c:f0
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <egrosbein@rdtc.ru>
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 <rysto32@gmail.com>
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>
<CAFMmRNydo=Bci=WM5mODS0vhiv8+2Oj39XKTXkEymYOJunhPxg@mail.gmail.com>
In-Reply-To: <CAFMmRNydo=Bci=WM5mODS0vhiv8+2Oj39XKTXkEymYOJunhPxg@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
Cc: bzeeb-lists@lists.zabbadoz.net,
Przemyslaw Frasunek <venglin@freebsd.lublin.pl>,
Mike Tancsa <mike@sentex.net>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <glebius@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <glebius@FreeBSD.org>
To: Eugene Grosbein <egrosbein@rdtc.ru>
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>
<CAFMmRNydo=Bci=WM5mODS0vhiv8+2Oj39XKTXkEymYOJunhPxg@mail.gmail.com>
<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 <venglin@freebsd.lublin.pl>,
Mike Tancsa <mike@sentex.net>, Ryan Stone <rysto32@gmail.com>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <glebius@freebsd.org> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <venglin@freebsd.lublin.pl>
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 <egrosbein@rdtc.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>
<CAFMmRNydo=Bci=WM5mODS0vhiv8+2Oj39XKTXkEymYOJunhPxg@mail.gmail.com>
<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 <rysto32@gmail.com>,
Mike Tancsa <mike@sentex.net>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Tue, 10 Jul 2012 07:10:15 +0000 (UTC)
Received: by ggnm2 with SMTP id m2so12609577ggn.13
for <freebsd-net@freebsd.org>; 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 <jhellenthal@dataix.net>
To: Adarsh Joshi <adarsh.joshi@qlogic.com>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<ACTIVE,COLLECTING,DISTRIBUTING>=
, 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu =
1500
> options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO=
4>
> ether 00:0e:1e:08:05:20
> inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
> nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> 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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu =
1500
> options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO=
4>
> ether 00:0e:1e:04:2c:f0
> inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
> nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D80048<VLAN_MTU,POLLING,LINKSTATE>
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<ACTIVE,COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <daniel@benzedrine.cx>
To: Eugene Grosbein <egrosbein@rdtc.ru>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<pkthdr,ext>,
Jul 10 09:06:03 testA kernel: mbuf: 0xc4fdb000 len: 1, next: 0, 3<pkthdr,ext>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Tue, 10 Jul 2012 08:35:19 +0000 (UTC)
Received: by eabm6 with SMTP id m6so4805259eab.13
for <freebsd-net@freebsd.org>; 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 <ml@my.gd>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<ACTIVE,COLLECTING,DISTRIBUTING>, 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>> options=13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
>> ether 00:0e:1e:08:05:20
>> inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> 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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>> options=13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
>> ether 00:0e:1e:04:2c:f0
>> inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=80048<VLAN_MTU,POLLING,LINKSTATE>
> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <egrosbein@rdtc.ru>
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 <daniel@benzedrine.cx>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <aboyer@averesystems.com>
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 <adarsh.joshi@qlogic.com>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<ACTIVE,COLLECTING,DISTRIBUTING>, 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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> =
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<ACTIVE,COLLECTING,DISTRIBUTING> =
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<COLLECTING,DISTRIBUTING> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <glebius@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <adarsh.joshi@qlogic.com>
To: Jason Hellenthal <jhellenthal@dataix.net>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<ACTIVE,COLLECTING,DISTRIBUTING>=
, 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu =
1500
> options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO=
4>
> ether 00:0e:1e:08:05:20
> inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
> nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> 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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu =
1500
> options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO=
4>
> ether 00:0e:1e:04:2c:f0
> inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
> nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D80048<VLAN_MTU,POLLING,LINKSTATE>
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<ACTIVE,COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <adarsh.joshi@qlogic.com>
To: Andrew Boyer <aboyer@averesystems.com>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<ACTIVE,COLLECTING,DISTRIBUTING>, =
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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<mailto: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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <adarsh.joshi@qlogic.com>
To: Andrew Boyer <aboyer@averesystems.com>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
ether 00:0e:1e:08:05:20
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
ether 00:0e:1e:04:2c:f0
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT>
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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0
Jul 10 10:38:51 bsd-14 kernel: ql0: old pstate 2<TIMEOUT>
Jul 10 10:38:51 bsd-14 kernel: ql0: new pstate 5<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
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<ACTIVITY,AGGREGATION,DEFAUL=
TED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,SYNC>
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<ACTIVITY,AGGREGATION>
Jul 10 10:38:54 bsd-14 kernel: maxdelay=3D0
Jul 10 10:38:54 bsd-14 kernel: ql0: old pstate 5<ACTIVITY,AGGREGATION>
Jul 10 10:38:54 bsd-14 kernel: ql0: new pstate d<ACTIVITY,AGGREGATION,SYNC>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING,DEFAULTED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING>
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<ACTIVITY,AGGREGATION,SYNC>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC=
,COLLECTING>
Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0
Jul 10 10:38:55 bsd-14 kernel: ql0: old pstate d<ACTIVITY,AGGREGATION,SYNC>
Jul 10 10:38:55 bsd-14 kernel: ql0: new pstate 3d<ACTIVITY,AGGREGATION,SYNC=
,COLLECTING,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT>
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<TIMEOUT>
Jul 10 02:38:26 bsd-15 kernel: ql0: new pstate 85<ACTIVITY,AGGREGATION,EXPI=
RED>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION>
Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0
Jul 10 02:38:27 bsd-15 kernel: ql0: old pstate 85<ACTIVITY,AGGREGATION,EXPI=
RED>
Jul 10 02:38:27 bsd-15 kernel: ql0: new pstate 5<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,DEFAUL=
TED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING>
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<ACTIVITY,AGGREGATION,SYNC>
Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0
Jul 10 02:38:30 bsd-15 kernel: ql0: old pstate 5<ACTIVITY,AGGREGATION>
Jul 10 02:38:30 bsd-15 kernel: ql0: new pstate 1d<ACTIVITY,AGGREGATION,SYNC=
,COLLECTING>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING,DEFAULTED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC=
,COLLECTING>
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<ACTIVE,COLLECTING,DISTRIBUTING>, =
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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<mailto: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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <gnn@neville-neil.com>) id 1SofvI-00039D-Jz
for net@freebsd.org; Tue, 10 Jul 2012 15:16:36 -0400
From: George Neville-Neil <gnn@neville-neil.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Jul 2012 15:16:36 -0400
Message-Id: <E1533C44-985C-447B-BA58-09901B34F883@neville-neil.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Wed, 11 Jul 2012 02:27:05 +0000 (UTC)
Received: by ghbz22 with SMTP id z22so820860ghb.13
for <freebsd-net@freebsd.org>; 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: <CAPKwmM0ymOebO0WsJqNRuRJ4sT09uikj9b-5x4BDe-eFJYyKFA@mail.gmail.com>
From: Chris Benesch <chris.benesch@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Wed, 11 Jul 2012 07:14:05 +0000 (UTC)
Received: by qcsg15 with SMTP id g15so636248qcs.13
for <freebsd-net@freebsd.org>; 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: <CAPKwmM0ymOebO0WsJqNRuRJ4sT09uikj9b-5x4BDe-eFJYyKFA@mail.gmail.com>
References: <CAPKwmM0ymOebO0WsJqNRuRJ4sT09uikj9b-5x4BDe-eFJYyKFA@mail.gmail.com>
Date: Wed, 11 Jul 2012 09:14:05 +0200
X-Google-Sender-Auth: FTwwQr_GtMKms7EAGq_bSxOake4
Message-ID: <CAPBZQG0SAs8HRj7XPxRmx5CL18qH8-SN0wnUm5Ef9OKbnSj63w@mail.gmail.com>
From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org>
To: Chris Benesch <chris.benesch@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 07:14:06 -0000
On Wed, Jul 11, 2012 at 4:27 AM, Chris Benesch <chris.benesch@gmail.com> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <bzeeb-lists@lists.zabbadoz.net>
In-Reply-To: <CAPBZQG0SAs8HRj7XPxRmx5CL18qH8-SN0wnUm5Ef9OKbnSj63w@mail.gmail.com>
Date: Wed, 11 Jul 2012 09:49:38 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <B44BD0C3-E5CC-4370-BCCA-5538568F4269@lists.zabbadoz.net>
References: <CAPKwmM0ymOebO0WsJqNRuRJ4sT09uikj9b-5x4BDe-eFJYyKFA@mail.gmail.com>
<CAPBZQG0SAs8HRj7XPxRmx5CL18qH8-SN0wnUm5Ef9OKbnSj63w@mail.gmail.com>
To: FreeBSD Networking Mailing List <freebsd-net@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 =
<chris.benesch@gmail.com> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <daniel@benzedrine.cx>
To: Chris Benesch <chris.benesch@gmail.com>
Message-ID: <20120711110152.GE9145@insomnia.benzedrine.cx>
References: <CAPKwmM0ymOebO0WsJqNRuRJ4sT09uikj9b-5x4BDe-eFJYyKFA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPKwmM0ymOebO0WsJqNRuRJ4sT09uikj9b-5x4BDe-eFJYyKFA@mail.gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <hartmut.brandt@dlr.de>
X-X-Sender: brandt_h@KNOP-BEAGLE.kn.op.dlr.de
To: <net@freebsd.org>
Message-ID: <alpine.BSF.2.00.1207111327340.68527@KNOP-BEAGLE.kn.op.dlr.de>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Wed, 11 Jul 2012 15:51:33 +0000 (UTC)
Received: by yenl8 with SMTP id l8so1567375yen.13
for <freebsd-net@freebsd.org>; 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: <CAPKwmM0ymOebO0WsJqNRuRJ4sT09uikj9b-5x4BDe-eFJYyKFA@mail.gmail.com>
<20120711110152.GE9145@insomnia.benzedrine.cx>
Date: Wed, 11 Jul 2012 08:51:32 -0700
Message-ID: <CAPKwmM2Wz+42yDzpHL8yis=nmgakRGcf5Qmf3SVDj7eUhyq5dQ@mail.gmail.com>
From: Chris Benesch <chris.benesch@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <adarsh.joshi@qlogic.com>
To: Andrew Boyer <aboyer@averesystems.com>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
ether 00:0e:1e:08:05:20
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
options=3D13b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,TSO4>
ether 00:0e:1e:04:2c:f0
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT> 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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT> 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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
Jul 10 10:38:51 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:51 bsd-14 kernel: =
ql0: old pstate 2<TIMEOUT> Jul 10 10:38:51 bsd-14 kernel: ql0: new pstate 5=
<ACTIVITY,AGGREGATION> 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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
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<ACTIVITY,AGGREGATION,DEFAUL=
TED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,SYNC>
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<ACTIVITY,AGGREGATION>
Jul 10 10:38:54 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:54 bsd-14 kernel: =
ql0: old pstate 5<ACTIVITY,AGGREGATION> Jul 10 10:38:54 bsd-14 kernel: ql0:=
new pstate d<ACTIVITY,AGGREGATION,SYNC> 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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING,DEFAULTED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING>
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<ACTIVITY,AGGREGATION,SYNC>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC=
,COLLECTING>
Jul 10 10:38:55 bsd-14 kernel: maxdelay=3D0 Jul 10 10:38:55 bsd-14 kernel: =
ql0: old pstate d<ACTIVITY,AGGREGATION,SYNC> Jul 10 10:38:55 bsd-14 kernel:=
ql0: new pstate 3d<ACTIVITY,AGGREGATION,SYNC,COLLECTING,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT> 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<TIME=
OUT> Jul 10 02:38:26 bsd-15 kernel: ql0: new pstate 85<ACTIVITY,AGGREGATION=
,EXPIRED> 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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
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<ACTIVITY,AGGREGATION,EXPIRE=
D>
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<TIMEOUT> 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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,EXPI=
RED>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION>
Jul 10 02:38:27 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:27 bsd-15 kernel: =
ql0: old pstate 85<ACTIVITY,AGGREGATION,EXPIRED> Jul 10 02:38:27 bsd-15 ker=
nel: ql0: new pstate 5<ACTIVITY,AGGREGATION> 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<ACTIVITY,AGGREGATION,DEFAUL=
TED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC>
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<ACTIVITY,AGGREGATION>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING>
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<ACTIVITY,AGGREGATION,SYNC>
Jul 10 02:38:30 bsd-15 kernel: maxdelay=3D0 Jul 10 02:38:30 bsd-15 kernel: =
ql0: old pstate 5<ACTIVITY,AGGREGATION> Jul 10 02:38:30 bsd-15 kernel: ql0:=
new pstate 1d<ACTIVITY,AGGREGATION,SYNC,COLLECTING>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING,DEFAULTED>
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<AGGREGATION,SYNC,COLLECTI=
NG,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC,C=
OLLECTING,DISTRIBUTING>
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<ACTIVITY,AGGREGATION,SYNC=
,COLLECTING>
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<ACTIVE,COLLECTING,DISTRIBUTING>, =
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<COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<ACTIVE,COLLECTING,DISTRIBUTING> 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<COLLECTING,DISTRIBUTING> 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<mailto: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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAEW+ogZCfOGJHGAQcKD+ANCzoX7snfjy_Azo2i_h4LsEuaGZ2g@mail.gmail.com>
From: Sami Halabi <sodynet1@gmail.com>
To: freebsd-net@freebsd.org, freebsd-isp@freebsd.org,
freebsd-performance@freebsd.org, Jack Vogel <jfvogel@gmail.com>,
Alexander Motin <mav@freebsd.org>,
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>,
Luigi Rizzo <l.rizzo@iet.unipi.it>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <gnn@neville-neil.com>) 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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 <nparhar@gmail.com>
Message-ID: <4FFDF6C7.3030301@FreeBSD.org>
Date: Wed, 11 Jul 2012 14:57:27 -0700
From: Navdeep Parhar <np@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAEW+ogZCfOGJHGAQcKD+ANCzoX7snfjy_Azo2i_h4LsEuaGZ2g@mail.gmail.com>
References: <CAEW+ogZCfOGJHGAQcKD+ANCzoX7snfjy_Azo2i_h4LsEuaGZ2g@mail.gmail.com>
Date: Wed, 11 Jul 2012 20:43:12 -0700
Message-ID: <CAN6yY1ueqGEfXN9uFeM6kCxTjZitMa6bVkdWEY0=FxLCVMXCfA@mail.gmail.com>
From: Kevin Oberman <kob6558@gmail.com>
To: Sami Halabi <sodynet1@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Luigi Rizzo <l.rizzo@iet.unipi.it>, freebsd-net@freebsd.org,
Alexander Motin <mav@freebsd.org>, freebsd-isp@freebsd.org,
Jack Vogel <jfvogel@gmail.com>,
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2012 03:43:15 -0000
On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi <sodynet1@gmail.com> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAN6yY1ueqGEfXN9uFeM6kCxTjZitMa6bVkdWEY0=FxLCVMXCfA@mail.gmail.com>
References: <CAEW+ogZCfOGJHGAQcKD+ANCzoX7snfjy_Azo2i_h4LsEuaGZ2g@mail.gmail.com>
<CAN6yY1ueqGEfXN9uFeM6kCxTjZitMa6bVkdWEY0=FxLCVMXCfA@mail.gmail.com>
Date: Thu, 12 Jul 2012 07:45:43 +0300
Message-ID: <CAEW+ogZAiQ64eCARmue9+B1ZQ3+3PXG_-2dTuvbTY1JzL=ycig@mail.gmail.com>
From: Sami Halabi <sodynet1@gmail.com>
To: Kevin Oberman <kob6558@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: Luigi Rizzo <l.rizzo@iet.unipi.it>, freebsd-net@freebsd.org,
Alexander Motin <mav@freebsd.org>, freebsd-isp@freebsd.org,
Jack Vogel <jfvogel@gmail.com>,
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <kob6558@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi <sodynet1@gmail.com> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <gnn@freebsd.org>)
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 <gnn@freebsd.org>
In-Reply-To: <4FFDF6C7.3030301@FreeBSD.org>
Date: Thu, 12 Jul 2012 10:55:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org>
To: Navdeep Parhar <np@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAEW+ogZAiQ64eCARmue9+B1ZQ3+3PXG_-2dTuvbTY1JzL=ycig@mail.gmail.com>
References: <CAEW+ogZCfOGJHGAQcKD+ANCzoX7snfjy_Azo2i_h4LsEuaGZ2g@mail.gmail.com>
<CAN6yY1ueqGEfXN9uFeM6kCxTjZitMa6bVkdWEY0=FxLCVMXCfA@mail.gmail.com>
<CAEW+ogZAiQ64eCARmue9+B1ZQ3+3PXG_-2dTuvbTY1JzL=ycig@mail.gmail.com>
Date: Thu, 12 Jul 2012 09:04:57 -0700
Message-ID: <CAN6yY1tTT37bNsx=tgg25SRUz38Tu8gShd2KX-Qsa1gTgPbA0Q@mail.gmail.com>
From: Kevin Oberman <kob6558@gmail.com>
To: Sami Halabi <sodynet1@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Luigi Rizzo <l.rizzo@iet.unipi.it>, freebsd-net@freebsd.org,
Alexander Motin <mav@freebsd.org>, freebsd-isp@freebsd.org,
Jack Vogel <jfvogel@gmail.com>,
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2012 16:04:59 -0000
On Wed, Jul 11, 2012 at 9:45 PM, Sami Halabi <sodynet1@gmail.com> 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 <kob6558@gmail.com> wrote:
>>
>> On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi <sodynet1@gmail.com> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; Thu, 12 Jul 2012 16:55:13 +0000 (UTC)
Received: by ghbz22 with SMTP id z22so3034292ghb.13
for <net@freebsd.org>; 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 <jhellenthal@dataix.net>
To: George Neville-Neil <gnn@freebsd.org>
Message-ID: <20120712165502.GA61341@DataIX.net>
References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org>
<C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
X-Gm-Message-State: ALoCoQny+qi2hh9jdVDeJutUWqRY7Qe/0rNOET5weGAD941sPNjg91rL/Hqtd8RnpD/QO5Y1LpjA
Cc: Navdeep Parhar <np@freebsd.org>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <aboyer@averesystems.com>
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>
<C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
<20120712165502.GA61341@DataIX.net>
To: Jason Hellenthal <jhellenthal@dataix.net>
X-Mailer: Apple Mail (2.1278)
Cc: George Neville-Neil <gnn@freebsd.org>, Navdeep Parhar <np@freebsd.org>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <dougb@FreeBSD.org>
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 <gnn@freebsd.org>
References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org>
<C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
In-Reply-To: <C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Navdeep Parhar <np@FreeBSD.org>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <yuri@rawbw.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <OLD-IP> &&
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: <owner-freebsd-net@FreeBSD.ORG>
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 <gnn@freebsd.org>)
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 <gnn@freebsd.org>
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>
<C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
<20120712165502.GA61341@DataIX.net>
To: Jason Hellenthal <jhellenthal@dataix.net>
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 <np@freebsd.org>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <gnn@freebsd.org>)
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 <gnn@freebsd.org>
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>
<C06D346A-97BE-4498-B4E5-0ED85731A8BD@freebsd.org>
<4FFF1742.9010906@FreeBSD.org>
To: Doug Barton <dougb@FreeBSD.org>
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 <np@FreeBSD.org>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 12 Jul 2012 20:52:01 +0000 (UTC)
Received: by ggnm2 with SMTP id m2so3354060ggn.13
for <freebsd-net@freebsd.org>; 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: <CAPKwmM1MLm5nYX6LT480iX2R9gKAQBskUghwVj6Q8KF8oMyL=w@mail.gmail.com>
From: Chris Benesch <chris.benesch@gmail.com>
To: Yuri <yuri@rawbw.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <process id>
dhclient re0
That will force it to acquire a new address.
On Thu, Jul 12, 2012 at 1:41 PM, Yuri <yuri@rawbw.com> 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 <OLD-IP> && 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<http://lists.freebsd.org/mailman/listinfo/freebsd-net>
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org<freebsd-net-unsubscribe@freebsd.org>
> "
>
From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 21:00:04 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <dougb@FreeBSD.org>
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 <gnn@freebsd.org>
References: <86liiqrnnq.wl%gnn@neville-neil.com> <4FFDF6C7.3030301@FreeBSD.org>
<C06D346A-97BE-4498-B4E5-0ED85731A8BD@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 <np@FreeBSD.org>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 12 Jul 2012 21:01:52 +0000 (UTC)
Received: by lbon10 with SMTP id n10so4674586lbo.13
for <freebsd-net@freebsd.org>; 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: <CAPKwmM1MLm5nYX6LT480iX2R9gKAQBskUghwVj6Q8KF8oMyL=w@mail.gmail.com>
References: <4FFF3683.7020107@rawbw.com>
<CAPKwmM1MLm5nYX6LT480iX2R9gKAQBskUghwVj6Q8KF8oMyL=w@mail.gmail.com>
Date: Thu, 12 Jul 2012 14:01:51 -0700
Message-ID: <CAOjFWZ6dCDSkdxGNGzmo+u871sOF8r05b6psukoP9pDLQHHk6A@mail.gmail.com>
From: Freddie Cash <fjwcash@gmail.com>
To: Chris Benesch <chris.benesch@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Yuri <yuri@rawbw.com>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2012 21:01:53 -0000
On Thu, Jul 12, 2012 at 1:52 PM, Chris Benesch <chris.benesch@gmail.com> 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 <process id>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 12 Jul 2012 21:08:24 +0000 (UTC)
Received: by ggnm2 with SMTP id m2so3373202ggn.13
for <freebsd-net@freebsd.org>; 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: <CAOjFWZ6dCDSkdxGNGzmo+u871sOF8r05b6psukoP9pDLQHHk6A@mail.gmail.com>
References: <4FFF3683.7020107@rawbw.com>
<CAPKwmM1MLm5nYX6LT480iX2R9gKAQBskUghwVj6Q8KF8oMyL=w@mail.gmail.com>
<CAOjFWZ6dCDSkdxGNGzmo+u871sOF8r05b6psukoP9pDLQHHk6A@mail.gmail.com>
Date: Thu, 12 Jul 2012 14:08:23 -0700
Message-ID: <CAPKwmM0tBaHGQvHwAafpVPYxowU5CiZ6-_tBKLk5S13T2pCa5g@mail.gmail.com>
From: Chris Benesch <chris.benesch@gmail.com>
To: Freddie Cash <fjwcash@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: Yuri <yuri@rawbw.com>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <fjwcash@gmail.com> wrote:
> On Thu, Jul 12, 2012 at 1:52 PM, Chris Benesch <chris.benesch@gmail.com>
> 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 <process id>
> > 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <reichert@numachi.com>
To: Freddie Cash <fjwcash@gmail.com>
Message-ID: <20120712211959.GG20201@numachi.com>
References: <4FFF3683.7020107@rawbw.com>
<CAPKwmM1MLm5nYX6LT480iX2R9gKAQBskUghwVj6Q8KF8oMyL=w@mail.gmail.com>
<CAOjFWZ6dCDSkdxGNGzmo+u871sOF8r05b6psukoP9pDLQHHk6A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOjFWZ6dCDSkdxGNGzmo+u871sOF8r05b6psukoP9pDLQHHk6A@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: Yuri <yuri@rawbw.com>, Chris Benesch <chris.benesch@gmail.com>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <reichert@numachi.com>
BSD admin/developer at large
From owner-freebsd-net@FreeBSD.ORG Thu Jul 12 22:25:09 2012
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 12 Jul 2012 22:25:08 +0000 (UTC)
Received: by ghbz22 with SMTP id z22so3440903ghb.13
for <freebsd-net@freebsd.org>; 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>
<CAPKwmM1MLm5nYX6LT480iX2R9gKAQBskUghwVj6Q8KF8oMyL=w@mail.gmail.com>
<CAOjFWZ6dCDSkdxGNGzmo+u871sOF8r05b6psukoP9pDLQHHk6A@mail.gmail.com>
<20120712211959.GG20201@numachi.com>
Date: Thu, 12 Jul 2012 15:25:07 -0700
Message-ID: <CAPKwmM3H2UJm1nX_2LZiHRxOswh__mF-SwVbNA7D6eBwg+10Ow@mail.gmail.com>
From: Chris Benesch <chris.benesch@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <pprocacci@datapipe.com>
To: Chris Benesch <chris.benesch@gmail.com>
Message-ID: <20120712223037.GD1907@nat.myhome>
References: <4FFF3683.7020107@rawbw.com>
<CAPKwmM1MLm5nYX6LT480iX2R9gKAQBskUghwVj6Q8KF8oMyL=w@mail.gmail.com>
<CAOjFWZ6dCDSkdxGNGzmo+u871sOF8r05b6psukoP9pDLQHHk6A@mail.gmail.com>
<20120712211959.GG20201@numachi.com>
<CAPKwmM3H2UJm1nX_2LZiHRxOswh__mF-SwVbNA7D6eBwg+10Ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAPKwmM3H2UJm1nX_2LZiHRxOswh__mF-SwVbNA7D6eBwg+10Ow@mail.gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 12 Jul 2012 22:39:41 +0000 (UTC)
Received: by obbun3 with SMTP id un3so4788910obb.13
for <freebsd-net@freebsd.org>; 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: <CAAAm0r2=_VbmHop7WMmg7UW7u0D+JGZn2BO1D7E96BFuGPs=8w@mail.gmail.com>
From: Jason Wolfe <nitroboost@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <Broadcom unknown BCM5719, ASIC rev 0x5719001> 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: <MII bus> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <ihsan@grep.my>
In-Reply-To: <CAFOYbcn6ETrNFGLBS1r46Jovr7p5QbdcuCKyheA_xw18GiYgtw@mail.gmail.com>
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>
<CAFOYbcn6ETrNFGLBS1r46Jovr7p5QbdcuCKyheA_xw18GiYgtw@mail.gmail.com>
To: Jack Vogel <jfvogel@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <ihsan@grep.my> =
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <kevlo@kevlo.org>
To: Yuri <yuri@rawbw.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <OLD-IP> &&
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <emz@norma.perm.ru>
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: <CAAAm0r2=_VbmHop7WMmg7UW7u0D+JGZn2BO1D7E96BFuGPs=8w@mail.gmail.com>
In-Reply-To: <CAAAm0r2=_VbmHop7WMmg7UW7u0D+JGZn2BO1D7E96BFuGPs=8w@mail.gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2012 06:02:58 -0000
Hi.
On 13.07.2012 04:39, Jason Wolfe wrote:
> bge0:<Broadcom unknown BCM5719, ASIC rev 0x5719001> 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:<MII bus> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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: <BA85507D-8BEC-41EC-BBA4-765D4B5E373F@neville-neil.com>
References: <1341718291.13585.15.camel@tabernacle>
<BA85507D-8BEC-41EC-BBA4-765D4B5E373F@neville-neil.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Julian Stecklina <js@alien8.de>
Date: Thu, 12 Jul 2012 23:35:22 -0700
To: George Neville-Neil <gnn@neville-neil.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2012 06:35:32 -0000
George Neville-Neil <gnn@neville-neil.com> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri, 13 Jul 2012 07:57:57 +0000 (UTC)
Received: by obbun3 with SMTP id un3so5545974obb.13
for <freebsd-net@freebsd.org>; 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: <CAPJF9wkjfSVCZQOmrSeXCPyK0R2MKTrbNvJOJKPvn7NLWsB7Cw@mail.gmail.com>
From: Alexander Yerenkow <yerenkow@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <peter@rulingia.com>
To: Yuri <yuri@rawbw.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <yuri@rawbw.com> 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 <OLD-IP> &&=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: <owner-freebsd-net@FreeBSD.ORG>
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 <jhb@freebsd.org>
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 <yuri@rawbw.com>, Brooks Davis <brooks@freebsd.org>,
Peter Jeremy <peter@rulingia.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <yuri@rawbw.com> 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 <OLD-IP> &&
> >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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <reese@myri.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: 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <yuri@rawbw.com>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
rv:13.0) Gecko/20120702 Thunderbird/13.0.1
MIME-Version: 1.0
To: Peter Jeremy <peter@rulingia.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <brooks@freebsd.org>
To: John Baldwin <jhb@freebsd.org>
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 <peter@rulingia.com>,
Yuri <yuri@rawbw.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <yuri@rawbw.com> 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 <OLD-IP> &&=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Sat, 14 Jul 2012 07:51:32 +0000 (UTC)
Received: by yhfs35 with SMTP id s35so5074741yhf.13
for <freebsd-net@freebsd.org>; 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 <jhellenthal@dataix.net>
To: Yuri <yuri@rawbw.com>
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 <peter@rulingia.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <multiple recipients>; 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: <CAN6yY1tTT37bNsx=tgg25SRUz38Tu8gShd2KX-Qsa1gTgPbA0Q@mail.gmail.com>
References: <CAEW+ogZCfOGJHGAQcKD+ANCzoX7snfjy_Azo2i_h4LsEuaGZ2g@mail.gmail.com>
<CAN6yY1ueqGEfXN9uFeM6kCxTjZitMa6bVkdWEY0=FxLCVMXCfA@mail.gmail.com>
<CAEW+ogZAiQ64eCARmue9+B1ZQ3+3PXG_-2dTuvbTY1JzL=ycig@mail.gmail.com>
<CAN6yY1tTT37bNsx=tgg25SRUz38Tu8gShd2KX-Qsa1gTgPbA0Q@mail.gmail.com>
Date: Sat, 14 Jul 2012 18:02:55 +0300
Message-ID: <CAEW+oga=2TybLAzirigRWFkJ59oyvQyJdoMDN-Ko+7L3yHMVTA@mail.gmail.com>
From: Sami Halabi <sodynet1@gmail.com>
To: Kevin Oberman <kob6558@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: Luigi Rizzo <l.rizzo@iet.unipi.it>, freebsd-net@freebsd.org,
Alexander Motin <mav@freebsd.org>, freebsd-isp@freebsd.org,
Jack Vogel <jfvogel@gmail.com>,
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <kob6558@gmail.com> wrote:
> On Wed, Jul 11, 2012 at 9:45 PM, Sami Halabi <sodynet1@gmail.com> 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 <kob6558@gmail.com>
> wrote:
> >>
> >> On Wed, Jul 11, 2012 at 1:31 PM, Sami Halabi <sodynet1@gmail.com>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <marinakirina@officeliveusers.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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