From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 09:20:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A5E9C14 for ; Sun, 17 Mar 2013 09:20:41 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2A5A48D8 for ; Sun, 17 Mar 2013 09:20:40 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id up1so5547018pbc.9 for ; Sun, 17 Mar 2013 02:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=fxq6ntUAhGp7nJhQnblHkmJEMMsvOECznvtGnd9Y0fg=; b=iJQ4eskMMNjZgttJAcLjvJmfvKaAKADMEwv8gHOvh/wbuSQssjU30Ey6ngpvQNX+xu jpZdudWngsnOQ8c/xVwPpux8L+1+DD92Edo8ZNXcPO+uF50Pa1pLdUWLzNJs6WyxX/a8 GoCDeqQEbRb2P71A5fNH6O2wBNOfRvMVoyvUIt8rKJkRJLFaR4EnPlRfd27sr2BxP+7I /DgOp+X3jZ7pM7KxbOXpRYpa8AT6erDBirVrso4e+DL57FCs/SFDLhp47bKyygwy0XoT JVFWk5Qn3HiqGj/FyhzHExpeKa5Uz4G9V+dpSQ0vBa6LUDlxXTWpYYFNABdXuy7PvDCI bz6g== MIME-Version: 1.0 X-Received: by 10.68.196.225 with SMTP id ip1mr27605689pbc.72.1363512040539; Sun, 17 Mar 2013 02:20:40 -0700 (PDT) Received: by 10.70.34.103 with HTTP; Sun, 17 Mar 2013 02:20:40 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Mar 2013 11:20:40 +0200 Message-ID: Subject: Re: MPLS From: Sami Halabi To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 09:20:41 -0000 any one? :) On Fri, Mar 15, 2013 at 6:28 PM, Sami Halabi wrote: > Hi, > Are there ongoing job of mpls in freebsd? > I saw thd site http://freebsd.mpls.in for aboug a year now and I don't > see much progress. > ITOH OpenBSD has a complete implementation of MPLS out of the box, maybe > porting it would be short and more straight forward than porting linux LDP > implementation of BIRD. > > Thanks in advance, > Sami > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 10:03:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B92BF397 for ; Sun, 17 Mar 2013 10:03:09 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5BE71A01 for ; Sun, 17 Mar 2013 10:03:08 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2HA34xf042068 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 17 Mar 2013 16:03:06 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <514594D7.1020202@norma.perm.ru> Date: Sun, 17 Mar 2013 16:03:03 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: carp regression in 9.1 ? References: <3B04FCB1-D0D4-4BC9-BB15-5221F438738C@my.gd> In-Reply-To: <3B04FCB1-D0D4-4BC9-BB15-5221F438738C@my.gd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Sun, 17 Mar 2013 16:03:06 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 10:03:09 -0000 Hi. On 14.03.2013 20:47, Fleuriot Damien wrote: > I'm experiencing this odd behavior with 9.1 r24791 for amd64. > You should definitely sit on 8.x until 10.x will become stable, or upgrade to 10.x from 9.x (at least this is what I do). Carp is entirely rewritten in 10.x branch. In the same time, in 9.x carp seems to be desperately broken: for example I was experiencing weird panics on boot, weird behaviour, and, when enabling WITNESS, lots of carp-related LORs. Furthermore, I was completely unable to boot up with a ipv6-enabled carp - I had to initialize it in multiuser with a custom script. All of this doesn't happen on 10.x, which I had to upgrade to. Right now, if we're talking about carp, my 10.x production works like a charm. 9.x branch just isn't destined to production. The situation is a bit improved on 9.1, but still I can compare this release to 4.6 or 5.0. Eugene. From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 15:08:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B03F0A4A for ; Sun, 17 Mar 2013 15:08:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 1E96E68E for ; Sun, 17 Mar 2013 15:08:17 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id r6so4205072wey.5 for ; Sun, 17 Mar 2013 08:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HGwnXQFG58hP6Buo03ZpNAbbSWqMS3jkgDHKuNSzNJ0=; b=VpqmWifB3Dr2OTae7a6J9V6W3PVwCDvmP40qa5SA11F9r4K6TtxKtE3hLogBD5jEvS neJfl7uFE6u3ssFhuwZKiSe3usSg3sVDV1C3ggmVVMkyCfNjLhHflDf4hLXHQZPb3LYU 0B+k6/iqbGJxOi5eNyhDxnOADQFm4lO3TJdVF4kJX8oJWZnBH1dA2Hakbywlnv4r55MJ Hwyd18kuPzhTJkjgVUlBKBPQQx1mW8o6Lk4AcWtpMwem5N9lHfiebhw2Q8cPpqIq7bbV 7NNdVfKaXAddhZiL0JhU/kjPGruk5EYfGvUd9/nZQoiGbh/iWuQ2yJwXmplHCCmQBPQ7 7uZQ== MIME-Version: 1.0 X-Received: by 10.180.86.1 with SMTP id l1mr11806531wiz.32.1363532897139; Sun, 17 Mar 2013 08:08:17 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.111.201 with HTTP; Sun, 17 Mar 2013 08:08:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Mar 2013 08:08:17 -0700 X-Google-Sender-Auth: grJeUrcuKBXbMdc64WOWL5Uf8zg Message-ID: Subject: Re: MPLS From: Adrian Chadd To: Sami Halabi Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 15:08:18 -0000 On 17 March 2013 02:20, Sami Halabi wrote: > any one? :) I'd love to see MPLS support in FreeBSD. The question is finding someone willing to do it, or sponsor the work. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 15:20:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0F7427F for ; Sun, 17 Mar 2013 15:20:40 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by mx1.freebsd.org (Postfix) with ESMTP id B6E1D71B for ; Sun, 17 Mar 2013 15:20:40 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id k5so2839217qej.37 for ; Sun, 17 Mar 2013 08:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eMQd8hS8GVUE672tCVTMALz9DWQfrLaqqWYJNQWNmFM=; b=upb/DXivhcxgGk9/hhvsMvz0Fnv2Roja9TLlsE6LdhJHmbK/l73KJstplnXQx0gsRU NIvmz1h6qzbL1nJefaeM2iV7cRjHmXnchBCdrNmCBpQt0pC+OqAS6xfL3h4PSk7ZeMsr uPjZQ13s985s5Pa0hxk5Fu6moDf80pZpNGj/D5UdT+iXNI8VFE4n2cjAGIB8otk8+1ju yPhuxHm/akOo8UHcuGikOKVYeB+AlriM/ALXkOMUmzx6YukAEHqCpnhXECXBmwnHClI4 KlNSrXCoSTSVOw1lvwsBbg+k0o9I+9ANwT72xzZhI4UQg21/kQPH3dCtZE9AxWv18yhA 8Z6A== MIME-Version: 1.0 X-Received: by 10.49.30.70 with SMTP id q6mr17195431qeh.28.1363533634001; Sun, 17 Mar 2013 08:20:34 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.98.103 with HTTP; Sun, 17 Mar 2013 08:20:33 -0700 (PDT) In-Reply-To: <514594D7.1020202@norma.perm.ru> References: <3B04FCB1-D0D4-4BC9-BB15-5221F438738C@my.gd> <514594D7.1020202@norma.perm.ru> Date: Sun, 17 Mar 2013 16:20:33 +0100 X-Google-Sender-Auth: SQ-G22Uy6oqur-C53KSC6YC71AE Message-ID: Subject: Re: carp regression in 9.1 ? From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: "Eugene M. Zheganin" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 15:20:41 -0000 On Sun, Mar 17, 2013 at 11:03 AM, Eugene M. Zheganin wrote: > Hi. > > > On 14.03.2013 20:47, Fleuriot Damien wrote: > >> I'm experiencing this odd behavior with 9.1 r24791 for amd64. >> >> You should definitely sit on 8.x until 10.x will become stable, or > upgrade to 10.x from 9.x (at least this is what I do). > Carp is entirely rewritten in 10.x branch. In the same time, in 9.x carp > seems to be desperately broken: for example I was experiencing weird panics > on boot, weird behaviour, and, when enabling WITNESS, lots of carp-related > LORs. Furthermore, I was completely unable to boot up with a ipv6-enabled > carp - I had to initialize it in multiuser with a custom script. All of > this doesn't happen on 10.x, which I had to upgrade to. Right now, if we're > talking about carp, my 10.x production works like a charm. 9.x branch just > isn't destined to production. The situation is a bit improved on 9.1, but > still I can compare this release to 4.6 or 5.0. >From this aspects carp in 10(HEAD) should behave the same since the internals of carp have not been changed only the iconnection with the FreeBSD stack has. Talking about aliases on carp that used to be a bit broken up-to 9.x they do not exist at all in 10. Which needs a bit of discussion per se how to solve. I will get to it by summer and see to merge improvements in that area. > > > Eugene. > > ______________________________**_________________ > 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 > " > -- Ermal From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 18:21:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A8A3C14 for ; Sun, 17 Mar 2013 18:21:09 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id D695FCC6 for ; Sun, 17 Mar 2013 18:21:08 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id u3so404255wey.38 for ; Sun, 17 Mar 2013 11:21:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id:x-gm-message-state; bh=L1wDGFpj2sJPrL/QXtwdWMyWmRELxbmHKLHmpLIhfpk=; b=U5Bm6pdMCDgQBhzXQ2Vcw3OyjphryHQyxXGj6mf7/QgD0T+2Ampi81jtcCvLFN59jZ yGe8Dmt71TqVcDi0WkHlfTxUGEiB5ien6vKbbN08JAXK55XteI/nnLf+p+zoa3dz6oP2 dPtRsgf6jzStmbTZrr0Kp0ur8f3sCjjAnHpiSawyhwJ8Kt0EPhqJcy+1jY+ASE/xIKxc QhO0SEfgGzobMoZeVuLG0iah6y0z4coC/Y2eZ5KvPWCfjc1nFvC1CAEgwubelJv63Fkn PfKVF5gF2zVJnTW/NWnw8AtCKmrbfUC9dSIMVazSyJsNd0dPKSwTnHZ6//73ht8hmflt sCrA== X-Received: by 10.180.105.99 with SMTP id gl3mr12616605wib.22.1363544467720; Sun, 17 Mar 2013 11:21:07 -0700 (PDT) Received: from zvezda.localnet ([109.144.239.183]) by mx.google.com with ESMTPS id ex1sm10482636wib.7.2013.03.17.11.21.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 17 Mar 2013 11:21:06 -0700 (PDT) From: Kajetan Staszkiewicz To: Ermal =?iso-8859-1?q?Lu=E7i?= Subject: Re: [patch] Source entries removing is awfully slow. Date: Sun, 17 Mar 2013 19:18:17 +0100 User-Agent: KMail/1.13.5 (Linux/3.6.6-vegeta.1; KDE/4.4.5; x86_64; ; ) References: <201303081419.17743.vegeta@tuxpowered.net> <201303111751.18274.vegeta@tuxpowered.net> <201303131651.03250.vegeta@tuxpowered.net> In-Reply-To: <201303131651.03250.vegeta@tuxpowered.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201303171918.17512.vegeta@tuxpowered.net> X-Gm-Message-State: ALoCoQnsSINwNjpxNcewhy0Ayb1CE08Qe1U40OwWAsfn6LqGuKrbs7rUEwRUbBY1mdT3fPAi73bu Cc: "freebsd-net@freebsd.org" , "freebsd-pf@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 18:21:09 -0000 Hi, I think I have the answer. 1. Some traffic creates a nat src node and some states. 2. Those states are properly linked to src_node->state_list, each has a proper pointer to nat_src_node. 3. At some point insertion of state (I do not for what reason) fails in this code: 3970 if (pf_state_insert(BOUND_IFACE(r, kif), skw, sks, s)) { 3971 if (pd->proto == IPPROTO_TCP) 3972 pf_normalize_tcp_cleanup(s); 3973 REASON_SET(&reason, PFRES_STATEINS); 3974 pf_src_tree_remove_state(s); 3975 STATE_DEC_COUNTERS(s); 3976 #ifdef __FreeBSD__ 3977 pool_put(&V_pf_state_pl, s); This state already has nat_src_node properly pointing to the src node. pf_src_tree_remove_state() is called: - s->nat_src_node is not NULL - TAILQ_EMPTY is false, as the src_node has a state_list containing some previously and properly created states - TAILQ_REMOVE fails because state s is not in the list, s->srcnode_link is {NULL,NULL}, src_node->state_list's head gets broken, giving the result as in my previous post and kernel panic. With calling TAILQ_INSERT_HEAD before any pf_src_tree_remove_state is potentally called, I have a kernel running stable since the last week. -- | pozdrawiam / greetings | powered by Debian, CentOS and FreeBSD | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 18:57:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C863E7D0 for ; Sun, 17 Mar 2013 18:57:35 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA2BE03 for ; Sun, 17 Mar 2013 18:57:35 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UHIpL-000DQY-1V; Sun, 17 Mar 2013 23:01:03 +0400 Message-ID: <5146121B.5080608@FreeBSD.org> Date: Sun, 17 Mar 2013 22:57:31 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Sami Halabi Subject: Re: MPLS References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 18:57:35 -0000 On 17.03.2013 13:20, Sami Halabi wrote: > any one? :) > > > On Fri, Mar 15, 2013 at 6:28 PM, Sami Halabi wrote: > >> Hi, >> Are there ongoing job of mpls in freebsd? >> I saw thd site http://freebsd.mpls.in for aboug a year now and I don't >> see much progress. Yep. It was frozen for a while. Currently I'm working on it again. control plane code was heavily redesigned, see http://bird.mpls.in/projects/mpls-bird/repository/show?rev=bird_mpls I have some working MPLS code on 8-S and I hope to create freebsd svn branch with base MPLS support in 2-3 weeks. >> ITOH OpenBSD has a complete implementation of MPLS out of the box, maybe Their control plane code is mostly useless due to design approach (routing daemons talk via kernel). Their data plane code, well.. Yes, we can use some defines from their headers, but that's all :) >> porting it would be short and more straight forward than porting linux LDP >> implementation of BIRD. It is not 'linux' implementation. LDP itself is cross-platform. The most tricky place here is control plane. However, making _fast_ MPLS switching is tricky too, since it requires chages in our netisr/ethernet handling code. >> >> Thanks in advance, >> Sami >> > > > From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 21:27:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26D158A5 for ; Sun, 17 Mar 2013 21:27:02 +0000 (UTC) (envelope-from yoann.gini@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id 8C88731F for ; Sun, 17 Mar 2013 21:27:01 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id l13so2186082wie.4 for ; Sun, 17 Mar 2013 14:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer; bh=wSikuKge5khcX/ScOuXR6Lcd9ar01G9P8v0ckKJ6Za0=; b=PjgHjYKMQSK2TFLkvH0Hya3TueaPnFljiAs/OLYZPcDQDqX62X0cmg1Mn2gxua6nCF vItQ6ewK1Arwmju1TlSEgx1celsCzmc6XdA9M7DobkZb9H6m+sjRNxRDyC8eXSJklOLT YrjePCDRz10fMIJdQexEGeChCraqcKpvzn1UIBuDQalRdcRNAZer4wZp13huDFBRVh2Y /FjJDa0Bt7otsuusGtFEo2v069mra5UgX8d2qQ1OejXDZwVRjv7owwudIN+wXtdL/tz9 eHM9X+NEcwrKRUQcQfkbyE7ALdmnp+ZmH1oGfrdVYeqhHYXDkpiCCq54wNAhNxThEpEG nXtg== X-Received: by 10.180.75.177 with SMTP id d17mr13185880wiw.16.1363555620833; Sun, 17 Mar 2013 14:27:00 -0700 (PDT) Received: from [192.168.1.38] (81.131.1.93.rev.sfr.net. [93.1.131.81]) by mx.google.com with ESMTPS id fx5sm11321197wib.11.2013.03.17.14.26.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 14:26:59 -0700 (PDT) From: Yoann Gini Content-Type: multipart/signed; boundary="Apple-Mail=_E997CD8F-4153-44D0-A1F0-0E6A152C7CE7"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: mpd5 and multiple route to send to clients Message-Id: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> Date: Sun, 17 Mar 2013 22:26:56 +0100 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 21:27:02 -0000 --Apple-Mail=_E997CD8F-4153-44D0-A1F0-0E6A152C7CE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello, I=92m Yoann. It=92s my first message here so a little brief about me. = I=92m a OS X Server System Administrator and Trainer, actually working = on a FreeBSD based setup for a simple service provider infrastructure. I currently setup a L2TP over IPSec VPN server with FreeBSD 9.1 and mpd = 5.6. I=92ve done with success my setup with radius authentication and all = interesting stuff except for one thing that I can=92t find on Internet. I need to push some routes to my clients to configure them to use the = VPN interface to reach some private network available behind my server. I can=92t find any clue about how to do that=85 They have a =AB set iface route =BB option but this add the route on the = server side, I want the same to push route on the client side=85 If someone can give my a clue=85 Best regards, Yoann Gini.= --Apple-Mail=_E997CD8F-4153-44D0-A1F0-0E6A152C7CE7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUqMIIEEqADAgECAhEA8BSF4QUynr/oAOUnSVCBvTANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzAzMDMw MDAwMDBaFw0xNDAzMDMyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFHlvYW5uLmdpbmlAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11zV57Sqb+CpMeUSmttu8MsHvdUR vZS9O5jKxWljaeZgQbr4A/yShO5PB7MgM4KMQjMIOoacShFvyf6ZivL8r8fFbAmc6NsHr4CN4S9T E0WAi/MWUTPLYrD8zx0NsjimxLP/3Ln1b3TDb0Vp/bqOWePStBU2truYBodyGZCQiHVPBZC6d5tu CswgnIbloUTf4RxyGGt8NCl94lBiw6ZNNc+94BRlIY8a6uyV5/9jqiAu/LZVpLV5n9YZ5BCfoRsM GAi94eUzFv/AdCLp+l0OGjQ+K8APeHihjU8/VtNujjW1tA7r5bs3O8wTQ6lCoCV8J+XZMWUK4grO xisqX5umywIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYD VR0OBBYEFH28/IbXcUSiVbEyWOgyob3zTeHTMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEE fDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHwYDVR0RBBgwFoEUeW9hbm4uZ2luaUBnbWFpbC5jb20wDQYJKoZIhvcNAQEF BQADggEBAC2aIbicOEFNkJwJlCEoBFsi/7im9S6E0GwQ2/+bn0GhOTZQ+mkB9Up2A99TsAV2dWJ/ TClZ5a/tx4K6eP+r7q1ci1QcDdomD8NLI+zpU0zx+I/RnEca24AYJ3fC5dS6nR5sjTj2zoYa0pXs CVrMb24vXBr14iLwG7U+REEX6+p0tbwAjrJLPnViS1TvUPBz5J9W2ag10cCaecSsa6VOGR3xR5ah r9pWGtKZ+xKxnuPsmny5xKCeB+73ZI6DTanIXzHiduGm3A/y7maIjJq4gy7Vm2hH3HaBTV4ZS/DZ 2/sKr5k9/asWaJosS5ciE00tMLCrvogWdF4xhSxUrm/C7j4xggOuMIIDqgIBATCBqTCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQgb0wCQYFKw4DAhoF AKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE3MjEy NjU3WjAjBgkqhkiG9w0BCQQxFgQUbiqI8vFhKVBMCzqnv4/+Y6amQOcwgboGCSsGAQQBgjcQBDGB rDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQ gb0wgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA8BSF4QUynr/oAOUnSVCBvTANBgkqhkiG9w0BAQEFAASCAQB6SJvuEVxJLfeiM/vkEuLN rbwqsg1n1rUX+jht7OKY9sVNys8vJ6u8UYWHSp/PTWUufbdmLzeFwa0HrAV4OGUq7i3CXIxXDt41 wW1rMvP82VNGmjBOHQJeZhN9jfR0CLRWg2SwmoHjqpB7lXxI6VN9zN8U+pQ2uG5icnr6yMntDYwk xUbV0F/neqsEeafSUfgWREhbGdm0m2Xqh1PShSSvTZ1xP3GQgHOjaboVZ1hCAEGkhk38fVg+QYxd mIociO7bsc/PNooFUwkSJnPMCUuT76s6e2LpcTS42H/yoEZOoZ1dMRGW4mLCCT5pslS3hpR/qz7T v2kIkj0t5c/5Eh0VAAAAAAAA --Apple-Mail=_E997CD8F-4153-44D0-A1F0-0E6A152C7CE7-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 17 22:54:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00128AFA for ; Sun, 17 Mar 2013 22:54:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D42F7B8 for ; Sun, 17 Mar 2013 22:54:37 +0000 (UTC) Received: (qmail 88609 invoked from network); 18 Mar 2013 00:06:10 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Mar 2013 00:06:10 -0000 Message-ID: <514649A5.4090200@freebsd.org> Date: Sun, 17 Mar 2013 23:54:29 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: MPLS References: <5146121B.5080608@FreeBSD.org> In-Reply-To: <5146121B.5080608@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , Sami Halabi X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Mar 2013 22:54:38 -0000 On 17.03.2013 19:57, Alexander V. Chernikov wrote: > On 17.03.2013 13:20, Sami Halabi wrote: >>> ITOH OpenBSD has a complete implementation of MPLS out of the box, maybe > Their control plane code is mostly useless due to design approach (routing daemons talk via kernel). What's your approach? > Their data plane code, well.. Yes, we can use some defines from their headers, but that's all :) >>> porting it would be short and more straight forward than porting linux LDP >>> implementation of BIRD. > > It is not 'linux' implementation. LDP itself is cross-platform. > The most tricky place here is control plane. > However, making _fast_ MPLS switching is tricky too, since it requires chages in our netisr/ethernet > handling code. Can you explain what changes you think are necessary and why? -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 00:54:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6E90CB3 for ; Mon, 18 Mar 2013 00:54:53 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id B5163BDF for ; Mon, 18 Mar 2013 00:54:52 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joe@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3ZTf782TpTz18L; Mon, 18 Mar 2013 00:54:44 +0000 (UTC) Message-ID: <514665CD.80809@rewt.org.uk> Date: Mon, 18 Mar 2013 00:54:37 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Yoann Gini Subject: Re: mpd5 and multiple route to send to clients References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> In-Reply-To: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 00:54:54 -0000 Yoann Gini wrote: > Hello, > > I’m Yoann. It’s my first message here so a little brief about me. I’m a OS X Server System Administrator and Trainer, actually working on a FreeBSD based setup for a simple service provider infrastructure. > > I currently setup a L2TP over IPSec VPN server with FreeBSD 9.1 and mpd 5.6. > > I’ve done with success my setup with radius authentication and all interesting stuff except for one thing that I can’t find on Internet. > > I need to push some routes to my clients to configure them to use the VPN interface to reach some private network available behind my server. > > I can’t find any clue about how to do that… > > They have a « set iface route » option but this add the route on the server side, I want the same to push route on the client side… > > If someone can give my a clue… > > Best regards, > Yoann Gini. If you're using radius, see 'framed-route'... if not, see external auth From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 04:37:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2DC16A64 for ; Mon, 18 Mar 2013 04:37:48 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id CFF99375 for ; Mon, 18 Mar 2013 04:37:47 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2I4bf4u088084 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Mar 2013 10:37:43 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <51469A13.7090503@norma.perm.ru> Date: Mon, 18 Mar 2013 10:37:39 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net Subject: Re: carp regression in 9.1 ? References: <3B04FCB1-D0D4-4BC9-BB15-5221F438738C@my.gd> <514594D7.1020202@norma.perm.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 18 Mar 2013 10:37:44 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 04:37:48 -0000 Hi. On 17.03.2013 21:20, Ermal Luçi wrote: > > From this aspects carp in 10(HEAD) should behave the same since the > internals of carp have not been changed only the iconnection with the > FreeBSD stack has. > Talking about aliases on carp that used to be a bit broken up-to 9.x > they do not exist at all in 10. > Which needs a bit of discussion per se how to solve. > > Yup, but the same behaviour can be achieved in 10.x with two ways: - one address == one vhid (when a machine needs to neighbour with carp on 8.x this requires configuration changes on 8.x). - multiple addresses == one vhid, in the same order the addresses appear on the neighbor, regardless of the version. I tried both ways and they both work. Eugene. From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 04:45:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63D01BAC for ; Mon, 18 Mar 2013 04:45:31 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 55A3B3E7 for ; Mon, 18 Mar 2013 04:45:30 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2I4jQj2088766 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Mar 2013 10:45:27 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <51469BE4.6070502@norma.perm.ru> Date: Mon, 18 Mar 2013 10:45:24 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.1-RELEASE + bge0 == watchdog timeout References: <5136D89D.4000902@norma.perm.ru> <20130306062658.GC1483@michelle.cdnetworks.com> <513713C2.1000007@norma.perm.ru> <20130307022446.GB3108@michelle.cdnetworks.com> <513820E2.806@norma.perm.ru> <20130307062335.GB1478@michelle.cdnetworks.com> <51383E3B.5030007@norma.perm.ru> <20130307081548.GD1478@michelle.cdnetworks.com> <20130313015753.GD3062@michelle.cdnetworks.com> <514171D1.50807@norma.perm.ru> <20130314072946.GA1519@michelle.cdnetworks.com> In-Reply-To: <20130314072946.GA1519@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 18 Mar 2013 10:45:28 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 04:45:31 -0000 Hi. On 14.03.2013 13:29, YongHyeon PYUN wrote: > I thought you were using stable/8 but it seems you have slightly > older stable/8. The bge(4) code difference between CURRENT and > stable9/stable8 is very minor. Nah, I really am running recent 8/stable. My mistake was to try to apply the whole code of the if_bge.c to 8/stable. > I've attached diff against stable/8 which will address ASF/IPMI > issue but I'm not sure whether it helps watchdog timeout or not. > I have plan to MFC the change but I need time for settlement before > the MFC. Thanks a lot. Now the 'watchdog timeout' behaviour stopped, the driver reports nothing on the console, but the freezes, unfortunately - didn't stop. The machine is freezing at random periods of time, usually 1-2 days, it partially stops answering to network (network services running on this machine close the connection, and other weird stuff happens), it partially responds on the console (I can type but I cannot login) and so on. The asf feature has no influence on this - I tried to enable it, this happens anyway. Should I try upgrade to 9 or 10, do they have more improvements in bge(4) ? Eugene. From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 10:47:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33EF613A6 for ; Mon, 18 Mar 2013 10:47:34 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by mx1.freebsd.org (Postfix) with ESMTP id B64AC5EB for ; Mon, 18 Mar 2013 10:47:33 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi8so2387776wib.13 for ; Mon, 18 Mar 2013 03:47:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4YBn8qIV66zGrTanfyuitUCnKdwhuYyRHFsH4Vqktnw=; b=WJSrVYtk7Y1TjDCqmpeXdf+yvh7Vp4cD0RO47V3kKS7GtdHJqT2xY/xwfRppOZwMDQ pYzl6UveXV2OdaIS2/tD7Fqr/PDsQC218SuxerIWzZ1eLiCWr+5V9Qwaou2mBJqDyeVv e7mAEDslVo04/QDGmcWBBhLnhgSnk+9YXapAkSudK5AezNovHk6TDghwkacQfIloQg92 dr00QiQA1WEuemlMSy+l10EstUljYEztThufteZ8aqkjzqdOFXhZEiV85xQThPi+U8WQ WhuwYFbtIA9d8pjYHkqGcPOUlR+K7LAXRsxptJOQ9SD1XWgcfgm4zJjv+3bxq7HneNSP vihw== X-Received: by 10.194.178.9 with SMTP id cu9mr23716054wjc.39.1363601850829; Mon, 18 Mar 2013 03:17:30 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id fx5sm14017850wib.11.2013.03.18.03.17.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 03:17:29 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: carp regression in 9.1 ? From: Fleuriot Damien In-Reply-To: <39FC9737-4F34-4978-BDFE-17410CD2E5C4@my.gd> Date: Mon, 18 Mar 2013 11:17:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B04FCB1-D0D4-4BC9-BB15-5221F438738C@my.gd> <514594D7.1020202@norma.perm.ru> <39FC9737-4F34-4978-BDFE-17410CD2E5C4@my.gd> To: "Eugene M. Zheganin" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkLSZG2ut7neU4lpmPZiwpDzA7tQUL2aXqQC9zTRwcPGU2GykztR0sZQI7AHEe03z490oBX Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 10:47:34 -0000 On Mar 18, 2013, at 9:23 AM, Damien Fleuriot wrote: >=20 > On 17 Mar 2013, at 11:03, "Eugene M. Zheganin" = wrote: >=20 >> Hi. >>=20 >> On 14.03.2013 20:47, Fleuriot Damien wrote: >>> I'm experiencing this odd behavior with 9.1 r24791 for amd64. >> You should definitely sit on 8.x until 10.x will become stable, or = upgrade to 10.x from 9.x (at least this is what I do). >> Carp is entirely rewritten in 10.x branch. In the same time, in 9.x = carp seems to be desperately broken: for example I was experiencing = weird panics on boot, weird behaviour, and, when enabling WITNESS, lots = of carp-related LORs. Furthermore, I was completely unable to boot up = with a ipv6-enabled carp - I had to initialize it in multiuser with a = custom script. All of this doesn't happen on 10.x, which I had to = upgrade to. Right now, if we're talking about carp, my 10.x production = works like a charm. 9.x branch just isn't destined to production. The = situation is a bit improved on 9.1, but still I can compare this release = to 4.6 or 5.0. >>=20 >> Eugene. >>=20 >=20 >=20 > I'm afraid I can't afford 10.x, this is for production, although I = acknowledge the problems you're faced with. >=20 > Regarding 8.x, this is a guest VM running on proxmox 2.3 which doesn't = support stock 8.x (need the virtio kernel option, I'll get a thread = reference when I hit work). >=20 >=20 > So yeah I'm kinda fucked here... ;) The link to the thread on the proxmox forum where many people report 8.x = not working with proxmox 2.3: http://forum.proxmox.com/threads/13013-Error-pfsense-freebsd Apparently it's now a known bug and is related to a KVM bios update. A dirty and temporary fix is to use an old bios (say from 2.0 or 2.2) in = the vm config: =3D=3D=3D args: -bios /usr/share/kvm/bios_old.bin =3D=3D=3D It seems a fix has been submitted by the devs and it reportedly works: = http://forum.proxmox.com/threads/13013-Error-pfsense-freebsd?p=3D71136#pos= t71136 I confirm the updated BIOS (which has already been committed to the = debian packages) fixes the problems and allows 8.x to boot. So, I guess I'm going to happily revert that 9.1 to 8.3 eh=85 Still doesn't explain the CARP regressions though :( From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 10:59:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 143B61B5 for ; Mon, 18 Mar 2013 10:59:21 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id A8CCD8E5 for ; Mon, 18 Mar 2013 10:59:20 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id o45so4675774wer.37 for ; Mon, 18 Mar 2013 03:59:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=cMHfLzpKGDhHEamcf7tUgBFiQWhybZ+bo4nLH5aiKZk=; b=CLwRmq9uZLIijpOkaMcixR16nf85kBBukVGHVzghw9uireCASWKAI87AhIF/Lo4b+g H5n+cxNBa2horwcypqtRDbE9A2mvacUvkkB2xPW0r9qi6qetSsYIf+3fo34z6ROOl387 uC0fm5vRvD6SxT/mKHcTTx2XS/zbgsxXCLgSQPrQs53cuDcFjEVZsBWURK3pVaDB9zt1 vjzEJiXf9eND4xT3aTolttbGPk3SGtRdzicE8A8w/8KGOcTo9Kobkty0KE/6LeYCL7C7 83VnH9Lvjf6Lw+db76jij4YjbFCq2zGdXBTE+jelrrZjel8S8WPQY62HiCqjuqoHuVGY ehaA== X-Received: by 10.194.9.166 with SMTP id a6mr23181858wjb.2.1363595017784; Mon, 18 Mar 2013 01:23:37 -0700 (PDT) Received: from [10.136.187.126] ([92.90.16.18]) by mx.google.com with ESMTPS id f1sm12002542wib.0.2013.03.18.01.23.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 01:23:36 -0700 (PDT) References: <3B04FCB1-D0D4-4BC9-BB15-5221F438738C@my.gd> <514594D7.1020202@norma.perm.ru> Mime-Version: 1.0 (1.0) In-Reply-To: <514594D7.1020202@norma.perm.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <39FC9737-4F34-4978-BDFE-17410CD2E5C4@my.gd> X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: carp regression in 9.1 ? Date: Mon, 18 Mar 2013 09:23:13 +0100 To: "Eugene M. Zheganin" X-Gm-Message-State: ALoCoQlA8srPET82GkGbs2J5mlLVCRWfGcK+p6S3hWueTsmDUVmHKyTKNmrJ481Qh73CAl4jS+D9 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 10:59:21 -0000 On 17 Mar 2013, at 11:03, "Eugene M. Zheganin" wrote: > Hi. >=20 > On 14.03.2013 20:47, Fleuriot Damien wrote: >> I'm experiencing this odd behavior with 9.1 r24791 for amd64. > You should definitely sit on 8.x until 10.x will become stable, or upgrade= to 10.x from 9.x (at least this is what I do). > Carp is entirely rewritten in 10.x branch. In the same time, in 9.x carp s= eems to be desperately broken: for example I was experiencing weird panics o= n boot, weird behaviour, and, when enabling WITNESS, lots of carp-related LO= Rs. Furthermore, I was completely unable to boot up with a ipv6-enabled carp= - I had to initialize it in multiuser with a custom script. All of this doe= sn't happen on 10.x, which I had to upgrade to. Right now, if we're talking a= bout carp, my 10.x production works like a charm. 9.x branch just isn't dest= ined to production. The situation is a bit improved on 9.1, but still I can c= ompare this release to 4.6 or 5.0. >=20 > Eugene. >=20 I'm afraid I can't afford 10.x, this is for production, although I acknowle= dge the problems you're faced with. Regarding 8.x, this is a guest VM running on proxmox 2.3 which doesn't suppo= rt stock 8.x (need the virtio kernel option, I'll get a thread reference whe= n I hit work). So yeah I'm kinda fucked here... ;)= From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 11:06:47 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2EAEB9F for ; Mon, 18 Mar 2013 11:06:46 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0F71CAB4 for ; Mon, 18 Mar 2013 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2IB6kUu002211 for ; Mon, 18 Mar 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2IB6jwY002209 for freebsd-net@FreeBSD.org; Mon, 18 Mar 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Mar 2013 11:06:45 GMT Message-Id: <201303181106.r2IB6jwY002209@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 11:06:47 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176667 net [libalias] [patch] libalias locks on uninitalized data o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 453 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 11:10:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 466C087B for ; Mon, 18 Mar 2013 11:10:31 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id F00B0D1B for ; Mon, 18 Mar 2013 11:10:30 +0000 (UTC) Received: from [192.168.248.34] ([192.168.248.34]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2IBAPuI029057 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Mar 2013 17:10:26 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <5146F61E.3040601@norma.perm.ru> Date: Mon, 18 Mar 2013 17:10:22 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: carp regression in 9.1 ? References: <3B04FCB1-D0D4-4BC9-BB15-5221F438738C@my.gd> <514594D7.1020202@norma.perm.ru> <39FC9737-4F34-4978-BDFE-17410CD2E5C4@my.gd> In-Reply-To: <39FC9737-4F34-4978-BDFE-17410CD2E5C4@my.gd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Mon, 18 Mar 2013 17:10:27 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 11:10:31 -0000 Hi. On 18.03.2013 14:23, Damien Fleuriot wrote: > I'm afraid I can't afford 10.x, this is for production, although I acknowledge the problems you're faced with. > > Regarding 8.x, this is a guest VM running on proxmox 2.3 which doesn't support stock 8.x (need the virtio kernel option, I'll get a thread reference when I hit work). > > So yeah I'm kinda fucked here... ;) > This is of course up to you to decide, but I feel like I should encourage you - 10.x isn't that scarry as it seems to be. I also run it on a production (though my production may be not as harsh as yours), - this is a main router for a LAN consisting of 500+ machines, it also runs a squid proxy with 200+ active users (AD integrated, winbind, kerberos and stuff) and a HFSC traffic shaper. Plus, a bunch of routing protocols - ospf, ospfv3 and a load of network services like SMTP/HTTP/DHCP. Plus, it's a zfs installation. At least, after upgrade from 9.1-STABLE to a random -CURRENT I didn't notice any degradation, only improvements. I had all of your fears right before the upgrade, none of it became real. Eugene. From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 11:55:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2B9AF1E9 for ; Mon, 18 Mar 2013 11:55:32 +0000 (UTC) (envelope-from yoann.gini@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id B81EA3F6 for ; Mon, 18 Mar 2013 11:55:31 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x51so4631171wey.4 for ; Mon, 18 Mar 2013 04:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=cvoT2/DlSMS2hw4wws/loj+tRw8Il+eY0NR10dkZAtE=; b=SfrJahXfJJe6aK9yWz+7Vyz+/nAF9e/FIOBdOpb4hkELxq6f41YK/cCt8MmXHI+X3r zZPrLv512J27l8TrCDMcs6bZpiqj98DZZdB0i9WkLKeKWOJxKWcNGqsRXM8oD1L4x7MA OU3bhm0R9dqJ/VWDDuofmGm0WIQ8SaSdbOAuCIKGeDovmxVwy6BLW6fFW6RiIQO3dQVR eFtaOl9j/TWGVpokLhAZ+O43yPD49J6ZnXskfzi+tRtgjm5L8UlHoFvucC6yEVXC4S5j aLOWqNnEQi7RSiCvAXbYp3NIH0lLcSK0WpCNMkmRjX8bD2mBzXcB46ct0tRcTKJyLLvI ui1Q== X-Received: by 10.180.94.133 with SMTP id dc5mr8065055wib.1.1363587938054; Sun, 17 Mar 2013 23:25:38 -0700 (PDT) Received: from [192.168.1.38] (81.131.1.93.rev.sfr.net. [93.1.131.81]) by mx.google.com with ESMTPS id er3sm11555300wib.1.2013.03.17.23.25.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 23:25:36 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F09F946A-4DAD-45CB-A477-4A1C1F39401D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: mpd5 and multiple route to send to clients From: Yoann Gini In-Reply-To: <514665CD.80809@rewt.org.uk> Date: Mon, 18 Mar 2013 07:25:36 +0100 Message-Id: References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <514665CD.80809@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 11:55:32 -0000 --Apple-Mail=_F09F946A-4DAD-45CB-A477-4A1C1F39401D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Thank you for your answer. Le 18 mars 2013 =E0 01:54, Joe Holden a =E9crit : > If you're using radius, see 'framed-route'... if not, see external = auth Well, that=92s a unexpected answer, I will never think to set that = information in the Radius server instead of the VPN server=85 That=92s the only way to do that with mpd5 ? For example, on OS X Server = we use vpnd who is able to manage route by itself=85 Nevertheless, I try your recommendations and on the users file of my = FreeRadius config I=92ve that config: DEFAULT Auth-Type :=3D ldap Framed-Protocol =3D PPP, Framed-Route =3D "10.42.0.0/23 10.42.1.1 1", Fall-Through =3D 1 Based on what I=92ve seen on different examples. It don=92t work. I = can=92t see this route on my client. What=92s wrong with my setup? Y.= --Apple-Mail=_F09F946A-4DAD-45CB-A477-4A1C1F39401D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUqMIIEEqADAgECAhEA8BSF4QUynr/oAOUnSVCBvTANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzAzMDMw MDAwMDBaFw0xNDAzMDMyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFHlvYW5uLmdpbmlAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11zV57Sqb+CpMeUSmttu8MsHvdUR vZS9O5jKxWljaeZgQbr4A/yShO5PB7MgM4KMQjMIOoacShFvyf6ZivL8r8fFbAmc6NsHr4CN4S9T E0WAi/MWUTPLYrD8zx0NsjimxLP/3Ln1b3TDb0Vp/bqOWePStBU2truYBodyGZCQiHVPBZC6d5tu CswgnIbloUTf4RxyGGt8NCl94lBiw6ZNNc+94BRlIY8a6uyV5/9jqiAu/LZVpLV5n9YZ5BCfoRsM GAi94eUzFv/AdCLp+l0OGjQ+K8APeHihjU8/VtNujjW1tA7r5bs3O8wTQ6lCoCV8J+XZMWUK4grO xisqX5umywIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYD VR0OBBYEFH28/IbXcUSiVbEyWOgyob3zTeHTMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEE fDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHwYDVR0RBBgwFoEUeW9hbm4uZ2luaUBnbWFpbC5jb20wDQYJKoZIhvcNAQEF BQADggEBAC2aIbicOEFNkJwJlCEoBFsi/7im9S6E0GwQ2/+bn0GhOTZQ+mkB9Up2A99TsAV2dWJ/ TClZ5a/tx4K6eP+r7q1ci1QcDdomD8NLI+zpU0zx+I/RnEca24AYJ3fC5dS6nR5sjTj2zoYa0pXs CVrMb24vXBr14iLwG7U+REEX6+p0tbwAjrJLPnViS1TvUPBz5J9W2ag10cCaecSsa6VOGR3xR5ah r9pWGtKZ+xKxnuPsmny5xKCeB+73ZI6DTanIXzHiduGm3A/y7maIjJq4gy7Vm2hH3HaBTV4ZS/DZ 2/sKr5k9/asWaJosS5ciE00tMLCrvogWdF4xhSxUrm/C7j4xggOuMIIDqgIBATCBqTCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQgb0wCQYFKw4DAhoF AKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE4MDYy NTM2WjAjBgkqhkiG9w0BCQQxFgQU6zuHpR8tmaR5t0hrKFmVmUk2Ln8wgboGCSsGAQQBgjcQBDGB rDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQ gb0wgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA8BSF4QUynr/oAOUnSVCBvTANBgkqhkiG9w0BAQEFAASCAQCKCQbUR2PY2jvTU/K5MeMz KQ2tQaAsvCOdAjQvOdib2tEF3uC8Nnr9idL3gNKud1HhwniRetdYjkX1flTo5uZ4IU/yU+ar2IBy tn3UoaZQIUqfUlktAHjXnluEyB6Z0gMa1tBTPONx6Bj58o3UVXgdiqOfCLFPbA1K+ZVzodNm0ASO tsjlg+JKSfXDrkzapKs2exCPuRBXJ1s5gesyf8bl1mBnv/QHR/2lmmHfKOmz6slxBGO8C+TSejUk E6O7b790ONdexz9t6XoNSEgo9U4sefbtPAgpiz92ciEThYHwGkXTLjXQjLZKUq1eeRkIr9WvQGIF HWSEQ8BeIIGPi5qnAAAAAAAA --Apple-Mail=_F09F946A-4DAD-45CB-A477-4A1C1F39401D-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 12:19:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4540D9D4; Mon, 18 Mar 2013 12:19:25 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB7E77D; Mon, 18 Mar 2013 12:19:25 +0000 (UTC) Received: from [2001:920:7000:101:5925:271b:9fa8:e84e] by mail.ipfw.ru with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UHZ5Y-000NU4-KA; Mon, 18 Mar 2013 16:22:52 +0400 References: <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org> In-Reply-To: <514649A5.4090200@freebsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> X-Mailer: iPhone Mail (10B146) From: "Alexander V. Chernikov" Subject: Re: MPLS Date: Mon, 18 Mar 2013 13:20:30 +0100 To: Andre Oppermann Cc: Sami Halabi , "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 12:19:25 -0000 On 17.03.2013, at 23:54, Andre Oppermann wrote: > On 17.03.2013 19:57, Alexander V. Chernikov wrote: >> On 17.03.2013 13:20, Sami Halabi wrote: >>>> ITOH OpenBSD has a complete implementation of MPLS out of the box, mayb= e >> Their control plane code is mostly useless due to design approach (routin= g daemons talk via kernel). >=20 > What's your approach? It is actually not mine. We have discussed this a bit in radix-related threa= d. Generally quagga/bird (and other hiperf hardware-accelerated and software= routers) have feature-rich RIb from which best routes (possibly multipath) a= re installed to kernel/fib. Kernel main task should be to do efficient looku= ps while every other advanced feature should be implemented in userland. >=20 >> Their data plane code, well.. Yes, we can use some defines from their hea= ders, but that's all :) >>>> porting it would be short and more straight forward than porting linux L= DP >>>> implementation of BIRD. >>=20 >> It is not 'linux' implementation. LDP itself is cross-platform. >> The most tricky place here is control plane. >> However, making _fast_ MPLS switching is tricky too, since it requires ch= ages in our netisr/ethernet >> handling code. >=20 > Can you explain what changes you think are necessary and why? We definitely need ability to dispatch chain of mbufs - this was already dis= cussed in intel rx ring lock thread in -net. Currently significant number of drivers support interrupt moderation permitt= ing several/tens/hundreds of packets to be received on interrupt. For each packet we have to run some basic checks, PFIL hooks, netisr code, l= 3 code resulting in many locks being acquired/released per each packet. Typically we rely on NIC to put packet in given queue (direct isr), which wo= rks bad for non-hashable types of traffic like gre, PPPoE, MPLS. Additionall= y, hashing function is either standard (from M$ NDIS) or documented permitti= ng someone malicious to generate 'special' traffic matching single queue. Currently even if we can add m2flowid/m2cpu function able to hash, say, gre o= r MPLS, it is unefficient since we have to lock/unlock netisr queues for eve= ry packet.=20 I'm thinking of * utilizing m_nextpkt field in mbuf header * adding some nh_chain flag to netisr If given netisr does not support flag and nextpkt is not null we simply call= such netisr in cycle. * netisr hash function accepts mbuf 'chain' and pointer to array (Sizeof N *= ptr), sorts mbuf to N netisr queues saving list heads to supplied array. A= fter that we put given lists to appropriate queues. * teach ethersubr RX code to deal with mbuf chains (not easy one) * add some partial support of handling chains to fastfwd code >=20 > --=20 > Andre >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 13:41:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BAEFAEBA for ; Mon, 18 Mar 2013 13:41:17 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 236EDAEC for ; Mon, 18 Mar 2013 13:41:16 +0000 (UTC) Received: (qmail 2529 invoked from network); 18 Mar 2013 14:52:44 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Mar 2013 14:52:44 -0000 Message-ID: <51471974.3090300@freebsd.org> Date: Mon, 18 Mar 2013 14:41:08 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: MPLS References: <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org> <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> In-Reply-To: <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Alexander V. Chernikov" , Sami Halabi , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 13:41:17 -0000 On 18.03.2013 13:20, Alexander V. Chernikov wrote: > On 17.03.2013, at 23:54, Andre Oppermann wrote: > >> On 17.03.2013 19:57, Alexander V. Chernikov wrote: >>> On 17.03.2013 13:20, Sami Halabi wrote: >>>>> ITOH OpenBSD has a complete implementation of MPLS out of the box, maybe >>> Their control plane code is mostly useless due to design approach (routing daemons talk via kernel). >> >> What's your approach? > It is actually not mine. We have discussed this a bit in radix-related thread. Generally quagga/bird (and other hiperf hardware-accelerated and software routers) have feature-rich RIb from which best routes (possibly multipath) are installed to kernel/fib. Kernel main task should be to do efficient lookups while every other advanced feature should be implemented in userland. Yes, we have started discussing it but haven't reached a conclusion among the two philosophies. We have also agreed that the current radix code is horrible in terms of cache misses per lookup. That however doesn't preclude an agnostic FIB+RIB approach. It's mostly a matter of structure layout to keep it efficient. >>> Their data plane code, well.. Yes, we can use some defines from their headers, but that's all :) >>>>> porting it would be short and more straight forward than porting linux LDP >>>>> implementation of BIRD. >>> >>> It is not 'linux' implementation. LDP itself is cross-platform. >>> The most tricky place here is control plane. >>> However, making _fast_ MPLS switching is tricky too, since it requires chages in our netisr/ethernet >>> handling code. >> >> Can you explain what changes you think are necessary and why? > > We definitely need ability to dispatch chain of mbufs - this was already discussed in intel rx ring lock thread in -net. Actually I'm not so convinced of that. Packet handling is a tradeoff between doing process-to-completion on each packet and doing context switches on batches of packets. Every few years the balance tilts forth and back between process-to-completion and batch processing. DragonFly went with a batch-lite token-passing approach throughout their kernel. It seems it didn't work out to the extent they expected. Now many parts are moving back to the more traditional locking approach. > Currently significant number of drivers support interrupt moderation permitting several/tens/hundreds of packets to be received on interrupt. But they've also started to provide multiple queues. > For each packet we have to run some basic checks, PFIL hooks, netisr code, l3 code resulting in many locks being acquired/released per each packet. Right, on the other hand you'll likely run into serious interlock and latency issues when large batches of packets monopolize certain locks preventing other interfaces from sending their batches up. > Typically we rely on NIC to put packet in given queue (direct isr), which works bad for non-hashable types of traffic like gre, PPPoE, MPLS. Additionally, hashing function is either standard (from M$ NDIS) or documented permitting someone malicious to generate 'special' traffic matching single queue. Malicious traffic is always a problem, no matter how many queues you have. > Currently even if we can add m2flowid/m2cpu function able to hash, say, gre or MPLS, it is unefficient since we have to lock/unlock netisr queues for every packet. Yes, however I'm arguing that our locking strategy may be broken or sub-optimal. > I'm thinking of > * utilizing m_nextpkt field in mbuf header OK. That's what it is there for. > * adding some nh_chain flag to netisr > If given netisr does not support flag and nextpkt is not null we simply call such netisr in cycle. > * netisr hash function accepts mbuf 'chain' and pointer to array (Sizeof N * ptr), sorts mbuf to N netisr queues saving list heads to supplied array. After that we put given lists to appropriate queues. > * teach ethersubr RX code to deal with mbuf chains (not easy one) > * add some partial support of handling chains to fastfwd code I really don't think this going to help much. You're just adding a lot of latency and context switches to while packet path. Also you're making it much more complicated. The interface drivers and how they manage the boundary between RX ring and the stack is not optimal yet. I think there's a lot of potential there. In my tcp_workqueue branch I started to experiment with a couple of approaches. It's not complete yet though. The big advantage of having the interface RX thread pushing the packets is that it provides a natural feedback loop regarding system load. Once you have more packets coming in than you can process, the RX dma ring gets naturally starved and the load is stabilized on the input side preventing a live-lock that can easily happen in batch mode. Only a well-adjusted driver works properly though and we don't have any yet in that regard. Before we start to invent complicated mbuf batching methods lets make sure that the single packet path at its maximal possible efficiency. And only then evaluate more complicated approaches on whether they deliver additional gains. From that follows that we should: 1. fix longest prefix match radix to minimize cache misses. 2. fix drivers to optimize RX dequeuing and TX enqueuing. 3. have a critical look at other parts of the packet path to avoid or optimize costly operations (in_local() for example). -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 16:56:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 04440438 for ; Mon, 18 Mar 2013 16:56:21 +0000 (UTC) (envelope-from gust@hotmail.com) Received: from cpsmtp-fia05.kpnxchange.com (cpsmtp-fia05.kpnxchange.com [195.121.247.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9650196A for ; Mon, 18 Mar 2013 16:56:20 +0000 (UTC) Received: from smtp.direct-adsl.nl ([37.74.53.146]) by cpsmtp-fia05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 17:56:12 +0100 From: "Citibank Services" To: freebsd-net@freebsd.org Subject: Account is at risk Message-ID: X-OriginalArrivalTime: 18 Mar 2013 16:56:12.0488 (UTC) FILETIME=[7F005480:01CE23F9] Date: 18 Mar 2013 17:56:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-two" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 16:56:21 -0000 ATTENTION __________________________________________________________________ Your credit card account information is obtained illegally from a merchant's records, credit card numbers are exposed, putting those accounts at risk for fraudulent activity. [1]Validate bank details. Do not use public networks/computers to login to Citibank. Do not ever disclose your banking information to any one and do not let any body do internet banking on your behalf __________________________________________________________________ Copyright © 2013 Citigroup Inc References 1. http://zdBT2cLQNCHk1xe8DzC6msV0BZd8LHwaUiFXjIrWSDmF9dZHmL.fonsecaartes.com/plugins/system/logs/positive.php?email_from=freebsd-net@freebsd.org&sub=online.citibank.com.7MZnIinCUfxaJx1ofavNFfrLXxgWMB From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 17:23:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89AD8CAC for ; Mon, 18 Mar 2013 17:23:19 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 38A3DAEC for ; Mon, 18 Mar 2013 17:23:18 +0000 (UTC) Received: from [172.16.8.72] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3ZV43n055Gz1G1; Mon, 18 Mar 2013 17:23:16 +0000 (UTC) Message-ID: <51474D7D.2030107@rewt.org.uk> Date: Mon, 18 Mar 2013 17:23:09 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Yoann Gini Subject: Re: mpd5 and multiple route to send to clients References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <514665CD.80809@rewt.org.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 17:23:19 -0000 Yoann Gini wrote: > Hi, > > Thank you for your answer. > > Le 18 mars 2013 à 01:54, Joe Holden a écrit : > >> If you're using radius, see 'framed-route'... if not, see external auth > > Well, that’s a unexpected answer, I will never think to set that information in the Radius server instead of the VPN server… > > That’s the only way to do that with mpd5 ? For example, on OS X Server we use vpnd who is able to manage route by itself… > > Nevertheless, I try your recommendations and on the users file of my FreeRadius config I’ve that config: > > DEFAULT Auth-Type := ldap > Framed-Protocol = PPP, > Framed-Route = "10.42.0.0/23 10.42.1.1 1", > Fall-Through = 1 > > Based on what I’ve seen on different examples. It don’t work. I can’t see this route on my client. What’s wrong with my setup? > The radius entry tells the NAS (mpd in this case) to add a route towards the client, the route/ip will still need to be configured on the client side, do you see a correct entry on the NAS? (route -n get 10.42.0.0/23) > Y. From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 18:31:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B8ECC6FF for ; Mon, 18 Mar 2013 18:31:50 +0000 (UTC) (envelope-from krjeschke@omniti.com) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 82285F9B for ; Mon, 18 Mar 2013 18:31:50 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id hg5so1854936qab.13 for ; Mon, 18 Mar 2013 11:31:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=PQOyg22O74dFVzZyXb1pbxRtD7B0WqwrvOqwSs+oZ+Q=; b=kQmN6nqjK6uOTEezrIByZKeS2PorFC7t2yFjTB4CB9ipymIWJ8NhZhRHsaqyDM5u0q Cf5f8yiNzNUsCk0E13FiOmBF1fHdL+im5EbtM3rg3JPuOgEmY6jVO0yxjDX7QXdQFsYw K+UJuzZnPxGYGm99sc8V3cVZ5nJWykYp8iLRa3c6kck5/dBhfFsvjERztQGPihJicgnm Tt4Rw0ZvvfaESpLSB8xB+wo5dsgoOEUX6vuPTuxGw8vIglVljxInVZr2cYzpIXRsydR5 FLVmkPzuuBFaD8mZFb3dJcDYUbf4k/VqgPRAlJK9NoquRyaJwI4Zha/DX1P8KFQocxr9 5BvQ== MIME-Version: 1.0 X-Received: by 10.229.193.134 with SMTP id du6mr5049337qcb.46.1363631503784; Mon, 18 Mar 2013 11:31:43 -0700 (PDT) Received: by 10.229.17.134 with HTTP; Mon, 18 Mar 2013 11:31:43 -0700 (PDT) Date: Mon, 18 Mar 2013 14:31:43 -0400 Message-ID: Subject: Surge 2013 CFP Open From: Katherine Jeschke To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQkDqU7wEhuqf3okP2p3M1Jx+soRAYllvk4rBhmal3sJ8/aJfV04RJuMwsk+1bLPvu2XJtiH Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 18:31:50 -0000 The Surge 2013 CFP is open. For details or to submit a paper, please visit http://surge.omniti.com/2013 -- Katherine Jeschke Director of Marketing and Creative Services OmniTI Computer Consulting, Inc. 11830 West Market Place, Suite F Fulton, MD 20759 O: 240-646-0770, 222 F: 301-497-2001 C: 443/643-6140 omniti.com Surge 2013 The information contained in this electronic message and any attached documents is privileged, confidential, and protected from disclosure. If you are not the intended recipient, note that any review, disclosure, copying, distribution, or use of the contents of this electronic message or any attached documents is prohibited. If you have received this communication in error, please destroy it and notify us immediately by telephone (1-443-325-1360) or by electronic mail (info@omniti.com). Thank you. From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 20:29:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7ED74915 for ; Mon, 18 Mar 2013 20:29:01 +0000 (UTC) (envelope-from yoann.gini@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id F0A9A8AE for ; Mon, 18 Mar 2013 20:29:00 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t44so5256601wey.40 for ; Mon, 18 Mar 2013 13:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=M5evD60xrq00qKLLtPkw2NWGVuvQbV2jK9HnxKXKFQU=; b=Tf5CbO8n2K0T/OPiFgf2MY2FgbE0q/a8URddqP+fKtwgTJHNG5xg1O1wM+yX65Ww6V v50Mq23aGDP4kjqEDjsfSJxZHgg4cMK9TTOKAAP74OP5A61dt7soeyqjT/ioGKtcjjeQ 66GHHYQoBEEk9V5IygYgZm6yDZrT9IwMUDQ0ywieO5ixxshy36qzLqEpE/cXsEw4xuDL HoFCkIvPAUNQRs6Yb0OBHc/eOFLwW+5sVA1tnmLXXsMZQJShoHTA1AUQTQODeKSCDtbr +l900YoQhDAtc61eMNTry2sPFhiL0JAGbNVVhnBbGTfXPf9vAmAPn7ta63O/wU8Zm6YK WcoA== X-Received: by 10.194.109.35 with SMTP id hp3mr27912549wjb.15.1363638539908; Mon, 18 Mar 2013 13:28:59 -0700 (PDT) Received: from [192.168.1.38] (81.131.1.93.rev.sfr.net. [93.1.131.81]) by mx.google.com with ESMTPS id dp5sm2917146wib.1.2013.03.18.13.28.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 13:28:58 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9D0823E5-1BDF-4D1D-8564-3881D62F2D93"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: mpd5 and multiple route to send to clients From: Yoann Gini In-Reply-To: <51474D7D.2030107@rewt.org.uk> Date: Mon, 18 Mar 2013 21:28:58 +0100 Message-Id: <065823BC-24A6-48EE-B689-310D01019998@gmail.com> References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <514665CD.80809@rewt.org.uk> <51474D7D.2030107@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 20:29:01 -0000 --Apple-Mail=_9D0823E5-1BDF-4D1D-8564-3881D62F2D93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Le 18 mars 2013 =E0 18:23, Joe Holden a =E9crit : > The radius entry tells the NAS (mpd in this case) to add a route = towards the client, the route/ip will still need to be configured on the = client side, do you see a correct entry on the NAS? (route -n get = 10.42.0.0/23) OK, that=92s still not what I'm looking for=85 If I understand well what = you said, =AB Framed-Route =BB do the same as =AB set iface route =BB, = it add the specified route on the server side and not on the client. You say =AB the route/ip will still need to be configured on the client = side =BB, how are you supposed to do that automatically ? I don=92t want my users need to do a route add on their side=85 Y.= --Apple-Mail=_9D0823E5-1BDF-4D1D-8564-3881D62F2D93 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUqMIIEEqADAgECAhEA8BSF4QUynr/oAOUnSVCBvTANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzAzMDMw MDAwMDBaFw0xNDAzMDMyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFHlvYW5uLmdpbmlAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11zV57Sqb+CpMeUSmttu8MsHvdUR vZS9O5jKxWljaeZgQbr4A/yShO5PB7MgM4KMQjMIOoacShFvyf6ZivL8r8fFbAmc6NsHr4CN4S9T E0WAi/MWUTPLYrD8zx0NsjimxLP/3Ln1b3TDb0Vp/bqOWePStBU2truYBodyGZCQiHVPBZC6d5tu CswgnIbloUTf4RxyGGt8NCl94lBiw6ZNNc+94BRlIY8a6uyV5/9jqiAu/LZVpLV5n9YZ5BCfoRsM GAi94eUzFv/AdCLp+l0OGjQ+K8APeHihjU8/VtNujjW1tA7r5bs3O8wTQ6lCoCV8J+XZMWUK4grO xisqX5umywIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYD VR0OBBYEFH28/IbXcUSiVbEyWOgyob3zTeHTMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEE fDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHwYDVR0RBBgwFoEUeW9hbm4uZ2luaUBnbWFpbC5jb20wDQYJKoZIhvcNAQEF BQADggEBAC2aIbicOEFNkJwJlCEoBFsi/7im9S6E0GwQ2/+bn0GhOTZQ+mkB9Up2A99TsAV2dWJ/ TClZ5a/tx4K6eP+r7q1ci1QcDdomD8NLI+zpU0zx+I/RnEca24AYJ3fC5dS6nR5sjTj2zoYa0pXs CVrMb24vXBr14iLwG7U+REEX6+p0tbwAjrJLPnViS1TvUPBz5J9W2ag10cCaecSsa6VOGR3xR5ah r9pWGtKZ+xKxnuPsmny5xKCeB+73ZI6DTanIXzHiduGm3A/y7maIjJq4gy7Vm2hH3HaBTV4ZS/DZ 2/sKr5k9/asWaJosS5ciE00tMLCrvogWdF4xhSxUrm/C7j4xggOuMIIDqgIBATCBqTCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQgb0wCQYFKw4DAhoF AKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE4MjAy ODU5WjAjBgkqhkiG9w0BCQQxFgQUlRYTvM3iBLnwtwM/72JrI+a9n7YwgboGCSsGAQQBgjcQBDGB rDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQ gb0wgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA8BSF4QUynr/oAOUnSVCBvTANBgkqhkiG9w0BAQEFAASCAQAkPmoHIXKGYOGMPZ/ZPAeC 5YKOFMvjjSUyuORjoRRWntzBY+LijeUl0nHQ9tEq5HuKK/5o+4hFA2g/lIbuG//N/j6CycK5QdKN YO/qM7C8siKqYEdhMgA69/pycsMNdLfhfdRxNEshjZ+0X20yMOrBdzR7E7qmKVUbTjB2bhs1gIep 0An/zps9cL1cwg9cE8L9UGpF9XWMmTcyJ9k48vMql4Y7pVEMjt+48UbMSTIUyXLfy6HdirPJKVdG JTv/Uuv4hjZjDltdwsKIaNUs3lFUDEKo2Ek+gs3CMCHuSlhxlkBQLA4K69Sckue4II/lWw6crlGT xnWvlq991mrVMs5PAAAAAAAA --Apple-Mail=_9D0823E5-1BDF-4D1D-8564-3881D62F2D93-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 20:48:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4EE651AD for ; Mon, 18 Mar 2013 20:48:33 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id E66519C0 for ; Mon, 18 Mar 2013 20:48:32 +0000 (UTC) Received: from [172.16.8.72] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3ZV8cZ3yB3z1J1; Mon, 18 Mar 2013 20:48:30 +0000 (UTC) Message-ID: <51477D96.4070305@rewt.org.uk> Date: Mon, 18 Mar 2013 20:48:22 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Yoann Gini Subject: Re: mpd5 and multiple route to send to clients References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <514665CD.80809@rewt.org.uk> <51474D7D.2030107@rewt.org.uk> <065823BC-24A6-48EE-B689-310D01019998@gmail.com> In-Reply-To: <065823BC-24A6-48EE-B689-310D01019998@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 20:48:33 -0000 Yoann Gini wrote: > Hi, > > Le 18 mars 2013 à 18:23, Joe Holden a écrit : > >> The radius entry tells the NAS (mpd in this case) to add a route towards the client, the route/ip will still need to be configured on the client side, do you see a correct entry on the NAS? (route -n get 10.42.0.0/23) > > OK, that’s still not what I'm looking for… If I understand well what you said, « Framed-Route » do the same as « set iface route », it add the specified route on the server side and not on the client. > > You say « the route/ip will still need to be configured on the client side », how are you supposed to do that automatically ? > > I don’t want my users need to do a route add on their side… > > Y. You use something that can push configuration the client, like openvpn or run dhcp over something From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 21:22:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 23138117 for ; Mon, 18 Mar 2013 21:22:03 +0000 (UTC) (envelope-from yoann.gini@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id A042ABD7 for ; Mon, 18 Mar 2013 21:22:02 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so3524448wib.5 for ; Mon, 18 Mar 2013 14:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=ccoPmHT9kizaMsQbre4S2Sdi1hE0E/FryYNK+xTKGts=; b=zFAZD2vYhCpNgFfEFbOcs9V16CILKLrthcuObQm2iWr6c9UgahRQSVXfoXgw+/K+V1 dXTdiwVGgdlpWZ7yoMQssLhOlsA95hG21rrnSP1xkgOoqhzUrpnlbuB+NFm7rTbGZ2f0 n1rNCRAV4xD/dUI+NwlHeeFVVf6s9/ddbo+cYmQvfKqx7eSSvmEHIaNFcDyYlHKbwWGN H58yaK2aVCQk5jJxKtL5bDPA6YTnA3+TSr9lJDXUK0Qk9+O+sH0P/lss3rSYpBUEjVC8 LNonHOk1PamE68pCWtMK1y/3OluZvV78JrprUNf3uxLzClQ4KXzst93O+5v4KZGde3lk PNYg== X-Received: by 10.194.81.40 with SMTP id w8mr27931453wjx.14.1363641721923; Mon, 18 Mar 2013 14:22:01 -0700 (PDT) Received: from [192.168.1.38] (81.131.1.93.rev.sfr.net. [93.1.131.81]) by mx.google.com with ESMTPS id n2sm3134157wiy.6.2013.03.18.14.21.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 14:22:00 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8E5B9BA7-7512-475E-BA31-75D1C60B7452"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: mpd5 and multiple route to send to clients From: Yoann Gini In-Reply-To: <51477D96.4070305@rewt.org.uk> Date: Mon, 18 Mar 2013 22:22:01 +0100 Message-Id: References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <514665CD.80809@rewt.org.uk> <51474D7D.2030107@rewt.org.uk> <065823BC-24A6-48EE-B689-310D01019998@gmail.com> <51477D96.4070305@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 21:22:03 -0000 --Apple-Mail=_8E5B9BA7-7512-475E-BA31-75D1C60B7452 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 18 mars 2013 =E0 21:48, Joe Holden a =E9crit : > You use something that can push configuration the client, like openvpn = or run dhcp over something Well, I really don=92t understand. =46rom my experience, with a Cisco VPN Concentrator or a OS X VPN Server = or a Windows VPN Server, you can set a L2TP VPN service with some remote = config to send to the client (DNS servers, domain name, routing = information [like what it for the private network and what is for the = public one], and so on). It supposed to be built-in the VPN client and server. On others = platform, I don=92t need to use a setup based on SSL VPN like OpenVPN = and it=92s not the DHCP who handle that kind of client config but the = built-in mechanisms in the VPN Server (that=92s the case for L2TP and = PPTP). I=92m quite surprised to be front of a so difficult problem here. Routes = sends to the clients are something like the 101 VPN course=85 How do you handle your routing table on your VPN systems with mpd5 = without having to push routes from your concentrators ? Best regards, Y.= --Apple-Mail=_8E5B9BA7-7512-475E-BA31-75D1C60B7452 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUqMIIEEqADAgECAhEA8BSF4QUynr/oAOUnSVCBvTANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzAzMDMw MDAwMDBaFw0xNDAzMDMyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFHlvYW5uLmdpbmlAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11zV57Sqb+CpMeUSmttu8MsHvdUR vZS9O5jKxWljaeZgQbr4A/yShO5PB7MgM4KMQjMIOoacShFvyf6ZivL8r8fFbAmc6NsHr4CN4S9T E0WAi/MWUTPLYrD8zx0NsjimxLP/3Ln1b3TDb0Vp/bqOWePStBU2truYBodyGZCQiHVPBZC6d5tu CswgnIbloUTf4RxyGGt8NCl94lBiw6ZNNc+94BRlIY8a6uyV5/9jqiAu/LZVpLV5n9YZ5BCfoRsM GAi94eUzFv/AdCLp+l0OGjQ+K8APeHihjU8/VtNujjW1tA7r5bs3O8wTQ6lCoCV8J+XZMWUK4grO xisqX5umywIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYD VR0OBBYEFH28/IbXcUSiVbEyWOgyob3zTeHTMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEE fDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHwYDVR0RBBgwFoEUeW9hbm4uZ2luaUBnbWFpbC5jb20wDQYJKoZIhvcNAQEF BQADggEBAC2aIbicOEFNkJwJlCEoBFsi/7im9S6E0GwQ2/+bn0GhOTZQ+mkB9Up2A99TsAV2dWJ/ TClZ5a/tx4K6eP+r7q1ci1QcDdomD8NLI+zpU0zx+I/RnEca24AYJ3fC5dS6nR5sjTj2zoYa0pXs CVrMb24vXBr14iLwG7U+REEX6+p0tbwAjrJLPnViS1TvUPBz5J9W2ag10cCaecSsa6VOGR3xR5ah r9pWGtKZ+xKxnuPsmny5xKCeB+73ZI6DTanIXzHiduGm3A/y7maIjJq4gy7Vm2hH3HaBTV4ZS/DZ 2/sKr5k9/asWaJosS5ciE00tMLCrvogWdF4xhSxUrm/C7j4xggOuMIIDqgIBATCBqTCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQgb0wCQYFKw4DAhoF AKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE4MjEy MjAxWjAjBgkqhkiG9w0BCQQxFgQUmyCdjePqIQ+fDW90POa2RA4/sUYwgboGCSsGAQQBgjcQBDGB rDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQ gb0wgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA8BSF4QUynr/oAOUnSVCBvTANBgkqhkiG9w0BAQEFAASCAQAyT0JwnXpZ6PrN01cwhv72 B+GtSlhP7L99NIOF26TuzQhY4s/goZe2QmSEb1wSJArQOtRAeA/Ax/gQS4E6WNwwuB950R+JyT+v iBOiEpPizaDNrNA/RbIUyFbjYKZdG/ML1QET4XIGoBscm4RQHnGpe+J5XBW9U4bm/F8NxO9moBB3 3rznTrUMPTarqsY2la5/5rP7o7cbOlUrNZSccxI6np6bb3py5G63YXcOprd6vu+lA16WMuwYhiuZ 6mOfi+QAQtMatDxZ6EJ4vzfSzOp9BcYcy7r2rVr3as1p/8zU3r5b2PVwekPYMY6Szfp4Yott1XkJ qzwetiR5jKmVHWA0AAAAAAAA --Apple-Mail=_8E5B9BA7-7512-475E-BA31-75D1C60B7452-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 21:22:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F26E1A6 for ; Mon, 18 Mar 2013 21:22:17 +0000 (UTC) (envelope-from rganascim@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id D87E1BDE for ; Mon, 18 Mar 2013 21:22:16 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t57so5374932wey.13 for ; Mon, 18 Mar 2013 14:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=alCZY2HU2dEMw301SPbhBffhPrQTP4/amFhiQ1Wsndc=; b=kcVNyBFe9590SeBSJEsuY5hpONt/iSKPIxoGk3qr7bRuzdDSsiev4kFrDFZ7LFsjoS zatNrlqO97Q7TyhsNPSCKXs7QDt46JQdXeSEB2MoOnsoP118JAEymkBlj/hJis7um7gY ef3hgOW5pr6SDFP3tW4svYZryAbZ9CAmlkugcgv0at+bEDv9LI1Pwic0A3MkKEpdEinC nv0RL6Y4E8KIBEk7RhMoeSFP3GtltV2qh4d4AwDiXfNnlotdXUA4ewsxwBZw+Odni3sz d1/UgLpYUIxj1Xj6xHsDRt3qUbNOmFq6Q50aMwUv6QrzHggHYsYj2+R/dBOZ9GwTm5fv zmKg== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr898869wiv.23.1363641736032; Mon, 18 Mar 2013 14:22:16 -0700 (PDT) Received: by 10.216.34.3 with HTTP; Mon, 18 Mar 2013 14:22:15 -0700 (PDT) Date: Mon, 18 Mar 2013 18:22:15 -0300 Message-ID: Subject: Carp strange behavior From: Rafael Ganascim To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 21:22:17 -0000 Hi list, I have multiple FreeBSD firewalls with carp working well. I have no problem and the vast majority of firewalls works perfectly. But now, I'm with problems with a simple firewall cluster with carp that the state randomly goes to MASTER and randomly returns to BACKUP. Looking to the L1/L2 tests, I have no rx/tx erros, buffers miss, in/out drops , etc. The physical conection between the firewalls looks good. Monitoring the interfaces/buffers/mbufs/virtual memory with netstat, vmstat.... no errors was found. Using tcpdump, I can see that in the exact moment of the state change, the currently master's firewall stop sending multicasts to the 224.0.0.18 during some seconds and the state change occurs. The system: # uname -a FreeBSD fw-cj-01 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Thu Feb 28 13:18:41 BRT 2013 root@fw-new-01:/usr/obj/usr/src/sys/DEDICr9v1CoreX64 amd64 Now, how can I debug why carp stops to send multicast packets? Best Regards, Rafael From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 21:27:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 67ADB388 for ; Mon, 18 Mar 2013 21:27:53 +0000 (UTC) (envelope-from yoann.gini@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 03595C35 for ; Mon, 18 Mar 2013 21:27:52 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id d46so5221159wer.31 for ; Mon, 18 Mar 2013 14:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=lZGVAbdTs+9y9oR8Yq5A8KwkeIpyqz1qFbvD8K5hwYQ=; b=0eKI2YaqIxR4G7GYV2rusYRXGDp1dlt3oYHaMkQeL+8ScbAxEOVNKeqA2xO0wCn57s m2xPHgJ776X92SJMzmEvO5wkg8dZgUJwSD4Gq+FjXrelSVZDkPrd02sxtWcoEH4YdtPu uRS4OeGsSSEQnVB8LR+8t7xi7U81We5F0IiMM2Z0uLzWI5t5mouzXNMhahGytTtVj/Ei WKGrX2DH0l8t8DTAKMe8dxIWoUHtvNflfb/EMAQ5Lx7OjGMs7dHOOVM03eK1Kx3nNyuK BDN5q+/w53Oz0/2qvdDwaqH9jVZ4ynCQrJJpkjwOtopCnjuhgJJb8fD/4n0iE37PS9pl C0wQ== X-Received: by 10.194.178.9 with SMTP id cu9mr28181641wjc.39.1363642071401; Mon, 18 Mar 2013 14:27:51 -0700 (PDT) Received: from [192.168.1.38] (81.131.1.93.rev.sfr.net. [93.1.131.81]) by mx.google.com with ESMTPS id dm9sm3168663wib.3.2013.03.18.14.27.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 14:27:50 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C8726F15-288D-4634-9ADF-1B58E3C04C24"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: mpd5 and multiple route to send to clients From: Yoann Gini In-Reply-To: Date: Mon, 18 Mar 2013 22:27:50 +0100 Message-Id: <222F9A4C-763E-47C0-AE37-3FA0934463E3@gmail.com> References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <514665CD.80809@rewt.org.uk> <51474D7D.2030107@rewt.org.uk> <065823BC-24A6-48EE-B689-310D01019998@gmail.com> <51477D96.4070305@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 21:27:53 -0000 --Apple-Mail=_C8726F15-288D-4634-9ADF-1B58E3C04C24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 18 mars 2013 =E0 22:22, Yoann Gini a =E9crit : >=20 > Le 18 mars 2013 =E0 21:48, Joe Holden a =E9crit : >=20 >> You use something that can push configuration the client, like = openvpn or run dhcp over something >=20 > Well, I really don=92t understand. >=20 > =46rom my experience, with a Cisco VPN Concentrator or a OS X VPN = Server or a Windows VPN Server, you can set a L2TP VPN service with some = remote config to send to the client (DNS servers, domain name, routing = information [like what it for the private network and what is for the = public one], and so on). >=20 > It supposed to be built-in the VPN client and server. On others = platform, I don=92t need to use a setup based on SSL VPN like OpenVPN = and it=92s not the DHCP who handle that kind of client config but the = built-in mechanisms in the VPN Server (that=92s the case for L2TP and = PPTP). >=20 > I=92m quite surprised to be front of a so difficult problem here. = Routes sends to the clients are something like the 101 VPN course=85 >=20 > How do you handle your routing table on your VPN systems with mpd5 = without having to push routes from your concentrators ? Just to explicitly name it, in case it=92s not clear, what I try to = setup is a Split Tunneling config.= --Apple-Mail=_C8726F15-288D-4634-9ADF-1B58E3C04C24 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUqMIIEEqADAgECAhEA8BSF4QUynr/oAOUnSVCBvTANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzAzMDMw MDAwMDBaFw0xNDAzMDMyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFHlvYW5uLmdpbmlAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11zV57Sqb+CpMeUSmttu8MsHvdUR vZS9O5jKxWljaeZgQbr4A/yShO5PB7MgM4KMQjMIOoacShFvyf6ZivL8r8fFbAmc6NsHr4CN4S9T E0WAi/MWUTPLYrD8zx0NsjimxLP/3Ln1b3TDb0Vp/bqOWePStBU2truYBodyGZCQiHVPBZC6d5tu CswgnIbloUTf4RxyGGt8NCl94lBiw6ZNNc+94BRlIY8a6uyV5/9jqiAu/LZVpLV5n9YZ5BCfoRsM GAi94eUzFv/AdCLp+l0OGjQ+K8APeHihjU8/VtNujjW1tA7r5bs3O8wTQ6lCoCV8J+XZMWUK4grO xisqX5umywIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYD VR0OBBYEFH28/IbXcUSiVbEyWOgyob3zTeHTMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEE fDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHwYDVR0RBBgwFoEUeW9hbm4uZ2luaUBnbWFpbC5jb20wDQYJKoZIhvcNAQEF BQADggEBAC2aIbicOEFNkJwJlCEoBFsi/7im9S6E0GwQ2/+bn0GhOTZQ+mkB9Up2A99TsAV2dWJ/ TClZ5a/tx4K6eP+r7q1ci1QcDdomD8NLI+zpU0zx+I/RnEca24AYJ3fC5dS6nR5sjTj2zoYa0pXs CVrMb24vXBr14iLwG7U+REEX6+p0tbwAjrJLPnViS1TvUPBz5J9W2ag10cCaecSsa6VOGR3xR5ah r9pWGtKZ+xKxnuPsmny5xKCeB+73ZI6DTanIXzHiduGm3A/y7maIjJq4gy7Vm2hH3HaBTV4ZS/DZ 2/sKr5k9/asWaJosS5ciE00tMLCrvogWdF4xhSxUrm/C7j4xggOuMIIDqgIBATCBqTCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQgb0wCQYFKw4DAhoF AKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE4MjEy NzUxWjAjBgkqhkiG9w0BCQQxFgQUpRIX+Mj593EEygdLdIGMgf+d4hIwgboGCSsGAQQBgjcQBDGB rDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQ gb0wgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA8BSF4QUynr/oAOUnSVCBvTANBgkqhkiG9w0BAQEFAASCAQB1kQ6NaJ0qWiYGmxFFwmKD ngk4MAbLrP2Br4A7iHncf+uAtngBTgjCuSTnrp5NQHhz63h0qyhveN5mLT38E6T3wJHElC3FD+0B 61rxDC18lz1Q/7ZQhj1gF1nSZ/HdnLC1Ih3uXT8KdioOzvJJTC5T/syUlwfByXMYmS6PFpqi6beZ PD1pyv75QkaQnh5iN1HF3QgfsLGfmmhxgZc81wQd2VezBWA3IPvld1nQ5lIACubvAdC+j9M384jS 4z8+oib5g9sgaVMwUsodp+s7kDWZ4KE4vwd8SasixdRKE99jvvxfs7taZz4sZ8alA3upgYtG5r0z wFxpCus3iF7dT+7RAAAAAAAA --Apple-Mail=_C8726F15-288D-4634-9ADF-1B58E3C04C24-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 21:32:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB03A71B for ; Mon, 18 Mar 2013 21:32:25 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 776CBD03 for ; Mon, 18 Mar 2013 21:32:23 +0000 (UTC) Received: from [172.16.9.23] (bella.stf.rewt.org.uk [91.208.177.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joe@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3ZV9b74WDTz1JJ; Mon, 18 Mar 2013 21:32:19 +0000 (UTC) Message-ID: <514787D8.6010207@rewt.org.uk> Date: Mon, 18 Mar 2013 21:32:08 +0000 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Yoann Gini Subject: Re: mpd5 and multiple route to send to clients References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <514665CD.80809@rewt.org.uk> <51474D7D.2030107@rewt.org.uk> <065823BC-24A6-48EE-B689-310D01019998@gmail.com> <51477D96.4070305@rewt.org.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 21:32:25 -0000 Yoann Gini wrote: > Le 18 mars 2013 à 21:48, Joe Holden a écrit : > >> You use something that can push configuration the client, like openvpn or run dhcp over something > > Well, I really don’t understand. > > From my experience, with a Cisco VPN Concentrator or a OS X VPN Server or a Windows VPN Server, you can set a L2TP VPN service with some remote config to send to the client (DNS servers, domain name, routing information [like what it for the private network and what is for the public one], and so on). > > It supposed to be built-in the VPN client and server. On others platform, I don’t need to use a setup based on SSL VPN like OpenVPN and it’s not the DHCP who handle that kind of client config but the built-in mechanisms in the VPN Server (that’s the case for L2TP and PPTP). > > I’m quite surprised to be front of a so difficult problem here. Routes sends to the clients are something like the 101 VPN course… > > How do you handle your routing table on your VPN systems with mpd5 without having to push routes from your concentrators ? > > Best regards, > Y. Cisco et al don't use plain l2tp/pptp - they allow the remote configuration of client routing.. traditional ppp doesn't allow the ability to push configuration to the clients outside of IP/dns/netbios etc, IPsec for example has this ability but straight ppp does not. You will probably be better off by doing IPsec over L2TP as it should cover what you need From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 21:51:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D309E2C9 for ; Mon, 18 Mar 2013 21:51:16 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id 6CA65EFD for ; Mon, 18 Mar 2013 21:51:16 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so4928693wge.34 for ; Mon, 18 Mar 2013 14:51:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=u5nTfswZU9tXAtnhQcaghqV/iq07TlAixfU7LzbodZc=; b=AiU0XvWQJ66/AD9Mvk/dEw6+3C5VIIVMEkbV7GyFiCWzdg6NFfvE+gaW5otDgyrbhD 8wzMP6kLYW0TzesuQohb8bTOvEcQvIPWobZZQ0hZPqRd20M8ZihmKbWAOb+GPCP79Jkr o6CG5vGxmus5hCA2gEuJWg1mlL8414GFZ9/LxfzjHzz3bpj2RYlhGi+vkOZAhgnxgLgK oa7ZPoGdMCoXjhVb2VeDYQm7KN1W8KoatuBnhITUeIYoIdQoTze2h+lbyo9eASUUG1D4 y995k6UWcIUPa6qU3G6SVNxGuwZwfBHZqHk6MmiRiDPUKNDtDKV2QzUEatLx59KENuBy SrDQ== X-Received: by 10.180.13.166 with SMTP id i6mr1020165wic.21.1363643469614; Mon, 18 Mar 2013 14:51:09 -0700 (PDT) Received: from [10.208.255.159] ([92.90.16.102]) by mx.google.com with ESMTPS id j4sm3242276wiz.10.2013.03.18.14.51.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 14:51:08 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (10B144) From: Damien Fleuriot Subject: Re: Carp strange behavior Date: Mon, 18 Mar 2013 22:50:44 +0100 To: Rafael Ganascim X-Gm-Message-State: ALoCoQnkZIqbXonG11fGUa54dY7jZAVwAyne7/54XoBei+qM9CQ1Y34iMvUXFTZHxKw0OVO2zEWZ Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 21:51:16 -0000 On 18 Mar 2013, at 22:22, Rafael Ganascim wrote: > Hi list, > > I have multiple FreeBSD firewalls with carp working well. I have no problem > and the vast majority of firewalls works perfectly. > > But now, I'm with problems with a simple firewall cluster with carp that > the state randomly goes to MASTER and randomly returns to BACKUP. > > Looking to the L1/L2 tests, I have no rx/tx erros, buffers miss, in/out > drops , etc. The physical conection between the firewalls looks good. > > Monitoring the interfaces/buffers/mbufs/virtual memory with netstat, > vmstat.... no errors was found. > > Using tcpdump, I can see that in the exact moment of the state change, the > currently master's firewall stop sending multicasts to the 224.0.0.18 > during some seconds and the state change occurs. > > The system: > # uname -a > FreeBSD fw-cj-01 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Thu Feb 28 13:18:41 > BRT 2013 root@fw-new-01:/usr/obj/usr/src/sys/DEDICr9v1CoreX64 amd64 > > > Now, how can I debug why carp stops to send multicast packets? > Lots of things to be said here. First, how do you know carp stops sending packets ? Might not be the case. Second, triple check that the VHID is not already used somewhere else. Third, any firewalling in place ? If so, disable it, check for better results. Fourth, netstat -m -p carp Fifth, raise advbase on both boxes and see if that helps. Sixth, what's the frequency of these role swaps ? Seventh, what do you get in dmesg ? From owner-freebsd-net@FreeBSD.ORG Mon Mar 18 22:03:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4A0BF82C for ; Mon, 18 Mar 2013 22:03:10 +0000 (UTC) (envelope-from rganascim@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by mx1.freebsd.org (Postfix) with ESMTP id C64E1FAF for ; Mon, 18 Mar 2013 22:03:09 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id l13so3564981wie.0 for ; Mon, 18 Mar 2013 15:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=obhWdEZulOaIEjThJw1Erj7Z0uL+AsQjqrfblnmWWsA=; b=tDdpYv8YkFFa4LhpNIsNjN+dsQYA5ozhHdJOkRzXcrkfD5WgVgqoxUWFOuMqQPOzUW fPgGhqEcCaA9nn65BqjLJCSk7MlvcKrSHLeqcYi80Hd3y/OOLlCiS9V/aSG6lKHo6S6G IkKcjMXb0Gl6RUi+tZMs90mrXskZoQlyMKO1QK+trvtsBfdKjSE+8eOwTJ2Ja51jVdAl CxkTCG+FDKlCfuNd5yz+QPLziUGnUjcsSqLtbOjTeFgwYiQzWRaTZEQvQS6zjOZ3Sv3y mt/+goELrHyuYXnSh2fc2TH0iavRaDD7UCnnR6iYypz87HDdjnHpEHQWrZzs94xBsfLh OOlw== MIME-Version: 1.0 X-Received: by 10.194.103.72 with SMTP id fu8mr28196805wjb.42.1363644188840; Mon, 18 Mar 2013 15:03:08 -0700 (PDT) Received: by 10.216.34.3 with HTTP; Mon, 18 Mar 2013 15:03:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Mar 2013 19:03:08 -0300 Message-ID: Subject: Re: Carp strange behavior From: Rafael Ganascim To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Mar 2013 22:03:10 -0000 2013/3/18 Damien Fleuriot > > On 18 Mar 2013, at 22:22, Rafael Ganascim wrote: > > > Hi list, > > > > I have multiple FreeBSD firewalls with carp working well. I have no > problem > > and the vast majority of firewalls works perfectly. > > > > But now, I'm with problems with a simple firewall cluster with carp that > > the state randomly goes to MASTER and randomly returns to BACKUP. > > > > Looking to the L1/L2 tests, I have no rx/tx erros, buffers miss, in/out > > drops , etc. The physical conection between the firewalls looks good. > > > > Monitoring the interfaces/buffers/mbufs/virtual memory with netstat, > > vmstat.... no errors was found. > > > > Using tcpdump, I can see that in the exact moment of the state change, > the > > currently master's firewall stop sending multicasts to the 224.0.0.18 > > during some seconds and the state change occurs. > > > > The system: > > # uname -a > > FreeBSD fw-cj-01 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Thu Feb 28 13:18:41 > > BRT 2013 root@fw-new-01:/usr/obj/usr/src/sys/DEDICr9v1CoreX64 amd64 > > > > > > Now, how can I debug why carp stops to send multicast packets? > > > > Lots of things to be said here. > > First, how do you know carp stops sending packets ? > Might not be the case. > > Second, triple check that the VHID is not already used somewhere else. > > Third, any firewalling in place ? > If so, disable it, check for better results. > > Fourth, netstat -m -p carp > > Fifth, raise advbase on both boxes and see if that helps. > > Sixth, what's the frequency of these role swaps ? > > Seventh, what do you get in dmesg ? > Hi Damien, thanks for the help. 1) Really, I don't know. What I can see is the ausence of the multicast packets to the 224.0.0.18 for some seconds. 2) VHID not used anywhere. 3) pf is enabled with basic rules. I'll test with pf disabled. 4) here the output: # netstat -m -p carp 10744/5396/16140 mbufs in use (current/cache/total) 10232/5406/15638/262144 mbuf clusters in use (current/cache/total/max) 10232/3976 mbuf+clusters out of packet secondary zone in use (current/cache) 0/151/151/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 23150K/12765K/35915K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines # netstat -s -p carp carp: 590531 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 4915111 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error 5) I'll raise and report the results. 6) Look here: Mar 15 10:41:36 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 10:45:27 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 14:09:33 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 15:36:36 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 16:31:01 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 19:31:23 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 22:13:58 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 22:46:14 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 15 23:41:55 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 16 12:31:43 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 17 17:38:01 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 18 12:21:48 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) Mar 18 17:30:57 fw-cj-01 kernel: carp300: MASTER -> BACKUP (more frequent advertisement received) 7) dmesg carp300: MASTER -> BACKUP (more frequent advertisement received) carp300: link state changed to DOWN carp301: MASTER -> BACKUP (more frequent advertisement received) carp301: link state changed to DOWN carp302: MASTER -> BACKUP (more frequent advertisement received) carp302: link state changed to DOWN carp319: MASTER -> BACKUP (more frequent advertisement received) carp319: link state changed to DOWN carp302: link state changed to UP carp319: link state changed to UP carp300: link state changed to UP carp301: link state changed to UP carp302: MASTER -> BACKUP (more frequent advertisement received) carp302: link state changed to DOWN carp319: MASTER -> BACKUP (more frequent advertisement received) carp319: link state changed to DOWN carp302: BACKUP -> MASTER (preempting a slower master) carp302: link state changed to UP carp319: BACKUP -> MASTER (preempting a slower master) carp319: link state changed to UP carp300: MASTER -> BACKUP (more frequent advertisement received) carp300: link state changed to DOWN carp301: MASTER -> BACKUP (more frequent advertisement received) carp301: link state changed to DOWN carp302: MASTER -> BACKUP (more frequent advertisement received) carp302: link state changed to DOWN carp319: MASTER -> BACKUP (more frequent advertisement received) carp319: link state changed to DOWN carp302: link state changed to UP carp319: link state changed to UP carp301: link state changed to UP carp300: link state changed to UP carp302: MASTER -> BACKUP (more frequent advertisement received) carp302: link state changed to DOWN carp319: MASTER -> BACKUP (more frequent advertisement received) carp319: link state changed to DOWN carp301: MASTER -> BACKUP (more frequent advertisement received) carp301: link state changed to DOWN carp301: BACKUP -> MASTER (preempting a slower master) carp301: link state changed to UP carp302: BACKUP -> MASTER (preempting a slower master) carp302: link state changed to UP carp319: BACKUP -> MASTER (preempting a slower master) carp319: link state changed to UP Limiting icmp ping response from 428 to 200 packets/sec Limiting icmp ping response from 466 to 200 packets/sec carp300: MASTER -> BACKUP (more frequent advertisement received) carp300: link state changed to DOWN carp301: MASTER -> BACKUP (more frequent advertisement received) carp301: link state changed to DOWN carp302: MASTER -> BACKUP (more frequent advertisement received) carp302: link state changed to DOWN carp319: MASTER -> BACKUP (more frequent advertisement received) carp319: link state changed to DOWN carp300: link state changed to UP carp301: BACKUP -> MASTER (preempting a slower master) carp301: link state changed to UP carp302: BACKUP -> MASTER (preempting a slower master) carp302: link state changed to UP carp319: BACKUP -> MASTER (preempting a slower master) carp319: link state changed to UP carp300: MASTER -> BACKUP (more frequent advertisement received) carp300: link state changed to DOWN carp301: MASTER -> BACKUP (more frequent advertisement received) carp301: link state changed to DOWN carp302: MASTER -> BACKUP (more frequent advertisement received) carp302: link state changed to DOWN carp319: MASTER -> BACKUP (more frequent advertisement received) carp319: link state changed to DOWN carp301: link state changed to UP carp302: link state changed to UP carp319: link state changed to UP carp300: link state changed to UP carp302: MASTER -> BACKUP (more frequent advertisement received) carp302: link state changed to DOWN carp301: MASTER -> BACKUP (more frequent advertisement received) carp319: MASTER -> BACKUP (more frequent advertisement received) carp301: link state changed to DOWN carp319: link state changed to DOWN carp302: BACKUP -> MASTER (preempting a slower master) carp302: link state changed to UP carp319: BACKUP -> MASTER (preempting a slower master) carp319: link state changed to UP carp301: link state changed to UP From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 04:29:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AF551397; Tue, 19 Mar 2013 04:29:59 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 281526E; Tue, 19 Mar 2013 04:29:58 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.5/8.14.5) with ESMTP id r2J4Tvgu085622; Tue, 19 Mar 2013 00:29:57 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.5/8.14.4/Submit) id r2J4TvgG085619; Tue, 19 Mar 2013 00:29:57 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20807.59845.764047.618551@hergotha.csail.mit.edu> Date: Tue, 19 Mar 2013 00:29:57 -0400 From: Garrett Wollman To: Rick Macklem Subject: Re: Limits on jumbo mbuf cluster allocation In-Reply-To: <75232221.3844453.1363146480616.JavaMail.root@erie.cs.uoguelph.ca> References: <20798.44871.601547.24628@hergotha.csail.mit.edu> <75232221.3844453.1363146480616.JavaMail.root@erie.cs.uoguelph.ca> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Tue, 19 Mar 2013 00:29:58 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-net@freebsd.org, andre@freebsd.org, Ivan Voras X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 04:29:59 -0000 < said: > I've attached a patch that has assorted changes. So I've done some preliminary testing on a slightly modified form of this patch, and it appears to have no major issues. However, I'm still waiting for my user with 500 VMs to have enough free to be able to run some real stress tests for me. I was able to get about 2.5 Gbit/s throughput for a single streaming client over local 10G interfaces with jumbo frames (through a single switch and with LACP on both sides -- how well does lagg(4) interact with TSO and checksum offload?) This is a little bit disappointing (considering that the filesystem can do 14 Gbit/s locally) but still pretty decent for one single-threaded client. This obviously does not implicate the DRC changes at all, but does suggest that there is room for more performance improvement. (In previous tests last year, I was able to get a sustained 8 Gbit/s when using multiple clients.) I also found that one of our 10G switches is reordering TCP segments in a way that causes poor performance. I'll hopefully have some proper testing results later in the week. -GAWollman From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 04:49:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E0EDA671 for ; Tue, 19 Mar 2013 04:49:43 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8F51B123 for ; Tue, 19 Mar 2013 04:49:43 +0000 (UTC) Received: from [192.168.248.33] ([192.168.248.33]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2J4ndlP004035 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 19 Mar 2013 10:49:40 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <5147EE5D.5070203@norma.perm.ru> Date: Tue, 19 Mar 2013 10:49:33 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: mpd5 and multiple route to send to clients References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> In-Reply-To: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Tue, 19 Mar 2013 10:49:41 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 04:49:43 -0000 Hi. On 18.03.2013 3:26, Yoann Gini wrote: > Hello, > > I’m Yoann. It’s my first message here so a little brief about me. I’m a OS X Server System Administrator and Trainer, actually working on a FreeBSD based setup for a simple service provider infrastructure. > > I currently setup a L2TP over IPSec VPN server with FreeBSD 9.1 and mpd 5.6. > > I’ve done with success my setup with radius authentication and all interesting stuff except for one thing that I can’t find on Internet. > > I need to push some routes to my clients to configure them to use the VPN interface to reach some private network available behind my server. > > You cannot do this with a pptp or l2tp, they just don't have that ability. You could do this using openvpn, but openvpn is a horrible mess of weirdness and incompatibility. Standard approach is either using remote pptp/l2tp peer as default gateway, or creating a sticky route on the client side. Eugene. From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 06:03:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC4BC50A for ; Tue, 19 Mar 2013 06:03:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4F67E3D9 for ; Tue, 19 Mar 2013 06:03:40 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id u10so52743pdi.9 for ; Mon, 18 Mar 2013 23:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=/EZ5euU0SEjm6o5WLwPezg+Hz2lh/eD7lfagsl79634=; b=R1XCnL9NddET/ex7Zx8a5bepTE3GAckbCymJ26Trn1tLhG9qqFG89TV3LBKkgbCGb6 5zlRgf90IQKoTUMYqHE/KhUcrwKDVH6qEd37AQq3qFG7V4Ss/u5B+EQvA2xmowFV2uK0 0ji1ofX7hMUHXs1ELBc37GJWYEeHH6Y7fhkolmw6VxcuPAfuOWfwjMeICHbJW0oO8NDz nWtXtrpiSB0/WsgKy2QbOXDyyDjkkdOeD072fV9e3odeixt5/Cu6hrlu9EhXBCymGQzk SWpW3i6rmTu31NFCegAze83qcB+uuQ4nQdWZWK1hvynSeDoePxeh7JBiJ07l//v17iDQ qPcQ== X-Received: by 10.66.152.129 with SMTP id uy1mr1527380pab.36.1363673013923; Mon, 18 Mar 2013 23:03:33 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id fh1sm11210740pac.1.2013.03.18.23.03.30 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 18 Mar 2013 23:03:32 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 19 Mar 2013 15:03:27 +0900 From: YongHyeon PYUN Date: Tue, 19 Mar 2013 15:03:27 +0900 To: "Eugene M. Zheganin" Subject: Re: FreeBSD 9.1-RELEASE + bge0 == watchdog timeout Message-ID: <20130319060327.GC1437@michelle.cdnetworks.com> References: <513713C2.1000007@norma.perm.ru> <20130307022446.GB3108@michelle.cdnetworks.com> <513820E2.806@norma.perm.ru> <20130307062335.GB1478@michelle.cdnetworks.com> <51383E3B.5030007@norma.perm.ru> <20130307081548.GD1478@michelle.cdnetworks.com> <20130313015753.GD3062@michelle.cdnetworks.com> <514171D1.50807@norma.perm.ru> <20130314072946.GA1519@michelle.cdnetworks.com> <51469BE4.6070502@norma.perm.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51469BE4.6070502@norma.perm.ru> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 06:03:40 -0000 On Mon, Mar 18, 2013 at 10:45:24AM +0600, Eugene M. Zheganin wrote: > Hi. > > On 14.03.2013 13:29, YongHyeon PYUN wrote: > > >I thought you were using stable/8 but it seems you have slightly > >older stable/8. The bge(4) code difference between CURRENT and > >stable9/stable8 is very minor. > Nah, I really am running recent 8/stable. My mistake was to try to apply > the whole code of the if_bge.c to 8/stable. > > >I've attached diff against stable/8 which will address ASF/IPMI > >issue but I'm not sure whether it helps watchdog timeout or not. > >I have plan to MFC the change but I need time for settlement before > >the MFC. > Thanks a lot. Now the 'watchdog timeout' behaviour stopped, the driver > reports nothing on the console, but the freezes, unfortunately - didn't > stop. The machine is freezing at random periods of time, usually 1-2 > days, it partially stops answering to network (network services running > on this machine close the connection, and other weird stuff happens), it > partially responds on the console (I can type but I cannot login) and so I have no idea how this change can freeze your box. It would be even better to know whether the issue was triggered by bge(4) changes. I think you can use bge(4)/brgphy(4) of 8.3-RELEASE on your stable/8. Copy required files from 8.3-RELEASE to stable/8 and rebuild your kernel. For instance, Copy /usr/src/sys/dev/bge/if_bge.c from 8.3-RELEASE to /usr/src/sys/dev/bge on stable/8 Copy /usr/src/sys/dev/bge/if_bgereg.h from 8.3-RELEASE to /usr/src/sys/dev/bge on stable/8 Copy /usr/src/sys/dev/mii/brgphy.c from 8.3-RELEASE to /usr/src/sys/dev/mii on stable/8 Copy /usr/src/sys/dev/mii/brgphyreg.g from 8.3-RELEASE to /usr/src/sys/dev/mii on stable/8 And rebuild your kernel. > on. The asf feature has no influence on this - I tried to enable it, > this happens anyway. > > Should I try upgrade to 9 or 10, do they have more improvements in bge(4) ? No, there is no bge(4) functional differences between stable/8 and stable/9. From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 06:57:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9839EC4A for ; Tue, 19 Mar 2013 06:57:02 +0000 (UTC) (envelope-from yoann.gini@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 0884478C for ; Tue, 19 Mar 2013 06:57:01 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 15so81229wgd.31 for ; Mon, 18 Mar 2013 23:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=Rum59LzexENzc9CiBWK3lHfxnBNkBrDDLpHC4l2cArA=; b=L2F++hMSiD0hEV6VQsfcIs8e/O0oq+29/Hz0VSGSsy7LCkedunuYGlILqQKvgN2pAE jcmlb0EPHl5hEIR+7RMJ3049f5Knu6w/NI4djSLbdJmUvznkhp3Hh4KtSTAscAzOQbTH 22cDNwt/aKPvFrGtz6W0Yia2QzbHAZEKulLXTFurGbu+002zKnCbMIPa2ftch9GDQT2H 9hRm3k2kAzF45eJrR/9GgrfTCDTeA0ggt5apxp+5S1FLSqAY3qSVquaFXdKxglSaVKhf 0WlXM9J0WHEdYkq5hkKD9t1nBWj934oiJoDcqdA0b0d3hi5JA0ccOYaAz2oeiQBSEYxC iQ8w== X-Received: by 10.180.185.204 with SMTP id fe12mr1099052wic.2.1363676215057; Mon, 18 Mar 2013 23:56:55 -0700 (PDT) Received: from [172.20.10.2] ([37.161.232.168]) by mx.google.com with ESMTPS id k5sm19351689wiy.5.2013.03.18.23.56.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Mar 2013 23:56:53 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_185037E8-C7DB-44E5-90C1-DFD058EAA9C1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: mpd5 and multiple route to send to clients From: Yoann Gini In-Reply-To: <5147EE5D.5070203@norma.perm.ru> Date: Tue, 19 Mar 2013 07:56:50 +0100 Message-Id: <1306548A-C393-44DF-9B8D-9A34D806622E@gmail.com> References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <5147EE5D.5070203@norma.perm.ru> To: Eugene M. Zheganin X-Mailer: Apple Mail (2.1503) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 06:57:02 -0000 --Apple-Mail=_185037E8-C7DB-44E5-90C1-DFD058EAA9C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 19 mars 2013 =E0 05:49, Eugene M. Zheganin a = =E9crit : > You cannot do this with a pptp or l2tp, they just don't have that = ability. > Standard approach is either using remote pptp/l2tp peer as default = gateway, or creating a sticky route on the client side. Even if it=92s not built-in the L2TP / PPTP standard, the rest of the = world do it, and need it by the way. Using the VPN gateway as a default = one is not acceptable when it=92s made to secure access to specific = resources only (i.e: Split Tunneling), as a provider, I don=92t want to = handle all network traffic from road-warriors, I don=92t care about = their FaceBook traffic, I just want they corporate one. With VPN, also regularly come VPN on Demand, a settings on the client = side allowing the system to automatically start VPN connection when the = user request for a specific domain (like private.example.com). And if = the authentication is fully based on certificate, the user don=92t see = any authentication request. This kind of highly demanded feature today can=92t be address if at the = beginning we don=92t have split tunneling=85 Well, that=92s a big big problem for me and force me to review all my = plan about this network and also with my OS X Server replacement project = made from a standard FreeBSD=85 > You could do this using openvpn, but openvpn is a horrible mess of = weirdness and incompatibility. I agree with that, OpenVPN is such a mess=85 And can=92t be deployed on = all devices, for example, they have some problems to distribute their = app in France on iOS devices. That the only one with that problem=85 --Apple-Mail=_185037E8-C7DB-44E5-90C1-DFD058EAA9C1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2jCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUqMIIEEqADAgECAhEA8BSF4QUynr/oAOUnSVCBvTANBgkq hkiG9w0BAQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzAzMDMw MDAwMDBaFw0xNDAzMDMyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFHlvYW5uLmdpbmlAZ21haWwu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11zV57Sqb+CpMeUSmttu8MsHvdUR vZS9O5jKxWljaeZgQbr4A/yShO5PB7MgM4KMQjMIOoacShFvyf6ZivL8r8fFbAmc6NsHr4CN4S9T E0WAi/MWUTPLYrD8zx0NsjimxLP/3Ln1b3TDb0Vp/bqOWePStBU2truYBodyGZCQiHVPBZC6d5tu CswgnIbloUTf4RxyGGt8NCl94lBiw6ZNNc+94BRlIY8a6uyV5/9jqiAu/LZVpLV5n9YZ5BCfoRsM GAi94eUzFv/AdCLp+l0OGjQ+K8APeHihjU8/VtNujjW1tA7r5bs3O8wTQ6lCoCV8J+XZMWUK4grO xisqX5umywIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYD VR0OBBYEFH28/IbXcUSiVbEyWOgyob3zTeHTMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAA MCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09N T0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEE fDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRo ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wHwYDVR0RBBgwFoEUeW9hbm4uZ2luaUBnbWFpbC5jb20wDQYJKoZIhvcNAQEF BQADggEBAC2aIbicOEFNkJwJlCEoBFsi/7im9S6E0GwQ2/+bn0GhOTZQ+mkB9Up2A99TsAV2dWJ/ TClZ5a/tx4K6eP+r7q1ci1QcDdomD8NLI+zpU0zx+I/RnEca24AYJ3fC5dS6nR5sjTj2zoYa0pXs CVrMb24vXBr14iLwG7U+REEX6+p0tbwAjrJLPnViS1TvUPBz5J9W2ag10cCaecSsa6VOGR3xR5ah r9pWGtKZ+xKxnuPsmny5xKCeB+73ZI6DTanIXzHiduGm3A/y7maIjJq4gy7Vm2hH3HaBTV4ZS/DZ 2/sKr5k9/asWaJosS5ciE00tMLCrvogWdF4xhSxUrm/C7j4xggOuMIIDqgIBATCBqTCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQgb0wCQYFKw4DAhoF AKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE5MDY1 NjUwWjAjBgkqhkiG9w0BCQQxFgQURXI9GaPj2eTy4/Zd0P2dpfoazGowgboGCSsGAQQBgjcQBDGB rDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAPAUheEFMp6/6ADlJ0lQ gb0wgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEA8BSF4QUynr/oAOUnSVCBvTANBgkqhkiG9w0BAQEFAASCAQAq7+o1EUy+K//oPKNZxusM WAMu8yp3c53I7AHJ7wZPTuzzxQCwIvZadTkjZDRzgjePT6QkuqHY5rVLGNZ8OfWYy4cme2RcjC4L 2Ez/guCxXkvMlInEZ2OOUBXwN29v+XF068OyDee0N4anxedD3UwWkTV1Pw800dQ936TTHe/u/+oS PVrrImddxyC3itk+TIeG8yf2TxuT5prXzOIAkEflwPmVb3gMB+4SElblSqqvZA/qNY17mCVYaAJ8 lgGHHPwmLBR6YtIfLji5RAJ2wyCGSBlt0BNRvNxpn17KDLmNphzxtuicuYOG2TyaOqp6Vd6pqy3s s585Jd5sOJ8GCbTeAAAAAAAA --Apple-Mail=_185037E8-C7DB-44E5-90C1-DFD058EAA9C1-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 07:06:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F40CFEC for ; Tue, 19 Mar 2013 07:06:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8A16A803 for ; Tue, 19 Mar 2013 07:06:31 +0000 (UTC) Received: (qmail 6982 invoked from network); 19 Mar 2013 08:17:50 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 19 Mar 2013 08:17:50 -0000 Message-ID: <51480E6D.9050708@freebsd.org> Date: Tue, 19 Mar 2013 08:06:21 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Garrett Wollman Subject: Re: Limits on jumbo mbuf cluster allocation References: <20798.44871.601547.24628@hergotha.csail.mit.edu> <75232221.3844453.1363146480616.JavaMail.root@erie.cs.uoguelph.ca> <20807.59845.764047.618551@hergotha.csail.mit.edu> In-Reply-To: <20807.59845.764047.618551@hergotha.csail.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Rick Macklem , Ivan Voras X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 07:06:32 -0000 On 19.03.2013 05:29, Garrett Wollman wrote: > < said: > >> I've attached a patch that has assorted changes. > > So I've done some preliminary testing on a slightly modified form of > this patch, and it appears to have no major issues. However, I'm > still waiting for my user with 500 VMs to have enough free to be able > to run some real stress tests for me. > > I was able to get about 2.5 Gbit/s throughput for a single streaming > client over local 10G interfaces with jumbo frames (through a single > switch and with LACP on both sides -- how well does lagg(4) interact > with TSO and checksum offload?) This is a little bit disappointing > (considering that the filesystem can do 14 Gbit/s locally) but still > pretty decent for one single-threaded client. This obviously does not > implicate the DRC changes at all, but does suggest that there is room > for more performance improvement. (In previous tests last year, I > was able to get a sustained 8 Gbit/s when using multiple clients.) I > also found that one of our 10G switches is reordering TCP segments in > a way that causes poor performance. Of course testing a single vs. multiple clients has a different dynamic on the control loop between TCP, RPC, NFS, VFS and disk. The aggregate multiple is likely to be much higher. There may be optimization potential in fine-tuning these control loops. Also NFS (old and new) do not do direct dispatch of the VM pages as in sendfile but copy the data into mbufs. The performance improvement on highly loaded systems may be non-trivial, however it is not so easy to implement. -- Andre > I'll hopefully have some proper testing results later in the week. > > -GAWollman > _______________________________________________ > 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 Mar 19 07:21:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D1A665CE for ; Tue, 19 Mar 2013 07:21:31 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 633328B7 for ; Tue, 19 Mar 2013 07:21:31 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2J7LRBB019118 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 19 Mar 2013 13:21:28 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <514811F1.4060706@norma.perm.ru> Date: Tue, 19 Mar 2013 13:21:21 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: mpd5 and multiple route to send to clients References: <9EC8E2D3-A52B-4FF1-B840-3D962DF8D917@gmail.com> <5147EE5D.5070203@norma.perm.ru> <1306548A-C393-44DF-9B8D-9A34D806622E@gmail.com> In-Reply-To: <1306548A-C393-44DF-9B8D-9A34D806622E@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Tue, 19 Mar 2013 13:21:29 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 07:21:31 -0000 Hi. On 19.03.2013 12:56, Yoann Gini wrote: > Even if it’s not built-in the L2TP / PPTP standard, the rest of the world do it, and need it by the way. Using the VPN gateway as a default one is not acceptable when it’s made to secure access to specific resources only (i.e: Split Tunneling), as a provider, I don’t want to handle all network traffic from road-warriors, I don’t care about their FaceBook traffic, I just want they corporate one. No questions here, this feature is highly demanded, but still, standard pptp/l2tp implementation just doesn't support it by design. > With VPN, also regularly come VPN on Demand, a settings on the client side allowing the system to automatically start VPN connection when the user request for a specific domain (like private.example.com). And if the authentication is fully based on certificate, the user don’t see any authentication request. > > This kind of highly demanded feature today can’t be address if at the beginning we don’t have split tunneling… > > Well, that’s a big big problem for me and force me to review all my plan about this network and also with my OS X Server replacement project made from a standard FreeBSD… Ofc there's many VPN implementation that supports this feature. But most of them are not compatible with each other, or just aren't available on some platforms. There are lots of modern fancy SSL-VPNs, but their ideology is an ideology of a custom VPN client, like Cisco EzVPN, or even openvpn (which I personally hate). In the same time, mpd is good where you need to have interoperability. Unfortunately, there's bo silver bullet yet. Eugene. From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 14:27:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C7D83A52 for ; Tue, 19 Mar 2013 14:27:16 +0000 (UTC) (envelope-from tom@claimlynx.com) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by mx1.freebsd.org (Postfix) with ESMTP id 529F9A3F for ; Tue, 19 Mar 2013 14:27:16 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id jg9so256278bkc.23 for ; Tue, 19 Mar 2013 07:27:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=9rsAlmc1UnoYIU3XehZa09H8EEMD57HuHmxsxOYlJO8=; b=cjDYBS8Vn26bG7puIzslor572/RGv0mlEmzS+Ca5CMHXpV7jAm/Ipv9UxLvAncTgE9 WOvqR3twoVoSGDu1BjIJu62K+7B6ytMf41ZE9wDaRZhnYm6Lxes5Y/8lcXGDi8iXtXxJ OJFmW0LY5StK+E630Ct0nUVkG6HQ4MxsmimqFAkKi25dSx0pSBT8X31oLx3TeuR+mUvy b0qkJMo7r6vqj9O8iOw/qsflZFu9JjwTFvnFu6LfyhpnoG8X9XEG9vqjNt1wTCjlH0FV Yg1Mgal7b3GnwKYU43ShxV0J0nzzSOLpw7iVp4syzMBepNibMnI1XuZ9+RbqnlvjUIvc wusQ== MIME-Version: 1.0 X-Received: by 10.204.244.196 with SMTP id lr4mr8894443bkb.80.1363703235037; Tue, 19 Mar 2013 07:27:15 -0700 (PDT) Received: by 10.204.153.15 with HTTP; Tue, 19 Mar 2013 07:27:14 -0700 (PDT) Date: Tue, 19 Mar 2013 09:27:14 -0500 Message-ID: Subject: Troubleshooting network issue in 9.1 From: Thomas Johnson To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQlyUdHfzQnohrD3VsczS9WgRlnzkDdVyHR6j8gFLfXTwZD9/4JVAs9a4qhoJndK70oWS1+migrOYUtJwxcQ2huQcBJZNG+yJ/3Wpn6ZnnlZOsObUX0= Content-Type: text/plain; charset=US-ASCII X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: root X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 14:27:16 -0000 I am looking for suggestions on how to troubleshoot a recurring issue we have seen on a pair of firewalls. Twice in the past month, we have rebooted the pair in response to reports of lost connections (an effective, albeit unhelpful solution). In both cases, we have observed that most connections seem to work correctly, but some connections seem to be dropped. Rebooting does resolve the issue. I have attempted to confirm packet loss using tcpdump, but I have not been successful, due to the seemingly inconsistent nature of the drops. The pair of hosts is not under any substantial load. generally (max ~12k states in pf, 1.3k pps on the WAN, over the week). The firewall pair runs FreeBSD i386. They were upgraded from 8.2 to 9.1-RC3 in early December, and the first connection drop event (and resulting reboot) occurred on February 12. In the days preceeding the first event (Feb. 11th), we added a VLAN, CARP interface, and IPv6 configuration to the hosts. We considered that something in this new configuration may have been responsible for the event, though these firewalls already had a number of VLANs and CARP interfaces. On February 14th, both firewalls were upgraded to 9.1-RELEASE. Since then, we have re-added the VLAN and CARP configurations. The firewalls were stable until March 14, when we began receiving reports of the same behavior. After a quick investigation yielded nothing, we rebooted the firewalls again, in the interest of keeping things running normally. Does anyone have any suggestions on what I should look for, when this happens again? Could this be related to reported CARP issues in 9.1, as discussed on this list recently? Thanks! -- Thomas Johnson -- This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the individual responsible for delivering the e-mail to the intended recipient, please be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender or call ClaimLynx at (952) 593-5969. From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 14:37:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AFF32F8; Tue, 19 Mar 2013 14:37:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3E867AD0; Tue, 19 Mar 2013 14:37:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAPh2SFGDaFvO/2dsb2JhbABDiB+8b4FsdIIkAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdtBgyvbIJAkCWBI4w7fDQHgi2BEwOTGYEIgj6BH49jgyYgMoEFNQ X-IronPort-AV: E=Sophos;i="4.84,872,1355115600"; d="scan'208";a="19706936" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Mar 2013 10:37:31 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id ACBE8B3F4A; Tue, 19 Mar 2013 10:37:31 -0400 (EDT) Date: Tue, 19 Mar 2013 10:37:31 -0400 (EDT) From: Rick Macklem To: Garrett Wollman Message-ID: <1784154272.4050462.1363703851697.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20807.59845.764047.618551@hergotha.csail.mit.edu> Subject: Re: Limits on jumbo mbuf cluster allocation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org, andre@freebsd.org, Ivan Voras X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 14:37:33 -0000 Garrett Wollman wrote: > < said: > > > I've attached a patch that has assorted changes. > > So I've done some preliminary testing on a slightly modified form of > this patch, and it appears to have no major issues. However, I'm > still waiting for my user with 500 VMs to have enough free to be able > to run some real stress tests for me. > > I was able to get about 2.5 Gbit/s throughput for a single streaming > client over local 10G interfaces with jumbo frames (through a single > switch and with LACP on both sides -- how well does lagg(4) interact > with TSO and checksum offload?) This is a little bit disappointing > (considering that the filesystem can do 14 Gbit/s locally) but still > pretty decent for one single-threaded client. This obviously does not > implicate the DRC changes at all, but does suggest that there is room > for more performance improvement. (In previous tests last year, I > was able to get a sustained 8 Gbit/s when using multiple clients.) I > also found that one of our 10G switches is reordering TCP segments in > a way that causes poor performance. > If the server for this test isn't doing anything else yet, you could try a test run with a single nfsd thread and see if that improves performance. ken@ emailed yesterday mentioning that out of order reads was resulting in poor performance related to ZFS and that a single nfsd thread improved that for his test. Although a single nfsd thread isn't practical, it suggests that the nfsd thread affinity code that I had forgotten about and has never been ported to the new server, might be needed for this. (I'm not sure how to do the affinity stuff for NFSv4, but it should at least be easy to port the code so that it works for NFSv3 mounts.) rick ps: For a couple of years I had assumed that Isilon would be doing this, but they are no longer working on the FreeBSD NFS server, so the affinity stuff slipped through the cracks. > I'll hopefully have some proper testing results later in the week. > > -GAWollman > _______________________________________________ > 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 Mar 19 15:15:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 632FFCD2; Tue, 19 Mar 2013 15:15:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id E8776E22; Tue, 19 Mar 2013 15:15:14 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAO1/SFGDaFvO/2dsb2JhbABDiB+8boFsdIIkAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdtBgyvXoJAkCGBI4w7fDQHgi2BEwOTGYEIgj6BH49jgyYgMoEFNQ X-IronPort-AV: E=Sophos;i="4.84,872,1355115600"; d="scan'208";a="19716152" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 19 Mar 2013 11:15:13 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A3225B3F16; Tue, 19 Mar 2013 11:15:13 -0400 (EDT) Date: Tue, 19 Mar 2013 11:15:13 -0400 (EDT) From: Rick Macklem To: Garrett Wollman Message-ID: <1807531371.4052865.1363706113648.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1784154272.4050462.1363703851697.JavaMail.root@erie.cs.uoguelph.ca> Subject: Re: Limits on jumbo mbuf cluster allocation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org, andre@freebsd.org, Ivan Voras X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 15:15:15 -0000 I wrote: > Garrett Wollman wrote: > > < > said: > > > > > I've attached a patch that has assorted changes. > > > > So I've done some preliminary testing on a slightly modified form of > > this patch, and it appears to have no major issues. However, I'm > > still waiting for my user with 500 VMs to have enough free to be > > able > > to run some real stress tests for me. > > > > I was able to get about 2.5 Gbit/s throughput for a single streaming > > client over local 10G interfaces with jumbo frames (through a single > > switch and with LACP on both sides -- how well does lagg(4) interact > > with TSO and checksum offload?) This is a little bit disappointing > > (considering that the filesystem can do 14 Gbit/s locally) but still > > pretty decent for one single-threaded client. This obviously does > > not > > implicate the DRC changes at all, but does suggest that there is > > room > > for more performance improvement. (In previous tests last year, I > > was able to get a sustained 8 Gbit/s when using multiple clients.) I > > also found that one of our 10G switches is reordering TCP segments > > in > > a way that causes poor performance. > > > If the server for this test isn't doing anything else yet, you could > try a test run with a single nfsd thread and see if that improves > performance. > > ken@ emailed yesterday mentioning that out of order reads was > resulting > in poor performance related to ZFS and that a single nfsd thread > improved > that for his test. > > Although a single nfsd thread isn't practical, it suggests that the > nfsd > thread affinity code that I had forgotten about and has never been > ported > to the new server, might be needed for this. (I'm not sure how to do > the > affinity stuff for NFSv4, but it should at least be easy to port the > code > so that it works for NFSv3 mounts.) > Oh, and don't hesitate to play with the rsize and readahead options on the client mount. It is not obvious what is an optimal setting for a given LAN/server config. (I think the Linux client has a readahead option?) rick > rick > ps: For a couple of years I had assumed that Isilon would be doing > this, > but they are no longer working on the FreeBSD NFS server, so the > affinity stuff slipped through the cracks. > > > I'll hopefully have some proper testing results later in the week. > > > > -GAWollman > > _______________________________________________ > > 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 Tue Mar 19 20:31:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A8BB276 for ; Tue, 19 Mar 2013 20:31:07 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0A937A for ; Tue, 19 Mar 2013 20:31:06 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2JKV2nc087450 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 20 Mar 2013 02:31:03 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <5148CB00.9060908@norma.perm.ru> Date: Wed, 20 Mar 2013 02:30:56 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Troubleshooting network issue in 9.1 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Wed, 20 Mar 2013 02:31:04 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 20:31:07 -0000 Hi. On 19.03.2013 20:27, Thomas Johnson wrote: > Does anyone have any suggestions on what I should look for, when this > happens again? Could this be related to reported CARP issues in 9.1, as > discussed on this list recently? So, in other words, you upgraded from pf 4.4 to pf 4.5 and problems arised immidiately. Looks familiar. I switched to th 10.x in the same case. And I wait for the situation to resolve, and I'm not upgrading my others productions running 8.x and pf. But I didn't see complains about packet losses or connection drops (I saw once, but it was related only to the max states limit). All that I saw were panics (after applying some particular sets of rules), LORs and freezes (still not sure whether the freezes were about zfs or pf). So, in my case, there were some definitely diagnoseable problems with pf. I've also seen a horrible performance degradation when using route-to/reply-to rules, but this was fixed somewhere between 9.0-RELEASE and 9.1-STABLE. Eugene. From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 20:34:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 88D595F8 for ; Tue, 19 Mar 2013 20:34:50 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 033163E4 for ; Tue, 19 Mar 2013 20:34:49 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2JKYkDP087683 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 20 Mar 2013 02:34:47 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <5148CBE0.9090005@norma.perm.ru> Date: Wed, 20 Mar 2013 02:34:40 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.1-RELEASE + bge0 == watchdog timeout References: <513713C2.1000007@norma.perm.ru> <20130307022446.GB3108@michelle.cdnetworks.com> <513820E2.806@norma.perm.ru> <20130307062335.GB1478@michelle.cdnetworks.com> <51383E3B.5030007@norma.perm.ru> <20130307081548.GD1478@michelle.cdnetworks.com> <20130313015753.GD3062@michelle.cdnetworks.com> <514171D1.50807@norma.perm.ru> <20130314072946.GA1519@michelle.cdnetworks.com> <51469BE4.6070502@norma.perm.ru> <20130319060327.GC1437@michelle.cdnetworks.com> In-Reply-To: <20130319060327.GC1437@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Wed, 20 Mar 2013 02:34:47 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Mar 2013 20:34:50 -0000 Hi. On 19.03.2013 12:03, YongHyeon PYUN wrote: > I have no idea how this change can freeze your box. It would be > even better to know whether the issue was triggered by bge(4) > changes. I think you can use bge(4)/brgphy(4) of 8.3-RELEASE on > your stable/8. Copy required files from 8.3-RELEASE to stable/8 and > rebuild your kernel. For instance, > > Copy /usr/src/sys/dev/bge/if_bge.c from 8.3-RELEASE to /usr/src/sys/dev/bge on stable/8 > Copy /usr/src/sys/dev/bge/if_bgereg.h from 8.3-RELEASE to /usr/src/sys/dev/bge on stable/8 > Copy /usr/src/sys/dev/mii/brgphy.c from 8.3-RELEASE to /usr/src/sys/dev/mii on stable/8 > Copy /usr/src/sys/dev/mii/brgphyreg.g from 8.3-RELEASE to /usr/src/sys/dev/mii on stable/8 > And rebuild your kernel. > I took the sources from one of my servers running March 2012 8.3-PRERELEASE (way more stable than recent stable/8) and I will post results here. Thanks. Eugene. From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 23:10:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7E1B7CB for ; Tue, 19 Mar 2013 23:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 56C41C29 for ; Tue, 19 Mar 2013 23:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2JNA1Y3029203 for ; Tue, 19 Mar 2013 23:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2JNA1Wh029202; Tue, 19 Mar 2013 23:10:01 GMT (envelope-from gnats) Date: Tue, 19 Mar 2013 23:10:01 GMT Message-Id: <201303192310.r2JNA1Wh029202@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mark Andrews Subject: Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mark Andrews List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:10:01 -0000 The following reply was made to PR kern/165305; it has been noted by GNATS. From: Mark Andrews To: bug-followup@FreeBSD.org, marka@isc.org Cc: Subject: Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS Date: Wed, 20 Mar 2013 10:05:41 +1100 As a further followup on the size issue. It should be possible to = accept either int or char as the kernel checks the size.= From owner-freebsd-net@FreeBSD.ORG Tue Mar 19 23:10:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6311BCC for ; Tue, 19 Mar 2013 23:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 51B6DC2A for ; Tue, 19 Mar 2013 23:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2JNA2in029209 for ; Tue, 19 Mar 2013 23:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2JNA2xC029208; Tue, 19 Mar 2013 23:10:02 GMT (envelope-from gnats) Date: Tue, 19 Mar 2013 23:10:02 GMT Message-Id: <201303192310.r2JNA2xC029208@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Mark Andrews Subject: Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mark Andrews List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:10:02 -0000 The following reply was made to PR kern/165305; it has been noted by GNATS. From: Mark Andrews To: bug-followup@FreeBSD.org, marka@isc.org Cc: Subject: Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS Date: Wed, 20 Mar 2013 10:01:49 +1100 Thanks for adding this. It appears to work with FreeBSD 8.4-BETA1 #25 = r248493M. The only point of contention is using sizeof(char) rather than = sizeof(int). Using char is extending the exception from recvmsg and IP_TOS. = sendmsg/recvmsg/setsockopt should all be using the same size. I had to read the kernel code to = work out that it was a 'char' as the header files say 'int' and that is what setsockopt = uses. Mark= From owner-freebsd-net@FreeBSD.ORG Wed Mar 20 01:13:37 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CEE89426 for ; Wed, 20 Mar 2013 01:13:37 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe10.ukr.net (ffe10.ukr.net [195.214.192.60]) by mx1.freebsd.org (Postfix) with ESMTP id 818C617D for ; Wed, 20 Mar 2013 01:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=+gYLq6souI73AFuB2F7/fd4M2qepGQ2wGJbM6WZipzw=; b=AWf0h5q9jgNsiH18DKuNcyOp5pbFQ9kQZSjuzpoGhpaVeqwX9uZWzXDi8qCC1ZdCs822TLHmhJSpQQw9MapK1MAfbs5lTIU+2iM/F88eHKrFdYV+hctXwjK2AtIeAZ74H0NUhgP2NrN4r6GXpK5XP4vnbZmk2SdTe22FUGutqY0=; Received: from mail by ffe10.ukr.net with local ID 1UI7I3-0003si-IK for net@freebsd.org; Wed, 20 Mar 2013 02:54:03 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Need NAT64 on FreeBSD To: "net@freebsd.org" From: "Vladislav Prodan" X-Mailer: freemail.ukr.net 4.0 Message-Id: <13648.1363740843.879986722086846464@ffe10.ukr.net> Date: Wed, 20 Mar 2013 02:54:03 +0200 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Mar 2013 01:13:37 -0000 Prompt please what or how to implement NAT64 on Freebsd? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Mar 20 02:35:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8474E73 for ; Wed, 20 Mar 2013 02:35:01 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 6326B5E5 for ; Wed, 20 Mar 2013 02:35:01 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3ZVwFt1jptzGN2L for ; Wed, 20 Mar 2013 03:34:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:organization:in-reply-to:references:user-agent :date:date:subject:subject:from:from:received:received:received :vbr-info; s=jakla2; t=1363746891; x=1366338892; bh=IIDcAdPjVBpz tRmY4Y3q/3GYt9N7HvzlOKg733UJTCs=; b=S06u5ZqfwNJkym5pi+nCbsM9q6Lc vbjvgRpdnOBimYhPZm9xtQJPXhpWGNJJSLkngBxt15xebYD8Mdywy/RDJY0korvE JZd6bT1454QvpSvBCNxy3iQddgRxm7VZ5eMC2M+GKW9A2UzYrt8j3Abzc+wVHzHw 7xPlC4OLQWR/4Yw= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 56N23fqplm-e for ; Wed, 20 Mar 2013 03:34:51 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 20 Mar 2013 03:34:50 +0100 (CET) Received: from sleepy.ijs.si (sleepy.ijs.si [IPv6:2001:1470:ff80:e001::1:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id DD94AC73 for ; Wed, 20 Mar 2013 03:34:50 +0100 (CET) From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: Need NAT64 on FreeBSD Date: Wed, 20 Mar 2013 03:34:50 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) References: <13648.1363740843.879986722086846464@ffe10.ukr.net> In-Reply-To: <13648.1363740843.879986722086846464@ffe10.ukr.net> Organization: J. Stefan Institute MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201303200334.50448.Mark.Martinec+freebsd@ijs.si> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Mar 2013 02:35:01 -0000 On Wednesday March 20 2013 01:54:03 Vladislav Prodan wrote: > Prompt please what or how to implement NAT64 on Freebsd? It is very unfortunate that the PF firewall on FreeBSD is stuck at an old version and doesn't support NAT64, nor does the IPFW support it AFICT. The quickest options that I see is to fire up a VirtualBox under FreeBSD and install a guest OS there that can do the job, like OpenBSD 5.2, or perhaps using an older live-CD by Ecdysis ( http://ecdysis.viagenie.ca/ ), which provides two choices: Linux with Netfilter, or an old OpenBSD with a patched PF. Btw, the DNS64 is not a problem, just use a recent Bind from ports. Similarly the DHCPv6 is not a problem either thanks to ISC dhcp42 from ports. I feel the lack of NAT64 support under FreeBSD a large hurdle against deploying IPv6-only internal networks. Mark From owner-freebsd-net@FreeBSD.ORG Wed Mar 20 02:56:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C733694 for ; Wed, 20 Mar 2013 02:56:57 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe8.ukr.net (ffe8.ukr.net [195.214.192.88]) by mx1.freebsd.org (Postfix) with ESMTP id 10052752 for ; Wed, 20 Mar 2013 02:56:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=FdExPWQEUJfu+/ae/eDMjSsWBxmdTDFbsFRG7iyNJf4=; b=Lbe6f/QT6zHH8udfQzxSuYkkd7hMGt6+7/hpL7yslziblAsjgPTiDyqWMRm8Vf1jhy7cAlIYMGdc3JvSlkgiwTPZkgBn7tNa0oi5y88kvJW/BJgtgpSddKqeRivRfwSVxEYUt18eiHABR/reCs40T0GHnIOjuC74FgmrBwrMAFI=; Received: from mail by ffe8.ukr.net with local ID 1UI8wV-000NP2-9u ; Wed, 20 Mar 2013 04:39:55 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Re[2]: Need NAT64 on FreeBSD In-Reply-To: <201303200334.50448.Mark.Martinec+freebsd@ijs.si> References: <13648.1363740843.879986722086846464@ffe10.ukr.net> <201303200334.50448.Mark.Martinec+freebsd@ijs.si> To: "Mark Martinec" From: "Vladislav Prodan" X-Mailer: freemail.ukr.net 4.0 Message-Id: <89851.1363747195.14604848580114907136@ffe8.ukr.net> Date: Wed, 20 Mar 2013 04:39:55 +0200 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Mar 2013 02:56:57 -0000 > On Wednesday March 20 2013 01:54:03 Vladislav Prodan wrote: > > Prompt please what or how to implement NAT64 on Freebsd? > > The quickest options that I see is to fire up a VirtualBox > under FreeBSD and install a guest OS there that can do the job, > like OpenBSD 5.2, or perhaps using an older live-CD > by Ecdysis ( http://ecdysis.viagenie.ca/ ), which provides > two choices: Linux with Netfilter, or an old OpenBSD > with a patched PF. Thank you! -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Wed Mar 20 07:24:39 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8F9D216D for ; Wed, 20 Mar 2013 07:24:39 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 524FBF2 for ; Wed, 20 Mar 2013 07:24:39 +0000 (UTC) Received: from 156.cx.rdns.acropolistelecom.net ([217.64.51.156] helo=yafree.ipfw.ru) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UIDRO-000L2K-NY; Wed, 20 Mar 2013 11:28:06 +0400 Message-ID: <5149641B.2070003@ipfw.ru> Date: Wed, 20 Mar 2013 11:24:11 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120824 Thunderbird/14.0 MIME-Version: 1.0 To: Vladislav Prodan Subject: Re: Need NAT64 on FreeBSD References: <13648.1363740843.879986722086846464@ffe10.ukr.net> In-Reply-To: <13648.1363740843.879986722086846464@ffe10.ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Mar 2013 07:24:39 -0000 On 20.03.2013 04:54, Vladislav Prodan wrote: > Prompt please what or how to implement NAT64 on Freebsd? Currently you can try to use net/tayga, it can serve for some purposes. > > From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 00:04:44 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 12391F5A; Thu, 21 Mar 2013 00:04:44 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E09E7BFC; Thu, 21 Mar 2013 00:04:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2L04hUs028347; Thu, 21 Mar 2013 00:04:43 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2L04hlm028346; Thu, 21 Mar 2013 00:04:43 GMT (envelope-from linimon) Date: Thu, 21 Mar 2013 00:04:43 GMT Message-Id: <201303210004.r2L04hlm028346@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 00:04:44 -0000 Old Synopsis: igb drops ethernet ports 2 and 3 New Synopsis: [igb] igb drops ethernet ports 2 and 3 Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 21 00:04:05 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177139 From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 00:20:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8129F922 for ; Thu, 21 Mar 2013 00:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 59A47D27 for ; Thu, 21 Mar 2013 00:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2L0K010031282 for ; Thu, 21 Mar 2013 00:20:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2L0K0M9031281; Thu, 21 Mar 2013 00:20:00 GMT (envelope-from gnats) Date: Thu, 21 Mar 2013 00:20:00 GMT Message-Id: <201303210020.r2L0K0M9031281@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: "Vogel, Jack" Subject: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "Vogel, Jack" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 00:20:01 -0000 The following reply was made to PR kern/177139; it has been noted by GNATS. From: "Vogel, Jack" To: "bug-followup@FreeBSD.org" , "david@dr.eclipse.co.uk" Cc: Subject: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Date: Thu, 21 Mar 2013 00:17:03 +0000 --_000_BC1B13FD0226B0479C795193AC1B25721CA94605ORSMSX108amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please provide more details, are the ports described as 'dropped' just losi= ng link, or some other symptoms as well. Also, is there any different in t= he link-partner between the sets of ports? Is the activity different, etc..= . Jack --_000_BC1B13FD0226B0479C795193AC1B25721CA94605ORSMSX108amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please provide more details, are the ports described= as ‘dropped’ just losing link, or some other symptoms as well.=   Also, is there any different in the link-partner between the sets of= ports? Is the activity different, etc…

 

Jack

 

--_000_BC1B13FD0226B0479C795193AC1B25721CA94605ORSMSX108amrcor_-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 01:06:41 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DD9085F5 for ; Thu, 21 Mar 2013 01:06:41 +0000 (UTC) (envelope-from markd-freebsd-net@bushwire.net) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id 936A7E93 for ; Thu, 21 Mar 2013 01:06:40 +0000 (UTC) Received: (qmail 98715 invoked by uid 1001); 21 Mar 2013 00:59:59 -0000 Delivered-To: qmda-intercept-freebsd-net@FreeBSD.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=2004; d=bushwire.net; b=5VKch5Qe/4PKKnpod3DpMPME5+sPBbTwUfAZT6sSmt+8mPfLWnjP8/z3lC3Nk4D9; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=10; b=25; l=C18R71D32M65F47T27S69M17C39C27; Comments: QMDA 0.3 Received: (qmail 98707 invoked by uid 1001); 21 Mar 2013 00:59:59 -0000 Date: 21 Mar 2013 00:59:59 +0000 Message-ID: <20130321005959.98706.qmail@f5-external.bushwire.net> From: "Mark D" To: freebsd-net@FreeBSD.org Subject: Best way for an app to accept traffic on 30,000+ interfaces? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 01:06:41 -0000 (Hopefully this isn't too out-of-scope for this list..) I have an application in mind that I'd like to have accept/respond to UDP queries sent to perhaps 30K contiguous IP addresses (most likely IPV6 addresses because such ranges are easy to come by, but conceptually ipv4 as well). This would all be on a small number of FBSD instances. Though it could be done, I don't really want to create 30K interfaces and have the application bind 30K sockets as it's not clear if that will scale if I try an address range that expands to, say, 1M IPs wide. This address range would be internet-facing and responding to random remote clients. My first thought is to use SOCK_RAW in much the same way that natd does - at least to receive the traffic. Is that a sensible and viable approach or is there a better/easier way? Mark. From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 02:14:06 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 576BAEF3 for ; Thu, 21 Mar 2013 02:14:06 +0000 (UTC) (envelope-from markd-freebsd-net@bushwire.net) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id 0A5A1120 for ; Thu, 21 Mar 2013 02:14:05 +0000 (UTC) Received: (qmail 98970 invoked by uid 1001); 21 Mar 2013 02:14:04 -0000 Delivered-To: qmda-intercept-freebsd-net@FreeBSD.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=2004; d=bushwire.net; b=4onIC8ERdOjI6nDt30lJrVNSv44idZQ6g5q1xaABK+OlZE1T0UE+NN76jLJec5of; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=13; b=17; l=C18R71D32M65F47T27S73R65?69M17C39C27I81; Comments: QMDA 0.3 Received: (qmail 98963 invoked by uid 1001); 21 Mar 2013 02:14:04 -0000 Date: 21 Mar 2013 02:14:04 +0000 Message-ID: <20130321021404.98962.qmail@f5-external.bushwire.net> From: "Mark D" To: freebsd-net@FreeBSD.org Subject: Re: Best way for an app to accept traffic on 30,000+ interfaces? References: <20130321005959.98706.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 02:14:06 -0000 On 20Mar13, Juli Mallett allegedly wrote: > Well, the easiest thing is to add 30k aliases to your Ethernet > interface (you may hit a limit, not sure) and then just listen on > INADDR_ANY (or the IP6 equivalent), assuming you don't mind listening > to other addresses you have configured as well. The application can > always decide to close an incoming connection that wasn't going to one > of those 30k IP addresses. Agreed that INADDR_ANY will fix the socket count. But what of the interface/alias count? Is 300K ok? How about 3M aliases? I'll spin up an instance and try it out, but I'm a little worried that there might be something non-linear or some threshold limit that won't necessarily be exposed by a modicum of adhoc testing. Mark. From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 08:31:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA22B36C for ; Thu, 21 Mar 2013 08:31:30 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 6E725217 for ; Thu, 21 Mar 2013 08:31:30 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id a22so1252766qcs.40 for ; Thu, 21 Mar 2013 01:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HpPqEyNitrfPXeWuBQ98GTawQg8Xc5almegC8LJeHLY=; b=gfeQZmu6DAOtfa8098zPm2juf48FtqukEpu2FJM1FHb+yjI33/X1QYMkDQm1NEaZ/G 8qIbqg64NTr/zoWQtFOzBQ9z68lFojEqHuAmluH8Jw0gp/bil9C14BU/N+HnRYx73wNq MfHUPQQBXLF5HImupI5w43JjZpHkPhQuCCGg5app2iO67zBNe4uBn95XqfdWSX0TMbEN OVKuTCHWNNR0OL7caNlEDgR7J6VAY03w7CqUxEkAR7rywk2ix0MGydteUa4jpijBj+WL AfY1wxYhQCXzBidbaWq3h3hrcbDH9MhjHx0Zn7/5SvYL+wBCyDlvFnIliNCaZGkHPr31 5Zhg== MIME-Version: 1.0 X-Received: by 10.49.30.70 with SMTP id q6mr6025460qeh.28.1363854316589; Thu, 21 Mar 2013 01:25:16 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.98.103 with HTTP; Thu, 21 Mar 2013 01:25:16 -0700 (PDT) In-Reply-To: <20130321005959.98706.qmail@f5-external.bushwire.net> References: <20130321005959.98706.qmail@f5-external.bushwire.net> Date: Thu, 21 Mar 2013 09:25:16 +0100 X-Google-Sender-Auth: WqpwJo1177_PGbU3R5naCqjrCUg Message-ID: Subject: Re: Best way for an app to accept traffic on 30,000+ interfaces? From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Mark D Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 08:31:30 -0000 On Thu, Mar 21, 2013 at 1:59 AM, Mark D wrote: > (Hopefully this isn't too out-of-scope for this list..) > > I have an application in mind that I'd like to have accept/respond to > UDP queries sent to perhaps 30K contiguous IP addresses (most likely > IPV6 addresses because such ranges are easy to come by, but > conceptually ipv4 as well). > > This would all be on a small number of FBSD instances. > > Though it could be done, I don't really want to create 30K interfaces > and have the application bind 30K sockets as it's not clear if that > will scale if I try an address range that expands to, say, 1M IPs > wide. > > This address range would be internet-facing and responding to random > remote clients. > > My first thought is to use SOCK_RAW in much the same way that natd > does - at least to receive the traffic. > > Is that a sensible and viable approach or is there a better/easier > way? > > > Mark. > _______________________________________________ > 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" > How about firing up one of the firewall/pfil(9) consumers like (ipfw/pf) and adding rules to redirect traffic to a socket bound on loopback? -- Ermal From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 11:40:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07BD8966 for ; Thu, 21 Mar 2013 11:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id ED08EF7D for ; Thu, 21 Mar 2013 11:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2LBe1wv059909 for ; Thu, 21 Mar 2013 11:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2LBe1wP059908; Thu, 21 Mar 2013 11:40:01 GMT (envelope-from gnats) Date: Thu, 21 Mar 2013 11:40:01 GMT Message-Id: <201303211140.r2LBe1wP059908@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: david@dr.eclipse.co.uk Subject: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: david@dr.eclipse.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 11:40:02 -0000 The following reply was made to PR kern/177139; it has been noted by GNATS. From: david@dr.eclipse.co.uk To: "Vogel Jack" , bug-followup@FreeBSD.org Cc: Subject: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Date: Thu, 21 Mar 2013 11:02:49 +0000 --=_839ebb776a4668cec96eeb4f50d4c37a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0=0A=0A Hi Jack,=0A=0AIn dmesg and /var/log/messages we see=0A=0Aig= b2: link state changed to UP=0Aigb2: link state changed to DOWN=0A=C2=A0= =0Aifconfig reports=0A=0A=C2=A0igb2: flags=3D8c02 metric 0 mtu 1500=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 options=3D401bb=0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ether bc:30:5b:f6:12:de=0A=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet6 fe80::be30:5bff:fef6:12de%igb2 pref= ixlen 64=0Ascopeid 0x3=0A=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet= 192.168.179.134 netmask 0xffffff00 broadcast=0A192.168.179.255=0A=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 nd6 options=3D29=0A=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 media: Ethernet 1000baseT (autoselect)=0A= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status: no carrier=0A=0AThis= interface is being used exclusively for Postgresql database=0Areplicati= on from one server to another.=0ABoth servers do the same.=C2=A0 They ca= n stay up for anything from a few=0Aminutes to a few hours but always di= e.=0AOne major difference is that the two interfaces are connected with= a=0Acrossover (also tried straight through) cable.=0AThis is a configur= ation we have been using with great success for a=0Anumber of years with= broadcom adapters.=0AOpted for the Intel card on these servers as we ha= d trouble with the=0Alatest broadcom drivers. =0AI have tried disabling= msix as I read this could possibly help and=0Aalso tried disabling auto= select and manually configuring the=0Ainterfaces.=0ANone of these have h= elped.=C2=A0 igb0 and igb1 are connect to switches=0Aand have been stabl= e.=0ASo at the moment I have created a vlan on one of our switches and= =0Ahave plugged both servers into these vlan ports and they have=0Aremai= ned up over night.=0ACould it be that this network card does not like di= rect connections=0Aand is looking for a switch?=0A=0ADavid=0A=0A----- Or= iginal Message -----=0AFrom: "Vogel Jack" =0ATo:"bug-followup@FreeBSD.or= g" , "david@dr.eclipse.co.uk" =0ACc:=0ASent:Thu, 21 Mar 2013 00:17:03 +0= 000=0ASubject:Re: kern/177139: [igb] igb drops ethernet ports 2 and 3=0A= =0A=09Please provide more details, are the ports described as=0A=E2=80= =98dropped=E2=80=99 just losing link, or some other symptoms as well.=C2= =A0=0AAlso, is there any different in the link-partner between the sets= of=0Aports? Is the activity different, etc=E2=80=A6=0A=0A=09=C2=A0=0A= =0A=09Jack=0A=0A=09=C2=A0=0A=0A=09 --=_839ebb776a4668cec96eeb4f50d4c37a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C2=A0

=09=09Hi Jack,

In dmesg and /va= r/log/messages we see

igb2: link state changed to UP
igb= 2: link state changed to DOWN
=C2=A0
ifconfig reports
=C2=A0igb2: flags=3D8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> m= etric 0 mtu 1500
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 options= =3D401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,= TSO4,VLAN_HWTSO>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ethe= r bc:30:5b:f6:12:de
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet= 6 fe80::be30:5bff:fef6:12de%igb2 prefixlen 64 scopeid 0x3
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet 192.168.179.134 netmask 0xffffff0= 0 broadcast 192.168.179.255
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 media: Ethernet 1000baseT <= ;full-duplex> (autoselect)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 status: no carrier

This interface is being used exclus= ively for Postgresql database replication from one server to another.Both servers do the same.=C2=A0 They can stay up for anything from a= few minutes to a few hours but always die.
One major difference is= that the two interfaces are connected with a crossover (also tried stra= ight through) cable.
This is a configuration we have been using wit= h great success for a number of years with broadcom adapters.
Opted= for the Intel card on these servers as we had trouble with the latest b= roadcom drivers.
I have tried disabling msix as I read this could= possibly help and also tried disabling autoselect and manually configur= ing the interfaces.
None of these have helped.=C2=A0 igb0 and igb1= are connect to switches and have been stable.
So at the moment I h= ave created a vlan on one of our switches and have plugged both servers= into these vlan ports and they have remained up over night.
Could= it be that this network card does not like direct connections and is lo= oking for a switch?

David

----- Origin= al Message -----
From:
"Vogel Jack" <jack.= vogel@intel.com>

To:"bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>, "david@dr.= eclipse.co.uk" <david@dr.eclipse.co.uk>
Cc:

Sent:
T= hu, 21 Mar 2013 00:17:03 +0000
Sub= ject:
Re: kern/177139: [igb] igb drops ethernet ports 2 and 3
=

=0A

Please= provide more details, are the ports described as =E2=80=98dropped=E2=80= =99 just losing link, or some other symptoms as well.=C2=A0 Also, is the= re any different in the link-partner between the sets of ports? Is the a= ctivity different, etc=E2=80=A6

=0A

=C2=A0

=0A

Jack

<= /p>=0A

=C2=A0

=0A
=0A=0A=0A= =0A
--=_839ebb776a4668cec96eeb4f50d4c37a-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 13:02:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 634626FD for ; Thu, 21 Mar 2013 13:02:50 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from us3.route.mx (us3.route.mx [107.21.107.127]) by mx1.freebsd.org (Postfix) with ESMTP id 214396C7 for ; Thu, 21 Mar 2013 13:02:49 +0000 (UTC) Received: (route-mx 75847 invoked from network); 21 Mar 2013 13:02:49 -0000 Received: from unknown (HELO nbari-z200.diz.la) (nbari@inbox.im@route.mx) (envelope-sender ) by us3.route.mx (route-mx) with SMTP for ; 21 Mar 2013 13:02:48 -0000 Message-ID: <514B04F5.5010603@inbox.im> Date: Thu, 21 Mar 2013 13:02:45 +0000 From: Nicolas de Bari Embriz Garcia Rojas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: netstat -ib Obytes empty for alias on main interface Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 13:02:50 -0000 Hi all, I want to know the total of bytes in and out of each IP address assigned as an alias to an bce0 interlace. if I run netstat -ib I get something like this: > netstat -ib Name Mtu Network Address Ipkts Ierrs Idrop Ibytes Opkts Oerrs Obytes Coll bce0 1500 78:2b:cb:71:aa:7f 1733163 0 0 199210984 1562794 0 339429658 0 bce0 1500 174.142.192.0 hostserver 225655 - - 33210469 1588858 - 317543703 - bce0 1500 fe80::7a2b:cb fe80::7a2b:cbff:f 0 - - 0 0 - 0 - bce0 1500 174.142.193.5 jail1 9930 - - 533577 0 - 0 - bce0 1500 174.142.193.5 jail2 130567 - - 269049579 0 - 0 - bce0 1500 174.142.193.5 jail3 264 - - 14072 0 - 0 - bce0 1500 174.142.193.5 jail4 978747 - - 94504639 0 - 0 - bce0 1500 174.142.193.5 jail5 329095 - - 117322843 0 - 0 - bce0 1500 174.142.193.5 jail6 260 - - 13998 0 - 0 - bce0 1500 72.55.175.68/ jail7 141953 - - 45070407 0 - 0 - ... ... lo1 16384 424903 0 0 30341272 424880 0 30338825 0 lo1 16384 172.16.13.0 172.16.13.1 30415 - - 2173077 30361 - 2172801 - lo1 16384 172.16.13.2/3 172.16.13.2 104842 - - 8848322 40993 - 3957589 - lo1 16384 172.16.13.3/3 172.16.13.3 8696 - - 351244 8668 - 349132 - lo1 16384 172.16.13.30/ 172.16.13.30 344856 - - 23862253 344856 - 23862253 - I only have Input bytes per IP but not Obytes for the alias on bce0 but I do have the Ibytes and Obytes for the lo1 cloned interface, also any idea of how to avoid truncating the output, the network IP's display part of the IP not the full address, my idea is to use this output to create some stats. Any ideas ? thanks in advance. regards. From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 13:08:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 559FFC20; Thu, 21 Mar 2013 13:08:15 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id 1E09273C; Thu, 21 Mar 2013 13:08:15 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id 17so3460125iea.12 for ; Thu, 21 Mar 2013 06:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=cpT2n620NPhcrz2FOQIY0KopkJ4qmITZT4dx/hHIDQY=; b=Dg07TDP8wAtaG0X5QURBw4twLHFknjuwMrdAizToes38VU63ux7pf8FdlnpYWX6Y9k z1dVmX5YTEH6RalkxRzJPmlkIKHTfma13WJ+XVaZvAqQh+2iLsXEjK+yneeUB0WHQxSR Qal3Cdm5rMWOrUVcB8qwJbiwdTaWA1AD6/GE56w0WbQxK/3mCyQdkJxWtvg3OsxvuXL+ JjKtGOV+JUZdpQER/X6lT3U1oQxpuk4o14Ua1idZ5zU26THiE+m/MeoLGYG3NkrfRkVp Y922RQKI8+Ed+yce9ERWzIgla2menaMnJUs89Cxx5mlhQivVUE1XbkuBAJUzkG1S8AKw 5oSw== X-Received: by 10.50.181.134 with SMTP id dw6mr2030366igc.68.1363871294843; Thu, 21 Mar 2013 06:08:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.106.161 with HTTP; Thu, 21 Mar 2013 06:07:54 -0700 (PDT) In-Reply-To: References: <20130321005959.98706.qmail@f5-external.bushwire.net> From: Michael MacLeod Date: Thu, 21 Mar 2013 09:07:54 -0400 Message-ID: Subject: Re: Best way for an app to accept traffic on 30,000+ interfaces? To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 13:08:15 -0000 Ermal is probably on the right track. Working in a load balanced environment I've personally done three contiguous /20 blocks using three loopback interfaces on linux hosts. I'd imagine that FreeBSD should behave similarly. The only fancy thing the load balancer did was as packets destined for one of the VIPs, it would forward the packet to one of the linux hosts at layer 2, but wouldn't touch the layer 3 headers at all, preserving that information. The host would see the VIP address, and respond from it, because it existed on the loopback interface. It worked well - you'll have to recreate similar behaviour in your network. We did entire groups of contiguous /64 blocks in IPv6 in the same way. On Thu, Mar 21, 2013 at 4:25 AM, Ermal Lu=E7i wrote: > On Thu, Mar 21, 2013 at 1:59 AM, Mark D w= rote: > >> (Hopefully this isn't too out-of-scope for this list..) >> >> I have an application in mind that I'd like to have accept/respond to >> UDP queries sent to perhaps 30K contiguous IP addresses (most likely >> IPV6 addresses because such ranges are easy to come by, but >> conceptually ipv4 as well). >> >> This would all be on a small number of FBSD instances. >> >> Though it could be done, I don't really want to create 30K interfaces >> and have the application bind 30K sockets as it's not clear if that >> will scale if I try an address range that expands to, say, 1M IPs >> wide. >> >> This address range would be internet-facing and responding to random >> remote clients. >> >> My first thought is to use SOCK_RAW in much the same way that natd >> does - at least to receive the traffic. >> >> Is that a sensible and viable approach or is there a better/easier >> way? >> >> >> Mark. >> _______________________________________________ >> 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" >> > > > How about firing up one of the firewall/pfil(9) consumers like (ipfw/pf) > and adding rules to redirect traffic to a socket bound on loopback? > > -- > Ermal > _______________________________________________ > 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 Mar 21 13:25:49 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21B64578; Thu, 21 Mar 2013 13:25:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EFA47871; Thu, 21 Mar 2013 13:25:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2LDPm1w081358; Thu, 21 Mar 2013 13:25:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2LDPmeR081357; Thu, 21 Mar 2013 13:25:48 GMT (envelope-from linimon) Date: Thu, 21 Mar 2013 13:25:48 GMT Message-Id: <201303211325.r2LDPmeR081357@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177184: [bge] [patch] enable wake on lan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 13:25:49 -0000 Old Synopsis: patch for bge network driver to enable wake on lan New Synopsis: [bge] [patch] enable wake on lan Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Mar 21 13:25:19 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177184 From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 13:54:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1A8A32F5 for ; Thu, 21 Mar 2013 13:54:19 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id AB7D4A6F for ; Thu, 21 Mar 2013 13:54:18 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hm6so3095739wib.14 for ; Thu, 21 Mar 2013 06:54:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QRzs2kZi6LtubNKYlAyLAv57/tApI1pbq+PWtkixyfA=; b=aYxjgK19GH+QzsDHh/K+8G37tYDyGh+iycO2XnBlBM+ZhdOwkPY5eVDI98+sOk2IKc iFu/dI0RTa3LKnVd01hoGcCScbgD3kzJcz3uYH/6Ft9qtoCHdk582WNdRtepNvF8Rskk 0koSdOgdyNWo1W9VNMxGPYQnXZDE8BXrDUk5WmdoD9gHKOegJ36ybqGLQwxoio2hIP2v 6dCEmcjcOtCbMKyG/rZN3U4hPTgQGWF4OnPrxrGFhnEWn7wOC2GBb3FO1yOpv7De1o8j UIZ0hV4Lqe1dpQaeSA3F/7yLl2ftNI3WeRPIhMMmkc53vEGVE7nzGrXykOkq2+OcGPWW pOow== X-Received: by 10.194.109.136 with SMTP id hs8mr17547841wjb.8.1363874057915; Thu, 21 Mar 2013 06:54:17 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id g4sm5396975wib.11.2013.03.21.06.54.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 06:54:17 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Best way for an app to accept traffic on 30,000+ interfaces? From: Fleuriot Damien In-Reply-To: Date: Thu, 21 Mar 2013 14:54:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96327F03-86EC-4EE6-9679-F66A960BDDB4@my.gd> References: <20130321005959.98706.qmail@f5-external.bushwire.net> To: =?iso-8859-1?Q?Ermal_Lu=E7i?= X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlj8KyGvn+4g9UdzvbQZ51HUepITbo0HVfACPEN/KGyuw/C7pjSv1FSrvT85wcG13UAtBy5 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 13:54:19 -0000 On Mar 21, 2013, at 9:25 AM, Ermal Lu=E7i wrote: > On Thu, Mar 21, 2013 at 1:59 AM, Mark D = wrote: >=20 >> (Hopefully this isn't too out-of-scope for this list..) >>=20 >> I have an application in mind that I'd like to have accept/respond to >> UDP queries sent to perhaps 30K contiguous IP addresses (most likely >> IPV6 addresses because such ranges are easy to come by, but >> conceptually ipv4 as well). >>=20 >> This would all be on a small number of FBSD instances. >>=20 >> Though it could be done, I don't really want to create 30K interfaces >> and have the application bind 30K sockets as it's not clear if that >> will scale if I try an address range that expands to, say, 1M IPs >> wide. >>=20 >> This address range would be internet-facing and responding to random >> remote clients. >>=20 >> My first thought is to use SOCK_RAW in much the same way that natd >> does - at least to receive the traffic. >>=20 >> Is that a sensible and viable approach or is there a better/easier >> way? >>=20 >>=20 >> Mark. >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>=20 >=20 >=20 > How about firing up one of the firewall/pfil(9) consumers like = (ipfw/pf) > and adding rules to redirect traffic to a socket bound on loopback? >=20 > --=20 > Ermal I fail to see how that's different from what I suggested with PF's rdr = rule ? From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 13:57:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3CBB352A for ; Thu, 21 Mar 2013 13:57:13 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by mx1.freebsd.org (Postfix) with ESMTP id 01B85A9C for ; Thu, 21 Mar 2013 13:57:12 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id a11so1788194qen.5 for ; Thu, 21 Mar 2013 06:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PiRkDsAgric+9o+oGLMTiuGX/xBHWmNUVK/co/yZLg0=; b=LpSALldtXG2UG3vzaM8nGKonEaSeF/l1Smoap4OD55trlduNCr9aqhCIlXtQOnRR30 TpzpfZ8PKfuvcKzNa/P6hC2yfc/3i2hhpqRbkO3YQQInIyFVwEjTjU9+bKpD1AdUPVtW G9t6rX3r3LvrGp4NglX360P+BNZBE4hBrWSAWLA4tn4NUBPK07G21VOV0zoncfvIjWnh 3NezDJ0beW/lU4EcXfG32UHyr4RYxQd9L0yExmmdR/hUFziHKffIDWnsGJS+x2QJbaSE +5q/8HZcdnkXAUpgQvsXFEd2DdWqxtF5c9tRYwuQNwrh3zWWpsWzMB7+s7fQvseRM6eQ QJSg== MIME-Version: 1.0 X-Received: by 10.49.25.12 with SMTP id y12mr8989978qef.1.1363874226153; Thu, 21 Mar 2013 06:57:06 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.98.103 with HTTP; Thu, 21 Mar 2013 06:57:06 -0700 (PDT) In-Reply-To: <96327F03-86EC-4EE6-9679-F66A960BDDB4@my.gd> References: <20130321005959.98706.qmail@f5-external.bushwire.net> <96327F03-86EC-4EE6-9679-F66A960BDDB4@my.gd> Date: Thu, 21 Mar 2013 14:57:06 +0100 X-Google-Sender-Auth: 5Y8n3icMM4eITLNNmk7sjFBZLDM Message-ID: Subject: Re: Best way for an app to accept traffic on 30,000+ interfaces? From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Fleuriot Damien Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 13:57:13 -0000 On Thu, Mar 21, 2013 at 2:54 PM, Fleuriot Damien wrote: > > On Mar 21, 2013, at 9:25 AM, Ermal Lu=E7i wrote: > > > On Thu, Mar 21, 2013 at 1:59 AM, Mark D >wrote: > > > >> (Hopefully this isn't too out-of-scope for this list..) > >> > >> I have an application in mind that I'd like to have accept/respond to > >> UDP queries sent to perhaps 30K contiguous IP addresses (most likely > >> IPV6 addresses because such ranges are easy to come by, but > >> conceptually ipv4 as well). > >> > >> This would all be on a small number of FBSD instances. > >> > >> Though it could be done, I don't really want to create 30K interfaces > >> and have the application bind 30K sockets as it's not clear if that > >> will scale if I try an address range that expands to, say, 1M IPs > >> wide. > >> > >> This address range would be internet-facing and responding to random > >> remote clients. > >> > >> My first thought is to use SOCK_RAW in much the same way that natd > >> does - at least to receive the traffic. > >> > >> Is that a sensible and viable approach or is there a better/easier > >> way? > >> > >> > >> Mark. > >> _______________________________________________ > >> 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" > >> > > > > > > How about firing up one of the firewall/pfil(9) consumers like (ipfw/pf= ) > > and adding rules to redirect traffic to a socket bound on loopback? > > > > -- > > Ermal > > > I fail to see how that's different from what I suggested with PF's rdr > rule ? > > I never saw the e-mail in this thread! --=20 Ermal From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 13:59:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BDAAA707 for ; Thu, 21 Mar 2013 13:59:13 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 56251AD6 for ; Thu, 21 Mar 2013 13:59:13 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so1897743wgb.4 for ; Thu, 21 Mar 2013 06:59:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=0KUsTyXzDcs9HwzEO6cADsP/zYUmv0ws0FMQs2gJIQg=; b=SvpyBGr3tjEpxFXxzZUQQvlHurfJmt0tGTJro5oSGK3ZLZWEWax88MfNr7SMteaSQd CvpMa5xJq1oPssRkX5cO02nPgrIZRax0hPXb312FuyRioYQ0aZn9Id46tV4K9bmGjaml vQf1CDO6x/QBlyuc8nKaqm0+wDZaGAl327i8gl68G/mK2p05enecT7CyGnNbnoFZdfuf /aZ7jXIYE0f7F5UUXhusXq8eWxllxZLqC83jHAqyvgnpmR5FARX1OxthItzMFifw9tWQ qbaYJa0u88iVlTmOE94HoKfzEnsuuCKsvE1vayoKAmOOy5AuPWamn1ulwMIMYUabA5DG t7Qg== X-Received: by 10.180.79.227 with SMTP id m3mr4949840wix.12.1363874351902; Thu, 21 Mar 2013 06:59:11 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ex15sm4870646wid.5.2013.03.21.06.59.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Mar 2013 06:59:11 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Best way for an app to accept traffic on 30,000+ interfaces? From: Fleuriot Damien In-Reply-To: Date: Thu, 21 Mar 2013 14:59:03 +0100 Message-Id: References: <20130321005959.98706.qmail@f5-external.bushwire.net> <96327F03-86EC-4EE6-9679-F66A960BDDB4@my.gd> To: =?iso-8859-1?Q?Ermal_Lu=E7i?= X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkBwZYVvq2rwaS2Mqo+hVWrw5r520VI5R5YQqNqoaUJJdEha2xiEl/VLqDLFKCr8xIKimic Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 13:59:13 -0000 On Mar 21, 2013, at 2:57 PM, Ermal Lu=E7i wrote: >=20 >=20 >=20 > On Thu, Mar 21, 2013 at 2:54 PM, Fleuriot Damien wrote: >=20 > On Mar 21, 2013, at 9:25 AM, Ermal Lu=E7i wrote: >=20 > > On Thu, Mar 21, 2013 at 1:59 AM, Mark D = wrote: > > > >> (Hopefully this isn't too out-of-scope for this list..) > >> > >> I have an application in mind that I'd like to have accept/respond = to > >> UDP queries sent to perhaps 30K contiguous IP addresses (most = likely > >> IPV6 addresses because such ranges are easy to come by, but > >> conceptually ipv4 as well). > >> > >> This would all be on a small number of FBSD instances. > >> > >> Though it could be done, I don't really want to create 30K = interfaces > >> and have the application bind 30K sockets as it's not clear if that > >> will scale if I try an address range that expands to, say, 1M IPs > >> wide. > >> > >> This address range would be internet-facing and responding to = random > >> remote clients. > >> > >> My first thought is to use SOCK_RAW in much the same way that natd > >> does - at least to receive the traffic. > >> > >> Is that a sensible and viable approach or is there a better/easier > >> way? > >> > >> > >> Mark. > >> _______________________________________________ > >> 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" > >> > > > > > > How about firing up one of the firewall/pfil(9) consumers like = (ipfw/pf) > > and adding rules to redirect traffic to a socket bound on loopback? > > > > -- > > Ermal >=20 >=20 > I fail to see how that's different from what I suggested with PF's rdr = rule ? >=20 > I never saw the e-mail in this thread!=20 Find below a copy of the text I posted : =3D=3D Use PF ? :p Rdr quick on $wan inet6 proto udp from any to 2001:1234::1/120 port = 12345 tag uwin -> ::1 Pass in quick on $wan inet6 proto udp tagged $uwin That's a bit dirty though, using PAT on ip6... =3D=3D Here you go. =46rom what I understand, that would be pretty similar to what you = suggested, aye ? From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 15:23:30 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB52290A for ; Thu, 21 Mar 2013 15:23:30 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe17.ukr.net (ffe17.ukr.net [195.214.192.83]) by mx1.freebsd.org (Postfix) with ESMTP id AA26F197 for ; Thu, 21 Mar 2013 15:23:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=+OJIAW+owwUn2RSVdQ+h/EAqMwSve1x2h+IciPXEByA=; b=em83IuYzwW6tjEQ8T9uTE0Imx7UFA9WfPQrloC///JvM7JQFgXMUfsRH9E+M8yNC6HDnu8+LwcUdg78xfJq4dkRzt2bFiwZb65DlIUyIFwg+Jrf4GreMOfK44EznZ2XYO5dQqXn6T49Kyob4qSB1yMuDCcvHBNvY9fTuJNgiJBM=; Received: from mail by ffe17.ukr.net with local ID 1UIh4a-000HTD-5N for net@freebsd.org; Thu, 21 Mar 2013 17:06:32 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Quagga not support password for neighbor To: "net@freebsd.org" From: "Vladislav Prodan" X-Mailer: freemail.ukr.net 4.0 Message-Id: <66067.1363878392.12938546996697300992@ffe17.ukr.net> Date: Thu, 21 Mar 2013 17:06:32 +0200 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 15:23:31 -0000 FreeBSD 8.2-STABLE quagga-0.99.21 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software BGP.as11111(config-router)# neighbor XXX.XXX.YYY.YYY password testtest % Error while applying TCP-Sig to session(s) No one to share the patch with the Linux version of quagga, so get to work option password? Thanks! -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 15:52:45 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6CDF4A5D for ; Thu, 21 Mar 2013 15:52:45 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 336A1395 for ; Thu, 21 Mar 2013 15:52:45 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id a22so1466465qcs.40 for ; Thu, 21 Mar 2013 08:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TGsmLGysDL+6BK/usfs56uE/cIXMMjLiBEV8lnXLeZY=; b=RBsyL9xeJqcYKh+HwByZn++rW+zy6dWAA+5rTW0EbDgbgy25SQZbJT5UP6fIuKaYbj T8uvrEO/OQB2GyFtXkpHk/2e7RQW4DJDM9CaAPjUNI5JxV7nyuAyKymlucOQdHmD81NJ E6WBX8MakvsecfphKZuDxg+AERGNoZT4pAMRMoReyaW3xVCQMEDM2FN4upIb3AAWkNbh 5hfMkYJhtlIJ4dESuwjEcDyzfAjMb264/6RKxHsaUbAroa2suEUUS5b0LKEwVpvf2Me3 qxs+qjUBB9xmC4jXoRrT1tSifAr5x6rL5dsHGqw0grDKfsHm5a3s9k7GezYF8hDul64C Jl2g== MIME-Version: 1.0 X-Received: by 10.49.30.70 with SMTP id q6mr7348804qeh.28.1363881164790; Thu, 21 Mar 2013 08:52:44 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.49.98.103 with HTTP; Thu, 21 Mar 2013 08:52:44 -0700 (PDT) In-Reply-To: <66067.1363878392.12938546996697300992@ffe17.ukr.net> References: <66067.1363878392.12938546996697300992@ffe17.ukr.net> Date: Thu, 21 Mar 2013 16:52:44 +0100 X-Google-Sender-Auth: h4evPjfmPwWvgAHWVlnH5p_BgO0 Message-ID: Subject: Re: Quagga not support password for neighbor From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Vladislav Prodan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 15:52:45 -0000 You need a kernel with TCP_SIGNATURE option and insert policy routes with setkey. On Thu, Mar 21, 2013 at 4:06 PM, Vladislav Prodan wrote: > > FreeBSD 8.2-STABLE > quagga-0.99.21 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software > > BGP.as11111(config-router)# neighbor XXX.XXX.YYY.YYY password testtest > % Error while applying TCP-Sig to session(s) > > No one to share the patch with the Linux version of quagga, so get to work > option password? > > Thanks! > > -- > Vladislav V. Prodan > System & Network Administrator > http://support.od.ua > +380 67 4584408, +380 99 4060508 > VVP88-RIPE > _______________________________________________ > 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" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 16:07:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A437F291 for ; Thu, 21 Mar 2013 16:07:17 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from eu.route.mx (eu.route.mx [46.137.95.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1B6416AC for ; Thu, 21 Mar 2013 16:07:16 +0000 (UTC) Received: (route-mx 36092 invoked from network); 21 Mar 2013 16:07:16 -0000 Received: from unknown (HELO nbari-z200.diz.la) (nbari@inbox.im@[194.65.5.235]) (envelope-sender ) by eu.route.mx (route-mx) with SMTP for ; 21 Mar 2013 16:07:15 -0000 Message-ID: <514B3032.1070205@inbox.im> Date: Thu, 21 Mar 2013 16:07:14 +0000 From: Nicolas de Bari Embriz Garcia Rojas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130314 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: netstat -ib Obytes empty for alias on main interface References: <514B04F5.5010603@inbox.im> In-Reply-To: <514B04F5.5010603@inbox.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 16:07:17 -0000 Here is the output with a better formatting: http://pastebin.com/arrRsM78 What I would like to understand is why lo1 shows Obytes (incrementing) while bce0 IP's don't lo1 is a using NAT also the sum of lo1 (not including the Hi all, I want to know the total of bytes in and out of each IP address > assigned as an alias to an bce0 interlace. > > if I run netstat -ib I get something like this: >> netstat -ib > Name Mtu Network Address Ipkts Ierrs Idrop > Ibytes Opkts Oerrs Obytes Coll > bce0 1500 78:2b:cb:71:aa:7f 1733163 0 0 > 199210984 1562794 0 339429658 0 > bce0 1500 174.142.192.0 hostserver 225655 - > - 33210469 1588858 - 317543703 - > bce0 1500 fe80::7a2b:cb fe80::7a2b:cbff:f 0 - > - 0 0 - > 0 - > bce0 1500 174.142.193.5 jail1 9930 > - - 533577 0 - > 0 - > bce0 1500 174.142.193.5 jail2 130567 - > - 269049579 0 - 0 - > bce0 1500 174.142.193.5 jail3 264 > - - 14072 0 - > 0 - > bce0 1500 174.142.193.5 jail4 978747 - > - 94504639 0 - 0 - > bce0 1500 174.142.193.5 jail5 329095 - > - 117322843 0 - 0 - > bce0 1500 174.142.193.5 jail6 260 > - - 13998 0 - > 0 - > bce0 1500 72.55.175.68/ jail7 141953 - > - 45070407 0 - 0 - > ... > ... > lo1 16384 424903 > 0 0 30341272 424880 0 30338825 0 > lo1 16384 172.16.13.0 172.16.13.1 30415 - - > 2173077 30361 - 2172801 - > lo1 16384 172.16.13.2/3 172.16.13.2 104842 - - > 8848322 40993 - 3957589 - > lo1 16384 172.16.13.3/3 172.16.13.3 8696 - > - 351244 8668 - 349132 - > lo1 16384 172.16.13.30/ 172.16.13.30 344856 - > - 23862253 344856 - 23862253 - > > > I only have Input bytes per IP but not Obytes for the alias on bce0 but > I do have the Ibytes and Obytes for the lo1 cloned interface, also any > idea of how to avoid truncating the output, the network IP's display > part of the IP not the full address, my idea is to use this output to > create some stats. > > Any ideas ? > > thanks in advance. > > regards. > > > > From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 16:44:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F0597A8F for ; Thu, 21 Mar 2013 16:44:05 +0000 (UTC) (envelope-from sonsechang@gmail.com) Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by mx1.freebsd.org (Postfix) with ESMTP id D0214A7C for ; Thu, 21 Mar 2013 16:44:05 +0000 (UTC) Received: by mail-da0-f52.google.com with SMTP id f10so1748774dak.39 for ; Thu, 21 Mar 2013 09:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=q4f5nxVRO64jcM6CIs/Ix520gYdStlVG6CFsSPNAyx0=; b=FAHOn5KL+qJqAds0RBmhfIynClJhj21r/fGQtDe7qT9NehlU4TDZuTfyA9Ve8iNZLk nY7oOd/iQQuBEaQ9P3lGgqwMf3wk5z6MWyTUxP3fqRJ0UDYXFo4oALmXgROWYXcuKFcr Qsl2Vu2jOuugnPuxYOtvElu9yZTHeJvw0j9hxaxWEyDZOYCYh7plz3LrRYMsR43fgAX9 LooRtuKGsfc/bXA0G0ildOrCDBBvZwS82Y9hrpFheEiFG3WCYA/W927rH7T8GutEDZPm odE3yE2garWg73S/OC3MYSwEU8aEp6LHPnjVJQp8VQu7+yPe4OMEMhXplyfStabO4NZ7 CTkQ== X-Received: by 10.66.170.44 with SMTP id aj12mr15742707pac.31.1363884245566; Thu, 21 Mar 2013 09:44:05 -0700 (PDT) Received: from sson1XP ([198.95.226.240]) by mx.google.com with ESMTPS id 1sm6672703pba.32.2013.03.21.09.44.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Mar 2013 09:44:04 -0700 (PDT) From: "Sechang Son" To: "'freebsd-net'" Subject: Accessing/modifying route without lock in ip_output Date: Thu, 21 Mar 2013 09:44:02 -0700 Message-ID: <01e701ce2653$4c23f8d0$e46bea70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4mUa/Pa3aW7F7VQ+CUqZd+FJEYkA== Content-Language: en-us X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Mar 2013 16:44:06 -0000 Hi, It seems that route entry (i.e. ro->ro_rt) is read/modified without lock in ip_output. The code snippet below is from FreeBSD 10 and other releases are similar to this. Can somebody tell me why it is okay or a design decision of doing this? Appreciated in advance... 114 int 115 ip_output(struct mbuf *m, struct mbuf *opt, struct route *ro, int flags, 116 struct ip_moptions *imo, struct inpcb *inp) 117 { ... 268 if (rte == NULL) { 269 #ifdef RADIX_MPATH 270 rtalloc_mpath_fib(ro, 271 ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), 272 inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); 273 #else 274 in_rtalloc_ign(ro, 0, 275 inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); 276 #endif 277 rte = ro->ro_rt; <====== Note that ro->ro_rt is not locked here... ... 310 if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) { 311 /* 312 * This case can happen if the user changed the MTU 313 * of an interface after enabling IP on it. Because 314 * most netifs don't keep track of routes pointing to 315 * them, there is no way for one to update all its 316 * routes when the MTU is changed. 317 */ 318 if (rte->rt_rmx.rmx_mtu > ifp->if_mtu) 319 rte->rt_rmx.rmx_mtu = ifp->if_mtu; 320 mtu = rte->rt_rmx.rmx_mtu; - Sonny From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 17:10:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8D6D7348 for ; Thu, 21 Mar 2013 17:10:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 7F618D41 for ; Thu, 21 Mar 2013 17:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2LHA1mu023401 for ; Thu, 21 Mar 2013 17:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2LHA13o023400; Thu, 21 Mar 2013 17:10:01 GMT (envelope-from gnats) Date: Thu, 21 Mar 2013 17:10:01 GMT Message-Id: <201303211710.r2LHA13o023400@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Jack Vogel Subject: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jack Vogel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:10:01 -0000 The following reply was made to PR kern/177139; it has been noted by GNATS. From: Jack Vogel To: bug-followup@FreeBSD.org, david@dr.eclipse.co.uk Cc: Subject: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Date: Thu, 21 Mar 2013 10:04:14 -0700 --20cf3078114c10128504d872541e Content-Type: text/plain; charset=ISO-8859-1 So, when the igb ports are in the failing configuration what are they connected to specifically, what device/nic? There is no special procedure "looking for a switch", its just the autoneg between two devices, so maybe there is some compatibility issue. Also occurs to me that an interesting test would be to swap the two pair of devices and see if the problem follows the function or not, do you understand? Regards, Jack --20cf3078114c10128504d872541e Content-Type: text/html; charset=ISO-8859-1 So, when the igb ports are in the failing configuration what are they connected to specifically, what device/nic?

There is no special procedure "looking for a switch", its just the autoneg between two devices, so maybe there
is some compatibility issue. Also occurs to me that an interesting test would be to swap the two pair of devices
and see if the problem follows the function or not, do you understand?

Regards,

Jack

--20cf3078114c10128504d872541e-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 21 17:50:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ACFE22DA for ; Thu, 21 Mar 2013 17:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9DC26FBC for ; Thu, 21 Mar 2013 17:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r2LHo1km030869 for ; Thu, 21 Mar 2013 17:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r2LHo18r030867; Thu, 21 Mar 2013 17:50:01 GMT (envelope-from gnats) Date: Thu, 21 Mar 2013 17:50:01 GMT Message-Id: <201303211750.r2LHo18r030867@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: david@dr.eclipse.co.uk Subject: Fwd: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: david@dr.eclipse.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 17:50:02 -0000 The following reply was made to PR kern/177139; it has been noted by GNATS. From: david@dr.eclipse.co.uk To: bug-followup@FreeBSD.org Cc: Subject: Fwd: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Date: Thu, 21 Mar 2013 17:31:57 +0000 --=_0e01cef1795d0a99970a4500053df16b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is an Intel I350-t4 nic to a I350-t4 nic.=0AThe problem occurs at bot= h sides.=0ANot sure I follow your swap suggestion as both devices should= be=0Aidentical.=0A=0ADavid --=_0e01cef1795d0a99970a4500053df16b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is an Intel I350-t4 nic to a I350-t4 nic.
The proble= m occurs at both sides.
Not sure I follow your swap suggestion as b= oth devices should be identical.

David --=_0e01cef1795d0a99970a4500053df16b-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 01:26:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD447589 for ; Fri, 22 Mar 2013 01:26:47 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 88B90787 for ; Fri, 22 Mar 2013 01:26:47 +0000 (UTC) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 21 Mar 2013 18:25:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,888,1355126400"; d="scan'208,217";a="305887096" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga002.jf.intel.com with ESMTP; 21 Mar 2013 18:26:41 -0700 Received: from orsmsx108.amr.corp.intel.com (10.22.225.41) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 21 Mar 2013 18:26:40 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.213]) by ORSMSX108.amr.corp.intel.com ([169.254.9.84]) with mapi id 14.01.0355.002; Thu, 21 Mar 2013 18:26:40 -0700 From: "Pieper, Jeffrey E" To: "david@dr.eclipse.co.uk" , "freebsd-net@FreeBSD.org" Subject: RE: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Thread-Topic: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Thread-Index: AQHOJlyS5AcgYUbqtkG8ekPVMynL8Jiw6i1A Date: Fri, 22 Mar 2013 01:26:40 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65687D4639E3@ORSMSX101.amr.corp.intel.com> References: <201303211750.r2LHo18r030867@freefall.freebsd.org> In-Reply-To: <201303211750.r2LHo18r030867@freefall.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 01:26:47 -0000 What Jack means is to swap ports 0/1 with ports 2/3, so that 0/1 are B2B wi= th the other i350 and ports 2/3 are connected to the switch. Do this on bot= h sides. The reason for this is because there is a bridge between ports 0/1= and 2/3, so it is possible that the bridge is causing problems when connec= ted B2B. Jeff -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] = On Behalf Of david@dr.eclipse.co.uk Sent: Thursday, March 21, 2013 10:50 AM To: freebsd-net@FreeBSD.org Subject: Fwd: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 The following reply was made to PR kern/177139; it has been noted by GNATS. From: david@dr.eclipse.co.uk To: bug-followup@FreeBSD.org Cc: =20 Subject: Fwd: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Date: Thu, 21 Mar 2013 17:31:57 +0000 --=3D_0e01cef1795d0a99970a4500053df16b Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: quoted-printable =20 It is an Intel I350-t4 nic to a I350-t4 nic.=3D0AThe problem occurs at bot= =3D h sides.=3D0ANot sure I follow your swap suggestion as both devices should= =3D be=3D0Aidentical.=3D0A=3D0ADavid =20 --=3D_0e01cef1795d0a99970a4500053df16b Content-Type: text/html; charset=3DUTF-8 Content-Transfer-Encoding: quoted-printable =20 It is an Intel I350-t4 nic to a I350-t4 nic.
The proble= =3D m occurs at both sides.
Not sure I follow your swap suggestion as b= =3D oth devices should be identical.

David =20 --=3D_0e01cef1795d0a99970a4500053df16b-- =20 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 10:18:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 066DB904 for ; Fri, 22 Mar 2013 10:18:07 +0000 (UTC) (envelope-from walter.dedonato@unina.it) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by mx1.freebsd.org (Postfix) with ESMTP id 43E0B8B6 for ; Fri, 22 Mar 2013 10:18:06 +0000 (UTC) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r2MAG893031483 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 22 Mar 2013 11:16:09 +0100 Received: by mail-vc0-f170.google.com with SMTP id lf10so3118913vcb.29 for ; Fri, 22 Mar 2013 03:16:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.233.210 with SMTP id ty18mr1349147vec.46.1363947367845; Fri, 22 Mar 2013 03:16:07 -0700 (PDT) Received: by 10.52.53.98 with HTTP; Fri, 22 Mar 2013 03:16:07 -0700 (PDT) Date: Fri, 22 Mar 2013 11:16:07 +0100 Message-ID: Subject: Netmap ixgbe driver problem on 10Gbps X540-AT2 adapters (Linux only?) From: Walter de Donato To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 10:18:07 -0000 Dear Tahir, I've already tried to disable Rx/Tx pause and autonegotiation but the result in transmission is always the same. I did the following: $ sudo ifconfig eth2 up $ sudo ethtool -A eth2 autoneg off $ sudo ethtool -A eth2 rx off $ sudo ethtool -A eth2 tx off These are the resulting dmesg output lines: [253131.445124] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: RX/TX [253147.935426] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: TX [253163.930776] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: None Here is what I obtain: $ sudo ./pkt-gen -i eth2 -n 100000 -f tx extract_ip_range [136] extract IP range from 10.0.0.1 extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 extract_ip_range [136] extract IP range from 10.1.0.1 extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 extract_mac_range [192] a0:36:9f:0d:f0:98 starts at a0:36:9f:d:f0:98 extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1401] map size is 334980 Kb main [1423] mapping 334980 Kbytes Sending on eth2: 4 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) main [1477] Wait 2 secs for phy reset main [1479] Ready... sender_body [683] start main_thread [1078] 7155 pps (7162 pkts in 1001020 usec) main_thread [1078] 3484 pps (3488 pkts in 1001030 usec) main_thread [1078] 3487 pps (3491 pkts in 1001024 usec) main_thread [1078] 3466 pps (3469 pkts in 1000847 usec) main_thread [1078] 3485 pps (3490 pkts in 1001521 usec) main_thread [1078] 3322 pps (3328 pkts in 1001765 usec) main_thread [1078] 3293 pps (3297 pkts in 1001322 usec) main_thread [1078] 3492 pps (3498 pkts in 1001763 usec) main_thread [1078] 3485 pps (3489 pkts in 1001168 usec) main_thread [1078] 3351 pps (3356 pkts in 1001402 usec) main_thread [1078] 3297 pps (3301 pkts in 1001314 usec) main_thread [1078] 3933 pps (3938 pkts in 1001390 usec) main_thread [1078] 3481 pps (3486 pkts in 1001528 usec) main_thread [1078] 3493 pps (3497 pkts in 1001177 usec) main_thread [1078] 3310 pps (3314 pkts in 1001292 usec) main_thread [1078] 3485 pps (3491 pkts in 1001812 usec) main_thread [1078] 3326 pps (3331 pkts in 1001547 usec) main_thread [1078] 3480 pps (3485 pkts in 1001456 usec) main_thread [1078] 3489 pps (3493 pkts in 1001209 usec) main_thread [1078] 3377 pps (3381 pkts in 1001040 usec) main_thread [1078] 3450 pps (3454 pkts in 1001048 usec) main_thread [1078] 3378 pps (3382 pkts in 1001050 usec) main_thread [1078] 3470 pps (3474 pkts in 1001052 usec) main_thread [1078] 3323 pps (3327 pkts in 1001056 usec) main_thread [1078] 3482 pps (3486 pkts in 1001050 usec) main_thread [1078] 3472 pps (3476 pkts in 1001066 usec) main_thread [1078] 3497 pps (3501 pkts in 1001044 usec) main_thread [1078] 3115 pps (3115 pkts in 1000035 usec) main_thread [1078] 0 pps (0 pkts in 1001057 usec) Sent 100000 packets, 60 bytes each, in 28.42 seconds. Speed: 3.52 Kpps Bandwidth: 1.69 Mbps (raw 2.36 Mbps) While executing pkt-gen I see the following dmesg output lines: [253741.892031] ixgbe 0000:0c:00.0: eth2: Reset adapter [253742.874686] ixgbe 0000:0c:00.0: eth2: Reset adapter [253743.864635] ixgbe 0000:0c:00.0: eth2: Reset adapter [253744.854513] ixgbe 0000:0c:00.0: eth2: Reset adapter [253745.844527] ixgbe 0000:0c:00.0: eth2: Reset adapter [253746.830323] ixgbe 0000:0c:00.0: eth2: Reset adapter [253747.821223] ixgbe 0000:0c:00.0: eth2: Reset adapter [253748.813229] ixgbe 0000:0c:00.0: eth2: Reset adapter [253749.804317] ixgbe 0000:0c:00.0: eth2: Reset adapter [253750.794286] ixgbe 0000:0c:00.0: eth2: Reset adapter [253751.784302] ixgbe 0000:0c:00.0: eth2: Reset adapter [253752.774324] ixgbe 0000:0c:00.0: eth2: Reset adapter [253753.764258] ixgbe 0000:0c:00.0: eth2: Reset adapter [253754.753735] ixgbe 0000:0c:00.0: eth2: Reset adapter [253755.748011] ixgbe 0000:0c:00.0: eth2: Reset adapter [253756.734927] ixgbe 0000:0c:00.0: eth2: Reset adapter [253757.724876] ixgbe 0000:0c:00.0: eth2: Reset adapter [253758.713267] ixgbe 0000:0c:00.0: eth2: Reset adapter [253759.704793] ixgbe 0000:0c:00.0: eth2: Reset adapter [253760.694759] ixgbe 0000:0c:00.0: eth2: Reset adapter [253761.684743] ixgbe 0000:0c:00.0: eth2: Reset adapter [253762.674699] ixgbe 0000:0c:00.0: eth2: Reset adapter [253763.664642] ixgbe 0000:0c:00.0: eth2: Reset adapter [253764.654488] ixgbe 0000:0c:00.0: eth2: Reset adapter [253765.644462] ixgbe 0000:0c:00.0: eth2: Reset adapter [253766.634425] ixgbe 0000:0c:00.0: eth2: Reset adapter [253767.624392] ixgbe 0000:0c:00.0: eth2: Reset adapter [253768.614364] ixgbe 0000:0c:00.0: eth2: Reset adapter [253769.611107] ixgbe 0000:0c:00.0: eth2: Reset adapter [253769.715298] 893.960705 netmap_ring_reinit [966] called for eth2 [253769.716646] 893.962054 netmap_ring_reinit [966] called for eth2 [253769.725844] 893.971252 netmap_ioctl [1236] deprecated, data is ded4df20 [253776.141936] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow Control: None It seems that the adapter is reset every second, but no packet goes on the wire. I'm starting to look into the code to investigate this issue. If you have any suggestion on where to look at it would save me a lot of time. I also rechecked the rx mode. It is working at least up to 50Kpps (as I'm generation on the other side with nping and the original driver). Pkg-gen/netmap is configured to receive only the frames directed to the physical MAC address of the interface. I don't know if and how a promiscuous mode can be enabled with netmap. Thanks, -Walter 2013/3/22 Tahir Rauf > Dear Walter, > > Can you please disable Rx/Tx pause frames on your NIC. You can use > "ethtool" to do so. Please run the example again after disabling Rx/Tx > frames and let me know about the results. > > Regards > > > On Thu, Mar 21, 2013 at 8:20 PM, Walter de Donato < > walter.dedonato@gmail.com> wrote: > >> Not that lucky since my first goal is to transmit packets... >> I also noticed that the same car d is configured with 4 rings on 32bit >> kernels and 16 rings on 64bit kernels. >> Do you have any idea to explain this difference? >> >> -Walter >> >> 2013/3/21 Tahir Rauf >> >>> Dear Walter, >>> >>> You are lucky to have* X540-AT2 :). *Mine is different (82598EB) and >>> can't receive packets properly. >>> Yes, my tx is working and is able to send packets on line rate. >>> >>> Regards >>> >>> >>> On Thu, Mar 21, 2013 at 8:04 PM, Walter de Donato < >>> walter.dedonato@gmail.com> wrote: >>> >>>> Here is the lshw output: >>>> >>>> *-network:0 >>>> description: Ethernet interface >>>> product: Ethernet Controller 10 Gigabit X540-AT2 >>>> vendor: Intel Corporation >>>> physical id: 0 >>>> bus info: pci@0000:0c:00.0 >>>> logical name: eth2 >>>> version: 01 >>>> serial: a0:36:9f:0d:f0:98 >>>> capacity: 1Gbit/s >>>> width: 64 bits >>>> clock: 33MHz >>>> capabilities: pm msi msix pciexpress vpd bus_master cap_list rom >>>> ethernet physical tp 100bt-fd 1000bt-fd autonegotiation >>>> configuration: autonegotiation=on broadcast=yes driver=ixgbe >>>> driverversion=3.6.7-k duplex=full firmware=0x800002ef latency=0 link=yes >>>> multicast=yes port=twisted pair >>>> resources: irq:17 memory:d8400000-d85fffff >>>> memory:d83fc000-d83fffff memory:fc500000-fc57ffff memory:fc400000-fc4fffff >>>> *-network:1 >>>> description: Ethernet interface >>>> product: Ethernet Controller 10 Gigabit X540-AT2 >>>> vendor: Intel Corporation >>>> physical id: 0.1 >>>> bus info: pci@0000:0c:00.1 >>>> logical name: eth3 >>>> version: 01 >>>> serial: a0:36:9f:0d:f0:9a >>>> capacity: 1Gbit/s >>>> width: 64 bits >>>> clock: 33MHz >>>> capabilities: pm msi msix pciexpress vpd bus_master cap_list rom >>>> ethernet physical tp 100bt-fd 1000bt-fd autonegotiation >>>> configuration: autonegotiation=on broadcast=yes driver=ixgbe >>>> driverversion=3.6.7-k duplex=full firmware=0x800002ef ip=192.168.78.2 >>>> latency=0 link=yes multicast=yes port=twisted pair >>>> resources: irq:16 memory:d8000000-d81fffff >>>> memory:d83f8000-d83fbfff memory:d8200000-d827ffff >>>> >>>> Did you check if in tx mode your pkt-gen effectively sends the packets >>>> on the wire? >>>> What rates are you observing with it? >>>> >>>> -Walter >>>> >>>> 2013/3/21 Tahir Rauf >>>> >>>>> Dear walter, >>>>> >>>>> Can you please run following command to get your NIC information. >>>>> sudo lshw -class network >>>>> >>>>> I have *82598EB *10GB AF dual port network connection NIC and my rx >>>>> is not working. >>>>> >>>>> Regards >>>>> >>>>> >>>>> On Thu, Mar 21, 2013 at 7:46 PM, Walter de Donato < >>>>> walter.dedonato@gmail.com> wrote: >>>>> >>>>>> I tried the rx command and it seems to work: >>>>>> $ sudo ./pkt-gen -i eth3 -f rx -n 100000 -l 60 -w 1 >>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 >>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 >>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 >>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 >>>>>> extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:9a >>>>>> extract_mac_range [192] a0:36:9f:0d:f0:9a starts at a0:36:9f:d:f0:9a >>>>>> extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff >>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff >>>>>> main [1401] map size is 334980 Kb >>>>>> main [1423] mapping 334980 Kbytes >>>>>> Receiving from eth3: 4 queues, 1 threads and 1 cpus. >>>>>> main [1477] Wait 1 secs for phy reset >>>>>> main [1479] Ready... >>>>>> main_thread [1078] 0 pps (0 pkts in 1001020 usec) >>>>>> receiver_body [833] waiting for initial packets, poll returns 0 0 >>>>>> main_thread [1078] 0 pps (0 pkts in 1001059 usec) >>>>>> receiver_body [833] waiting for initial packets, poll returns 0 0 >>>>>> main_thread [1078] 0 pps (0 pkts in 1001047 usec) >>>>>> receiver_body [833] waiting for initial packets, poll returns 0 0 >>>>>> main_thread [1078] 2 pps (2 pkts in 1001118 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001040 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001038 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001030 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001028 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001051 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001068 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001040 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001035 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001042 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001083 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001050 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001073 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001052 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001041 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001051 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001058 usec) >>>>>> main_thread [1078] 1 pps (1 pkts in 1001020 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001021 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001022 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001072 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001020 usec) >>>>>> main_thread [1078] 3 pps (3 pkts in 1001041 usec) >>>>>> main_thread [1078] 3 pps (3 pkts in 1001023 usec) >>>>>> main_thread [1078] 4 pps (4 pkts in 1001025 usec) >>>>>> main_thread [1078] 3 pps (3 pkts in 1001032 usec) >>>>>> main_thread [1078] 3 pps (3 pkts in 1001058 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001042 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001018 usec) >>>>>> main_thread [1078] 2 pps (2 pkts in 1001024 usec) >>>>>> main_thread [1078] 0 pps (0 pkts in 1001058 usec) >>>>>> Received 58 packets, in 29.16 seconds. >>>>>> Speed: 1.99 pps >>>>>> >>>>>> >>>>>> The proble is that on the other side I had to use ping instead of >>>>>> pkt-gen. >>>>>> >>>>>> If I try to use pkt-gen I don't receive any packet. >>>>>> I just checked that pkt-gen is not effectively sending the packets on >>>>>> the wire, >>>>>> on the other side using tcpdump I don't receive any packet. >>>>>> >>>>>> So the problem on the tx side has not been completely solved in my >>>>>> case. >>>>>> Can you do the same test please? >>>>>> >>>>>> -Walter >>>>>> >>>>>> 2013/3/21 Tahir Rauf >>>>>> >>>>>>> Dear Walter, >>>>>>> >>>>>>> What about the Rx, Can you please try and inform me. >>>>>>> sudo ./pkt-gen -i eth2 -f rx -n 100000 -l 60 -w 1 >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 21, 2013 at 7:06 PM, Walter de Donato < >>>>>>> walter.dedonato@gmail.com> wrote: >>>>>>> >>>>>>>> Thanks Thair, >>>>>>>> >>>>>>>> with the fixed version the interface correctly attaches to the >>>>>>>> netmap driver and it is able to transmit packets. >>>>>>>> >>>>>>>> Anyway, I'm observing really poor performance: >>>>>>>> $ sudo ./pkt-gen -i eth2 -f tx -n 100000 -l 60 -w 1 >>>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 >>>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 >>>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 >>>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 >>>>>>>> extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 >>>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:98 starts at a0:36:9f:d:f0:98 >>>>>>>> extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff >>>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at >>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>> main [1401] map size is 334980 Kb >>>>>>>> main [1423] mapping 334980 Kbytes >>>>>>>> Sending on eth2: 4 queues, 1 threads and 1 cpus. >>>>>>>> 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) >>>>>>>> main [1477] Wait 1 secs for phy reset >>>>>>>> main [1479] Ready... >>>>>>>> sender_body [683] start >>>>>>>> main_thread [1078] 7101 pps (7108 pkts in 1001019 usec) >>>>>>>> main_thread [1078] 3482 pps (3486 pkts in 1001031 usec) >>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001026 usec) >>>>>>>> main_thread [1078] 3483 pps (3487 pkts in 1001026 usec) >>>>>>>> main_thread [1078] 3340 pps (3343 pkts in 1001019 usec) >>>>>>>> main_thread [1078] 3455 pps (3459 pkts in 1001025 usec) >>>>>>>> main_thread [1078] 3493 pps (3497 pkts in 1001024 usec) >>>>>>>> main_thread [1078] 3494 pps (3498 pkts in 1001022 usec) >>>>>>>> main_thread [1078] 3353 pps (3357 pkts in 1001056 usec) >>>>>>>> main_thread [1078] 3488 pps (3492 pkts in 1001093 usec) >>>>>>>> main_thread [1078] 3474 pps (3478 pkts in 1001064 usec) >>>>>>>> main_thread [1078] 3485 pps (3489 pkts in 1001102 usec) >>>>>>>> main_thread [1078] 3479 pps (3483 pkts in 1001064 usec) >>>>>>>> main_thread [1078] 3335 pps (3339 pkts in 1001111 usec) >>>>>>>> main_thread [1078] 3484 pps (3488 pkts in 1001074 usec) >>>>>>>> main_thread [1078] 3484 pps (3488 pkts in 1001030 usec) >>>>>>>> main_thread [1078] 3470 pps (3474 pkts in 1001046 usec) >>>>>>>> main_thread [1078] 3486 pps (3490 pkts in 1001040 usec) >>>>>>>> main_thread [1078] 3482 pps (3486 pkts in 1001035 usec) >>>>>>>> main_thread [1078] 3278 pps (3281 pkts in 1001045 usec) >>>>>>>> main_thread [1078] 3476 pps (3480 pkts in 1001021 usec) >>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001036 usec) >>>>>>>> main_thread [1078] 3477 pps (3481 pkts in 1001083 usec) >>>>>>>> main_thread [1078] 3493 pps (3497 pkts in 1001048 usec) >>>>>>>> main_thread [1078] 3353 pps (3357 pkts in 1001082 usec) >>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001051 usec) >>>>>>>> main_thread [1078] 3465 pps (3469 pkts in 1001060 usec) >>>>>>>> main_thread [1078] 3008 pps (3011 pkts in 1001030 usec) >>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001039 usec) >>>>>>>> Sent 100000 packets, 60 bytes each, in 28.58 seconds. >>>>>>>> Speed: 3.50 Kpps Bandwidth: 1.68 Mbps (raw 2.35 Mbps) >>>>>>>> >>>>>>>> With the rtl8169 1G driver (which they say to have the worst >>>>>>>> performance) >>>>>>>> I easily obtained Speed: 359.24Kpps. Bandwidth: 172.44Mbps with 64 >>>>>>>> bytes packets. >>>>>>>> >>>>>>>> Also, if I increase the packet size this is what happens: >>>>>>>> $ sudo ./pkt-gen -i eth2 -f tx -t 1000000 -l 508 >>>>>>>> main [1270] -t deprecated, please use -f tx -n 1000000 >>>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 >>>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 >>>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 >>>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 >>>>>>>> extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 >>>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:98 starts at a0:36:9f:d:f0:98 >>>>>>>> extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff >>>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at >>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>> main [1401] map size is 334980 Kb >>>>>>>> main [1423] mapping 334980 Kbytes >>>>>>>> Sending on eth2: 4 queues, 1 threads and 1 cpus. >>>>>>>> 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) >>>>>>>> main [1477] Wait 2 secs for phy reset >>>>>>>> main [1479] Ready... >>>>>>>> sender_body [683] start >>>>>>>> main_thread [1078] 2042 pps (2044 pkts in 1001016 usec) >>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001049 usec) >>>>>>>> sender_body [729] poll error/timeout on queue 0 >>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001035 usec) >>>>>>>> main_thread [1096] ouch, thread 0 exited with error >>>>>>>> Sent 2044 packets, 508 bytes each, in -1363874673.38 seconds. >>>>>>>> Speed: -0.00 pps Bandwidth: -0.01 bps (raw -0.01 bps) >>>>>>>> >>>>>>>> Don't you experience the same issues? >>>>>>>> >>>>>>>> -Walter >>>>>>>> >>>>>>>> 2013/3/21 Tahir Rauf >>>>>>>> >>>>>>>>> Dear Walter, >>>>>>>>> >>>>>>>>> Please try following code. >>>>>>>>> http://info.iet.unipi.it/~luigi/doc/20130217-netmap.tgz >>>>>>>>> It will fix your problem with Ixgbe tx function. >>>>>>>>> >>>>>>>>> Please let me know, if you encounter any problem. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 21, 2013 at 6:28 PM, Walter de Donato < >>>>>>>>> walter.dedonato@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Dear Tahir, >>>>>>>>>> >>>>>>>>>> thank you for the prompt reply. >>>>>>>>>> I downloaded the source code from the official website: >>>>>>>>>> http://info.iet.unipi.it/~luigi/doc/20120813-netmap.tgz >>>>>>>>>> Can you please share with me the fix about the tx function? >>>>>>>>>> I was just starting to look at the patched code of the drivers. >>>>>>>>>> >>>>>>>>>> Thanks in advance, >>>>>>>>>> -Walter >>>>>>>>>> >>>>>>>>>> 2013/3/21 Tahir Rauf >>>>>>>>>> >>>>>>>>>>> Hi dedonato, >>>>>>>>>>> >>>>>>>>>>> I just observed that you are having trouble with tx function of >>>>>>>>>>> pkt-gen. Whereas, we already have fixed that problem. We are facing issues >>>>>>>>>>> with rx only now. >>>>>>>>>>> Please tell me that from where you get the code of netmap? >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 21, 2013 at 5:49 PM, Tahir Rauf < >>>>>>>>>>> tahir.rauf1@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Dear Walter, >>>>>>>>>>>> >>>>>>>>>>>> I tried to fix the problem but i don't have any success yet. >>>>>>>>>>>> Also if you are trying to fix this problem, please share with >>>>>>>>>>>> me that which path you are going to take for fixing. It might be possible >>>>>>>>>>>> that I already have tried that path. In that case, I can share my results >>>>>>>>>>>> with you, thus saving your time. >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 21, 2013 at 5:08 PM, >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Dear Tahir and Luigi, >>>>>>>>>>>>> >>>>>>>>>>>>> I have exactly the same problem with a similar hardware/os >>>>>>>>>>>>> configuration reported in the following. >>>>>>>>>>>>> Do you hav any uptade on this issue? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> -Walter >>>>>>>>>>>>> >>>>>>>>>>>>> Netmap version: 20120813 >>>>>>>>>>>>> OS: Ubuntu 12.04.2 LTS >>>>>>>>>>>>> Kernel: 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 >>>>>>>>>>>>> 12:39:51 UTC 2013 i686 i686 i386 GNU/Linux >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Network interfaces: >>>>>>>>>>>>> eth2 >>>>>>>>>>>>> 0c:00.0 Ethernet controller: Intel Corporation Ethernet >>>>>>>>>>>>> Controller 10 Gigabit X540-AT2 (rev 01) >>>>>>>>>>>>> Subsystem: Intel Corporation Ethernet 10G 2P X540-t >>>>>>>>>>>>> Adapter >>>>>>>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 17 >>>>>>>>>>>>> Memory at d8400000 (64-bit, prefetchable) [size=2M] >>>>>>>>>>>>> Memory at d83fc000 (64-bit, prefetchable) [size=16K] >>>>>>>>>>>>> Expansion ROM at fc500000 [disabled] [size=512K] >>>>>>>>>>>>> Capabilities: [40] Power Management version 3 >>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ >>>>>>>>>>>>> 64bit+ >>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=64 Masked- >>>>>>>>>>>>> Capabilities: [a0] Express Endpoint, MSI 00 >>>>>>>>>>>>> Capabilities: [e0] Vital Product Data >>>>>>>>>>>>> Capabilities: [100] Advanced Error Reporting >>>>>>>>>>>>> Capabilities: [140] Device Serial Number >>>>>>>>>>>>> a0-36-9f-ff-ff-0d-f0-98 >>>>>>>>>>>>> Capabilities: [150] Alternative Routing-ID >>>>>>>>>>>>> Interpretation (ARI) >>>>>>>>>>>>> Capabilities: [160] Single Root I/O Virtualization >>>>>>>>>>>>> (SR-IOV) >>>>>>>>>>>>> Capabilities: [1d0] Access Control Services >>>>>>>>>>>>> Kernel driver in use: ixgbe >>>>>>>>>>>>> Kernel modules: ixgbe >>>>>>>>>>>>> >>>>>>>>>>>>> eth3 >>>>>>>>>>>>> 0c:00.1 Ethernet controller: Intel Corporation Ethernet >>>>>>>>>>>>> Controller 10 Gigabit X540-AT2 (rev 01) >>>>>>>>>>>>> Subsystem: Intel Corporation Ethernet 10G 2P X540-t >>>>>>>>>>>>> Adapter >>>>>>>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 16 >>>>>>>>>>>>> Memory at d8000000 (64-bit, prefetchable) [size=2M] >>>>>>>>>>>>> Memory at d83f8000 (64-bit, prefetchable) [size=16K] >>>>>>>>>>>>> Expansion ROM at d8200000 [disabled] [size=512K] >>>>>>>>>>>>> Capabilities: [40] Power Management version 3 >>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ >>>>>>>>>>>>> 64bit+ >>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=64 Masked- >>>>>>>>>>>>> Capabilities: [a0] Express Endpoint, MSI 00 >>>>>>>>>>>>> Capabilities: [e0] Vital Product Data >>>>>>>>>>>>> Capabilities: [100] Advanced Error Reporting >>>>>>>>>>>>> Capabilities: [140] Device Serial Number >>>>>>>>>>>>> a0-36-9f-ff-ff-0d-f0-98 >>>>>>>>>>>>> Capabilities: [150] Alternative Routing-ID >>>>>>>>>>>>> Interpretation (ARI) >>>>>>>>>>>>> Capabilities: [160] Single Root I/O Virtualization >>>>>>>>>>>>> (SR-IOV) >>>>>>>>>>>>> Capabilities: [1d0] Access Control Services >>>>>>>>>>>>> Kernel driver in use: ixgbe >>>>>>>>>>>>> Kernel modules: ixgbe >>>>>>>>>>>>> >>>>>>>>>>>>> After loading the modules this is the (interesting) lsmod >>>>>>>>>>>>> output: >>>>>>>>>>>>> $ lsmod >>>>>>>>>>>>> Module Size Used by >>>>>>>>>>>>> ixgbe 160150 0 >>>>>>>>>>>>> netmap_lin 102855 1 ixgbe >>>>>>>>>>>>> dca 14728 1 ixgbe >>>>>>>>>>>>> mdio 13559 1 ixgbe >>>>>>>>>>>>> >>>>>>>>>>>>> And the following is the (interesting) dmesg output: >>>>>>>>>>>>> [175397.625200] 521.870604 netmap_new_obj_allocator [426] >>>>>>>>>>>>> objsize 1024 clustsize 4096 objects 4 >>>>>>>>>>>>> [175397.625501] 521.870912 netmap_new_obj_allocator [504] >>>>>>>>>>>>> Pre-allocated 128 clusters (4/512KB) for 'netmap_if' >>>>>>>>>>>>> [175397.625653] 521.871065 netmap_new_obj_allocator [426] >>>>>>>>>>>>> objsize 36864 clustsize 36864 objects 1 >>>>>>>>>>>>> [175397.629906] 521.875312 netmap_new_obj_allocator [504] >>>>>>>>>>>>> Pre-allocated 200 clusters (36/7200KB) for 'netmap_ring' >>>>>>>>>>>>> [175397.630064] 521.875477 netmap_new_obj_allocator [426] >>>>>>>>>>>>> objsize 2048 clustsize 4096 objects 2 >>>>>>>>>>>>> [175397.708572] 521.953976 netmap_new_obj_allocator [504] >>>>>>>>>>>>> Pre-allocated 50000 clusters (4/200000KB) for 'netmap_buf' >>>>>>>>>>>>> [175397.708737] 521.954147 netmap_memory_init [554] Have 512 >>>>>>>>>>>>> KB for interfaces, 7200 KB for rings and 195 MB for buffers >>>>>>>>>>>>> [175397.708885] netmap: loaded module with 202 Mbytes >>>>>>>>>>>>> [175418.013476] ixgbe: Intel(R) 10 Gigabit PCI Express Network >>>>>>>>>>>>> Driver - version 3.6.7-k >>>>>>>>>>>>> [175418.013479] ixgbe: Copyright (c) 1999-2011 Intel >>>>>>>>>>>>> Corporation. >>>>>>>>>>>>> [175418.013531] ixgbe 0000:0c:00.0: PCI INT B -> GSI 17 >>>>>>>>>>>>> (level, low) -> IRQ 17 >>>>>>>>>>>>> [175418.013543] ixgbe 0000:0c:00.0: setting latency timer to 64 >>>>>>>>>>>>> [175418.425782] ixgbe 0000:0c:00.0: irq 271 for MSI/MSI-X >>>>>>>>>>>>> [175418.425791] ixgbe 0000:0c:00.0: irq 272 for MSI/MSI-X >>>>>>>>>>>>> [175418.425798] ixgbe 0000:0c:00.0: irq 273 for MSI/MSI-X >>>>>>>>>>>>> [175418.425806] ixgbe 0000:0c:00.0: irq 274 for MSI/MSI-X >>>>>>>>>>>>> [175418.425813] ixgbe 0000:0c:00.0: irq 275 for MSI/MSI-X >>>>>>>>>>>>> [175418.425829] ixgbe 0000:0c:00.0: Multiqueue Enabled: Rx >>>>>>>>>>>>> Queue count = 4, Tx Queue count = 4 >>>>>>>>>>>>> [175418.485972] ixgbe 0000:0c:00.0: (PCI Express:2.5GT/s:Width >>>>>>>>>>>>> x8) a0:36:9f:0d:f0:98 >>>>>>>>>>>>> [175418.646372] ixgbe 0000:0c:00.0: MAC: 3, PHY: 3, PBA No: >>>>>>>>>>>>> G44743-006 >>>>>>>>>>>>> [175418.788262] ixgbe 0000:0c:00.0: Intel(R) 10 Gigabit >>>>>>>>>>>>> Network Connection >>>>>>>>>>>>> [175418.788285] ixgbe 0000:0c:00.1: PCI INT A -> GSI 16 >>>>>>>>>>>>> (level, low) -> IRQ 16 >>>>>>>>>>>>> [175418.788296] ixgbe 0000:0c:00.1: setting latency timer to 64 >>>>>>>>>>>>> [175419.213734] ixgbe 0000:0c:00.1: irq 276 for MSI/MSI-X >>>>>>>>>>>>> [175419.213742] ixgbe 0000:0c:00.1: irq 277 for MSI/MSI-X >>>>>>>>>>>>> [175419.213750] ixgbe 0000:0c:00.1: irq 278 for MSI/MSI-X >>>>>>>>>>>>> [175419.213758] ixgbe 0000:0c:00.1: irq 279 for MSI/MSI-X >>>>>>>>>>>>> [175419.213766] ixgbe 0000:0c:00.1: irq 280 for MSI/MSI-X >>>>>>>>>>>>> [175419.213782] ixgbe 0000:0c:00.1: Multiqueue Enabled: Rx >>>>>>>>>>>>> Queue count = 4, Tx Queue count = 4 >>>>>>>>>>>>> [175419.273937] ixgbe 0000:0c:00.1: (PCI Express:2.5GT/s:Width >>>>>>>>>>>>> x8) a0:36:9f:0d:f0:9a >>>>>>>>>>>>> [175419.434299] ixgbe 0000:0c:00.1: MAC: 3, PHY: 3, PBA No: >>>>>>>>>>>>> G44743-006 >>>>>>>>>>>>> [175419.576197] ixgbe 0000:0c:00.1: Intel(R) 10 Gigabit >>>>>>>>>>>>> Network Connection >>>>>>>>>>>>> >>>>>>>>>>>>> This is the pkt-gen output: >>>>>>>>>>>>> $ sudo ./pkt-gen -i eth2 tx -n 10000 >>>>>>>>>>>>> extract_ip_range [119] extract IP range from 10.0.0.1 >>>>>>>>>>>>> extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 >>>>>>>>>>>>> extract_ip_range [119] extract IP range from 10.1.0.1 >>>>>>>>>>>>> extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 >>>>>>>>>>>>> extract_mac_range [135] extract MAC range from >>>>>>>>>>>>> a0:36:9f:0d:f0:98 >>>>>>>>>>>>> extract_mac_range [150] a0:36:9f:0d:f0:98 starts at >>>>>>>>>>>>> a0:36:9f:d:f0:98 >>>>>>>>>>>>> extract_mac_range [135] extract MAC range from >>>>>>>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>>>>>>> extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at >>>>>>>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>>>>>>> main [1053] map size is 207712 Kb >>>>>>>>>>>>> main [1059] Unable to get if info for eth2 >>>>>>>>>>>>> main [1066] bad nthreads 1, have 0 queues >>>>>>>>>>>>> main [1075] mmapping 207712 Kbytes >>>>>>>>>>>>> main [1094] Unable to register interface eth2 >>>>>>>>>>>>> Receiving from eth2: 0 queues, 1 threads and 1 cpus. >>>>>>>>>>>>> main [1128] Wait 2 secs for phy reset >>>>>>>>>>>>> main [1130] Ready... >>>>>>>>>>>>> main [1181] Unable to register eth2 >>>>>>>>>>>>> main [1242] 0 pps >>>>>>>>>>>>> Received 0 packets, in 0.00 seconds. >>>>>>>>>>>>> Speed: -nanpps. >>>>>>>>>>>>> >>>>>>>>>>>>> Dmesg after trying to use pkt-gen on eth2: >>>>>>>>>>>>> [175537.838503] ADDRCONF(NETDEV_UP): eth2: link is not ready >>>>>>>>>>>>> [175542.802288] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 >>>>>>>>>>>>> Gbps, Flow Control: RX/TX >>>>>>>>>>>>> [175542.802607] ADDRCONF(NETDEV_CHANGE): eth2: link becomes >>>>>>>>>>>>> ready >>>>>>>>>>>>> [175553.256029] eth2: no IPv6 routers present >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Tahir Rauf >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Tahir Rauf >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Tahir Rauf >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Tahir Rauf >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Tahir Rauf >>>>> >>>>> >>>> >>> >>> >>> -- >>> Tahir Rauf >>> >>> >> > > > -- > Tahir Rauf > > From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 10:41:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00BC07B for ; Fri, 22 Mar 2013 10:41:53 +0000 (UTC) (envelope-from micchie@sfc.wide.ad.jp) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) by mx1.freebsd.org (Postfix) with ESMTP id 85E42A1C for ; Fri, 22 Mar 2013 10:41:53 +0000 (UTC) Received: from epi.lan (prova.iet.unipi.it [131.114.58.86]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A6DF32780D1; Fri, 22 Mar 2013 19:41:49 +0900 (JST) Subject: Re: Netmap ixgbe driver problem on 10Gbps X540-AT2 adapters (Linux only?) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michio Honda In-Reply-To: Date: Fri, 22 Mar 2013 11:41:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Walter de Donato X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 10:41:54 -0000 You need to specify "-w 4" on running pkt-gen to wait for that the link = resets. Cheers, - Michio On Mar 22, 2013, at 11:16 AM, Walter de Donato wrote: > Dear Tahir, >=20 > I've already tried to disable Rx/Tx pause and autonegotiation but the > result in transmission is always the same. >=20 > I did the following: > $ sudo ifconfig eth2 up > $ sudo ethtool -A eth2 autoneg off > $ sudo ethtool -A eth2 rx off > $ sudo ethtool -A eth2 tx off >=20 > These are the resulting dmesg output lines: > [253131.445124] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > Control: RX/TX > [253147.935426] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > Control: TX > [253163.930776] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > Control: None >=20 > Here is what I obtain: > $ sudo ./pkt-gen -i eth2 -n 100000 -f tx > extract_ip_range [136] extract IP range from 10.0.0.1 > extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 > extract_ip_range [136] extract IP range from 10.1.0.1 > extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 > extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 > extract_mac_range [192] a0:36:9f:0d:f0:98 starts at a0:36:9f:d:f0:98 > extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff > extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff > main [1401] map size is 334980 Kb > main [1423] mapping 334980 Kbytes > Sending on eth2: 4 queues, 1 threads and 1 cpus. > 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) > main [1477] Wait 2 secs for phy reset > main [1479] Ready... > sender_body [683] start > main_thread [1078] 7155 pps (7162 pkts in 1001020 usec) > main_thread [1078] 3484 pps (3488 pkts in 1001030 usec) > main_thread [1078] 3487 pps (3491 pkts in 1001024 usec) > main_thread [1078] 3466 pps (3469 pkts in 1000847 usec) > main_thread [1078] 3485 pps (3490 pkts in 1001521 usec) > main_thread [1078] 3322 pps (3328 pkts in 1001765 usec) > main_thread [1078] 3293 pps (3297 pkts in 1001322 usec) > main_thread [1078] 3492 pps (3498 pkts in 1001763 usec) > main_thread [1078] 3485 pps (3489 pkts in 1001168 usec) > main_thread [1078] 3351 pps (3356 pkts in 1001402 usec) > main_thread [1078] 3297 pps (3301 pkts in 1001314 usec) > main_thread [1078] 3933 pps (3938 pkts in 1001390 usec) > main_thread [1078] 3481 pps (3486 pkts in 1001528 usec) > main_thread [1078] 3493 pps (3497 pkts in 1001177 usec) > main_thread [1078] 3310 pps (3314 pkts in 1001292 usec) > main_thread [1078] 3485 pps (3491 pkts in 1001812 usec) > main_thread [1078] 3326 pps (3331 pkts in 1001547 usec) > main_thread [1078] 3480 pps (3485 pkts in 1001456 usec) > main_thread [1078] 3489 pps (3493 pkts in 1001209 usec) > main_thread [1078] 3377 pps (3381 pkts in 1001040 usec) > main_thread [1078] 3450 pps (3454 pkts in 1001048 usec) > main_thread [1078] 3378 pps (3382 pkts in 1001050 usec) > main_thread [1078] 3470 pps (3474 pkts in 1001052 usec) > main_thread [1078] 3323 pps (3327 pkts in 1001056 usec) > main_thread [1078] 3482 pps (3486 pkts in 1001050 usec) > main_thread [1078] 3472 pps (3476 pkts in 1001066 usec) > main_thread [1078] 3497 pps (3501 pkts in 1001044 usec) > main_thread [1078] 3115 pps (3115 pkts in 1000035 usec) > main_thread [1078] 0 pps (0 pkts in 1001057 usec) > Sent 100000 packets, 60 bytes each, in 28.42 seconds. > Speed: 3.52 Kpps Bandwidth: 1.69 Mbps (raw 2.36 Mbps) >=20 > While executing pkt-gen I see the following dmesg output lines: > [253741.892031] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253742.874686] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253743.864635] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253744.854513] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253745.844527] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253746.830323] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253747.821223] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253748.813229] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253749.804317] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253750.794286] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253751.784302] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253752.774324] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253753.764258] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253754.753735] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253755.748011] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253756.734927] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253757.724876] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253758.713267] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253759.704793] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253760.694759] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253761.684743] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253762.674699] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253763.664642] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253764.654488] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253765.644462] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253766.634425] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253767.624392] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253768.614364] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253769.611107] ixgbe 0000:0c:00.0: eth2: Reset adapter > [253769.715298] 893.960705 netmap_ring_reinit [966] called for eth2 > [253769.716646] 893.962054 netmap_ring_reinit [966] called for eth2 > [253769.725844] 893.971252 netmap_ioctl [1236] deprecated, data is = ded4df20 > [253776.141936] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > Control: None >=20 > It seems that the adapter is reset every second, but no packet goes on = the > wire. >=20 > I'm starting to look into the code to investigate this issue. > If you have any suggestion on where to look at it would save me a lot = of > time. >=20 > I also rechecked the rx mode. > It is working at least up to 50Kpps (as I'm generation on the other = side > with nping and the original driver). > Pkg-gen/netmap is configured to receive only the frames directed to = the > physical MAC address of the interface. > I don't know if and how a promiscuous mode can be enabled with netmap. >=20 > Thanks, > -Walter > 2013/3/22 Tahir Rauf >=20 >> Dear Walter, >>=20 >> Can you please disable Rx/Tx pause frames on your NIC. You can use >> "ethtool" to do so. Please run the example again after disabling = Rx/Tx >> frames and let me know about the results. >>=20 >> Regards >>=20 >>=20 >> On Thu, Mar 21, 2013 at 8:20 PM, Walter de Donato < >> walter.dedonato@gmail.com> wrote: >>=20 >>> Not that lucky since my first goal is to transmit packets... >>> I also noticed that the same car d is configured with 4 rings on = 32bit >>> kernels and 16 rings on 64bit kernels. >>> Do you have any idea to explain this difference? >>>=20 >>> -Walter >>>=20 >>> 2013/3/21 Tahir Rauf >>>=20 >>>> Dear Walter, >>>>=20 >>>> You are lucky to have* X540-AT2 :). *Mine is different (82598EB) = and >>>> can't receive packets properly. >>>> Yes, my tx is working and is able to send packets on line rate. >>>>=20 >>>> Regards >>>>=20 >>>>=20 >>>> On Thu, Mar 21, 2013 at 8:04 PM, Walter de Donato < >>>> walter.dedonato@gmail.com> wrote: >>>>=20 >>>>> Here is the lshw output: >>>>>=20 >>>>> *-network:0 >>>>> description: Ethernet interface >>>>> product: Ethernet Controller 10 Gigabit X540-AT2 >>>>> vendor: Intel Corporation >>>>> physical id: 0 >>>>> bus info: pci@0000:0c:00.0 >>>>> logical name: eth2 >>>>> version: 01 >>>>> serial: a0:36:9f:0d:f0:98 >>>>> capacity: 1Gbit/s >>>>> width: 64 bits >>>>> clock: 33MHz >>>>> capabilities: pm msi msix pciexpress vpd bus_master cap_list = rom >>>>> ethernet physical tp 100bt-fd 1000bt-fd autonegotiation >>>>> configuration: autonegotiation=3Don broadcast=3Dyes = driver=3Dixgbe >>>>> driverversion=3D3.6.7-k duplex=3Dfull firmware=3D0x800002ef = latency=3D0 link=3Dyes >>>>> multicast=3Dyes port=3Dtwisted pair >>>>> resources: irq:17 memory:d8400000-d85fffff >>>>> memory:d83fc000-d83fffff memory:fc500000-fc57ffff = memory:fc400000-fc4fffff >>>>> *-network:1 >>>>> description: Ethernet interface >>>>> product: Ethernet Controller 10 Gigabit X540-AT2 >>>>> vendor: Intel Corporation >>>>> physical id: 0.1 >>>>> bus info: pci@0000:0c:00.1 >>>>> logical name: eth3 >>>>> version: 01 >>>>> serial: a0:36:9f:0d:f0:9a >>>>> capacity: 1Gbit/s >>>>> width: 64 bits >>>>> clock: 33MHz >>>>> capabilities: pm msi msix pciexpress vpd bus_master cap_list = rom >>>>> ethernet physical tp 100bt-fd 1000bt-fd autonegotiation >>>>> configuration: autonegotiation=3Don broadcast=3Dyes = driver=3Dixgbe >>>>> driverversion=3D3.6.7-k duplex=3Dfull firmware=3D0x800002ef = ip=3D192.168.78.2 >>>>> latency=3D0 link=3Dyes multicast=3Dyes port=3Dtwisted pair >>>>> resources: irq:16 memory:d8000000-d81fffff >>>>> memory:d83f8000-d83fbfff memory:d8200000-d827ffff >>>>>=20 >>>>> Did you check if in tx mode your pkt-gen effectively sends the = packets >>>>> on the wire? >>>>> What rates are you observing with it? >>>>>=20 >>>>> -Walter >>>>>=20 >>>>> 2013/3/21 Tahir Rauf >>>>>=20 >>>>>> Dear walter, >>>>>>=20 >>>>>> Can you please run following command to get your NIC information. >>>>>> sudo lshw -class network >>>>>>=20 >>>>>> I have *82598EB *10GB AF dual port network connection NIC and my = rx >>>>>> is not working. >>>>>>=20 >>>>>> Regards >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Mar 21, 2013 at 7:46 PM, Walter de Donato < >>>>>> walter.dedonato@gmail.com> wrote: >>>>>>=20 >>>>>>> I tried the rx command and it seems to work: >>>>>>> $ sudo ./pkt-gen -i eth3 -f rx -n 100000 -l 60 -w 1 >>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 >>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 >>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 >>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 >>>>>>> extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:9a >>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:9a starts at = a0:36:9f:d:f0:9a >>>>>>> extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff >>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at = ff:ff:ff:ff:ff:ff >>>>>>> main [1401] map size is 334980 Kb >>>>>>> main [1423] mapping 334980 Kbytes >>>>>>> Receiving from eth3: 4 queues, 1 threads and 1 cpus. >>>>>>> main [1477] Wait 1 secs for phy reset >>>>>>> main [1479] Ready... >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001020 usec) >>>>>>> receiver_body [833] waiting for initial packets, poll returns 0 = 0 >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001059 usec) >>>>>>> receiver_body [833] waiting for initial packets, poll returns 0 = 0 >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001047 usec) >>>>>>> receiver_body [833] waiting for initial packets, poll returns 0 = 0 >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001118 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001040 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001038 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001030 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001028 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001051 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001068 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001040 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001035 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001042 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001083 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001050 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001073 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001052 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001041 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001051 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001058 usec) >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001020 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001021 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001022 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001072 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001020 usec) >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001041 usec) >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001023 usec) >>>>>>> main_thread [1078] 4 pps (4 pkts in 1001025 usec) >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001032 usec) >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001058 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001042 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001018 usec) >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001024 usec) >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001058 usec) >>>>>>> Received 58 packets, in 29.16 seconds. >>>>>>> Speed: 1.99 pps >>>>>>>=20 >>>>>>>=20 >>>>>>> The proble is that on the other side I had to use ping instead = of >>>>>>> pkt-gen. >>>>>>>=20 >>>>>>> If I try to use pkt-gen I don't receive any packet. >>>>>>> I just checked that pkt-gen is not effectively sending the = packets on >>>>>>> the wire, >>>>>>> on the other side using tcpdump I don't receive any packet. >>>>>>>=20 >>>>>>> So the problem on the tx side has not been completely solved in = my >>>>>>> case. >>>>>>> Can you do the same test please? >>>>>>>=20 >>>>>>> -Walter >>>>>>>=20 >>>>>>> 2013/3/21 Tahir Rauf >>>>>>>=20 >>>>>>>> Dear Walter, >>>>>>>>=20 >>>>>>>> What about the Rx, Can you please try and inform me. >>>>>>>> sudo ./pkt-gen -i eth2 -f rx -n 100000 -l 60 -w 1 >>>>>>>>=20 >>>>>>>> Regards >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Thu, Mar 21, 2013 at 7:06 PM, Walter de Donato < >>>>>>>> walter.dedonato@gmail.com> wrote: >>>>>>>>=20 >>>>>>>>> Thanks Thair, >>>>>>>>>=20 >>>>>>>>> with the fixed version the interface correctly attaches to the >>>>>>>>> netmap driver and it is able to transmit packets. >>>>>>>>>=20 >>>>>>>>> Anyway, I'm observing really poor performance: >>>>>>>>> $ sudo ./pkt-gen -i eth2 -f tx -n 100000 -l 60 -w 1 >>>>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 >>>>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 >>>>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 >>>>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 >>>>>>>>> extract_mac_range [177] extract MAC range from = a0:36:9f:0d:f0:98 >>>>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:98 starts at = a0:36:9f:d:f0:98 >>>>>>>>> extract_mac_range [177] extract MAC range from = ff:ff:ff:ff:ff:ff >>>>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at >>>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>>> main [1401] map size is 334980 Kb >>>>>>>>> main [1423] mapping 334980 Kbytes >>>>>>>>> Sending on eth2: 4 queues, 1 threads and 1 cpus. >>>>>>>>> 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) >>>>>>>>> main [1477] Wait 1 secs for phy reset >>>>>>>>> main [1479] Ready... >>>>>>>>> sender_body [683] start >>>>>>>>> main_thread [1078] 7101 pps (7108 pkts in 1001019 usec) >>>>>>>>> main_thread [1078] 3482 pps (3486 pkts in 1001031 usec) >>>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001026 usec) >>>>>>>>> main_thread [1078] 3483 pps (3487 pkts in 1001026 usec) >>>>>>>>> main_thread [1078] 3340 pps (3343 pkts in 1001019 usec) >>>>>>>>> main_thread [1078] 3455 pps (3459 pkts in 1001025 usec) >>>>>>>>> main_thread [1078] 3493 pps (3497 pkts in 1001024 usec) >>>>>>>>> main_thread [1078] 3494 pps (3498 pkts in 1001022 usec) >>>>>>>>> main_thread [1078] 3353 pps (3357 pkts in 1001056 usec) >>>>>>>>> main_thread [1078] 3488 pps (3492 pkts in 1001093 usec) >>>>>>>>> main_thread [1078] 3474 pps (3478 pkts in 1001064 usec) >>>>>>>>> main_thread [1078] 3485 pps (3489 pkts in 1001102 usec) >>>>>>>>> main_thread [1078] 3479 pps (3483 pkts in 1001064 usec) >>>>>>>>> main_thread [1078] 3335 pps (3339 pkts in 1001111 usec) >>>>>>>>> main_thread [1078] 3484 pps (3488 pkts in 1001074 usec) >>>>>>>>> main_thread [1078] 3484 pps (3488 pkts in 1001030 usec) >>>>>>>>> main_thread [1078] 3470 pps (3474 pkts in 1001046 usec) >>>>>>>>> main_thread [1078] 3486 pps (3490 pkts in 1001040 usec) >>>>>>>>> main_thread [1078] 3482 pps (3486 pkts in 1001035 usec) >>>>>>>>> main_thread [1078] 3278 pps (3281 pkts in 1001045 usec) >>>>>>>>> main_thread [1078] 3476 pps (3480 pkts in 1001021 usec) >>>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001036 usec) >>>>>>>>> main_thread [1078] 3477 pps (3481 pkts in 1001083 usec) >>>>>>>>> main_thread [1078] 3493 pps (3497 pkts in 1001048 usec) >>>>>>>>> main_thread [1078] 3353 pps (3357 pkts in 1001082 usec) >>>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001051 usec) >>>>>>>>> main_thread [1078] 3465 pps (3469 pkts in 1001060 usec) >>>>>>>>> main_thread [1078] 3008 pps (3011 pkts in 1001030 usec) >>>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001039 usec) >>>>>>>>> Sent 100000 packets, 60 bytes each, in 28.58 seconds. >>>>>>>>> Speed: 3.50 Kpps Bandwidth: 1.68 Mbps (raw 2.35 Mbps) >>>>>>>>>=20 >>>>>>>>> With the rtl8169 1G driver (which they say to have the worst >>>>>>>>> performance) >>>>>>>>> I easily obtained Speed: 359.24Kpps. Bandwidth: 172.44Mbps = with 64 >>>>>>>>> bytes packets. >>>>>>>>>=20 >>>>>>>>> Also, if I increase the packet size this is what happens: >>>>>>>>> $ sudo ./pkt-gen -i eth2 -f tx -t 1000000 -l 508 >>>>>>>>> main [1270] -t deprecated, please use -f tx -n 1000000 >>>>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 >>>>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 >>>>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 >>>>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 >>>>>>>>> extract_mac_range [177] extract MAC range from = a0:36:9f:0d:f0:98 >>>>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:98 starts at = a0:36:9f:d:f0:98 >>>>>>>>> extract_mac_range [177] extract MAC range from = ff:ff:ff:ff:ff:ff >>>>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at >>>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>>> main [1401] map size is 334980 Kb >>>>>>>>> main [1423] mapping 334980 Kbytes >>>>>>>>> Sending on eth2: 4 queues, 1 threads and 1 cpus. >>>>>>>>> 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) >>>>>>>>> main [1477] Wait 2 secs for phy reset >>>>>>>>> main [1479] Ready... >>>>>>>>> sender_body [683] start >>>>>>>>> main_thread [1078] 2042 pps (2044 pkts in 1001016 usec) >>>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001049 usec) >>>>>>>>> sender_body [729] poll error/timeout on queue 0 >>>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001035 usec) >>>>>>>>> main_thread [1096] ouch, thread 0 exited with error >>>>>>>>> Sent 2044 packets, 508 bytes each, in -1363874673.38 seconds. >>>>>>>>> Speed: -0.00 pps Bandwidth: -0.01 bps (raw -0.01 bps) >>>>>>>>>=20 >>>>>>>>> Don't you experience the same issues? >>>>>>>>>=20 >>>>>>>>> -Walter >>>>>>>>>=20 >>>>>>>>> 2013/3/21 Tahir Rauf >>>>>>>>>=20 >>>>>>>>>> Dear Walter, >>>>>>>>>>=20 >>>>>>>>>> Please try following code. >>>>>>>>>> http://info.iet.unipi.it/~luigi/doc/20130217-netmap.tgz >>>>>>>>>> It will fix your problem with Ixgbe tx function. >>>>>>>>>>=20 >>>>>>>>>> Please let me know, if you encounter any problem. >>>>>>>>>>=20 >>>>>>>>>> Regards >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Thu, Mar 21, 2013 at 6:28 PM, Walter de Donato < >>>>>>>>>> walter.dedonato@gmail.com> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Dear Tahir, >>>>>>>>>>>=20 >>>>>>>>>>> thank you for the prompt reply. >>>>>>>>>>> I downloaded the source code from the official website: >>>>>>>>>>> http://info.iet.unipi.it/~luigi/doc/20120813-netmap.tgz >>>>>>>>>>> Can you please share with me the fix about the tx function? >>>>>>>>>>> I was just starting to look at the patched code of the = drivers. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks in advance, >>>>>>>>>>> -Walter >>>>>>>>>>>=20 >>>>>>>>>>> 2013/3/21 Tahir Rauf >>>>>>>>>>>=20 >>>>>>>>>>>> Hi dedonato, >>>>>>>>>>>>=20 >>>>>>>>>>>> I just observed that you are having trouble with tx = function of >>>>>>>>>>>> pkt-gen. Whereas, we already have fixed that problem. We = are facing issues >>>>>>>>>>>> with rx only now. >>>>>>>>>>>> Please tell me that from where you get the code of netmap? >>>>>>>>>>>>=20 >>>>>>>>>>>> Regards >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> On Thu, Mar 21, 2013 at 5:49 PM, Tahir Rauf < >>>>>>>>>>>> tahir.rauf1@gmail.com> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Dear Walter, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I tried to fix the problem but i don't have any success = yet. >>>>>>>>>>>>> Also if you are trying to fix this problem, please share = with >>>>>>>>>>>>> me that which path you are going to take for fixing. It = might be possible >>>>>>>>>>>>> that I already have tried that path. In that case, I can = share my results >>>>>>>>>>>>> with you, thus saving your time. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On Thu, Mar 21, 2013 at 5:08 PM, = >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Dear Tahir and Luigi, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I have exactly the same problem with a similar = hardware/os >>>>>>>>>>>>>> configuration reported in the following. >>>>>>>>>>>>>> Do you hav any uptade on this issue? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> -Walter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Netmap version: 20120813 >>>>>>>>>>>>>> OS: Ubuntu 12.04.2 LTS >>>>>>>>>>>>>> Kernel: 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 >>>>>>>>>>>>>> 12:39:51 UTC 2013 i686 i686 i386 GNU/Linux >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Network interfaces: >>>>>>>>>>>>>> eth2 >>>>>>>>>>>>>> 0c:00.0 Ethernet controller: Intel Corporation Ethernet >>>>>>>>>>>>>> Controller 10 Gigabit X540-AT2 (rev 01) >>>>>>>>>>>>>> Subsystem: Intel Corporation Ethernet 10G 2P = X540-t >>>>>>>>>>>>>> Adapter >>>>>>>>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 17 >>>>>>>>>>>>>> Memory at d8400000 (64-bit, prefetchable) = [size=3D2M] >>>>>>>>>>>>>> Memory at d83fc000 (64-bit, prefetchable) = [size=3D16K] >>>>>>>>>>>>>> Expansion ROM at fc500000 [disabled] [size=3D512K] >>>>>>>>>>>>>> Capabilities: [40] Power Management version 3 >>>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=3D1/1 = Maskable+ >>>>>>>>>>>>>> 64bit+ >>>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=3D64 = Masked- >>>>>>>>>>>>>> Capabilities: [a0] Express Endpoint, MSI 00 >>>>>>>>>>>>>> Capabilities: [e0] Vital Product Data >>>>>>>>>>>>>> Capabilities: [100] Advanced Error Reporting >>>>>>>>>>>>>> Capabilities: [140] Device Serial Number >>>>>>>>>>>>>> a0-36-9f-ff-ff-0d-f0-98 >>>>>>>>>>>>>> Capabilities: [150] Alternative Routing-ID >>>>>>>>>>>>>> Interpretation (ARI) >>>>>>>>>>>>>> Capabilities: [160] Single Root I/O Virtualization >>>>>>>>>>>>>> (SR-IOV) >>>>>>>>>>>>>> Capabilities: [1d0] Access Control Services >>>>>>>>>>>>>> Kernel driver in use: ixgbe >>>>>>>>>>>>>> Kernel modules: ixgbe >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> eth3 >>>>>>>>>>>>>> 0c:00.1 Ethernet controller: Intel Corporation Ethernet >>>>>>>>>>>>>> Controller 10 Gigabit X540-AT2 (rev 01) >>>>>>>>>>>>>> Subsystem: Intel Corporation Ethernet 10G 2P = X540-t >>>>>>>>>>>>>> Adapter >>>>>>>>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 16 >>>>>>>>>>>>>> Memory at d8000000 (64-bit, prefetchable) = [size=3D2M] >>>>>>>>>>>>>> Memory at d83f8000 (64-bit, prefetchable) = [size=3D16K] >>>>>>>>>>>>>> Expansion ROM at d8200000 [disabled] [size=3D512K] >>>>>>>>>>>>>> Capabilities: [40] Power Management version 3 >>>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=3D1/1 = Maskable+ >>>>>>>>>>>>>> 64bit+ >>>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=3D64 = Masked- >>>>>>>>>>>>>> Capabilities: [a0] Express Endpoint, MSI 00 >>>>>>>>>>>>>> Capabilities: [e0] Vital Product Data >>>>>>>>>>>>>> Capabilities: [100] Advanced Error Reporting >>>>>>>>>>>>>> Capabilities: [140] Device Serial Number >>>>>>>>>>>>>> a0-36-9f-ff-ff-0d-f0-98 >>>>>>>>>>>>>> Capabilities: [150] Alternative Routing-ID >>>>>>>>>>>>>> Interpretation (ARI) >>>>>>>>>>>>>> Capabilities: [160] Single Root I/O Virtualization >>>>>>>>>>>>>> (SR-IOV) >>>>>>>>>>>>>> Capabilities: [1d0] Access Control Services >>>>>>>>>>>>>> Kernel driver in use: ixgbe >>>>>>>>>>>>>> Kernel modules: ixgbe >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> After loading the modules this is the (interesting) lsmod >>>>>>>>>>>>>> output: >>>>>>>>>>>>>> $ lsmod >>>>>>>>>>>>>> Module Size Used by >>>>>>>>>>>>>> ixgbe 160150 0 >>>>>>>>>>>>>> netmap_lin 102855 1 ixgbe >>>>>>>>>>>>>> dca 14728 1 ixgbe >>>>>>>>>>>>>> mdio 13559 1 ixgbe >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> And the following is the (interesting) dmesg output: >>>>>>>>>>>>>> [175397.625200] 521.870604 netmap_new_obj_allocator [426] >>>>>>>>>>>>>> objsize 1024 clustsize 4096 objects 4 >>>>>>>>>>>>>> [175397.625501] 521.870912 netmap_new_obj_allocator [504] >>>>>>>>>>>>>> Pre-allocated 128 clusters (4/512KB) for 'netmap_if' >>>>>>>>>>>>>> [175397.625653] 521.871065 netmap_new_obj_allocator [426] >>>>>>>>>>>>>> objsize 36864 clustsize 36864 objects 1 >>>>>>>>>>>>>> [175397.629906] 521.875312 netmap_new_obj_allocator [504] >>>>>>>>>>>>>> Pre-allocated 200 clusters (36/7200KB) for 'netmap_ring' >>>>>>>>>>>>>> [175397.630064] 521.875477 netmap_new_obj_allocator [426] >>>>>>>>>>>>>> objsize 2048 clustsize 4096 objects 2 >>>>>>>>>>>>>> [175397.708572] 521.953976 netmap_new_obj_allocator [504] >>>>>>>>>>>>>> Pre-allocated 50000 clusters (4/200000KB) for = 'netmap_buf' >>>>>>>>>>>>>> [175397.708737] 521.954147 netmap_memory_init [554] Have = 512 >>>>>>>>>>>>>> KB for interfaces, 7200 KB for rings and 195 MB for = buffers >>>>>>>>>>>>>> [175397.708885] netmap: loaded module with 202 Mbytes >>>>>>>>>>>>>> [175418.013476] ixgbe: Intel(R) 10 Gigabit PCI Express = Network >>>>>>>>>>>>>> Driver - version 3.6.7-k >>>>>>>>>>>>>> [175418.013479] ixgbe: Copyright (c) 1999-2011 Intel >>>>>>>>>>>>>> Corporation. >>>>>>>>>>>>>> [175418.013531] ixgbe 0000:0c:00.0: PCI INT B -> GSI 17 >>>>>>>>>>>>>> (level, low) -> IRQ 17 >>>>>>>>>>>>>> [175418.013543] ixgbe 0000:0c:00.0: setting latency timer = to 64 >>>>>>>>>>>>>> [175418.425782] ixgbe 0000:0c:00.0: irq 271 for MSI/MSI-X >>>>>>>>>>>>>> [175418.425791] ixgbe 0000:0c:00.0: irq 272 for MSI/MSI-X >>>>>>>>>>>>>> [175418.425798] ixgbe 0000:0c:00.0: irq 273 for MSI/MSI-X >>>>>>>>>>>>>> [175418.425806] ixgbe 0000:0c:00.0: irq 274 for MSI/MSI-X >>>>>>>>>>>>>> [175418.425813] ixgbe 0000:0c:00.0: irq 275 for MSI/MSI-X >>>>>>>>>>>>>> [175418.425829] ixgbe 0000:0c:00.0: Multiqueue Enabled: = Rx >>>>>>>>>>>>>> Queue count =3D 4, Tx Queue count =3D 4 >>>>>>>>>>>>>> [175418.485972] ixgbe 0000:0c:00.0: (PCI = Express:2.5GT/s:Width >>>>>>>>>>>>>> x8) a0:36:9f:0d:f0:98 >>>>>>>>>>>>>> [175418.646372] ixgbe 0000:0c:00.0: MAC: 3, PHY: 3, PBA = No: >>>>>>>>>>>>>> G44743-006 >>>>>>>>>>>>>> [175418.788262] ixgbe 0000:0c:00.0: Intel(R) 10 Gigabit >>>>>>>>>>>>>> Network Connection >>>>>>>>>>>>>> [175418.788285] ixgbe 0000:0c:00.1: PCI INT A -> GSI 16 >>>>>>>>>>>>>> (level, low) -> IRQ 16 >>>>>>>>>>>>>> [175418.788296] ixgbe 0000:0c:00.1: setting latency timer = to 64 >>>>>>>>>>>>>> [175419.213734] ixgbe 0000:0c:00.1: irq 276 for MSI/MSI-X >>>>>>>>>>>>>> [175419.213742] ixgbe 0000:0c:00.1: irq 277 for MSI/MSI-X >>>>>>>>>>>>>> [175419.213750] ixgbe 0000:0c:00.1: irq 278 for MSI/MSI-X >>>>>>>>>>>>>> [175419.213758] ixgbe 0000:0c:00.1: irq 279 for MSI/MSI-X >>>>>>>>>>>>>> [175419.213766] ixgbe 0000:0c:00.1: irq 280 for MSI/MSI-X >>>>>>>>>>>>>> [175419.213782] ixgbe 0000:0c:00.1: Multiqueue Enabled: = Rx >>>>>>>>>>>>>> Queue count =3D 4, Tx Queue count =3D 4 >>>>>>>>>>>>>> [175419.273937] ixgbe 0000:0c:00.1: (PCI = Express:2.5GT/s:Width >>>>>>>>>>>>>> x8) a0:36:9f:0d:f0:9a >>>>>>>>>>>>>> [175419.434299] ixgbe 0000:0c:00.1: MAC: 3, PHY: 3, PBA = No: >>>>>>>>>>>>>> G44743-006 >>>>>>>>>>>>>> [175419.576197] ixgbe 0000:0c:00.1: Intel(R) 10 Gigabit >>>>>>>>>>>>>> Network Connection >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This is the pkt-gen output: >>>>>>>>>>>>>> $ sudo ./pkt-gen -i eth2 tx -n 10000 >>>>>>>>>>>>>> extract_ip_range [119] extract IP range from 10.0.0.1 >>>>>>>>>>>>>> extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 >>>>>>>>>>>>>> extract_ip_range [119] extract IP range from 10.1.0.1 >>>>>>>>>>>>>> extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 >>>>>>>>>>>>>> extract_mac_range [135] extract MAC range from >>>>>>>>>>>>>> a0:36:9f:0d:f0:98 >>>>>>>>>>>>>> extract_mac_range [150] a0:36:9f:0d:f0:98 starts at >>>>>>>>>>>>>> a0:36:9f:d:f0:98 >>>>>>>>>>>>>> extract_mac_range [135] extract MAC range from >>>>>>>>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>>>>>>>> extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at >>>>>>>>>>>>>> ff:ff:ff:ff:ff:ff >>>>>>>>>>>>>> main [1053] map size is 207712 Kb >>>>>>>>>>>>>> main [1059] Unable to get if info for eth2 >>>>>>>>>>>>>> main [1066] bad nthreads 1, have 0 queues >>>>>>>>>>>>>> main [1075] mmapping 207712 Kbytes >>>>>>>>>>>>>> main [1094] Unable to register interface eth2 >>>>>>>>>>>>>> Receiving from eth2: 0 queues, 1 threads and 1 cpus. >>>>>>>>>>>>>> main [1128] Wait 2 secs for phy reset >>>>>>>>>>>>>> main [1130] Ready... >>>>>>>>>>>>>> main [1181] Unable to register eth2 >>>>>>>>>>>>>> main [1242] 0 pps >>>>>>>>>>>>>> Received 0 packets, in 0.00 seconds. >>>>>>>>>>>>>> Speed: -nanpps. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Dmesg after trying to use pkt-gen on eth2: >>>>>>>>>>>>>> [175537.838503] ADDRCONF(NETDEV_UP): eth2: link is not = ready >>>>>>>>>>>>>> [175542.802288] ixgbe 0000:0c:00.0: eth2: NIC Link is Up = 10 >>>>>>>>>>>>>> Gbps, Flow Control: RX/TX >>>>>>>>>>>>>> [175542.802607] ADDRCONF(NETDEV_CHANGE): eth2: link = becomes >>>>>>>>>>>>>> ready >>>>>>>>>>>>>> [175553.256029] eth2: no IPv6 routers present >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Tahir Rauf >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Tahir Rauf >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> Tahir Rauf >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Tahir Rauf >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Tahir Rauf >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Tahir Rauf >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >> -- >> Tahir Rauf >>=20 >>=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 10:55:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C16F3629 for ; Fri, 22 Mar 2013 10:55:08 +0000 (UTC) (envelope-from david@dr.eclipse.co.uk) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4AF7CAF9 for ; Fri, 22 Mar 2013 10:55:07 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAHg0TFFSmf6C/2dsb2JhbABDhz5pvVCBXxZ0giQBAQEEAQEBICsgFwwDBAkEAwEBASgDAikBCRUJCAYBBwIFBAEHEwIEh3cIp0yHe5IwjWKBHxgGgieBEwOUJoNdhQEDimCDCjwygQU X-IPAS-Result: Ag4FAHg0TFFSmf6C/2dsb2JhbABDhz5pvVCBXxZ0giQBAQEEAQEBICsgFwwDBAkEAwEBASgDAikBCRUJCAYBBwIFBAEHEwIEh3cIp0yHe5IwjWKBHxgGgieBEwOUJoNdhQEDimCDCjwygQU X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208,217";a="6342417" Received: from unknown (HELO localhost) ([82.153.254.130]) by smtpout.karoo.kcom.com with ESMTP; 22 Mar 2013 10:43:49 +0000 Message-Id: <9b1e8e52c51fd9592fdbd13556744ce700a32b62@webmail.eclipse.net.uk> From: david@dr.eclipse.co.uk To: "Pieper Jeffrey E" , freebsd-net@FreeBSD.org X-Mailer: Atmail 6.3.5.8698 in-reply-to: <2A35EA60C3C77D438915767F458D65687D4639E3@ORSMSX101.amr.corp.intel.com> Subject: RE: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Date: Fri, 22 Mar 2013 10:43:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: david@dr.eclipse.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 10:55:08 -0000 =C2=A0=0A I'll try to arrange this but so far igb2/3 have been fine when= going=0Athrough the switch so tempted to take this as a solution.=0AWe= loose some switch ports but that is no great loss.=C2=A0 Going to put= =0Asome traffic through them over the weekend and see if they are still= =0Agood on Monday.=0A=0ADavid=0A=0A----- Original Message -----=0AFrom:= "Pieper Jeffrey E" =0ATo:"david@dr.eclipse.co.uk" , "freebsd-net@FreeBS= D.org" =0ACc:=0ASent:Fri, 22 Mar 2013 01:26:40 +0000=0ASubject:RE: Re: k= ern/177139: [igb] igb drops ethernet ports 2 and 3=0A=0A What Jack means= is to swap ports 0/1 with ports 2/3, so that 0/1 are=0AB2B with the oth= er i350 and ports 2/3 are connected to the switch. Do=0Athis on both sid= es. The reason for this is because there is a bridge=0Abetween ports 0/1= and 2/3, so it is possible that the bridge is=0Acausing problems when c= onnected B2B.=0A=0A Jeff=0A=0A -----Original Message-----=0A From: owner= -freebsd-net@freebsd.org=0A[mailto:owner-freebsd-net@freebsd.org] On Beh= alf Of=0Adavid@dr.eclipse.co.uk=0A Sent: Thursday, March 21, 2013 10:50= AM=0A To: freebsd-net@FreeBSD.org=0A Subject: Fwd: Re: kern/177139: [ig= b] igb drops ethernet ports 2 and=0A3=0A=0A The following reply was made= to PR kern/177139; it has been noted by=0AGNATS.=0A=0A From: david@dr.e= clipse.co.uk=0A To: bug-followup@FreeBSD.org=0A Cc: =0A Subject: Fwd: Re= : kern/177139: [igb] igb drops ethernet ports 2 and=0A3=0A Date: Thu, 21= Mar 2013 17:31:57 +0000=0A=0A --=3D_0e01cef1795d0a99970a4500053df16b=0A= Content-Type: text/plain; charset=3DUTF-8=0A Content-Transfer-Encoding:= quoted-printable=0A=0A It is an Intel I350-t4 nic to a I350-t4 nic.=3D0= AThe problem occurs at=0Abot=3D=0A h sides.=3D0ANot sure I follow your s= wap suggestion as both devices=0Ashould=3D=0A be=3D0Aidentical.=3D0A=3D0= ADavid=0A=0A --=3D_0e01cef1795d0a99970a4500053df16b=0A Content-Type: tex= t/html; charset=3DUTF-8=0A Content-Transfer-Encoding: quoted-printable= =0A=0A It is an Intel I350-t4 nic to a I350-t4 nic.The proble=3D=0A m oc= curs at both sides.Not sure I follow your swap suggestion as b=3D=0A oth= devices should be identical.David=0A=0A --=3D_0e01cef1795d0a99970a45000= 53df16b--=0A=0A _______________________________________________=0A freeb= sd-net@freebsd.org mailing list=0A http://lists.freebsd.org/mailman/list= info/freebsd-net=0A To unsubscribe, send any mail to=0A"freebsd-net-unsu= bscribe@freebsd.org"=0A From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 10:58:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C1E79771; Fri, 22 Mar 2013 10:58:53 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6568AB3B; Fri, 22 Mar 2013 10:58:53 +0000 (UTC) Received: from [195.68.67.65] (helo=yafree.ipfw.ru) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1UIzjo-000O67-Ml; Fri, 22 Mar 2013 15:02:20 +0400 Message-ID: <514C3952.2010903@ipfw.ru> Date: Fri, 22 Mar 2013 14:58:26 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120824 Thunderbird/14.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: MPLS References: <5146121B.5080608@FreeBSD.org> <514649A5.4090200@freebsd.org> <3659B942-7C37-431F-8945-C8A5BCD8DC67@ipfw.ru> <51471974.3090300@freebsd.org> In-Reply-To: <51471974.3090300@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Alexander V. Chernikov" , Sami Halabi , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 10:58:53 -0000 On 18.03.2013 17:41, Andre Oppermann wrote: > On 18.03.2013 13:20, Alexander V. Chernikov wrote: >> On 17.03.2013, at 23:54, Andre Oppermann wrote: >> >>> On 17.03.2013 19:57, Alexander V. Chernikov wrote: >>>> On 17.03.2013 13:20, Sami Halabi wrote: >>>>>> ITOH OpenBSD has a complete implementation of MPLS out of the >>>>>> box, maybe >>>> Their control plane code is mostly useless due to design approach >>>> (routing daemons talk via kernel). >>> >>> What's your approach? >> It is actually not mine. We have discussed this a bit in >> radix-related thread. Generally quagga/bird (and other hiperf >> hardware-accelerated and software routers) have feature-rich RIb from >> which best routes (possibly multipath) are installed to kernel/fib. >> Kernel main task should be to do efficient lookups while every other >> advanced feature should be implemented in userland. > > Yes, we have started discussing it but haven't reached a conclusion > among the > two philosophies. We have also agreed that the current radix code is > horrible > in terms of cache misses per lookup. That however doesn't preclude an > agnostic > FIB+RIB approach. It's mostly a matter of structure layout to keep it > efficient. Yes. Additionally, we have problems with misuse of rtalloc api (rte grabbing). My point of view is to use separate FIB for 'data plane' e.g. forwarding while keeping some kind of higher-level kernel RIB used for route socket, multipath, other subsystem intercation and so on. > >>>> Their data plane code, well.. Yes, we can use some defines from >>>> their headers, but that's all :) >>>>>> porting it would be short and more straight forward than porting >>>>>> linux LDP >>>>>> implementation of BIRD. >>>> >>>> It is not 'linux' implementation. LDP itself is cross-platform. >>>> The most tricky place here is control plane. >>>> However, making _fast_ MPLS switching is tricky too, since it >>>> requires chages in our netisr/ethernet >>>> handling code. >>> >>> Can you explain what changes you think are necessary and why? > > >> We definitely need ability to dispatch chain of mbufs - this was >> already discussed in intel rx ring lock thread in -net. > > Actually I'm not so convinced of that. Packet handling is a tradeoff > between Yes. But I'm talking on mixed way (one part as batches, to eliminate contentions, and than - process-to-completion) > doing process-to-completion on each packet and doing context switches > on batches > of packets. Context switches? Batches are efficient: it is noted explicitly in 1) Luigi's VALE paper http://info.iet.unipi.it/~luigi/papers/20121026-vale.pdf (Section 5.2) 2) Intel/6wind uses batches to move packets to their 'netisr' rings in their DPDK 3) PacketShader ( http://shader.kaist.edu/packetshader/ ) uses batches too. > > Every few years the balance tilts forth and back between > process-to-completion > and batch processing. DragonFly went with a batch-lite token-passing > approach > throughout their kernel. It seems it didn't work out to the extent > they expected. There are other, more successful solutions with _much_ better results (100x faster that our code, for example). > > Now many parts are moving back to the more traditional locking approach. > >> Currently significant number of drivers support interrupt moderation >> permitting several/tens/hundreds of packets to be received on interrupt. > > But they've also started to provide multiple queues. Yes, but hashing function is pre-defined, and bursty flows can still fall on single CPU. > >> For each packet we have to run some basic checks, PFIL hooks, netisr >> code, l3 code resulting in many locks being acquired/released per >> each packet. > > Right, on the other hand you'll likely run into serious interlock and > latency > issues when large batches of packets monopolize certain locks > preventing other > interfaces from sending their batches up. > >> Typically we rely on NIC to put packet in given queue (direct isr), >> which works bad for non-hashable types of traffic like gre, PPPoE, >> MPLS. Additionally, hashing function is either standard (from M$ >> NDIS) or documented permitting someone malicious to generate >> 'special' traffic matching single queue. > > Malicious traffic is always a problem, no matter how many queues you > have. > >> Currently even if we can add m2flowid/m2cpu function able to hash, >> say, gre or MPLS, it is unefficient since we have to lock/unlock >> netisr queues for every packet. > > Yes, however I'm arguing that our locking strategy may be broken or > sub-optimal. Various solution reports, say, 50MPPS (or scalable 10-15MPPS per-core) of IPv4 forwarding. Currenty stock kernel can do ~1MPPS. There are, of course, other reasons (structure alignment, radix, arp code), but the difference is _too_ huge. > >> I'm thinking of >> * utilizing m_nextpkt field in mbuf header > > OK. That's what it is there for. > >> * adding some nh_chain flag to netisr >> If given netisr does not support flag and nextpkt is not null we >> simply call such netisr in cycle. >> * netisr hash function accepts mbuf 'chain' and pointer to array >> (Sizeof N * ptr), sorts mbuf to N netisr queues saving list heads to >> supplied array. After that we put given lists to appropriate queues. >> * teach ethersubr RX code to deal with mbuf chains (not easy one) >> * add some partial support of handling chains to fastfwd code > > I really don't think this going to help much. You're just adding a > lot of > latency and context switches to while packet path. Also you're making it > much more complicated. > > The interface drivers and how they manage the boundary between RX ring > and > the stack is not optimal yet. I think there's a lot of potential > there. In > my tcp_workqueue branch I started to experiment with a couple of > approaches. > It's not complete yet though. > > The big advantage of having the interface RX thread pushing the > packets is > that it provides a natural feedback loop regarding system load. Once you > have more packets coming in than you can process, the RX dma ring gets > naturally starved and the load is stabilized on the input side preventing I see no difference here. > > a live-lock that can easily happen in batch mode. Only a well-adjusted > driver works properly though and we don't have any yet in that regard. That's true. > > > Before we start to invent complicated mbuf batching methods lets make > sure > that the single packet path at its maximal possible efficiency. And only > then evaluate more complicated approaches on whether they deliver > additional > gains. > > From that follows that we should: > > 1. fix longest prefix match radix to minimize cache misses. Personally I think that 'fix' is rewriting this entirely.. For example, common solution for IPv6 lookup is to use the fact that you have either /64 or wider routes, or host route, so radix lookup is done on first 64 bit (and there can be another tree in given element if there are several more specific routes). That's why I'm talking on RIB/fib approach (one common 'academic' implementation for control, and family-depended effective lookup code). We also need to fix fundamental rte usage paradigm, currently it is unsafe for both ingress and egress interface.. > > 2. fix drivers to optimize RX dequeuing and TX enqueuing. > > 3. have a critical look at other parts of the packet path to avoid For IPv4 fastforwarding we have: 1) RX ring mtx lock, (BPF rlock) (L3 PFIL in, FW lock), Ifaddr RLOCK, Radix Rlock, rte mtx_lock (twice by default), (L3 PFIL out, FW lock), ARP rlock, ARP entry rlock, TX ring lock? (And +2 rlocks for VLAN, and another 2 for LAGG) There was RX ring lock/unlock thead for 8299 ended with nothing. I've changed BPF 2 mtx_lock to be 1 RLOCK There are patches permitting IPFW to use PFIL lock (however they are not committed due to possibility that we can make lockless PFIL) I've removed 1 rte mtx_lock (dynamic routes, turned off if forwarding is ON) I'm working on ARP stack rewrite to (first stage to enable L2 multipath (lagg-aware) and remove ARP entry lock from forwarding path), second stage - to store pointer to full L2 prepend header to rte (yes, that was removed in 7.x)). I'm a bit stuck of other ideas to eliminate remaining locks (except of simply moving forwarding code to userland netmap-based solution like others do) > > From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 12:16:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C309EA1 for ; Fri, 22 Mar 2013 12:16:32 +0000 (UTC) (envelope-from walter.dedonato@unina.it) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by mx1.freebsd.org (Postfix) with ESMTP id 7BD612A0 for ; Fri, 22 Mar 2013 12:16:29 +0000 (UTC) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r2MBkFYr006148 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 22 Mar 2013 12:46:16 +0100 Received: by mail-vb0-f53.google.com with SMTP id fj18so2521111vbb.26 for ; Fri, 22 Mar 2013 04:46:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.74.34 with SMTP id q2mr1450145vdv.76.1363952774501; Fri, 22 Mar 2013 04:46:14 -0700 (PDT) Received: by 10.52.53.98 with HTTP; Fri, 22 Mar 2013 04:46:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Mar 2013 12:46:14 +0100 Message-ID: Subject: Re: Netmap ixgbe driver problem on 10Gbps X540-AT2 adapters (Linux only?) From: Walter de Donato To: Michio Honda Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 12:16:32 -0000 Thank you Michio, actually for me it was necessary to set -w 6 to avoid the adapter reset every second, but what I am observing is a big difference between what is being sent and what is being received on the other side, as reported in the following. This experiment relates to two separate Linux servers connected back to back with a CAT6 cable. Sender output: $ sudo ./pkt-gen -i eth2 -n 100000000 -w 6 -f tx extract_ip_range [136] extract IP range from 10.0.0.1 extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 extract_ip_range [136] extract IP range from 10.1.0.1 extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 extract_mac_range [177] extract MAC range from a0:36:9f:0d:f8:88 extract_mac_range [192] a0:36:9f:0d:f8:88 starts at a0:36:9f:d:f8:88 extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1401] map size is 334980 Kb main [1423] mapping 334980 Kbytes Sending on eth2: 16 queues, 1 threads and 1 cpus. 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f8:88 -> ff:ff:ff:ff:ff:ff) main [1477] Wait 6 secs for phy reset main [1479] Ready... sender_body [683] start sender_body [736] drop copy main_thread [1078] 8722463 pps (8731028 pkts in 1000982 usec) main_thread [1078] 8416235 pps (8425308 pkts in 1001078 usec) main_thread [1078] 8498540 pps (8506792 pkts in 1000971 usec) main_thread [1078] 9048765 pps (9058755 pkts in 1001104 usec) main_thread [1078] 9136045 pps (9138740 pkts in 1000295 usec) main_thread [1078] 9062717 pps (9069541 pkts in 1000753 usec) main_thread [1078] 8693680 pps (8703017 pkts in 1001074 usec) main_thread [1078] 8920226 pps (8930172 pkts in 1001115 usec) main_thread [1078] 8879883 pps (8882067 pkts in 1000246 usec) main_thread [1078] 9060322 pps (9070343 pkts in 1001106 usec) main_thread [1078] 9086352 pps (9096556 pkts in 1001123 usec) main_thread [1078] 2384776 pps (2387681 pkts in 1001218 usec) Sent 100000000 packets, 60 bytes each, in 11.27 seconds. Speed: 8.87 Mpps Bandwidth: 4.26 Gbps (raw 5.96 Gbps) Receiver output: $ sudo ./pkt-gen -f rx -i eth2 -w 6 extract_ip_range [136] extract IP range from 10.0.0.1 extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 extract_ip_range [136] extract IP range from 10.1.0.1 extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 extract_mac_range [192] a0:36:9f:0d:f0:98 starts at a0:36:9f:d:f0:98 extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff main [1401] map size is 334980 Kb main [1423] mapping 334980 Kbytes Receiving from eth2: 4 queues, 1 threads and 1 cpus. main [1477] Wait 6 secs for phy reset main [1479] Ready... main_thread [1078] 0 pps (0 pkts in 1001034 usec) receiver_body [833] waiting for initial packets, poll returns 0 0 main_thread [1078] 0 pps (0 pkts in 1001028 usec) receiver_body [833] waiting for initial packets, poll returns 0 0 main_thread [1078] 322409 pps (324924 pkts in 1007802 usec) main_thread [1078] 339256 pps (340996 pkts in 1005129 usec) main_thread [1078] 339305 pps (345252 pkts in 1017528 usec) main_thread [1078] 339285 pps (341276 pkts in 1005868 usec) main_thread [1078] 339284 pps (340752 pkts in 1004326 usec) main_thread [1078] 339271 pps (341316 pkts in 1006028 usec) main_thread [1078] 339276 pps (344396 pkts in 1015090 usec) main_thread [1078] 339271 pps (341420 pkts in 1006335 usec) main_thread [1078] 339293 pps (340960 pkts in 1004914 usec) main_thread [1078] 339291 pps (341528 pkts in 1006594 usec) main_thread [1078] 339270 pps (344080 pkts in 1014177 usec) main_thread [1078] 185293 pps (185491 pkts in 1001068 usec) main_thread [1078] 0 pps (0 pkts in 1001085 usec) Received 3932391 packets, in 11.59 seconds. Speed: 339.29 Kpps -Walter 2013/3/22 Michio Honda > You need to specify "-w 4" on running pkt-gen to wait for that the link > resets. > > Cheers, > - Michio > > On Mar 22, 2013, at 11:16 AM, Walter de Donato wrote: > > > Dear Tahir, > > > > I've already tried to disable Rx/Tx pause and autonegotiation but the > > result in transmission is always the same. > > > > I did the following: > > $ sudo ifconfig eth2 up > > $ sudo ethtool -A eth2 autoneg off > > $ sudo ethtool -A eth2 rx off > > $ sudo ethtool -A eth2 tx off > > > > These are the resulting dmesg output lines: > > [253131.445124] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > > Control: RX/TX > > [253147.935426] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > > Control: TX > > [253163.930776] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > > Control: None > > > > Here is what I obtain: > > $ sudo ./pkt-gen -i eth2 -n 100000 -f tx > > extract_ip_range [136] extract IP range from 10.0.0.1 > > extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 > > extract_ip_range [136] extract IP range from 10.1.0.1 > > extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 > > extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 > > extract_mac_range [192] a0:36:9f:0d:f0:98 starts at a0:36:9f:d:f0:98 > > extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff > > extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at ff:ff:ff:ff:ff:ff > > main [1401] map size is 334980 Kb > > main [1423] mapping 334980 Kbytes > > Sending on eth2: 4 queues, 1 threads and 1 cpus. > > 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) > > main [1477] Wait 2 secs for phy reset > > main [1479] Ready... > > sender_body [683] start > > main_thread [1078] 7155 pps (7162 pkts in 1001020 usec) > > main_thread [1078] 3484 pps (3488 pkts in 1001030 usec) > > main_thread [1078] 3487 pps (3491 pkts in 1001024 usec) > > main_thread [1078] 3466 pps (3469 pkts in 1000847 usec) > > main_thread [1078] 3485 pps (3490 pkts in 1001521 usec) > > main_thread [1078] 3322 pps (3328 pkts in 1001765 usec) > > main_thread [1078] 3293 pps (3297 pkts in 1001322 usec) > > main_thread [1078] 3492 pps (3498 pkts in 1001763 usec) > > main_thread [1078] 3485 pps (3489 pkts in 1001168 usec) > > main_thread [1078] 3351 pps (3356 pkts in 1001402 usec) > > main_thread [1078] 3297 pps (3301 pkts in 1001314 usec) > > main_thread [1078] 3933 pps (3938 pkts in 1001390 usec) > > main_thread [1078] 3481 pps (3486 pkts in 1001528 usec) > > main_thread [1078] 3493 pps (3497 pkts in 1001177 usec) > > main_thread [1078] 3310 pps (3314 pkts in 1001292 usec) > > main_thread [1078] 3485 pps (3491 pkts in 1001812 usec) > > main_thread [1078] 3326 pps (3331 pkts in 1001547 usec) > > main_thread [1078] 3480 pps (3485 pkts in 1001456 usec) > > main_thread [1078] 3489 pps (3493 pkts in 1001209 usec) > > main_thread [1078] 3377 pps (3381 pkts in 1001040 usec) > > main_thread [1078] 3450 pps (3454 pkts in 1001048 usec) > > main_thread [1078] 3378 pps (3382 pkts in 1001050 usec) > > main_thread [1078] 3470 pps (3474 pkts in 1001052 usec) > > main_thread [1078] 3323 pps (3327 pkts in 1001056 usec) > > main_thread [1078] 3482 pps (3486 pkts in 1001050 usec) > > main_thread [1078] 3472 pps (3476 pkts in 1001066 usec) > > main_thread [1078] 3497 pps (3501 pkts in 1001044 usec) > > main_thread [1078] 3115 pps (3115 pkts in 1000035 usec) > > main_thread [1078] 0 pps (0 pkts in 1001057 usec) > > Sent 100000 packets, 60 bytes each, in 28.42 seconds. > > Speed: 3.52 Kpps Bandwidth: 1.69 Mbps (raw 2.36 Mbps) > > > > While executing pkt-gen I see the following dmesg output lines: > > [253741.892031] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253742.874686] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253743.864635] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253744.854513] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253745.844527] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253746.830323] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253747.821223] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253748.813229] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253749.804317] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253750.794286] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253751.784302] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253752.774324] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253753.764258] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253754.753735] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253755.748011] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253756.734927] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253757.724876] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253758.713267] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253759.704793] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253760.694759] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253761.684743] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253762.674699] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253763.664642] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253764.654488] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253765.644462] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253766.634425] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253767.624392] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253768.614364] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253769.611107] ixgbe 0000:0c:00.0: eth2: Reset adapter > > [253769.715298] 893.960705 netmap_ring_reinit [966] called for eth2 > > [253769.716646] 893.962054 netmap_ring_reinit [966] called for eth2 > > [253769.725844] 893.971252 netmap_ioctl [1236] deprecated, data is > ded4df20 > > [253776.141936] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 Gbps, Flow > > Control: None > > > > It seems that the adapter is reset every second, but no packet goes on > the > > wire. > > > > I'm starting to look into the code to investigate this issue. > > If you have any suggestion on where to look at it would save me a lot of > > time. > > > > I also rechecked the rx mode. > > It is working at least up to 50Kpps (as I'm generation on the other side > > with nping and the original driver). > > Pkg-gen/netmap is configured to receive only the frames directed to the > > physical MAC address of the interface. > > I don't know if and how a promiscuous mode can be enabled with netmap. > > > > Thanks, > > -Walter > > 2013/3/22 Tahir Rauf > > > >> Dear Walter, > >> > >> Can you please disable Rx/Tx pause frames on your NIC. You can use > >> "ethtool" to do so. Please run the example again after disabling Rx/Tx > >> frames and let me know about the results. > >> > >> Regards > >> > >> > >> On Thu, Mar 21, 2013 at 8:20 PM, Walter de Donato < > >> walter.dedonato@gmail.com> wrote: > >> > >>> Not that lucky since my first goal is to transmit packets... > >>> I also noticed that the same car d is configured with 4 rings on 32bit > >>> kernels and 16 rings on 64bit kernels. > >>> Do you have any idea to explain this difference? > >>> > >>> -Walter > >>> > >>> 2013/3/21 Tahir Rauf > >>> > >>>> Dear Walter, > >>>> > >>>> You are lucky to have* X540-AT2 :). *Mine is different (82598EB) and > >>>> can't receive packets properly. > >>>> Yes, my tx is working and is able to send packets on line rate. > >>>> > >>>> Regards > >>>> > >>>> > >>>> On Thu, Mar 21, 2013 at 8:04 PM, Walter de Donato < > >>>> walter.dedonato@gmail.com> wrote: > >>>> > >>>>> Here is the lshw output: > >>>>> > >>>>> *-network:0 > >>>>> description: Ethernet interface > >>>>> product: Ethernet Controller 10 Gigabit X540-AT2 > >>>>> vendor: Intel Corporation > >>>>> physical id: 0 > >>>>> bus info: pci@0000:0c:00.0 > >>>>> logical name: eth2 > >>>>> version: 01 > >>>>> serial: a0:36:9f:0d:f0:98 > >>>>> capacity: 1Gbit/s > >>>>> width: 64 bits > >>>>> clock: 33MHz > >>>>> capabilities: pm msi msix pciexpress vpd bus_master cap_list > rom > >>>>> ethernet physical tp 100bt-fd 1000bt-fd autonegotiation > >>>>> configuration: autonegotiation=on broadcast=yes driver=ixgbe > >>>>> driverversion=3.6.7-k duplex=full firmware=0x800002ef latency=0 > link=yes > >>>>> multicast=yes port=twisted pair > >>>>> resources: irq:17 memory:d8400000-d85fffff > >>>>> memory:d83fc000-d83fffff memory:fc500000-fc57ffff > memory:fc400000-fc4fffff > >>>>> *-network:1 > >>>>> description: Ethernet interface > >>>>> product: Ethernet Controller 10 Gigabit X540-AT2 > >>>>> vendor: Intel Corporation > >>>>> physical id: 0.1 > >>>>> bus info: pci@0000:0c:00.1 > >>>>> logical name: eth3 > >>>>> version: 01 > >>>>> serial: a0:36:9f:0d:f0:9a > >>>>> capacity: 1Gbit/s > >>>>> width: 64 bits > >>>>> clock: 33MHz > >>>>> capabilities: pm msi msix pciexpress vpd bus_master cap_list > rom > >>>>> ethernet physical tp 100bt-fd 1000bt-fd autonegotiation > >>>>> configuration: autonegotiation=on broadcast=yes driver=ixgbe > >>>>> driverversion=3.6.7-k duplex=full firmware=0x800002ef ip=192.168.78.2 > >>>>> latency=0 link=yes multicast=yes port=twisted pair > >>>>> resources: irq:16 memory:d8000000-d81fffff > >>>>> memory:d83f8000-d83fbfff memory:d8200000-d827ffff > >>>>> > >>>>> Did you check if in tx mode your pkt-gen effectively sends the > packets > >>>>> on the wire? > >>>>> What rates are you observing with it? > >>>>> > >>>>> -Walter > >>>>> > >>>>> 2013/3/21 Tahir Rauf > >>>>> > >>>>>> Dear walter, > >>>>>> > >>>>>> Can you please run following command to get your NIC information. > >>>>>> sudo lshw -class network > >>>>>> > >>>>>> I have *82598EB *10GB AF dual port network connection NIC and my rx > >>>>>> is not working. > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> > >>>>>> On Thu, Mar 21, 2013 at 7:46 PM, Walter de Donato < > >>>>>> walter.dedonato@gmail.com> wrote: > >>>>>> > >>>>>>> I tried the rx command and it seems to work: > >>>>>>> $ sudo ./pkt-gen -i eth3 -f rx -n 100000 -l 60 -w 1 > >>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 > >>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 > >>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 > >>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 > >>>>>>> extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:9a > >>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:9a starts at > a0:36:9f:d:f0:9a > >>>>>>> extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff > >>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at > ff:ff:ff:ff:ff:ff > >>>>>>> main [1401] map size is 334980 Kb > >>>>>>> main [1423] mapping 334980 Kbytes > >>>>>>> Receiving from eth3: 4 queues, 1 threads and 1 cpus. > >>>>>>> main [1477] Wait 1 secs for phy reset > >>>>>>> main [1479] Ready... > >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001020 usec) > >>>>>>> receiver_body [833] waiting for initial packets, poll returns 0 0 > >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001059 usec) > >>>>>>> receiver_body [833] waiting for initial packets, poll returns 0 0 > >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001047 usec) > >>>>>>> receiver_body [833] waiting for initial packets, poll returns 0 0 > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001118 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001040 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001038 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001030 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001028 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001051 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001068 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001040 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001035 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001042 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001083 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001050 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001073 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001052 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001041 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001051 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001058 usec) > >>>>>>> main_thread [1078] 1 pps (1 pkts in 1001020 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001021 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001022 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001072 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001020 usec) > >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001041 usec) > >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001023 usec) > >>>>>>> main_thread [1078] 4 pps (4 pkts in 1001025 usec) > >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001032 usec) > >>>>>>> main_thread [1078] 3 pps (3 pkts in 1001058 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001042 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001018 usec) > >>>>>>> main_thread [1078] 2 pps (2 pkts in 1001024 usec) > >>>>>>> main_thread [1078] 0 pps (0 pkts in 1001058 usec) > >>>>>>> Received 58 packets, in 29.16 seconds. > >>>>>>> Speed: 1.99 pps > >>>>>>> > >>>>>>> > >>>>>>> The proble is that on the other side I had to use ping instead of > >>>>>>> pkt-gen. > >>>>>>> > >>>>>>> If I try to use pkt-gen I don't receive any packet. > >>>>>>> I just checked that pkt-gen is not effectively sending the packets > on > >>>>>>> the wire, > >>>>>>> on the other side using tcpdump I don't receive any packet. > >>>>>>> > >>>>>>> So the problem on the tx side has not been completely solved in my > >>>>>>> case. > >>>>>>> Can you do the same test please? > >>>>>>> > >>>>>>> -Walter > >>>>>>> > >>>>>>> 2013/3/21 Tahir Rauf > >>>>>>> > >>>>>>>> Dear Walter, > >>>>>>>> > >>>>>>>> What about the Rx, Can you please try and inform me. > >>>>>>>> sudo ./pkt-gen -i eth2 -f rx -n 100000 -l 60 -w 1 > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> > >>>>>>>> On Thu, Mar 21, 2013 at 7:06 PM, Walter de Donato < > >>>>>>>> walter.dedonato@gmail.com> wrote: > >>>>>>>> > >>>>>>>>> Thanks Thair, > >>>>>>>>> > >>>>>>>>> with the fixed version the interface correctly attaches to the > >>>>>>>>> netmap driver and it is able to transmit packets. > >>>>>>>>> > >>>>>>>>> Anyway, I'm observing really poor performance: > >>>>>>>>> $ sudo ./pkt-gen -i eth2 -f tx -n 100000 -l 60 -w 1 > >>>>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 > >>>>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 > >>>>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 > >>>>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 > >>>>>>>>> extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 > >>>>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:98 starts at > a0:36:9f:d:f0:98 > >>>>>>>>> extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff > >>>>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at > >>>>>>>>> ff:ff:ff:ff:ff:ff > >>>>>>>>> main [1401] map size is 334980 Kb > >>>>>>>>> main [1423] mapping 334980 Kbytes > >>>>>>>>> Sending on eth2: 4 queues, 1 threads and 1 cpus. > >>>>>>>>> 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) > >>>>>>>>> main [1477] Wait 1 secs for phy reset > >>>>>>>>> main [1479] Ready... > >>>>>>>>> sender_body [683] start > >>>>>>>>> main_thread [1078] 7101 pps (7108 pkts in 1001019 usec) > >>>>>>>>> main_thread [1078] 3482 pps (3486 pkts in 1001031 usec) > >>>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001026 usec) > >>>>>>>>> main_thread [1078] 3483 pps (3487 pkts in 1001026 usec) > >>>>>>>>> main_thread [1078] 3340 pps (3343 pkts in 1001019 usec) > >>>>>>>>> main_thread [1078] 3455 pps (3459 pkts in 1001025 usec) > >>>>>>>>> main_thread [1078] 3493 pps (3497 pkts in 1001024 usec) > >>>>>>>>> main_thread [1078] 3494 pps (3498 pkts in 1001022 usec) > >>>>>>>>> main_thread [1078] 3353 pps (3357 pkts in 1001056 usec) > >>>>>>>>> main_thread [1078] 3488 pps (3492 pkts in 1001093 usec) > >>>>>>>>> main_thread [1078] 3474 pps (3478 pkts in 1001064 usec) > >>>>>>>>> main_thread [1078] 3485 pps (3489 pkts in 1001102 usec) > >>>>>>>>> main_thread [1078] 3479 pps (3483 pkts in 1001064 usec) > >>>>>>>>> main_thread [1078] 3335 pps (3339 pkts in 1001111 usec) > >>>>>>>>> main_thread [1078] 3484 pps (3488 pkts in 1001074 usec) > >>>>>>>>> main_thread [1078] 3484 pps (3488 pkts in 1001030 usec) > >>>>>>>>> main_thread [1078] 3470 pps (3474 pkts in 1001046 usec) > >>>>>>>>> main_thread [1078] 3486 pps (3490 pkts in 1001040 usec) > >>>>>>>>> main_thread [1078] 3482 pps (3486 pkts in 1001035 usec) > >>>>>>>>> main_thread [1078] 3278 pps (3281 pkts in 1001045 usec) > >>>>>>>>> main_thread [1078] 3476 pps (3480 pkts in 1001021 usec) > >>>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001036 usec) > >>>>>>>>> main_thread [1078] 3477 pps (3481 pkts in 1001083 usec) > >>>>>>>>> main_thread [1078] 3493 pps (3497 pkts in 1001048 usec) > >>>>>>>>> main_thread [1078] 3353 pps (3357 pkts in 1001082 usec) > >>>>>>>>> main_thread [1078] 3490 pps (3494 pkts in 1001051 usec) > >>>>>>>>> main_thread [1078] 3465 pps (3469 pkts in 1001060 usec) > >>>>>>>>> main_thread [1078] 3008 pps (3011 pkts in 1001030 usec) > >>>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001039 usec) > >>>>>>>>> Sent 100000 packets, 60 bytes each, in 28.58 seconds. > >>>>>>>>> Speed: 3.50 Kpps Bandwidth: 1.68 Mbps (raw 2.35 Mbps) > >>>>>>>>> > >>>>>>>>> With the rtl8169 1G driver (which they say to have the worst > >>>>>>>>> performance) > >>>>>>>>> I easily obtained Speed: 359.24Kpps. Bandwidth: 172.44Mbps with > 64 > >>>>>>>>> bytes packets. > >>>>>>>>> > >>>>>>>>> Also, if I increase the packet size this is what happens: > >>>>>>>>> $ sudo ./pkt-gen -i eth2 -f tx -t 1000000 -l 508 > >>>>>>>>> main [1270] -t deprecated, please use -f tx -n 1000000 > >>>>>>>>> extract_ip_range [136] extract IP range from 10.0.0.1 > >>>>>>>>> extract_ip_range [171] range is 10.0.0.1 0 to 10.0.0.1 0 > >>>>>>>>> extract_ip_range [136] extract IP range from 10.1.0.1 > >>>>>>>>> extract_ip_range [171] range is 10.1.0.1 0 to 10.1.0.1 0 > >>>>>>>>> extract_mac_range [177] extract MAC range from a0:36:9f:0d:f0:98 > >>>>>>>>> extract_mac_range [192] a0:36:9f:0d:f0:98 starts at > a0:36:9f:d:f0:98 > >>>>>>>>> extract_mac_range [177] extract MAC range from ff:ff:ff:ff:ff:ff > >>>>>>>>> extract_mac_range [192] ff:ff:ff:ff:ff:ff starts at > >>>>>>>>> ff:ff:ff:ff:ff:ff > >>>>>>>>> main [1401] map size is 334980 Kb > >>>>>>>>> main [1423] mapping 334980 Kbytes > >>>>>>>>> Sending on eth2: 4 queues, 1 threads and 1 cpus. > >>>>>>>>> 10.0.0.1 -> 10.1.0.1 (a0:36:9f:0d:f0:98 -> ff:ff:ff:ff:ff:ff) > >>>>>>>>> main [1477] Wait 2 secs for phy reset > >>>>>>>>> main [1479] Ready... > >>>>>>>>> sender_body [683] start > >>>>>>>>> main_thread [1078] 2042 pps (2044 pkts in 1001016 usec) > >>>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001049 usec) > >>>>>>>>> sender_body [729] poll error/timeout on queue 0 > >>>>>>>>> main_thread [1078] 0 pps (0 pkts in 1001035 usec) > >>>>>>>>> main_thread [1096] ouch, thread 0 exited with error > >>>>>>>>> Sent 2044 packets, 508 bytes each, in -1363874673.38 seconds. > >>>>>>>>> Speed: -0.00 pps Bandwidth: -0.01 bps (raw -0.01 bps) > >>>>>>>>> > >>>>>>>>> Don't you experience the same issues? > >>>>>>>>> > >>>>>>>>> -Walter > >>>>>>>>> > >>>>>>>>> 2013/3/21 Tahir Rauf > >>>>>>>>> > >>>>>>>>>> Dear Walter, > >>>>>>>>>> > >>>>>>>>>> Please try following code. > >>>>>>>>>> http://info.iet.unipi.it/~luigi/doc/20130217-netmap.tgz > >>>>>>>>>> It will fix your problem with Ixgbe tx function. > >>>>>>>>>> > >>>>>>>>>> Please let me know, if you encounter any problem. > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Thu, Mar 21, 2013 at 6:28 PM, Walter de Donato < > >>>>>>>>>> walter.dedonato@gmail.com> wrote: > >>>>>>>>>> > >>>>>>>>>>> Dear Tahir, > >>>>>>>>>>> > >>>>>>>>>>> thank you for the prompt reply. > >>>>>>>>>>> I downloaded the source code from the official website: > >>>>>>>>>>> http://info.iet.unipi.it/~luigi/doc/20120813-netmap.tgz > >>>>>>>>>>> Can you please share with me the fix about the tx function? > >>>>>>>>>>> I was just starting to look at the patched code of the drivers. > >>>>>>>>>>> > >>>>>>>>>>> Thanks in advance, > >>>>>>>>>>> -Walter > >>>>>>>>>>> > >>>>>>>>>>> 2013/3/21 Tahir Rauf > >>>>>>>>>>> > >>>>>>>>>>>> Hi dedonato, > >>>>>>>>>>>> > >>>>>>>>>>>> I just observed that you are having trouble with tx function > of > >>>>>>>>>>>> pkt-gen. Whereas, we already have fixed that problem. We are > facing issues > >>>>>>>>>>>> with rx only now. > >>>>>>>>>>>> Please tell me that from where you get the code of netmap? > >>>>>>>>>>>> > >>>>>>>>>>>> Regards > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Mar 21, 2013 at 5:49 PM, Tahir Rauf < > >>>>>>>>>>>> tahir.rauf1@gmail.com> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Dear Walter, > >>>>>>>>>>>>> > >>>>>>>>>>>>> I tried to fix the problem but i don't have any success yet. > >>>>>>>>>>>>> Also if you are trying to fix this problem, please share with > >>>>>>>>>>>>> me that which path you are going to take for fixing. It > might be possible > >>>>>>>>>>>>> that I already have tried that path. In that case, I can > share my results > >>>>>>>>>>>>> with you, thus saving your time. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Thu, Mar 21, 2013 at 5:08 PM, > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Dear Tahir and Luigi, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I have exactly the same problem with a similar hardware/os > >>>>>>>>>>>>>> configuration reported in the following. > >>>>>>>>>>>>>> Do you hav any uptade on this issue? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> -Walter > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Netmap version: 20120813 > >>>>>>>>>>>>>> OS: Ubuntu 12.04.2 LTS > >>>>>>>>>>>>>> Kernel: 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 > >>>>>>>>>>>>>> 12:39:51 UTC 2013 i686 i686 i386 GNU/Linux > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Network interfaces: > >>>>>>>>>>>>>> eth2 > >>>>>>>>>>>>>> 0c:00.0 Ethernet controller: Intel Corporation Ethernet > >>>>>>>>>>>>>> Controller 10 Gigabit X540-AT2 (rev 01) > >>>>>>>>>>>>>> Subsystem: Intel Corporation Ethernet 10G 2P X540-t > >>>>>>>>>>>>>> Adapter > >>>>>>>>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 17 > >>>>>>>>>>>>>> Memory at d8400000 (64-bit, prefetchable) [size=2M] > >>>>>>>>>>>>>> Memory at d83fc000 (64-bit, prefetchable) [size=16K] > >>>>>>>>>>>>>> Expansion ROM at fc500000 [disabled] [size=512K] > >>>>>>>>>>>>>> Capabilities: [40] Power Management version 3 > >>>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ > >>>>>>>>>>>>>> 64bit+ > >>>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=64 Masked- > >>>>>>>>>>>>>> Capabilities: [a0] Express Endpoint, MSI 00 > >>>>>>>>>>>>>> Capabilities: [e0] Vital Product Data > >>>>>>>>>>>>>> Capabilities: [100] Advanced Error Reporting > >>>>>>>>>>>>>> Capabilities: [140] Device Serial Number > >>>>>>>>>>>>>> a0-36-9f-ff-ff-0d-f0-98 > >>>>>>>>>>>>>> Capabilities: [150] Alternative Routing-ID > >>>>>>>>>>>>>> Interpretation (ARI) > >>>>>>>>>>>>>> Capabilities: [160] Single Root I/O Virtualization > >>>>>>>>>>>>>> (SR-IOV) > >>>>>>>>>>>>>> Capabilities: [1d0] Access Control Services > >>>>>>>>>>>>>> Kernel driver in use: ixgbe > >>>>>>>>>>>>>> Kernel modules: ixgbe > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> eth3 > >>>>>>>>>>>>>> 0c:00.1 Ethernet controller: Intel Corporation Ethernet > >>>>>>>>>>>>>> Controller 10 Gigabit X540-AT2 (rev 01) > >>>>>>>>>>>>>> Subsystem: Intel Corporation Ethernet 10G 2P X540-t > >>>>>>>>>>>>>> Adapter > >>>>>>>>>>>>>> Flags: bus master, fast devsel, latency 0, IRQ 16 > >>>>>>>>>>>>>> Memory at d8000000 (64-bit, prefetchable) [size=2M] > >>>>>>>>>>>>>> Memory at d83f8000 (64-bit, prefetchable) [size=16K] > >>>>>>>>>>>>>> Expansion ROM at d8200000 [disabled] [size=512K] > >>>>>>>>>>>>>> Capabilities: [40] Power Management version 3 > >>>>>>>>>>>>>> Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ > >>>>>>>>>>>>>> 64bit+ > >>>>>>>>>>>>>> Capabilities: [70] MSI-X: Enable+ Count=64 Masked- > >>>>>>>>>>>>>> Capabilities: [a0] Express Endpoint, MSI 00 > >>>>>>>>>>>>>> Capabilities: [e0] Vital Product Data > >>>>>>>>>>>>>> Capabilities: [100] Advanced Error Reporting > >>>>>>>>>>>>>> Capabilities: [140] Device Serial Number > >>>>>>>>>>>>>> a0-36-9f-ff-ff-0d-f0-98 > >>>>>>>>>>>>>> Capabilities: [150] Alternative Routing-ID > >>>>>>>>>>>>>> Interpretation (ARI) > >>>>>>>>>>>>>> Capabilities: [160] Single Root I/O Virtualization > >>>>>>>>>>>>>> (SR-IOV) > >>>>>>>>>>>>>> Capabilities: [1d0] Access Control Services > >>>>>>>>>>>>>> Kernel driver in use: ixgbe > >>>>>>>>>>>>>> Kernel modules: ixgbe > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> After loading the modules this is the (interesting) lsmod > >>>>>>>>>>>>>> output: > >>>>>>>>>>>>>> $ lsmod > >>>>>>>>>>>>>> Module Size Used by > >>>>>>>>>>>>>> ixgbe 160150 0 > >>>>>>>>>>>>>> netmap_lin 102855 1 ixgbe > >>>>>>>>>>>>>> dca 14728 1 ixgbe > >>>>>>>>>>>>>> mdio 13559 1 ixgbe > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> And the following is the (interesting) dmesg output: > >>>>>>>>>>>>>> [175397.625200] 521.870604 netmap_new_obj_allocator [426] > >>>>>>>>>>>>>> objsize 1024 clustsize 4096 objects 4 > >>>>>>>>>>>>>> [175397.625501] 521.870912 netmap_new_obj_allocator [504] > >>>>>>>>>>>>>> Pre-allocated 128 clusters (4/512KB) for 'netmap_if' > >>>>>>>>>>>>>> [175397.625653] 521.871065 netmap_new_obj_allocator [426] > >>>>>>>>>>>>>> objsize 36864 clustsize 36864 objects 1 > >>>>>>>>>>>>>> [175397.629906] 521.875312 netmap_new_obj_allocator [504] > >>>>>>>>>>>>>> Pre-allocated 200 clusters (36/7200KB) for 'netmap_ring' > >>>>>>>>>>>>>> [175397.630064] 521.875477 netmap_new_obj_allocator [426] > >>>>>>>>>>>>>> objsize 2048 clustsize 4096 objects 2 > >>>>>>>>>>>>>> [175397.708572] 521.953976 netmap_new_obj_allocator [504] > >>>>>>>>>>>>>> Pre-allocated 50000 clusters (4/200000KB) for 'netmap_buf' > >>>>>>>>>>>>>> [175397.708737] 521.954147 netmap_memory_init [554] Have 512 > >>>>>>>>>>>>>> KB for interfaces, 7200 KB for rings and 195 MB for buffers > >>>>>>>>>>>>>> [175397.708885] netmap: loaded module with 202 Mbytes > >>>>>>>>>>>>>> [175418.013476] ixgbe: Intel(R) 10 Gigabit PCI Express > Network > >>>>>>>>>>>>>> Driver - version 3.6.7-k > >>>>>>>>>>>>>> [175418.013479] ixgbe: Copyright (c) 1999-2011 Intel > >>>>>>>>>>>>>> Corporation. > >>>>>>>>>>>>>> [175418.013531] ixgbe 0000:0c:00.0: PCI INT B -> GSI 17 > >>>>>>>>>>>>>> (level, low) -> IRQ 17 > >>>>>>>>>>>>>> [175418.013543] ixgbe 0000:0c:00.0: setting latency timer > to 64 > >>>>>>>>>>>>>> [175418.425782] ixgbe 0000:0c:00.0: irq 271 for MSI/MSI-X > >>>>>>>>>>>>>> [175418.425791] ixgbe 0000:0c:00.0: irq 272 for MSI/MSI-X > >>>>>>>>>>>>>> [175418.425798] ixgbe 0000:0c:00.0: irq 273 for MSI/MSI-X > >>>>>>>>>>>>>> [175418.425806] ixgbe 0000:0c:00.0: irq 274 for MSI/MSI-X > >>>>>>>>>>>>>> [175418.425813] ixgbe 0000:0c:00.0: irq 275 for MSI/MSI-X > >>>>>>>>>>>>>> [175418.425829] ixgbe 0000:0c:00.0: Multiqueue Enabled: Rx > >>>>>>>>>>>>>> Queue count = 4, Tx Queue count = 4 > >>>>>>>>>>>>>> [175418.485972] ixgbe 0000:0c:00.0: (PCI > Express:2.5GT/s:Width > >>>>>>>>>>>>>> x8) a0:36:9f:0d:f0:98 > >>>>>>>>>>>>>> [175418.646372] ixgbe 0000:0c:00.0: MAC: 3, PHY: 3, PBA No: > >>>>>>>>>>>>>> G44743-006 > >>>>>>>>>>>>>> [175418.788262] ixgbe 0000:0c:00.0: Intel(R) 10 Gigabit > >>>>>>>>>>>>>> Network Connection > >>>>>>>>>>>>>> [175418.788285] ixgbe 0000:0c:00.1: PCI INT A -> GSI 16 > >>>>>>>>>>>>>> (level, low) -> IRQ 16 > >>>>>>>>>>>>>> [175418.788296] ixgbe 0000:0c:00.1: setting latency timer > to 64 > >>>>>>>>>>>>>> [175419.213734] ixgbe 0000:0c:00.1: irq 276 for MSI/MSI-X > >>>>>>>>>>>>>> [175419.213742] ixgbe 0000:0c:00.1: irq 277 for MSI/MSI-X > >>>>>>>>>>>>>> [175419.213750] ixgbe 0000:0c:00.1: irq 278 for MSI/MSI-X > >>>>>>>>>>>>>> [175419.213758] ixgbe 0000:0c:00.1: irq 279 for MSI/MSI-X > >>>>>>>>>>>>>> [175419.213766] ixgbe 0000:0c:00.1: irq 280 for MSI/MSI-X > >>>>>>>>>>>>>> [175419.213782] ixgbe 0000:0c:00.1: Multiqueue Enabled: Rx > >>>>>>>>>>>>>> Queue count = 4, Tx Queue count = 4 > >>>>>>>>>>>>>> [175419.273937] ixgbe 0000:0c:00.1: (PCI > Express:2.5GT/s:Width > >>>>>>>>>>>>>> x8) a0:36:9f:0d:f0:9a > >>>>>>>>>>>>>> [175419.434299] ixgbe 0000:0c:00.1: MAC: 3, PHY: 3, PBA No: > >>>>>>>>>>>>>> G44743-006 > >>>>>>>>>>>>>> [175419.576197] ixgbe 0000:0c:00.1: Intel(R) 10 Gigabit > >>>>>>>>>>>>>> Network Connection > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> This is the pkt-gen output: > >>>>>>>>>>>>>> $ sudo ./pkt-gen -i eth2 tx -n 10000 > >>>>>>>>>>>>>> extract_ip_range [119] extract IP range from 10.0.0.1 > >>>>>>>>>>>>>> extract_ip_range [129] 10.0.0.1 starts at 10.0.0.1 > >>>>>>>>>>>>>> extract_ip_range [119] extract IP range from 10.1.0.1 > >>>>>>>>>>>>>> extract_ip_range [129] 10.1.0.1 starts at 10.1.0.1 > >>>>>>>>>>>>>> extract_mac_range [135] extract MAC range from > >>>>>>>>>>>>>> a0:36:9f:0d:f0:98 > >>>>>>>>>>>>>> extract_mac_range [150] a0:36:9f:0d:f0:98 starts at > >>>>>>>>>>>>>> a0:36:9f:d:f0:98 > >>>>>>>>>>>>>> extract_mac_range [135] extract MAC range from > >>>>>>>>>>>>>> ff:ff:ff:ff:ff:ff > >>>>>>>>>>>>>> extract_mac_range [150] ff:ff:ff:ff:ff:ff starts at > >>>>>>>>>>>>>> ff:ff:ff:ff:ff:ff > >>>>>>>>>>>>>> main [1053] map size is 207712 Kb > >>>>>>>>>>>>>> main [1059] Unable to get if info for eth2 > >>>>>>>>>>>>>> main [1066] bad nthreads 1, have 0 queues > >>>>>>>>>>>>>> main [1075] mmapping 207712 Kbytes > >>>>>>>>>>>>>> main [1094] Unable to register interface eth2 > >>>>>>>>>>>>>> Receiving from eth2: 0 queues, 1 threads and 1 cpus. > >>>>>>>>>>>>>> main [1128] Wait 2 secs for phy reset > >>>>>>>>>>>>>> main [1130] Ready... > >>>>>>>>>>>>>> main [1181] Unable to register eth2 > >>>>>>>>>>>>>> main [1242] 0 pps > >>>>>>>>>>>>>> Received 0 packets, in 0.00 seconds. > >>>>>>>>>>>>>> Speed: -nanpps. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Dmesg after trying to use pkt-gen on eth2: > >>>>>>>>>>>>>> [175537.838503] ADDRCONF(NETDEV_UP): eth2: link is not ready > >>>>>>>>>>>>>> [175542.802288] ixgbe 0000:0c:00.0: eth2: NIC Link is Up 10 > >>>>>>>>>>>>>> Gbps, Flow Control: RX/TX > >>>>>>>>>>>>>> [175542.802607] ADDRCONF(NETDEV_CHANGE): eth2: link becomes > >>>>>>>>>>>>>> ready > >>>>>>>>>>>>>> [175553.256029] eth2: no IPv6 routers present > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> Tahir Rauf > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Tahir Rauf > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Tahir Rauf > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Tahir Rauf > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Tahir Rauf > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Tahir Rauf > >>>> > >>>> > >>> > >> > >> > >> -- > >> Tahir Rauf > >> > >> > > _______________________________________________ > > 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 Mar 22 16:27:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D863DF6 for ; Fri, 22 Mar 2013 16:27:23 +0000 (UTC) (envelope-from jeffrey.e.pieper@intel.com) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by mx1.freebsd.org (Postfix) with ESMTP id 49D1DB38 for ; Fri, 22 Mar 2013 16:27:23 +0000 (UTC) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 22 Mar 2013 09:27:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.84,893,1355126400"; d="scan'208,217";a="217811841" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by AZSMGA002.ch.intel.com with ESMTP; 22 Mar 2013 09:27:07 -0700 Received: from orsmsx107.amr.corp.intel.com (10.22.225.80) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 22 Mar 2013 09:26:54 -0700 Received: from orsmsx101.amr.corp.intel.com ([169.254.8.213]) by ORSMSX107.amr.corp.intel.com ([169.254.10.107]) with mapi id 14.01.0355.002; Fri, 22 Mar 2013 09:26:54 -0700 From: "Pieper, Jeffrey E" To: "david@dr.eclipse.co.uk" , "freebsd-net@FreeBSD.org" Subject: RE: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Thread-Topic: Re: kern/177139: [igb] igb drops ethernet ports 2 and 3 Thread-Index: AQHOJlyS5AcgYUbqtkG8ekPVMynL8Jiw6i1AgAESuID//+ooAA== Date: Fri, 22 Mar 2013 16:26:54 +0000 Message-ID: <2A35EA60C3C77D438915767F458D65687D463B4A@ORSMSX101.amr.corp.intel.com> References: <2A35EA60C3C77D438915767F458D65687D4639E3@ORSMSX101.amr.corp.intel.com> <9b1e8e52c51fd9592fdbd13556744ce700a32b62@webmail.eclipse.net.uk> In-Reply-To: <9b1e8e52c51fd9592fdbd13556744ce700a32b62@webmail.eclipse.net.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 16:27:23 -0000 T25lIG1vcmUgcXVlc3Rpb247IEFyZSB0aGVzZSBEZWxsIGkzNTAgZGF1Z2h0ZXIgY2FyZHMgb3Ig ZGlzY3JldGUgTklDcz8NCg0KVGhhbmtzLA0KDQpKZWZmDQoNCkZyb206IGRhdmlkQGRyLmVjbGlw c2UuY28udWsgW21haWx0bzpkYXZpZEBkci5lY2xpcHNlLmNvLnVrXQ0KU2VudDogRnJpZGF5LCBN YXJjaCAyMiwgMjAxMyAzOjQ0IEFNDQpUbzogUGllcGVyLCBKZWZmcmV5IEU7IGZyZWVic2QtbmV0 QEZyZWVCU0Qub3JnDQpTdWJqZWN0OiBSRTogUmU6IGtlcm4vMTc3MTM5OiBbaWdiXSBpZ2IgZHJv cHMgZXRoZXJuZXQgcG9ydHMgMiBhbmQgMw0KDQoNCkknbGwgdHJ5IHRvIGFycmFuZ2UgdGhpcyBi dXQgc28gZmFyIGlnYjIvMyBoYXZlIGJlZW4gZmluZSB3aGVuIGdvaW5nIHRocm91Z2ggdGhlIHN3 aXRjaCBzbyB0ZW1wdGVkIHRvIHRha2UgdGhpcyBhcyBhIHNvbHV0aW9uLg0KV2UgbG9vc2Ugc29t ZSBzd2l0Y2ggcG9ydHMgYnV0IHRoYXQgaXMgbm8gZ3JlYXQgbG9zcy4gIEdvaW5nIHRvIHB1dCBz b21lIHRyYWZmaWMgdGhyb3VnaCB0aGVtIG92ZXIgdGhlIHdlZWtlbmQgYW5kIHNlZSBpZiB0aGV5 IGFyZSBzdGlsbCBnb29kIG9uIE1vbmRheS4NCg0KRGF2aWQNCg0KLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KRnJvbToNCiJQaWVwZXIgSmVmZnJleSBFIiA8amVmZnJleS5lLnBpZXBlckBp bnRlbC5jb208bWFpbHRvOmplZmZyZXkuZS5waWVwZXJAaW50ZWwuY29tPj4NCg0KVG86DQoiZGF2 aWRAZHIuZWNsaXBzZS5jby51azxtYWlsdG86ZGF2aWRAZHIuZWNsaXBzZS5jby51az4iIDxkYXZp ZEBkci5lY2xpcHNlLmNvLnVrPG1haWx0bzpkYXZpZEBkci5lY2xpcHNlLmNvLnVrPj4sICJmcmVl YnNkLW5ldEBGcmVlQlNELm9yZzxtYWlsdG86ZnJlZWJzZC1uZXRARnJlZUJTRC5vcmc+IiA8ZnJl ZWJzZC1uZXRARnJlZUJTRC5vcmc8bWFpbHRvOmZyZWVic2QtbmV0QEZyZWVCU0Qub3JnPj4NCkNj Og0KDQpTZW50Og0KRnJpLCAyMiBNYXIgMjAxMyAwMToyNjo0MCArMDAwMA0KU3ViamVjdDoNClJF OiBSZToga2Vybi8xNzcxMzk6IFtpZ2JdIGlnYiBkcm9wcyBldGhlcm5ldCBwb3J0cyAyIGFuZCAz DQoNCg0KV2hhdCBKYWNrIG1lYW5zIGlzIHRvIHN3YXAgcG9ydHMgMC8xIHdpdGggcG9ydHMgMi8z LCBzbyB0aGF0IDAvMSBhcmUgQjJCIHdpdGggdGhlIG90aGVyIGkzNTAgYW5kIHBvcnRzIDIvMyBh cmUgY29ubmVjdGVkIHRvIHRoZSBzd2l0Y2guIERvIHRoaXMgb24gYm90aCBzaWRlcy4gVGhlIHJl YXNvbiBmb3IgdGhpcyBpcyBiZWNhdXNlIHRoZXJlIGlzIGEgYnJpZGdlIGJldHdlZW4gcG9ydHMg MC8xIGFuZCAyLzMsIHNvIGl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIGJyaWRnZSBpcyBjYXVzaW5n IHByb2JsZW1zIHdoZW4gY29ubmVjdGVkIEIyQi4NCg0KSmVmZg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogb3duZXItZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc8bWFpbHRvOm93 bmVyLWZyZWVic2QtbmV0QGZyZWVic2Qub3JnPiBbbWFpbHRvOm93bmVyLWZyZWVic2QtbmV0QGZy ZWVic2Qub3JnXSBPbiBCZWhhbGYgT2YgZGF2aWRAZHIuZWNsaXBzZS5jby51azxtYWlsdG86ZGF2 aWRAZHIuZWNsaXBzZS5jby51az4NClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyMSwgMjAxMyAxMDo1 MCBBTQ0KVG86IGZyZWVic2QtbmV0QEZyZWVCU0Qub3JnPG1haWx0bzpmcmVlYnNkLW5ldEBGcmVl QlNELm9yZz4NClN1YmplY3Q6IEZ3ZDogUmU6IGtlcm4vMTc3MTM5OiBbaWdiXSBpZ2IgZHJvcHMg ZXRoZXJuZXQgcG9ydHMgMiBhbmQgMw0KDQpUaGUgZm9sbG93aW5nIHJlcGx5IHdhcyBtYWRlIHRv IFBSIGtlcm4vMTc3MTM5OyBpdCBoYXMgYmVlbiBub3RlZCBieSBHTkFUUy4NCg0KRnJvbTogZGF2 aWRAZHIuZWNsaXBzZS5jby51azxtYWlsdG86ZGF2aWRAZHIuZWNsaXBzZS5jby51az4NClRvOiBi dWctZm9sbG93dXBARnJlZUJTRC5vcmc8bWFpbHRvOmJ1Zy1mb2xsb3d1cEBGcmVlQlNELm9yZz4N CkNjOg0KU3ViamVjdDogRndkOiBSZToga2Vybi8xNzcxMzk6IFtpZ2JdIGlnYiBkcm9wcyBldGhl cm5ldCBwb3J0cyAyIGFuZCAzDQpEYXRlOiBUaHUsIDIxIE1hciAyMDEzIDE3OjMxOjU3ICswMDAw DQoNCi0tPV8wZTAxY2VmMTc5NWQwYTk5OTcwYTQ1MDAwNTNkZjE2Yg0KQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04DQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90 ZWQtcHJpbnRhYmxlDQoNCkl0IGlzIGFuIEludGVsIEkzNTAtdDQgbmljIHRvIGEgSTM1MC10NCBu aWMuPTBBVGhlIHByb2JsZW0gb2NjdXJzIGF0IGJvdD0NCmggc2lkZXMuPTBBTm90IHN1cmUgSSBm b2xsb3cgeW91ciBzd2FwIHN1Z2dlc3Rpb24gYXMgYm90aCBkZXZpY2VzIHNob3VsZD0NCmJlPTBB aWRlbnRpY2FsLj0wQT0wQURhdmlkDQoNCi0tPV8wZTAxY2VmMTc5NWQwYTk5OTcwYTQ1MDAwNTNk ZjE2Yg0KQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgNCkNvbnRlbnQtVHJh bnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCg0KPGh0bWw+PGJvZHk+SXQgaXMgYW4g SW50ZWwgSTM1MC10NCBuaWMgdG8gYSBJMzUwLXQ0IG5pYy48YnIgLz5UaGUgcHJvYmxlPQ0KbSBv Y2N1cnMgYXQgYm90aCBzaWRlcy48YnIgLz5Ob3Qgc3VyZSBJIGZvbGxvdyB5b3VyIHN3YXAgc3Vn Z2VzdGlvbiBhcyBiPQ0Kb3RoIGRldmljZXMgc2hvdWxkIGJlIGlkZW50aWNhbC48YnIgLz48YnIg Lz5EYXZpZDwvYm9keT48L2h0bWw+DQoNCi0tPV8wZTAxY2VmMTc5NWQwYTk5OTcwYTQ1MDAwNTNk ZjE2Yi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpmcmVlYnNkLW5ldEBmcmVlYnNkLm9yZzxtYWlsdG86ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc+ IG1haWxpbmcgbGlzdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8v ZnJlZWJzZC1uZXQNClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLW5l dC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZzxtYWlsdG86ZnJlZWJzZC1uZXQtdW5zdWJzY3JpYmVA ZnJlZWJzZC5vcmc+Ig0K From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 19:43:31 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D94B2300; Fri, 22 Mar 2013 19:43:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id A9A8FF72; Fri, 22 Mar 2013 19:43:31 +0000 (UTC) Received: by mail-ia0-f177.google.com with SMTP id w33so743772iag.8 for ; Fri, 22 Mar 2013 12:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=2ocL+tri1l738dyfiUykDc9qyv/z2foArWDo46QtWTo=; b=cYoTEOI28mmzIG9txISgQnllA8AmIfDrokrWx5AdW2dRYQFbow+q3VhmTtL+tQKInZ 59fexT6aRo+Ot6H2GIaWzQGvirt9YdyWTTXkr467YEz6FNPB0amLqx0pGSDF/ecWERGt HN2PMEepSDSieOSz3aB4LtyFn2YPiK56h7Ift1gJONqdOaPPw3UTGS65Y8HgYKdbkRYf 0uNtHIg6MRtvcQrD6Jt3WcnFDPNipBoa9AIFGblJr140OWD4ZHMDX4Mg3h+gVCR3cwwE Ly3VXOl08MZfYXO6ABi9a5VBU15zhZNRqtIAy7NVD7xewfEKuqggIlGdjQBVifJiRZjq njog== MIME-Version: 1.0 X-Received: by 10.50.41.71 with SMTP id d7mr1974807igl.86.1363981409692; Fri, 22 Mar 2013 12:43:29 -0700 (PDT) Received: by 10.64.30.99 with HTTP; Fri, 22 Mar 2013 12:43:29 -0700 (PDT) Date: Fri, 22 Mar 2013 12:43:29 -0700 Message-ID: Subject: panic: 'Sleeping on "t4slptst" with the following non-sleepable locks held' when using cxgbe+lagg From: Garrett Cooper To: np@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Cc: hhash@isilon.com, freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 19:43:31 -0000 Unfortunately I don't have swap setup on this machine (not sure why... I'll remedy that soon). Basically I was tcpdump'ing the interface that was doing intense NFS I/O at the same time, and I ran into this crash with cxgbe+lagg. Sources are a bit stale (~1.5 months old). Thanks, -Garrett PS Please CC me as I don't receive emails from -net@. db> x/s version version: FreeBSD 10.0-CURRENT #2 r+0db561c: Wed Feb 6 22:21:51 PST 2013\012 root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC\012 db> show msgbuf msgbufp = 0xfffffe01bfffffb8 magic = 63062, size = 98232, r= 290850, w = 293687, ptr = 0xfffffe01bffe8000, cksum= 8071666 Sleeping on "t4slptst" with the following non-sleepable locks held: exclusive rw if_lagg rwlock (if_lagg rwlock) r = 0 (0xfffffe01a66b3608) locked @ /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1065 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8498e26490 kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8498e26540 witness_warn() at witness_warn+0x4a8/frame 0xffffff8498e26600 _sleep() at _sleep+0x6c/frame 0xffffff8498e26690 begin_synchronized_op() at begin_synchronized_op+0x38/frame 0xffffff8498e266f0 cxgbe_ioctl() at cxgbe_ioctl+0x77/frame 0xffffff8498e26740 if_setflag() at if_setflag+0xe1/frame 0xffffff8498e267b0 ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e267e0 lagg_setflags() at lagg_setflags+0x65/frame 0xffffff8498e26820 lagg_ioctl() at lagg_ioctl+0x3d0/frame 0xffffff8498e268c0 if_setflag() at if_setflag+0xe1/frame 0xffffff8498e26930 ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e26960 bpfioctl() at bpfioctl+0x84c/frame 0xffffff8498e269e0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xffffff8498e26a40 kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff8498e26a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff8498e26ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8498e26bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8498e26bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fffeca, rsp = 0x7fffffffd3a8, rbp = 0x7fffffffd980 --- Sleeping thread (tid 100775, pid 64749) owns a non-sleepable lock KDB: stack backtrace of thread 100775: sched_switch() at sched_switch+0x481/frame 0xffffff8498e26550 mi_switch() at mi_switch+0x179/frame 0xffffff8498e26590 sleepq_switch() at sleepq_switch+0x18a/frame 0xffffff8498e265d0 sleepq_timedwait() at sleepq_timedwait+0x43/frame 0xffffff8498e26600 _sleep() at _sleep+0x32c/frame 0xffffff8498e26690 begin_synchronized_op() at begin_synchronized_op+0x38/frame 0xffffff8498e266f0 cxgbe_ioctl() at cxgbe_ioctl+0x77/frame 0xffffff8498e26740 if_setflag() at if_setflag+0xe1/frame 0xffffff8498e267b0 ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e267e0 lagg_setflags() at lagg_setflags+0x65/frame 0xffffff8498e26820 lagg_ioctl() at lagg_ioctl+0x3d0/frame 0xffffff8498e268c0 if_setflag() at if_setflag+0xe1/frame 0xffffff8498e26930 ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e26960 bpfioctl() at bpfioctl+0x84c/frame 0xffffff8498e269e0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xffffff8498e26a40 kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff8498e26a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff8498e26ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8498e26bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8498e26bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fffeca, rsp = 0x7fffffffd3a8, rbp = 0x7fffffffd980 --- panic: sleeping thread cpuid = 2 From owner-freebsd-net@FreeBSD.ORG Fri Mar 22 19:53:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 53A07996 for ; Fri, 22 Mar 2013 19:53:32 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-da0-x231.google.com (mail-da0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF9F10C for ; Fri, 22 Mar 2013 19:53:32 +0000 (UTC) Received: by mail-da0-f49.google.com with SMTP id t11so2456721daj.36 for ; Fri, 22 Mar 2013 12:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uY14WYZIc5jis+NAUlpavRuczryPbPawD2dS8pyIDAc=; b=pQjBkTsK1d2m+eQk4SQ5gfEKfnNljkgoxuw8cxzlbDPKFVDkum5HmS5SsvFTaU9YEc hEPkpJPTsAS05SMlZK4LWlI4SOUXYWyCsFIsrmLPghLKywI1htjAs6wXSYuKZXXCGcMY EvhZyt0J9g/wQW6/yZNHY3fpO9WVryAjiZ0Yhxze7MNVIXlo9hH+TneA9M4HOUlIKcFw egOE8FcgPLa/0d6BqgpTAiFBKVWgGknlMP2WffUR8w8bkNexTm6BZXRiXdFMpXRc7sea Wyita3HZdl04POuYh4dqNDdS9Jb/fVbQ6tgCXp2iE5YKxkknxx/Dw3uZ+ZF22nCSQTLi SjMg== X-Received: by 10.68.134.38 with SMTP id ph6mr4417023pbb.205.1363982012005; Fri, 22 Mar 2013 12:53:32 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id wi7sm4110873pac.9.2013.03.22.12.53.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Mar 2013 12:53:30 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <514CB6B8.3050207@FreeBSD.org> Date: Fri, 22 Mar 2013 12:53:28 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130220 Thunderbird/17.0.3 MIME-Version: 1.0 To: Garrett Cooper Subject: Re: panic: 'Sleeping on "t4slptst" with the following non-sleepable locks held' when using cxgbe+lagg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: hhash@isilon.com, freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 22 Mar 2013 19:53:32 -0000 Thanks for the bug report. I added this "t4 sleep test" sleep exactly for this purpose -- to catch cases where cxgbe(4) thinks it can sleep but it really can't. There is no need for a core, the stack has all the info I need. Regards, Navdeep On 03/22/13 12:43, Garrett Cooper wrote: > Unfortunately I don't have swap setup on this machine (not sure > why... I'll remedy that soon). Basically I was tcpdump'ing the > interface that was doing intense NFS I/O at the same time, and I ran > into this crash with cxgbe+lagg. Sources are a bit stale (~1.5 months > old). > Thanks, > -Garrett > > PS Please CC me as I don't receive emails from -net@. > > db> x/s version > version: FreeBSD 10.0-CURRENT #2 r+0db561c: Wed Feb 6 22:21:51 > PST 2013\012 > root@wf158.west.isilon.com:/usr/obj/usr/src/sys/ISI-GENERIC\012 > db> show msgbuf > msgbufp = 0xfffffe01bfffffb8 > magic = 63062, size = 98232, r= 290850, w = 293687, ptr = > 0xfffffe01bffe8000, cksum= 8071666 > Sleeping on "t4slptst" with the following non-sleepable locks held: > exclusive rw if_lagg rwlock (if_lagg rwlock) r = 0 > (0xfffffe01a66b3608) locked @ > /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:1065 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffff8498e26490 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xffffff8498e26540 > witness_warn() at witness_warn+0x4a8/frame 0xffffff8498e26600 > _sleep() at _sleep+0x6c/frame 0xffffff8498e26690 > begin_synchronized_op() at begin_synchronized_op+0x38/frame 0xffffff8498e266f0 > cxgbe_ioctl() at cxgbe_ioctl+0x77/frame 0xffffff8498e26740 > if_setflag() at if_setflag+0xe1/frame 0xffffff8498e267b0 > ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e267e0 > lagg_setflags() at lagg_setflags+0x65/frame 0xffffff8498e26820 > lagg_ioctl() at lagg_ioctl+0x3d0/frame 0xffffff8498e268c0 > if_setflag() at if_setflag+0xe1/frame 0xffffff8498e26930 > ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e26960 > bpfioctl() at bpfioctl+0x84c/frame 0xffffff8498e269e0 > devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xffffff8498e26a40 > kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff8498e26a90 > sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff8498e26ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8498e26bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8498e26bf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fffeca, rsp = > 0x7fffffffd3a8, rbp = 0x7fffffffd980 --- > Sleeping thread (tid 100775, pid 64749) owns a non-sleepable lock > KDB: stack backtrace of thread 100775: > sched_switch() at sched_switch+0x481/frame 0xffffff8498e26550 > mi_switch() at mi_switch+0x179/frame 0xffffff8498e26590 > sleepq_switch() at sleepq_switch+0x18a/frame 0xffffff8498e265d0 > sleepq_timedwait() at sleepq_timedwait+0x43/frame 0xffffff8498e26600 > _sleep() at _sleep+0x32c/frame 0xffffff8498e26690 > begin_synchronized_op() at begin_synchronized_op+0x38/frame 0xffffff8498e266f0 > cxgbe_ioctl() at cxgbe_ioctl+0x77/frame 0xffffff8498e26740 > if_setflag() at if_setflag+0xe1/frame 0xffffff8498e267b0 > ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e267e0 > lagg_setflags() at lagg_setflags+0x65/frame 0xffffff8498e26820 > lagg_ioctl() at lagg_ioctl+0x3d0/frame 0xffffff8498e268c0 > if_setflag() at if_setflag+0xe1/frame 0xffffff8498e26930 > ifpromisc() at ifpromisc+0x2c/frame 0xffffff8498e26960 > bpfioctl() at bpfioctl+0x84c/frame 0xffffff8498e269e0 > devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xffffff8498e26a40 > kern_ioctl() at kern_ioctl+0x1ce/frame 0xffffff8498e26a90 > sys_ioctl() at sys_ioctl+0x11f/frame 0xffffff8498e26ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xffffff8498e26bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8498e26bf0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x800fffeca, rsp = > 0x7fffffffd3a8, rbp = 0x7fffffffd980 --- > panic: sleeping thread > cpuid = 2 > From owner-freebsd-net@FreeBSD.ORG Sat Mar 23 18:05:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D6997BE0 for ; Sat, 23 Mar 2013 18:05:33 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 89A307CB for ; Sat, 23 Mar 2013 18:05:33 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r2NI5SDq072632 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 24 Mar 2013 00:05:30 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <514DEED6.10001@norma.perm.ru> Date: Sun, 24 Mar 2013 00:05:10 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.1-RELEASE + bge0 == watchdog timeout References: <513713C2.1000007@norma.perm.ru> <20130307022446.GB3108@michelle.cdnetworks.com> <513820E2.806@norma.perm.ru> <20130307062335.GB1478@michelle.cdnetworks.com> <51383E3B.5030007@norma.perm.ru> <20130307081548.GD1478@michelle.cdnetworks.com> <20130313015753.GD3062@michelle.cdnetworks.com> <514171D1.50807@norma.perm.ru> <20130314072946.GA1519@michelle.cdnetworks.com> <51469BE4.6070502@norma.perm.ru> <20130319060327.GC1437@michelle.cdnetworks.com> In-Reply-To: <20130319060327.GC1437@michelle.cdnetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Sun, 24 Mar 2013 00:05:31 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 23 Mar 2013 18:05:33 -0000 Hi. On 19.03.2013 12:03, YongHyeon PYUN wrote: > I have no idea how this change can freeze your box. It would be > even better to know whether the issue was triggered by bge(4) > changes. I think you can use bge(4)/brgphy(4) of 8.3-RELEASE on > your stable/8. Copy required files from 8.3-RELEASE to stable/8 and > rebuild your kernel. For instance, > > Copy /usr/src/sys/dev/bge/if_bge.c from 8.3-RELEASE to /usr/src/sys/dev/bge on stable/8 > Copy /usr/src/sys/dev/bge/if_bgereg.h from 8.3-RELEASE to /usr/src/sys/dev/bge on stable/8 > Copy /usr/src/sys/dev/mii/brgphy.c from 8.3-RELEASE to /usr/src/sys/dev/mii on stable/8 > Copy /usr/src/sys/dev/mii/brgphyreg.g from 8.3-RELEASE to /usr/src/sys/dev/mii on stable/8 > And rebuild your kernel. Well, as I said, I took the if_bge* and bgrphy* sources from one of my servers running 8.3-PRERELEASE (21 мар 2012) and applied it to the stable/8 I'm running on this troubled server. This is how the "last" output looks on it: last | grep reboot reboot ~ Wed Mar 20 00:36 reboot ~ Tue Mar 19 12:44 reboot ~ Mon Mar 18 22:47 reboot ~ Mon Mar 18 08:31 reboot ~ Sun Mar 17 20:40 reboot ~ Sat Mar 16 11:24 reboot ~ Sat Mar 16 11:17 reboot ~ Fri Mar 15 15:17 reboot ~ Fri Mar 15 13:41 reboot ~ Fri Mar 15 08:58 ^^^^^^ this is the time point where the stable/8 was installed. Last reboot was on March, 20 - this is when I rolled back the bge(4) driver. Uptime is now about 4 days. Before that it couldn't stand a full day, and now - 4 days. This doesn't look accidental. Thanks. Eugene.