From owner-freebsd-net@FreeBSD.ORG Sun Apr 19 00:18:09 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C533BA46 for ; Sun, 19 Apr 2015 00:18:09 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id B22837D9 for ; Sun, 19 Apr 2015 00:18:09 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t3J0I2bb006180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 18 Apr 2015 17:18:03 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <5532F439.8070506@rawbw.com> Date: Sat, 18 Apr 2015 17:18:01 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "net@freebsd.org" Subject: resolvconf(8) always leaves original DNS server in the list, allowing DNS requests to leak Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 00:18:09 -0000 I am looking at this typical situation: the VPN app creates and sets up tap0 interface meant to be the new default route. Then it calls this command: > echo " > nameserver > domain > " | resolvconf -a tap0 Problem: /etc/resolv.conf now looks like this: > nameserver > nameserver The old DNS server is left at the last position. This means that in cases when the new server fails, DNS resolution falls back on the old server, therefore allowing DNS requests to leak. I looked through the resolvconf man page, and can't find any way that application can replace the old DNS server there. It can only add the new one for some interface, and in the end remove it. The new server "overrides" the old one, but still leaves the old one there. This creates the situation when DNS leaks to the old server. I would like to suggest the new option: > -x Make the new DNS server exclusive. With this option resolvconf(8) will replace the old server with the new one. This will require resolvconf to have some more logic. Yuri From owner-freebsd-net@FreeBSD.ORG Sun Apr 19 07:30:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57FA1338 for ; Sun, 19 Apr 2015 07:30:32 +0000 (UTC) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtp003.mac.com [17.172.81.2]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F831258 for ; Sun, 19 Apr 2015 07:30:32 +0000 (UTC) Received: from akita.localnet (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NN100M6SM6O4D20@st11p00mm-asmtp003.mac.com> for freebsd-net@freebsd.org; Sun, 19 Apr 2015 07:30:25 +0000 (GMT) From: Rui Paulo To: freebsd-net@freebsd.org Cc: Yuri Subject: Re: resolvconf(8) always leaves original DNS server in the list, allowing DNS requests to leak Date: Sun, 19 Apr 2015 00:30:23 -0700 Message-id: <4525101.OcnIUfWoXM@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-reply-to: <5532F439.8070506@rawbw.com> References: <5532F439.8070506@rawbw.com> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-19_01:2015-04-17,2015-04-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504190067 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 07:30:32 -0000 On Saturday 18 April 2015 17:18:01 Yuri wrote: > I am looking at this typical situation: the VPN app creates and sets up > tap0 interface meant to be the new default route. > > Then it calls this command: > > echo " > > nameserver > > domain > > " | resolvconf -a tap0 > > Problem: > > /etc/resolv.conf now looks like this: > > nameserver > > nameserver > > The old DNS server is left at the last position. This means that in > cases when the new server fails, DNS resolution falls back on the old > server, therefore allowing DNS requests to leak. > > I looked through the resolvconf man page, and can't find any way that > application can replace the old DNS server there. It can only add the > new one for some interface, and in the end remove it. The new server > "overrides" the old one, but still leaves the old one there. This > creates the situation when DNS leaks to the old server. > > I would like to suggest the new option: > > -x Make the new DNS server exclusive. > > With this option resolvconf(8) will replace the old server with the new one. What you want requires scoped routing and scoped DNS, meaning that the network stack must have knowledge of what domain names a specific VPN DNS server resolves. The resolv.conf file is completely unsuitable for this purpose. The solution you offer is just a hack to avoid the "leak" of DNS domain names and doesn't really solve the bigger problem. What if the VPN DNS server doesn't resolve google.com? -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sun Apr 19 08:40:56 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 913E487F for ; Sun, 19 Apr 2015 08:40:56 +0000 (UTC) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7CFB4B60 for ; Sun, 19 Apr 2015 08:40:56 +0000 (UTC) Received: from yuri.doctorlan.com (c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128]) (authenticated bits=0) by shell1.rawbw.com (8.14.9/8.14.9) with ESMTP id t3J8esPU051979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 19 Apr 2015 01:40:55 -0700 (PDT) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-50-184-63-128.hsd1.ca.comcast.net [50.184.63.128] claimed to be yuri.doctorlan.com Message-ID: <55336A15.3050905@rawbw.com> Date: Sun, 19 Apr 2015 01:40:53 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Rui Paulo , freebsd-net@freebsd.org Subject: Re: resolvconf(8) always leaves original DNS server in the list, allowing DNS requests to leak References: <5532F439.8070506@rawbw.com> <4525101.OcnIUfWoXM@akita> In-Reply-To: <4525101.OcnIUfWoXM@akita> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 08:40:56 -0000 On 04/19/2015 00:30, Rui Paulo wrote: > What you want requires scoped routing and scoped DNS, meaning that the network > stack must have knowledge of what domain names a specific VPN DNS server > resolves. The resolv.conf file is completely unsuitable for this purpose. > > The solution you offer is just a hack to avoid the "leak" of DNS domain names > and doesn't really solve the bigger problem. What if the VPN DNS server > doesn't resolve google.com? Actually, resolvconf does support DNS scoping, at least roughly. It has "-p" (private) flag, and in such case it only resolves domains listed in resolv.conf. And scoped routing is supported by OpenVPN. There is the distinction between the corporate VPN, and personal ("home") use VPN. Usually DNS in the latter one is resolving everything. Such VPN is designed to be exclusive and to protect privacy. This is the one I am mostly talking about. The current resolvconf works okay in the case of the corporate VPN. In such case "-p" flag and the list of corporate domains should be used. Yuri From owner-freebsd-net@FreeBSD.ORG Sun Apr 19 21:00:12 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76B08937 for ; Sun, 19 Apr 2015 21:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4EFA1D1C for ; Sun, 19 Apr 2015 21:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3JL0CeN060682 for ; Sun, 19 Apr 2015 21:00:12 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201504192100.t3JL0CeN060682@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-net@FreeBSD.org Subject: Problem reports for freebsd-net@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 19 Apr 2015 21:00:12 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 21:00:12 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 197535 | [re] [panic] if_re (Realtek 8168) causes memory w 1 problems total for which you should take action. From owner-freebsd-net@FreeBSD.ORG Mon Apr 20 06:14:12 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CC1CE71 for ; Mon, 20 Apr 2015 06:14:12 +0000 (UTC) Received: from sum.zhabenwang.com (sum.zhabenwang.com [178.251.230.20]) by mx1.freebsd.org (Postfix) with ESMTP id 77C63B5A for ; Mon, 20 Apr 2015 06:14:11 +0000 (UTC) To: freebsd-net@freebsd.org Subject: about our email marketing Message-ID: Date: Mon, 20 Apr 2015 07:39:01 +0200 From: "Louis" Reply-To: bonnietongy@sina.com MIME-Version: 1.0 X-Mailer-LID: 26 X-Mailer-RecptId: 20219482 X-Mailer-SID: 282 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 06:14:12 -0000 Hi, You are receiving this email because we wish you to use our target email marketing service. We specialize in providing target email marketing services to a number of businesses all over the world! Email marketing is one of the best marketing strategies of all time and has helped many businesses globally achieve their goals, double their profits and increase their client base. We have worked on a number of projects and campaigns, all our packages are tailor made and designed according to your requirements. We wish to be your marketing partner, we can increase your business sales 2-5 times. If you would require more information please send us an email and we would be glad to discuss the project requirements with you soon. Looking forward to your positive response. Kind Regards Louis Marketing Specialist Email: wukelili@tom.com From owner-freebsd-net@FreeBSD.ORG Mon Apr 20 19:26:25 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A574A8E4; Mon, 20 Apr 2015 19:26:25 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F3BC53E6; Mon, 20 Apr 2015 19:26:21 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t3KJQIM6060312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Apr 2015 22:26:18 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t3KJQIx4060311; Mon, 20 Apr 2015 22:26:18 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 20 Apr 2015 22:26:18 +0300 From: Gleb Smirnoff To: Mark Johnston Cc: freebsd-net@FreeBSD.org Subject: Re: moving struct bpf_if to bpf.c Message-ID: <20150420192618.GY883@FreeBSD.org> References: <20150418210855.GA50409@charmander.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150418210855.GA50409@charmander.west.isilon.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 19:26:25 -0000 On Sat, Apr 18, 2015 at 02:08:56PM -0700, Mark Johnston wrote: M> At the moment, bpf.h defines struct bpf_if differently depending on M> whether BPF_INTERNAL is #defined. This causes problems with CTF, as it M> results in a sort of bifurcation within the type graph: CTF sees two M> different struct bpf_ifs, and so every struct/union containing a struct M> bpf_if is duplicated, and so on. CTF currently imposes a limit of 2^15 M> distinct types within a container, and several people have been running M> into this limit. The type duplication exacerbates this problem. M> M> The change here fixes the issue by moving the definition of M> struct bpf_if to bpf.c, and making its externally-used fields M> available via struct bpf_if_ext: https://reviews.freebsd.org/D2319 M> M> In particular, the ext fields are at the same offsets within struct M> bpf_if as before, so this change should have no functional impact. M> Moreover, it reduces the number of types from 20879 to 15725 with my M> (stripped-down) kernel config on amd64. Would anyone be willing to M> review the proposed change? I've also placed the raw diff here: M> https://people.freebsd.org/~markj/patches/bpf_entrails.diff What actual software needs to look at struct bpf_if? I wonder if we can fix the software and hide the struct bpf_if into kernel entirely. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Apr 20 19:53:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1F592AF; Mon, 20 Apr 2015 19:53:27 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 932D09A3; Mon, 20 Apr 2015 19:53:27 +0000 (UTC) Received: by pacyx8 with SMTP id yx8so216493383pac.1; Mon, 20 Apr 2015 12:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PwwbBcCo08VAdfbjjC5+9Lqry9EH9Vb3kiioPIrKOd8=; b=wpaWpPXpHiApQrB/xDCW9ZNC/uYUbP7H2DwyeQo2dU6kKrVDhaXx5JXZVE7puds7av BV+xe/bLndMMT2p1jontDFJyTNTaWPy1lhNH0ZuqxG/eE7mJYFQENaj8fDTTMEPwqk0v 1uHCIhVrbDYb+2JeiKCrPSnX4h6GuNymEiN1FqUx4mK2/NOKoDL94vjHp8jehF2vxvll 7Ab+W0YYWgsIVKNawqBZ8Dg2leD2zhcRPBV6/HSmfbaaLFfubFDjr/uTZffSeWfs+P+S uZ7iikvtob2eXRPVg95PlLlvLZjGzT5nrO5A6hpKxudgJyQQirrAiu66JJFW3ZH09QQ+ JoHg== X-Received: by 10.70.131.193 with SMTP id oo1mr15862318pdb.63.1429559607226; Mon, 20 Apr 2015 12:53:27 -0700 (PDT) Received: from muskytusk ([104.236.250.12]) by mx.google.com with ESMTPSA id nn6sm19000871pdb.79.2015.04.20.12.53.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 12:53:25 -0700 (PDT) Sender: Mark Johnston Date: Mon, 20 Apr 2015 19:52:33 +0000 From: Mark Johnston To: Gleb Smirnoff Cc: freebsd-net@FreeBSD.org Subject: Re: moving struct bpf_if to bpf.c Message-ID: <20150420195233.GA71166@muskytusk> References: <20150418210855.GA50409@charmander.west.isilon.com> <20150420192618.GY883@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420192618.GY883@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 19:53:27 -0000 On Mon, Apr 20, 2015 at 10:26:18PM +0300, Gleb Smirnoff wrote: > On Sat, Apr 18, 2015 at 02:08:56PM -0700, Mark Johnston wrote: > M> At the moment, bpf.h defines struct bpf_if differently depending on > M> whether BPF_INTERNAL is #defined. This causes problems with CTF, as it > M> results in a sort of bifurcation within the type graph: CTF sees two > M> different struct bpf_ifs, and so every struct/union containing a struct > M> bpf_if is duplicated, and so on. CTF currently imposes a limit of 2^15 > M> distinct types within a container, and several people have been running > M> into this limit. The type duplication exacerbates this problem. > M> > M> The change here fixes the issue by moving the definition of > M> struct bpf_if to bpf.c, and making its externally-used fields > M> available via struct bpf_if_ext: https://reviews.freebsd.org/D2319 > M> > M> In particular, the ext fields are at the same offsets within struct > M> bpf_if as before, so this change should have no functional impact. > M> Moreover, it reduces the number of types from 20879 to 15725 with my > M> (stripped-down) kernel config on amd64. Would anyone be willing to > M> review the proposed change? I've also placed the raw diff here: > M> https://people.freebsd.org/~markj/patches/bpf_entrails.diff > > What actual software needs to look at struct bpf_if? I wonder if > we can fix the software and hide the struct bpf_if into kernel > entirely. bpf_peers_present() is defined in bpf.h so that it can be inlined, and it needs access to the bif_dlist field of struct bpf_if. As far as I can see, this is the only reason for exposing part of struct bpf_if. From owner-freebsd-net@FreeBSD.ORG Tue Apr 21 00:05:56 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61504FCB for ; Tue, 21 Apr 2015 00:05:56 +0000 (UTC) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0EEF9CC for ; Tue, 21 Apr 2015 00:05:55 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t3L05pGL030439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2015 10:05:53 +1000 Message-ID: <5535945F.90504@swin.edu.au> Date: Tue, 21 Apr 2015 10:05:51 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Congestion Control Modification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 00:05:56 -0000 Hi, On 04/18/2015 16:59, Karlis Laivins wrote: > Hello, > > I have read an interesting publication about a proposed modification of TCP > Congestion Control algorithm that would allow to improve it (the CC) by > dynamic bandwidth estimation. The idea seems so interesting that I would > like to try to implement it by modifying the NewReno code. > > Do I understand correctly that to do the above stated, I would create a > copy of source file (in my case - cc_newreno.c) located in /usr/src/sys/ > and rename it to, for example, cc_newreno_test.c and make changes to it? > How would I then compile it, and how would I create a newreno_test.ko file > that can be loaded into Kernel and tested? > > Thank you in advance for your answers! In case this helps shed some (probably incomplete) light, here are the steps I took late last year to make a modified version of NewReno: I start with copying the newreno module under sys/netinet/cc/cc_newreno.c as a template. The new source file will be called newrenoVarBeta.c /usr/src/sys/netinet/cc % cp cc_newreno.c cc_newrenoVarBeta.c /usr/src/sys/netinet/cc % Then create a modules definition based on /usr/src/sys/modules/cc/cc_cubic (because there isn't one for newreno per se) /usr/src/sys/netinet/cc % cd /usr/src/sys/modules/cc /usr/src/sys/modules/cc % mkdir cc_newrenoVarBeta /usr/src/sys/modules/cc % cp cc_cubic/Makefile cc_newrenoVarBeta/ /usr/src/sys/modules/cc % Tweak the cc_newrenoVarBeta/Makefile to say: KMOD= cc_newrenoVarBeta SRCS= cc_newrenoVarBeta.c Made my changes to cc_newrenoVarBeta.c (including changing the module's name from 'newreno' to something else) Then built/installed the new module with: /usr/src/sys/netinet/cc % cd /usr/src/sys/modules/cc/cc_newrenoVarBeta /usr/src/sys/modules/cc % make clean && make && make install [..build and install output..] /usr/src/sys/modules/cc % All being well, cc_newrenoVarBeta.ko should now exist under /boot/kernel Then use 'kldload cc_newrenoVarBeta.ko' to load your new CC algorithm If all goes well, your new module will appear (with whatever name you gave it) in the sysctl net.inet.tcp.cc.available list. Don't forget to actually select your new module with sysctl net.inet.tcp.cc.algorithm when running experiments. cheers, gja From owner-freebsd-net@FreeBSD.ORG Tue Apr 21 04:30:33 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A6EA277 for ; Tue, 21 Apr 2015 04:30:33 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E6D4A5F for ; Tue, 21 Apr 2015 04:30:32 +0000 (UTC) Received: by lagv1 with SMTP id v1so142248311lag.3 for ; Mon, 20 Apr 2015 21:30:30 -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=W1gRLNYmRGxR5XIiSacBOGRKSGVlTheYOP2dhv6G4CM=; b=H5TNGcd/6d0CIFBM8SJLZMJiWwihE/at+P8AzTsMGnJsIfTVRFPA4Wtae8Bt9YHZay iW1pAswmgi1pcPaRT9ygYU9oscIu1FpwsUFVtbR9IQOHSRoclco31KGHrRO0oz2k2qAX nTJl7ZVxlKBtA5gZqSnK4eO81AP5RWgqf4IIHv5B9E50oCs4ZQs/E3QdKmqR+hjqGOOk rR2RChUTt7k6+UHBIOjIvZLLaB6IH4zp5rm9Yya9T97DDrVE1jOkldySeCnHH8BcPqax jqU/tIv6LJzS47d6sHzjPGwAOeLIoM6tzB6M+t4QyzMtMQ+JtRVu6znIUHHdxmeYQGxK e0Yg== MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr10027127lab.82.1429590630346; Mon, 20 Apr 2015 21:30:30 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Mon, 20 Apr 2015 21:30:30 -0700 (PDT) In-Reply-To: <5535945F.90504@swin.edu.au> References: <5535945F.90504@swin.edu.au> Date: Tue, 21 Apr 2015 07:30:30 +0300 Message-ID: Subject: Re: Congestion Control Modification From: Karlis Laivins To: grenville armitage Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 04:30:33 -0000 Hi, Thank you very much for such a comprehensive description of how to properly create a loadable Kernel module, this does the trick - I was able to create the module successfully, load it into Kernel and set it as the congestion control algorithm used via sysctl net.inet.tcp.cc.algorithm=new (new - the name of my test module). Best Regards, Karlis On Tue, Apr 21, 2015 at 3:05 AM, grenville armitage wrote: > Hi, > > > On 04/18/2015 16:59, Karlis Laivins wrote: > >> Hello, >> >> I have read an interesting publication about a proposed modification of >> TCP >> Congestion Control algorithm that would allow to improve it (the CC) by >> dynamic bandwidth estimation. The idea seems so interesting that I would >> like to try to implement it by modifying the NewReno code. >> >> Do I understand correctly that to do the above stated, I would create a >> copy of source file (in my case - cc_newreno.c) located in /usr/src/sys/ >> and rename it to, for example, cc_newreno_test.c and make changes to it? >> How would I then compile it, and how would I create a newreno_test.ko file >> that can be loaded into Kernel and tested? >> >> Thank you in advance for your answers! >> > > In case this helps shed some (probably incomplete) light, here are the > steps > I took late last year to make a modified version of NewReno: > > I start with copying the newreno module under sys/netinet/cc/cc_newreno.c > as a template. The new source file will be called newrenoVarBeta.c > > /usr/src/sys/netinet/cc % cp cc_newreno.c cc_newrenoVarBeta.c > /usr/src/sys/netinet/cc % > > Then create a modules definition based on /usr/src/sys/modules/cc/cc_cubic > (because there isn't one for newreno per se) > > /usr/src/sys/netinet/cc % cd /usr/src/sys/modules/cc > /usr/src/sys/modules/cc % mkdir cc_newrenoVarBeta > /usr/src/sys/modules/cc % cp cc_cubic/Makefile cc_newrenoVarBeta/ > /usr/src/sys/modules/cc % > > Tweak the cc_newrenoVarBeta/Makefile to say: > > KMOD= cc_newrenoVarBeta > SRCS= cc_newrenoVarBeta.c > > Made my changes to cc_newrenoVarBeta.c (including changing the module's > name from 'newreno' to something else) > > Then built/installed the new module with: > > /usr/src/sys/netinet/cc % cd /usr/src/sys/modules/cc/cc_newrenoVarBeta > /usr/src/sys/modules/cc % make clean && make && make install > [..build and install output..] > /usr/src/sys/modules/cc % > > All being well, cc_newrenoVarBeta.ko should now exist under /boot/kernel > > Then use 'kldload cc_newrenoVarBeta.ko' to load your new CC algorithm > > If all goes well, your new module will appear (with whatever name you gave > it) in the sysctl net.inet.tcp.cc.available list. Don't forget to actually > select your new module with sysctl net.inet.tcp.cc.algorithm when running > experiments. > > cheers, > gja > > > > _______________________________________________ > 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 Tue Apr 21 06:14:29 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 098856FD; Tue, 21 Apr 2015 06:14:29 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7214716FD; Tue, 21 Apr 2015 06:14:27 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id t3L6EOoi062822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Apr 2015 09:14:24 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id t3L6EOIr062821; Tue, 21 Apr 2015 09:14:24 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 21 Apr 2015 09:14:24 +0300 From: Gleb Smirnoff To: Mark Johnston Cc: melifaro@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: moving struct bpf_if to bpf.c Message-ID: <20150421061424.GC883@glebius.int.ru> References: <20150418210855.GA50409@charmander.west.isilon.com> <20150420192618.GY883@FreeBSD.org> <20150420195233.GA71166@muskytusk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420195233.GA71166@muskytusk> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 06:14:29 -0000 On Mon, Apr 20, 2015 at 07:52:33PM +0000, Mark Johnston wrote: M> On Mon, Apr 20, 2015 at 10:26:18PM +0300, Gleb Smirnoff wrote: M> > On Sat, Apr 18, 2015 at 02:08:56PM -0700, Mark Johnston wrote: M> > M> At the moment, bpf.h defines struct bpf_if differently depending on M> > M> whether BPF_INTERNAL is #defined. This causes problems with CTF, as it M> > M> results in a sort of bifurcation within the type graph: CTF sees two M> > M> different struct bpf_ifs, and so every struct/union containing a struct M> > M> bpf_if is duplicated, and so on. CTF currently imposes a limit of 2^15 M> > M> distinct types within a container, and several people have been running M> > M> into this limit. The type duplication exacerbates this problem. M> > M> M> > M> The change here fixes the issue by moving the definition of M> > M> struct bpf_if to bpf.c, and making its externally-used fields M> > M> available via struct bpf_if_ext: https://reviews.freebsd.org/D2319 M> > M> M> > M> In particular, the ext fields are at the same offsets within struct M> > M> bpf_if as before, so this change should have no functional impact. M> > M> Moreover, it reduces the number of types from 20879 to 15725 with my M> > M> (stripped-down) kernel config on amd64. Would anyone be willing to M> > M> review the proposed change? I've also placed the raw diff here: M> > M> https://people.freebsd.org/~markj/patches/bpf_entrails.diff M> > M> > What actual software needs to look at struct bpf_if? I wonder if M> > we can fix the software and hide the struct bpf_if into kernel M> > entirely. M> M> bpf_peers_present() is defined in bpf.h so that it can be inlined, and M> it needs access to the bif_dlist field of struct bpf_if. As far as I can M> see, this is the only reason for exposing part of struct bpf_if. My suggestion is to un-inline it. Calling a static function isn't a big deal on modern machines. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Apr 21 20:50:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95493D1C for ; Tue, 21 Apr 2015 20:50:17 +0000 (UTC) Received: from mail-wg0-f70.google.com (mail-wg0-f70.google.com [74.125.82.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3786A1AA8 for ; Tue, 21 Apr 2015 20:50:16 +0000 (UTC) Received: by wgtl5 with SMTP id l5so48321500wgt.1 for ; Tue, 21 Apr 2015 13:50:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=aL8zuIacG2/6CQBKPFBsa8wLU6AJ3hhh1bUy0IIEhTI=; b=jJssfWU2eQBPzavAuMXJu9NEhpJwOAzv61HamYejCaJ97SZNs+2R/wAhV7LS/5d+Xq vKR55VJx2Ov+qyuAw3fKLrQiCyMbILDYp6xta9nFgup+3tMTFWFUKDAlw4SJmcUzwwnX 3X/52amWingXz2XCf5JEs/dsBVMNglOTuhAI/Qyj4S7+BeNPykjWQshQO/tPZ87zBBsR VxXvhH4kvn5ilCpORgiGfSkJhGJpYvgHEpKabBNAYwTBeChwxC8d7eKyMkbiJmlBmmyt eMtseVh/VFp9RJeuthcKnjSy3FVkCleYiojD6BupK+z8IJW1pY0YdOjkdcTdY6FSbKG2 ONnQ== X-Gm-Message-State: ALoCoQkjpWgmW04mevB61oLK0kIBlfmZlywuGo/abDIjFm8SsrKvdyj15fo0Gr0+4NlKnT4cWADr MIME-Version: 1.0 X-Received: by 10.112.40.9 with SMTP id t9mr21912988lbk.55.1429645665099; Tue, 21 Apr 2015 12:47:45 -0700 (PDT) Received: by 10.25.78.149 with HTTP; Tue, 21 Apr 2015 12:47:45 -0700 (PDT) Date: Tue, 21 Apr 2015 12:47:45 -0700 Message-ID: Subject: net.inet.ip.forwarding impact on throughput From: Scott Larson To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:50:17 -0000 We're in the process of migrating our network into the future with 40G at the core, including our firewall/traffic routers with 40G interfaces. An issue which this exposed and threw me for a week turns out to be directly related to net.inet.ip.forwarding and I'm looking to just get some insight on what exactly is occurring as a result of using it. What I am seeing is when that knob is set to 0, an identical pair of what will be PF/relayd servers with direct DAC links between each other using Chelsio T580s can sustain around 38Gb/s on iperf runs. However the moment I set that knob to 1, that throughput collapses down into the 3 to 5Gb/s range. As the old gear this is replacing is all GigE I'd never witnessed this. Twiddling net.inet.ip.fastforwarding has no apparent effect. I've not found any docs going in depth on what deeper changes enabling forwarding does to the network stack. Does it ultimately put a lower priority on traffic where the server functioning as the packet router is the final endpoint in exchange for having more resources available to route traffic across interfaces as would generally be the case? *[image: userimage]Scott Larson[image: los angeles] Lead Systems Administrator[image: wdlogo] [image: linkedin] [image: facebook] [image: twitter] [image: instagram] T 310 823 8238 x1106 <310%20823%208238%20x1106> | M 310 904 8818 <310%20904%208818>* From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 01:53:48 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7570DED8 for ; Wed, 22 Apr 2015 01:53:48 +0000 (UTC) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3980919DA for ; Wed, 22 Apr 2015 01:53:48 +0000 (UTC) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 230247E88D; Wed, 22 Apr 2015 11:45:43 +1000 (EST) Message-ID: <5536FD31.40000@freebsd.org> Date: Wed, 22 Apr 2015 11:45:21 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Peter Holm , net@freebsd.org Subject: Re: panic: SACK scoreboard must not be empty References: <20150415110401.GA26326@x2.osted.lan> In-Reply-To: <20150415110401.GA26326@x2.osted.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 01:53:48 -0000 Hi Peter, On 04/15/15 21:04, Peter Holm wrote: > Seen during i386 stress tests. > > db_trace_self_wrapper(c11e20fc,0,c11b79d4,1eb,e47578e0,...) at db_trace_self_wrapper+0x2a/frame 0xe47578b0 > kdb_backtrace(c139e637,2,c120851d,e4757984,e4757940,...) at kdb_backtrace+0x2d/frame 0xe4757918 > vpanic(c155b86a,100,c120851d,e4757984,e4757984,...) at vpanic+0x11d/frame 0xe4757954 > kassert_panic(c120851d,0,8,164,16,...) at kassert_panic+0xe6/frame 0xe4757978 > tcp_sack_doack(e047d900,e4757a48,e9eeab30,5f8,c15a9298,...) at tcp_sack_doack+0x405/frame 0xe47579f0 > tcp_do_segment(df801720,e047d900,40,0,0,...) at tcp_do_segment+0x21c2/frame 0xe4757aa0 > tcp_input(e4757bec,e4757be8,6,0,e4757be8,...) at tcp_input+0xfbc/frame 0xe4757ba0 > ip_input(e1cb5800,0,c11f6228,2f0,45,...) at ip_input+0x17c/frame 0xe4757c0c > swi_net(c1c25880,c11d6fed,54f,8f6da840,c8a209c8,...) at swi_net+0x1a3/frame 0xe4757c4c > intr_event_execute_handlers(c156a310,c8a20980,c11d6fed,54f,0,...) at intr_event_execute_handlers+0xdb/frame 0xe4757c74 > ithread_loop(c88d4f50,e4757ce8,c11d6d7c,3dc,0,...) at ithread_loop+0x87/frame 0xe4757cac > fork_exit(c0b2c9d0,c88d4f50,e4757ce8) at fork_exit+0x7e/frame 0xe4757cd4 > fork_trampoline() at fork_trampoline+0x8/frame 0xe4757cd4 > > Details: > https://people.freebsd.org/~pho/stress/log/kostik794.txt > >From the looks of the log, you don't have a core? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 02:31:20 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5666B514 for ; Wed, 22 Apr 2015 02:31:20 +0000 (UTC) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id AC8BD1CE3 for ; Wed, 22 Apr 2015 02:31:19 +0000 (UTC) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id F2FB07E839 for ; Wed, 22 Apr 2015 12:31:16 +1000 (EST) Message-ID: <553707DF.20305@freebsd.org> Date: Wed, 22 Apr 2015 12:30:55 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: FYI: TSO results in significant IP ID reuse on short time scales Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 02:31:20 -0000 Hi all, An interesting observation I made last night digging into some pcap files captured on a server doing TSO/LRO and client side bridge seeing all packets as they were on the wire... When doing TSO, the NIC takes the stack supplied template IP/TCP header and increments the IP ID field for each segment put on the wire, resulting in IP IDs of n, n+1, n+2, etc. For the next TSO chunk, the stack thinks it's sending the next logical segment, and if no or few packets have been sent in the meantime, sets the IP ID to n+1, and the NIC then diligently sends out segments with n+1, n+2, n+3 etc. This behaviour causes a lot of segments within the same window/RTT to have duplicate IP IDs. For obvious reasons, this is rather unfortunate if packets are not marked DF. This also potentially might upset some middle boxes doing 5-tuple based flow normalisation, although IP ID randomisation has probably weeded out most boxes that would have had problems with repeated IP IDs. At any rate, this is a cautionary note to file away in the back of your minds, especially when DF is not set for your packets (probably when PMTUD is disabled or not working). There's also an open question as to whether there might be some value in having the IP code increment the IP ID counter based on the number of MSS segments the packet nominally represents, so that the stack generated IP ID will not overlap with TSO segments when sequential generation is used. Thoughts welcome. Below is a concrete example from the pcap files I was poking at last night, with IP addresses sanitised. Note the client was behind a NAT doing port translation, but it was passing IP IDs through untouched as far as I can tell. server side: > 17:05:12.882836 IP (tos 0x0, ttl 64, id 60276, offset 0, flags [DF], proto TCP (6), length 14532, bad cksum 0 (->c7b7)!) > server.80 > client-nat.24122: Flags [.], seq 68344824:68359304, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 14480 > 17:05:12.885424 IP (tos 0x0, ttl 64, id 60277, offset 0, flags [DF], proto TCP (6), length 17428, bad cksum 0 (->bc66)!) > server.80 > client-nat.24122: Flags [.], seq 68359304:68376680, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 17376 is seen as this on the client side: > 7:05:12.882597 IP (tos 0x0, ttl 57, id 60276, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xb45b (correct), seq 68344824:68346272, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882673 IP (tos 0x0, ttl 57, id 60277, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xb1f4 (correct), seq 68346272:68347720, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882676 IP (tos 0x0, ttl 57, id 60278, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0x0821 (correct), seq 68347720:68349168, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882678 IP (tos 0x0, ttl 57, id 60279, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xa768 (correct), seq 68349168:68350616, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882681 IP (tos 0x0, ttl 57, id 60280, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xc26c (correct), seq 68350616:68352064, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882683 IP (tos 0x0, ttl 57, id 60281, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xf750 (correct), seq 68352064:68353512, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882686 IP (tos 0x0, ttl 57, id 60282, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0x95e9 (correct), seq 68353512:68354960, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882688 IP (tos 0x0, ttl 57, id 60283, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xb0d6 (correct), seq 68354960:68356408, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882698 IP (tos 0x0, ttl 57, id 60284, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xe7ed (correct), seq 68356408:68357856, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 > 17:05:12.882772 IP (tos 0x0, ttl 57, id 60285, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xec4d (correct), seq 68357856:68359304, ack 2096907437, win 2050, options [nop,nop,TS val 1580984794 ecr 87033596], length 1448 Note the reuse begins here for the transmission of the second TSO chunk of 17376 bytes. > 17:05:12.884413 IP (tos 0x0, ttl 57, id 60277, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xd935 (correct), seq 68359304:68360752, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884416 IP (tos 0x0, ttl 57, id 60278, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xce96 (correct), seq 68360752:68362200, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884418 IP (tos 0x0, ttl 57, id 60279, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0x273d (correct), seq 68362200:68363648, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884420 IP (tos 0x0, ttl 57, id 60280, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xc86b (correct), seq 68363648:68365096, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884422 IP (tos 0x0, ttl 57, id 60281, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xbde3 (correct), seq 68365096:68366544, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884423 IP (tos 0x0, ttl 57, id 60282, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0x144a (correct), seq 68366544:68367992, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884425 IP (tos 0x0, ttl 57, id 60283, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xb999 (correct), seq 68367992:68369440, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884427 IP (tos 0x0, ttl 57, id 60284, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0x982d (correct), seq 68369440:68370888, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884498 IP (tos 0x0, ttl 57, id 60285, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xa79a (correct), seq 68370888:68372336, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884500 IP (tos 0x0, ttl 57, id 60286, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xbc50 (correct), seq 68372336:68373784, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884501 IP (tos 0x0, ttl 57, id 60287, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0xc84c (correct), seq 68373784:68375232, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 > 17:05:12.884503 IP (tos 0x0, ttl 57, id 60288, offset 0, flags [DF], proto TCP (6), length 1500) > server.80 > client-priv.57140: Flags [.], cksum 0x7468 (correct), seq 68375232:68376680, ack 2096907437, win 2050, options [nop,nop,TS val 1580984796 ecr 87033598], length 1448 Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 04:50:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2081C810; Wed, 22 Apr 2015 04:50:51 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E061C1B91; Wed, 22 Apr 2015 04:50:50 +0000 (UTC) Received: by igblo3 with SMTP id lo3so32822867igb.0; Tue, 21 Apr 2015 21:50:50 -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:message-id:subject :from:to:cc:content-type; bh=88b2NSyQA/XqCeqh9ivmQDx0aSr2FsCTH3l5Gx9NUvY=; b=oo+kkcMiwtETtdhOeREKpxyZGb0xGUenSVajcAg9mPuXJGYBMPr9ImlINCsi3/c0ad y/UssKS7OuWvpnIQFEadksQ8aXdL+kJ3jgTD43IXzfUrQt27D0NsjdBQay2mc/AmX62H feGP9zEJR8lwdiAbUuKULpSTGBk0znKCbVnnBgcMT6OvSaKZgTMySp+LMrULfUkdkliG tMR9fNixEQbhgzsTgyQGbdqy+5WEquNRhjvof4Sisl46F5Bf3M7a/1H6CnC4mk8n96Lc clH3NUP6pSnLqpMIC4o78yaNU6wppqZTNwmv1qHm5FYbxxKqgnVe1GCxLDM6jLNf9PpX GHEQ== MIME-Version: 1.0 X-Received: by 10.107.136.25 with SMTP id k25mr32744056iod.88.1429678250350; Tue, 21 Apr 2015 21:50:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.17.194 with HTTP; Tue, 21 Apr 2015 21:50:50 -0700 (PDT) In-Reply-To: <553707DF.20305@freebsd.org> References: <553707DF.20305@freebsd.org> Date: Tue, 21 Apr 2015 21:50:50 -0700 X-Google-Sender-Auth: e3jcyHEZfdWvxUAsIzzuO5GnSbg Message-ID: Subject: Re: FYI: TSO results in significant IP ID reuse on short time scales From: Adrian Chadd To: Lawrence Stewart Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 04:50:51 -0000 [snip] I bet doing a pre-allocation scheme would be fine. Ie, you make some guess based on payload size and MSS, allocate those, don't worry if you allocate too many. -adrian From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 06:58:42 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0319614 for ; Wed, 22 Apr 2015 06:58:42 +0000 (UTC) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "goliath.siemens.de", Issuer "savelogs.saacon.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A1331751 for ; Wed, 22 Apr 2015 06:58:41 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.14.3/8.14.3) with ESMTP id t3M6wXEa012504; Wed, 22 Apr 2015 08:58:34 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.14.3/8.14.3) with ESMTP id t3M6wX6I021865; Wed, 22 Apr 2015 08:58:33 +0200 Received: (from user@localhost) by curry.mchp.siemens.de (8.14.9/8.14.9) id t3M6wXQk081898; Date: Wed, 22 Apr 2015 08:58:33 +0200 From: Andre Albsmeier To: Mike Tancsa Cc: Andre Albsmeier , freebsd-net@freebsd.org Subject: Re: Intel em (82574L and 82573L) problems: stopping on high network and cpu load (Watchdog timeout) Message-ID: <20150422065833.GA66880@bali> References: <20150413101626.GA47411@bali> <552BBF48.4090808@sentex.net> <20150414055445.GA54779@bali> <552D1DAC.9040104@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552D1DAC.9040104@sentex.net> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 06:58:42 -0000 On Tue, 14-Apr-2015 at 10:01:16 -0400, Mike Tancsa wrote: > On 4/14/2015 1:54 AM, Andre Albsmeier wrote: > > > > Is this an em specific issue or should one avoid TSO generally > > at the moment? That is, should I disable it on machines with > > msk (and maybe other) interfaces as well? > > em specific I think. This thread has some info on what might be going on > > https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080081.html For the records: I can definitely say that the problem did not appear again since I disabled TSO on the em adapters. I've left it enabled on the msk adapters, so this is indeed an em-only problem (at least here). TSO should be disabled in the em driver until fixed. Thanks again for the hint. -Andre From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 09:20:08 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D554DD36 for ; Wed, 22 Apr 2015 09:20:08 +0000 (UTC) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id 8D3A2167D for ; Wed, 22 Apr 2015 09:20:07 +0000 (UTC) Received: (qmail 16464 invoked from network); 22 Apr 2015 09:20:00 -0000 Received: from 188.182.139.176 (HELO x2.osted.lan) (188.182.139.176) by relay02.pair.com with SMTP; 22 Apr 2015 09:20:00 -0000 X-pair-Authenticated: 188.182.139.176 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.9/8.14.9) with ESMTP id t3M9JxId086846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Apr 2015 11:19:59 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.9/8.14.9/Submit) id t3M9Jwgi086845; Wed, 22 Apr 2015 11:19:58 +0200 (CEST) (envelope-from pho) Date: Wed, 22 Apr 2015 11:19:58 +0200 From: Peter Holm To: Lawrence Stewart Cc: net@freebsd.org Subject: Re: panic: SACK scoreboard must not be empty Message-ID: <20150422091958.GA81930@x2.osted.lan> References: <20150415110401.GA26326@x2.osted.lan> <5536FD31.40000@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5536FD31.40000@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 09:20:08 -0000 On Wed, Apr 22, 2015 at 11:45:21AM +1000, Lawrence Stewart wrote: > Hi Peter, > > On 04/15/15 21:04, Peter Holm wrote: > > Seen during i386 stress tests. > > > > db_trace_self_wrapper(c11e20fc,0,c11b79d4,1eb,e47578e0,...) at db_trace_self_wrapper+0x2a/frame 0xe47578b0 > > kdb_backtrace(c139e637,2,c120851d,e4757984,e4757940,...) at kdb_backtrace+0x2d/frame 0xe4757918 > > vpanic(c155b86a,100,c120851d,e4757984,e4757984,...) at vpanic+0x11d/frame 0xe4757954 > > kassert_panic(c120851d,0,8,164,16,...) at kassert_panic+0xe6/frame 0xe4757978 > > tcp_sack_doack(e047d900,e4757a48,e9eeab30,5f8,c15a9298,...) at tcp_sack_doack+0x405/frame 0xe47579f0 > > tcp_do_segment(df801720,e047d900,40,0,0,...) at tcp_do_segment+0x21c2/frame 0xe4757aa0 > > tcp_input(e4757bec,e4757be8,6,0,e4757be8,...) at tcp_input+0xfbc/frame 0xe4757ba0 > > ip_input(e1cb5800,0,c11f6228,2f0,45,...) at ip_input+0x17c/frame 0xe4757c0c > > swi_net(c1c25880,c11d6fed,54f,8f6da840,c8a209c8,...) at swi_net+0x1a3/frame 0xe4757c4c > > intr_event_execute_handlers(c156a310,c8a20980,c11d6fed,54f,0,...) at intr_event_execute_handlers+0xdb/frame 0xe4757c74 > > ithread_loop(c88d4f50,e4757ce8,c11d6d7c,3dc,0,...) at ithread_loop+0x87/frame 0xe4757cac > > fork_exit(c0b2c9d0,c88d4f50,e4757ce8) at fork_exit+0x7e/frame 0xe4757cd4 > > fork_trampoline() at fork_trampoline+0x8/frame 0xe4757cd4 > > > > Details: > > https://people.freebsd.org/~pho/stress/log/kostik794.txt > > > > >From the looks of the log, you don't have a core? > Sure, I have. https://people.freebsd.org/~pho/kernel+vmcore.792.txz -- Peter From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 16:22:59 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5DFC6CE for ; Wed, 22 Apr 2015 16:22:59 +0000 (UTC) Received: from bin.sds.com (bin.sds.com [198.133.242.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bin.sds.com", Issuer "bin.sds.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 88FDD1569 for ; Wed, 22 Apr 2015 16:22:59 +0000 (UTC) Received: from dhcp-assigned205.sds.com (dhcp-assigned205.sds.com [10.0.1.205] (may be forged)) (authenticated bits=0) by bin.sds.com (8.15.1/8.14.7) with ESMTPSA id t3MG20QJ013567 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Apr 2015 09:02:01 -0700 (PDT) (envelope-from scotto@sds.com) Message-ID: <5537C5F8.1090000@sds.com> Date: Wed, 22 Apr 2015 09:02:00 -0700 From: "Scott O'Connell" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: bhyve with vlans - host and vm can't pass traffic X-Virus-Scanned: clamav-milter 0.98.6 at bin.sds.com X-Virus-Status: Clean Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:22:59 -0000 I'm very new to bhyve and am having an issue. I'm trying to get VM's and VLAN's working. I'm able to get VLAN's working in a VM, but the VM and the VMHOST, can't communicate with each other on the same vlan. Using 10.1-RELEASE-p9 for both VMHOST01 and DEV. Upstream from the VMHOST on lagg0 is a Cisco 3750G. VMHOST01 before starting VM: bge0: flags=8843 metric 0 mtu 1500 options=c019b ether f0:1f:af:dd:2e:c5 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active bge1: flags=8843 metric 0 mtu 1500 options=c019b ether f0:1f:af:dd:2e:c5 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 lagg0: flags=8843 metric 0 mtu 1500 options=c019b ether f0:1f:af:dd:2e:c5 nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: bge1 flags=1c laggport: bge0 flags=1c vlan100: flags=8843 metric 0 mtu 1500 options=103 ether f0:1f:af:dd:2e:c5 inet 10.0.1.17 netmask 0xffffff00 broadcast 10.0.1.255 nd6 options=29 media: Ethernet autoselect status: active vlan: 100 parent interface: lagg0 VMHOST after starting VM (added tap0 & bridge0): tap0: flags=8902 metric 0 mtu 1500 options=80000 ether 00:bd:70:71:1d:00 nd6 options=29 media: Ethernet autoselect status: no carrier bridge0: flags=8843 metric 0 mtu 1500 ether 02:d3:e4:02:03:00 nd6 options=1 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 6 priority 128 path cost 2000000 member: lagg0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 10000 Note that the "status: no carrier" is because I hadn't brought up the VM yet. It properly changes to the following after the VM is started: tap0: flags=8943 metric 0 mtu 1500 options=80000 ether 00:bd:70:71:1d:00 nd6 options=29 media: Ethernet autoselect status: active Opened by PID 70827 VM: vtnet0: flags=8943 metric 0 mtu 1500 options=80028 ether 00:a0:98:2b:34:37 nd6 options=29 media: Ethernet 10Gbase-T status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 vlan100: flags=8843 metric 0 mtu 1500 ether 00:a0:98:2b:34:37 inet 10.0.1.6 netmask 0xffffff00 broadcast 10.0.1.255 nd6 options=29 media: Ethernet 10Gbase-T status: active vlan: 100 parent interface: vtnet0 With this configuration, both VMHOST01 and DEV can communicate anywhere, EXCEPT to each other using their IP on VLAN100. The ultimate goal is to have more than one VLAN presented to the VM, whether it exists on the VMHOST or not. Where did I go wrong? Thanks in advance, scotto From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 22:04:22 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 572B49FD; Wed, 22 Apr 2015 22:04:22 +0000 (UTC) Received: from st11p00im-asmtp003.me.com (st11p00im-asmtp003.me.com [17.172.80.97]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 316B91BF2; Wed, 22 Apr 2015 22:04:21 +0000 (UTC) Received: from akita.localnet (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p00im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NN000AHLUR8BC10@st11p00im-asmtp003.me.com>; Sat, 18 Apr 2015 21:37:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-18_02:2015-04-17,2015-04-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504180201 From: Rui Paulo To: freebsd-net@freebsd.org Cc: Mark Johnston Subject: Re: moving struct bpf_if to bpf.c Date: Sat, 18 Apr 2015 14:37:56 -0700 Message-id: <3983189.kvm2TuS0U7@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-reply-to: <20150418210855.GA50409@charmander.west.isilon.com> References: <20150418210855.GA50409@charmander.west.isilon.com> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:04:22 -0000 On Saturday 18 April 2015 14:08:56 Mark Johnston wrote: > Hello, > > At the moment, bpf.h defines struct bpf_if differently depending on > whether BPF_INTERNAL is #defined. This causes problems with CTF, as it > results in a sort of bifurcation within the type graph: CTF sees two > different struct bpf_ifs, and so every struct/union containing a struct > bpf_if is duplicated, and so on. CTF currently imposes a limit of 2^15 > distinct types within a container, and several people have been running > into this limit. The type duplication exacerbates this problem. > > The change here fixes the issue by moving the definition of > struct bpf_if to bpf.c, and making its externally-used fields > available via struct bpf_if_ext: https://reviews.freebsd.org/D2319 > > In particular, the ext fields are at the same offsets within struct > bpf_if as before, so this change should have no functional impact. > Moreover, it reduces the number of types from 20879 to 15725 with my > (stripped-down) kernel config on amd64. Would anyone be willing to > review the proposed change? I've also placed the raw diff here: > https://people.freebsd.org/~markj/patches/bpf_entrails.diff Looks good to me. Thanks for fixing this! -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 22:33:27 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E63E1EA for ; Wed, 22 Apr 2015 22:33:27 +0000 (UTC) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 451371EF4 for ; Wed, 22 Apr 2015 22:33:27 +0000 (UTC) Received: from lgwl-lstewart2.corp.netflix.com (c110-22-60-167.eburwd6.vic.optusnet.com.au [110.22.60.167]) by lauren.room52.net (Postfix) with ESMTPSA id 1AB6C7E81E; Thu, 23 Apr 2015 08:33:25 +1000 (EST) Message-ID: <5538219C.7090600@freebsd.org> Date: Thu, 23 Apr 2015 08:33:00 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Peter Holm CC: net@freebsd.org Subject: Re: panic: SACK scoreboard must not be empty References: <20150415110401.GA26326@x2.osted.lan> <5536FD31.40000@freebsd.org> <20150422091958.GA81930@x2.osted.lan> In-Reply-To: <20150422091958.GA81930@x2.osted.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DNS_FROM_AHBL_RHSBL, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 22:33:27 -0000 On 04/22/15 19:19, Peter Holm wrote: > On Wed, Apr 22, 2015 at 11:45:21AM +1000, Lawrence Stewart wrote: >> Hi Peter, >> >> On 04/15/15 21:04, Peter Holm wrote: >>> Seen during i386 stress tests. >>> >>> db_trace_self_wrapper(c11e20fc,0,c11b79d4,1eb,e47578e0,...) at db_trace_self_wrapper+0x2a/frame 0xe47578b0 >>> kdb_backtrace(c139e637,2,c120851d,e4757984,e4757940,...) at kdb_backtrace+0x2d/frame 0xe4757918 >>> vpanic(c155b86a,100,c120851d,e4757984,e4757984,...) at vpanic+0x11d/frame 0xe4757954 >>> kassert_panic(c120851d,0,8,164,16,...) at kassert_panic+0xe6/frame 0xe4757978 >>> tcp_sack_doack(e047d900,e4757a48,e9eeab30,5f8,c15a9298,...) at tcp_sack_doack+0x405/frame 0xe47579f0 >>> tcp_do_segment(df801720,e047d900,40,0,0,...) at tcp_do_segment+0x21c2/frame 0xe4757aa0 >>> tcp_input(e4757bec,e4757be8,6,0,e4757be8,...) at tcp_input+0xfbc/frame 0xe4757ba0 >>> ip_input(e1cb5800,0,c11f6228,2f0,45,...) at ip_input+0x17c/frame 0xe4757c0c >>> swi_net(c1c25880,c11d6fed,54f,8f6da840,c8a209c8,...) at swi_net+0x1a3/frame 0xe4757c4c >>> intr_event_execute_handlers(c156a310,c8a20980,c11d6fed,54f,0,...) at intr_event_execute_handlers+0xdb/frame 0xe4757c74 >>> ithread_loop(c88d4f50,e4757ce8,c11d6d7c,3dc,0,...) at ithread_loop+0x87/frame 0xe4757cac >>> fork_exit(c0b2c9d0,c88d4f50,e4757ce8) at fork_exit+0x7e/frame 0xe4757cd4 >>> fork_trampoline() at fork_trampoline+0x8/frame 0xe4757cd4 >>> >>> Details: >>> https://people.freebsd.org/~pho/stress/log/kostik794.txt >>> >> >> >From the looks of the log, you don't have a core? >> > > Sure, I have. > https://people.freebsd.org/~pho/kernel+vmcore.792.txz > Oh, great. For some reason I thought I saw a filesystem full message related to capturing the dump in the log, but it was just my brain playing tricks on me :) I'll take a look at this panic. Thanks for the report and crash dump. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Apr 22 23:45:04 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79090E58 for ; Wed, 22 Apr 2015 23:45:04 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40B0F167F for ; Wed, 22 Apr 2015 23:45:03 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t3MNGBqt021816 for ; Wed, 22 Apr 2015 18:16:11 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id 14BCB18A8DD for ; Wed, 22 Apr 2015 18:16:01 -0500 (CDT) Message-ID: <55382C0A.1040505@shrew.net> Date: Wed, 22 Apr 2015 18:17:30 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bhyve with vlans - host and vm can't pass traffic References: <5537C5F8.1090000@sds.com> In-Reply-To: <5537C5F8.1090000@sds.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Wed, 22 Apr 2015 18:16:11 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 23:45:04 -0000 On 4/22/2015 11:02 AM, Scott O'Connell wrote: > I'm very new to bhyve and am having an issue. I'm trying to get VM's > and VLAN's working. > > I'm able to get VLAN's working in a VM, but the VM and the VMHOST, > can't communicate with each other on the same vlan. > > Using 10.1-RELEASE-p9 for both VMHOST01 and DEV. Upstream from the > VMHOST on lagg0 is a Cisco 3750G. > > VMHOST01 before starting VM: > > bge0: flags=8843 > metric 0 mtu 1500 > options=c019b > > ether f0:1f:af:dd:2e:c5 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > bge1: flags=8843 > metric 0 mtu 1500 > options=c019b > > ether f0:1f:af:dd:2e:c5 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > lagg0: flags=8843 > metric 0 mtu 1500 > options=c019b > > ether f0:1f:af:dd:2e:c5 > nd6 options=29 > media: Ethernet autoselect > status: active > laggproto lacp lagghash l2,l3,l4 > laggport: bge1 flags=1c > laggport: bge0 flags=1c > vlan100: flags=8843 > metric 0 mtu 1500 > options=103 > ether f0:1f:af:dd:2e:c5 > inet 10.0.1.17 netmask 0xffffff00 broadcast 10.0.1.255 > nd6 options=29 > media: Ethernet autoselect > status: active > vlan: 100 parent interface: lagg0 > > VMHOST after starting VM (added tap0 & bridge0): > > tap0: flags=8902 metric 0 > mtu 1500 > options=80000 > ether 00:bd:70:71:1d:00 > nd6 options=29 > media: Ethernet autoselect > status: no carrier > bridge0: flags=8843 > metric 0 mtu 1500 > ether 02:d3:e4:02:03:00 > nd6 options=1 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 2000000 > member: lagg0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 10000 > > > Note that the "status: no carrier" is because I hadn't brought up the > VM yet. It properly changes to the following after the VM is started: > > tap0: > flags=8943 metric 0 > mtu 1500 > options=80000 > ether 00:bd:70:71:1d:00 > nd6 options=29 > media: Ethernet autoselect > status: active > Opened by PID 70827 > > VM: > vtnet0: > flags=8943 metric 0 > mtu 1500 > options=80028 > ether 00:a0:98:2b:34:37 > nd6 options=29 > media: Ethernet 10Gbase-T > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > vlan100: flags=8843 > metric 0 mtu 1500 > ether 00:a0:98:2b:34:37 > inet 10.0.1.6 netmask 0xffffff00 broadcast 10.0.1.255 > nd6 options=29 > media: Ethernet 10Gbase-T > status: active > vlan: 100 parent interface: vtnet0 > > > With this configuration, both VMHOST01 and DEV can communicate > anywhere, EXCEPT to each other using their IP on VLAN100. > > The ultimate goal is to have more than one VLAN presented to the VM, > whether it exists on the VMHOST or not. > > Where did I go wrong? > > Thanks in advance, > scotto > Scott, Have you tried creating the bridge on vlan100 device instead of lagg0 and assigning 10.0.1.6/24 directly to vtnet0 in the VM? I understand that you would prefer to do the VLAN tagging inside the VM, but have you tried it the other way just to make sure that untagged packets are being passed properly? If so, it could be that either the vtnet0 or the tap0 interface is choking on the VLAN tag. Another thing to try would be to run 'tcpdump -i tap0' in vmhost0 while the VM is trying to send packets to see if any frames are captured and, consequently, if they contain a VLAN tag at the head of the frame. -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 01:34:01 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C58D72D0 for ; Thu, 23 Apr 2015 01:34:01 +0000 (UTC) Received: from bin.sds.com (bin.sds.com [198.133.242.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bin.sds.com", Issuer "bin.sds.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A699F1227 for ; Thu, 23 Apr 2015 01:34:01 +0000 (UTC) Received: from [10.0.1.189] (dhcp-assigned189.sds.com [10.0.1.189] (may be forged)) (authenticated bits=0) by bin.sds.com (8.15.1/8.14.7) with ESMTPSA id t3N1XxnY053544 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Apr 2015 18:34:00 -0700 (PDT) (envelope-from scotto@sds.com) X-Authentication-Warning: bin.sds.com: Host dhcp-assigned189.sds.com [10.0.1.189] (may be forged) claimed to be [10.0.1.189] Message-ID: <55384C24.5040607@sds.com> Date: Wed, 22 Apr 2015 18:34:28 -0700 From: "Scott O'Connell" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bhyve with vlans - host and vm can't pass traffic References: <5537C5F8.1090000@sds.com> <55382C0A.1040505@shrew.net> In-Reply-To: <55382C0A.1040505@shrew.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.6 at bin.sds.com X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 01:34:01 -0000 Thanks for your reply, Matthew. See results below: On 4/22/2015 4:17 PM, Matthew Grooms wrote: > On 4/22/2015 11:02 AM, Scott O'Connell wrote: >> I'm very new to bhyve and am having an issue. I'm trying to get VM's >> and VLAN's working. >> >> I'm able to get VLAN's working in a VM, but the VM and the VMHOST, >> can't communicate with each other on the same vlan. >> >> Using 10.1-RELEASE-p9 for both VMHOST01 and DEV. Upstream from the >> VMHOST on lagg0 is a Cisco 3750G. >> >> VMHOST01 before starting VM: >> >> bge0: flags=8843 >> metric 0 mtu 1500 >> options=c019b >> >> ether f0:1f:af:dd:2e:c5 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> bge1: flags=8843 >> metric 0 mtu 1500 >> options=c019b >> >> ether f0:1f:af:dd:2e:c5 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> lo0: flags=8049 metric 0 mtu >> 16384 >> options=600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=21 >> lagg0: flags=8843 >> metric 0 mtu 1500 >> options=c019b >> >> ether f0:1f:af:dd:2e:c5 >> nd6 options=29 >> media: Ethernet autoselect >> status: active >> laggproto lacp lagghash l2,l3,l4 >> laggport: bge1 flags=1c >> laggport: bge0 flags=1c >> vlan100: flags=8843 >> metric 0 mtu 1500 >> options=103 >> ether f0:1f:af:dd:2e:c5 >> inet 10.0.1.17 netmask 0xffffff00 broadcast 10.0.1.255 >> nd6 options=29 >> media: Ethernet autoselect >> status: active >> vlan: 100 parent interface: lagg0 >> >> VMHOST after starting VM (added tap0 & bridge0): >> >> tap0: flags=8902 metric >> 0 mtu 1500 >> options=80000 >> ether 00:bd:70:71:1d:00 >> nd6 options=29 >> media: Ethernet autoselect >> status: no carrier >> bridge0: flags=8843 >> metric 0 mtu 1500 >> ether 02:d3:e4:02:03:00 >> nd6 options=1 >> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >> member: tap0 flags=143 >> ifmaxaddr 0 port 6 priority 128 path cost 2000000 >> member: lagg0 flags=143 >> ifmaxaddr 0 port 4 priority 128 path cost 10000 >> >> >> Note that the "status: no carrier" is because I hadn't brought up the >> VM yet. It properly changes to the following after the VM is started: >> >> tap0: >> flags=8943 metric 0 >> mtu 1500 >> options=80000 >> ether 00:bd:70:71:1d:00 >> nd6 options=29 >> media: Ethernet autoselect >> status: active >> Opened by PID 70827 >> >> VM: >> vtnet0: >> flags=8943 metric 0 >> mtu 1500 >> options=80028 >> ether 00:a0:98:2b:34:37 >> nd6 options=29 >> media: Ethernet 10Gbase-T >> status: active >> lo0: flags=8049 metric 0 mtu >> 16384 >> options=600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=21 >> vlan100: flags=8843 >> metric 0 mtu 1500 >> ether 00:a0:98:2b:34:37 >> inet 10.0.1.6 netmask 0xffffff00 broadcast 10.0.1.255 >> nd6 options=29 >> media: Ethernet 10Gbase-T >> status: active >> vlan: 100 parent interface: vtnet0 >> >> >> With this configuration, both VMHOST01 and DEV can communicate >> anywhere, EXCEPT to each other using their IP on VLAN100. >> >> The ultimate goal is to have more than one VLAN presented to the VM, >> whether it exists on the VMHOST or not. >> >> Where did I go wrong? >> >> Thanks in advance, >> scotto >> > > Scott, > > Have you tried creating the bridge on vlan100 device instead of lagg0 > and assigning 10.0.1.6/24 directly to vtnet0 in the VM? I understand > that you would prefer to do the VLAN tagging inside the VM, but have > you tried it the other way just to make sure that untagged packets are > being passed properly? If so, it could be that either the vtnet0 or > the tap0 interface is choking on the VLAN tag. > > Another thing to try would be to run 'tcpdump -i tap0' in vmhost0 > while the VM is trying to send packets to see if any frames are > captured and, consequently, if they contain a VLAN tag at the head of > the frame. > > -Matthew > _______________________________________________ > 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" I tried your suggestions. I was successful in changing the vmhost01 bridge to include vlan100 and tap0, and in the vm (dev) binding the address directly to vtnet0. On the VMHOST: tap0: flags=8943 metric 0 mtu 1500 options=80000 ether 00:bd:4c:d1:02:00 media: Ethernet autoselect status: active Opened by PID 888 bridge0: flags=8843 metric 0 mtu 1500 ether 02:d3:e4:02:03:00 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143 ifmaxaddr 0 port 6 priority 128 path cost 2000000 member: vlan100 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 2000000 In the VM: vtnet0: flags=8943 metric 0 mtu 1500 options=80028 ether 00:a0:98:2b:34:37 inet 10.0.1.6 netmask 0xffffff00 broadcast 10.0.1.255 nd6 options=29 media: Ethernet 10Gbase-T status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 The same results with regard to connectivity. Both the VMHOST and the VM can communicate everywhere, except with each other. I'm not sure how much detail to post, or what protocol I should be testing from the tcpdump, but here are a couple of relevant portions. Captured on the VMHOST with "tcpdump -i tap0 -n -vv", and on the VM with "tcpdump -i vtnet0 -n -vv" A ping from the VM (10.0.1.6) to VMHOST (10.0.1.17): Captured on tap0: 18:18:40.656407 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, length 64 18:18:40.656429 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->55a3)!) 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64 Captured on vtnet0: 18:18:40.906203 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, length 64 18:18:40.906366 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->55a3)!) 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64 100% packet loss on the ping. Here is the same traffic from both systems between the VM (10.0.1.6) and the switch (10.0.1.1) through the VMHOST: Captured on tap0: 18:23:42.712065 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64 18:23:42.712595 IP (tos 0x0, ttl 255, id 2858, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64 Captured on vtnet0: 18:23:43.141890 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64 18:23:43.142553 IP (tos 0x0, ttl 255, id 2858, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64 100% packet success on the ping. I'm never quite sure when checksum's with TCP Dump or Wireshark are expected, and when they aren't, but it appears that is where the problem lies here. With that said, if I'm understanding this correctly, and checksums are the problem, I'm not sure what to try next. Thanks again! scotto From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 07:17:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5E39799 for ; Thu, 23 Apr 2015 07:17:40 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EC4413A3 for ; Thu, 23 Apr 2015 07:17:40 +0000 (UTC) Received: by lbcga7 with SMTP id ga7so6712976lbc.1 for ; Thu, 23 Apr 2015 00:17:37 -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=O9O9pu0aw9+2K8D1eGY08zAHD7NlF1XSq5Y6zzgpad0=; b=XoX2Z3oidQlE0iDKO896wT1zW2WR2Tp2/BEI24mOWioAM2DAcSIzyrx00VKNzriI61 /pISf+P7fhDud8j96xxF3Ez5RLgT5JyBYfhlkvAXkrMGWL+a6LOm7SQ+Y97MYwticoOE uFlTWhrD0QEvCw9Ug6y3WxR3q0ztre0LzXXfeMdoeIhMk6TaaSB6nQM4lnQLaSLSyMrS e8MACptcunKUm+dxeBTu8FYHMJ1Ak9bmsC3Pd0l1o2JHq/4Iq0RDo/H+OK8nX1digAH8 30anp1wLf/CQgS3bMS9L7SIzX0/8wsFCsyx7qBOXHN/p+uGhmoVV7cuSS6SJ4+vZpPpc dWLQ== MIME-Version: 1.0 X-Received: by 10.112.198.225 with SMTP id jf1mr1188359lbc.91.1429773457551; Thu, 23 Apr 2015 00:17:37 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Thu, 23 Apr 2015 00:17:37 -0700 (PDT) Date: Thu, 23 Apr 2015 10:17:37 +0300 Message-ID: Subject: Testing Congestion Control Algorithms From: Karlis Laivins To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 07:17:40 -0000 Hi, I am currently working on a modification of TCP NewReno congestion control algorithm. It seems that I have been able to write a working module. Now, I am looking for a way to test the performance of the built-in congestion control algorithms and the new algorithm. I have heard about the NS-2 simulator, and I am trying to compile and configure it now, but that's just a statistical tool (from what I hear) and the results are far from reality (please correct me, if I am wrong). Please recommend a tool or way I can test the performance of the congestion control algorithm in a "real" environment (sender side - 2 Computers, one connected to the wireless network, other to a wire, receiver - one PC, running FTP server, both senders each sending a big file at the same time). I would like to get comparable performance results from each of the existing congestion control algorithm as well as the new one I have created by modifying the NewReno algorithm. Thank you in advance for your assistance. Best Regards, Karlis From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 07:37:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F4D9338 for ; Thu, 23 Apr 2015 07:37:37 +0000 (UTC) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx142.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C18AC1637 for ; Thu, 23 Apr 2015 07:37:36 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,629,1422950400"; d="scan'208";a="36592233" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 23 Apr 2015 00:32:25 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 23 Apr 2015 00:32:25 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::f07f:691d:89d:53b7%21]) with mapi id 15.00.0995.031; Thu, 23 Apr 2015 00:32:25 -0700 From: "Eggert, Lars" To: Karlis Laivins CC: "freebsd-net@freebsd.org" Subject: Re: Testing Congestion Control Algorithms Thread-Topic: Testing Congestion Control Algorithms Thread-Index: AQHQfZWcISxRKgHOhEOxikIQ9oaysJ1aqXMA Date: Thu, 23 Apr 2015 07:32:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2098) x-originating-ip: [10.120.60.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <371BBDC70BF17F48870E22AEB9E89DF8@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 07:37:37 -0000 Hi, On 2015-4-23, at 09:17, Karlis Laivins wrote: > I am currently working on a modification of TCP NewReno congestion contro= l > algorithm. It seems that I have been able to write a working module. >=20 > Now, I am looking for a way to test the performance of the built-in > congestion control algorithms and the new algorithm. I have heard about t= he > NS-2 simulator, and I am trying to compile and configure it now, but that= 's > just a statistical tool (from what I hear) and the results are far from > reality (please correct me, if I am wrong). >=20 > Please recommend a tool or way I can test the performance of the congesti= on > control algorithm in a "real" environment (sender side - 2 Computers, one > connected to the wireless network, other to a wire, receiver - one PC, > running FTP server, both senders each sending a big file at the same time= ). > I would like to get comparable performance results from each of the > existing congestion control algorithm as well as the new one I have creat= ed > by modifying the NewReno algorithm. I think you are moving away from the scope where freebsd-net is the correct= mailing list.=20 There are literally thousands of research papers comparing congestion contr= ol algorithms and other TCP improvements. I suggest you check some of those= (Sally Floyd's papers http://www.icir.org/floyd/ are still a good starting= point) and read up on what the ICCRG has done: https://irtf.org/iccrg Lars= From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 07:43:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4ABC8677 for ; Thu, 23 Apr 2015 07:43:28 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 371CB172A for ; Thu, 23 Apr 2015 07:43:27 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id C66AF106709; Thu, 23 Apr 2015 00:43:20 -0700 (PDT) Date: Thu, 23 Apr 2015 00:43:20 -0700 From: hiren panchasara To: Karlis Laivins Cc: freebsd-net@freebsd.org Subject: Re: Testing Congestion Control Algorithms Message-ID: <20150423074320.GI28632@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wjoFZxbW4tu+iR6v" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 07:43:28 -0000 --wjoFZxbW4tu+iR6v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 04/23/15 at 10:17P, Karlis Laivins wrote: > Hi, >=20 > I am currently working on a modification of TCP NewReno congestion control > algorithm. It seems that I have been able to write a working module. >=20 > Now, I am looking for a way to test the performance of the built-in > congestion control algorithms and the new algorithm. I have heard about t= he > NS-2 simulator, and I am trying to compile and configure it now, but that= 's > just a statistical tool (from what I hear) and the results are far from > reality (please correct me, if I am wrong). >=20 > Please recommend a tool or way I can test the performance of the congesti= on > control algorithm in a "real" environment (sender side - 2 Computers, one > connected to the wireless network, other to a wire, receiver - one PC, > running FTP server, both senders each sending a big file at the same time= ). > I would like to get comparable performance results from each of the > existing congestion control algorithm as well as the new one I have creat= ed > by modifying the NewReno algorithm. Comparing performance of different cc algorithms might be tricky as they are designed with different goals in mind. I suggest you stick with your modified newreno vs original newreno and see = if your modifications are letting you do whatever that you have decided. You may want to look at dummynet(4). This can be a useful read http://info.iet.unipi.it/~luigi/papers/20091201-dummynet.pdf siftr(4) is a handy tool to have around to make sure your congestion control module is behaving the way you want. cheers, Hiren --wjoFZxbW4tu+iR6v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVOKKYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lnvcH/1NjmwhKOjhqUqWIBHlH9VsO L9Hq3RMo6wol7jTth24HdeJjAQsON5Q/fbQaPVyoJu5KfFgahvL5ibmQQ3MeUQfE UhxvSUx3m9wSdDRRMAcO7YLIhPQD2Ui6npQiK2MtQ1cg+esYWJ6Usz7XTvvYKqOi Gv9BYN26zBZ+IrJzHs6Sbvuo5l37G+ulVN4pNtu4dkcCjSG8an6jgE9p6/bDD9BG MyDlf8OYs3zdGAk/U1w6bVQiAFZZY85shR7EgFFQb1rToq8g79WaOl9GVr5sGTuY Mr7n7okA1Vyp/cKUQwNgk15R9xhHAeWQK0qkscaSH7JpKZHUtqbL0nFHcVZBaqA= =SXoJ -----END PGP SIGNATURE----- --wjoFZxbW4tu+iR6v-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 07:44:51 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3C6A8DE; Thu, 23 Apr 2015 07:44:51 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 989831747; Thu, 23 Apr 2015 07:44:51 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-105.lns20.per1.internode.on.net [121.45.229.105]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t3N7ijTF019975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Apr 2015 00:44:49 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5538A2E8.309@freebsd.org> Date: Thu, 23 Apr 2015 15:44:40 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Karlis Laivins , freebsd-net@freebsd.org CC: Marko Zec Subject: Re: Testing Congestion Control Algorithms References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 07:44:51 -0000 On 4/23/15 3:17 PM, Karlis Laivins wrote: > Hi, > > I am currently working on a modification of TCP NewReno congestion control > algorithm. It seems that I have been able to write a working module. > > Now, I am looking for a way to test the performance of the built-in > congestion control algorithms and the new algorithm. I have heard about the > NS-2 simulator, and I am trying to compile and configure it now, but that's > just a statistical tool (from what I hear) and the results are far from > reality (please correct me, if I am wrong). > > Please recommend a tool or way I can test the performance of the congestion > control algorithm in a "real" environment (sender side - 2 Computers, one > connected to the wireless network, other to a wire, receiver - one PC, > running FTP server, both senders each sending a big file at the same time). > I would like to get comparable performance results from each of the > existing congestion control algorithm as well as the new one I have created > by modifying the NewReno algorithm. > > Thank you in advance for your assistance. There is a setup called 'imunes' (from memory) that used the virtual stack capabilities (VNET/VIMAGE) to give you a fully configurable test network within a singe computer. see http://imunes.tel.fer.hr/ I'm not sure if the CC stuff can be set up "per vnet" but if it can then you could use that.. or do it yourself using vnet jails and dummynet for link latency/throughput. if Marko is around he may be able to tell you about the current state of imunes. > Best Regards, > Karlis > _______________________________________________ > 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 Apr 23 08:21:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE138A7D; Thu, 23 Apr 2015 08:21:27 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5120E1AE5; Thu, 23 Apr 2015 08:21:27 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t3N8LML0006391; Thu, 23 Apr 2015 10:21:22 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 3354281C; Thu, 23 Apr 2015 10:21:22 +0200 (CEST) Message-ID: <5538AB75.4070401@omnilan.de> Date: Thu, 23 Apr 2015 10:21:09 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Jack Vogel CC: FreeBSD Stable , "freebsd-net@freebsd.org" Subject: Re: igb(4) watchdog timeout, lagg(4) fails References: <54ACC6A2.1050400@omnilan.de> <54AE565D.50208@omnilan.de> <54AE5A6B.7040601@omnilan.de> <54AFA784.6020102@omnilan.de> <54B10432.8050909@omnilan.de> <54DB8975.2030001@omnilan.de> <54DBB1F5.1090601@omnilan.de> <54E733FA.1020208@omnilan.de> In-Reply-To: <54E733FA.1020208@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE4E7208CF628E4EC4EE9682D" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 23 Apr 2015 10:21:22 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 08:21:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE4E7208CF628E4EC4EE9682D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Harald Schmalzbauer's Nachricht vom 20.02.2015 14:17 (localt= ime): (https://lists.freebsd.org/pipermail/freebsd-stable/2015-February/081810.= html) > Bez=FCglich Harald Schmalzbauer's Nachricht vom 11.02.2015 20:48 > (localtime): >> Bez=FCglich Jack Vogel's Nachricht vom 11.02.2015 18:31 (localtime): >>> tdh and tdt mean the head and tail indices of the ring, and these >>> values are >>> obviously severely borked :) Hello Jack, could you find some time for having a look at this problem? The reported values don't bother me, but the watchdog timeout which happens on NICs that are PCIe-connected via the PCH. Please see my previouse findings. I think the most significant hint for my problem seems to be the link_irq, which becomes garbage at the first watchdog timeout occurrence, like previously described: >> =85 >> For the records: Rebooting the machine (ESXi guest-only!) brought the >> stalled igb1 back to operation. >> The guest has 2 igb (kawela) ports, one from a NIC(Intel ET Dual Port >> 82576)@CPU-PCIe and the second port from an identical NIC, but connect= ed >> via PCH-PCIe. >> The watchdog timeout problem only occurs with the port from the >> PCH-PCIe-connected NIC (falisfied)! >> After the reboot the suspicious "dev.igb.1.link_irq=3D848" turned into= : >> dev.igb.0.link_irq: 3 >> dev.igb.1.link_irq: 4 > Jack, > > I'd like to let you know that "dev.igb.1.link_irq" again shows garbage > after the watchdog timeout problem occured again: > dev.igb.1.link_irq: 1458 > > I can imagine that resetting goes wrong and ends in loss of link_irq. > I now have to reboot the guest to get igb1 back to a working state, the= n > the link_irq will show "4" again, but I can't tell you what was first, > the timeour-reset or the "link_irq" jam. I guess the latter can't be th= e > case, but I have no idea about the code Thanks for any help, currently my lagg setup is permanently degraded :-( Would be nice to have it back in a working state :-) -Harry --------------enigE4E7208CF628E4EC4EE9682D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlU4q4EACgkQLDqVQ9VXb8iWYQCg0nEJGLjm1TSYzXZ4ZQtCG0yh MM4An1k7NyDhS9rSfHuZsndSj+amv+hN =nvl7 -----END PGP SIGNATURE----- --------------enigE4E7208CF628E4EC4EE9682D-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 08:29:18 2015 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40BD4CB2; Thu, 23 Apr 2015 08:29:18 +0000 (UTC) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 290F01BFD; Thu, 23 Apr 2015 08:29:17 +0000 (UTC) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 1FD6910DA38; Thu, 23 Apr 2015 01:29:16 -0700 (PDT) Date: Thu, 23 Apr 2015 01:29:16 -0700 From: hiren panchasara To: Lawrence Stewart , koobs@freebsd.org, Andre Oppermann , "freebsd-net@freebsd.org" , nitroboost@gmail.com Subject: Re: TCP Initial Window 10 MFC Message-ID: <20150423082916.GJ28632@strugglingcoder.info> References: <201307051458.r65EwObo066269@svn.freebsd.org> <520AED2F.4050001@freebsd.org> <520BB3F0.4020506@freebsd.org> <520C4F03.9040601@freebsd.org> <5316413D.7050000@FreeBSD.org> <53169C19.5020008@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KZLWU/9q3evlN4nQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 08:29:18 -0000 --KZLWU/9q3evlN4nQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/04/14 at 10:22P, hiren panchasara wrote: > On Tue, Mar 4, 2014 at 7:38 PM, Lawrence Stewart w= rote: > >=20 > > I lost the battle of wills on this topic and 10.0 shipped with IW10 > > enabled by default :( > > > > As for having it configurable, it is a trivial patch which perhaps, > > Hiren, you might be willing to take a stab at? I obviously did not > > manage to carve out the time last year to push forward with the agenda I > > proposed in this thread, but I will get back to it at some point. >=20 > Hi Lawrence, >=20 > Let's fix it the right way if possible. >=20 > Below is a rough/untested quick patch I came up with. Is this how you > were planning to have "nonstandard" sysctl knob designed? A bit more updated patch: https://people.freebsd.org/~hiren/initcwnd.patch How do we go about the existing knob 'sysctl net.inet.tcp.experimental.initcwnd10' ? cheers, Hiren --KZLWU/9q3evlN4nQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVOK1cXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l+2MH/ieW6R55esUlufGry880f3af mbmzpkScc7zdNqL4+ldjqlI21STEjQFrtJjOrOylh5AcyZd+/gXh3kgHbMfewFbT s6hvhzaWnvo58WixysSwQqL3hMLWlwu/fJHsHTM4yNGeYulY86qRjljRRwiOdJWq ioqiGxPSUGjkTKD/TVqVLrfSlehavX2p3NjF9S3bglc2Bv6qyLlMJ1ZXO19ZKeL/ RmN4nbB5XHAQSwbX84t7ZNc/8CLm5kCtnZTz7KxJbyWLu6tOV/41Wr3zU5n012ej ogQmzz5N2Wp4/l4wTeqaMD0g2bjSFT8E8E1MmSdTxB3dCFFtYdLG7e0ubTyxOjQ= =rPNS -----END PGP SIGNATURE----- --KZLWU/9q3evlN4nQ-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 09:45:47 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79EFDCF0 for ; Thu, 23 Apr 2015 09:45:47 +0000 (UTC) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14BE61480 for ; Thu, 23 Apr 2015 09:45:46 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t3N9jhhn013761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Apr 2015 19:45:44 +1000 Message-ID: <5538BF47.4000803@swin.edu.au> Date: Thu, 23 Apr 2015 19:45:43 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Testing Congestion Control Algorithms References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 09:45:47 -0000 On 04/23/2015 17:17, Karlis Laivins wrote: > Hi, > > I am currently working on a modification of TCP NewReno congestion control > algorithm. It seems that I have been able to write a working module. > > Now, I am looking for a way to test the performance of the built-in > congestion control algorithms and the new algorithm. I have heard about the > NS-2 simulator, and I am trying to compile and configure it now, but that's > just a statistical tool (from what I hear) and the results are far from > reality (please correct me, if I am wrong). > > Please recommend a tool or way I can test the performance of the congestion > control algorithm in a "real" environment (sender side - 2 Computers, one > connected to the wireless network, other to a wire, receiver - one PC, > running FTP server, both senders each sending a big file at the same time). > I would like to get comparable performance results from each of the > existing congestion control algorithm as well as the new one I have created > by modifying the NewReno algorithm. > > Thank you in advance for your assistance. Lars is right, the ns-2 tangent is starting to diverge from freebsd-net@ Indeed, I would suggest you don't bother with ns-2 -- it wont help you do meaningful comparisons to a kernel-resident cc module you develop under FreeBSD. If you have the time and inclination to build a small testbed using a couple of physical hosts, you might find this tool useful -- http://caia.swin.edu.au/tools/teacup My colleague and I built TEACUP (TCP Experiment Automation Controlled Using Python) to automate many aspects of running TCP performance experiments in our small, specially-constructed physical testbed. TEACUP enables repeatable testing of different TCP algorithms over a range of emulated network path conditions, bottleneck rate limits and bottleneck queuing disciplines. (e.g. I've used it to experiment with custom FreeBSD CC modules vs conventional FreeBSD and Linux CC algorithms.) A key caveat: TEACUP assumes your physical testbed is a multi-host/single-bottleneck dumbbell-like topology with suitably configured end hosts and Linux-based bottleneck router (see http://caia.swin.edu.au/reports/150210C/CAIA-TR-150210C.pdf for an example). TEACUP does not try to run experiments over arbitrary network paths or the wider Internet. This has satisfied our use-cases, other people's mileage may vary :-) We've released TEACUP in case it may be useful to other researchers who already have (or are interested in setting up) similar network testbeds. (Small note -- we recently found a small bug in some of the v0.9 data analysis code, which will be fixed when v0.9.2 comes out RSN.) cheers, gja From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 10:43:13 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA599737 for ; Thu, 23 Apr 2015 10:43:13 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FC9E1ACA for ; Thu, 23 Apr 2015 10:43:13 +0000 (UTC) Received: by labbd9 with SMTP id bd9so9594376lab.2 for ; Thu, 23 Apr 2015 03:43:11 -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=5NX4ezdStwEzzdRAwBPBjScwuvfHgOVWHWFUBkH94PA=; b=Z8jshJU6rAbI9GRv+Z8m/kOFqEP8sn0SQYzgnQUJuBomRNd4DDNus6rCxvzMzT2QZ4 mrp8rWDg/P+ZlQr5iEygYSrvK0BCUm3m6U0GCre/awyR98+E3B7gTJWc4Vblrtkg/f4p CK40Qbxd7P4dNTw791tjoJqQGmLxQYsPmHmJmGIcG95yBfAhqiFu3dty3Wd2fNIaRzNy XFNB5hd5oDrOuUu0iT6gwQo3tguIcAIt3268jpJt3fd5llLe+6p4vi+ZxBezCMm4oyzf jDkVZPLjZEcuejr88gqsRDFMJ7X3+5zVnSoPAo29GOWp9NV3A4oFZ7nzhzRQRY//1els N3Yg== MIME-Version: 1.0 X-Received: by 10.112.198.225 with SMTP id jf1mr1836979lbc.91.1429785791248; Thu, 23 Apr 2015 03:43:11 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Thu, 23 Apr 2015 03:43:11 -0700 (PDT) In-Reply-To: <5538BF47.4000803@swin.edu.au> References: <5538BF47.4000803@swin.edu.au> Date: Thu, 23 Apr 2015 13:43:11 +0300 Message-ID: Subject: Re: Testing Congestion Control Algorithms From: Karlis Laivins To: grenville armitage Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 10:43:13 -0000 Hi, Thank you very much for this suggestion! I will try to build the testbed and use the tool suggested by you. Best Regards, Karlis On Thu, Apr 23, 2015 at 12:45 PM, grenville armitage wrote: > > > On 04/23/2015 17:17, Karlis Laivins wrote: > >> Hi, >> >> I am currently working on a modification of TCP NewReno congestion control >> algorithm. It seems that I have been able to write a working module. >> >> Now, I am looking for a way to test the performance of the built-in >> congestion control algorithms and the new algorithm. I have heard about >> the >> NS-2 simulator, and I am trying to compile and configure it now, but >> that's >> just a statistical tool (from what I hear) and the results are far from >> reality (please correct me, if I am wrong). >> >> Please recommend a tool or way I can test the performance of the >> congestion >> control algorithm in a "real" environment (sender side - 2 Computers, one >> connected to the wireless network, other to a wire, receiver - one PC, >> running FTP server, both senders each sending a big file at the same >> time). >> I would like to get comparable performance results from each of the >> existing congestion control algorithm as well as the new one I have >> created >> by modifying the NewReno algorithm. >> >> Thank you in advance for your assistance. >> > > Lars is right, the ns-2 tangent is starting to diverge from freebsd-net@ > > Indeed, I would suggest you don't bother with ns-2 -- it wont help you do > meaningful comparisons to a kernel-resident cc module you develop under > FreeBSD. > > If you have the time and inclination to build a small testbed using a > couple of physical hosts, you might find this tool useful -- > http://caia.swin.edu.au/tools/teacup > > My colleague and I built TEACUP (TCP Experiment Automation Controlled > Using Python) to automate many aspects of running TCP performance > experiments in our small, specially-constructed physical testbed. TEACUP > enables repeatable testing of different TCP algorithms over a range of > emulated network path conditions, bottleneck rate limits and bottleneck > queuing disciplines. (e.g. I've used it to experiment with custom FreeBSD > CC modules vs conventional FreeBSD and Linux CC algorithms.) > > A key caveat: TEACUP assumes your physical testbed is a > multi-host/single-bottleneck dumbbell-like topology with suitably > configured end hosts and Linux-based bottleneck router (see > http://caia.swin.edu.au/reports/150210C/CAIA-TR-150210C.pdf for an > example). TEACUP does not try to run experiments over arbitrary network > paths or the wider Internet. This has satisfied our use-cases, other > people's mileage may vary :-) > > We've released TEACUP in case it may be useful to other researchers who > already have (or are interested in setting up) similar network testbeds. > > (Small note -- we recently found a small bug in some of the v0.9 data > analysis code, which will be fixed when v0.9.2 comes out RSN.) > > cheers, > gja > > > > > _______________________________________________ > 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 Apr 23 11:15:35 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D8E7CCE for ; Thu, 23 Apr 2015 11:15:35 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0BBA1DD6 for ; Thu, 23 Apr 2015 11:15:34 +0000 (UTC) Received: by lbbuc2 with SMTP id uc2so10551863lbb.2 for ; Thu, 23 Apr 2015 04:15: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=hhIyQwB2hG07a4urhCD4U+w1EWbRpPRBqM0ugxTiCA8=; b=r2q8TFfxtM+2/oS7dWz8KFpvHkbcieLNiwH5lSXGidmAEaCPRrlyy6RUSM1n54DmMR BA3UWL1h3YtySW5NI3ou49yJ2ZzpkV9gpU07TI8ufPD18WEQ5uVigIfQK1iyWPRbsyq/ unwTWlAytoz/y+1pQKPgNGlwrZU9pWtGRIxJbiu4U+NKr6oa2XvQYWOWt+GzDSjJLSTr Sahdsh9q3ZTaaE2P1qhIAYtbp0rgSwBch1honB5jvoSJsMBH3paABrqiTZVrmypE0oPH rV5OrsnOMwX6jnvZW6HisWOGOX7lIWdb/z7JBPBgcfH6mhYOVJ9Xt8GHQTXr6nkF+QVC hM2g== MIME-Version: 1.0 X-Received: by 10.152.2.130 with SMTP id 2mr1964596lau.120.1429787732763; Thu, 23 Apr 2015 04:15:32 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Thu, 23 Apr 2015 04:15:32 -0700 (PDT) In-Reply-To: <5538BF47.4000803@swin.edu.au> References: <5538BF47.4000803@swin.edu.au> Date: Thu, 23 Apr 2015 14:15:32 +0300 Message-ID: Subject: Re: Testing Congestion Control Algorithms From: Karlis Laivins To: grenville armitage Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 11:15:35 -0000 Hello once again, Before I dive in the TEACUP, I wanted to clarify this - should I build the testbed to consist of FreeBSD machines, will I be able to use congestion control module (.ko) that was created by modifying the cc_newreno (written in C) in TEACUP, or will I have to rewrite it in Python? Sorry, if this question seems silly, but I have limited time to do the tests and I want to be sure that I don't have to redo something in a language that I haven't used yet. Thank you in advance for your answer! With Best Regards, Karlis On Thu, Apr 23, 2015 at 12:45 PM, grenville armitage wrote: > > > On 04/23/2015 17:17, Karlis Laivins wrote: > >> Hi, >> >> I am currently working on a modification of TCP NewReno congestion control >> algorithm. It seems that I have been able to write a working module. >> >> Now, I am looking for a way to test the performance of the built-in >> congestion control algorithms and the new algorithm. I have heard about >> the >> NS-2 simulator, and I am trying to compile and configure it now, but >> that's >> just a statistical tool (from what I hear) and the results are far from >> reality (please correct me, if I am wrong). >> >> Please recommend a tool or way I can test the performance of the >> congestion >> control algorithm in a "real" environment (sender side - 2 Computers, one >> connected to the wireless network, other to a wire, receiver - one PC, >> running FTP server, both senders each sending a big file at the same >> time). >> I would like to get comparable performance results from each of the >> existing congestion control algorithm as well as the new one I have >> created >> by modifying the NewReno algorithm. >> >> Thank you in advance for your assistance. >> > > Lars is right, the ns-2 tangent is starting to diverge from freebsd-net@ > > Indeed, I would suggest you don't bother with ns-2 -- it wont help you do > meaningful comparisons to a kernel-resident cc module you develop under > FreeBSD. > > If you have the time and inclination to build a small testbed using a > couple of physical hosts, you might find this tool useful -- > http://caia.swin.edu.au/tools/teacup > > My colleague and I built TEACUP (TCP Experiment Automation Controlled > Using Python) to automate many aspects of running TCP performance > experiments in our small, specially-constructed physical testbed. TEACUP > enables repeatable testing of different TCP algorithms over a range of > emulated network path conditions, bottleneck rate limits and bottleneck > queuing disciplines. (e.g. I've used it to experiment with custom FreeBSD > CC modules vs conventional FreeBSD and Linux CC algorithms.) > > A key caveat: TEACUP assumes your physical testbed is a > multi-host/single-bottleneck dumbbell-like topology with suitably > configured end hosts and Linux-based bottleneck router (see > http://caia.swin.edu.au/reports/150210C/CAIA-TR-150210C.pdf for an > example). TEACUP does not try to run experiments over arbitrary network > paths or the wider Internet. This has satisfied our use-cases, other > people's mileage may vary :-) > > We've released TEACUP in case it may be useful to other researchers who > already have (or are interested in setting up) similar network testbeds. > > (Small note -- we recently found a small bug in some of the v0.9 data > analysis code, which will be fixed when v0.9.2 comes out RSN.) > > cheers, > gja > > > > > _______________________________________________ > 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 Apr 23 12:14:41 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1952D96D for ; Thu, 23 Apr 2015 12:14:41 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD5F31476 for ; Thu, 23 Apr 2015 12:14:40 +0000 (UTC) Received: by pdea3 with SMTP id a3so16939187pde.3 for ; Thu, 23 Apr 2015 05:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Vbn5VdIHRhsBmqEpyR0jptfqx1ZM8DeaGkFUC/MtYxM=; b=eFbZAppU2J+P4dEZiYaYLa1y0QtVR3Q+QbepEwtR9hGtvv7xJscIhzJBsk1e8V+Z2Q gSlu2BoivNHq03c7TwJdwCKsEE6genDoeP7Zz6ZRsfhoOlStDRyCltuK0lEZOP0p2cR/ Z0+5Y7ySVmQVsMe4+l5ZRFPBLFpbYa3ahIaUbHOQ7McAnEgErMNbUdiy0JLkd4V0wft0 c+UcUDancH9vzJtkGIrzZ9H8MxPKDZCp294FKAi5g/XkeuZHkArjL1cy0fe5jh5zB9H9 Tom8XMtwafqdvijsNTJxZKECEAADYYLI0+R396ouLxYNPDC9y9zac0E3fubojElQVHKc nBFQ== X-Received: by 10.68.114.68 with SMTP id je4mr4646812pbb.99.1429791280159; Thu, 23 Apr 2015 05:14:40 -0700 (PDT) Received: from ox (c-24-6-44-228.hsd1.ca.comcast.net. [24.6.44.228]) by mx.google.com with ESMTPSA id do6sm7995089pdb.72.2015.04.23.05.14.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 05:14:38 -0700 (PDT) Date: Thu, 23 Apr 2015 05:14:33 -0700 From: Navdeep Parhar To: Scott Larson Cc: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding impact on throughput Message-ID: <20150423121433.GA15890@ox> Mail-Followup-To: Scott Larson , freebsd-net@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 12:14:41 -0000 On Tue, Apr 21, 2015 at 12:47:45PM -0700, Scott Larson wrote: > We're in the process of migrating our network into the future with 40G > at the core, including our firewall/traffic routers with 40G interfaces. An > issue which this exposed and threw me for a week turns out to be directly > related to net.inet.ip.forwarding and I'm looking to just get some insight > on what exactly is occurring as a result of using it. Enabling forwarding disables LRO and TSO and that probably accounts for a large part of the difference in throughput that you've observed. The number of packets passing through the stack (and not the amount of data passing through) is the dominant bottleneck. fastforwarding _should_ make a difference, but only if packets actually take the fast-forward path. Check the counters available via netstat: # netstat -sp ip | grep forwarded Regards, Navdeep > What I am seeing is when that knob is set to 0, an identical pair of > what will be PF/relayd servers with direct DAC links between each other > using Chelsio T580s can sustain around 38Gb/s on iperf runs. However the > moment I set that knob to 1, that throughput collapses down into the 3 to > 5Gb/s range. As the old gear this is replacing is all GigE I'd never > witnessed this. Twiddling net.inet.ip.fastforwarding has no apparent effect. > I've not found any docs going in depth on what deeper changes enabling > forwarding does to the network stack. Does it ultimately put a lower > priority on traffic where the server functioning as the packet router is > the final endpoint in exchange for having more resources available to route > traffic across interfaces as would generally be the case? > > > *[image: userimage]Scott Larson[image: los angeles] > Lead > Systems Administrator[image: wdlogo] [image: > linkedin] [image: facebook] > [image: twitter] > [image: instagram] > T 310 823 8238 x1106 > <310%20823%208238%20x1106> | M 310 904 8818 <310%20904%208818>* > _______________________________________________ > 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 Apr 23 18:26:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE3DF499 for ; Thu, 23 Apr 2015 18:26:54 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B27811AD for ; Thu, 23 Apr 2015 18:26:54 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id t3NIPJ2K026758 for ; Thu, 23 Apr 2015 13:25:19 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (72-48-144-84.static.grandenetworks.net [72.48.144.84]) by mail.shrew.net (Postfix) with ESMTPSA id 949AB18AF96 for ; Thu, 23 Apr 2015 13:25:08 -0500 (CDT) Message-ID: <5539395D.9040304@shrew.net> Date: Thu, 23 Apr 2015 13:26:37 -0500 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bhyve with vlans - host and vm can't pass traffic References: <5537C5F8.1090000@sds.com> <55382C0A.1040505@shrew.net> <55384C24.5040607@sds.com> In-Reply-To: <55384C24.5040607@sds.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Thu, 23 Apr 2015 13:25:19 -0500 (CDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 18:26:55 -0000 On 4/22/2015 8:34 PM, Scott O'Connell wrote: > I tried your suggestions. > > I was successful in changing the vmhost01 bridge to include vlan100 > and tap0, and in the vm (dev) binding the address directly to vtnet0. > > On the VMHOST: > tap0: flags=8943 > metric 0 mtu 1500 > options=80000 > ether 00:bd:4c:d1:02:00 > media: Ethernet autoselect > status: active > Opened by PID 888 > bridge0: flags=8843 metric 0 > mtu 1500 > ether 02:d3:e4:02:03:00 > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: tap0 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 2000000 > member: vlan100 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 2000000 > > In the VM: > vtnet0: flags=8943 > metric 0 mtu 1500 > options=80028 > ether 00:a0:98:2b:34:37 > inet 10.0.1.6 netmask 0xffffff00 broadcast 10.0.1.255 > nd6 options=29 > media: Ethernet 10Gbase-T > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > > The same results with regard to connectivity. Both the VMHOST and > the VM can communicate everywhere, except with each other. > > I'm not sure how much detail to post, or what protocol I should be > testing from the tcpdump, but here are a couple of relevant portions. > Captured on the VMHOST with "tcpdump -i tap0 -n -vv", and on the VM > with "tcpdump -i vtnet0 -n -vv" > > A ping from the VM (10.0.1.6) to VMHOST (10.0.1.17): > > Captured on tap0: > 18:18:40.656407 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], > proto ICMP (1), length 84) > 10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, length 64 > 18:18:40.656429 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], > proto ICMP (1), length 84, bad cksum 0 (->55a3)!) > 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64 > > Captured on vtnet0: > 18:18:40.906203 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], > proto ICMP (1), length 84) > 10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, length 64 > 18:18:40.906366 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], > proto ICMP (1), length 84, bad cksum 0 (->55a3)!) > 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64 > > 100% packet loss on the ping. > > Here is the same traffic from both systems between the VM (10.0.1.6) > and the switch (10.0.1.1) through the VMHOST: > > Captured on tap0: > 18:23:42.712065 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], > proto ICMP (1), length 84) > 10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64 > 18:23:42.712595 IP (tos 0x0, ttl 255, id 2858, offset 0, flags [none], > proto ICMP (1), length 84) > 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64 > > Captured on vtnet0: > 18:23:43.141890 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], > proto ICMP (1), length 84) > 10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64 > 18:23:43.142553 IP (tos 0x0, ttl 255, id 2858, offset 0, flags [none], > proto ICMP (1), length 84) > 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64 > > 100% packet success on the ping. > > I'm never quite sure when checksum's with TCP Dump or Wireshark are > expected, and when they aren't, but it appears that is where the > problem lies here. > > With that said, if I'm understanding this correctly, and checksums are > the problem, I'm not sure what to try next. > > Thanks again! > Hi Scott, I certainly appears that ICMP echo reply packets are being returned but the host isn't processing them for some reason. Do you have any firewalls running on either system? You might try including a -e in the tcpdump command line arguments. IIRC, that will also show you VLAN and MAC address info from the packet headers. Maybe one of the network kernel developers could provide some additional insight as to what may be happening in this scenario. -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 20:30:10 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84C4CC13 for ; Thu, 23 Apr 2015 20:30:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7125C1EE9 for ; Thu, 23 Apr 2015 20:30:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3NKUAnG066290 for ; Thu, 23 Apr 2015 20:30:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194855] VLAN interface MTU does not change on changing the base interface MTU Date: Thu, 23 Apr 2015 20:30:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 20:30:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194855 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glebius@FreeBSD.org Assignee|freebsd-net@FreeBSD.org |glebius@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 22:00:38 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1A50231 for ; Thu, 23 Apr 2015 22:00:38 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58CD1194E for ; Thu, 23 Apr 2015 22:00:38 +0000 (UTC) Received: by wizk4 with SMTP id k4so717554wiz.1 for ; Thu, 23 Apr 2015 15:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ZsoS87qDdqe9l8qp32TLRUZL12kxhfakVXRuba7b5/k=; b=GGo9XNXtbNS5ev7AuOWN1BCgIdRzLcahRE2OfGRo0PxWA3Kkfl7EFhtPHtbhB41ibm N3QQCfSFLLPnLhBC9rE+6u2QT8i7SrZVMkKdV9hzdl5iL4fDdAux7MmEYWY41RWVuFH8 x43t8d3HNKC/JecXYiV/5nWuJLizX6jMWiq4+GdD7X1IFDIDkREycTqKRkHvVZjCiNz7 U3kI6xcrEs2wHEO7sYQU98bPQ3mBvyA+ylOpIqE9H5q0a4wELqm4SgWRDaZIM9xHz7bi aDAWhA6ser1DinDQnQ7kZH9AVopTYBLtIrLJfw7/jevak7KlvrxgYVOvFoHkqBtCagn5 o21Q== X-Received: by 10.180.106.131 with SMTP id gu3mr775603wib.16.1429826436859; Thu, 23 Apr 2015 15:00:36 -0700 (PDT) Received: from ?IPv6:2a02:a03f:a39:de00:9b8:308d:8797:6d7c? ([2a02:a03f:a39:de00:9b8:308d:8797:6d7c]) by mx.google.com with ESMTPSA id n3sm4832242wix.1.2015.04.23.15.00.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 15:00:36 -0700 (PDT) From: Sydney Meyer X-Google-Original-From: Sydney Meyer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: IPSec Performance under Xen Message-Id: Date: Fri, 24 Apr 2015 00:00:33 +0200 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 22:00:38 -0000 Hello, I have set up 2 VM's under Xen running each one IPSec-Endpoint. = Everything seems to work fine, but (measured with benchmarks/iperf) the = performance drops from ~10 Gb/s on a non-IPSec-Kernel to ~200 Mb/s with = IPSec compiled in, regardless of whether actually using IPSec or not. I have read about reasoning why IPSec isn't enabled in GENERIC, but = wanted to ask if this is the kind of performance hit one has to expect. I have observed this on FreeBSD 10.1 and 10 Stable, both AMD64. The = Hypervisor is running Xen 4.4 with a Linux 3.16 Dom0.= From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 22:22:17 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 766EB925 for ; Thu, 23 Apr 2015 22:22:17 +0000 (UTC) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10AEC1C22 for ; Thu, 23 Apr 2015 22:22:16 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t3NMMDVI014440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 08:22:14 +1000 Message-ID: <55397095.3040700@swin.edu.au> Date: Fri, 24 Apr 2015 08:22:13 +1000 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Testing Congestion Control Algorithms References: <5538BF47.4000803@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 22:22:17 -0000 This is veering somewhat off tangent for the freebsd-net list, but... On 04/23/2015 21:15, Karlis Laivins wrote: > Hello once again, > > Before I dive in the TEACUP, I wanted to clarify this - should I build the > testbed to consist of FreeBSD machines, will I be able to use congestion > control module (.ko) that was created by modifying the cc_newreno (written > in C) in TEACUP, or will I have to rewrite it in Python? Short answer: TEACUP doesn't implement CC algorithms per se. It focuses on controlling all the data generation & capture tools, end hosts and bottleneck to start/log/stop TCP performance tests using whatever CC algorithm you select. You will need to copy-paste-edit about 5 lines of TEACUP's python code so TEACUP will recognise and kldload your new module on your FreeBSD end hosts. For the long answer -- ping me offlist. > Sorry, if this question seems silly, but I have limited time to do the > tests and I want to be sure that I don't have to redo something in a > language that I haven't used yet. TEACUP takes a bit of time to set up the end hosts and bottleneck router with the right tools. But once you have it running you'll be able to iterate across a range of TCP and path parameters quite efficiently. cheers, gja > > Thank you in advance for your answer! > > With Best Regards, > Karlis > > On Thu, Apr 23, 2015 at 12:45 PM, grenville armitage > wrote: > >> >> >> On 04/23/2015 17:17, Karlis Laivins wrote: >> >>> Hi, >>> >>> I am currently working on a modification of TCP NewReno congestion control >>> algorithm. It seems that I have been able to write a working module. >>> >>> Now, I am looking for a way to test the performance of the built-in >>> congestion control algorithms and the new algorithm. I have heard about >>> the >>> NS-2 simulator, and I am trying to compile and configure it now, but >>> that's >>> just a statistical tool (from what I hear) and the results are far from >>> reality (please correct me, if I am wrong). >>> >>> Please recommend a tool or way I can test the performance of the >>> congestion >>> control algorithm in a "real" environment (sender side - 2 Computers, one >>> connected to the wireless network, other to a wire, receiver - one PC, >>> running FTP server, both senders each sending a big file at the same >>> time). >>> I would like to get comparable performance results from each of the >>> existing congestion control algorithm as well as the new one I have >>> created >>> by modifying the NewReno algorithm. >>> >>> Thank you in advance for your assistance. >>> >> >> Lars is right, the ns-2 tangent is starting to diverge from freebsd-net@ >> >> Indeed, I would suggest you don't bother with ns-2 -- it wont help you do >> meaningful comparisons to a kernel-resident cc module you develop under >> FreeBSD. >> >> If you have the time and inclination to build a small testbed using a >> couple of physical hosts, you might find this tool useful -- >> http://caia.swin.edu.au/tools/teacup >> >> My colleague and I built TEACUP (TCP Experiment Automation Controlled >> Using Python) to automate many aspects of running TCP performance >> experiments in our small, specially-constructed physical testbed. TEACUP >> enables repeatable testing of different TCP algorithms over a range of >> emulated network path conditions, bottleneck rate limits and bottleneck >> queuing disciplines. (e.g. I've used it to experiment with custom FreeBSD >> CC modules vs conventional FreeBSD and Linux CC algorithms.) >> >> A key caveat: TEACUP assumes your physical testbed is a >> multi-host/single-bottleneck dumbbell-like topology with suitably >> configured end hosts and Linux-based bottleneck router (see >> http://caia.swin.edu.au/reports/150210C/CAIA-TR-150210C.pdf for an >> example). TEACUP does not try to run experiments over arbitrary network >> paths or the wider Internet. This has satisfied our use-cases, other >> people's mileage may vary :-) >> >> We've released TEACUP in case it may be useful to other researchers who >> already have (or are interested in setting up) similar network testbeds. >> >> (Small note -- we recently found a small bug in some of the v0.9 data >> analysis code, which will be fixed when v0.9.2 comes out RSN.) >> >> cheers, >> gja >> >> >> >> >> _______________________________________________ >> 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" >> > _______________________________________________ > 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" > -- Professor Grenville Armitage Centre for Advanced Internet Architectures School of Software and Electrical Engineering Faculty of Science, Engineering and Technology Swinburne University of Technology, Australia http://caia.swin.edu.au/cv/garmitage From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 23:12:30 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 58880904; Thu, 23 Apr 2015 23:12:30 +0000 (UTC) Received: from forward8l.mail.yandex.net (forward8l.mail.yandex.net [IPv6:2a02:6b8:0:1819::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1709F1156; Thu, 23 Apr 2015 23:12:29 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward8l.mail.yandex.net (Yandex) with ESMTP id 07C801A4024C; Fri, 24 Apr 2015 02:12:17 +0300 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id EACB21B43393; Fri, 24 Apr 2015 02:12:16 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:6::a8]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id KQkKyMmqXC-CGjWa3iQ; Fri, 24 Apr 2015 02:12:16 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1429830736; bh=CAR1M/iJNFn3hi7ngdx8C+R+/5ezkcGZvw2Pbsc2+wg=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bCfam4hhSm0YGZSWl5vkcopep6+suELJrbjhvuixEIQfcuS1oFbNET+nElrk2jDmf /S2uY7WI+WQnkBKe4c95Jh3Pm85+urtYEatI1ndPxQGsk4316ZXaAtYxSz5erFgNYJ acTHLX2F3sdpDGbZSrZHnWQg5awO5kw8+WTOYPLs= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <55397BE1.7090403@yandex.ru> Date: Fri, 24 Apr 2015 02:10:25 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sydney Meyer , freebsd-net@freebsd.org CC: "Robert N. M. Watson" , George Neville-Neil Subject: Re: IPSec Performance under Xen References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 23:12:30 -0000 On 24.04.2015 01:00, Sydney Meyer wrote: > Hello, > > I have set up 2 VM's under Xen running each one IPSec-Endpoint. > Everything seems to work fine, but (measured with benchmarks/iperf) > the performance drops from ~10 Gb/s on a non-IPSec-Kernel to ~200 > Mb/s with IPSec compiled in, regardless of whether actually using > IPSec or not. > > I have read about reasoning why IPSec isn't enabled in GENERIC, but > wanted to ask if this is the kind of performance hit one has to > expect. Hi, I have a guess. Since you use iperf, I think the main bottleneck there is the fact, that the socket has a PCB. When you have compiled IPSEC in the kernel, it enables the code, that does initialization of PCB's security policy inp_sp via ipsec_init_policy(). Then each packet that has associated PCB (iperf uses sockets, so it has PCB) on output goes through a bunch of checks, that includes several lookups with taking of exclusive locks. Even if you don't use any security policies ALL packets that have associated PCB will go through such UNNEEDED checks. I am not very familiar with this code, but maybe George or Robert can answer why we do this for every PCB? Why not initialize inp_sp only when application does needed configuration via setsockopt(IP_IPSEC_POLICY)? -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 23:28:46 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F619A40 for ; Thu, 23 Apr 2015 23:28:46 +0000 (UTC) Received: from forward5l.mail.yandex.net (forward5l.mail.yandex.net [IPv6:2a02:6b8:0:1819::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0E1D125C for ; Thu, 23 Apr 2015 23:28:45 +0000 (UTC) Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::117]) by forward5l.mail.yandex.net (Yandex) with ESMTP id 6EB71C410E3; Fri, 24 Apr 2015 02:28:34 +0300 (MSK) Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id D71621B47EF3; Fri, 24 Apr 2015 02:28:33 +0300 (MSK) Received: from unknown (unknown [2a02:6b8:0:6::a8]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id O1shYZ0keC-SXhaMRJ7; Fri, 24 Apr 2015 02:28:33 +0300 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1429831713; bh=k+yQdFpVajCGreBbVdGSKYASARWBkZi9vgBo0kmCbQw=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pvhFrN9Kb0votHEkqZIPAuQADMmuvJ4SCdnC4VPuVTpNV39M7ZRizMv+gwfhS8+on jC/b9YSv/FDl8FhUhI3JA3ZkREs7uumMhKzG1YHtqAlqgAaMQi87Z6WKYuY7S8Tl5A Y7bJQvnB+fHHfaI+ezn7ijdBP0H3NRcMkV1/+khc= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru Message-ID: <55397FB3.6080702@yandex.ru> Date: Fri, 24 Apr 2015 02:26:43 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sydney Meyer , freebsd-net@freebsd.org Subject: Re: IPSec Performance under Xen References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 23:28:46 -0000 On 24.04.2015 01:00, Sydney Meyer wrote: > Hello, > > I have set up 2 VM's under Xen running each one IPSec-Endpoint. > Everything seems to work fine, but (measured with benchmarks/iperf) > the performance drops from ~10 Gb/s on a non-IPSec-Kernel to ~200 > Mb/s with IPSec compiled in, regardless of whether actually using > IPSec or not. Can you test this patch to see the difference? It isn't a fix. It is just to see how will help avoiding of PCB check. --- ip_output.c (revision 281867) +++ ip_output.c (working copy) @@ -482,7 +482,7 @@ again: sendit: #ifdef IPSEC - switch(ip_ipsec_output(&m, inp, &flags, &error)) { + switch(ip_ipsec_output(&m, NULL, &flags, &error)) { case 1: goto bad; case -1: -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Apr 23 23:34:42 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54B1EB2C for ; Thu, 23 Apr 2015 23:34:42 +0000 (UTC) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02F57132B for ; Thu, 23 Apr 2015 23:34:41 +0000 (UTC) Received: by wicmx19 with SMTP id mx19so23192594wic.1 for ; Thu, 23 Apr 2015 16:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=nJMjjOLJV7FswJ6qymWob0OYTRDVje4IN92FWIO1LlM=; b=XWTE0dhjazo4DOYouOe2NrUjYKh3I7F4ml8TyOOskF4UB61C5ZvQ6Hq5tQMxQnrdHB RqJz50ILqiud8cFD3EFzDTqM3PbIdM0Pth7RTQjKhR6/8zkFieU58/oFZb6rHfzT1IVZ TIdcSvdTfjvPaDyHvQBCaMG99TTc6hmbjB0SfiNTp8TC1Yj5V8jCTl+xYZtTOdrDwS0U pWTKUktL2J5YGXFOxjpg4CTgmJ6CKE8Vw2XsSQx2TELNd3G7qv1GMzJG9FKiF6RpPArW 50elMyuZfY8uLEpR4K1byqs9A+wQpFES+4FU28Q5WiC29F0TwXk1AxfvEj5AOSE69FUo DI3g== X-Received: by 10.194.110.233 with SMTP id id9mr10225052wjb.136.1429832080489; Thu, 23 Apr 2015 16:34:40 -0700 (PDT) Received: from ?IPv6:2a02:a03f:a39:de00:9b8:308d:8797:6d7c? ([2a02:a03f:a39:de00:9b8:308d:8797:6d7c]) by mx.google.com with ESMTPSA id fs9sm14341584wjc.34.2015.04.23.16.34.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 16:34:39 -0700 (PDT) From: Sydney Meyer X-Google-Original-From: Sydney Meyer Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: IPSec Performance under Xen In-Reply-To: <55397FB3.6080702@yandex.ru> Date: Fri, 24 Apr 2015 01:34:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <55397FB3.6080702@yandex.ru> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 23:34:42 -0000 Sure.. i'll get back to you.. S. > On Apr 24, 2015, at 01:26, Andrey V. Elsukov wrote: > > On 24.04.2015 01:00, Sydney Meyer wrote: >> Hello, >> >> I have set up 2 VM's under Xen running each one IPSec-Endpoint. >> Everything seems to work fine, but (measured with benchmarks/iperf) >> the performance drops from ~10 Gb/s on a non-IPSec-Kernel to ~200 >> Mb/s with IPSec compiled in, regardless of whether actually using >> IPSec or not. > > Can you test this patch to see the difference? It isn't a fix. It is > just to see how will help avoiding of PCB check. > > --- ip_output.c (revision 281867) > +++ ip_output.c (working copy) > @@ -482,7 +482,7 @@ again: > > sendit: > #ifdef IPSEC > - switch(ip_ipsec_output(&m, inp, &flags, &error)) { > + switch(ip_ipsec_output(&m, NULL, &flags, &error)) { > case 1: > goto bad; > case -1: > > > -- > WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 00:06:00 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3148F19 for ; Fri, 24 Apr 2015 00:06:00 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E512164D for ; Fri, 24 Apr 2015 00:06:00 +0000 (UTC) Received: by wiax7 with SMTP id x7so23571283wia.0 for ; Thu, 23 Apr 2015 17:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=06PIwfEldjUIO+wBd3tOI+CF/u7X1EGb3bNjsY3FhMI=; b=O43Llz0bKxz6QarkRZrpaqKGxZN32l3fqfmUfLr777It61l5/cyZg2+JGpPaS4liB2 kFSTsRCwm4eHxANhgIRcs9XxW/BoIeRClVuFOPJJ+a2AxZ1vDCFa5JHuWzIcZ84+cUTq zsAXnllQNUZ0DFGfaJA4/zoL6XQun8ggP76OUVZlYWIFerleyqAOYkhC6neRapRZX9Yu 6ETAEnz5W5Y4OKGf9aoXZdugcj0Fv7JrOrIWKGC0hNFjKCN2iFU76oHBwN0Ij5v2QFx9 6D+2XacEeo9/GkM50JxkywzQDN2TLJvFBolisKYk30RX+UaynbFAOPZrkrXc6DQXcOzn 470g== X-Received: by 10.194.192.226 with SMTP id hj2mr10581026wjc.51.1429833958928; Thu, 23 Apr 2015 17:05:58 -0700 (PDT) Received: from ?IPv6:2a02:a03f:a39:de00:9b8:308d:8797:6d7c? ([2a02:a03f:a39:de00:9b8:308d:8797:6d7c]) by mx.google.com with ESMTPSA id o5sm5179407wia.0.2015.04.23.17.05.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 17:05:58 -0700 (PDT) From: Sydney Meyer X-Google-Original-From: Sydney Meyer Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: IPSec Performance under Xen In-Reply-To: <55397FB3.6080702@yandex.ru> Date: Fri, 24 Apr 2015 02:05:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55397FB3.6080702@yandex.ru> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 00:06:00 -0000 Hello Andrey, first off, thank you for your explanation. As for your Hint, i am not a C Programmer but i think i have a better = understanding of the issue now. I believe this is a know issue and the reason why IPSEC isn't in = GENERIC, afaik from this discussion = (https://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028364.htm= l). I have compiled the patched kernel and am installing on the vm's now.. = will get back to you. S. > On Apr 24, 2015, at 01:26, Andrey V. Elsukov = wrote: >=20 > On 24.04.2015 01:00, Sydney Meyer wrote: >> Hello, >>=20 >> I have set up 2 VM's under Xen running each one IPSec-Endpoint. >> Everything seems to work fine, but (measured with benchmarks/iperf) >> the performance drops from ~10 Gb/s on a non-IPSec-Kernel to ~200 >> Mb/s with IPSec compiled in, regardless of whether actually using >> IPSec or not. >=20 > Can you test this patch to see the difference? It isn't a fix. It is > just to see how will help avoiding of PCB check. >=20 > --- ip_output.c (revision 281867) > +++ ip_output.c (working copy) > @@ -482,7 +482,7 @@ again: >=20 > sendit: > #ifdef IPSEC > - switch(ip_ipsec_output(&m, inp, &flags, &error)) { > + switch(ip_ipsec_output(&m, NULL, &flags, &error)) { > case 1: > goto bad; > case -1: >=20 >=20 > --=20 > WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 00:55:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 265483CD for ; Fri, 24 Apr 2015 00:55:32 +0000 (UTC) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFDEB1AC4 for ; Fri, 24 Apr 2015 00:55:31 +0000 (UTC) Received: by wgyo15 with SMTP id o15so35073382wgy.2 for ; Thu, 23 Apr 2015 17:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=T+O2pt+aHY3JbugIi81c3+1ILDy/6ulvCPZ2Ka6ik/Q=; b=u2bP+c2TbtJs3fe0u5kUR2qx1NLkV6V7bn5TYJKrvWQnf4v79Vw6CYBJHvul/mJVkH W6Ks5hK907MKO6jpiuLkzf+nR780cegyUZkmSu1kELoHO9hcHXDhDTkuQ697Q1L/Mkqd LtsG0dKYQ2+mQGVegvQ+h8MuS3tK1u+AJzBRqp80v83MondCZztQdEU40x6dd4PT8wqe o5MGoy3IzpPRxwv7xlw3jjlI7VUtGzeZFbdyhSnj5RIDpQTDYPa5BTShbMzFi2loEbTl hAqLDTDvzUnIXZWYQXKOgAHEQnlC0ZzgUqE5Uq5XEdNHgYWK9Dds9hpFTlQfz0JxkOkM 7FoA== X-Received: by 10.180.223.7 with SMTP id qq7mr1594783wic.21.1429836930174; Thu, 23 Apr 2015 17:55:30 -0700 (PDT) Received: from ?IPv6:2a02:a03f:a39:de00:9b8:308d:8797:6d7c? ([2a02:a03f:a39:de00:9b8:308d:8797:6d7c]) by mx.google.com with ESMTPSA id u9sm8152369wjx.15.2015.04.23.17.55.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 17:55:29 -0700 (PDT) From: Sydney Meyer X-Google-Original-From: Sydney Meyer Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: IPSec Performance under Xen In-Reply-To: <55397FB3.6080702@yandex.ru> Date: Fri, 24 Apr 2015 02:55:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <079851FA-50AC-47E8-B4BE-D97DE4C185B5@gmail.com> References: <55397FB3.6080702@yandex.ru> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 00:55:32 -0000 Andrey, with your patch applied the performance drop while using the = IPSEC-enabled kernel without doing actual IPSec traffic seems to be = gone. I haven't tested IPSec itself yet, as i had to start from scratch with = new VM's but i will set up a IPSec connection and report back. S. > On Apr 24, 2015, at 01:26, Andrey V. Elsukov = wrote: >=20 > On 24.04.2015 01:00, Sydney Meyer wrote: >> Hello, >>=20 >> I have set up 2 VM's under Xen running each one IPSec-Endpoint. >> Everything seems to work fine, but (measured with benchmarks/iperf) >> the performance drops from ~10 Gb/s on a non-IPSec-Kernel to ~200 >> Mb/s with IPSec compiled in, regardless of whether actually using >> IPSec or not. >=20 > Can you test this patch to see the difference? It isn't a fix. It is > just to see how will help avoiding of PCB check. >=20 > --- ip_output.c (revision 281867) > +++ ip_output.c (working copy) > @@ -482,7 +482,7 @@ again: >=20 > sendit: > #ifdef IPSEC > - switch(ip_ipsec_output(&m, inp, &flags, &error)) { > + switch(ip_ipsec_output(&m, NULL, &flags, &error)) { > case 1: > goto bad; > case -1: >=20 >=20 > --=20 > WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 01:02:14 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B037570 for ; Fri, 24 Apr 2015 01:02:14 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id 8739010BD; Fri, 24 Apr 2015 01:02:13 +0000 (UTC) Message-ID: <553995A6.60603@FreeBSD.org> Date: Fri, 24 Apr 2015 04:00:22 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Sydney Meyer , freebsd-net@freebsd.org Subject: Re: IPSec Performance under Xen References: <55397FB3.6080702@yandex.ru> <079851FA-50AC-47E8-B4BE-D97DE4C185B5@gmail.com> In-Reply-To: <079851FA-50AC-47E8-B4BE-D97DE4C185B5@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 01:02:14 -0000 On 24.04.2015 03:55, Sydney Meyer wrote: > Andrey, > > with your patch applied the performance drop while using the > IPSEC-enabled kernel without doing actual IPSec traffic seems to be > gone. > > I haven't tested IPSec itself yet, as i had to start from scratch > with new VM's but i will set up a IPSec connection and report back. Thank you. But I think something will not work if you try it with IPSec. Probably if you use some IKE software, it will not work with this patch. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 01:06:44 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39621617 for ; Fri, 24 Apr 2015 01:06:44 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCC1F1BD5 for ; Fri, 24 Apr 2015 01:06:43 +0000 (UTC) Received: by widdi4 with SMTP id di4so4061022wid.0 for ; Thu, 23 Apr 2015 18:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=oJWETtAKgbskZ6JhmaP8doSqUTMqyI1Zs8j05eMI/8A=; b=jUgOKZc9XlEn7nrStyQRJMrYahmHd3qIHo0v63Bv4lskbcsPgtTkDt0G02GmML5MrP NXpqsB5kzDbFX2RhrEkivRqD0Z+ts6bLboz+29IpspTf9y0673hyLex4VrZN6wcAhTZ9 HJF9zB8WVu9ag6WafD3l0jxbSQIZiSq8kXZfqEaBht8kTVcqZf19XC44MaDGCGZex0Ju PWXmM/m+Qp+j2TwmXPJT1rOjjhIkJB+KfLemr9hByGjgFc67CL56qCV0LLtgMvSqHxd5 mNM2JgNbf/sSAkr1ybFQ8rqDnqMKySy/2AJ+PRd4IyYKLvWszmCX9bgVP8lOAUS69ljn do6w== X-Received: by 10.180.92.228 with SMTP id cp4mr1831724wib.62.1429837602345; Thu, 23 Apr 2015 18:06:42 -0700 (PDT) Received: from ?IPv6:2a02:a03f:a39:de00:9b8:308d:8797:6d7c? ([2a02:a03f:a39:de00:9b8:308d:8797:6d7c]) by mx.google.com with ESMTPSA id cf12sm14567645wjb.10.2015.04.23.18.06.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Apr 2015 18:06:41 -0700 (PDT) From: Sydney Meyer X-Google-Original-From: Sydney Meyer Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: IPSec Performance under Xen In-Reply-To: <553995A6.60603@FreeBSD.org> Date: Fri, 24 Apr 2015 03:06:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55397FB3.6080702@yandex.ru> <079851FA-50AC-47E8-B4BE-D97DE4C185B5@gmail.com> <553995A6.60603@FreeBSD.org> To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 01:06:44 -0000 You're right.. strongswan fails/hangs with: initiating IKE_SA host-host[1] to 10.0.30.66 generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) = N(HASH_ALG) ] sending packet: from 10.0.30.114[500] to 10.0.30.66[500] (1148 bytes) received packet: from 10.0.30.66[500] to 10.0.30.114[500] (456 bytes) parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) = N(HASH_ALG) N(MULT_AUTH) ] authentication of 'sun.strongswan.org' (myself) with pre-shared key establishing CHILD_SA host-host generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH = N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_6_ADDR) N(MULT_AUTH) = N(EAP_ONLY) ] sending packet: from 10.0.30.114[4500] to 10.0.30.66[4500] (444 bytes) retransmit 1 of request with message ID 1 sending packet: from 10.0.30.114[4500] to 10.0.30.66[4500] (444 bytes) retransmit 2 of request with message ID 1 sending packet: from 10.0.30.114[4500] to 10.0.30.66[4500] (444 bytes) .. S. > On Apr 24, 2015, at 03:00, Andrey V. Elsukov wrote: >=20 > On 24.04.2015 03:55, Sydney Meyer wrote: >> Andrey, >>=20 >> with your patch applied the performance drop while using the >> IPSEC-enabled kernel without doing actual IPSec traffic seems to be >> gone. >>=20 >> I haven't tested IPSec itself yet, as i had to start from scratch >> with new VM's but i will set up a IPSec connection and report back. >=20 > Thank you. But I think something will not work if you try it with = IPSec. > Probably if you use some IKE software, it will not work with this = patch. >=20 > --=20 > WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 06:27:40 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 211FD137 for ; Fri, 24 Apr 2015 06:27:40 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFFE1B1E for ; Fri, 24 Apr 2015 06:27:39 +0000 (UTC) Received: by layy10 with SMTP id y10so28279066lay.0 for ; Thu, 23 Apr 2015 23:27:37 -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=U+MG+Y3U/TcGOJFB5+GhkmnjJr+HzWMl5+LkvngqgLQ=; b=EkK+Kkxj4DZf3+QIxYI4lairTQ9YImFEO9pkX+e+ayn8BOE+y8kUISY7gp3lU5O5Tc 1XExoz1O+EpKu0SLeDZ7UV/9HARzMm+NKGrdvJidog7Qk6BqRCk/QfXbcOCaRic8elMU fL/grHop8lb31N+7v+1cPZSqiFBgTdtun1ORHZhSCvMDeLOG16RzLjZLliaYHv9XfHnG y88CyWdJkpVvPdWg/z0kw5vN6DjZ2G4I1lEVRekelUunOR+x/sNTJLYaEMGA6VgWfzYF MrKnN4JZXQv/3k0nFoM3YausO5l1HEAeq1Aj+V1ngNnXVm5zfoIt99OI4EyBHp13tNV1 3uqA== MIME-Version: 1.0 X-Received: by 10.152.29.42 with SMTP id g10mr5735531lah.58.1429856857858; Thu, 23 Apr 2015 23:27:37 -0700 (PDT) Received: by 10.114.202.229 with HTTP; Thu, 23 Apr 2015 23:27:37 -0700 (PDT) Date: Fri, 24 Apr 2015 09:27:37 +0300 Message-ID: Subject: Westwood From: Karlis Laivins To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 06:27:40 -0000 Hi, Has there been an effort to implement the Westwood congestion control algorithm? Is there a source file available? I would like to take a look and see how Bandwidth estimation is done there. Thank you in advance! Best Regards, Karlis From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 09:34:09 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C7DF873 for ; Fri, 24 Apr 2015 09:34:09 +0000 (UTC) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 274861F4A for ; Fri, 24 Apr 2015 09:34:08 +0000 (UTC) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.9/8.14.9) with ESMTP id t3O9F9C7092847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Apr 2015 11:15:10 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: fjwcash@gmail.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.9/8.14.9) with ESMTP id t3O9F6mg013397; Fri, 24 Apr 2015 16:15:08 +0700 (KRAT) (envelope-from eugen@grosbein.net) Message-ID: <553A099A.4040703@grosbein.net> Date: Fri, 24 Apr 2015 16:15:06 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Aristedes Maniatis , freebsd-net@freebsd.org CC: Freddie Cash Subject: Re: CARP vhid: across interfaces? References: <54A52966.9040407@ish.com.au> <54A52F81.4080409@ish.com.au> In-Reply-To: <54A52F81.4080409@ish.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0001] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 09:34:09 -0000 On 01.01.2015 18:29, Aristedes Maniatis wrote: > At any rate what does "interface groups that the carp(4) interface is a member of" mean? FreeBSD has interface groups. Any interface may be a member of one or multiple groups, you can manually insert interface into a group, list groups etc. See man ifconfig. From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 16:46:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F5D2BCA for ; Fri, 24 Apr 2015 16:46:37 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A19FB13A6 for ; Fri, 24 Apr 2015 16:46:36 +0000 (UTC) Received: from moby.local ([92.74.226.55]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MhRUQ-1YyFWS1kRO-00MdXX for ; Fri, 24 Apr 2015 18:46:34 +0200 Message-ID: <553A7350.40607@gmx.com> Date: Fri, 24 Apr 2015 18:46:08 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: FreeBSD Net Subject: net.inet.ip.forwarding is mysteriously set to 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+SPaPY9tQOfKT+S5zsf3fnwyo42EhqCz6PpJr5B1SJCQD+Tn62t HAlMC9ut3/YVEBcKpQHY3W/kAhlXlJh1i2UVWO/+HPpNMoPHnUwn28D1hwhoywqbp703ir2 J5Bvj27IbEKXrA2o9JCT04QaROy2byyhmimMdX27dGWaNK0y3qrGtnVxGnpk+e/80CIAiY0 uMRSC0PjT1YfkPHUgDMtQ== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:46:37 -0000 Hi, Just saw this. Can somebody re-produce this? > root@m4fh2:~ # sysctl net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > root@m4fh2:~ # ifconfig bridge0 create > root@m4fh2:~ # sysctl net.inet.ip.forwarding > net.inet.ip.forwarding: 0 That's on GENERIC 10-STABLE from the day before yesterday. Thanks, Nikos From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 16:48:08 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB10FC6B for ; Fri, 24 Apr 2015 16:48:08 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3F0113B5 for ; Fri, 24 Apr 2015 16:48:08 +0000 (UTC) Received: by pdbnk13 with SMTP id nk13so53610779pdb.0 for ; Fri, 24 Apr 2015 09:48:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NnGoMbOR6dhZURxX3R/lsG0qPh0fCUm5nbmAxXuft78=; b=NdLlCZcXr2CWEt/ejAMr9bSJUETKzD3ek5Mlsbo18bu9GLvuAsgHNtPZiZ5vOFwCvd xQTsJCSN43JZGkKtKmU7aCUjsxTGtz3Mpbtlw7PeYzMkZVi1k9GJ55b0L9zxRDkB9a6H EO30ZiZ8IgQ0UwujKBjBsjhkRaJjL5fTUeGDZdfiuoW7N/nAk6EMPNME4TOq6ClTyh05 xdCY6gMKhMZQt1ei9f5yJBA4A7JWiCLK/3oVn2C7X9UQjdzrY+Bm5d31rVdq+KYydpec ORAPGHToq9qIEa7Rp1FuHv5k8cmA5JaDBrY6CJBs1qDnI/PoAENqmijbC64uxgjSEEfb zNnA== X-Gm-Message-State: ALoCoQl79bAMVW5it+ZwgzHWL8ojEXKIrPaxio/SYtaHEIatzYdDPEcmkyjoE6HrSExOfNCpfXwF X-Received: by 10.68.112.195 with SMTP id is3mr16736629pbb.92.1429894082068; Fri, 24 Apr 2015 09:48:02 -0700 (PDT) Received: from [128.199.254.70] (sgp.sin.winterei.se. [128.199.254.70]) by mx.google.com with ESMTPSA id l14sm11328435pdm.16.2015.04.24.09.47.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Apr 2015 09:48:00 -0700 (PDT) Message-ID: <553A73B6.8010307@winterei.se> Date: Sat, 25 Apr 2015 01:47:50 +0900 From: "Paul S." User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 References: <553A7350.40607@gmx.com> In-Reply-To: <553A7350.40607@gmx.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:48:08 -0000 Can confirm that anything to do with netif restart on a forwarding interface also creates the same problem. On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote: > Hi, > > Just saw this. Can somebody re-produce this? > >> root@m4fh2:~ # sysctl net.inet.ip.forwarding >> net.inet.ip.forwarding: 1 >> root@m4fh2:~ # ifconfig bridge0 create >> root@m4fh2:~ # sysctl net.inet.ip.forwarding >> net.inet.ip.forwarding: 0 > > That's on GENERIC 10-STABLE from the day before yesterday. > > Thanks, > Nikos > _______________________________________________ > 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 Apr 24 16:54:39 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6000204 for ; Fri, 24 Apr 2015 16:54:39 +0000 (UTC) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B6C1154D for ; Fri, 24 Apr 2015 16:54:39 +0000 (UTC) Received: from gjp by mail.in-addr.com with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1Ylgs9-000IyN-Cm; Fri, 24 Apr 2015 17:54:37 +0100 Date: Fri, 24 Apr 2015 17:54:37 +0100 From: Gary Palmer To: "Paul S." Cc: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 Message-ID: <20150424165437.GB22493@in-addr.com> References: <553A7350.40607@gmx.com> <553A73B6.8010307@winterei.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <553A73B6.8010307@winterei.se> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:54:39 -0000 On Sat, Apr 25, 2015 at 01:47:50AM +0900, Paul S. wrote: > Can confirm that anything to do with netif restart on a forwarding > interface also creates the same problem. > > On 4/25/2015 ?????? 01:46, Nikos Vassiliadis wrote: > > Hi, > > > > Just saw this. Can somebody re-produce this? > > > >> root@m4fh2:~ # sysctl net.inet.ip.forwarding > >> net.inet.ip.forwarding: 1 > >> root@m4fh2:~ # ifconfig bridge0 create > >> root@m4fh2:~ # sysctl net.inet.ip.forwarding > >> net.inet.ip.forwarding: 0 > > > > That's on GENERIC 10-STABLE from the day before yesterday. > > > > Thanks, > > Nikos What is your setting for gateway_enable in /etc/rc.conf? Gary From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 16:54:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCB902AC for ; Fri, 24 Apr 2015 16:54:54 +0000 (UTC) Received: from smtp4.mail.clearhost.co.uk (smtp4.mail.clearhost.co.uk [IPv6:2001:1420::25:104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.mail.clearhost.co.uk", Issuer "RapidSSL CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A80891556 for ; Fri, 24 Apr 2015 16:54:54 +0000 (UTC) Received: from [2001:1420:a:105:c62c:3ff:fe2f:bf] (port=62277 helo=parsnip.heronsbrook.org.uk) by smtp4.mail.clearhost.co.uk with esmtpa (Exim 4.76 (FreeBSD)) (envelope-from ) id 1YlgsN-000F14-RL for freebsd-net@freebsd.org; Fri, 24 Apr 2015 16:54:51 +0000 Message-ID: <553A75E7.4090804@prt.org> Date: Fri, 24 Apr 2015 17:57:11 +0100 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 References: <553A7350.40607@gmx.com> <553A73B6.8010307@winterei.se> In-Reply-To: <553A73B6.8010307@winterei.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:54:54 -0000 Hi This happens when any interface is created if you've enabled forwarding with the sysctl and not using gateway_enable in rc.conf. It is easily fixed though. See this thread from January: https://docs.freebsd.org/cgi/getmsg.cgi?fetch=403720+0+archive/2015/freebsd-net/20150104.freebsd-net Paul. On 24/04/2015 17:47, Paul S. wrote: > Can confirm that anything to do with netif restart on a forwarding > interface also creates the same problem. > > On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote: >> Hi, >> >> Just saw this. Can somebody re-produce this? >> >>> root@m4fh2:~ # sysctl net.inet.ip.forwarding >>> net.inet.ip.forwarding: 1 >>> root@m4fh2:~ # ifconfig bridge0 create >>> root@m4fh2:~ # sysctl net.inet.ip.forwarding >>> net.inet.ip.forwarding: 0 >> >> That's on GENERIC 10-STABLE from the day before yesterday. >> >> Thanks, >> Nikos >> _______________________________________________ >> 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" > > _______________________________________________ > 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 Apr 24 17:01:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21F58554; Fri, 24 Apr 2015 17:01:32 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC242165F; Fri, 24 Apr 2015 17:01:31 +0000 (UTC) Received: from moby.local ([92.74.226.55]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MKYsh-1YmVnA3Mmd-001vb2; Fri, 24 Apr 2015 19:01:23 +0200 Message-ID: <553A76CF.8040407@gmx.com> Date: Fri, 24 Apr 2015 19:01:03 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gary Palmer , "Paul S." CC: freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 References: <553A7350.40607@gmx.com> <553A73B6.8010307@winterei.se> <20150424165437.GB22493@in-addr.com> In-Reply-To: <20150424165437.GB22493@in-addr.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ikORY165mxc/ddl26G7i3K7SPXx7muaHIzehL2T6ax70Wn3Ejeu LvzIFJ9BGOh2q+76vgZtGTRSMnXLTFBXJisFHuehLt2z9AtIZ0Edr4m4n/vgnFBtAv+Curs nllmOsA9G19L0Tb5PyKIxh/p2casFf3GLGFbVZ9DPUbDvptspjjHfXEiz698xvtJqeYYE+E L3n0Ja112o1pFHO6gz8cg== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 17:01:32 -0000 On 04/24/15 18:54, Gary Palmer wrote: > On Sat, Apr 25, 2015 at 01:47:50AM +0900, Paul S. wrote: >> Can confirm that anything to do with netif restart on a forwarding >> interface also creates the same problem. >> >> On 4/25/2015 ?????? 01:46, Nikos Vassiliadis wrote: >>> Hi, >>> >>> Just saw this. Can somebody re-produce this? >>> >>>> root@m4fh2:~ # sysctl net.inet.ip.forwarding >>>> net.inet.ip.forwarding: 1 >>>> root@m4fh2:~ # ifconfig bridge0 create >>>> root@m4fh2:~ # sysctl net.inet.ip.forwarding >>>> net.inet.ip.forwarding: 0 >>> >>> That's on GENERIC 10-STABLE from the day before yesterday. >>> >>> Thanks, >>> Nikos > > What is your setting for gateway_enable in /etc/rc.conf? Thanks Gary, I was not using anything in rc.conf. I was just using the sysctl in /etc/sysctl.conf. Setting gateway_enable to yes fixes the issue. I am kind of surprised. Is this behaviour new? From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 17:06:54 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEA34956 for ; Fri, 24 Apr 2015 17:06:54 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7508E16A2 for ; Fri, 24 Apr 2015 17:06:54 +0000 (UTC) Received: from moby.local ([92.74.226.55]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MMk99-1YftuF0gd5-008f13; Fri, 24 Apr 2015 19:06:52 +0200 Message-ID: <553A7817.5050001@gmx.com> Date: Fri, 24 Apr 2015 19:06:31 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Thornton , freebsd-net@freebsd.org Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 References: <553A7350.40607@gmx.com> <553A73B6.8010307@winterei.se> <553A75E7.4090804@prt.org> In-Reply-To: <553A75E7.4090804@prt.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:exe2SfP8tiQNre1IKzWfaumI1VmkQ2exeEfaAKAsHQgrp6b8RrC n0FLh2dXMIK7Cv3a/Ih4gQXXwhB16gXGlk91chVI34/O+eUUbdEULTZpfpwZbeOdUeCeS4t mOB1Qgb171Nusyv5rgFwaK0xQGWgexzXjGm5kxPQ0kDYif1x9t3pGfVXL2wJ52IHGh+B3Nr I5YsWd8PlsMsfDvZSvO2A== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 17:06:55 -0000 On 04/24/15 18:57, Paul Thornton wrote: > Hi > > This happens when any interface is created if you've enabled forwarding > with the sysctl and not using gateway_enable in rc.conf. It is easily > fixed though. > > See this thread from January: > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=403720+0+archive/2015/freebsd-net/20150104.freebsd-net Ok, thanks for the pointer. Everything is clear now. Nikos From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 17:13:55 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01868C76 for ; Fri, 24 Apr 2015 17:13:54 +0000 (UTC) Received: from frv189.fwdcdn.com (frv189.fwdcdn.com [212.42.77.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B572A180A for ; Fri, 24 Apr 2015 17:13:54 +0000 (UTC) Received: from [10.10.1.28] (helo=frv196.fwdcdn.com) by frv189.fwdcdn.com with esmtp ID 1Ylgr6-000Ag4-Rz for freebsd-net@freebsd.org; Fri, 24 Apr 2015 19:53:33 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=qEKNsSOt0wpXj1nQRWVQfyKYi8f06fRgA8Cqw7cXMg4=; b=XXRbP1NMy6zRrpFus62Xd9otvIdaRNQW2OrWoBlPCf5arQ0Abca8QokkHY0WZx1rLMj+dHLQGs4VEr2FHFNd30GVQEvFCqY7zc3pgUVmJSQWO67kVFiN83TM0gejIiylp9RycxWlLz7oYpXHr2tWfXiNVw8s8SHgeLWic85k74U=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv196.fwdcdn.com with smtp ID 1Ylgqz-0009Tf-HZ for freebsd-net@freebsd.org; Fri, 24 Apr 2015 19:53:25 +0300 Date: Fri, 24 Apr 2015 19:53:25 +0300 From: wishmaster Subject: Re: net.inet.ip.forwarding is mysteriously set to 0 To: nvass@gmx.com Cc: freebsd-net@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1429894130.217124945.cx0dr7rv@frv34.fwdcdn.com> In-Reply-To: <553A7350.40607@gmx.com> References: <553A7350.40607@gmx.com> X-Reply-Action: reply Received: from artemrts@ukr.net by frv34.fwdcdn.com; Fri, 24 Apr 2015 19:53:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 17:13:55 -0000 Hi, --- Original Message --- From: "Nikos Vassiliadis" Date: 24 April 2015, 19:46:42 > Hi, > > Just saw this. Can somebody re-produce this? > > > root@m4fh2:~ # sysctl net.inet.ip.forwarding > > net.inet.ip.forwarding: 1 > > root@m4fh2:~ # ifconfig bridge0 create > > root@m4fh2:~ # sysctl net.inet.ip.forwarding > > net.inet.ip.forwarding: 0 > > That's on GENERIC 10-STABLE from the day before yesterday. > Put gateway_enable=YES into rc.conf and try again. Cheers, Vitaliy From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 18:12:01 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19F39E45 for ; Fri, 24 Apr 2015 18:12:01 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E282B1F51 for ; Fri, 24 Apr 2015 18:12:00 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t3OIBwZS016362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 11:11:58 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t3OIBw47016361; Fri, 24 Apr 2015 11:11:58 -0700 (PDT) (envelope-from jmg) Date: Fri, 24 Apr 2015 11:11:58 -0700 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, Poul-Henning Kamp Subject: should m_copyback possibly throw data away? Message-ID: <20150424181158.GJ37063@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 24 Apr 2015 11:11:59 -0700 (PDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:12:01 -0000 I was reviewing m_copyback from some other code, and noticed that it does this: if (m0 == NULL) return; at the beginin... If you pass in a NULL mbuf, it will not copy any data in.. This is clearly to avoid panics, but at the same time, this means we'll have data loss... If someone tried to copy into a NULL mbuf, it's likely a bug, and papering over that bug doesn't seem wise... I'd like to see that removed (or changed to a KASSERT), but as it's been in there since 1994: https://svnweb.freebsd.org/base/head/sys/kern/uipc_mbuf.c?r1=3351&r2=3352 That's a pretty fundamental change... mbuf(9) does not document this behavior that data may be thrown away... I would also be fine w/ documenting this behavior, though I'm sure it'd be surprising to many that you'd have to check to make sure your data was properly copied. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 18:23:10 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D2DD1B6 for ; Fri, 24 Apr 2015 18:23:10 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B0D31075 for ; Fri, 24 Apr 2015 18:23:09 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t3OIN9CR016474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Apr 2015 11:23:09 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t3OIN8g2016473; Fri, 24 Apr 2015 11:23:08 -0700 (PDT) (envelope-from jmg) Date: Fri, 24 Apr 2015 11:23:08 -0700 From: John-Mark Gurney To: freebsd-net@FreeBSD.org, Poul-Henning Kamp Subject: Re: should m_copyback possibly throw data away? Message-ID: <20150424182308.GK37063@funkthat.com> References: <20150424181158.GJ37063@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150424181158.GJ37063@funkthat.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 24 Apr 2015 11:23:09 -0700 (PDT) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:23:10 -0000 John-Mark Gurney wrote this message on Fri, Apr 24, 2015 at 11:11 -0700: > I would also be fine w/ documenting this behavior, though I'm sure > it'd be surprising to many that you'd have to check to make sure your > data was properly copied. Should have reviewed the m_copyback function before sending this email... It gets worse.. If the m_get to extend it fails, there is no notification that your data didn't get copyied into the mbuf.. and no warning in the man page that this function is unsafe and may cause data loss... Comments? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 18:39:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2D877E1 for ; Fri, 24 Apr 2015 18:39:27 +0000 (UTC) Received: from bin.sds.com (bin.sds.com [198.133.242.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bin.sds.com", Issuer "bin.sds.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2FA211F4 for ; Fri, 24 Apr 2015 18:39:27 +0000 (UTC) Received: from [10.0.1.189] (dhcp-assigned189.sds.com [10.0.1.189] (may be forged)) (authenticated bits=0) by bin.sds.com (8.15.1/8.14.7) with ESMTPSA id t3OIdKZB097069 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 24 Apr 2015 11:39:20 -0700 (PDT) (envelope-from scotto@sds.com) X-Authentication-Warning: bin.sds.com: Host dhcp-assigned189.sds.com [10.0.1.189] (may be forged) claimed to be [10.0.1.189] Message-ID: <553A8DF0.2060901@sds.com> Date: Fri, 24 Apr 2015 11:39:44 -0700 From: "Scott O'Connell" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bhyve with vlans - host and vm can't pass traffic References: <5537C5F8.1090000@sds.com> <55382C0A.1040505@shrew.net> <55384C24.5040607@sds.com> <5539395D.9040304@shrew.net> In-Reply-To: <5539395D.9040304@shrew.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.6 at bin.sds.com X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 18:39:28 -0000 On 4/23/2015 11:26 AM, Matthew Grooms wrote: > On 4/22/2015 8:34 PM, Scott O'Connell wrote: >> I tried your suggestions. >> >> I was successful in changing the vmhost01 bridge to include vlan100 >> and tap0, and in the vm (dev) binding the address directly to vtnet0. >> >> On the VMHOST: >> tap0: flags=8943 >> metric 0 mtu 1500 >> options=80000 >> ether 00:bd:4c:d1:02:00 >> media: Ethernet autoselect >> status: active >> Opened by PID 888 >> bridge0: flags=8843 metric 0 >> mtu 1500 >> ether 02:d3:e4:02:03:00 >> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 >> maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 >> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 >> member: tap0 flags=143 >> ifmaxaddr 0 port 6 priority 128 path cost 2000000 >> member: vlan100 flags=143 >> ifmaxaddr 0 port 5 priority 128 path cost 2000000 >> >> In the VM: >> vtnet0: flags=8943 >> metric 0 mtu 1500 >> options=80028 >> ether 00:a0:98:2b:34:37 >> inet 10.0.1.6 netmask 0xffffff00 broadcast 10.0.1.255 >> nd6 options=29 >> media: Ethernet 10Gbase-T >> status: active >> lo0: flags=8049 metric 0 mtu 16384 >> options=600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >> inet 127.0.0.1 netmask 0xff000000 >> nd6 options=21 >> >> The same results with regard to connectivity. Both the VMHOST and >> the VM can communicate everywhere, except with each other. >> >> I'm not sure how much detail to post, or what protocol I should be >> testing from the tcpdump, but here are a couple of relevant >> portions. Captured on the VMHOST with "tcpdump -i tap0 -n -vv", and >> on the VM with "tcpdump -i vtnet0 -n -vv" >> >> A ping from the VM (10.0.1.6) to VMHOST (10.0.1.17): >> >> Captured on tap0: >> 18:18:40.656407 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], >> proto ICMP (1), length 84) >> 10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, >> length 64 >> 18:18:40.656429 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], >> proto ICMP (1), length 84, bad cksum 0 (->55a3)!) >> 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64 >> >> Captured on vtnet0: >> 18:18:40.906203 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], >> proto ICMP (1), length 84) >> 10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, >> length 64 >> 18:18:40.906366 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], >> proto ICMP (1), length 84, bad cksum 0 (->55a3)!) >> 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64 >> >> 100% packet loss on the ping. >> >> Here is the same traffic from both systems between the VM (10.0.1.6) >> and the switch (10.0.1.1) through the VMHOST: >> >> Captured on tap0: >> 18:23:42.712065 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], >> proto ICMP (1), length 84) >> 10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64 >> 18:23:42.712595 IP (tos 0x0, ttl 255, id 2858, offset 0, flags >> [none], proto ICMP (1), length 84) >> 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64 >> >> Captured on vtnet0: >> 18:23:43.141890 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], >> proto ICMP (1), length 84) >> 10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64 >> 18:23:43.142553 IP (tos 0x0, ttl 255, id 2858, offset 0, flags >> [none], proto ICMP (1), length 84) >> 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64 >> >> 100% packet success on the ping. >> >> I'm never quite sure when checksum's with TCP Dump or Wireshark are >> expected, and when they aren't, but it appears that is where the >> problem lies here. >> >> With that said, if I'm understanding this correctly, and checksums >> are the problem, I'm not sure what to try next. >> >> Thanks again! >> > > Hi Scott, > > I certainly appears that ICMP echo reply packets are being returned > but the host isn't processing them for some reason. Do you have any > firewalls running on either system? You might try including a -e in > the tcpdump command line arguments. IIRC, that will also show you VLAN > and MAC address info from the packet headers. Maybe one of the network > kernel developers could provide some additional insight as to what may > be happening in this scenario. > > -Matthew > The latest updates: vmhost capture using "tcpdump -i tap0 -n -vv -e" 10:51:02.988660 00:a0:98:2b:34:37 > f0:1f:af:dd:2e:c5, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18864, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.17: ICMP echo request, id 34069, seq 5, length 64 10:51:02.988689 f0:1f:af:dd:2e:c5 > 00:a0:98:2b:34:37, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16775, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->230c)!) 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 34069, seq 5, length 64 vm capture using "tcpdump -i vtnet0 -n -vv -e" 10:51:03.462131 00:a0:98:2b:34:37 > f0:1f:af:dd:2e:c5, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18864, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.17: ICMP echo request, id 34069, seq 5, length 64 10:51:03.462318 f0:1f:af:dd:2e:c5 > 00:a0:98:2b:34:37, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16775, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 0 (->230c)!) 10.0.1.17 > 10.0.1.6: ICMP echo reply, id 34069, seq 5, length 64 vmhost capture using "tcpdump -i tap0 -n -vv -e" 11:10:25.372567 00:a0:98:2b:34:37 > 00:22:56:ae:f1:c7, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 20759, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.1: ICMP echo request, id 43797, seq 3, length 64 11:10:25.373188 00:22:56:ae:f1:c7 > 00:a0:98:2b:34:37, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 255, id 20759, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 43797, seq 3, length 64 vm capture using "tcpdump -i vtnet0 -n -vv -e" 11:10:25.890274 00:a0:98:2b:34:37 > 00:22:56:ae:f1:c7, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 20759, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.1: ICMP echo request, id 43797, seq 3, length 64 11:10:25.891083 00:22:56:ae:f1:c7 > 00:a0:98:2b:34:37, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 255, id 20759, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 43797, seq 3, length 64 It doesn't look like any frames are being tagged. However, if I look at lagg0, and pick another ping between the vm and the switch, vlan tagging IS occurring: 11:18:28.209997 00:a0:98:2b:34:37 > 00:22:56:ae:f1:c7, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 21499, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.6 > 10.0.1.1: ICMP echo request, id 43797, seq 461, length 64 11:18:28.210527 00:22:56:ae:f1:c7 > 00:a0:98:2b:34:37, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 255, id 21499, offset 0, flags [none], proto ICMP (1), length 84) 10.0.1.1 > 10.0.1.6: ICMP echo reply, id 43797, seq 461, length 64 So I've tried bridging lagg0 and tap0 on the VMHOST, with vtnet0 and vlan100 in the VM, and bridging vlan100 and tap0 on the VMHOST, and native vtnet0 in the VM. Both instances the VMHOST and VM can't talk to each other, but can with anything upstream of the VMHOST through lagg0. (I wrote this mostly for myself, but decided to leave it in!) I've tried applying various vlan options to the tap and bridge interfaces, but since they're not physical interfaces, those options appear to be invalid. Any new ideas? Thanks, scotto From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 21:03:20 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2ACE1262 for ; Fri, 24 Apr 2015 21:03:20 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 166C31312 for ; Fri, 24 Apr 2015 21:03:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3OL3J8N019947 for ; Fri, 24 Apr 2015 21:03:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage Date: Fri, 24 Apr 2015 21:03:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: robak@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:03:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 Bartek Rutkowski changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robak@freebsd.org --- Comment #21 from Bartek Rutkowski --- Is there any update on these fixes? I've just happened to bump my 10.1-RELEASE into 10-STABLE and created few VIMAGE based jails. As soon as I stop any of them, and I can reproduce it every time, the host OS crashes. That makes the entire VIMAGE completely unusable... -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 21:05:37 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 262F3464 for ; Fri, 24 Apr 2015 21:05:37 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0830A1337 for ; Fri, 24 Apr 2015 21:05:37 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t3OL5a0k023363 for ; Fri, 24 Apr 2015 21:05:36 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t3OL5a0x023362; Fri, 24 Apr 2015 21:05:36 GMT (envelope-from daemon-user) Date: Fri, 24 Apr 2015 21:05:36 +0000 To: freebsd-net@freebsd.org From: "robak (Bartek Rutkowski)" Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: <6d613025557bbac5654b2505a4095f84@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFU6sCA= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:05:37 -0000 robak added a subscriber: robak. robak added a comment. Is there any update on these fixes? I've just happened to bump my 10.1-RELEASE into 10-STABLE and created few VIMAGE based jails. As soon as I stop any of them, and I can reproduce it every time, the host OS crashes. That makes the entire VIMAGE completely unusable... REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn Cc: robak, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Fri Apr 24 21:09:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD5035CF for ; Fri, 24 Apr 2015 21:09:28 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFDA81379 for ; Fri, 24 Apr 2015 21:09:28 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t3OL9Sf8023582 for ; Fri, 24 Apr 2015 21:09:28 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t3OL9S4k023581; Fri, 24 Apr 2015 21:09:28 GMT (envelope-from daemon-user) Date: Fri, 24 Apr 2015 21:09:28 +0000 To: freebsd-net@freebsd.org From: "glebius (Gleb Smirnoff)" Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFU6sQg= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 21:09:29 -0000 glebius added a comment. Recently Nikos has asked questions on kernel debugging. So, I guess, he is working. REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn Cc: robak, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Apr 25 00:59:28 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53B8AC68 for ; Sat, 25 Apr 2015 00:59:28 +0000 (UTC) Received: from mail-wi0-f197.google.com (mail-wi0-f197.google.com [209.85.212.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DB523199A for ; Sat, 25 Apr 2015 00:59:27 +0000 (UTC) Received: by wixv7 with SMTP id v7so7679866wix.0 for ; Fri, 24 Apr 2015 17:59:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ykr1LZLqo+h7fUvVn0yfsTjRZH5m2IJQBc06XuS2Zjc=; b=e679VlNr1p44xd9cpW3oVB/oq6lfv2bIWvXIVdYjl0SltkNIEKHGSn2eK3apydiqdD nBv7T/yd4PoZRtmCgOU2NPyyeafMBNtWedd7jCeDN6IaOtaIXS/HhXm5JHxFzjFZlRV/ fqggIcbz6ktTknXFA1FcNUqgjF1u9LYrmR5YXGuPliaCrjmq8gioDQ3wFp7h7eThypUc MtDKPz61Ko3BqJMcocWB5EJwjt6p69Mz7QysQtoMmzTMWJNtjbmCoGeQMn7VSsAjEl+l pvKEgs33iYnkFY/vBqDgmzt+UJgPtTcIGd3F8JKOzRY0n61MFUBLsQBcbkivB7xp30QI /wBA== X-Gm-Message-State: ALoCoQlrhL2huAbceYmxLBsu2MZjmcQWlJUx/15Fr9T4VJQArN2236Am0dvv/zPV127YVlSsqwTS MIME-Version: 1.0 X-Received: by 10.112.181.68 with SMTP id du4mr582626lbc.11.1429917596397; Fri, 24 Apr 2015 16:19:56 -0700 (PDT) Received: by 10.25.78.149 with HTTP; Fri, 24 Apr 2015 16:19:56 -0700 (PDT) In-Reply-To: <20150423121433.GA15890@ox> References: <20150423121433.GA15890@ox> Date: Fri, 24 Apr 2015 16:19:56 -0700 Message-ID: Subject: Re: net.inet.ip.forwarding impact on throughput From: Scott Larson To: Scott Larson , freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 00:59:28 -0000 Thanks Navdeep, I figured there had to be more going on than just allowing packets across interfaces. With forwarding automatically disabling TSO/LRO that would entirely explain why my bandwidth throughput tests drop off significantly. *[image: userimage]Scott Larson[image: los angeles] Lead Systems Administrator[image: wdlogo] [image: linkedin] [image: facebook] [image: twitter] [image: instagram] T 310 823 8238 x1106 <310%20823%208238%20x1106> | M 310 904 8818 <310%20904%208818>* On Thu, Apr 23, 2015 at 5:14 AM, Navdeep Parhar wrote: > On Tue, Apr 21, 2015 at 12:47:45PM -0700, Scott Larson wrote: > > We're in the process of migrating our network into the future with > 40G > > at the core, including our firewall/traffic routers with 40G interfaces. > An > > issue which this exposed and threw me for a week turns out to be directly > > related to net.inet.ip.forwarding and I'm looking to just get some > insight > > on what exactly is occurring as a result of using it. > > Enabling forwarding disables LRO and TSO and that probably accounts for > a large part of the difference in throughput that you've observed. The > number of packets passing through the stack (and not the amount of data > passing through) is the dominant bottleneck. > > fastforwarding _should_ make a difference, but only if packets actually > take the fast-forward path. Check the counters available via netstat: > # netstat -sp ip | grep forwarded > > Regards, > Navdeep > > > What I am seeing is when that knob is set to 0, an identical pair of > > what will be PF/relayd servers with direct DAC links between each other > > using Chelsio T580s can sustain around 38Gb/s on iperf runs. However the > > moment I set that knob to 1, that throughput collapses down into the 3 to > > 5Gb/s range. As the old gear this is replacing is all GigE I'd never > > witnessed this. Twiddling net.inet.ip.fastforwarding has no apparent > effect. > > I've not found any docs going in depth on what deeper changes > enabling > > forwarding does to the network stack. Does it ultimately put a lower > > priority on traffic where the server functioning as the packet router is > > the final endpoint in exchange for having more resources available to > route > > traffic across interfaces as would generally be the case? > > > > > > *[image: userimage]Scott Larson[image: los angeles] > > < > https://www.google.com/maps/place/4216+Glencoe+Ave,+Marina+Del+Rey,+CA+90292/@33.9892151,-118.4421334,17z/data=!3m1!4b1!4m2!3m1!1s0x80c2ba88ffae914d:0x14e1d00084d4d09c > >Lead > > Systems Administrator[image: wdlogo] > [image: > > linkedin] [image: facebook] > > [image: twitter] > > [image: instagram] > > T 310 823 8238 x1106 > > <310%20823%208238%20x1106> | M 310 904 8818 <310%20904%208818>* > > _______________________________________________ > > 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 Sat Apr 25 01:32:21 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC23F5AD for ; Sat, 25 Apr 2015 01:32:21 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 959FE1D25 for ; Sat, 25 Apr 2015 01:32:21 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3P1WLow054620 for ; Sat, 25 Apr 2015 01:32:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 194515] Fatal Trap 12 Kernel with vimage Date: Sat, 25 Apr 2015 01:32:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: needs-qa X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: bug_status flagtypes.name keywords bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 01:32:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194515 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open Flags| |mfc-stable10? Keywords| |needs-qa Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Apr 25 05:32:38 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E58A5EA for ; Sat, 25 Apr 2015 05:32:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7C381471 for ; Sat, 25 Apr 2015 05:32:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3P5Wbqo067258 for ; Sat, 25 Apr 2015 05:32:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2)) Date: Sat, 25 Apr 2015 05:32:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 05:32:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181741 --- Comment #9 from commit-hook@freebsd.org --- A commit references this bug: Author: ngie Date: Sat Apr 25 05:32:03 UTC 2015 New revision: 281974 URL: https://svnweb.freebsd.org/changeset/base/281974 Log: MFC r261550,r281354,r281355,r281356,r281358,r281359,r281360,r281361,r281362,r281391,r281392,r281393,r281394,r281395,r281397,r281398,r281399,r281400,r281401,r281402,r281403,r281404,r281407,r281408,r281409,r281410,r281411: r261550 (by glebius): Add test case for kern/181741. Right now test fails. PR: 181741 Sponsored by: Nginx, Inc. r281354: Fix warnings, fix a typo in a testcase description, bump WARNS to 3 - Remove argc/argv (-Wunused) - Cast len in comparison to size_t (-Wsign-compare) Sponsored by: EMC / Isilon Storage Division r281355: Fix -Wunused warnings, bump WARNS to 6 The testcase fails today on subtest # 9 The output is still broken if prove -rv is run and the testcase aborts prematurely (the testcase doesn't really conform to TAP protocol properly, except when it completes fully) Sponsored by: EMC / Isilon Storage Division r281356: Fix -Wunused warnings, bump WARNS to 6 The output is still broken if prove -rv is run and the testcase aborts prematurely with fail_assertion (the testcase doesn't really conform to TAP protocol properly, except when it completes fully) Sponsored by: EMC / Isilon Storage Division r281358: - Parameterize out the number of accept/connect attempts - Randomize the bind port to allow 2+ consecutive calls in < 10 minutes, and to also not fail if (for instance) there's a server already listening on port 8080 - Don't leak the listening socket / fds into the child process - Fix warnings: -- Remove argc/argv (-Wunused) -- Mark sig __unused (-Wunused) -- Mark quit static (-Wmissing-variable-declarations) Sponsored by: EMC / Isilon Storage Division r281359: Remove argc/argv (-Wunused) Sponsored by: EMC / Isilon Storage Division r281360: Fix warnings - Remove argc/argv (-Wunused) - Mark some parameters to socket_listen_update __unused (-Wunused) Sponsored by: EMC / Isilon Storage Division r281361: Remove argc/argv (-Wunused) Sponsored by: EMC / Isilon Storage Division r281362: Use _exit, not exit in forked process Sponsored by: EMC / Isilon Storage Division r281391: - Use static buffers for temporary file paths instead of strdup of constant strings - Don't use /tmp because it's outside ATF's prescribed sandbox - Use mkstemp instead of mktemp to eliminate warning Sponsored by: EMC / Isilon Storage Division r281392: - Garbage collect argc/argv (-Wunused) - Bump WARNS to 6 Sponsored by: EMC / Isilon Storage Division r281393: Fix warnings and bump WARNS to 6 - Garbage collect argc/argv (-Wunused) - sleep(3) will always return an unsigned int; don't check for return codes <0 (-Wsign-compare) Sponsored by: EMC / Isilon Storage Division r281394: - Don't use /tmp because it's outside ATF's prescribed sandbox - Replace a hardcoded PATH_MAX value with sizeof(path) - Use path like an array, not a pointer, and always try to unlink it in cleanup Sponsored by: EMC / Isilon Storage Division r281395: Fix a -Wuninitialized warning by setting the socket to -1 and bump WARNS to 6 Sponsored by: EMC / Isilon Storage Division r281397: Mark signum unused in signal_handler; bump WARNS to 6 Sponsored by: EMC / Isilon Storage Division r281398: Garbage collect argc/argv and bump WARNS to 6 Sponsored by: EMC / Isilon Storage Division r281399: Fix warnings and bump WARNS to 6 - Staticize variables as needed - Garbage collect argc/argv - Fix -Wsign-compare warnings by casting small sizeof to (int) Sponsored by: EMC / Isilon Storage Division r281400: - Garbage collect argc/argv; bump WARNS to 6 - Make the socket path random and move it out of /tmp as that's outside ATF's prescribed path Sponsored by: EMC / Isilon Storage Division r281401: - Garbage collect argc/argv - Use random paths instead of one in /tmp Sponsored by: EMC / Isilon Storage Division r281402: Garbage collect argc/argv and bump WARNS to 6 Sponsored by: EMC / Isilon Storage Division r281403: Garbage collect argc/argv and bump WARNS to 6 Sponsored by: EMC / Isilon Storage Division r281404: Generate temporary files with mkstemp instead of mktemp Sponsored by: EMC / Isilon Storage Division r281407: Fix the knob twiddling to work properly per src.opts.mk Sponsored by: EMC / Isilon Storage Division r281408: - Remove the .t wrapper and put the "magic" of determining the number of testcases into the .c file - Require root for now because it fails with SOCK_RAW without root privileges - Increment the test count properly on socket create failure Sponsored by: EMC / Isilon Storage Division r281409: Fix warnings, bump WARNS to 6, and use a temporary socket instead of one in /tmp Sponsored by: EMC / Isilon Storage Division r281410: Fix more warnings I didn't catch in the first go-around Sponsored by: EMC / Isilon Storage Division r281411: Fix even more warnings.. Sponsored by: EMC / Isilon Storage Division Changes: _U stable/10/ stable/10/tools/regression/sockets/accept_fd_leak/Makefile stable/10/tools/regression/sockets/accept_fd_leak/accept_fd_leak.c stable/10/tools/regression/sockets/accf_data_attach/Makefile stable/10/tools/regression/sockets/accf_data_attach/accf_data_attach.c stable/10/tools/regression/sockets/fstat/Makefile stable/10/tools/regression/sockets/fstat/fstat.c stable/10/tools/regression/sockets/kqueue/Makefile stable/10/tools/regression/sockets/kqueue/kqueue.c stable/10/tools/regression/sockets/listen_backlog/Makefile stable/10/tools/regression/sockets/listen_backlog/listen_backlog.c stable/10/tools/regression/sockets/listenclose/Makefile stable/10/tools/regression/sockets/listenclose/listenclose.c stable/10/tools/regression/sockets/pr_atomic/Makefile stable/10/tools/regression/sockets/pr_atomic/pr_atomic.c stable/10/tools/regression/sockets/reconnect/Makefile stable/10/tools/regression/sockets/reconnect/reconnect.c stable/10/tools/regression/sockets/rtsocket/Makefile stable/10/tools/regression/sockets/rtsocket/rtsocket.c stable/10/tools/regression/sockets/sblock/Makefile stable/10/tools/regression/sockets/sblock/sblock.c stable/10/tools/regression/sockets/sendfile/sendfile.c stable/10/tools/regression/sockets/shutdown/Makefile stable/10/tools/regression/sockets/shutdown/shutdown.c stable/10/tools/regression/sockets/sigpipe/Makefile stable/10/tools/regression/sockets/sigpipe/sigpipe.c stable/10/tools/regression/sockets/so_setfib/Makefile stable/10/tools/regression/sockets/so_setfib/so_setfib.c stable/10/tools/regression/sockets/so_setfib/so_setfib.t stable/10/tools/regression/sockets/socketpair/Makefile stable/10/tools/regression/sockets/socketpair/socketpair.c stable/10/tools/regression/sockets/unix_bindconnect/Makefile stable/10/tools/regression/sockets/unix_bindconnect/unix_bindconnect.c stable/10/tools/regression/sockets/unix_close_race/Makefile stable/10/tools/regression/sockets/unix_close_race/unix_close_race.c stable/10/tools/regression/sockets/unix_passfd/Makefile stable/10/tools/regression/sockets/unix_passfd/unix_passfd.c stable/10/tools/regression/sockets/unix_sendtorace/Makefile stable/10/tools/regression/sockets/unix_sendtorace/unix_sendtorace.c stable/10/tools/regression/sockets/unix_socket/Makefile stable/10/tools/regression/sockets/unix_socket/unix_socket.c stable/10/tools/regression/sockets/unix_sorflush/Makefile stable/10/tools/regression/sockets/unix_sorflush/unix_sorflush.c stable/10/tools/regression/sockets/zerosend/zerosend.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-net@FreeBSD.ORG Sat Apr 25 12:49:06 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2DFA0DF6 for ; Sat, 25 Apr 2015 12:49:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BB381BDC for ; Sat, 25 Apr 2015 12:49:06 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t3PCn51k091151 for ; Sat, 25 Apr 2015 12:49:05 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t3PCn5ed091150; Sat, 25 Apr 2015 12:49:05 GMT (envelope-from daemon-user) Date: Sat, 25 Apr 2015 12:49:05 +0000 To: freebsd-net@freebsd.org From: "nvass-gmx.com (Nikos Vassiliadis)" Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: <21b5b61ed41e59153a27fac3647f7f35@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFU7jUE= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 12:49:06 -0000 nvass-gmx.com added a comment. Yes, I am trying to fix the issues. It needs more work. I will update when I have a new patch REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn Cc: robak, freebsd-virtualization, freebsd-pf, freebsd-net From owner-freebsd-net@FreeBSD.ORG Sat Apr 25 16:52:40 2015 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B4B1448 for ; Sat, 25 Apr 2015 16:52:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7565212FE for ; Sat, 25 Apr 2015 16:52:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t3PGqexB032294 for ; Sat, 25 Apr 2015 16:52:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-net@FreeBSD.org Subject: [Bug 199489] NAT with IPv6 and PF round robins between external address and link-local address Date: Sat, 25 Apr 2015 16:52:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-net@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 16:52:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199489 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Assignee|freebsd-bugs@FreeBSD.org |freebsd-net@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.