From owner-freebsd-net@FreeBSD.ORG Sun Sep 16 09:01:04 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AED2C106566C; Sun, 16 Sep 2012 09:01:04 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 810EB8FC14; Sun, 16 Sep 2012 09:01:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8G914Y8095766; Sun, 16 Sep 2012 09:01:04 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8G914Xg095746; Sun, 16 Sep 2012 09:01:04 GMT (envelope-from yongari) Date: Sun, 16 Sep 2012 09:01:04 GMT Message-Id: <201209160901.q8G914Xg095746@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/169634: [bge] Network unavailable when booting directly to FreeBSD [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 09:01:04 -0000 Synopsis: [bge] Network unavailable when booting directly to FreeBSD [regression] Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Sun Sep 16 09:00:43 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=169634 From owner-freebsd-net@FreeBSD.ORG Sun Sep 16 14:47:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 170551065672 for ; Sun, 16 Sep 2012 14:47:20 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from smtpout.ngs.ru (fallback6.ngs.ru [195.19.71.26]) by mx1.freebsd.org (Postfix) with ESMTP id A8A928FC08 for ; Sun, 16 Sep 2012 14:47:18 +0000 (UTC) Received: from smtpout.ngs.ru (mc-spool1 [172.16.103.66]) by mc-spool1.in.ngs.ru (fallback) with ESMTP id 692AD181DF6 for ; Sun, 16 Sep 2012 21:41:28 +0700 (NOVT) Received: from mx14.intranet.ru (mx14.intranet.ru [172.16.7.2]) by mail.ngs.ru (smtp) with ESMTP id 8DAEF180CD1 for ; Sun, 16 Sep 2012 21:41:19 +0700 (NOVT) Received: from mx16.intranet.ru (mx16.intranet.ru [172.16.7.4]) by mx14.intranet.ru (mx14.intranet.ru) with ESMTP id 8B5A7FB66 for ; Sun, 16 Sep 2012 21:41:19 +0700 (NOVT) Received: from [176.51.91.130] (account ivsan@ngs.ru) by mx16.intranet.ru (CommuniGate Pro WebUser 4.3.11) with HTTP id 25219141 for freebsd-net@freebsd.org; Sun, 16 Sep 2012 21:41:19 +0700 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org Date: Sun, 16 Sep 2012 21:41:19 +0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit X-SpamTest-Envelope-From: ivsan@ngs.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: NOTSPAM X-SpamTest-Info: Profiles 36690 [Sep 16 2012] X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status-Extended: not_detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: getting counters for a plenty of vlan ifaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 14:47:20 -0000 Hi We are running freebsd9.0 on a router with more than 1000 of subscriber's vlan interfaces. Outgoing packet rate is approximately 40 kpps. There's a need to collect bytes and packets counters for all those vlan interfaces every minute (or even twice a minute) and store them in a plain text file: ... Also I'd like to copy the whole arp table into a file (not so frequently). Our observations show that using common tools like a snmp daemon can create a significant CPU load. If I'm not mistaken this is due to high rate of context switches that are need to access kernel data from the userspace. So it is desirable to run this tasks - saving counters and arp table into files on a dedicated cpu core. So that copying data from kernel will not affect router performance - packet delays, for example. I would like to ask for an advice about possible solutions. Currently there are two scenarios I can think of: 1) Our custom daemon using userspace APIs (rtmsg, if_* functions, don't know for sure). 2) Our kld module that will store the data needed directly from the kernel into the files. Thanks, Ivan From owner-freebsd-net@FreeBSD.ORG Sun Sep 16 21:34:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48E1F106564A for ; Sun, 16 Sep 2012 21:34:43 +0000 (UTC) (envelope-from lpolaczyk@o2.pl) Received: from moh1-ve1.go2.pl (moh1-ve1.go2.pl [193.17.41.131]) by mx1.freebsd.org (Postfix) with ESMTP id B2BFA8FC12 for ; Sun, 16 Sep 2012 21:34:42 +0000 (UTC) Received: from moh1-ve1.go2.pl (unknown [10.0.0.131]) by moh1-ve1.go2.pl (Postfix) with ESMTP id C43E8928856 for ; Sun, 16 Sep 2012 23:34:34 +0200 (CEST) Received: from o2.pl (unknown [10.0.0.121]) by moh1-ve1.go2.pl (Postfix) with SMTP for ; Sun, 16 Sep 2012 23:34:33 +0200 (CEST) From: =?UTF-8?Q?Lukasz_Polaczyk?= To: freebsd-net@freebsd.org Mime-Version: 1.0 Message-ID: <4de583de.ec6cac4.505645e9.abcf9@o2.pl> Date: Sun, 16 Sep 2012 23:34:33 +0200 X-Originator: 89.75.184.182 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: proxy arp - openvpn X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 21:34:43 -0000 Hi. I=20am=20trying=20to=20use=20proxy=20arp=20mechanism=20to=20create=20new=20= registration=20in=20arp=20table. I=20have=20three=20NICs:=20xl0,=20em0=20and=20one=20virtual=20-=20tun0. Default=20route=20is=20going=20through=20em0.=20Route=20to=2010.146.0.0/1= 6=20network=20is going=20through=20xl0. OS=20is=20FreeBSD=209.0-RELEASE=20amd64 I=20would=20like=20to=20add=20registration=20in=20arp=20table=20for=20add= resses=20in 10.146.100.0/24=20network,=20so=20 all=20traffic=20to=20that=20network=20from=2010.146.0.0/16=20will=20go=20= through=20xl0.=20I would=20like=20to=20do=20this=20dynamically,=20when=20openvpn=20client=20= connects. The=20situation=20is=20like=20this: 1.=203=20NICs=20are=20up: s1%=20ifconfig em0:=20flags=3D8843=20metric=200=20= mtu 1500 =20=20=20=20=20=20=20=20options=3D4219b =20=20=20=20=20=20=20=20media:=20Ethernet=20autoselect=20(1000baseT=20) =20=20=20=20=20=20=20=20status:=20active lo0:=20flags=3D8049=20metric=200=20mtu=201= 6384 =20=20=20=20=20=20=20=20options=3D600003 =20=20=20=20=20=20=20=20inet=20127.0.0.1=20netmask=20255.0.0.0 xl0:=20flags=3D8843=20metric=200=20= mtu 1500 =20=20=20=20=20=20=20=20options=3D82009 =20=20=20=20=20=20=20=20ether=2000:10:4b:c3:db:5b =20=20=20=20=20=20=20=20inet=2010.146.225.1=20netmask=20255.255.0.0=20bro= adcast=2010.146.255.255 =20=20=20=20=20=20=20=20media:=20Ethernet=20autoselect=20(100baseTX=20) =20=20=20=20=20=20=20=20status:=20active tun0:=20flags=3D8010=20metric=200=20mtu=201500 =20=20=20=20=20=20=20=20options=3D80000 route=20table=20is=20like=20below: s1%=20netstat=20-rn Routing=20tables Internet: Destination=20=20=20=20=20=20=20=20Gateway=20=20=20=20=20=20=20=20=20=20=20= =20Flags=20=20=20=20Refs=20=20=20=20=20=20Use=20=20Netif Expire default=20=20=20=20=20=20=20=20=20=20=20=20A.B.C.D=20=20=20=20=20=20=20=20= =20=20=20=20UGS=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20217=20=20=20= =20em0 10.146.0.0/16=20=20=20=20=20=20link#3=20=20=20=20=20=20=20=20=20=20=20=20= =20U=20=20=20=20=20=20=20=20=20=20=200=20=20=20=2011737=20=20=20=20xl0 10.146.225.1=20=20=20=20=20=20=20link#3=20=20=20=20=20=20=20=20=20=20=20=20= =20UHS=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=200=20=20=20=20lo= 0 127.0.0.1=20=20=20=20=20=20=20=20=20=20link#2=20=20=20=20=20=20=20=20=20=20= =20=20=20UH=20=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=201=20=20= =20=20lo0 A.B.C.0/24=20=20=20=20=20=20=20=20=20link#1=20=20=20=20=20=20=20=20=20=20= =20=20=20U=20=20=20=20=20=20=20=20=20=20=200=20=20=20138837=20=20=20=20em= 0 A.B.C.D=20=20=20=20=20=20=20=20=20=20=20=20link#1=20=20=20=20=20=20=20=20= =20=20=20=20=20UHS=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=200=20= =20=20=20lo0 A.B.C.D=20is=20my=20WAN=20interface. arp=20table=20is=20like=20below: s1%=20arp=20-a s1.lan=20(10.146.225.1)=20at=20S01-3C=20on=20xl0=20permanent=20[ethernet]= my.host.pl=20(A.B.C.D)=20at=20S01=20on=20em0=20permanent=20[ethernet] In=20this=20situation=20I=20could=20add=20new=20entry=20in=20arp=20table:= s1%=20#=20arp=20-s=2010.146.100.1=20auto=20pub using=20interface=20xl0=20for=20proxy=20with=20address=20S01-3C After=20adding=20I=20could=20see=20new=20entry=20in=20arp=20table: s1%=20arp=20-a s1.lan=20(10.146.225.1)=20at=20S01-3C=20on=20xl0=20permanent=20[ethernet]= ?=20(10.146.100.1)=20at=20S01-3C=20on=20xl0=20permanent=20published=20[et= hernet] Proxy=20ARP=20is=20working=20manually. 2.=20The=20second=20situation=20is=20diffrent=20(before=20using=20arp=20p= roxy),=20 =20=20=203=20NICs=20are=20working,=20I=20have=20added=20address=20and=20n= ew=20route=20like=20below: s1%=20ifconfig em0:=20flags=3D8843=20metric=200=20= mtu 1500 =20=20=20=20=20=20=20=20options=3D4219b =20=20=20=20=20=20=20=20media:=20Ethernet=20autoselect=20(1000baseT=20) =20=20=20=20=20=20=20=20status:=20active lo0:=20flags=3D8049=20metric=200=20mtu=201= 6384 =20=20=20=20=20=20=20=20options=3D600003 =20=20=20=20=20=20=20=20inet=20127.0.0.1=20netmask=20255.0.0.0 xl0:=20flags=3D8843=20metric=200=20= mtu 1500 =20=20=20=20=20=20=20=20options=3D82009 =20=20=20=20=20=20=20=20ether=2000:10:4b:c3:db:5b =20=20=20=20=20=20=20=20inet=2010.146.225.1=20netmask=20255.255.0.0=20bro= adcast=2010.146.255.255 =20=20=20=20=20=20=20=20media:=20Ethernet=20autoselect=20(100baseTX=20) =20=20=20=20=20=20=20=20status:=20active tun0:=20flags=3D8043=20metric=200=20mtu=20= 1500 =20=20=20=20=20=20=20=20options=3D80000 =20=20=20=20=20=20=20=20inet=2010.146.100.1=20netmask=20255.255.255.0=20b= roadcast=2010.146.100.255 =20=20=20=20=20=20=20=20Opened=20by=20PID=205211 s1%=20netstat=20-rn Routing=20tables Internet: Destination=20=20=20=20=20=20=20=20Gateway=20=20=20=20=20=20=20=20=20=20=20= =20Flags=20=20=20=20Refs=20=20=20=20=20=20Use=20=20Netif Expire default=20=20=20=20=20=20=20=20=20=20=20=20A.B.C.D=20=20=20=20=20=20=20=20= =20=20=20=20UGS=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20223=20=20=20= =20em0 10.146.0.0/16=20=20=20=20=20=20link#3=20=20=20=20=20=20=20=20=20=20=20=20= =20U=20=20=20=20=20=20=20=20=20=20=200=20=20=20=2011739=20=20=20=20xl0 10.146.100.0/24=20=20=20=20link#4=20=20=20=20=20=20=20=20=20=20=20=20=20U= =20=20=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=200=20=20=20tun0 10.146.100.1=20=20=20=20=20=20=20link#4=20=20=20=20=20=20=20=20=20=20=20=20= =20UHS=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=200=20=20=20=20lo= 0 10.146.225.1=20=20=20=20=20=20=20link#3=20=20=20=20=20=20=20=20=20=20=20=20= =20UHS=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=200=20=20=20=20lo= 0 127.0.0.1=20=20=20=20=20=20=20=20=20=20link#2=20=20=20=20=20=20=20=20=20=20= =20=20=20UH=20=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=201=20=20= =20=20lo0 A.B.C.0/24=20=20=20=20=20=20=20=20=20link#1=20=20=20=20=20=20=20=20=20=20= =20=20=20U=20=20=20=20=20=20=20=20=20=20=200=20=20=20146082=20=20=20=20em= 0 A.B.C.D=20=20=20=20=20=20=20=20=20=20=20=20link#1=20=20=20=20=20=20=20=20= =20=20=20=20=20UHS=20=20=20=20=20=20=20=20=200=20=20=20=20=20=20=20=200=20= =20=20=20lo0 When=20trying=20to=20add=20an=20entry=20in=20arp=20table=20I=20got=20an=20= error=20like=20this: s1%=20arp=20-s=2010.146.100.100=20auto=20pub using=20interface=20xl0=20for=20proxy=20with=20address=20S01-3C cannot=20intuit=20interface=20index=20and=20type=20for=2010.146.100.100 I=20can=20not=20delete=20arp=20entries=20provided=20earlier,=20if=20are=20= any: s1%=20#=20arp=20-d=2010.146.100.100 delete:=20cannot=20locate=2010.146.100.100 Is=20there=20any=20solution=20to=20provide=20arp=20entries=20dynamically,= =20after=20creation of=2010.146.100.0/24=20network=20on=20xl0=20interace or=20I=20have=20to=20do=20this=20manually=20before=20creating=20this=20ne= twork? regards, Lukasz=20Polaczyk From owner-freebsd-net@FreeBSD.ORG Sun Sep 16 22:00:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BDC4106566B for ; Sun, 16 Sep 2012 22:00:29 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3338FC0C for ; Sun, 16 Sep 2012 22:00:29 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q8GM0JeQ013762; Sun, 16 Sep 2012 18:00:20 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <50564BE9.6050104@sentex.net> Date: Sun, 16 Sep 2012 18:00:09 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ivan Alexandrovich References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: freebsd-net@freebsd.org Subject: Re: getting counters for a plenty of vlan ifaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 22:00:29 -0000 On 9/16/2012 10:41 AM, Ivan Alexandrovich wrote: > Hi > > We are running freebsd9.0 on a router with > more than 1000 of subscriber's vlan interfaces. > Outgoing packet rate is approximately 40 kpps. > > There's a need to collect bytes and packets > counters for all those vlan interfaces every > minute (or even twice a minute) and store them Hi, We approach it a little differently and collect all the data via netflow, or in this case argus. I sample the parent interface and save all the flow data which argus is smart enough to parse out at the vlan level. You can then run all sorts of fine grained reports this way. We use it on a system with about 900 ng interfaces. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 02:28:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FCD1106566C for ; Mon, 17 Sep 2012 02:28:39 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 307BB8FC0A for ; Mon, 17 Sep 2012 02:28:38 +0000 (UTC) Received: by obbun3 with SMTP id un3so10520915obb.13 for ; Sun, 16 Sep 2012 19:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rddSSOkfI9IhOI5AVYO1a3NUnraiL78cFMFx/r9iRyE=; b=jiTTZZLNN0aOeM6YWl6Md8xEUEF3BQ67S8Zyj0O0YLWddpSDqS+65Wdk6Ey00PGcxN tPr55QH7QOvTZ9lwDZpNI+zgSY7h61RknaszBFwi1UP295cVk8IULI41IRA07FFlYWe9 p8g8gTvxLd+nQL4RMWbyI++WWsbcpFcOSoRnw5WHjo8rFDOqWVLAMcTBeEneJPuRTAWy zUwcoLGhkxlbeU848veISg6RziV4NJTKFuMy2w4yZGLjcj8PGDj8L0y6n4Z65wG2OIHh d7hWatfuCiW6u+F+pnqRIlc3VDJ+8+KZ3rohdqDW6qzT9I7reksBxZ7qLIPFzPlc5GAC 3Mzg== MIME-Version: 1.0 Received: by 10.60.12.234 with SMTP id b10mr10484783oec.72.1347848918410; Sun, 16 Sep 2012 19:28:38 -0700 (PDT) Received: by 10.76.143.194 with HTTP; Sun, 16 Sep 2012 19:28:38 -0700 (PDT) In-Reply-To: <50564BE9.6050104@sentex.net> References: <50564BE9.6050104@sentex.net> Date: Sun, 16 Sep 2012 22:28:38 -0400 Message-ID: From: Zaphod Beeblebrox To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ivan Alexandrovich Subject: Re: getting counters for a plenty of vlan ifaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 02:28:39 -0000 On Sun, Sep 16, 2012 at 6:00 PM, Mike Tancsa wrote: > On 9/16/2012 10:41 AM, Ivan Alexandrovich wrote: >> >> We are running freebsd9.0 on a router with >> more than 1000 of subscriber's vlan interfaces. >> Outgoing packet rate is approximately 40 kpps. >> >> There's a need to collect bytes and packets >> counters for all those vlan interfaces every >> minute (or even twice a minute) and store them > > Hi, > We approach it a little differently and collect all the data via > netflow, or in this case argus. I sample the parent interface and save > all the flow data which argus is smart enough to parse out at the vlan > level. You can then run all sorts of fine grained reports this way. We > use it on a system with about 900 ng interfaces. I know that many people like netflow, but consider you're adding a processing point per packet to solve a once per minute interface sample. Netflow has always struck me as a solution for closed systems --- giving access to all possible information at moderate expense such that you would then never have an excuse to want changes in the operating system of the router. It strikes me that a little kernel module that provided a kernel call that (when called) walked the list of interfaces (in kernel) building a table as described and then shipping that table to userland in one go would be exceedingly cheep to call. It would also not be part of the packet forwarding path and not a potential constant cost during a DDOS. If someone wanted me to write a little .ko for that and an associated userland utility, I'd be happy to do the work. From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 03:09:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1036C106564A for ; Mon, 17 Sep 2012 03:09:15 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id D59618FC0C for ; Mon, 17 Sep 2012 03:09:14 +0000 (UTC) Received: by dadr6 with SMTP id r6so4111582dad.13 for ; Sun, 16 Sep 2012 20:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ySh3ADQOd7ZKz0JEMN1y87GU0+Vk5BAapMNRVbsZJEs=; b=LU37IBfMADaMo0E1CN3jG8KdpvonfPk6uiQqQGK18upk3JaLhFTYjjmySH5eoUjC4t NZS7tKLK2VnC2prYehlbUKIzOaRtJLfYL11VjeakjMnKgxHeLK8zUrdtMdIxgm9fCF3j YpccnEB9j5hzCy5QjH+bTDaRWCAK+uitcmx6jpjZSAF1nhVzrvzyTnDDDZklrmE7A9PK O5v7v1JtFw46Gji/dY80BlwZE3woKjOxznxVmI4Mw/9dTZ59uAYC0SQJxDQ44hrtMcGw UHU0g3NIoArXBW+RR/pDXcg9tTsCPOwCa6pNZ2H+8HMt/iENlPIUUAd/mVM0eaenk8Eg KS0w== MIME-Version: 1.0 Received: by 10.66.85.4 with SMTP id d4mr17617790paz.11.1347851354601; Sun, 16 Sep 2012 20:09:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Sun, 16 Sep 2012 20:09:14 -0700 (PDT) In-Reply-To: References: <50564BE9.6050104@sentex.net> Date: Sun, 16 Sep 2012 20:09:14 -0700 X-Google-Sender-Auth: CDMOrRsKBxGbvr5AVz2ytOSOgNo Message-ID: From: Adrian Chadd To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ivan Alexandrovich , Mike Tancsa Subject: Re: getting counters for a plenty of vlan ifaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 03:09:15 -0000 .. you just have to make sure you get the locking right. Especially if you're walking lists of interfaces and getting protocol stats from a device that's dynamically creating/deleting network interfaces (eg ppp stuff.) Adrian From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 07:29:02 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6C7EA1065672; Mon, 17 Sep 2012 07:29:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 405928FC12; Mon, 17 Sep 2012 07:29:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8H7T2vT090830; Mon, 17 Sep 2012 07:29:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8H7T2qN090814; Mon, 17 Sep 2012 07:29:02 GMT (envelope-from linimon) Date: Mon, 17 Sep 2012 07:29:02 GMT Message-Id: <201209170729.q8H7T2qN090814@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/171697: [ip6] [ndp] panic when changing routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 07:29:02 -0000 Synopsis: [ip6] [ndp] panic when changing routes Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Sep 17 07:28:55 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=171697 From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 08:10:14 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9286106566C for ; Mon, 17 Sep 2012 08:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A3A768FC0A for ; Mon, 17 Sep 2012 08:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8H8AEpR061040 for ; Mon, 17 Sep 2012 08:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8H8AEAE061027; Mon, 17 Sep 2012 08:10:14 GMT (envelope-from gnats) Date: Mon, 17 Sep 2012 08:10:14 GMT Message-Id: <201209170810.q8H8AEAE061027@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Eugene M. Zheganin" Cc: Subject: Re: kern/171697: [ip6] [ndp] panic when changing routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Eugene M. Zheganin" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 08:10:14 -0000 The following reply was made to PR kern/171697; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/171697: [ip6] [ndp] panic when changing routes Date: Mon, 17 Sep 2012 14:03:02 +0600 Actually it's repeatable. There's a bug in net/bird6 (and net/bird), both aren't directly related to this bug, but bird for some reason doesn't honor on-interface routes and can delete them, so I have to add a filter so it won't do it again and then restore the on-interface route by hand. And in this moment FreeBSD panics. One more panic: panic: sin_family 18 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x1d8 in6_lltable_lookup() at in6_lltable_lookup+0x44d nd6_output_lle() at nd6_output_lle+0x349 nd6_output() at nd6_output+0x18 ip6_output() at ip6_output+0x122f tcp_output() at tcp_output+0x12c7 tcp_usr_shutdown() at tcp_usr_shutdown+0xf8 sys_shutdown() at sys_shutdown+0x75 amd64_syscall() at amd64_syscall+0x2fa Xfast_syscall() at Xfast_syscall+0xf7 --- syscall (134, FreeBSD ELF64, sys_shutdown), rip = 0x801fee65c, rsp = 0x7fffffffd728, rbp = 0x7fffffffd970 --- Uptime: 43m28s Dumping 545 out of 4079 MB:panic: Bad tailq NEXT(0xfffffe0002a74160->tqh_last) != NULL cpuid = 1 Uptime: 43m28s aac0: shutting down controller... From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 11:07:11 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C00D41065687 for ; Mon, 17 Sep 2012 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A26438FC1F for ; Mon, 17 Sep 2012 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q8HB7BoW004522 for ; Mon, 17 Sep 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q8HB7Ag9004520 for freebsd-net@FreeBSD.org; Mon, 17 Sep 2012 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Sep 2012 11:07:10 GMT Message-Id: <201209171107.q8HB7Ag9004520@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 11:07:11 -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/171697 net [ip6] [ndp] panic when changing routes o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow o kern/171520 net [alc] alc network driver + tso + vlan does not work. 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/170713 net [cxgb] Driver must be loaded after boot due to timing 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 o kern/169399 net [re] RealTek RTL8168/8111/8111c network interface not p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/168152 net [xl] Periodically, the network card xl0 stops working o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel 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 [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/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 kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 420 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 12:51:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CDB80106566B for ; Mon, 17 Sep 2012 12:51:29 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from smtpout.ngs.ru (smtpout25.ngs.ru [195.19.71.8]) by mx1.freebsd.org (Postfix) with ESMTP id 694AC8FC08 for ; Mon, 17 Sep 2012 12:51:28 +0000 (UTC) Received: from mx14.intranet.ru (mx14.intranet.ru [172.16.7.2]) by mail.ngs.ru (smtp) with ESMTP id BF6F620CB10 for ; Mon, 17 Sep 2012 19:51:24 +0700 (NOVT) Received: from mx16.intranet.ru (mx16.intranet.ru [172.16.7.4]) by mx14.intranet.ru (mx14.intranet.ru) with ESMTP id B0AD8FB6A for ; Mon, 17 Sep 2012 19:51:24 +0700 (NOVT) Received: from [80.242.66.33] (account ivsan@ngs.ru) by mx16.intranet.ru (CommuniGate Pro WebUser 4.3.11) with HTTP id 25262422 for freebsd-net@freebsd.org; Mon, 17 Sep 2012 19:51:24 +0700 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org Date: Mon, 17 Sep 2012 19:51:24 +0700 Message-ID: In-Reply-To: References: <50564BE9.6050104@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit X-SpamTest-Envelope-From: ivsan@ngs.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: NOTSPAM X-SpamTest-Info: Profiles 36718 [Sep 17 2012] X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status-Extended: not_detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: Re: getting counters for a plenty of vlan ifaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 12:51:29 -0000 Hi Thanks for your replies. Mike Tancsa mike at sentex.net wrote: > We approach it a little differently and collect all the data via > netflow, or in this case argus. Netflow is fine. We used ng_netflow with ng_vlan on a previous installation with FreeBSD-6.x and it worked fine. Then we had to drop it as a safety measure since the hardware itself was slow and once failed to sustain anomalous packet rate the during packet storm. Currently that's enough for us to have ipt_NETFLOW (linux) on a border router and some service-specific RDRs from SCE. Zaphod Beeblebrox zbeeble at gmail.com wrote > It strikes me that a little kernel module that provided a kernel call > that (when called) walked the list of interfaces (in kernel) building > a table as described and then shipping that table to userland in one > go would be exceedingly cheep to call. Custom syscall? Thanks for the idea, i'll try. Would freebsd-net be the right place to ask specific questions concerning in-kernel data structures? Adrian Chadd adrian at freebsd.org wrote: > you just have to make sure you get the locking right. Thanks, I'll try. And what will be the right way to ensure the code is smp safe before taking it into production? Run a few scripts that will continuosly create/destroy vlans? Thanks, Ivan From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 15:50:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B99331065672 for ; Mon, 17 Sep 2012 15:50:01 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 694A28FC18 for ; Mon, 17 Sep 2012 15:50:01 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so9650174vcb.13 for ; Mon, 17 Sep 2012 08:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BaHmVNe0Gg6qtj5EqiJhabhczSIGCpel/omzD44kYSI=; b=q0JLYERaYZU1xrhSTRXposJQwNbDveeyPADNpFgZ8d/lmHECNhdhLPnjxWUHoNIgRg x/j0gDek80LnFF7yZeFJliG4USHF0UwZWjCBFMO9SxLH738lvEQuEVA7Rx28mZDG1CJ7 ekn9aEzZRmlTzwj8ZcdSJqcU4njL4TTDj6x6AnoS9+AC6wtaUqRHhj2SlRGDdNzA4Mbk ZTOUQr3AmX5kD8F2PbE1uEHSkj3+liJLAaRqtuM71VY2+88jdHHe3oy/MWacOK6pOJ2U R+Dkr1+VQ9nadgdXYAWNOYYXaqacYes1XH9C1o2NM70Ns8G6IcrkUQIjornDPT1l98gY 8MHg== MIME-Version: 1.0 Received: by 10.52.36.113 with SMTP id p17mr3681765vdj.91.1347896999728; Mon, 17 Sep 2012 08:49:59 -0700 (PDT) Received: by 10.58.207.114 with HTTP; Mon, 17 Sep 2012 08:49:59 -0700 (PDT) Date: Mon, 17 Sep 2012 11:49:59 -0400 Message-ID: From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 15:50:01 -0000 I know that there have been a lot of discussions about fixing how packets are handed off to ifnets due to the current methods being extremely race-prone. Has there been any consensus on how the problem is going to be solved? In my particular case, I've seen an if_bridge interface whose if_snd queue is full, and once an ifnet reaches that point it will never transmit anything ever again unless its driver manually calls the start method somehow. As a short-term fix I'm temped to call to if_start in IFQ_HANDOFF_ADJ even if IFQ_ENQUEUE returns an error, to ensure that the queue will be drained eventually, but I'm wondering if people are actively working on longer-term fixes. From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 17:16:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F318D106566C for ; Mon, 17 Sep 2012 17:16:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C9D908FC12 for ; Mon, 17 Sep 2012 17:16:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3789FB993; Mon, 17 Sep 2012 13:16:49 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 17 Sep 2012 13:16:45 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209171316.45029.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 17 Sep 2012 13:16:49 -0400 (EDT) Cc: Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:16:50 -0000 On Monday, September 17, 2012 11:49:59 am Ryan Stone wrote: > I know that there have been a lot of discussions about fixing how > packets are handed off to ifnets due to the current methods being > extremely race-prone. Has there been any consensus on how the problem > is going to be solved? > > In my particular case, I've seen an if_bridge interface whose if_snd > queue is full, and once an ifnet reaches that point it will never > transmit anything ever again unless its driver manually calls the > start method somehow. > > As a short-term fix I'm temped to call to if_start in IFQ_HANDOFF_ADJ > even if IFQ_ENQUEUE returns an error, to ensure that the queue will be > drained eventually, but I'm wondering if people are actively working > on longer-term fixes. I think for if_bridge the fix is that it no longer uses if_start. :) For real hardware you will get some sort of TX completion interrupt that will restart the transmit queue. Virtual software-only interfaces such as vlan(4) and if_bridge(4) don't have that luxury though, and the best bet for them is to probably have them use if_transmit instead. vlan(4) and if_bridge(4) are already fixed for that (if_bridge was only fixed a week or so ago in HEAD). -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 17:45:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4275E106564A; Mon, 17 Sep 2012 17:45:13 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0EDAD8FC08; Mon, 17 Sep 2012 17:45:12 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so10183005pbb.13 for ; Mon, 17 Sep 2012 10:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=viJvVX16tiayV6P2uYnBEHYxJ3Q15NlcE3cQgQK3mqg=; b=UNwp3odszTEU01reHyBmuLvqQ3CnPJJ1FbkjLY3Tr06DEfOkF8IuY+AqQGqMfhwVgz JYg9PR7Xdh+R5P1LwV9P/0aICBe583abIQBbzNKIlAabQvoVOu7e5Uz8hmP76if63Ug0 G+mRm8Uw/rzRcISH2z/BfarY3oAef4j+c8oBjGH9Ud557Oovqg1XMXUAZZRLky333484 MpJHgUaK/8ULFBOPBQ5P+2QwMwTdhKApb+OPQsCp2Xng0At4Ijc4ydho4mna8Hgoen9u htAZlXra77wssyUBagUqhAOs/ydS/6g/uRXudQb9g6QbHKq9bR7bGT5NnEFp7P659KAi pPaQ== MIME-Version: 1.0 Received: by 10.68.189.70 with SMTP id gg6mr23996936pbc.125.1347903912291; Mon, 17 Sep 2012 10:45:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Mon, 17 Sep 2012 10:45:12 -0700 (PDT) In-Reply-To: <201209171316.45029.jhb@freebsd.org> References: <201209171316.45029.jhb@freebsd.org> Date: Mon, 17 Sep 2012 10:45:12 -0700 X-Google-Sender-Auth: KGGbdjWExcwKBnhBLcakggKJyi8 Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 17:45:13 -0000 On 17 September 2012 10:16, John Baldwin wrote: > I think for if_bridge the fix is that it no longer uses if_start. :) :) > For real hardware you will get some sort of TX completion interrupt that will > restart the transmit queue. Virtual software-only interfaces such as vlan(4) > and if_bridge(4) don't have that luxury though, and the best bet for them is > to probably have them use if_transmit instead. vlan(4) and if_bridge(4) are > already fixed for that (if_bridge was only fixed a week or so ago in HEAD). I'm still not convinced that going the if_start route (with process-to-completion) is going to work well when forwarding gobs of packets on anything bar ${BIG_IRON}, but that aside.. It may be nice to introduce a virtual TX completion callback? Ie, a child driver could signal that it's successfully drained its TX queue, notifying any parent drivers that they can send more? adrian From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 19:04:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C170A106564A; Mon, 17 Sep 2012 19:04:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8FEEC8FC0C; Mon, 17 Sep 2012 19:04:10 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id ED15FB911; Mon, 17 Sep 2012 15:04:09 -0400 (EDT) From: John Baldwin To: Adrian Chadd Date: Mon, 17 Sep 2012 15:03:12 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201209171316.45029.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209171503.12517.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 17 Sep 2012 15:04:10 -0400 (EDT) Cc: freebsd-net@freebsd.org, Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:04:10 -0000 On Monday, September 17, 2012 1:45:12 pm Adrian Chadd wrote: > On 17 September 2012 10:16, John Baldwin wrote: > > > I think for if_bridge the fix is that it no longer uses if_start. :) > > :) > > > For real hardware you will get some sort of TX completion interrupt that will > > restart the transmit queue. Virtual software-only interfaces such as vlan(4) > > and if_bridge(4) don't have that luxury though, and the best bet for them is > > to probably have them use if_transmit instead. vlan(4) and if_bridge(4) are > > already fixed for that (if_bridge was only fixed a week or so ago in HEAD). > > I'm still not convinced that going the if_start route (with > process-to-completion) is going to work well when forwarding gobs of > packets on anything bar ${BIG_IRON}, but that aside.. Eh? For virtual interfaces, if_transmit introduces less overhead than using if_start (no locking, queueing, dequeueing, etc.). I expect that to be a net win for smaller boards. > It may be nice to introduce a virtual TX completion callback? Ie, a > child driver could signal that it's successfully drained its TX queue, > notifying any parent drivers that they can send more? That could work, but I generally think if_transmit is a better route for these sorts of things. That turns these interfaces into simple filters rather than building up their own queue, etc. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 20:00:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 341B4106566C; Mon, 17 Sep 2012 20:00:06 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A04788FC12; Mon, 17 Sep 2012 20:00:05 +0000 (UTC) Received: by vcbfw7 with SMTP id fw7so10084967vcb.13 for ; Mon, 17 Sep 2012 13:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=99N203WNO8g663yBKCvNWcuikw1dpnjCrZtP1EJU/WA=; b=o0Lei7KQR0SO4aVRqUDNhO0yUpMlqZlK8VgiR+Rk6IHLzs/d0nwAB0QnHMkiC2iu4X Q2vOQmTfP0gXWkNl9Z2JbDUeIwSuf1yUaKbK2qQj8a1oAs3pjXT3JjfDaMC+SQ0esRw3 hUNKWSglgkrXbF2sMUjuz6qJdS8rl2niore7crh5ohvSXeyVOy5iY+gNOpwODecZXkYw Ks+Iej5pkH3ftF6oRuwEhobPVYr6BvlEU1X88fNYHFahF2uidLv2Mexf7uXCvfF5cToY WCGGmxxyAQJsLAuVtTnKFrwP1UWeWDHM9d6UenODTN5UmpqbqIIldjMcT6M1lGfBGkCD BuFg== MIME-Version: 1.0 Received: by 10.52.33.165 with SMTP id s5mr3911436vdi.51.1347912004746; Mon, 17 Sep 2012 13:00:04 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Mon, 17 Sep 2012 13:00:04 -0700 (PDT) In-Reply-To: <201209171503.12517.jhb@freebsd.org> References: <201209171316.45029.jhb@freebsd.org> <201209171503.12517.jhb@freebsd.org> Date: Mon, 17 Sep 2012 13:00:04 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Adrian Chadd , Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:00:06 -0000 So, you mean having them create their own buf ring I assume? Would be easy enough to hack some code and try it if someone is so inclined? Jack On Mon, Sep 17, 2012 at 12:03 PM, John Baldwin wrote: > On Monday, September 17, 2012 1:45:12 pm Adrian Chadd wrote: > > On 17 September 2012 10:16, John Baldwin wrote: > > > > > I think for if_bridge the fix is that it no longer uses if_start. :) > > > > :) > > > > > For real hardware you will get some sort of TX completion interrupt > that will > > > restart the transmit queue. Virtual software-only interfaces such as > vlan(4) > > > and if_bridge(4) don't have that luxury though, and the best bet for > them is > > > to probably have them use if_transmit instead. vlan(4) and > if_bridge(4) are > > > already fixed for that (if_bridge was only fixed a week or so ago in > HEAD). > > > > I'm still not convinced that going the if_start route (with > > process-to-completion) is going to work well when forwarding gobs of > > packets on anything bar ${BIG_IRON}, but that aside.. > > Eh? For virtual interfaces, if_transmit introduces less overhead than > using if_start (no locking, queueing, dequeueing, etc.). I expect that > to be a net win for smaller boards. > > > It may be nice to introduce a virtual TX completion callback? Ie, a > > child driver could signal that it's successfully drained its TX queue, > > notifying any parent drivers that they can send more? > > That could work, but I generally think if_transmit is a better route for > these sorts of things. That turns these interfaces into simple filters > rather than building up their own queue, etc. > > -- > John Baldwin > _______________________________________________ > 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 Mon Sep 17 20:22:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 749461065677; Mon, 17 Sep 2012 20:22:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 471D38FC17; Mon, 17 Sep 2012 20:22:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A174AB941; Mon, 17 Sep 2012 16:22:33 -0400 (EDT) From: John Baldwin To: Jack Vogel Date: Mon, 17 Sep 2012 16:22:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201209171503.12517.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201209171622.11157.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 17 Sep 2012 16:22:33 -0400 (EDT) Cc: freebsd-net@freebsd.org, Adrian Chadd , Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:22:34 -0000 On Monday, September 17, 2012 4:00:04 pm Jack Vogel wrote: > So, you mean having them create their own buf ring I assume? Would be easy > enough to hack some code and try it if someone is so inclined? No, that would be backwards (back to giving them a queue). Adrian's suggestion is to provide a mechanism so that the "real" interface (e.g. emX) can call back into the psuedo-interfaces on top of it (vlanX or bridgeX) when a TX completion interrupt fires so that the pseudo-interface would know to restart transmission. However, I think this is generally not ideal. I don't think we want an additional queue of pending packets in things like if_bridge(4) and vlan(4). If the underlying physical interface(s) are full, the packet should just get dropped rather than queued. Using if_transmit directly will do that while avoiding overhead. Also, making the callback work would also be a bit ungainly. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 20:29:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A26B1106564A; Mon, 17 Sep 2012 20:29:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 212368FC0C; Mon, 17 Sep 2012 20:29:50 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2841564vbm.13 for ; Mon, 17 Sep 2012 13:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ZUNwY1FLmNHW7uPBeF4z4tdVxUB6A0NEtGQOO4MPyM=; b=L/aJvB5eh95DX4P2ZgOyrcFuZlFWWdSvXRBmce5aEajOEvjbSS5gLoymvcfuxXTQDs Fhfw8j4i6vFaNmGnns20um59pjqjdS7o79q95gCCGLhuo/ZVxnOxRN13XifrhP1M8R/f c3UjAW/h5nQofqjVhbYCJs995BVHdB4YB7u5HPUpYKeJJqjfI1q1QeBkPeVuRrkBfy/U mTIoG4A3V0ts/AAXiJRvrYiSYGg1wbeIAhB5YbjtDbiSw3xxez0UYvyYdn/gVaBWkPM5 yhwPgqB/oxhMaDoJ9s6wNi/pR1zQVESsumgRfDkhkBwfsH95tYw2IJObk7nGtcjz9g/8 s4lg== MIME-Version: 1.0 Received: by 10.58.31.228 with SMTP id d4mr8608725vei.40.1347913790445; Mon, 17 Sep 2012 13:29:50 -0700 (PDT) Received: by 10.58.68.8 with HTTP; Mon, 17 Sep 2012 13:29:50 -0700 (PDT) In-Reply-To: <201209171622.11157.jhb@freebsd.org> References: <201209171503.12517.jhb@freebsd.org> <201209171622.11157.jhb@freebsd.org> Date: Mon, 17 Sep 2012 13:29:50 -0700 Message-ID: From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Adrian Chadd , Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 20:29:51 -0000 On Mon, Sep 17, 2012 at 1:22 PM, John Baldwin wrote: > On Monday, September 17, 2012 4:00:04 pm Jack Vogel wrote: > > So, you mean having them create their own buf ring I assume? Would be > easy > > enough to hack some code and try it if someone is so inclined? > > No, that would be backwards (back to giving them a queue). Adrian's > suggestion is to provide a mechanism so that the "real" interface > (e.g. emX) can call back into the psuedo-interfaces on top of it > (vlanX or bridgeX) when a TX completion interrupt fires so that the > pseudo-interface would know to restart transmission. However, I think > this is generally not ideal. I don't think we want an additional queue > of pending packets in things like if_bridge(4) and vlan(4). If the > underlying physical interface(s) are full, the packet should just get > dropped rather than queued. Using if_transmit directly will do that while > avoiding overhead. Also, making the callback work would also be a bit > ungainly. > > I meant using if_transmit, not the callback, would it not then need a buf ring? Jack From owner-freebsd-net@FreeBSD.ORG Mon Sep 17 23:16:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4292F106566B; Mon, 17 Sep 2012 23:16:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6298FC12; Mon, 17 Sep 2012 23:16:27 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so10634335pbb.13 for ; Mon, 17 Sep 2012 16:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Edgzu7ITKZ/e27U8V/9UdaOVog64dNQFPdt8q4bRUB0=; b=OczxPczJuC0Q8ZR4xv4KDNNkj0zoBYDVoA+6nCVJLgLJz+S78enYHE7d5Cmm7MpjCq DgB3b7XZvX6V5cxoZXUZ/SpGVG1FEGKmTR/M92IsPobENuHxT0gVCaPbYN5iN5Jm7MiQ qalk+rf5Hzckpqd68nQ90lH9shC4xqPCVegQDkW5Qmw2hk1p13kfw040vOQhZZELFza8 Cspko+lHb1xzs9CbpnepIDlWXEj6/J5jLqju3T7K1KnIlClMwutEed1/9TfGDBb5k+/V 909/amTeTfDFWWbpoykFGdhKPpL5J3aA1FBEzFS4+ff89L6BYLgDwZhY3Be4lx1lepQV 5TLA== MIME-Version: 1.0 Received: by 10.66.74.196 with SMTP id w4mr22386184pav.32.1347923787647; Mon, 17 Sep 2012 16:16:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Mon, 17 Sep 2012 16:16:27 -0700 (PDT) In-Reply-To: <201209171503.12517.jhb@freebsd.org> References: <201209171316.45029.jhb@freebsd.org> <201209171503.12517.jhb@freebsd.org> Date: Mon, 17 Sep 2012 16:16:27 -0700 X-Google-Sender-Auth: VCcByGSriHpxpb0Oj_geRsBCs_4 Message-ID: From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 23:16:28 -0000 There's a lot less cache in these boards. Going through the stack trace all the way and back for each packet is actually quite expensive. Then there's the overhead of having if_start() be called multiple times, concurrently, from multiple senders. It's fine for a wifi AP setup where the if_start() is only called once or twice in an overlapping fashion, but sucks with lots of concurrent TCP/UDP contexts all potentially calling if_start() and having them have to clash with each other. I've not sat down and instrumented it all that much, so I'm going to spend much time harping on about it until I have some hard numbers either way. I'm just going by what I see people do to various network stacks when it comes time to try and squeeze high packet rates out of smaller platforms, especially with NAT/bridging/PPPoE in the way. And that tended not to be "complete packet to completion on each frame." adrian From owner-freebsd-net@FreeBSD.ORG Tue Sep 18 12:34:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9639E10657DC; Tue, 18 Sep 2012 12:34:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 69ACF8FC15; Tue, 18 Sep 2012 12:34:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B7D93B911; Tue, 18 Sep 2012 08:34:50 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Tue, 18 Sep 2012 07:58:42 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201209171622.11157.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209180758.42299.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Sep 2012 08:34:50 -0400 (EDT) Cc: Adrian Chadd , Ryan Stone , Jack Vogel Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:34:51 -0000 On Monday, September 17, 2012 4:29:50 pm Jack Vogel wrote: > On Mon, Sep 17, 2012 at 1:22 PM, John Baldwin wrote: > > > On Monday, September 17, 2012 4:00:04 pm Jack Vogel wrote: > > > So, you mean having them create their own buf ring I assume? Would be > > easy > > > enough to hack some code and try it if someone is so inclined? > > > > No, that would be backwards (back to giving them a queue). Adrian's > > suggestion is to provide a mechanism so that the "real" interface > > (e.g. emX) can call back into the psuedo-interfaces on top of it > > (vlanX or bridgeX) when a TX completion interrupt fires so that the > > pseudo-interface would know to restart transmission. However, I think > > this is generally not ideal. I don't think we want an additional queue > > of pending packets in things like if_bridge(4) and vlan(4). If the > > underlying physical interface(s) are full, the packet should just get > > dropped rather than queued. Using if_transmit directly will do that while > > avoiding overhead. Also, making the callback work would also be a bit > > ungainly. > > > > > I meant using if_transmit, not the callback, would it not then need a buf > ring? No. You only need a buf_ring if you want a software queue of packets. In the case of virtual interfaces you don't really want that (it leads to double queueing). Instead, you want things like vlan(4) to just be a simple transform that slaps on a vlan header and then passes the packet to the underlying interface. You wouldn't want to have a software queue at various protocol layers that slap on headers (e.g. Ethernet or IP), and things like vlan(4) shouldn't have one either. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Sep 18 12:34:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C0F210657F0; Tue, 18 Sep 2012 12:34:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0EEAB8FC08; Tue, 18 Sep 2012 12:34:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5E3CCB96F; Tue, 18 Sep 2012 08:34:51 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Tue, 18 Sep 2012 08:10:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <201209171503.12517.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201209180810.52409.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Sep 2012 08:34:51 -0400 (EDT) Cc: Adrian Chadd , Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:34:52 -0000 On Monday, September 17, 2012 7:16:27 pm Adrian Chadd wrote: > There's a lot less cache in these boards. Going through the stack > trace all the way and back for each packet is actually quite > expensive. > > Then there's the overhead of having if_start() be called multiple > times, concurrently, from multiple senders. It's fine for a wifi AP > setup where the if_start() is only called once or twice in an > overlapping fashion, but sucks with lots of concurrent TCP/UDP > contexts all potentially calling if_start() and having them have to > clash with each other. > > I've not sat down and instrumented it all that much, so I'm going to > spend much time harping on about it until I have some hard numbers > either way. I'm just going by what I see people do to various network > stacks when it comes time to try and squeeze high packet rates out of > smaller platforms, especially with NAT/bridging/PPPoE in the way. And > that tended not to be "complete packet to completion on each frame." I (mostly) don't get where you are coming from at all. The "old" code would do this given a packet bound for if_vlan(4) or if_bridge(4): - queue the packet to the virtual interface's if_snd(4) including locking, etc. - call the virtual interface's if_start() which dequeues the previously queued packet (again, using locking) and then passes it down to the underlying physical interface via if_transmit(). For most NICs this entails queueing the packet to if_snd and then optionally calling the NIC's if_start(). The "new" code does: - Pass the packet down to the underlying physical interface via if_transmit(). For most NICs this entails queueing the packet to if_snd and then optionally calling the NIC's if_start(). This is _less_ work. Also, consider vlan(4). vlan(4)'s job is to serve (largely) as a protocol layer that prepends (or strips) a vlan header from the packet. We don't use interface queues for other protocols such as Ethernet or IP. We shouldn't use one for vlan(4) either. The packet should have the transform applied and then be dispatched to the actual NIC. As for direct dispatch, there is a toggle to not use direct dispatch in the network stack and to use netisr for certain tasks. However, that is generally used for receive, not transmit AFAIK. As for concurrent calls to if_start(), it certainly might be nice to provide a way under the IFQ lock to know in if_transmit() (the default one) whether or not if_start() is in progress and should be called (this would mean having if_start() be called with the IFQ lock held I think, though for drivers that use if_start() this would work nicely I think, esp. if you moved OACTIVE into the IFQ). That is orthogonal to bypassing queueing for things like vlan and bridge however. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Sep 18 18:12:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19839106566B for ; Tue, 18 Sep 2012 18:12:16 +0000 (UTC) (envelope-from Sudharshan.Varadarajan@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id E89008FC08 for ; Tue, 18 Sep 2012 18:12:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.80,444,1344236400"; d="scan'208,217";a="691162932" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 18 Sep 2012 11:12:09 -0700 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q8IIC8LL005217 for ; Tue, 18 Sep 2012 11:12:09 -0700 (PDT) Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.90]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0309.002; Tue, 18 Sep 2012 11:12:08 -0700 From: "Varadarajan, Sudharshan" To: "freebsd-net@freebsd.org" Thread-Topic: Help: Macro limit in file "nd6.h" Thread-Index: AQHNlckcTj60jqOpgEa+Ee8EOC5Eiw== Date: Tue, 18 Sep 2012 18:11:54 +0000 Message-ID: <0694CF3623AD4B4FBCD500FFCA8CBC330547B036@SACEXCMBX02-PRD.hq.netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Help: Macro limit in file "nd6.h" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 18:12:16 -0000 Hi all, When I was going through the file nd6.h, (../sysnetinet6/nd6.h) I find that= macro (prefix list size) "PRLSTSIZ" is defined as 10. Is there any particu= lar reason for having a lower value like this? Thanks Sudharshan From owner-freebsd-net@FreeBSD.ORG Wed Sep 19 03:41:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87D2B106566B; Wed, 19 Sep 2012 03:41:00 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay2-bcrtfl2.verio.net (relay2-bcrtfl2.verio.net [131.103.218.177]) by mx1.freebsd.org (Postfix) with ESMTP id 339138FC08; Wed, 19 Sep 2012 03:41:00 +0000 (UTC) Received: from iad-wprd-xchw01.corp.verio.net (iad-wprd-xchw01.corp.verio.net [198.87.7.164]) by relay2-bcrtfl2.verio.net (Postfix) with ESMTP id 8BC311FF02ED; Tue, 18 Sep 2012 23:08:59 -0400 (EDT) thread-index: Ac2WFBzoWPmUufLdRBO5G0XzmsnhRQ== Received: from hometx-733b1p1.corp.verio.net ([10.144.2.53]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Sep 2012 23:08:58 -0400 Received: by hometx-733b1p1.corp.verio.net (sSMTP sendmail emulation); Tue, 18 Sep 2012 22:08:58 -0500 Content-Transfer-Encoding: 7bit Date: Tue, 18 Sep 2012 22:08:58 -0500 From: "David DeSimone" Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 To: "Daniel Eischen" Message-ID: <20120919030858.GG6080@verio.net> Mail-Followup-To: Daniel Eischen , freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> <503E7A16.6030600@zirakzigil.org> <5044F62E.8030001@zirakzigil.org> <504FA735.709@zirakzigil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Disposition: inline In-Reply-To: Precedence: bulk User-Agent: Mutt/1.5.20 (2009-12-10) X-OriginalArrivalTime: 19 Sep 2012 03:08:58.0169 (UTC) FILETIME=[1C494A90:01CD9614] Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 03:41:00 -0000 Daniel Eischen wrote: > > My rc.conf is something like this: > > # > # For now, force ath0 to use the same MAC address as xl0. > # This works around a bug where lagg is unable to set the > # MAC address of the underlying wlan0 interface. > # > ifconfig_ath0="ether 01:02:03:04:05:06" > wlans_ath0=wlan0 > ifconfig_wlan0="ssid SSID_FOO_NAME WPA" I hope the above isn't literally what you're using for your MAC address. The first octet in particular, because it has LSB set to 1, will be treated as a multicast address, and many routers and switches will not believe it when it's given as an ARP reply, or as a source address for traffic. I'm hoping it's just an example you substituted so as not to reveal your actual MAC. When making up MAC addresses, keep the LSB of the first octet at zero (required) and set the next bit to 1 (optional, but a good practice). So first octet should be 02, 06, 8a, 9e, etc... any even number, preferably multiple of four, plus two. > ifconfig_xl0="up" > closed_interfaces="lagg0" > ifconfig_lagg0="laggproto failover laggport xl0 laggport wlan0" > ifconfig_lagg0_alias0="inet 10.0.0.4 netmask 0xffffff00" > > I use aliasX to add the address and netmask. > > -- > DE -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-net@FreeBSD.ORG Wed Sep 19 03:55:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6DB16106564A; Wed, 19 Sep 2012 03:55:34 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2729F8FC12; Wed, 19 Sep 2012 03:55:34 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.5/8.14.5/NETPLEX) with ESMTP id q8J3tRnJ062766; Tue, 18 Sep 2012 23:55:27 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.7 (mail.netplex.net [204.213.176.10]); Tue, 18 Sep 2012 23:55:27 -0400 (EDT) Date: Tue, 18 Sep 2012 23:55:27 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David DeSimone In-Reply-To: <20120919030858.GG6080@verio.net> Message-ID: References: <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> <503E7A16.6030600@zirakzigil.org> <5044F62E.8030001@zirakzigil.org> <504FA735.709@zirakzigil.org> <20120919030858.GG6080@verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Issue with igb and lagg (was Re: Problem with link aggregation + sshd) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 03:55:34 -0000 On Tue, 18 Sep 2012, David DeSimone wrote: > Daniel Eischen wrote: >> >> My rc.conf is something like this: >> >> # >> # For now, force ath0 to use the same MAC address as xl0. >> # This works around a bug where lagg is unable to set the >> # MAC address of the underlying wlan0 interface. >> # >> ifconfig_ath0="ether 01:02:03:04:05:06" >> wlans_ath0=wlan0 >> ifconfig_wlan0="ssid SSID_FOO_NAME WPA" > > I hope the above isn't literally what you're using for your MAC address. No, of course not :-) I thought it was obvious I elided my actual MAC address. -- DE From owner-freebsd-net@FreeBSD.ORG Wed Sep 19 15:18:09 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F08F51065674 for ; Wed, 19 Sep 2012 15:18:08 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 6A3FB8FC16 for ; Wed, 19 Sep 2012 15:18:08 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q8JFI6b7040574; Wed, 19 Sep 2012 19:18:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q8JFI6dF040573; Wed, 19 Sep 2012 19:18:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 19 Sep 2012 19:18:06 +0400 From: Gleb Smirnoff To: Ivan Alexandrovich Message-ID: <20120919151806.GK85604@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: getting counters for a plenty of vlan ifaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:18:09 -0000 On Sun, Sep 16, 2012 at 09:41:19PM +0700, Ivan Alexandrovich wrote: I> Hi I> I> We are running freebsd9.0 on a router with I> more than 1000 of subscriber's vlan interfaces. I> Outgoing packet rate is approximately 40 kpps. I> I> There's a need to collect bytes and packets I> counters for all those vlan interfaces every I> minute (or even twice a minute) and store them I> in a plain text file: I> I> I> ... I> Also I'd like to copy the whole arp table I> into a file (not so frequently). I> I> Our observations show that using common tools I> like a snmp daemon can create a significant I> CPU load. If I'm not mistaken this is due to I> high rate of context switches that are need I> to access kernel data from the userspace. That's strange. Per-minute read shouldn't induce large CPU load. What snmp daemon do you use? I remember that several years ago net-snmp daemon from ports used a single linked list for all ARP entries, and thus it consumed a lot of CPU when receiving a single ARP change from routing socket. Don't know whether this is still valid. And I hope in base bsnmpd doesn't have such problem. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Sep 19 15:19:57 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E7B93106564A; Wed, 19 Sep 2012 15:19:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 5EF578FC12; Wed, 19 Sep 2012 15:19:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q8JFJuXC040588; Wed, 19 Sep 2012 19:19:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q8JFJubb040587; Wed, 19 Sep 2012 19:19:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 19 Sep 2012 19:19:56 +0400 From: Gleb Smirnoff To: John Baldwin Message-ID: <20120919151956.GL85604@FreeBSD.org> References: <201209171316.45029.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201209171316.45029.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, Ryan Stone Subject: Re: What's the latest on fixing IFF_DRV_OACTIVE/if_start/etc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:19:58 -0000 On Mon, Sep 17, 2012 at 01:16:45PM -0400, John Baldwin wrote: J> On Monday, September 17, 2012 11:49:59 am Ryan Stone wrote: J> > I know that there have been a lot of discussions about fixing how J> > packets are handed off to ifnets due to the current methods being J> > extremely race-prone. Has there been any consensus on how the problem J> > is going to be solved? J> > J> > In my particular case, I've seen an if_bridge interface whose if_snd J> > queue is full, and once an ifnet reaches that point it will never J> > transmit anything ever again unless its driver manually calls the J> > start method somehow. J> > J> > As a short-term fix I'm temped to call to if_start in IFQ_HANDOFF_ADJ J> > even if IFQ_ENQUEUE returns an error, to ensure that the queue will be J> > drained eventually, but I'm wondering if people are actively working J> > on longer-term fixes. J> J> I think for if_bridge the fix is that it no longer uses if_start. :) And this is already in head. :) -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Sep 19 17:47:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08EBB1065670 for ; Wed, 19 Sep 2012 17:47:54 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id DDB428FC17 for ; Wed, 19 Sep 2012 17:47:53 +0000 (UTC) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 38F45C95D1; Wed, 19 Sep 2012 17:47:44 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EE8CB216C3D; Wed, 19 Sep 2012 17:47:43 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Wed, 19 Sep 2012 10:47:43 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Varadarajan, Sudharshan" In-Reply-To: <0694CF3623AD4B4FBCD500FFCA8CBC330547B036@SACEXCMBX02-PRD.hq.netapp.com> References: <0694CF3623AD4B4FBCD500FFCA8CBC330547B036@SACEXCMBX02-PRD.hq.netapp.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: "freebsd-net@freebsd.org" Subject: Re: Help: Macro limit in file "nd6.h" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 17:47:54 -0000 At Tue, 18 Sep 2012 18:11:54 +0000, "Varadarajan, Sudharshan" wrote: > When I was going through the file nd6.h, (../sysnetinet6/nd6.h) I find that macro (prefix list size) "PRLSTSIZ" is defined as 10. Is there any particular reason for having a lower value like this? I don't remember, but I suspect it was an arbitrary choice. Maybe you can find the rationale (if any) in old commit logs when the code was developed by the KAME project at, e.g., http://www.kame.net/dev/cvsweb2.cgi/ --- JINMEI, Tatuya Internet Systems Consortium, Inc. From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 07:25:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E11AB1065670 for ; Thu, 20 Sep 2012 07:25:59 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 57F7A8FC0A for ; Thu, 20 Sep 2012 07:25:58 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so2472420lbb.13 for ; Thu, 20 Sep 2012 00:25:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:x-gm-message-state; bh=FBtpjX+JNOvyV83zv/U/Q5G+UGUNrzs6G8ji0hglN5E=; b=HyaDv1S139x/02jIgKKl8Ns4E7X/DuBsXnfteYrkhs/Jj/4KODLwcLV0yer/UzEE/c /wFhLydVO2tS7+fQ7cPc42Rc7usb9ybSxa28JwgWC/h8kEpt4yFPKsKYwDdodga2Emf+ 8PrfKl/HbnBX82p/xBv2Fy4xUOTC1/ZhlCO7O1SLd27FfMuywTWnlozRXF2bKHrrQ3Qb 19XYvUxgWBWPfYHT7hB1M4o8Vrt+JyI3ZuK1hwHNRKOpS8/nqTnoMhnT1Xdj3inwhIRR OxWatKSS2IB3rku1YF1DdXuiNc2mh8Ee4xMuvH5TsiUoiSoc4Sw2BsI7xQuR7yRtOiaQ v+Pg== Received: by 10.152.132.168 with SMTP id ov8mr862540lab.0.1348125957398; Thu, 20 Sep 2012 00:25:57 -0700 (PDT) Received: from zont-osx.local (ppp95-165-139-113.pppoe.spdop.ru. [95.165.139.113]) by mx.google.com with ESMTPS id ly17sm1222931lab.2.2012.09.20.00.25.56 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 00:25:56 -0700 (PDT) Sender: Andrey Zonov Message-ID: <505AC500.6060903@FreeBSD.org> Date: Thu, 20 Sep 2012 11:25:52 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" X-Enigmail-Version: 1.4.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig71DF1AF920C0571CBAA7F2BB" X-Gm-Message-State: ALoCoQkK+LWPEU+orRsukBGfgboiLRI9Tq+m5c2h4DqWnQnqic6v3jc0DL3Kw6UV+cY/xuYKs8CI Subject: [patch] sysctls for TCP timers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 07:26:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig71DF1AF920C0571CBAA7F2BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Some of them may be read google's article about tuning TCP parameters [1]. I convert most of TCP timers to sysctls [2] and we are using this patch for few months. We tuned net.inet.tcp.rtobase and net.inet.tcp.syncache.rexmttime and it gives good results (especially in conjunction with cc_htcp(4)). Is there any suggestions how to make patch better and commit it? [1] www.ietf.org/proceedings/75/slides/tcpm-1.pdf [2] http://people.freebsd.org/~zont/patches/tcp-timers.patch --=20 Andrey Zonov --------------enig71DF1AF920C0571CBAA7F2BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQWsUDAAoJEBWLemxX/CvTOd4IAK0JfMmLZtvjdgFqtC68LQht +qQ+Olwlq2M17BhPnDE9/NexG83uldgJrhGEswg3gV5GTaAP2Zvv51TJ9o+AB+K4 nkJrX6dcXcuH4QEiV1JIZhHYUh4BcG5Jb920Ql2yxzyY7BnKvVFlDzrTkp4hFKcZ xkDFAkSRUPZP10WDdwEI9m+d5BajoeFGDC/eh9p7pkS4ZUfUI4XRQ4u9Wi6GqJKv kpZJgWiHl6X0IeXpxLO53A7Cnr6fk3huPrO9bXxa5/54B0WytIoPOZlqoD/d1esK vAM5BtedGZvuqLSK4EquMHOpXr2ulRtaTQ6bKw66g0aeK4UT4SxRv1+PzzODxps= =yyEM -----END PGP SIGNATURE----- --------------enig71DF1AF920C0571CBAA7F2BB-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 07:36:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 033AC106564A; Thu, 20 Sep 2012 07:36:02 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id CD4C28FC08; Thu, 20 Sep 2012 07:36:01 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="p7s'?scan'208";a="691826862" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 20 Sep 2012 00:35:40 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q8K7Zequ007748; Thu, 20 Sep 2012 00:35:40 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0309.002; Thu, 20 Sep 2012 00:35:40 -0700 From: "Eggert, Lars" To: Andrey Zonov Thread-Topic: [patch] sysctls for TCP timers Thread-Index: AQHNlwFihOWSHsOU1kecbvduYbb6G5eTTGcA Date: Thu, 20 Sep 2012 07:35:38 +0000 Message-ID: References: <505AC500.6060903@FreeBSD.org> In-Reply-To: <505AC500.6060903@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_2D847243-414C-4A71-8628-F710D2687420"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: Re: [patch] sysctls for TCP timers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 07:36:02 -0000 --Apple-Mail=_2D847243-414C-4A71-8628-F710D2687420 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 Hi, On Sep 20, 2012, at 9:25, Andrey Zonov wrote: > Some of them may be read google's article about tuning TCP parameters > [1]. I convert most of TCP timers to sysctls [2] and we are using this > patch for few months. We tuned net.inet.tcp.rtobase and > net.inet.tcp.syncache.rexmttime and it gives good results (especially in > conjunction with cc_htcp(4)). can you share some measurements that quantify the results? Thanks, Lars --Apple-Mail=_2D847243-414C-4A71-8628-F710D2687420-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 07:47:32 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C9BC106566B for ; Thu, 20 Sep 2012 07:47:32 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 75A548FC0C for ; Thu, 20 Sep 2012 07:47:31 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q8K7lUau046046 for ; Thu, 20 Sep 2012 11:47:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q8K7lUL1046045 for net@freebsd.org; Thu, 20 Sep 2012 11:47:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 20 Sep 2012 11:47:30 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20120920074730.GS85604@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+QwZB9vYiNIzNXIj" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: [CFT] if_transmit method for lagg(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 07:47:32 -0000 --+QwZB9vYiNIzNXIj Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hi, Yet another patch to test. Was suprising to me that lagg(4), which aims at high-performance, still utilizes if_start. Attached is patch that converts lagg(4) to use if_transmit. I'd appreciate if someone who do use lagg(4) tests the patch. If anyone benchmarks lagg(4) with and w/o patch that will be most appreciated. -- Totus tuus, Glebius. --+QwZB9vYiNIzNXIj Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_lagg.c.diff" Index: if_lagg.c =================================================================== --- if_lagg.c (revision 240735) +++ if_lagg.c (working copy) @@ -110,7 +110,8 @@ static int lagg_setflag(struct lagg_port *, int, int, int (*func)(struct ifnet *, int)); static int lagg_setflags(struct lagg_port *, int status); -static void lagg_start(struct ifnet *); +static int lagg_transmit(struct ifnet *i, struct mbuf *); +static void lagg_qflush(struct ifnet *); static int lagg_media_change(struct ifnet *); static void lagg_media_status(struct ifnet *, struct ifmediareq *); static struct lagg_port *lagg_link_active(struct lagg_softc *, @@ -312,15 +313,12 @@ if_initname(ifp, ifc->ifc_name, unit); ifp->if_softc = sc; - ifp->if_start = lagg_start; + ifp->if_transmit = lagg_transmit; + ifp->if_qflush = lagg_qflush; ifp->if_init = lagg_init; ifp->if_ioctl = lagg_ioctl; ifp->if_flags = IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST; - IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); - ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; - IFQ_SET_READY(&ifp->if_snd); - /* * Attach as an ordinary ethernet device, children will be attached * as special device IFT_IEEE8023ADLAG. @@ -1222,37 +1220,41 @@ return (0); } -static void -lagg_start(struct ifnet *ifp) +static int +lagg_transmit(struct ifnet *ifp, struct mbuf *m) { struct lagg_softc *sc = (struct lagg_softc *)ifp->if_softc; - struct mbuf *m; int error = 0; LAGG_RLOCK(sc); /* We need a Tx algorithm and at least one port */ if (sc->sc_proto == LAGG_PROTO_NONE || sc->sc_count == 0) { - IF_DRAIN(&ifp->if_snd); LAGG_RUNLOCK(sc); - return; + m_freem(m); + return (ENXIO); } - for (;; error = 0) { - IFQ_DEQUEUE(&ifp->if_snd, m); - if (m == NULL) - break; + ETHER_BPF_MTAP(ifp, m); - ETHER_BPF_MTAP(ifp, m); + error = (*sc->sc_start)(sc, m); + LAGG_RUNLOCK(sc); - error = (*sc->sc_start)(sc, m); - if (error == 0) - ifp->if_opackets++; - else - ifp->if_oerrors++; - } - LAGG_RUNLOCK(sc); + if (error == 0) + ifp->if_opackets++; + else + ifp->if_oerrors++; + + return (error); } +/* + * The ifp->if_qflush entry point for lagg(4) is no-op. + */ +static void +lagg_qflush(struct ifnet *ifp __unused) +{ +} + static struct mbuf * lagg_input(struct ifnet *ifp, struct mbuf *m) { --+QwZB9vYiNIzNXIj-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 08:37:20 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90D0A106566C for ; Thu, 20 Sep 2012 08:37:20 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9508FC1A for ; Thu, 20 Sep 2012 08:37:20 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so5001325pbb.13 for ; Thu, 20 Sep 2012 01:37:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=UFgCOiQ/6fsCRrG5zrUH33Ou0XfFrx9RhMmL++PdaHE=; b=QcyLQBp/Ji9w5vBTNdYUd47rCddTGt6Aj43n3JJHOoolHLXkOQ0g4axD0ytSkFpiAk PxvVMzDWuJkkAPZ6j1nTgxc+9gRPHY3sDL8vej9CZS106KSl8QR0bhmj+oCrq2po7NyF ELkv8sx/N8Wl4OR5bGzAfkvZLI+coSHX2G0eM2e9qczC3D7gTPN24h1X5TvWZjvIJiTj IYn/5WaTftVQhc+9EFf4yVb28MXECOorQwRY/L+VsAQmX2eUVFUzs+KgPKjkSUQOjbPZ mdFrzVl5A/iW1FV2srnzcaxvesKYZt8bEF3AfAOycLPnQhWwpw8Jv3IeSv670Zu8Wtob xMyQ== MIME-Version: 1.0 Received: by 10.66.76.231 with SMTP id n7mr3446151paw.68.1348130239700; Thu, 20 Sep 2012 01:37:19 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.29.6 with HTTP; Thu, 20 Sep 2012 01:37:19 -0700 (PDT) In-Reply-To: <20120920074730.GS85604@FreeBSD.org> References: <20120920074730.GS85604@FreeBSD.org> Date: Thu, 20 Sep 2012 20:37:19 +1200 X-Google-Sender-Auth: A9oJ0jixWw2p1JH3-cvZHYIXYAk Message-ID: From: Andrew Thompson To: Gleb Smirnoff Content-Type: multipart/mixed; boundary=f46d042dfdd90c608304ca1e087d X-Gm-Message-State: ALoCoQl3opS1xkHTgJWH+mmE/RZ9HBo/tkN0KFeNyRxY4V8GIVszQek+pfMOlag05NXZS0636FCE Cc: net@freebsd.org Subject: Re: [CFT] if_transmit method for lagg(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:37:20 -0000 --f46d042dfdd90c608304ca1e087d Content-Type: text/plain; charset=ISO-8859-1 On 20 September 2012 19:47, Gleb Smirnoff wrote: > Hi, > > Yet another patch to test. Was suprising to me that lagg(4), which > aims at high-performance, still utilizes if_start. > > Attached is patch that converts lagg(4) to use if_transmit. I'd > appreciate if someone who do use lagg(4) tests the patch. If anyone > benchmarks lagg(4) with and w/o patch that will be most appreciated. Sean Bruno has already tested this patch at Yahoo, I have just been delayed in committing it. There are just a few small differences so we can commit one or merge. Andrew --f46d042dfdd90c608304ca1e087d Content-Type: application/octet-stream; name="lagg_transmit.diff" Content-Disposition: attachment; filename="lagg_transmit.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h7blxni41 SW5kZXg6IGlmX2xhZ2cuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIGlmX2xhZ2cuYwkocmV2aXNpb24gMjM4 MDQ3KQ0KKysrIGlmX2xhZ2cuYwkod29ya2luZyBjb3B5KQ0KQEAgLTExMCw3ICsxMTAsOCBAQCBz dGF0aWMgaW50CWxhZ2dfZXRoZXJfY21kbXVsdGkoc3RydWN0IGxhZ2dfcG9ydCAqLA0KIHN0YXRp YwlpbnQJbGFnZ19zZXRmbGFnKHN0cnVjdCBsYWdnX3BvcnQgKiwgaW50LCBpbnQsDQogCQkgICAg aW50ICgqZnVuYykoc3RydWN0IGlmbmV0ICosIGludCkpOw0KIHN0YXRpYwlpbnQJbGFnZ19zZXRm bGFncyhzdHJ1Y3QgbGFnZ19wb3J0ICosIGludCBzdGF0dXMpOw0KLXN0YXRpYyB2b2lkCWxhZ2df c3RhcnQoc3RydWN0IGlmbmV0ICopOw0KK3N0YXRpYyBpbnQJbGFnZ190cmFuc21pdChzdHJ1Y3Qg aWZuZXQgKmlmcCwgc3RydWN0IG1idWYgKm0pOw0KK3N0YXRpYyB2b2lkCWxhZ2dfcWZsdXNoKHN0 cnVjdCBpZm5ldCAqaWZwKTsNCiBzdGF0aWMgaW50CWxhZ2dfbWVkaWFfY2hhbmdlKHN0cnVjdCBp Zm5ldCAqKTsNCiBzdGF0aWMgdm9pZAlsYWdnX21lZGlhX3N0YXR1cyhzdHJ1Y3QgaWZuZXQgKiwg c3RydWN0IGlmbWVkaWFyZXEgKik7DQogc3RhdGljIHN0cnVjdCBsYWdnX3BvcnQgKmxhZ2dfbGlu a19hY3RpdmUoc3RydWN0IGxhZ2dfc29mdGMgKiwNCkBAIC0zMTIsMTUgKzMxMywxMiBAQCBsYWdn X2Nsb25lX2NyZWF0ZShzdHJ1Y3QgaWZfY2xvbmUgKmlmYywgaW50IHVuaXQsDQogCWlmX2luaXRu YW1lKGlmcCwgaWZjLT5pZmNfbmFtZSwgdW5pdCk7DQogCWlmcC0+aWZfdHlwZSA9IElGVF9FVEhF UjsNCiAJaWZwLT5pZl9zb2Z0YyA9IHNjOw0KLQlpZnAtPmlmX3N0YXJ0ID0gbGFnZ19zdGFydDsN CisJaWZwLT5pZl90cmFuc21pdCA9IGxhZ2dfdHJhbnNtaXQ7DQorCWlmcC0+aWZfcWZsdXNoID0g bGFnZ19xZmx1c2g7DQogCWlmcC0+aWZfaW5pdCA9IGxhZ2dfaW5pdDsNCiAJaWZwLT5pZl9pb2N0 bCA9IGxhZ2dfaW9jdGw7DQogCWlmcC0+aWZfZmxhZ3MgPSBJRkZfU0lNUExFWCB8IElGRl9CUk9B RENBU1QgfCBJRkZfTVVMVElDQVNUOw0KIA0KLQlJRlFfU0VUX01BWExFTigmaWZwLT5pZl9zbmQs IGlmcW1heGxlbik7DQotCWlmcC0+aWZfc25kLmlmcV9kcnZfbWF4bGVuID0gaWZxbWF4bGVuOw0K LQlJRlFfU0VUX1JFQURZKCZpZnAtPmlmX3NuZCk7DQotDQogCS8qDQogCSAqIEF0dGFjaCBhcyBh biBvcmRpbmFyeSBldGhlcm5ldCBkZXZpY2UsIGNoaWxkcyB3aWxsIGJlIGF0dGFjaGVkDQogCSAq IGFzIHNwZWNpYWwgZGV2aWNlIElGVF9JRUVFODAyM0FETEFHLg0KQEAgLTEyMjIsMzcgKzEyMjAs NDQgQEAgbGFnZ19zZXRmbGFncyhzdHJ1Y3QgbGFnZ19wb3J0ICpscCwgaW50IHN0YXR1cykNCiAJ cmV0dXJuICgwKTsNCiB9DQogDQotc3RhdGljIHZvaWQNCi1sYWdnX3N0YXJ0KHN0cnVjdCBpZm5l dCAqaWZwKQ0KK3N0YXRpYyBpbnQNCitsYWdnX3RyYW5zbWl0KHN0cnVjdCBpZm5ldCAqaWZwLCBz dHJ1Y3QgbWJ1ZiAqbSkNCiB7DQogCXN0cnVjdCBsYWdnX3NvZnRjICpzYyA9IChzdHJ1Y3QgbGFn Z19zb2Z0YyAqKWlmcC0+aWZfc29mdGM7DQotCXN0cnVjdCBtYnVmICptOw0KLQlpbnQgZXJyb3Ig PSAwOw0KKwlpbnQgZXJyb3IsIGxlbiwgbWNhc3Q7DQogDQogCUxBR0dfUkxPQ0soc2MpOw0KIAkv KiBXZSBuZWVkIGEgVHggYWxnb3JpdGhtIGFuZCBhdCBsZWFzdCBvbmUgcG9ydCAqLw0KIAlpZiAo c2MtPnNjX3Byb3RvID09IExBR0dfUFJPVE9fTk9ORSB8fCBzYy0+c2NfY291bnQgPT0gMCkgew0K LQkJSUZfRFJBSU4oJmlmcC0+aWZfc25kKTsNCisJCW1fZnJlZW0obSk7DQogCQlMQUdHX1JVTkxP Q0soc2MpOw0KLQkJcmV0dXJuOw0KKwkJcmV0dXJuICgwKTsNCiAJfQ0KIA0KLQlmb3IgKDs7IGVy cm9yID0gMCkgew0KLQkJSUZRX0RFUVVFVUUoJmlmcC0+aWZfc25kLCBtKTsNCi0JCWlmIChtID09 IE5VTEwpDQotCQkJYnJlYWs7DQorCWxlbiA9IG0tPm1fcGt0aGRyLmxlbjsNCisJbWNhc3QgPSAo bS0+bV9mbGFncyAmIChNX01DQVNUIHwgTV9CQ0FTVCkpID8gMSA6IDA7DQorCUVUSEVSX0JQRl9N VEFQKGlmcCwgbSk7DQogDQotCQlFVEhFUl9CUEZfTVRBUChpZnAsIG0pOw0KKwllcnJvciA9ICgq c2MtPnNjX3N0YXJ0KShzYywgbSk7DQorCWlmIChlcnJvciA9PSAwKSB7DQorCQlpZnAtPmlmX29w YWNrZXRzKys7DQorCQlpZnAtPmlmX29tY2FzdHMgKz0gbWNhc3Q7DQorCQlpZnAtPmlmX29ieXRl cyArPSBsZW47DQorCX0gZWxzZQ0KKwkJaWZwLT5pZl9vZXJyb3JzKys7DQorCUxBR0dfUlVOTE9D SyhzYyk7DQogDQotCQllcnJvciA9ICgqc2MtPnNjX3N0YXJ0KShzYywgbSk7DQotCQlpZiAoZXJy b3IgPT0gMCkNCi0JCQlpZnAtPmlmX29wYWNrZXRzKys7DQotCQllbHNlDQotCQkJaWZwLT5pZl9v ZXJyb3JzKys7DQotCX0NCi0JTEFHR19SVU5MT0NLKHNjKTsNCisJcmV0dXJuIChlcnJvcik7DQog fQ0KIA0KKy8qDQorICogVGhlIGlmcC0+aWZfcWZsdXNoIGVudHJ5IHBvaW50IGZvciBsYWdnKDQp IGlzIGEgbm8tb3AuDQorICovDQorc3RhdGljIHZvaWQNCitsYWdnX3FmbHVzaChzdHJ1Y3QgaWZu ZXQgKmlmcCBfX3VudXNlZCkNCit7DQorfQ0KKw0KIHN0YXRpYyBzdHJ1Y3QgbWJ1ZiAqDQogbGFn Z19pbnB1dChzdHJ1Y3QgaWZuZXQgKmlmcCwgc3RydWN0IG1idWYgKm0pDQogew0K --f46d042dfdd90c608304ca1e087d-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 08:48:06 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BE4B1065672; Thu, 20 Sep 2012 08:48:06 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 134398FC15; Thu, 20 Sep 2012 08:48:05 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q8K8m48f046568; Thu, 20 Sep 2012 12:48:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q8K8m4Yh046567; Thu, 20 Sep 2012 12:48:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 20 Sep 2012 12:48:04 +0400 From: Gleb Smirnoff To: Andrew Thompson Message-ID: <20120920084804.GY85604@glebius.int.ru> References: <20120920074730.GS85604@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="poJSiGMzRSvrLGLs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: [CFT] if_transmit method for lagg(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:48:06 -0000 --poJSiGMzRSvrLGLs Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hi! On Thu, Sep 20, 2012 at 08:37:19PM +1200, Andrew Thompson wrote: A> > Yet another patch to test. Was suprising to me that lagg(4), which A> > aims at high-performance, still utilizes if_start. A> > A> > Attached is patch that converts lagg(4) to use if_transmit. I'd A> > appreciate if someone who do use lagg(4) tests the patch. If anyone A> > benchmarks lagg(4) with and w/o patch that will be most appreciated. A> A> Sean Bruno has already tested this patch at Yahoo, I have just been A> delayed in committing it. There are just a few small differences so we A> can commit one or merge. Also fabient@ replied to me in private with this patch :) Hmm, I've missed stats update. I have merge statistics updates from your patch to mine and here it is attached. -- Totus tuus, Glebius. --poJSiGMzRSvrLGLs Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_lagg.c.diff" Index: if_lagg.c =================================================================== --- if_lagg.c (revision 240735) +++ if_lagg.c (working copy) @@ -110,7 +110,8 @@ static int lagg_setflag(struct lagg_port *, int, int, int (*func)(struct ifnet *, int)); static int lagg_setflags(struct lagg_port *, int status); -static void lagg_start(struct ifnet *); +static int lagg_transmit(struct ifnet *i, struct mbuf *); +static void lagg_qflush(struct ifnet *); static int lagg_media_change(struct ifnet *); static void lagg_media_status(struct ifnet *, struct ifmediareq *); static struct lagg_port *lagg_link_active(struct lagg_softc *, @@ -312,15 +313,12 @@ if_initname(ifp, ifc->ifc_name, unit); ifp->if_softc = sc; - ifp->if_start = lagg_start; + ifp->if_transmit = lagg_transmit; + ifp->if_qflush = lagg_qflush; ifp->if_init = lagg_init; ifp->if_ioctl = lagg_ioctl; ifp->if_flags = IFF_SIMPLEX | IFF_BROADCAST | IFF_MULTICAST; - IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); - ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; - IFQ_SET_READY(&ifp->if_snd); - /* * Attach as an ordinary ethernet device, children will be attached * as special device IFT_IEEE8023ADLAG. @@ -1222,37 +1220,47 @@ return (0); } -static void -lagg_start(struct ifnet *ifp) +static int +lagg_transmit(struct ifnet *ifp, struct mbuf *m) { struct lagg_softc *sc = (struct lagg_softc *)ifp->if_softc; - struct mbuf *m; - int error = 0; + int error, len, mcast; + len = m->m_pkthdr.len; + mcast = (m->m_flags & (M_MCAST | M_BCAST)) ? 1 : 0; + LAGG_RLOCK(sc); /* We need a Tx algorithm and at least one port */ if (sc->sc_proto == LAGG_PROTO_NONE || sc->sc_count == 0) { - IF_DRAIN(&ifp->if_snd); LAGG_RUNLOCK(sc); - return; + m_freem(m); + ifp->if_oerrors++; + return (ENXIO); } - for (;; error = 0) { - IFQ_DEQUEUE(&ifp->if_snd, m); - if (m == NULL) - break; + ETHER_BPF_MTAP(ifp, m); - ETHER_BPF_MTAP(ifp, m); + error = (*sc->sc_start)(sc, m); + LAGG_RUNLOCK(sc); - error = (*sc->sc_start)(sc, m); - if (error == 0) - ifp->if_opackets++; - else - ifp->if_oerrors++; - } - LAGG_RUNLOCK(sc); + if (error == 0) { + ifp->if_opackets++; + ifp->if_omcasts += mcast; + ifp->if_obytes += len; + } else + ifp->if_oerrors++; + + return (error); } +/* + * The ifp->if_qflush entry point for lagg(4) is no-op. + */ +static void +lagg_qflush(struct ifnet *ifp __unused) +{ +} + static struct mbuf * lagg_input(struct ifnet *ifp, struct mbuf *m) { --poJSiGMzRSvrLGLs-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 08:54:52 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0205C106566C for ; Thu, 20 Sep 2012 08:54:52 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C2CEE8FC14 for ; Thu, 20 Sep 2012 08:54:51 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so5034184pbb.13 for ; Thu, 20 Sep 2012 01:54:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=wcQw4k6VUHjHfZxu59QUzvcOqmwb5+WjJi00GwGLsok=; b=D28pO4WRbtAzl0VZaSVETyJ7B8iJ2KxCczCVaFnBwX0rBFJWY6vvlSE9R7xUJTd0XL xcTh3mwf1MtMEbcs9A+BYgrcgjzOsqVt7JxzdWnBVsIYcaA+EdGH84tDzF6Pb6HXPgOM UarQoNgMT+ug00udNxbGoBGgIn5OMNmxIGaFwPp+1NFyr/QE3DuFvhdFpK0dPfaZeAZR leW1V8t6X1GBvmWdT2Csyciu3ByI+sG2HVgWuawDi97ZbIK4TkLCFDTL41ep58hypj2p OP9XohrAF0T1eayjrBxn2g4BuoBrlxgILqu0LyVWB5gu7qsF3XUSQSKgTU6v8nf2QOZ6 2low== MIME-Version: 1.0 Received: by 10.68.220.137 with SMTP id pw9mr5079267pbc.1.1348131291355; Thu, 20 Sep 2012 01:54:51 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.29.6 with HTTP; Thu, 20 Sep 2012 01:54:51 -0700 (PDT) In-Reply-To: <20120920084804.GY85604@glebius.int.ru> References: <20120920074730.GS85604@FreeBSD.org> <20120920084804.GY85604@glebius.int.ru> Date: Thu, 20 Sep 2012 20:54:51 +1200 X-Google-Sender-Auth: JZJhiCS2GvyCB63rawxQuflYQZM Message-ID: From: Andrew Thompson To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlhofl1pjbjeDWpQ3Sgt8wEpBv79DnOrsbRMd8gy13cTdG7B1Fr9hc/UlusqraHNhwPkkF7 Cc: net@freebsd.org Subject: Re: [CFT] if_transmit method for lagg(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:54:52 -0000 On 20 September 2012 20:48, Gleb Smirnoff wrote: > Hi! > > On Thu, Sep 20, 2012 at 08:37:19PM +1200, Andrew Thompson wrote: > A> > Yet another patch to test. Was suprising to me that lagg(4), which > A> > aims at high-performance, still utilizes if_start. > A> > > A> > Attached is patch that converts lagg(4) to use if_transmit. I'd > A> > appreciate if someone who do use lagg(4) tests the patch. If anyone > A> > benchmarks lagg(4) with and w/o patch that will be most appreciated. > A> > A> Sean Bruno has already tested this patch at Yahoo, I have just been > A> delayed in committing it. There are just a few small differences so we > A> can commit one or merge. > > Also fabient@ replied to me in private with this patch :) > > Hmm, I've missed stats update. I have merge statistics updates from your patch > to mine and here it is attached. Looks good, please commit. There is just a stray `i` here +static int lagg_transmit(struct ifnet *i, struct mbuf *); Andrew From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 10:09:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24DF91065672 for ; Thu, 20 Sep 2012 10:09:23 +0000 (UTC) (envelope-from ivsan@ngs.ru) Received: from smtpout.ngs.ru (smtpout25.ngs.ru [195.19.71.8]) by mx1.freebsd.org (Postfix) with ESMTP id B94758FC08 for ; Thu, 20 Sep 2012 10:09:22 +0000 (UTC) Received: from mx14.intranet.ru (mx14.intranet.ru [172.16.7.2]) by mail.ngs.ru (smtp) with ESMTP id 6863F209E11 for ; Thu, 20 Sep 2012 17:09:13 +0700 (NOVT) Received: from mx16.intranet.ru (mx16.intranet.ru [172.16.7.4]) by mx14.intranet.ru (mx14.intranet.ru) with ESMTP id 678CA110E4 for ; Thu, 20 Sep 2012 17:09:13 +0700 (NOVT) Received: from [80.242.66.33] (account ivsan@ngs.ru) by mx16.intranet.ru (CommuniGate Pro WebUser 4.3.11) with HTTP id 25413494 for freebsd-net@freebsd.org; Thu, 20 Sep 2012 17:09:13 +0700 From: "Ivan Alexandrovich" To: freebsd-net@freebsd.org Date: Thu, 20 Sep 2012 17:09:13 +0700 Message-ID: In-Reply-To: <20120919151806.GK85604@FreeBSD.org> References: <20120919151806.GK85604@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit X-SpamTest-Envelope-From: ivsan@ngs.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: NOTSPAM X-SpamTest-Info: Profiles 36850 [Sep 20 2012] X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status-Extended: not_detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: Re: getting counters for a plenty of vlan ifaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 10:09:23 -0000 On Wed, 19 Sep 2012 19:18:06 +0400 Gleb Smirnoff wrote: > That's strange. Per-minute read shouldn't induce > large CPU load. > > What snmp daemon do you use? I remember that several > years ago net-snmp daemon from ports used a single > linked list for all ARP entries, and thus it consumed a lot > of CPU when receiving a single ARP change from routing > socket. It was net-snmp-5.3.. port. Just checked on net-snmp-5.7.1 running on FreeBSD-9.0 and I see that things have changed significantly. And even # snmpbulkwalk -v2c -On -c 1.3.6.1.2.1.4.22.1.2 running in an endless loop doesn't seem to affect the number of context switches. Only the page faults count grow up to 50k per second. Don't know if this metric has some relation with router performance. # vmstat a 1 procs memory page faults cpu r b w avm fre flt re pi po fr sr in sy cs us sy id 1 0 0 1034M 108M 99 0 0 0 0 0 17175 3814 30714 2 12 86 0 0 0 1034M 108M 0 0 0 0 180 0 17230 945 31461 1 15 84 1 0 0 1034M 108M 28627 0 0 0 0 0 17268 1734 30860 2 25 73 1 0 0 1034M 108M 54835 0 0 0 0 0 17192 7084 31114 5 36 59 0 0 0 1034M 108M 52911 0 0 0 0 0 17300 3508 31402 3 32 65 ... Thanks for the helpful message. So my issue seems to be resolved. I've been too naive not to recheck an old observation on a contemporary versions. Even "/usr/sbin/arp -an" some time ago (pre 8.0?) affected the cpu load somewhat. Now even arp -an running continuosly seems to have little impact on it. Thanks, Ivan From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 14:26:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8635106564A for ; Thu, 20 Sep 2012 14:26:08 +0000 (UTC) (envelope-from juanjo.listas@doblej.net) Received: from zaragoza.intera5.net (zaragoza.intera5.net [212.81.143.133]) by mx1.freebsd.org (Postfix) with ESMTP id 861EB8FC0C for ; Thu, 20 Sep 2012 14:26:08 +0000 (UTC) Received: from [192.168.3.10] (unknown [192.168.3.10]) (Authenticated sender: juanjose.sanchez@intera5.es) by zaragoza.intera5.net (Postfix) with ESMTPA id 1735A1D911 for ; Thu, 20 Sep 2012 16:38:42 +0200 (CEST) Message-ID: <505B2555.40704@doblej.net> Date: Thu, 20 Sep 2012 16:16:53 +0200 From: =?ISO-8859-1?Q?Juan_Jos=E9_S=E1nchez_Mesa?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:26:08 -0000 Hi! (sorry for my bad english) I have a FreeBSD machine (8.2-RELEASE-p3). The machine has two ethernet cards, configured in this way: - Card A: internet IP address - Card B: intranet IP address Default route goes via card A. Now, on the intranet I have a "normal" DSL router. Then, using NAT i've forewarded a simple port from the DSL to the intranet IP of this machine. The incoming packets from the DSL comes ok to the machine (via card B), but the outgoing packet goes to card A, due to the default route. There is a way to configure the network so that outgoing packets goes to the card from where the incoming packets was arrived ? Or is this impossible to configure ? Thanks!!! From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 14:29:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB299106564A for ; Thu, 20 Sep 2012 14:29:21 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by mx1.freebsd.org (Postfix) with ESMTP id 823A68FC15 for ; Thu, 20 Sep 2012 14:29:21 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.80,453,1344236400"; d="p7s'?scan'208";a="691947841" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 20 Sep 2012 07:29:21 -0700 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q8KETKg6025466; Thu, 20 Sep 2012 07:29:20 -0700 (PDT) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.46]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0309.002; Thu, 20 Sep 2012 07:29:21 -0700 From: "Eggert, Lars" To: =?iso-8859-1?Q?Juan_Jos=E9_S=E1nchez_Mesa?= Thread-Topic: Multiroute question Thread-Index: AQHNlzwAYoWtfQMXrEKTG1DxHQZPtZeTv4SA Date: Thu, 20 Sep 2012 14:29:19 +0000 Message-ID: References: <505B2555.40704@doblej.net> In-Reply-To: <505B2555.40704@doblej.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_4E733770-BE76-4659-BBF7-78F8D60FC4F4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "" Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:29:21 -0000 --Apple-Mail=_4E733770-BE76-4659-BBF7-78F8D60FC4F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 20, 2012, at 16:16, Juan Jos=E9 S=E1nchez Mesa = wrote: > There is a way to configure the network so that outgoing packets goes = to the card from where the incoming packets was arrived ? Policy routing e.g. with ipfw. Read up on ipfw "fwd". Lars= --Apple-Mail=_4E733770-BE76-4659-BBF7-78F8D60FC4F4-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 14:37:11 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8047E106566C for ; Thu, 20 Sep 2012 14:37:11 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 082B58FC14 for ; Thu, 20 Sep 2012 14:37:10 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1155260bkc.13 for ; Thu, 20 Sep 2012 07:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=m/eGrRXldRNek9aCLJRwrIIJBRIc0PVhCCp1wS38jOo=; b=Xb9b857/wReKBzdDZv2gJABN6CRaqIdKjhzIZiYB/F2NqT5JgUBJl2zqkDwHiq4CVB pHtfu5ZB0LmIaUgoYNsvpLDTezvwPrS8JkNHwevanqs5srin+CtYUTlizTxBMYg+gTgB kULStA+Z73enMMUecRPdC3KoATv1WG/RvOKahXdbjkXT9vZHwPPGkECcRFgvPgYv3k6q T3Gon6uiHa31wBCaWvuEPUCG2yK5BpeC18/VKSD11NC420yYJigK/g26Yaha+6M3Re1z lx/ZUUxa+WevBYE1e4ArQAnwmcC89ePG2kAeuupLqBQ4J0TjreWWENeKK3cboBHA9bF/ YIVg== Received: by 10.204.8.84 with SMTP id g20mr777293bkg.126.1348151824006; Thu, 20 Sep 2012 07:37:04 -0700 (PDT) Received: from [10.0.0.86] ([93.152.184.10]) by mx.google.com with ESMTPS id f7sm4505934bkv.1.2012.09.20.07.37.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Sep 2012 07:37:03 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=iso-8859-1 From: Nikolay Denev In-Reply-To: <505B2555.40704@doblej.net> Date: Thu, 20 Sep 2012 17:36:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1A848DF9-53C7-4A06-85CD-81234EC85BF8@gmail.com> References: <505B2555.40704@doblej.net> To: =?iso-8859-1?Q?Juan_Jos=E9_S=E1nchez_Mesa?= X-Mailer: Apple Mail (2.1498) Cc: freebsd-net@freebsd.org Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:37:11 -0000 On Sep 20, 2012, at 5:16 PM, Juan Jos=E9 S=E1nchez Mesa = wrote: > Hi! >=20 > (sorry for my bad english) >=20 > I have a FreeBSD machine (8.2-RELEASE-p3). The machine has two = ethernet cards, configured in this way: >=20 > - Card A: internet IP address > - Card B: intranet IP address >=20 > Default route goes via card A. >=20 > Now, on the intranet I have a "normal" DSL router. Then, using NAT = i've forewarded a simple port from the DSL to the intranet IP of this = machine. >=20 > The incoming packets from the DSL comes ok to the machine (via card = B), but the outgoing packet goes to card A, due to the default route. >=20 > There is a way to configure the network so that outgoing packets goes = to the card from where the incoming packets was arrived ? >=20 > Or is this impossible to configure ? >=20 > Thanks!!! >=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" Hi, You will probably need the pf(4) firewall configured with the "reply-to" = keyword for this to work. Something like : pass in on $CARD_B reply-to ($CARD_B, $CARD_B_GW) from any to any Regards, Nikolay Denev From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 15:01:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8975B106566B for ; Thu, 20 Sep 2012 15:01:28 +0000 (UTC) (envelope-from misho@elwix.org) Received: from x0r.aitnet.org (unknown [IPv6:2a00:e40:deba:1::5]) by mx1.freebsd.org (Postfix) with ESMTP id E68908FC08 for ; Thu, 20 Sep 2012 15:01:27 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by x0r.aitnet.org (Postfix) with ESMTP id B741C3F704 for ; Thu, 20 Sep 2012 18:01:20 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitnet.org Received: from x0r.aitnet.org ([127.0.0.1]) by localhost (x0r.aitnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohAFRp-G726g for ; Thu, 20 Sep 2012 18:01:15 +0300 (EEST) Received: from pi.batmbg.com (unknown [212.116.129.162]) by x0r.aitnet.org (Postfix) with ESMTPSA id 9C4D43F731 for ; Thu, 20 Sep 2012 18:01:15 +0300 (EEST) Date: Thu, 20 Sep 2012 18:01:15 +0300 From: Michael Pounov To: freebsd-net@freebsd.org Message-Id: <20120920180115.ede9a2b8.misho@elwix.org> In-Reply-To: <505B2555.40704@doblej.net> References: <505B2555.40704@doblej.net> Organization: ELWIX X-Mailer: Sylpheed 3.1.4 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:01:28 -0000 Hi, Juan Use pf like in that simple example: $dsl_if = "CardA" $int_if = "CardB" $dsl_addr = "_dsl_if_ip_" $int_addr = "_int_if_ip_" $dsl_gw = "_dsl_gw_ip_" $int_gw = "_int_gw_ip_" set state-policy if-bound .... blah blah blah whatever rules ... pass out on $dsl_if route-to ($int_if $int_gw) from $int_if no state pass out on $int_if route-to ($dsl_if $dsl_gw) from $dsl_if no state # End pf example ;) On Thu, 20 Sep 2012 16:16:53 +0200 Juan José Sánchez Mesa wrote: > Hi! > > (sorry for my bad english) > > I have a FreeBSD machine (8.2-RELEASE-p3). The machine has two ethernet > cards, configured in this way: > > - Card A: internet IP address > - Card B: intranet IP address > > Default route goes via card A. > > Now, on the intranet I have a "normal" DSL router. Then, using NAT i've > forewarded a simple port from the DSL to the intranet IP of this machine. > > The incoming packets from the DSL comes ok to the machine (via card B), > but the outgoing packet goes to card A, due to the default route. > > There is a way to configure the network so that outgoing packets goes to > the card from where the incoming packets was arrived ? > > Or is this impossible to configure ? > > Thanks!!! > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Best Regards, Michael Pounov ELWIX - embedded lightweight unix - WWW: http://www.elwix.org/ EMail: misho@elwix.org Skype: mpunov XMPP: misho@aitnet.org Phone: +359 888 737358; +359 899 737358 From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 17:26:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D38B1106566B for ; Thu, 20 Sep 2012 17:26:16 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id 980E28FC0A for ; Thu, 20 Sep 2012 17:26:16 +0000 (UTC) Received: by ieak10 with SMTP id k10so1323470iea.13 for ; Thu, 20 Sep 2012 10:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bdlg5HXuqk79ggehOWzQUD/e14LAKK3qobcIHc+q92c=; b=Mt+Bxy6cF1GVbOZ3Qs5husi9yN0SlZtj0ahz0USrJU0szRCElP7sT4YkZc75a4LK1k X9xUpqkZZysaX46QfpEZAfHP20OcEQ8qhZNjgo3WMl9CQjFdXN3+78Iay6BP77rKjk9P dRnA02ptaksVN3Cp/ERNLbYPfzELoiYJ4QKB408R+OdFKqcT/gWeqiKzv/nN8YocZkJB E2oiFmUBFrCYCRsnjQzp/RG8+m+k57xD8tUd1xtyCK/1/0+oRFbtXjelckIXFykxUvDq VNkroAsNwxn6OLtnms9l6z369j3oqdHnklGBGzXsOIhho+3GTToJmHwkI9iRun7FFDyG DYbA== Received: by 10.50.154.227 with SMTP id vr3mr2746269igb.43.1348161970415; Thu, 20 Sep 2012 10:26:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.19.73 with HTTP; Thu, 20 Sep 2012 10:25:50 -0700 (PDT) In-Reply-To: <20120920180115.ede9a2b8.misho@elwix.org> References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> From: Michael MacLeod Date: Thu, 20 Sep 2012 13:25:50 -0400 Message-ID: To: Michael Pounov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 17:26:16 -0000 Actually, multiple routing tables is the correct solution. I documented it here: http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using= -multiple-routing-table/ >From the post: "... But route-to and reply-to do not trump the default routing table for traffic that originates or terminates on the router itself. They are useful only for traffic passing through the router. pf can only make routing decisions when a packet passes through an interface. It can try and set the reply-to interface to be the second WAN connection when an inbound SSH connection is made, but neither the SSH daemon nor the routing table on the host know or care about the routing preferences of pf.= " On Thu, Sep 20, 2012 at 11:01 AM, Michael Pounov wrote: > Hi, Juan > > Use pf like in that simple example: > > $dsl_if =3D "CardA" > $int_if =3D "CardB" > $dsl_addr =3D "_dsl_if_ip_" > $int_addr =3D "_int_if_ip_" > $dsl_gw =3D "_dsl_gw_ip_" > $int_gw =3D "_int_gw_ip_" > > set state-policy if-bound > > .... blah blah blah whatever rules ... > > pass out on $dsl_if route-to ($int_if $int_gw) from $int_if no state > pass out on $int_if route-to ($dsl_if $dsl_gw) from $dsl_if no state > > # End pf example ;) > > On Thu, 20 Sep 2012 16:16:53 +0200 > Juan Jos=E9 S=E1nchez Mesa wrote: > > > Hi! > > > > (sorry for my bad english) > > > > I have a FreeBSD machine (8.2-RELEASE-p3). The machine has two ethernet > > cards, configured in this way: > > > > - Card A: internet IP address > > - Card B: intranet IP address > > > > Default route goes via card A. > > > > Now, on the intranet I have a "normal" DSL router. Then, using NAT i've > > forewarded a simple port from the DSL to the intranet IP of this machin= e. > > > > The incoming packets from the DSL comes ok to the machine (via card B), > > but the outgoing packet goes to card A, due to the default route. > > > > There is a way to configure the network so that outgoing packets goes t= o > > the card from where the incoming packets was arrived ? > > > > Or is this impossible to configure ? > > > > Thanks!!! > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > -- > Best Regards, > > Michael Pounov > ELWIX - embedded lightweight unix - > > WWW: http://www.elwix.org/ > EMail: misho@elwix.org > Skype: mpunov > XMPP: misho@aitnet.org > Phone: +359 888 737358; +359 899 737358 > _______________________________________________ > 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 Sep 20 19:26:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FE6D1065701 for ; Thu, 20 Sep 2012 19:26:06 +0000 (UTC) (envelope-from misho@elwix.org) Received: from x0r.aitnet.org (unknown [IPv6:2a00:e40:deba:1::5]) by mx1.freebsd.org (Postfix) with ESMTP id F40B68FC15 for ; Thu, 20 Sep 2012 19:26:05 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by x0r.aitnet.org (Postfix) with ESMTP id 451CF3F72B; Thu, 20 Sep 2012 22:26:05 +0300 (EEST) X-Virus-Scanned: amavisd-new at aitnet.org Received: from x0r.aitnet.org ([127.0.0.1]) by localhost (x0r.aitnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8lFm+a6uMeZ; Thu, 20 Sep 2012 22:26:04 +0300 (EEST) Received: from terran.aitnet.org (unknown [77.70.75.103]) by x0r.aitnet.org (Postfix) with ESMTPSA id 3805E3F707; Thu, 20 Sep 2012 22:26:04 +0300 (EEST) Date: Thu, 20 Sep 2012 22:26:03 +0300 From: Michael Pounov To: freebsd-net@freebsd.org Message-Id: <20120920222603.b5ebc4f5.misho@elwix.org> In-Reply-To: References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> Organization: ELWIX X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.6; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: mikemacleod@gmail.com Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 19:26:07 -0000 I dont think that route-to is only for passthrough traffic :):):) This pf config work even traffic is originated from and to machine ;) :) Please read option careful in example ;) On Thu, 20 Sep 2012 13:25:50 -0400 Michael MacLeod wrote: > Actually, multiple routing tables is the correct solution. I documented it > here: > > http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/ > > >From the post: "... But route-to and reply-to do not trump the default > routing table for traffic that originates or terminates on the router > itself. They are useful only for traffic passing through the router. pf can > only make routing decisions when a packet passes through an interface. It > can try and set the reply-to interface to be the second WAN connection when > an inbound SSH connection is made, but neither the SSH daemon nor the > routing table on the host know or care about the routing preferences of pf." > > On Thu, Sep 20, 2012 at 11:01 AM, Michael Pounov wrote: > > > Hi, Juan > > > > Use pf like in that simple example: > > > > $dsl_if = "CardA" > > $int_if = "CardB" > > $dsl_addr = "_dsl_if_ip_" > > $int_addr = "_int_if_ip_" > > $dsl_gw = "_dsl_gw_ip_" > > $int_gw = "_int_gw_ip_" > > > > set state-policy if-bound > > > > .... blah blah blah whatever rules ... > > > > pass out on $dsl_if route-to ($int_if $int_gw) from $int_if no state > > pass out on $int_if route-to ($dsl_if $dsl_gw) from $dsl_if no state > > > > # End pf example ;) > > > > On Thu, 20 Sep 2012 16:16:53 +0200 > > Juan José Sánchez Mesa wrote: > > > > > Hi! > > > > > > (sorry for my bad english) > > > > > > I have a FreeBSD machine (8.2-RELEASE-p3). The machine has two ethernet > > > cards, configured in this way: > > > > > > - Card A: internet IP address > > > - Card B: intranet IP address > > > > > > Default route goes via card A. > > > > > > Now, on the intranet I have a "normal" DSL router. Then, using NAT i've > > > forewarded a simple port from the DSL to the intranet IP of this machine. > > > > > > The incoming packets from the DSL comes ok to the machine (via card B), > > > but the outgoing packet goes to card A, due to the default route. > > > > > > There is a way to configure the network so that outgoing packets goes to > > > the card from where the incoming packets was arrived ? > > > > > > Or is this impossible to configure ? > > > > > > Thanks!!! > > > > > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > > > -- > > Best Regards, > > > > Michael Pounov > > ELWIX - embedded lightweight unix - > > > > WWW: http://www.elwix.org/ > > EMail: misho@elwix.org > > Skype: mpunov > > XMPP: misho@aitnet.org > > Phone: +359 888 737358; +359 899 737358 > > _______________________________________________ > > 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" -- Best Regards! Michael Pounov +359 888 737358, +359 899 737358 WWW: http://www.elwix.org/ XMPP: misho@aitnet.org Skype: mpunov From owner-freebsd-net@FreeBSD.ORG Fri Sep 21 05:22:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E45106564A for ; Fri, 21 Sep 2012 05:22:30 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 764078FC0A for ; Fri, 21 Sep 2012 05:22:30 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-8.hsd1.ca.comcast.net [50.143.149.8]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q8L5MFpD005423 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 22:22:19 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <505BF987.5020602@freebsd.org> Date: Thu, 20 Sep 2012 22:22:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Juan_Jos=E9_S=E1nchez_Mesa?= References: <505B2555.40704@doblej.net> In-Reply-To: <505B2555.40704@doblej.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 05:22:30 -0000 On 9/20/12 7:16 AM, Juan José Sánchez Mesa wrote: > Hi! > > (sorry for my bad english) > > I have a FreeBSD machine (8.2-RELEASE-p3). The machine has two > ethernet cards, configured in this way: > > - Card A: internet IP address > - Card B: intranet IP address > > Default route goes via card A. > > Now, on the intranet I have a "normal" DSL router. Then, using NAT > i've forewarded a simple port from the DSL to the intranet IP of > this machine. I do not understand this line please draw pictures :-) internet ---DSL ----DLSROUTER------A[FreeBSD]B------inside net.. is this what you mean? > > The incoming packets from the DSL comes ok to the machine (via card > B), but the outgoing packet goes to card A, due to the default route. > > There is a way to configure the network so that outgoing packets > goes to the card from where the incoming packets was arrived ? > > Or is this impossible to configure ? > > Thanks!!! > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Sep 21 05:54:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3141106566B for ; Fri, 21 Sep 2012 05:54:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 991BB8FC08 for ; Fri, 21 Sep 2012 05:54:56 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-8.hsd1.ca.comcast.net [50.143.149.8]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q8L5soBW005582 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 22:54:50 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <505C0129.50202@freebsd.org> Date: Thu, 20 Sep 2012 22:54:49 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Michael MacLeod References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Michael Pounov Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 05:54:56 -0000 On 9/20/12 10:25 AM, Michael MacLeod wrote: > Actually, multiple routing tables is the correct solution. I > documented it here: > http://www.mmacleod.ca/blog/2011/06/source-based-routing-with-freebsd-using-multiple-routing-table/ > >From the post: "... But route-to and reply-to do not trump the > default routing table for traffic that originates or terminates on > the router itself. They are useful only for traffic passing through > the router. pf can only make routing decisions when a packet passes > through an interface. It can try and set the reply-to interface to > be the second WAN connection when an inbound SSH connection is made, > but neither the SSH daemon nor the routing table on the host know or > care about the routing preferences of pf." On Thu, Sep 20, 2012 at > 11:01 AM, Michael Pounov wrote: > hi, not a bad article.. a couple of things... firstly, though it's not relevent to THIS case, you can assign differnet fibs to different sockets on the same process, so theoretically a single sshd instance could do both tasks. The question is "how does it know which to use?" without extending sshd to add more config options for that, we have just a few possibilities.. Firstly, all sockets inherit their fib from that assigned to the process, but what if we didn't assign one to the process, but let the sockets take on the fib assigne to the packets of the incoming request? The packets in turn can get a fib from two sources: policy, via pf, or the ipfw setfib command, OR from the interface. as we can now assign a fib to an interface and packets coming in on that interface will take on the fib of the incoming interface. The only missing part of this is the code that lets teh process's fib float in the wind. I was considering setting this like: setfib -N sshd blah.... where -N would be expressed within the kernel as fib -1. In the socket code that would be inherited, and we would add code in the listen/accept code of the sockets so that when it discovers the socket is assigned fib -1, it switches it over to the fib of the incoming SYN packet (or whatever protocol). I've been meaning to a this ever since I added multifib support. It may require a small amount of code in every protocol (a line or two of C) This would allow us to make unmodified arbitrary networking servers work correctlty in multihomed systems. from man ifconfig: fib fib_number Specify interface FIB. A FIB fib_number is assigned to all frames or packets received on that interface. The FIB is not inherited, e.g. vlans or other sub-interfaces will use the default FIB (0) irrespective of the parent interface's FIB. The kernel needs to be tuned to support more than the default FIB using the ROUTETABLES kernel configuration option, or the net.fibs tunable. from man ifpw: setfib fibnum | tablearg The packet is tagged so as to use the FIB (routing table) fibnum in any subsequent forwarding decisions. Initially this is lim- ited to the values 0 through 15, see setfib(1). Processing con- tinues at the next rule. It is possible to use the tablearg key- word with a setfib. If tablearg value is not within compiled FIB range packet fib is set to 0. from man setsockopt SO_SETFIB can be used to over-ride the default FIB (routing table) for the given socket. The value must be from 0 to one less than the number returned from the sysctl net.fibs. see also: setfib(1), setfib(2), setsockopt(2) From owner-freebsd-net@FreeBSD.ORG Fri Sep 21 08:09:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21EDE106564A; Fri, 21 Sep 2012 08:09:09 +0000 (UTC) (envelope-from anshukla@juniper.net) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by mx1.freebsd.org (Postfix) with ESMTP id 7E7598FC0C; Fri, 21 Sep 2012 08:09:08 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUFwgnvbuloRzQ8UYmklzA60hdzxLokx7@postini.com; Fri, 21 Sep 2012 01:09:08 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 21 Sep 2012 01:00:46 -0700 From: Anuranjan Shukla To: Julian Elischer Date: Fri, 21 Sep 2012 01:00:44 -0700 Thread-Topic: Proposal for changes to network device drivers and network stack (RFC) Thread-Index: Ac2XzzRqHWLEI8AgQJORQYsSLNqh7w== Message-ID: In-Reply-To: <504A1755.6090902@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:09:09 -0000 On 9/7/12 8:48 AM, "Julian Elischer" wrote: >>>> struct socket { >>>> >>>> int so_fibnum; /* routing domain for this socket */ >>>> uint32_t so_user_cookie; >>>> + u_int so_oqueue; /* manage send prioritizing based on >>>> application >>>> needs */ >>>> + u_short so_lrid; /* logical routing */ >>>> }; >>>> >>> >We have the second one with the SETFIB socket option, which allows >a socket to select the routing instance (fib) to use. > >it's in the diff, 3 lines up. Thanks Julian. I had wondered if our usage of so_lrid was different enough to justify another field, primarily because I wasn't sure about potential clash with setfib() for the process (since Junos doesn't use it). Having looked a bit more into setfib() after your comment, it looks ok for Junos to use so_fibnum. I'll remove so_lrid from our diff. From owner-freebsd-net@FreeBSD.ORG Fri Sep 21 09:15:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED5EA106566C for ; Fri, 21 Sep 2012 09:15:00 +0000 (UTC) (envelope-from anshukla@juniper.net) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by mx1.freebsd.org (Postfix) with ESMTP id 831ED8FC0C for ; Fri, 21 Sep 2012 09:15:00 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUFwwB8s5lxDsNJ8yku6hx5iW1+wjK/Zz@postini.com; Fri, 21 Sep 2012 02:15:00 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 21 Sep 2012 02:12:50 -0700 From: Anuranjan Shukla To: George Neville-Neil Date: Fri, 21 Sep 2012 02:12:47 -0700 Thread-Topic: Proposal for changes to network device drivers and network stack (RFC) Thread-Index: Ac2X2UV16qmg6bzeRjWvEbm5INbL3Q== Message-ID: In-Reply-To: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:15:01 -0000 Hi George, On 9/5/12 1:15 PM, "George Neville-Neil" wrote: > >> Building FreeBSD without the network stack (network stack as a module) >> ---------------------------------------------------------------------- >> Today, not compiling networking stack related files in the kernel breaks >> the kernel build due to dependencies the OS has on the network stack >> (calling into functions in the network stack). Network stack module >>isn't >> there. We've added these in JUNOS. The benefits for us are obvious (we >>can >> load our own version of network stack if we desire!), but most likely >>this >> functionality will benefit others too. >>=20 >> The detailed implementation is indicated later in this email. In short >>the >> changes are: >>=20 >> - Load network stack as a module. For now via loader, not dynamically >> loaded. (Is there interest in dynamic loading?). >> - To facilitate calling network stack functionality from the generic >> kernel, a new interface has been defined with the kobj framework. >> - Some files and tunables needed to move to generic kernel areas (accept >> filters) >> - Generic socket code calls into network stack for interface and route >> related ioctls. Network stack now registers these ioctl groups >> - Other changes: uuid generation (register/query uuid sources), fib/sctp >> system calls (moved to network stack code, with system calls register >> dynamically). >>=20 > >This would be interesting for many reasons, and I think it would be a good >contribution. Does the work you've done in this area handle the VNET >stuff that is in the stack as well? That is, how well does the network >stack >as a module play with the vnet architecture? Full VNET friendliness is expected by the time we finalize this work. In the diff provided, vnet support (vent.c) is already made optional additionally for netstack option. We plan to validate these changes with VIMAGE. We should have the broken down diffs by next week. Thanks for your input. From owner-freebsd-net@FreeBSD.ORG Fri Sep 21 09:22:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6C5A1065675 for ; Fri, 21 Sep 2012 09:22:42 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2F29E8FC08 for ; Fri, 21 Sep 2012 09:22:42 +0000 (UTC) Received: by weyx56 with SMTP id x56so2152079wey.13 for ; Fri, 21 Sep 2012 02:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Bfl+gDfF6BZrZJzQARaafeUjg7bLQdw2DddNZ0QeKXg=; b=Ibp2oRQQzFbWVnNkgqYH66RC52T8dzvqJ7mltHofQu543b+abcZMA8WBikYC+Nik0c TC7Pg1o1Ge0EgNdDsnoomZo/crtMuI56LJLSfiPsMTkhkug003JPGiVf1jhky2huQ1Eb V9wSK6s2PWsJj+K8RDwp74vD1ZEYAw0w6t9sOPI6+isrSHKBCZZ2QzotfxrFLZLKNA2O Kv99NshPjo2y0zVkKbgqz0CipXIlfIvAlP4XxbBxbnEXdpe1NbHXJcKKnQeKGEciQoyN /tf6H9bLthc++y4xnmqHeJSU4C35JnsTckpYfS7sTC1FmPvaM6ulVRmGq7HSJ/goJqLl mCzA== Received: by 10.216.135.217 with SMTP id u67mr2781771wei.115.1348219360301; Fri, 21 Sep 2012 02:22:40 -0700 (PDT) Received: from localhost ([95.69.174.83]) by mx.google.com with ESMTPS id fb20sm15630234wid.1.2012.09.21.02.22.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 02:22:39 -0700 (PDT) Sender: Mikolaj Golub Date: Fri, 21 Sep 2012 12:22:36 +0300 From: Mikolaj Golub To: Anuranjan Shukla Message-ID: <20120921092235.GC66984@gmail.com> References: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:22:42 -0000 On Fri, Sep 07, 2012 at 01:28:16AM -0700, Anuranjan Shukla wrote: > Hi George, > Thanks for taking a look. Some answers/comments below. > > > > >> Building FreeBSD without the network stack (network stack as a module) > >> ---------------------------------------------------------------------- > >> > >This would be interesting for many reasons, and I think it would be a good > >contribution. Does the work you've done in this area handle the VNET > >stuff that is in the stack as well? That is, how well does the network > >stack > >as a module play with the vnet architecture? > > I'll follow up on this one separately. FYI, there is at least this issue with virtualized global variables in modules: http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-July/000737.html On archs that use link_elf.c (i.e. all except amd64, which uses link_elf_obj.c) virtualized global variables in modules can not be accessed from another modules, because link_elf on a module load does relocation only for VNET variables defined in this module. As it was pointed by Marko Zec, the same issue is with DPCPU. The latest patch I have (both for VNET and DPCPU): http://people.freebsd.org/~trociny/link_elf.c.pcpu_vnet.patch The fix is to make the linker on a module load recognize "external" VNET/DPCPU variables defined in the previously loaded modules and relocate them accordingly. For this set_pcpu_list and set_vnet_list are used, where the addresses of modules 'set_pcpu' and 'set_vnet' linker sets are stored in. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Sat Sep 22 19:23:22 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 148551065672 for ; Sat, 22 Sep 2012 19:23:22 +0000 (UTC) (envelope-from juanjo.listas@doblej.net) Received: from zaragoza.intera5.net (zaragoza.intera5.net [212.81.143.133]) by mx1.freebsd.org (Postfix) with ESMTP id C5A668FC1A for ; Sat, 22 Sep 2012 19:23:21 +0000 (UTC) Received: from [192.168.3.10] (unknown [192.168.3.10]) (Authenticated sender: juanjose.sanchez@intera5.es) by zaragoza.intera5.net (Postfix) with ESMTPA id C9C3B1D913 for ; Sat, 22 Sep 2012 21:45:32 +0200 (CEST) Message-ID: <505E1035.1000805@doblej.net> Date: Sat, 22 Sep 2012 21:23:33 +0200 From: =?UTF-8?B?SnVhbiBKb3PDqSBTw6FuY2hleiBNZXNh?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <505B2555.40704@doblej.net> <20120920180115.ede9a2b8.misho@elwix.org> In-Reply-To: <20120920180115.ede9a2b8.misho@elwix.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: Multiroute question X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 19:23:22 -0000 El 20/09/2012 17:01, Michael Pounov escribió: > Hi, Juan > > Use pf like in that simple example: > > $dsl_if = "CardA" > $int_if = "CardB" > $dsl_addr = "_dsl_if_ip_" > $int_addr = "_int_if_ip_" > $dsl_gw = "_dsl_gw_ip_" > $int_gw = "_int_gw_ip_" > > set state-policy if-bound > > .... blah blah blah whatever rules ... > > pass out on $dsl_if route-to ($int_if $int_gw) from $int_if no state > pass out on $int_if route-to ($dsl_if $dsl_gw) from $dsl_if no state > > # End pf example ;) Thanks!!! Worked perfectly !!!