From owner-freebsd-net@FreeBSD.ORG Sun Jan 12 09:15:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C79D519 for ; Sun, 12 Jan 2014 09:15:49 +0000 (UTC) Received: from udns.ultimateDNS.NET (ultimatedns.net [209.180.214.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C769A11E8 for ; Sun, 12 Jan 2014 09:15:48 +0000 (UTC) Received: from udns.ultimateDNS.NET (localhost [127.0.0.1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with ESMTP id s0C9FZra007608 for ; Sun, 12 Jan 2014 01:15:42 -0800 (PST) (envelope-from bsd-lists@1command.com) Received: (from www@localhost) by udns.ultimateDNS.NET (8.14.5/8.14.5/Submit) id s0C9FTJm007604; Sun, 12 Jan 2014 01:15:29 -0800 (PST) (envelope-from bsd-lists@1command.com) Received: from udns.ultimatedns.net ([209.180.214.225]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 12 Jan 2014 01:15:30 -0800 (PST) Message-ID: In-Reply-To: <20140111.180057.78714603.sthaug@nethelp.no> References: <1063008459.20140111160525@serebryakov.spb.ru> <20140111164047.GA97150@edge.bac.lab> <20140111.180057.78714603.sthaug@nethelp.no> Date: Sun, 12 Jan 2014 01:15:30 -0800 (PST) Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? From: "Chris H" To: freebsd-net@freebsd.org User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Jan 2014 09:15:49 -0000 >> >>From an operator's point of view: unlike ordinary network applications like >> remote login tools, we are usually aware of address family when using network >> management tools. We do not just want to know the reachability to the host, >> but want to know the reachability to the host via a particular network protocol >> such as IPv6. Thus, even if we had a unified ping(8) command for both IPv4 and >> IPv6, we would usually type a -6 or -4 option (or something like those) to >> specify the particular address family. This essentially means that we have two >> different commands. > > Disagree. As I showed in my previous message, *only* in the case of a > name with both A and AAAA records is this necessary. > > I use unified ping and traceroute on JunOS daily. It's a blessing not > to have to specify the address family. Disagree. In the current, on FreeBSD, in either case, it's less keystrokes. How is ping -6 || ping -4 better? What's the point? How will modifying all the some thousands of scripts everyone currently uses based on the current commands, make it better? Really. This is a silly argument. Adding switches makes no sense. --Chris > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > 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 Sun Jan 12 14:49:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1046871 for ; Sun, 12 Jan 2014 14:49:57 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 5C97316BE for ; Sun, 12 Jan 2014 14:49:57 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3f2LSM5PkHzGMxT for ; Sun, 12 Jan 2014 15:49:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1389538194; x=1392130195; bh=prr YN4sKQItvfEqEkvAuKjVnC3Dq5U4Sf3GhYLO/ShE=; b=Dn9IMI3vbGH9x87JLiN /9zPKL+CWxfXhiZIH+xBR+MFzswViw0wWCFw4IVQ+q8KodmIWnFkDijoGfN+Z8Pl DSk3snmwD8RpZ0D13w5tcoVVBwxXwUlAAB8lVDKJoNrxDCHDdDw0IX8SdLufPxaK 2YxVpHL834Va8yagBaQ++/tc= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id d3CawHfRXFZV for ; Sun, 12 Jan 2014 15:49:54 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Sun, 12 Jan 2014 15:49:53 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) by mildred.ijs.si (Postfix) with ESMTP id 9D8A5A61 for ; Sun, 12 Jan 2014 15:49:53 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Sun, 12 Jan 2014 15:49:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 12 Jan 2014 15:49:53 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single =?UTF-8?Q?utilities=3F?= Organization: J. Stefan Institute In-Reply-To: References: <1063008459.20140111160525@serebryakov.spb.ru> <20140111164047.GA97150@edge.bac.lab> <20140111.180057.78714603.sthaug@nethelp.no> Message-ID: <29dbfd1a0f58628972811daff470b832@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Jan 2014 14:49:57 -0000 2014-01-12 10:15, Chris H wrote: >> I use unified ping and traceroute on JunOS daily. It's a blessing not >> to have to specify the address family. > > Disagree. In the current, on FreeBSD, in either case, it's less > keystrokes. > How is ping -6 || ping -4 better? What's the point? Less keystrokes? As has been already said, specifying a -4 or -6 is hardly ever needed. If the target is an IPv4 or IPv6 address there is no need to explicitly specify a protocol family, it is already implied in the address family. Same if a localhost lives in only one address family. Nor is it necessary to specify the PF if one is only interested in basic reachability of a target and does not care to pick any particular PF, interface, source IP address, target IP address, routing table, etc. The only case when one would need to explicitly specify a protocol family is when a target is a DNS name (not an IP address) AND the local side is dual stacked with both address families configured. This situation is *no different* from the current situation where a target is a DNS name resolving to multiple IP addresses (like in case of some multihomed hosts or internet services which rely on DNS for load balancing): if basic service availability is to be checked and one is not picky about interface, IP address, route etc chosen, just specifying a DNS name suffices, otherwise one has to manually specify the target IP address *even now*. How often do you need to use -4 or -6 options in utilities like ssh, telnet, rsync, curl, wget, ... ? Hardly ever, most of the time it just works and does what is needed. At times when it doesn't, there is probably a need to fix the broken network anyway. Imagine the hurdles if there were separate utilities ssh6, telnet6, etc - one would need to check the local and remote address and choose a suitable utility variant. > How will modifying all the some thousands of scripts everyone currently > uses based on the current commands, make it better? It is easy to see how it makes it friendlier for scripts and monitoring tools. Scripting languages like shell and IPv6-challenged PHP which has no access to getaddrinfo(3) and friends currently need to go to great lengths if they want to ping some target. They need to resolve the target name to IP addresses, check to see to which address families these addresses belong, check local host for availability of each protocol family, and based on this pick either ping or ping6 command. Most of such scripts currently just do not care of fall short of doing it properly, which makes them break on IPv6-only hosts, or leave their functionality severely limited. Now we are in 2014, major sites have already switched to dual stack support, some services are only offered over IPv6 (mostly internal currently), some hosts are IPv6-only (and use http proxy or NAT64 to connect to legacy services). It is illusionary to expect the masses of ad-hoc scripts to be adapted. Giving them a modern powerful tool would make things much easier for script writers to do it right, and make sysadmins life easier. Mark From owner-freebsd-net@FreeBSD.ORG Sun Jan 12 16:48:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E6934AD for ; Sun, 12 Jan 2014 16:48:06 +0000 (UTC) Received: from yoshi.bluerosetech.com (yoshi.bluerosetech.com [IPv6:2607:f2f8:a450::66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 417531F42 for ; Sun, 12 Jan 2014 16:48:06 +0000 (UTC) Received: from chombo.houseloki.net (c-71-236-222-167.hsd1.wa.comcast.net [71.236.222.167]) by yoshi.bluerosetech.com (Postfix) with ESMTPSA id 48364E6040; Sun, 12 Jan 2014 08:48:04 -0800 (PST) Received: from [IPv6:2601:7:880:bd0:fc09:c077:33b5:32cc] (unknown [IPv6:2601:7:880:bd0:fc09:c077:33b5:32cc]) by chombo.houseloki.net (Postfix) with ESMTPSA id 6A36BD5E; Sun, 12 Jan 2014 08:47:49 -0800 (PST) Message-ID: <52D2C734.8000808@bluerosetech.com> Date: Sun, 12 Jan 2014 08:47:48 -0800 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Chris H , freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? References: <1063008459.20140111160525@serebryakov.spb.ru> <20140111164047.GA97150@edge.bac.lab> <20140111.180057.78714603.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: freebsd-net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2014 16:48:06 -0000 On 1/12/2014 1:15 AM, Chris H wrote: > How is ping -6 || ping -4 better? It would make them behave the same way as almost everything else, thus following the concept of feature parity between IPv4 and IPv6. > How will modifying all the some thousands of scripts everyone currently uses > based on the current commands, make it better? No need to modify scripts. Provide a hardlink to ping6 and add code that checks argv[0] and runs in compatibility mode if called as ping6. We can then use this opportunity to homogenize the IPv4 and IPv6 ping parameter assignments without breaking backward compatibility. From owner-freebsd-net@FreeBSD.ORG Mon Jan 13 03:22:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D95B6809 for ; Mon, 13 Jan 2014 03:22:50 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id C296D1CA3 for ; Mon, 13 Jan 2014 03:22:50 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id BBC643983B; Sun, 12 Jan 2014 19:22:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Mbuf reference count From: Rui Paulo In-Reply-To: Date: Sun, 12 Jan 2014 19:22:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Venkata Duvvuru X-Mailer: Apple Mail (2.1827) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 13 Jan 2014 03:22:50 -0000 On 2 Jan 2014, at 06:26, Venkata Duvvuru = wrote: > Hi, > Is there a way to increase the reference count of mbuf? I see there is = a ref count for external storage (m_ext) but couldn't find one for = !M_EXT case. The idea was to reference count the mbufs with external storage so that = m_copym() would avoid copying. Why do you need to reference count an = mbuf? mbufs are usually short lived and I haven't encountered any = situation yet where reference counting an mbuf would help. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Mon Jan 13 11:06:49 2014 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13D0F645 for ; Mon, 13 Jan 2014 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F2E81114B for ; Mon, 13 Jan 2014 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0DB6mI1095912 for ; Mon, 13 Jan 2014 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0DB6mlA095910 for freebsd-net@FreeBSD.org; Mon, 13 Jan 2014 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Jan 2014 11:06:48 GMT Message-Id: <201401131106.s0DB6mlA095910@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 13 Jan 2014 11:06:49 -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/185496 net [re] RTL8169 doesn't receive unicast ethernet packets o kern/185427 net [igb] freebsd 8.4, 9.1 and 9.2 panic Double-Fault with o kern/185023 net [tun] Closing tun interface deconfigures IP address o kern/185022 net [tun] ls /dev/tun creates tun interface o kern/184311 net [bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host o kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN RealtekŪ 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/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/166462 net [gre] gre(4) when using a tunnel source address from c 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 p kern/165903 net mbuf leak 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/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/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/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p 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/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/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 o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/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/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 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 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/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 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 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/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/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging 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/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation 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/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/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 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 475 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 13 15:37:11 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53F81372 for ; Mon, 13 Jan 2014 15:37:11 +0000 (UTC) Received: from mail.marples.name (unknown [IPv6:2a01:348:31:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9CACC19D8 for ; Mon, 13 Jan 2014 15:37:10 +0000 (UTC) Received: from mail.marples.name (uberserver.marples.name [10.73.1.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.marples.name (Postfix) with ESMTPSA id 07D38A1117 for ; Mon, 13 Jan 2014 15:36:41 +0000 (GMT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_e87c2615c7ad8fd96c87aab790f1c042" Date: Mon, 13 Jan 2014 15:36:40 +0000 From: Roy Marples To: freebsd-net@freebsd.org Subject: IPv6: report address flag changes to userland Message-ID: X-Sender: roy@marples.name User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 13 Jan 2014 15:37:11 -0000 --=_e87c2615c7ad8fd96c87aab790f1c042 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Hi List There is zero point as I see it in announcing newly added tentative addresses to userland. It's not as if userland can actually use the address at this point. However, there is immense benefit in announcing address flag changes, such as removal of tentative, or addition of the other flags. The main benefit for this patch is so that dhcpcd(8) listen for when the kernel has completed DAD and has announced the result. dhcpcd can then react immediately instead of having to wait for the full time as dictated by the RFC. The attached patch addresses the above and was cut from FreeBSD-9 - there is a small adjustment needed for -current which is noted in the patch. The patch is based on the work I did in NetBSD a few months ago documented here: http://netbsd.2816.n7.nabble.com/PATCH-to-only-announce-RTM-NEWADDR-once-IPv6-DAD-completes-tp281110.html Comments? Roy --=_e87c2615c7ad8fd96c87aab790f1c042 Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=freebsd-ipv6-tentative.diff Content-Disposition: attachment; filename=freebsd-ipv6-tentative.diff; size=8768 SW5kZXg6IHN5cy9uZXRpbmV0Ni9pbjYuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldDYvaW42 LmMJKHJldmlzaW9uIDI1NTIzNSkKKysrIHN5cy9uZXRpbmV0Ni9pbjYuYwkod29ya2luZyBjb3B5 KQpAQCAtMTQwLDggKzE0MCw5IEBACiAjZGVmaW5lIGlhNjJpZmEoaWE2KQkoJigoaWE2KS0+aWFf aWZhKSkKIAogdm9pZAotaW42X2lmYWRkbG9vcChzdHJ1Y3QgaWZhZGRyICppZmEpCitpbjZfaWZk b2xvb3Aoc3RydWN0IGlmYWRkciAqaWZhLCBpbnQgbGxmbGFncykKIHsKKwlpbnQgYW5ub3VuY2lu ZzsKIAlzdHJ1Y3Qgc29ja2FkZHJfZGwgZ2F0ZXdheTsKIAlzdHJ1Y3Qgc29ja2FkZHJfaW42IG1h c2ssIGFkZHI7CiAJc3RydWN0IHJ0ZW50cnkgcnQ7CkBAIC0xNTEsNzMgKzE1Miw2MyBAQAogCiAJ aWEgPSBpZmEyaWE2KGlmYSk7CiAJaWZwID0gaWZhLT5pZmFfaWZwOwotCUlGX0FGREFUQV9MT0NL KGlmcCk7Ci0JaWZhLT5pZmFfcnRyZXF1ZXN0ID0gTlVMTDsKLQotCS8qIFhYWCBRTAotCSAqIHdl IG5lZWQgdG8gcmVwb3J0IHJ0X25ld2FkZHJtc2cKLQkgKi8KLQlsbiA9IGxsYV9sb29rdXAoTExU QUJMRTYoaWZwKSwgKExMRV9DUkVBVEUgfCBMTEVfSUZBRERSIHwKLQkgICAgTExFX0VYQ0xVU0lW RSksIChzdHJ1Y3Qgc29ja2FkZHIgKikmaWEtPmlhX2FkZHIpOwotCUlGX0FGREFUQV9VTkxPQ0so aWZwKTsKLQlpZiAobG4gIT0gTlVMTCkgewotCQlsbi0+bGFfZXhwaXJlID0gMDsgIC8qIGZvciBJ UHY2IHRoaXMgbWVhbnMgcGVybWFuZW50ICovCi0JCWxuLT5sbl9zdGF0ZSA9IE5ENl9MTElORk9f UkVBQ0hBQkxFOwotCQkvKgotCQkgKiBpbml0aWFsaXplIGZvciBydG1zZyBnZW5lcmF0aW9uCi0J CSAqLworCS8qIERvbid0IHJlcG9ydCBuZXcgdGVudGF0aXZlIGFkZHJlc3NlcyB0byB0aGUgcm91 dGluZyBzb2NrZXQgKi8KKwlhbm5vdW5jaW5nID0gKGxsZmxhZ3MgJiBMTEVfREVMRVRFIHx8CisJ ICAgICgoaWEtPmlhNl9mbGFncyAmIElONl9JRkZfVEVOVEFUSVZFKSA9PSAwKSk7CisJaWYgKGFu bm91bmNpbmcpIHsKKwkJbWVtY3B5KCZhZGRyLCAmaWEtPmlhX2FkZHIsIHNpemVvZihpYS0+aWFf YWRkcikpOworCQltZW1jcHkoJm1hc2ssICZpYS0+aWFfcHJlZml4bWFzaywgc2l6ZW9mKGlhLT5p YV9wcmVmaXhtYXNrKSk7CiAJCWJ6ZXJvKCZnYXRld2F5LCBzaXplb2YoZ2F0ZXdheSkpOwogCQln YXRld2F5LnNkbF9sZW4gPSBzaXplb2YoZ2F0ZXdheSk7CiAJCWdhdGV3YXkuc2RsX2ZhbWlseSA9 IEFGX0xJTks7CiAJCWdhdGV3YXkuc2RsX25sZW4gPSAwOwotCQlnYXRld2F5LnNkbF9hbGVuID0g NjsKLQkJbWVtY3B5KGdhdGV3YXkuc2RsX2RhdGEsICZsbi0+bGxfYWRkci5tYWNfYWxpZ25lZCwK LQkJICAgIHNpemVvZihsbi0+bGxfYWRkcikpOwotCQlMTEVfV1VOTE9DSyhsbik7CisJCWJ6ZXJv KCZydCwgc2l6ZW9mKHJ0KSk7CisJCXJ0LnJ0X2dhdGV3YXkgPSAoc3RydWN0IHNvY2thZGRyICop JmdhdGV3YXk7CisJCXJ0LnJ0X2ZsYWdzID0gUlRGX0hPU1QgfCBSVEZfU1RBVElDOworCQlydF9t YXNrKCZydCkgPSAoc3RydWN0IHNvY2thZGRyICopJm1hc2s7CisJCXJ0X2tleSgmcnQpID0gKHN0 cnVjdCBzb2NrYWRkciAqKSZhZGRyOwogCX0KIAotCWJ6ZXJvKCZydCwgc2l6ZW9mKHJ0KSk7Ci0J cnQucnRfZ2F0ZXdheSA9IChzdHJ1Y3Qgc29ja2FkZHIgKikmZ2F0ZXdheTsKLQltZW1jcHkoJm1h c2ssICZpYS0+aWFfcHJlZml4bWFzaywgc2l6ZW9mKGlhLT5pYV9wcmVmaXhtYXNrKSk7Ci0JbWVt Y3B5KCZhZGRyLCAmaWEtPmlhX2FkZHIsIHNpemVvZihpYS0+aWFfYWRkcikpOwotCXJ0X21hc2so JnJ0KSA9IChzdHJ1Y3Qgc29ja2FkZHIgKikmbWFzazsKLQlydF9rZXkoJnJ0KSA9IChzdHJ1Y3Qg c29ja2FkZHIgKikmYWRkcjsKLQlydC5ydF9mbGFncyA9IFJURl9VUCB8IFJURl9IT1NUIHwgUlRG X1NUQVRJQzsKLQlydF9uZXdhZGRybXNnKFJUTV9BREQsIGlmYSwgMCwgJnJ0KTsKLX0KKwlpZiAo bGxmbGFncyAmIExMRV9ERUxFVEUpIHsKKwkJbGx0YWJsZV9wcmVmaXhfZnJlZShBRl9JTkVUNiwg KHN0cnVjdCBzb2NrYWRkciAqKSZhZGRyLAorCQkgICAgKHN0cnVjdCBzb2NrYWRkciAqKSZtYXNr LCBMTEVfU1RBVElDKTsKKwkJZ2F0ZXdheS5zZGxfYWxlbiA9IGlmcC0+aWZfYWRkcmxlbjsKKwl9 IGVsc2UgeworCQlsbGZsYWdzIHw9IExMRV9JRkFERFI7CisJCUlGX0FGREFUQV9MT0NLKGlmcCk7 CisJCWlmIChsbGZsYWdzICYgTExFX0NSRUFURSkgeworCQkJbGxmbGFncyB8PSBMTEVfRVhDTFVT SVZFOworCQkgICAgICAgIGlmYS0+aWZhX3J0cmVxdWVzdCA9IE5VTEw7IC8vIC1jdXJyZW50IHVz ZSBuZDZfcnRyZXF1ZXN0CisJCX0KKwkJbG4gPSBsbGFfbG9va3VwKExMVEFCTEU2KGlmcCksIGxs ZmxhZ3MsCisJCSAgICAoc3RydWN0IHNvY2thZGRyICopJmlhLT5pYV9hZGRyKTsKKwkJSUZfQUZE QVRBX1VOTE9DSyhpZnApOworCQlpZiAobG4gIT0gTlVMTCkgeworCQkJaWYgKGxsZmxhZ3MgJiBM TEVfQ1JFQVRFKSB7CisJCQkJbG4tPmxhX2V4cGlyZSA9IDA7ICAvKiBwZXJtYW5lbnQgKi8KKwkJ CQlsbi0+bG5fc3RhdGUgPSBORDZfTExJTkZPX1JFQUNIQUJMRTsKKwkJCX0KKwkJCWlmIChhbm5v dW5jaW5nKSB7CisJCQkJZ2F0ZXdheS5zZGxfYWxlbiA9IDY7CisJCQkJbWVtY3B5KGdhdGV3YXku c2RsX2RhdGEsCisJCQkJICAgICZsbi0+bGxfYWRkci5tYWNfYWxpZ25lZCwKKwkJCQkgICAgc2l6 ZW9mKGxuLT5sbF9hZGRyKSk7CisJCQl9CisJCQlpZiAobGxmbGFncyAmIExMRV9FWENMVVNJVkUp CisJCQkJTExFX1dVTkxPQ0sobG4pOworCQkJZWxzZQorCQkJCUxMRV9SVU5MT0NLKGxuKTsKKwkJ fQorCX0KIAotdm9pZAotaW42X2lmcmVtbG9vcChzdHJ1Y3QgaWZhZGRyICppZmEpCi17Ci0Jc3Ry dWN0IHNvY2thZGRyX2RsIGdhdGV3YXk7Ci0Jc3RydWN0IHNvY2thZGRyX2luNiBtYXNrLCBhZGRy OwotCXN0cnVjdCBydGVudHJ5IHJ0MDsKLQlzdHJ1Y3QgaW42X2lmYWRkciAqaWE7Ci0Jc3RydWN0 IGlmbmV0ICppZnA7Ci0KLQlpYSA9IGlmYTJpYTYoaWZhKTsKLQlpZnAgPSBpZmEtPmlmYV9pZnA7 Ci0JSUZfQUZEQVRBX0xPQ0soaWZwKTsKLQlsbGFfbG9va3VwKExMVEFCTEU2KGlmcCksIChMTEVf REVMRVRFIHwgTExFX0lGQUREUiksCi0JICAgIChzdHJ1Y3Qgc29ja2FkZHIgKikmaWEtPmlhX2Fk ZHIpOwotCUlGX0FGREFUQV9VTkxPQ0soaWZwKTsKLQotCS8qCi0JICogaW5pdGlhbGl6ZSBmb3Ig cnRtc2cgZ2VuZXJhdGlvbgotCSAqLwotCWJ6ZXJvKCZnYXRld2F5LCBzaXplb2YoZ2F0ZXdheSkp OwotCWdhdGV3YXkuc2RsX2xlbiA9IHNpemVvZihnYXRld2F5KTsKLQlnYXRld2F5LnNkbF9mYW1p bHkgPSBBRl9MSU5LOwotCWdhdGV3YXkuc2RsX25sZW4gPSAwOwotCWdhdGV3YXkuc2RsX2FsZW4g PSBpZnAtPmlmX2FkZHJsZW47Ci0JYnplcm8oJnJ0MCwgc2l6ZW9mKHJ0MCkpOwotCXJ0MC5ydF9n YXRld2F5ID0gKHN0cnVjdCBzb2NrYWRkciAqKSZnYXRld2F5OwotCW1lbWNweSgmbWFzaywgJmlh LT5pYV9wcmVmaXhtYXNrLCBzaXplb2YoaWEtPmlhX3ByZWZpeG1hc2spKTsKLQltZW1jcHkoJmFk ZHIsICZpYS0+aWFfYWRkciwgc2l6ZW9mKGlhLT5pYV9hZGRyKSk7Ci0JcnRfbWFzaygmcnQwKSA9 IChzdHJ1Y3Qgc29ja2FkZHIgKikmbWFzazsKLQlydF9rZXkoJnJ0MCkgPSAoc3RydWN0IHNvY2th ZGRyICopJmFkZHI7Ci0JcnQwLnJ0X2ZsYWdzID0gUlRGX0hPU1QgfCBSVEZfU1RBVElDOwotCXJ0 X25ld2FkZHJtc2coUlRNX0RFTEVURSwgaWZhLCAwLCAmcnQwKTsKKwlpZiAoYW5ub3VuY2luZykg eworCQlpZiAobGxmbGFncyAmIExMRV9ERUxFVEUpCisJCQlydF9uZXdhZGRybXNnKFJUTV9ERUxF VEUsIGlmYSwgMCwgJnJ0KTsKKwkJZWxzZSB7CisJCQlydC5ydF9mbGFncyB8PSBSVEZfVVA7CisJ CQlydF9uZXdhZGRybXNnKFJUTV9BREQsIGlmYSwgMCwgJnJ0KTsKKwkJfQorCX0KIH0KIAogaW50 CkBAIC0xMDIxLDEwICsxMDEyLDYgQEAKIAl9IGVsc2UKIAkJaWEtPmlhNl9saWZldGltZS5pYTZ0 X3ByZWZlcnJlZCA9IDA7CiAKLQkvKiByZXNldCB0aGUgaW50ZXJmYWNlIGFuZCByb3V0aW5nIHRh YmxlIGFwcHJvcHJpYXRlbHkuICovCi0JaWYgKChlcnJvciA9IGluNl9pZmluaXQoaWZwLCBpYSwg JmlmcmEtPmlmcmFfYWRkciwgaG9zdElzTmV3KSkgIT0gMCkKLQkJZ290byB1bmxpbms7Ci0KIAkv KgogCSAqIGNvbmZpZ3VyZSBhZGRyZXNzIGZsYWdzLgogCSAqLwpAQCAtMTA1MCw2ICsxMDM3LDEw IEBACiAJaWYgKE5EX0lGSU5GTyhpZnApLT5mbGFncyAmIE5ENl9JRkZfSUZESVNBQkxFRCkKIAkJ aWEtPmlhNl9mbGFncyB8PSBJTjZfSUZGX1RFTlRBVElWRTsKIAorCS8qIHJlc2V0IHRoZSBpbnRl cmZhY2UgYW5kIHJvdXRpbmcgdGFibGUgYXBwcm9wcmlhdGVseS4gKi8KKwlpZiAoKGVycm9yID0g aW42X2lmaW5pdChpZnAsIGlhLCAmaWZyYS0+aWZyYV9hZGRyLCBob3N0SXNOZXcpKSAhPSAwKQor CQlnb3RvIHVubGluazsKKwogCS8qCiAJICogV2UgYXJlIGRvbmUgaWYgd2UgaGF2ZSBzaW1wbHkg bW9kaWZpZWQgYW4gZXhpc3RpbmcgYWRkcmVzcy4KIAkgKi8KQEAgLTE4ODUsNiArMTg3Niw4IEBA CiAJLyogQWRkIG93bmFkZHIgYXMgbG9vcGJhY2sgcnRlbnRyeSwgaWYgbmVjZXNzYXJ5IChleC4g b24gcDJwIGxpbmspLiAqLwogCWlmIChuZXdob3N0KQogCQlpbjZfaWZhZGRsb29wKCYoaWEtPmlh X2lmYSkpOworCWVsc2UKKwkJbmQ2X25ld2FkZHJtc2coJihpYS0+aWFfaWZhKSk7CiAKIAlyZXR1 cm4gKGVycm9yKTsKIH0KSW5kZXg6IHN5cy9uZXRpbmV0Ni9pbjZfdmFyLmgKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQot LS0gc3lzL25ldGluZXQ2L2luNl92YXIuaAkocmV2aXNpb24gMjU1MjM1KQorKysgc3lzL25ldGlu ZXQ2L2luNl92YXIuaAkod29ya2luZyBjb3B5KQpAQCAtNzc1LDggKzc3NSw5IEBACiBpbnQJaW42 X3ByZWZpeF9hZGRfaWZpZCBfX1AoKGludCwgc3RydWN0IGluNl9pZmFkZHIgKikpOwogdm9pZAlp bjZfcHJlZml4X3JlbW92ZV9pZmlkIF9fUCgoaW50LCBzdHJ1Y3QgaW42X2lmYWRkciAqKSk7CiB2 b2lkCWluNl9wdXJnZXByZWZpeCBfX1AoKHN0cnVjdCBpZm5ldCAqKSk7Ci12b2lkCWluNl9pZnJl bWxvb3Aoc3RydWN0IGlmYWRkciAqKTsKLXZvaWQJaW42X2lmYWRkbG9vcChzdHJ1Y3QgaWZhZGRy ICopOwordm9pZAlpbjZfaWZkb2xvb3Aoc3RydWN0IGlmYWRkciAqLCBpbnQpOworI2RlZmluZQlp bjZfaWZhZGRsb29wKGlmYSkJaW42X2lmZG9sb29wKChpZmEpLCBMTEVfQ1JFQVRFKQorI2RlZmlu ZQlpbjZfaWZyZW1sb29wKGlmYSkJaW42X2lmZG9sb29wKChpZmEpLCBMTEVfREVMRVRFKQogCiBp bnQJaW42X2lzX2FkZHJfZGVwcmVjYXRlZCBfX1AoKHN0cnVjdCBzb2NrYWRkcl9pbjYgKikpOwog c3RydWN0IGlucGNiOwpJbmRleDogc3lzL25ldGluZXQ2L25kNi5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5 cy9uZXRpbmV0Ni9uZDYuYwkocmV2aXNpb24gMjU1MjM1KQorKysgc3lzL25ldGluZXQ2L25kNi5j CSh3b3JraW5nIGNvcHkpCkBAIC02MzIsNyArNjMyLDEwIEBACiAJCX0gZWxzZSBpZiAoSUZBNl9J U19ERVBSRUNBVEVEKGlhNikpIHsKIAkJCWludCBvbGRmbGFncyA9IGlhNi0+aWE2X2ZsYWdzOwog Ci0JCQlpYTYtPmlhNl9mbGFncyB8PSBJTjZfSUZGX0RFUFJFQ0FURUQ7CisJCQlpZiAoKG9sZGZs YWdzICYgSU42X0lGRl9ERVBSRUNBVEVEKSA9PSAwKSB7CisJCQkJaWE2LT5pYTZfZmxhZ3MgfD0g SU42X0lGRl9ERVBSRUNBVEVEOworCQkJCW5kNl9uZXdhZGRybXNnKChzdHJ1Y3QgaWZhZGRyICop aWE2KTsKKwkJCX0KIAogCQkJLyoKIAkJCSAqIElmIGEgdGVtcG9yYXJ5IGFkZHJlc3MgaGFzIGp1 c3QgYmVjb21lIGRlcHJlY2F0ZWQsCkBAIC02NjMsNyArNjY2LDEwIEBACiAJCQkgKiBBIG5ldyBS QSBtaWdodCBoYXZlIG1hZGUgYSBkZXByZWNhdGVkIGFkZHJlc3MKIAkJCSAqIHByZWZlcnJlZC4K IAkJCSAqLwotCQkJaWE2LT5pYTZfZmxhZ3MgJj0gfklONl9JRkZfREVQUkVDQVRFRDsKKwkJCWlm IChpYTYtPmlhNl9mbGFncyAmIElONl9JRkZfREVQUkVDQVRFRCkgeworCQkJCWlhNi0+aWE2X2Zs YWdzICY9IH5JTjZfSUZGX0RFUFJFQ0FURUQ7CisJCQkJbmQ2X25ld2FkZHJtc2coKHN0cnVjdCBp ZmFkZHIgKilpYTYpOworCQkJfQogCQl9CiAJfQogCkluZGV4OiBzeXMvbmV0aW5ldDYvbmQ2LmgK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gc3lzL25ldGluZXQ2L25kNi5oCShyZXZpc2lvbiAyNTUyMzUpCisrKyBz eXMvbmV0aW5ldDYvbmQ2LmgJKHdvcmtpbmcgY29weSkKQEAgLTQyOCw2ICs0MjgsNyBAQAogdm9p ZCBuZDZfbnNfb3V0cHV0IF9fUCgoc3RydWN0IGlmbmV0ICosIGNvbnN0IHN0cnVjdCBpbjZfYWRk ciAqLAogCWNvbnN0IHN0cnVjdCBpbjZfYWRkciAqLCBzdHJ1Y3QgbGxlbnRyeSAqLCBpbnQpKTsK IGNhZGRyX3QgbmQ2X2lmcHRvbWFjIF9fUCgoc3RydWN0IGlmbmV0ICopKTsKKyNkZWZpbmUgbmQ2 X25ld2FkZHJtc2coaWZhKQlpbjZfaWZkb2xvb3AoKGlmYSksIDApCiB2b2lkIG5kNl9kYWRfc3Rh cnQgX19QKChzdHJ1Y3QgaWZhZGRyICosIGludCkpOwogdm9pZCBuZDZfZGFkX3N0b3AgX19QKChz dHJ1Y3QgaWZhZGRyICopKTsKIHZvaWQgbmQ2X2RhZF9kdXBsaWNhdGVkIF9fUCgoc3RydWN0IGlm YWRkciAqKSk7CkluZGV4OiBzeXMvbmV0aW5ldDYvbmQ2X25ici5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5 cy9uZXRpbmV0Ni9uZDZfbmJyLmMJKHJldmlzaW9uIDI1NTIzNSkKKysrIHN5cy9uZXRpbmV0Ni9u ZDZfbmJyLmMJKHdvcmtpbmcgY29weSkKQEAgLTEyMTgsMTQgKzEyMTgsMTEgQEAKIAkJCWlmYS0+ aWZhX2lmcCA/IGlmX25hbWUoaWZhLT5pZmFfaWZwKSA6ICI/Pz8iKTsKIAkJcmV0dXJuOwogCX0K LQlpZiAoaWEtPmlhNl9mbGFncyAmIElONl9JRkZfQU5ZQ0FTVCkgeworCWlmIChpYS0+aWE2X2Zs YWdzICYgSU42X0lGRl9BTllDQVNUIHx8ICFWX2lwNl9kYWRfY291bnQpIHsKIAkJaWEtPmlhNl9m bGFncyAmPSB+SU42X0lGRl9URU5UQVRJVkU7CisJCW5kNl9uZXdhZGRybXNnKGlmYSk7CiAJCXJl dHVybjsKIAl9Ci0JaWYgKCFWX2lwNl9kYWRfY291bnQpIHsKLQkJaWEtPmlhNl9mbGFncyAmPSB+ SU42X0lGRl9URU5UQVRJVkU7Ci0JCXJldHVybjsKLQl9CiAJaWYgKGlmYS0+aWZhX2lmcCA9PSBO VUxMKQogCQlwYW5pYygibmQ2X2RhZF9zdGFydDogaWZhLT5pZmFfaWZwID09IE5VTEwiKTsKIAlp ZiAoIShpZmEtPmlmYV9pZnAtPmlmX2ZsYWdzICYgSUZGX1VQKSkgewpAQCAtMTM4Myw2ICsxMzgw LDcgQEAKIAkJCSAqIE5vIGR1cGxpY2F0ZSBhZGRyZXNzIGZvdW5kLgogCQkJICovCiAJCQlpYS0+ aWE2X2ZsYWdzICY9IH5JTjZfSUZGX1RFTlRBVElWRTsKKwkJCW5kNl9uZXdhZGRybXNnKGlmYSk7 CiAKIAkJCW5kNmxvZygoTE9HX0RFQlVHLAogCQkJICAgICIlczogREFEIGNvbXBsZXRlIGZvciAl cyAtIG5vIGR1cGxpY2F0ZXMgZm91bmRcbiIsCkBAIC0xNDMyLDYgKzE0MzAsOSBAQAogCWxvZyhM T0dfRVJSLCAiJXM6IG1hbnVhbCBpbnRlcnZlbnRpb24gcmVxdWlyZWRcbiIsCiAJICAgIGlmX25h bWUoaWZwKSk7CiAKKwkvKiBJbmZvcm0gdGhlIHJvdXRpbmcgc29ja2V0IHRoYXQgREFEIGhhcyBj b21wbGV0ZWQgKi8KKwluZDZfbmV3YWRkcm1zZyhpZmEpOworCiAJLyoKIAkgKiBJZiB0aGUgYWRk cmVzcyBpcyBhIGxpbmstbG9jYWwgYWRkcmVzcyBmb3JtZWQgZnJvbSBhbiBpbnRlcmZhY2UKIAkg KiBpZGVudGlmaWVyIGJhc2VkIG9uIHRoZSBoYXJkd2FyZSBhZGRyZXNzIHdoaWNoIGlzIHN1cHBv c2VkIHRvIGJlCkluZGV4OiBzeXMvbmV0aW5ldDYvbmQ2X3J0ci5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5 cy9uZXRpbmV0Ni9uZDZfcnRyLmMJKHJldmlzaW9uIDI1NTIzNSkKKysrIHN5cy9uZXRpbmV0Ni9u ZDZfcnRyLmMJKHdvcmtpbmcgY29weSkKQEAgLTE1MjUsOSArMTUyNSwxNSBAQAogCQkJCQlpZmEt PmlhNl9mbGFncyAmPSB+SU42X0lGRl9ERVRBQ0hFRDsKIAkJCQkJaWZhLT5pYTZfZmxhZ3MgfD0g SU42X0lGRl9URU5UQVRJVkU7CiAJCQkJCW5kNl9kYWRfc3RhcnQoKHN0cnVjdCBpZmFkZHIgKilp ZmEsIDApOworCQkJCQkvKiBXZSB3aWxsIG5vdGlmeSB0aGUgcm91dGluZyBzb2NrZXQgb2YKKwkJ CQkJICogdGhlIERBRCByZXN1bHQsIHNvIG5vIG5lZWQgdG8KKwkJCQkJICogaGVyZSAqLwogCQkJ CX0KIAkJCX0gZWxzZSB7Ci0JCQkJaWZhLT5pYTZfZmxhZ3MgfD0gSU42X0lGRl9ERVRBQ0hFRDsK KwkJCQlpZiAoKGlmYS0+aWE2X2ZsYWdzICYgSU42X0lGRl9ERVRBQ0hFRCkgPT0gMCkgeworCQkJ CQlpZmEtPmlhNl9mbGFncyB8PSBJTjZfSUZGX0RFVEFDSEVEOworCQkJCQluZDZfbmV3YWRkcm1z Zygoc3RydWN0IGlmYWRkciAqKWlmYSk7CisJCQkJfQogCQkJfQogCQl9CiAJfQo= --=_e87c2615c7ad8fd96c87aab790f1c042-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 13 16:54:03 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3DBD9F3 for ; Mon, 13 Jan 2014 16:54:03 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EF52117F for ; Mon, 13 Jan 2014 16:54:03 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1W2km0-000Lir-PW for freebsd-net@freebsd.org; Mon, 13 Jan 2014 20:54:00 +0400 Message-ID: <52D41A22.3060805@smartspb.net> Date: Mon, 13 Jan 2014 20:53:54 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? References: <1063008459.20140111160525@serebryakov.spb.ru> In-Reply-To: <1063008459.20140111160525@serebryakov.spb.ru> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140112-2, 12.01.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 13 Jan 2014 16:54:03 -0000 Hello all. I think it's a really good idea. -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Mon Jan 13 17:14:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 635021BF for ; Mon, 13 Jan 2014 17:14:28 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 23E641336 for ; Mon, 13 Jan 2014 17:14:27 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id uy5so8044876obc.12 for ; Mon, 13 Jan 2014 09:14:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=D3sOhI/I8uXCzO9Nd9KT1BYl2se7byF3Ge2QIbIAHYs=; b=PobHo+5/VLoFd1otnGe1DotKcPLt34YLxUK1f9foswhkZtbfZ336aSDefxXbZj2Qnq jWu/+3H8Rdp5IOiFEGYT6PcyJ9ZEw6ie3xxOeKlMZBFtAC6GymfD0f4TDIlWTX41L+wJ TzrCye9kqk6TDOZtG0dR+pywtDXKefb0YtDimzeVcj1J8aAGR2OsC4zPSa5FB6+jvoHJ 75QkvHzvX7Qbf9WZfQlvbSpXUC33PCaHoTLnuCgd9e62oSGdIbxEe7l+h3Tj+HakSsQU Hhetb4x0kB9mZYlZmu6PAakUvCVD+jnKtVH+iMImGHXASqu2nE6bT1e/R32ZwaRJI3ea VMgQ== X-Gm-Message-State: ALoCoQn3CEeETBVwf2gFuAZxQ6fsuf+j4/1yjXW4tPX3nih0beqaUDo+GYeH7XibspdvbT9VtheZ X-Received: by 10.182.92.231 with SMTP id cp7mr918533obb.82.1389633266842; Mon, 13 Jan 2014 09:14:26 -0800 (PST) Received: from [10.10.10.205] (rrcs-97-77-122-61.sw.biz.rr.com. [97.77.122.61]) by mx.google.com with ESMTPSA id ru3sm21723044obc.2.2014.01.13.09.14.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Jan 2014 09:14:19 -0800 (PST) Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: Jim Thompson X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 13 Jan 2014 11:14:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8B65C9B3-A9E9-4168-8BBF-58F98718F7F3@netgate.com> References: <1063008459.20140111160525@serebryakov.spb.ru> <20140111164047.GA97150@edge.bac.lab> <20140111.180057.78714603.sthaug@nethelp.no> To: Chris H X-Mailer: Apple Mail (2.1827) Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 13 Jan 2014 17:14:28 -0000 On Jan 12, 2014, at 3:15 AM, Chris H wrote: >>>>> =46rom an operator's point of view: unlike ordinary network = applications like >>> remote login tools, we are usually aware of address family when = using network >>> management tools. We do not just want to know the reachability to = the host, >>> but want to know the reachability to the host via a particular = network protocol >>> such as IPv6. Thus, even if we had a unified ping(8) command for = both IPv4 and >>> IPv6, we would usually type a -6 or -4 option (or something like = those) to >>> specify the particular address family. This essentially means that = we have two >>> different commands. >>=20 >> Disagree. As I showed in my previous message, *only* in the case of a >> name with both A and AAAA records is this necessary. >>=20 >> I use unified ping and traceroute on JunOS daily. It's a blessing not >> to have to specify the address family. >=20 > Disagree. In the current, on FreeBSD, in either case, it's less = keystrokes. > How is ping -6 || ping -4 better? > What's the point? > How will modifying all the some thousands of scripts everyone = currently uses > based on the current commands, make it better? > Really. This is a silly argument. Adding switches makes no sense. While I tend to agree with the query, (that ping6/ping and = traceroute6/traceroute could be merged), and that the =91old=92 behavior can simply be hand via passing in -4 or -6 = as a switch, this thread is quickly entering the domain otherwise known as =93bike shedding=94. There *have* to be better things to do. Jim From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 07:48:41 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28C7CB64 for ; Tue, 14 Jan 2014 07:48:41 +0000 (UTC) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0F2918E8 for ; Tue, 14 Jan 2014 07:48:40 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.14.7/8.14.7) with ESMTP id s0E7ORqI030225 for ; Tue, 14 Jan 2014 01:24:27 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (cpe-70-113-194-94.austin.res.rr.com [70.113.194.94]) by mail.shrew.net (Postfix) with ESMTPSA id 0CD1C1884C6 for ; Tue, 14 Jan 2014 01:24:19 -0600 (CST) Message-ID: <52D4E633.1060000@shrew.net> Date: Tue, 14 Jan 2014 01:24:35 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: TCP socket handling lo[X], buggy in 9.x? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx2.shrew.net [10.24.10.11]); Tue, 14 Jan 2014 01:24:27 -0600 (CST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 07:48:41 -0000 All, I am seeing weird issues with tcp connections when they are established from an address that is assigned to a lo interface on 9.2-RELEASE. This works fine on older FreeBSD hosts that I have tested ( like 7.1-RELEASE and 8.2-RELEASE ) but appears to be broken in 9.2-RELEASE-p2. Here is an example of the issue ... host1 ( 9.2-RELEASE ) \ em0: inet 10.22.200.101/24 lo1: inet inet 172.16.1.1/32 host2 ( 8.2-RELEASE ) \ em0: inet 10.22.200.102/24 lo1: inet inet 172.18.1.1/32 ... I add a route on host1 to reach 172.18.1.1/32 on host2 ... [host1]# route add -host 172.18.1.1 10.22.200.102 ... and add a route on host2 to reach 172.16.1.1/32 on host1 ... [host2]# route add -host 172.16.1.1 10.22.200.101 ... Then I use netcat to connect from host1 to host2. When I connect from the local em0 interface to the remote em0 interface, everything is good ... [host1]# nc -s 10.22.200.101 10.22.200.102 1000 line1 line2 line3 line4 [host2]# nc -k -l 1000 line1 line2 line3 line4 ... when I connect from the local em0 interface to the remote lo1 interface, everything looks good ( to lo1 on the 8.2 host ) ... [host1]# nc -s 10.22.200.101 172.18.1.1 1000 line1 line2 line3 line4 [host2]# nc -k -l 1000 line1 line2 line3 line4 ... When I connect from the local lo1 interface to the remote em0 interface, weird things start to happen ( from lo1 on the 9.2 host ) ... [host1]# nc -s 172.16.1.1 10.22.200.102 1000 line1 line2 [host1]# nc -s 172.16.1.1 10.22.200.102 1000 line1 line2 [host1]# nc -s 172.16.1.1 10.22.200.102 1000 line1 line2 [host2]# nc -k -l 1000 line1 line1 line1 ... Here is a comparison of the tcpdump output from scenario #1 vs scenario #3. ... tcpdump -ni em0 src or dst 10.22.200.102 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 00:49:34.897822 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [S], seq 2109171603, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 113771252 ecr 0], length 0 00:49:34.898133 IP 10.22.200.102.1000 > 10.22.200.101.18401: Flags [S.], seq 1520138341, ack 2109171604, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 763106128 ecr 113771252], length 0 00:49:34.898242 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [.], ack 1, win 1040, options [nop,nop,TS val 113771252 ecr 763106128], length 0 00:49:36.411982 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [P.], seq 1:7, ack 1, win 1040, options [nop,nop,TS val 113772775 ecr 763106128], length 6 00:49:36.502874 IP 10.22.200.102.1000 > 10.22.200.101.18401: Flags [.], ack 7, win 8326, options [nop,nop,TS val 763106289 ecr 113772775], length 0 00:49:37.635691 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [P.], seq 7:13, ack 1, win 1040, options [nop,nop,TS val 113773992 ecr 763106289], length 6 00:49:37.733039 IP 10.22.200.102.1000 > 10.22.200.101.18401: Flags [.], ack 13, win 8326, options [nop,nop,TS val 763106412 ecr 113773992], length 0 00:49:40.467889 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [P.], seq 13:19, ack 1, win 1040, options [nop,nop,TS val 113776831 ecr 763106412], length 6 00:49:40.562215 IP 10.22.200.102.1000 > 10.22.200.101.18401: Flags [.], ack 19, win 8326, options [nop,nop,TS val 763106695 ecr 113776831], length 0 00:49:42.148281 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [P.], seq 19:25, ack 1, win 1040, options [nop,nop,TS val 113778511 ecr 763106695], length 6 00:49:42.242122 IP 10.22.200.102.1000 > 10.22.200.101.18401: Flags [.], ack 25, win 8326, options [nop,nop,TS val 763106863 ecr 113778511], length 0 00:49:42.556244 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [F.], seq 25, ack 1, win 1040, options [nop,nop,TS val 113778912 ecr 763106863], length 0 00:49:42.556697 IP 10.22.200.102.1000 > 10.22.200.101.18401: Flags [.], ack 26, win 8326, options [nop,nop,TS val 763106894 ecr 113778912], length 0 00:49:42.556722 IP 10.22.200.102.1000 > 10.22.200.101.18401: Flags [F.], seq 1, ack 26, win 8326, options [nop,nop,TS val 763106894 ecr 113778912], length 0 00:49:42.556806 IP 10.22.200.101.18401 > 10.22.200.102.1000: Flags [.], ack 2, win 1040, options [nop,nop,TS val 113778912 ecr 763106894], length 0 tcpdump -ni em0 src or dst 10.22.200.102 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 00:52:02.358683 IP 172.16.1.1.10364 > 10.22.200.102.1000: Flags [S], seq 2289590664, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 113918712 ecr 0], length 0 00:52:02.358896 IP 10.22.200.102.1000 > 172.16.1.1.10364: Flags [S.], seq 2860805865, ack 2289590665, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2333279786 ecr 113918712], length 0 00:52:02.359010 IP 172.16.1.1.10364 > 10.22.200.102.1000: Flags [.], ack 1, win 1040, options [nop,nop,TS val 113918722 ecr 2333279786], length 0 00:52:02.359015 IP 172.16.1.1.10364 > 10.22.200.102.1000: Flags [R], seq 2289590665, win 0, length 0 00:52:04.224632 IP 172.16.1.1.10364 > 10.22.200.102.1000: Flags [P.], seq 1:7, ack 1, win 1040, options [nop,nop,TS val 113920582 ecr 2333279786], length 6 00:52:04.322995 IP 10.22.200.102.1000 > 172.16.1.1.10364: Flags [.], ack 7, win 8326, options [nop,nop,TS val 2333279983 ecr 113920582], length 0 00:52:04.323026 IP 172.16.1.1.10364 > 10.22.200.102.1000: Flags [R], seq 2289590671, win 0, length 0 00:52:05.752341 IP 172.16.1.1.10364 > 10.22.200.102.1000: Flags [P.], seq 7:13, ack 1, win 1040, options [nop,nop,TS val 113922112 ecr 2333279983], length 6 00:52:05.752595 IP 10.22.200.102.1000 > 172.16.1.1.10364: Flags [R], seq 2860805866, win 0, length 0 00:52:06.798407 IP 172.16.1.1.61952 > 10.22.200.102.1000: Flags [S], seq 3819912610, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 113923152 ecr 0], length 0 00:52:06.798588 IP 10.22.200.102.1000 > 172.16.1.1.61952: Flags [S.], seq 889829473, ack 3819912611, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 1369790257 ecr 113923152], length 0 00:52:06.798657 IP 172.16.1.1.61952 > 10.22.200.102.1000: Flags [.], ack 1, win 1040, options [nop,nop,TS val 113923152 ecr 1369790257], length 0 00:52:06.798727 IP 172.16.1.1.61952 > 10.22.200.102.1000: Flags [R], seq 3819912611, win 0, length 0 00:52:08.328904 IP 172.16.1.1.61952 > 10.22.200.102.1000: Flags [P.], seq 1:7, ack 1, win 1040, options [nop,nop,TS val 113924692 ecr 1369790257], length 6 00:52:08.422462 IP 10.22.200.102.1000 > 172.16.1.1.61952: Flags [.], ack 7, win 8326, options [nop,nop,TS val 1369790267 ecr 113924692], length 0 00:52:08.422542 IP 172.16.1.1.61952 > 10.22.200.102.1000: Flags [R], seq 3819912617, win 0, length 0 00:52:09.968562 IP 172.16.1.1.61952 > 10.22.200.102.1000: Flags [P.], seq 7:13, ack 1, win 1040, options [nop,nop,TS val 113926332 ecr 1369790267], length 6 00:52:09.968846 IP 10.22.200.102.1000 > 172.16.1.1.61952: Flags [R], seq 889829474, win 0, length 0 00:52:12.869940 IP 172.16.1.1.35530 > 10.22.200.102.1000: Flags [S], seq 197894496, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 113929232 ecr 0], length 0 00:52:12.870144 IP 10.22.200.102.1000 > 172.16.1.1.35530: Flags [S.], seq 4171403115, ack 197894497, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2442049100 ecr 113929232], length 0 00:52:12.870211 IP 172.16.1.1.35530 > 10.22.200.102.1000: Flags [.], ack 1, win 1040, options [nop,nop,TS val 113929232 ecr 2442049100], length 0 00:52:12.870331 IP 172.16.1.1.35530 > 10.22.200.102.1000: Flags [R], seq 197894497, win 0, length 0 00:52:14.144771 IP 172.16.1.1.35530 > 10.22.200.102.1000: Flags [P.], seq 1:7, ack 1, win 1040, options [nop,nop,TS val 113930508 ecr 2442049100], length 6 00:52:14.241838 IP 10.22.200.102.1000 > 172.16.1.1.35530: Flags [.], ack 7, win 8326, options [nop,nop,TS val 2442049110 ecr 113930508], length 0 00:52:14.241864 IP 172.16.1.1.35530 > 10.22.200.102.1000: Flags [R], seq 197894503, win 0, length 0 00:52:15.152672 IP 172.16.1.1.35530 > 10.22.200.102.1000: Flags [P.], seq 7:13, ack 1, win 1040, options [nop,nop,TS val 113931512 ecr 2442049110], length 6 00:52:15.153065 IP 10.22.200.102.1000 > 172.16.1.1.35530: Flags [R], seq 4171403116, win 0, length 0 It looks like the 9.2 host is sending a reset before sending every PDU. Weird. In any case, this is really easy to re-produce. Anyone have an idea as to why this started happening? I didn't try FreeBSD 10, but I suspect the problem is the same. Thanks, -Matthew From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 09:16:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 419EDD84 for ; Tue, 14 Jan 2014 09:16:38 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E0DDD1FEA for ; Tue, 14 Jan 2014 09:16:37 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 5BA1C12959B1; Tue, 14 Jan 2014 10:16:27 +0100 (CET) X-Bogosity: Unsure, tests=bogofilter, spamicity=0.455051, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 6.4558] X-CRM114-CacheID: sfid-20140114_10162_360CBF6F X-CRM114-Status: Good ( pR: 6.4558 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Jan 14 10:16:26 2014 X-DSPAM-Confidence: 0.7618 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d5006a100956703610498 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, From*Attila, 0.00438, inet, 0.00477, this+#, 0.00525, Received*online.co.hu+[195.228.243.99]), 0.00872, Received*[195.228.243.99]), 0.00872, Received*online.co.hu, 0.00872, From*Attila+Nagy, 0.00872, Received*(japan.t, 0.00872, From*Nagy+; Tue, 14 Jan 2014 10:16:25 +0100 (CET) Message-ID: <52D50065.8060907@fsn.hu> Date: Tue, 14 Jan 2014 10:16:21 +0100 From: Attila Nagy MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Showing CDP info in ifconfig? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 09:16:38 -0000 Hi, Anybody thought about how useful would be showing CDP info in ifconfig output? Something like this: # ifconfig igb2 igb2: flags=8843 metric 0 mtu 1500 options=401bb ether ac:16:2d:9a:18:ce inet6 fe80::ae16:2dff:fe9a:18ce%igb2 prefixlen 64 tentative scopeid 0x3 inet 10.0.2.2 netmask 0xffffff00 broadcast 10.0.2.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active neighbor id: DP1106-A05-11-N5K(SSI3235613KZ) neighbor ip: 172.28.2.24 neighborport-id: Ethernet109/1/47 And maybe some other info (like VLAN tags, MTU etc). From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 09:29:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B71D3C5 for ; Tue, 14 Jan 2014 09:29:26 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC4C41109 for ; Tue, 14 Jan 2014 09:29:25 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1W30JI-00011K-9f for freebsd-net@freebsd.org; Tue, 14 Jan 2014 13:29:24 +0400 Message-ID: <52D50371.8000705@smartspb.net> Date: Tue, 14 Jan 2014 13:29:21 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Showing CDP info in ifconfig? References: <52D50065.8060907@fsn.hu> In-Reply-To: <52D50065.8060907@fsn.hu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140113-1, 14.01.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 09:29:26 -0000 Only in case of additional command argument. And why proprietary CDP but not LLDP? 14.01.2014 13:16, Attila Nagy ÐŋÐļŅˆÐĩŅ‚: > Hi, > > Anybody thought about how useful would be showing CDP info in ifconfig > output? > > Something like this: > # ifconfig igb2 > igb2: flags=8843 metric 0 mtu > 1500 > options=401bb > > ether ac:16:2d:9a:18:ce > inet6 fe80::ae16:2dff:fe9a:18ce%igb2 prefixlen 64 tentative scopeid 0x3 > inet 10.0.2.2 netmask 0xffffff00 broadcast 10.0.2.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > neighbor id: DP1106-A05-11-N5K(SSI3235613KZ) > neighbor ip: 172.28.2.24 > neighborport-id: Ethernet109/1/47 > > And maybe some other info (like VLAN tags, MTU etc). > _______________________________________________ > 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, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 09:32:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EBEA48A for ; Tue, 14 Jan 2014 09:32:09 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21C4F1184 for ; Tue, 14 Jan 2014 09:32:08 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 86F1725D3892; Tue, 14 Jan 2014 09:32:06 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 8A132C22C53; Tue, 14 Jan 2014 09:32:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id CW7irhEAGJKa; Tue, 14 Jan 2014 09:32:03 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:e9aa:93d8:3e34:3fa2] (unknown [IPv6:fde9:577b:c1a9:4410:e9aa:93d8:3e34:3fa2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 836A8C22C11; Tue, 14 Jan 2014 09:32:01 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Showing CDP info in ifconfig? From: "Bjoern A. Zeeb" In-Reply-To: <52D50065.8060907@fsn.hu> Date: Tue, 14 Jan 2014 09:31:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52D50065.8060907@fsn.hu> To: Attila Nagy X-Mailer: Apple Mail (2.1827) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 09:32:09 -0000 On 14 Jan 2014, at 09:16 , Attila Nagy wrote: > Hi, >=20 > Anybody thought about how useful would be showing CDP info in ifconfig = output? No. Neither would lldp or other protocols. That=92s what a higher = level management user interface is for. I=92d be happy to finally see = someone do this in an abstracted way so it could be a cli, a Web = interface, or some xml-rpc thingy or whatever is the standard of the = day. ifconfig is not the place, especially since it would have to query a = daemon running somewhere else anyway. Otherwise we=92ll end up with = ndp, ospf, isis, bgp, ipsec, and the apache, varnish, and squid status = there as well. Just my 2cts. > Something like this: > # ifconfig igb2 > igb2: flags=3D8843 metric 0 = mtu 1500 > = options=3D401bb > ether ac:16:2d:9a:18:ce > inet6 fe80::ae16:2dff:fe9a:18ce%igb2 prefixlen 64 tentative = scopeid 0x3 > inet 10.0.2.2 netmask 0xffffff00 broadcast 10.0.2.255 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > neighbor id: DP1106-A05-11-N5K(SSI3235613KZ) > neighbor ip: 172.28.2.24 > neighborport-id: Ethernet109/1/47 >=20 > And maybe some other info (like VLAN tags, MTU etc). > _______________________________________________ > 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" =97=20 Bjoern A. Zeeb ????????? ??? ??????? ??????: '??? ??? ???? ?????? ??????? ?? ?? ??????? ??????? ??? ????? ????? ???? ?????? ?? ????? ????', ????????? ?????????, "??? ????? ?? ?????", ?.??? From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 09:36:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3AB2E565 for ; Tue, 14 Jan 2014 09:36:50 +0000 (UTC) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB9B111B8 for ; Tue, 14 Jan 2014 09:36:49 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id as1so113580iec.27 for ; Tue, 14 Jan 2014 01:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=pcTMSGZXYi7HR0M4VGlwIJ9LGMxYOPt5NSew0WM8t0s=; b=hiUYV/6bfeVNR2d0AJuB2RoUVGaFowZU5vac0dGjIfoQuK3VyIrfhpsKWRwvqNWTm2 wNPJ2QvOsobkZ5UW65FTpA4NyT+pFsoxiaV9f/rYnpOftU7AGnrKgt2nGbDwXyzZfDoy IyzJXbudnc7Z6C4xvFchBC2lQX7jxSSMLQ3JQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=pcTMSGZXYi7HR0M4VGlwIJ9LGMxYOPt5NSew0WM8t0s=; b=e+Fm9UsggLYOa21xKg3/VHkbyB1g12RrfpI9o7S3IBHKarzsbW41Upd5rgb30CKKXF 849mzKJJB0Osxvui8x8IYqBnuuDt1eu6WnCMOgOk/SiEB/WnLAVAh/mMsh81N3AN1k9d mnLXb+68PIHuhYwAiRtG6RrayqPg5Rm/ZX37pZbM41des8vM1QafpzxVVKJ6oSWPuvd2 V9El/rmEinjNm7cR+IH2PGPuA8YBTLd4mwSiZRrcrIwWcbdT2rSf0N1AWxeO3mHRDSEi vdrqNHV0qboVQVVcw87bMc5wOIGKsGsEmhOxYs3pObecb2vepwHi6THy4r4F03p9tvPj HZ1A== X-Gm-Message-State: ALoCoQlIuFv26PoNvzessXBtA5xWDOxxc6UCpQ7xWMggONsByxqpKq5H2fR/VylNXQ2N3bX+jC1K X-Received: by 10.43.182.74 with SMTP id pl10mr1258026icc.70.1389692209402; Tue, 14 Jan 2014 01:36:49 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id qk7sm23128599igc.8.2014.01.14.01.36.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 Jan 2014 01:36:47 -0800 (PST) References: <52D50065.8060907@fsn.hu> Mime-Version: 1.0 (1.0) In-Reply-To: <52D50065.8060907@fsn.hu> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9EB9D4BA-F64F-4628-8C8C-4BD56B404B32; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <22003980-2D17-4601-A884-0FB903A74F24@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Showing CDP info in ifconfig? Date: Tue, 14 Jan 2014 04:36:44 -0500 To: Attila Nagy X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 09:36:50 -0000 --Apple-Mail-9EB9D4BA-F64F-4628-8C8C-4BD56B404B32 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That would be real nice, if implemented under (-v) for verbose output. While= at it how about some of the others too . . . EIGRP explicitly. But there ar= e a lot of variables in this right along with all the supported "show ____ n= eighbor" syntax as well showing the "hello" time. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 14, 2014, at 4:16, Attila Nagy wrote: >=20 > Hi, >=20 > Anybody thought about how useful would be showing CDP info in ifconfig out= put? >=20 > Something like this: > # ifconfig igb2 > igb2: flags=3D8843 metric 0 mtu 15= 00 > options=3D401bb > ether ac:16:2d:9a:18:ce > inet6 fe80::ae16:2dff:fe9a:18ce%igb2 prefixlen 64 tentative scopeid= 0x3 > inet 10.0.2.2 netmask 0xffffff00 broadcast 10.0.2.255 > nd6 options=3D29 > media: Ethernet autoselect (1000baseT ) > status: active > neighbor id: DP1106-A05-11-N5K(SSI3235613KZ) > neighbor ip: 172.28.2.24 > neighborport-id: Ethernet109/1/47 >=20 > And maybe some other info (like VLAN tags, MTU etc). > _______________________________________________ > 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" --Apple-Mail-9EB9D4BA-F64F-4628-8C8C-4BD56B404B32 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDExNDA5MzY0NlowIwYJKoZIhvcN AQkEMRYEFK6UkxC209kVcGr7aVbpNy8U/BdnMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEATN5UURKhwAJk5zNqzIsK JjrNQaGanFoJSdaqAMYReeHegDKxIrZ/vxp2gtESPeQxHs2NCxODgTsKQaRrH5+Cgh+TcOcVKFKt V1LB+WKewzNmy6A74ohEaPB8BZo4cXknixQrUU3F2akz0fLZLCaXp1+BjHXtbSJh+tff7qh++hZ5 JsR5Nnn+iY3RICE6cRzQqaCtRDgA4hYlBIUn86KnLo2zlgifvZjXLB/pXSjmF7e+u3TlQGq/IV74 OZavIx8/JidKDSiDZIgx7stgZhD7h5PpadA82xmn/Y/LfS1vdZojuTwsb2Cg1hf5964nCl8BO1Bp IPMrh0SvJHZi8a6TkgAAAAAAAA== --Apple-Mail-9EB9D4BA-F64F-4628-8C8C-4BD56B404B32-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 09:53:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91418CCB for ; Tue, 14 Jan 2014 09:53:06 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3C429132F for ; Tue, 14 Jan 2014 09:53:05 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 5ADA21295D27; Tue, 14 Jan 2014 10:53:03 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.003660, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 15.0867] X-CRM114-CacheID: sfid-20140114_10530_9F24C211 X-CRM114-Status: Good ( pR: 15.0867 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Jan 14 10:53:03 2014 X-DSPAM-Confidence: 0.9944 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d508ff275659298181027 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+On, 0.00049, wrote+>, 0.00189, wrote+>, 0.00189, >+>>, 0.00255, >>+>>, 0.00362, Otherwise, 0.00375, From*Attila, 0.00438, daemon, 0.00477, >>+Hi, 0.00477, wrote, 0.00520, wrote, 0.00520, update+the, 0.00525, 09+16, 0.00583, References*fsn.hu>, 0.00583, squid, 0.00655, >+I'm, 0.00655, at+09, 0.00748, Hi+>>, 0.00748, Received*online.co.hu+[195.228.243.99]), 0.00872, Received*[195.228.243.99]), 0.00872, Received*online.co.hu, 0.00872, From*Attila+Nagy, 0.00872, parse, 0.00872, Received*(japan.t, 0.00872, From*Nagy+ Date: Tue, 14 Jan 2014 10:53:01 +0100 From: Attila Nagy MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: Showing CDP info in ifconfig? References: <52D50065.8060907@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 09:53:06 -0000 On 01/14/14 10:31, Bjoern A. Zeeb wrote: > On 14 Jan 2014, at 09:16 , Attila Nagy wrote: > >> Hi, >> >> Anybody thought about how useful would be showing CDP info in ifconfig output? > No. Neither would lldp or other protocols. That’s what a higher level management user interface is for. I’d be happy to finally see someone do this in an abstracted way so it could be a cli, a Web interface, or some xml-rpc thingy or whatever is the standard of the day. > ifconfig is not the place, especially since it would have to query a daemon running somewhere else anyway. Otherwise we’ll end up with ndp, ospf, isis, bgp, ipsec, and the apache, varnish, and squid status there as well. > I'm not sure how this could be done efficiently, without any ill effects, but yes, it's likely that doing it in userspace is a safer way. With CDP you have to capture just one packet, parse it and update the values, with some of the examples, this is not the case. :) But I got the point. From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 10:06:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD67D336 for ; Tue, 14 Jan 2014 10:06:15 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 464871445 for ; Tue, 14 Jan 2014 10:06:14 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0EA6CWQ024503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jan 2014 14:06:12 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0EA6Cec024502; Tue, 14 Jan 2014 14:06:12 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Jan 2014 14:06:12 +0400 From: Gleb Smirnoff To: Matthew Grooms Subject: Re: TCP socket handling lo[X], buggy in 9.x? Message-ID: <20140114100612.GR8472@FreeBSD.org> References: <52D4E633.1060000@shrew.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D4E633.1060000@shrew.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 10:06:15 -0000 Matthew, On Tue, Jan 14, 2014 at 01:24:35AM -0600, Matthew Grooms wrote: M> It looks like the 9.2 host is sending a reset before sending every PDU. M> Weird. In any case, this is really easy to re-produce. Anyone have an M> idea as to why this started happening? I didn't try FreeBSD 10, but I M> suspect the problem is the same. I failed to reproduce that on couple of FreeBSD 11 boxes. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 10:15:50 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1751B8A7 for ; Tue, 14 Jan 2014 10:15:50 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C55101531 for ; Tue, 14 Jan 2014 10:15:49 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1W312B-0006EL-NT for freebsd-net@freebsd.org; Tue, 14 Jan 2014 14:15:47 +0400 Message-ID: <52D50E53.7000405@smartspb.net> Date: Tue, 14 Jan 2014 14:15:47 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Showing CDP info in ifconfig? References: <52D50065.8060907@fsn.hu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140114-0, 14.01.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 10:15:50 -0000 May be implement that functionality in ndp utility, as far it named after Neighbor Discovery Protocol? 14.01.2014 13:31, Bjoern A. Zeeb ÐŋÐļŅˆÐĩŅ‚: > No. Neither would lldp or other protocols. That’s what a higher level > management user interface is for. I’d be happy to finally see someone > do this in an abstracted way so it could be a cli, a Web interface, or > some xml-rpc thingy or whatever is the standard of the day. ifconfig > is not the place, especially since it would have to query a daemon > running somewhere else anyway. Otherwise we’ll end up with ndp, ospf, > isis, bgp, ipsec, and the apache, varnish, and squid status there as > well. Just my 2cts. -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 10:28:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01C47A9A for ; Tue, 14 Jan 2014 10:28:38 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B2DB4160B for ; Tue, 14 Jan 2014 10:28:37 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1W31Ea-0007gG-5q for freebsd-net@freebsd.org; Tue, 14 Jan 2014 14:28:36 +0400 Message-ID: <52D51153.6020607@smartspb.net> Date: Tue, 14 Jan 2014 14:28:35 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Set UDP packet size in ng_netflow/ng_ksocket? X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 140114-0, 14.01.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 10:28:38 -0000 Are there any way to set UDP packet size generated from ng_netflow with ng_ksocket? I'm sending netflow UDP packets throught tunnel with MTU 1476 and it's disappointing to see fragmented packets on it as far as it could be a problem for some firewalls, because ng_ksocket always generate 1500-bytes packets. Or I'm wrong? -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 10:33:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F465D10 for ; Tue, 14 Jan 2014 10:33:26 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DD261168D for ; Tue, 14 Jan 2014 10:33:25 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0EAXN5n024671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jan 2014 14:33:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0EAXNgd024670; Tue, 14 Jan 2014 14:33:23 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Jan 2014 14:33:23 +0400 From: Gleb Smirnoff To: Dennis Yusupoff Subject: Re: Set UDP packet size in ng_netflow/ng_ksocket? Message-ID: <20140114103323.GS8472@FreeBSD.org> References: <52D51153.6020607@smartspb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D51153.6020607@smartspb.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 10:33:26 -0000 On Tue, Jan 14, 2014 at 02:28:35PM +0400, Dennis Yusupoff wrote: D> Are there any way to set UDP packet size generated from ng_netflow with D> ng_ksocket? D> I'm sending netflow UDP packets throught tunnel with MTU 1476 and it's D> disappointing to see fragmented packets on it as far as it could be a D> problem for some firewalls, because ng_ksocket always generate D> 1500-bytes packets. Or I'm wrong? The ng_ksocket is irrelevant here. This is ng_netflow, who decides on datagram size. AFAIR, the size of Netflow datagram is dictated by the Cisco Netflow, and full sized datagram fits into 1500 MTU. Probably it was designed to be used on 1500 MTU sized networks. You can hack sources and redefine NETFLOW_V1_MAX_RECORDS or NETFLOW_V5_MAX_RECORDS so that datagram would fit your link. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 10:38:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F771DDD for ; Tue, 14 Jan 2014 10:38:09 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C03516AA for ; Tue, 14 Jan 2014 10:38:08 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 4814912B0159; Tue, 14 Jan 2014 11:38:06 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.009513, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 6.3772] X-CRM114-CacheID: sfid-20140114_11380_EBAE0F60 X-CRM114-Status: Good ( pR: 6.3772 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Jan 14 11:38:06 2014 X-DSPAM-Confidence: 0.7603 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d5138e491131243918760 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, ports, 0.00193, From*Attila, 0.00438, src, 0.00559, Received*online.co.hu+[195.228.243.99]), 0.00872, Received*[195.228.243.99]), 0.00872, Received*online.co.hu, 0.00872, From*Attila+Nagy, 0.00872, Received*(japan.t, 0.00872, From*Nagy+; Tue, 14 Jan 2014 11:38:04 +0100 (CET) Message-ID: <52D5138B.8050100@fsn.hu> Date: Tue, 14 Jan 2014 11:38:03 +0100 From: Attila Nagy MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: ECMP hash keys? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 10:38:09 -0000 Hi, Does equal cost multipath take only the destination address into consideration when choosing the route? (I've spent only about two minutes reading radix_mpath.h, but I've got this impression) What would be needed to use src and dst addresses and ports -if appropriate? Thanks, From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 10:39:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 531C0E83 for ; Tue, 14 Jan 2014 10:39:15 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 16F8416BB for ; Tue, 14 Jan 2014 10:39:15 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1W2xZ9-000BUK-GX; Tue, 14 Jan 2014 10:33:35 +0400 Message-ID: <52D5130B.5040009@FreeBSD.org> Date: Tue, 14 Jan 2014 14:35:55 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Dennis Yusupoff , freebsd-net@freebsd.org Subject: Re: Set UDP packet size in ng_netflow/ng_ksocket? References: <52D51153.6020607@smartspb.net> In-Reply-To: <52D51153.6020607@smartspb.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 10:39:15 -0000 On 14.01.2014 14:28, Dennis Yusupoff wrote: > Are there any way to set UDP packet size generated from ng_netflow with > ng_ksocket? > I'm sending netflow UDP packets throught tunnel with MTU 1476 and it's > disappointing to see fragmented packets on it as far as it could be a > problem for some firewalls, because ng_ksocket always generate > 1500-bytes packets. Or I'm wrong? Actually ng_netflow generates constant-sized v5 packets (NETFLOW_V5_MAX_RECORDS records in each packet). however, you change mtu for v9 export via "setmtu" message. > From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 10:49:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 603E2169 for ; Tue, 14 Jan 2014 10:49:29 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 26C5A1767 for ; Tue, 14 Jan 2014 10:49:28 +0000 (UTC) Received: from [10.16.240.11] (unknown [212.9.98.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.lhr1.as41113.net (Postfix) with ESMTPSA id 3f3T1q0YRYz7vXM for ; Tue, 14 Jan 2014 10:49:18 +0000 (UTC) Message-ID: <52D5162D.5020609@rewt.org.uk> Date: Tue, 14 Jan 2014 10:49:17 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Showing CDP info in ifconfig? References: <52D50065.8060907@fsn.hu> <52D50E53.7000405@smartspb.net> In-Reply-To: <52D50E53.7000405@smartspb.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 10:49:29 -0000 On 14/01/2014 10:15, Dennis Yusupoff wrote: > May be implement that functionality in ndp utility, as far it named > after Neighbor Discovery Protocol? > > 14.01.2014 13:31, Bjoern A. Zeeb ÐŋÐļŅˆÐĩŅ‚: >> No. Neither would lldp or other protocols. That’s what a higher level >> management user interface is for. I’d be happy to finally see someone >> do this in an abstracted way so it could be a cli, a Web interface, or >> some xml-rpc thingy or whatever is the standard of the day. ifconfig >> is not the place, especially since it would have to query a daemon >> running somewhere else anyway. Otherwise we’ll end up with ndp, ospf, >> isis, bgp, ipsec, and the apache, varnish, and squid status there as >> well. Just my 2cts. > That is an even worse place to implement it, since NDP is essentially IPv6 ARP. This should probably be in userland, GPL utilities already exist but there are/were some performance hits (not sure if the BPF writers patches fixed anything, or if they got merged in the end). From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 11:45:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B93A1DE2 for ; Tue, 14 Jan 2014 11:45:38 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73DEF1CD1 for ; Tue, 14 Jan 2014 11:45:38 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1W32R6-000Gt6-3l for freebsd-net@freebsd.org; Tue, 14 Jan 2014 15:45:36 +0400 Message-ID: <52D5235F.2010201@smartspb.net> Date: Tue, 14 Jan 2014 15:45:35 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Set UDP packet size in ng_netflow/ng_ksocket? References: <52D51153.6020607@smartspb.net> <20140114103323.GS8472@FreeBSD.org> In-Reply-To: <20140114103323.GS8472@FreeBSD.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140114-0, 14.01.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 11:45:38 -0000 I didn't find any open Netfow v5 specification, so why wouldn't add ability to set MTU size for v5 also as it already has done for v9? Anyway most people exporting netflow to open-source utuilties, such as flow-tools, that, AFAIK, doesn't care about exact datagram size. 14.01.2014 14:33, Gleb Smirnoff ÐŋÐļŅˆÐĩŅ‚: > The ng_ksocket is irrelevant here. This is ng_netflow, who decides on > datagram size. AFAIR, the size of Netflow datagram is dictated by the Cisco > Netflow, and full sized datagram fits into 1500 MTU. Probably it was designed > to be used on 1500 MTU sized networks. > > You can hack sources and redefine NETFLOW_V1_MAX_RECORDS or NETFLOW_V5_MAX_RECORDS > so that datagram would fit your link. > -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 11:57:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DC181A5 for ; Tue, 14 Jan 2014 11:57:33 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 885B11DB4 for ; Tue, 14 Jan 2014 11:57:31 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0EBvT2t025480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Jan 2014 15:57:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0EBvT2F025479; Tue, 14 Jan 2014 15:57:29 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 14 Jan 2014 15:57:29 +0400 From: Gleb Smirnoff To: Dennis Yusupoff Subject: Re: Set UDP packet size in ng_netflow/ng_ksocket? Message-ID: <20140114115729.GU8472@FreeBSD.org> References: <52D51153.6020607@smartspb.net> <20140114103323.GS8472@FreeBSD.org> <52D5235F.2010201@smartspb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D5235F.2010201@smartspb.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 11:57:33 -0000 On Tue, Jan 14, 2014 at 03:45:35PM +0400, Dennis Yusupoff wrote: D> I didn't find any open Netfow v5 specification, so why wouldn't add D> ability to set MTU size for v5 also as it already has done for v9? D> Anyway most people exporting netflow to open-source utuilties, such as D> flow-tools, that, AFAIK, doesn't care about exact datagram size. Patches are welcome. :) -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 13:48:51 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA0DAD9C for ; Tue, 14 Jan 2014 13:48:50 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 830771656 for ; Tue, 14 Jan 2014 13:48:50 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id e4so2530353wiv.0 for ; Tue, 14 Jan 2014 05:48:48 -0800 (PST) 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=CsvkBLsWx7pxaw8EVJVouiQM0FKRmO2oi7DuqvfL+Ak=; b=I3uq1LVtZimmw0zVs+0MKcb4FCR1XCaa6vwQnnXytckY+W678pM4vP2yfOR2UemSTP byxhkCoFH3rcAJbA1zBnN9Tt4hGwzUUAZUUn2nA5EzcK4jdgdLcWmPPkbt1hmHh0E1F9 ovnLvznGsw9KizyigxlSwWobmQVEdN0vf9eAMKzSgYdBQEJnhwvTNDbv5mL0Nzrmlm8m Im++MuQQP1kIc6farmR/YuWqwe2GGxCtAt+ysdbS8f/70xc6cshuqgOwg/qGk4IHYemf Ibz3IVwndztaxcGFOQEe9FPPgaHKUK7dPBHe0tNavpWt5VtFFwSXvEiG+aorafZSt/sX 75rA== MIME-Version: 1.0 X-Received: by 10.180.86.9 with SMTP id l9mr3081353wiz.20.1389707328486; Tue, 14 Jan 2014 05:48:48 -0800 (PST) Received: by 10.216.4.6 with HTTP; Tue, 14 Jan 2014 05:48:48 -0800 (PST) Date: Tue, 14 Jan 2014 13:48:48 +0000 Message-ID: Subject: FreeBSD network optimization project From: Vitalii Duk To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 13:48:51 -0000 Hello, colleagues! I'm working in ISP and use FreeBSD on BRAS'es. I have noticed that there are few problems in FreeBSD, which do not allow to use it on high speeds (>10G, >2Mpps). So I have a suggestion to create a list of improvements that needed to be done in FreeBSD collectively, to improve network perfomance and be on the same or higher level as Linux or Vyatta. After we create a todo list, it's possible to organize a donation for those developers who can do that job. I'm ready to donate money for this project, and I think that I'm not only one interested in it. I like FreeBSD and I don't want to migrate to another OS. My list of improvements in very general words (needed to be detailed): 1. Improve network subsystem and kernel to provide >10G forwarding. 2. Improve dummynet to provide massive shaping service and to be not single threaded (or maybe write something radically new). 3. Replace/rewrite libalias to support massive NAT service and remove current problems and limitations (non-SMP, offloading problems, etc). 4. Better work of tcpdump on >10G speeds (BPF improvements). Thank you in advance. Waiting for some other suggestions and support from specialists. Best regars, dv. From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 14:26:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DC3540B for ; Tue, 14 Jan 2014 14:26:39 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C5CA61A4B for ; Tue, 14 Jan 2014 14:26:38 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id n7so354065lam.15 for ; Tue, 14 Jan 2014 06:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nV1Mx1Z1X+ZKEIqDtYZ8fClTYhOJV9GUt3yW3X57uss=; b=CNM89Y+wzn23E6X/wMpqUF1Kg3IHPedzaDQBWqfD3JW1gU1Uqk4MkgTwFxJIfHuy3y dEBVyHppC9tm51dPPFp9qy7eqNRhDs1u7ifdIRPgzHT91cPsdo50dQX7TM7WtpVa3fwW CEZiKDVxqijbJVRHEK0/hcznEi+DRAz/nrV4U4IlgXSeuxZtUL2z2cEjFcV553kdluJG 9V9lLa0T/Oa7qMb1AaM0LcKO45cisnfTVQYaJ8JjZhVL63MWgXiYCjjBEpBbX5Gvse9U EhvM8yFgZDzisGa8PVzXiCX1cNhvFiiF8DRaaFKeZxYuFaP1eoNDwewFSW14ZJDxm31B EF2Q== MIME-Version: 1.0 X-Received: by 10.112.171.41 with SMTP id ar9mr621548lbc.74.1389709596717; Tue, 14 Jan 2014 06:26:36 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Tue, 14 Jan 2014 06:26:36 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 06:26:36 -0800 X-Google-Sender-Auth: vsC5d0gEXtMkIOwmC-ldHwUBJtM Message-ID: Subject: Re: FreeBSD network optimization project From: Luigi Rizzo To: Vitalii Duk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 14:26:39 -0000 On Tue, Jan 14, 2014 at 5:48 AM, Vitalii Duk wrote: > Hello, colleagues! > > I'm working in ISP and use FreeBSD on BRAS'es. > I have noticed that there are few problems in FreeBSD, which do not allow > to use it on high speeds (>10G, >2Mpps). > for this type of applications you really want to look at netmap http://info.iet.unipi.it/~luigi/netmap/ which already does a lot of what you need. cheers luigi > So I have a suggestion to create a list of improvements that needed to be > done in FreeBSD collectively, to improve network perfomance and be on the > same or higher level as Linux or Vyatta. > After we create a todo list, it's possible to organize a donation for those > developers who can do that job. > I'm ready to donate money for this project, and I think that I'm not only > one interested in it. I like FreeBSD and I don't want to migrate to another > OS. > > My list of improvements in very general words (needed to be detailed): > 1. Improve network subsystem and kernel to provide >10G forwarding. > 2. Improve dummynet to provide massive shaping service and to be not single > threaded (or maybe write something radically new). > 3. Replace/rewrite libalias to support massive NAT service and remove > current problems and limitations (non-SMP, offloading problems, etc). > 4. Better work of tcpdump on >10G speeds (BPF improvements). > > Thank you in advance. Waiting for some other suggestions and support from > specialists. > > Best regars, dv. > _______________________________________________ > 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" > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 16:52:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44A1BBD8; Tue, 14 Jan 2014 16:52:15 +0000 (UTC) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E21C61935; Tue, 14 Jan 2014 16:52:14 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id jx11so6101553veb.34 for ; Tue, 14 Jan 2014 08:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=KBs7bWaAqUWOZlmuoT21Z3+faaNVMcLFtBtZ78uQGIM=; b=oTFKarD/G37bnQoq82O9K6B0ao+sjWTLnayvlSOChqKyTgNKxLdZgAmBRvrq0mKnvV qLbR4lwU6X6+pRNG1mUcvddMINxbWaWnHUbWHnqctHp7LZ5kAKFIFvlTVkloaGjRMsqx /jzS1P5BpqXcsgJHgWmczHgd7k0geD35P53Gm5YEMT0ismB6fo2qC2nP7DQXFs6W9yCd nNrueeDwjY+T9rwr4XthQz0+itkvhCTt4hr2BgWfw89rqJgLG8WGamd32KbLe4cwUX+y eNlBeXLaXaJvcM/EItzY2NLjWn2yODAiCCdkLPfB4H/MAkE79y852RjDVaDUCeqVHe54 kQ3Q== X-Received: by 10.58.50.71 with SMTP id a7mr1454414veo.32.1389718334010; Tue, 14 Jan 2014 08:52:14 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.171.1 with HTTP; Tue, 14 Jan 2014 08:51:53 -0800 (PST) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 14 Jan 2014 17:51:53 +0100 X-Google-Sender-Auth: 3yFAflFsZkWGLAU5MqjkvrVhjnk Message-ID: Subject: Regression on 10-RC5 with a multicast routing daemon To: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 16:52:15 -0000 Hi all, I'm trying to port a PIM sparse-mode daemon ( https://github.com/troglobit/pimd/) and I've meet a problem: This daemon compile and run fine on FreeBSD 9.2 but on 10-RC5 this daemon can't understand received multicast packets (received from other PIM neighbors) and display this kind of error message in debug mode "warning - Received packet from 10.0.12.2 shorter (28 bytes) than hdr+data length (20+28)". How to troubleshoot this problem ? My current work of this port can be tested with theses commands: cd /usr/ports fetch -o ports.pimd.shar " https://sourceforge.net/p/bsdrp/code/HEAD/tree/trunk/BSDRP/patches/ports.pimd.shar?format=raw " sh ./ports.pimd.shar cd net/pimd make install From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 17:19:07 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9FCF31C for ; Tue, 14 Jan 2014 17:19:06 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7461B1AEE for ; Tue, 14 Jan 2014 17:19:06 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id m15so672067wgh.26 for ; Tue, 14 Jan 2014 09:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LO4I04emthlo2WWmYa52o7Zxi3qU5f0gWm1MECYkQOo=; b=z52bOQZvNDIMJsWoXd18xfMjGJT1odI6OURBDfLkPcKfrascAdGzS3YxZ/mu/Y1JNP AsuknNqacvv0V3NvkmkPQAseXcGgNdCSFoWNUdEUeVqE8RRa+xNe7sClXid8GUBw1lmj xsTGWi8gbXYh+/WgP1Ey+Uc6uYeXoVXHKW8CgEMfDPSQGR5N05uJbML2N/UVs1vWaZef LpZFCLqC3EAl+2cLECJsKh4L+gKzh4N1W+LNhbK0To4KTOC24BdM0pU2nSigIrayoPTT 3IsHeMS1peqWe2AiKyeMHlcDYLmzu7CP07pAKrqSnjUD81ueGUKO7nOA8JDxJRtZNzhV bc9w== MIME-Version: 1.0 X-Received: by 10.195.13.234 with SMTP id fb10mr28651503wjd.50.1389719944725; Tue, 14 Jan 2014 09:19:04 -0800 (PST) Received: by 10.216.4.6 with HTTP; Tue, 14 Jan 2014 09:19:04 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 17:19:04 +0000 Message-ID: Subject: Re: FreeBSD network optimization project From: Vitalii Duk To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 17:19:07 -0000 Luigi, your project is really interesting, you've done a great job! I will try to test ipfw and dummynet with netmap in my netork. But there is still a problem with NAT and libalias. I havent tried new SMP-friendly pf NAT, maybe it will give a good perfomance. But it will be also great to have something working with ipfw. I think in my previous list I forget to note about two more problems: 1. Not full support of LACP in FreeBSD (for example it's not possible to set priority, hash algorithm and mode(active/passive)). 2. No support of *RFC 3069 (IP unnumbered/SuperVLAN).* 2014/1/14 Luigi Rizzo > > > > On Tue, Jan 14, 2014 at 6:26 AM, Luigi Rizzo wrote: > >> On Tue, Jan 14, 2014 at 5:48 AM, Vitalii Duk wrote: >> >>> Hello, colleagues! >>> >>> I'm working in ISP and use FreeBSD on BRAS'es. >>> I have noticed that there are few problems in FreeBSD, which do not allow >>> to use it on high speeds (>10G, >2Mpps). >>> >> >> for this type of applications you really want to look at netmap >> >> http://info.iet.unipi.it/~luigi/netmap/ >> >> which already does a lot of what you need. >> > > and if you feel like funding some specific work in this area > you can contact me off list > > cheers > luigi > >> >> cheers >> luigi >> >>> So I have a suggestion to create a list of improvements that needed to be >>> done in FreeBSD collectively, to improve network perfomance and be on the >>> same or higher level as Linux or Vyatta. >>> After we create a todo list, it's possible to organize a donation for >>> those >>> developers who can do that job. >>> I'm ready to donate money for this project, and I think that I'm not only >>> one interested in it. I like FreeBSD and I don't want to migrate to >>> another >>> OS. >>> >>> My list of improvements in very general words (needed to be detailed): >>> 1. Improve network subsystem and kernel to provide >10G forwarding. >>> 2. Improve dummynet to provide massive shaping service and to be not >>> single >>> threaded (or maybe write something radically new). >>> 3. Replace/rewrite libalias to support massive NAT service and remove >>> current problems and limitations (non-SMP, offloading problems, etc). >>> 4. Better work of tcpdump on >10G speeds (BPF improvements). >>> >>> Thank you in advance. Waiting for some other suggestions and support from >>> specialists. >>> >>> Best regars, dv. >>> _______________________________________________ >>> 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" >>> >> >> >> >> -- >> -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------- >> > > > > -- > -----------------------------------------+------------------------------- > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -----------------------------------------+------------------------------- > From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 18:11:53 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADEC96A9 for ; Tue, 14 Jan 2014 18:11:53 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E0281099 for ; Tue, 14 Jan 2014 18:11:53 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id hz1so52515pad.36 for ; Tue, 14 Jan 2014 10:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3Dds7S6AEOpISYGy86DIh4TG27+rarEowOZqwg4Wsos=; b=K/mPUWQ6Cf339EDWx1Nx8juOcbP+UxjFdtolS2s3O2bwhWr4QC4EYLXBsAyJpToZ7G MHRfknxxiWmSb/F68fK25RdxguEY3Q1fwRom3eYtNi7dhyZdQEjXzw/x6peLJRdLykvq HJWZmfNr4781XgMcwQ/LzGuqNnotrZgV+nTcyxvDaubE98eiV+Sheg3ubqWftZztbxWn wbHpZPZ/3RZcimEon8R6zIyPpOm58+7ssAkK9E7j3NUpoW1CH2O/qfkCayczASgEEcqj 50hbtaNZUzuEY7ZeXFjm+XBKoOZWArCyKNTrG7ffWRAAhkrCpUiNKaoc2Q3oOm6CN8pY zirQ== MIME-Version: 1.0 X-Received: by 10.68.93.165 with SMTP id cv5mr3387503pbb.98.1389723113119; Tue, 14 Jan 2014 10:11:53 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.70.46.42 with HTTP; Tue, 14 Jan 2014 10:11:53 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 19:11:53 +0100 X-Google-Sender-Auth: 1zKYelT-2xHl0eSXKVfUxiKwaSk Message-ID: Subject: Re: FreeBSD network optimization project From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Vitalii Duk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 18:11:53 -0000 On Tue, Jan 14, 2014 at 6:19 PM, Vitalii Duk wrote: > Luigi, your project is really interesting, you've done a great job! > I will try to test ipfw and dummynet with netmap in my netork. > But there is still a problem with NAT and libalias. I havent tried new > SMP-friendly pf NAT, maybe it will give a good perfomance. But it will be > also great to have something working with ipfw. > > I think in my previous list I forget to note about two more problems: > 1. Not full support of LACP in FreeBSD (for example it's not possible to > set priority, hash algorithm and mode(active/passive)). > This is one of the project that you can consider implementing by donating to a developer. > 2. No support of *RFC 3069 (IP unnumbered/SuperVLAN).* > SuperVLAN can be achieved as detailed here https://redmine.pfsense.org/issues/1530 > > 2014/1/14 Luigi Rizzo > > > > > > > > > On Tue, Jan 14, 2014 at 6:26 AM, Luigi Rizzo wrote: > > > >> On Tue, Jan 14, 2014 at 5:48 AM, Vitalii Duk >wrote: > >> > >>> Hello, colleagues! > >>> > >>> I'm working in ISP and use FreeBSD on BRAS'es. > >>> I have noticed that there are few problems in FreeBSD, which do not > allow > >>> to use it on high speeds (>10G, >2Mpps). > >>> > >> > >> for this type of applications you really want to look at netmap > >> > >> http://info.iet.unipi.it/~luigi/netmap/ > >> > >> which already does a lot of what you need. > >> > > > > and if you feel like funding some specific work in this area > > you can contact me off list > > > > cheers > > luigi > > > >> > >> cheers > >> luigi > >> > >>> So I have a suggestion to create a list of improvements that needed to > be > >>> done in FreeBSD collectively, to improve network perfomance and be on > the > >>> same or higher level as Linux or Vyatta. > >>> After we create a todo list, it's possible to organize a donation for > >>> those > >>> developers who can do that job. > >>> I'm ready to donate money for this project, and I think that I'm not > only > >>> one interested in it. I like FreeBSD and I don't want to migrate to > >>> another > >>> OS. > >>> > >>> My list of improvements in very general words (needed to be detailed): > >>> 1. Improve network subsystem and kernel to provide >10G forwarding. > >>> 2. Improve dummynet to provide massive shaping service and to be not > >>> single > >>> threaded (or maybe write something radically new). > >>> 3. Replace/rewrite libalias to support massive NAT service and remove > >>> current problems and limitations (non-SMP, offloading problems, etc). > >>> 4. Better work of tcpdump on >10G speeds (BPF improvements). > >>> > >>> Thank you in advance. Waiting for some other suggestions and support > from > >>> specialists. > >>> > >>> Best regars, dv. > >>> _______________________________________________ > >>> 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" > >>> > >> > >> > >> > >> -- > >> > -----------------------------------------+------------------------------- > >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. > dell'Informazione > >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >> TEL +39-050-2211611 . via Diotisalvi 2 > >> Mobile +39-338-6809875 . 56122 PISA (Italy) > >> > -----------------------------------------+------------------------------- > >> > > > > > > > > -- > > -----------------------------------------+------------------------------- > > Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > > TEL +39-050-2211611 . via Diotisalvi 2 > > Mobile +39-338-6809875 . 56122 PISA (Italy) > > -----------------------------------------+------------------------------- > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Ermal From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 19:15:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7F595B8 for ; Tue, 14 Jan 2014 19:15:36 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 51E0815FC for ; Tue, 14 Jan 2014 19:15:36 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id c6so643273lan.24 for ; Tue, 14 Jan 2014 11:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7KQQs2Q7y7YRrMDtVGZSNhV5LmRePvla1YpRfizvLd8=; b=ZwAepN7LTU/Agc/jzYlgNZUFBGTHsGQBAlenWcTQOoiB5rSz8x028WbBWQfzXzgWNG ab7jKMnk0NZPMO7YTxaOXfqaPRGALEfzteu1AzkLBjQrO+B06PydiVliWBNa3FhmShzU nTZkCOQkePQD4/un9S+q/Q6/NF/mlp/hOLsxKUMiztp9u935LKcpQn05/pOum8sWJtCH 4I/+vQYs/WMBm0Ms1wZ6jb6BpOcRWKFjbhcFhPGlzMbgyXW/os6dNbqDavif2lI3JUXN +BrOufLEbu+L7Bd/4OFYl+cHfHK5nqrguXvI/z9Y8dBTkhgR+XsBRUc20z/XRadn/fcm aL6Q== MIME-Version: 1.0 X-Received: by 10.152.120.7 with SMTP id ky7mr278337lab.83.1389726934341; Tue, 14 Jan 2014 11:15:34 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.114.242.33 with HTTP; Tue, 14 Jan 2014 11:15:34 -0800 (PST) In-Reply-To: <52D5138B.8050100@fsn.hu> References: <52D5138B.8050100@fsn.hu> Date: Tue, 14 Jan 2014 19:15:34 +0000 X-Google-Sender-Auth: zHvFZ89LZoWVX4n5jx7C88WHlFM Message-ID: Subject: Re: ECMP hash keys? From: Nikolay Denev To: Attila Nagy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 19:15:36 -0000 Hi, Currently it's implemented using Modulo-N Hash (RFC2991), see radix_mpath.c:rtalloc_mpath_fib() And as hash the xor of source and destination IP is supplied, look for rtalloc_mpath_fib() in ip_output.c : ... #ifdef RADIX_MPATH rtalloc_mpath_fib(ro, ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); #else ... I've tried to hack this to use m_pkthdr.flowid if it exists, but in my case my network cards were not setting this (vr(4) on soekris) so I did not saw any change. Maybe my idea was completely wrong, but the XOR of src and dst IP is 4 bytes, and this is the size of the flowid as well. (haven't tried with FLOWTABLE enabled though). --Nikolay On Tue, Jan 14, 2014 at 10:38 AM, Attila Nagy wrote: > Hi, > > Does equal cost multipath take only the destination address into > consideration when choosing the route? (I've spent only about two minutes > reading radix_mpath.h, but I've got this impression) > > What would be needed to use src and dst addresses and ports -if appropriate? > > 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 Tue Jan 14 19:21:21 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71C87BF3 for ; Tue, 14 Jan 2014 19:21:21 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C7A0169B for ; Tue, 14 Jan 2014 19:21:20 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 4CD5E12B4CBB; Tue, 14 Jan 2014 20:21:18 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 21.5670] X-CRM114-CacheID: sfid-20140114_20211_720175A7 X-CRM114-Status: Good ( pR: 21.5670 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Tue Jan 14 20:21:18 2014 X-DSPAM-Confidence: 0.9972 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d58e2e986831614482305 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+On, 0.00049, the+>, 0.00074, >+Hi, 0.00110, wrote+>>, 0.00115, wrote+>, 0.00189, ports, 0.00193, Hi+>, 0.00195, On+Tue, 0.00195, bytes, 0.00251, I+>, 0.00251, Url*pr, 0.00263, Url*org/cgi/query, 0.00277, In-Reply-To*mail.gmail.com>, 0.00289, References*mail.gmail.com>, 0.00297, >+>, 0.00323, >+>, 0.00323, >+And, 0.00329, at+10, 0.00329, >>+>>, 0.00362, >>+>>, 0.00362, for+>, 0.00375, exists, 0.00404, From*Attila, 0.00438, >>+Hi, 0.00477, 10+38, 0.00477, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id DE9B612B4CA1; Tue, 14 Jan 2014 20:21:16 +0100 (CET) Message-ID: <52D58E29.7040306@fsn.hu> Date: Tue, 14 Jan 2014 20:21:13 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Nikolay Denev Subject: Re: ECMP hash keys? References: <52D5138B.8050100@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 19:21:21 -0000 Hi, I've read (well, mostly) OpenBSD's version (http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix_mpath.c), and I think it would be good to catch up with them. BTW, I couldn't even get it to work: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/185771 but I have only netbooted machines, it seems the two don't match currently. On 01/14/2014 08:15 PM, Nikolay Denev wrote: > Hi, > > Currently it's implemented using Modulo-N Hash (RFC2991), see > radix_mpath.c:rtalloc_mpath_fib() > > And as hash the xor of source and destination IP is supplied, look for > rtalloc_mpath_fib() in ip_output.c : > > ... > #ifdef RADIX_MPATH > rtalloc_mpath_fib(ro, > ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), > inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); > #else > ... > > I've tried to hack this to use m_pkthdr.flowid if it exists, but in my > case my network cards were not setting this (vr(4) on soekris) so I > did not saw any change. Maybe my idea was completely wrong, but the > XOR of src and dst IP is 4 bytes, and this is the size of the flowid > as well. (haven't tried with FLOWTABLE enabled though). > > --Nikolay > > On Tue, Jan 14, 2014 at 10:38 AM, Attila Nagy wrote: >> Hi, >> >> Does equal cost multipath take only the destination address into >> consideration when choosing the route? (I've spent only about two minutes >> reading radix_mpath.h, but I've got this impression) >> >> What would be needed to use src and dst addresses and ports -if appropriate? >> >> 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 Tue Jan 14 20:12:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 274C8AF4 for ; Tue, 14 Jan 2014 20:12:12 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 91E581E79 for ; Tue, 14 Jan 2014 20:12:11 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id b8so702695lan.4 for ; Tue, 14 Jan 2014 12:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=O1mUlO5hiHY3+Yy9xypmitThsd7kmS+CvIPkaKCPhNc=; b=a76j3aEJCiIiygErq4IzuAbdsiUIkUP+bMNriaGF/Xdn1+bRY4KoB+lq+D8CiyK8Zd v3C2amfER/TbmXqBShDI23GWGGaLs5CnOiyeL8xaBmfQSp5F90ScV4mhmFGEQiYjYKhg 8CJSTSqQQLuOvZQUHkxywlHrEVMKJdGqY9OTE0Aly/nToSa0lCxZ+addhB21BmlmPwf1 d2Dn54OJAVJkFSrYAza/TWZtKTX/KMqFcWhHG3Dr0pXx6YoWMNPzF1hpDqfZvmYOwklX pnlXEAWxQDrUeW+faSXduAy6cK3n/RCshR4bbrqtWEex4aLg6q3lboZdUB8u3XAiVg04 9qYA== MIME-Version: 1.0 X-Received: by 10.152.22.228 with SMTP id h4mr1603218laf.71.1389730329512; Tue, 14 Jan 2014 12:12:09 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Tue, 14 Jan 2014 12:12:09 -0800 (PST) Date: Tue, 14 Jan 2014 12:12:09 -0800 X-Google-Sender-Auth: whfPmnVAjBujD9lWgKouXnOjDS0 Message-ID: Subject: Fwd: netmap support for libpcap now available From: Luigi Rizzo To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 20:12:12 -0000 FYI. ---------- Forwarded message ---------- From: Luigi Rizzo Date: Tue, Jan 14, 2014 at 12:08 PM Subject: netmap support for libpcap now available To: tcpdump-workers@lists.tcpdump.org since there were no takers i went ahead and did it. The repo at http://code.google.com/p/netmap/ has been updated with a newer version of netmap, and the extra/ directory contains a netmap backend for libpcap https://code.google.com/p/netmap/source/browse/extra/libpcap-netmap.diff which works against a recent (Jan11) libpcap version from github https://github.com/the-tcpdump-group/libpcap/commits/master commit fd04c4ff9f9a6b50fccec7afb18af64433730a2b Author: Guy Harris Date: Sat Jan 11 20:38:02 2014 -0800 For some quick testing (linux; FreeBSD is similar): - download the netmap code from code.google.com/p/netmap/ - compile just the netmap module and the examples (cd LINUX; make NODRIVERS=1 ) (cd examples; make) - install the module (cd LINUX; sudo insmod ./netmap_lin.ko) (either change access privs to /dev/netmap, or run netmap clients with root privs) - fetch the pcap code - patch with the netmap support files cd pcap-base-code; patch -p1 < /wherever/is/the/netmap-base-dir/extra/libpcap-netmap-diff ) - make sure the netmap headers are accessible and rebuild libpcap export CFLAGS=-I/wherever/is/the/netmap-base-dir/sys ./configure make - create a link so ld will find it ln -s libpcap.so.1.6.0-PRE-GIT libpcap.so.0.8 - and now you can run tcpdump using the current library (depending on the OS you may need to tell apparmor to allow the library override for tcpdump, or make a non suid copy of tcpdump) LD_LIBRARY_PATH=. tcpdump -ni valexx:yy while in another window you run a netmap traffic generator /wherever/is/the/netmap-base-dir/pkt-gen -i valexx:zz -f tx You can access an ordinary interface in emulated netmap mode by prefixing the name with netmap: , but BEWARE: *** in this mode the interface is only used for capture, *** and goes back to regular mode when you exit the tcpdump LD_LIBRARY_PATH=. tcpdump -ni netmap:eth0 cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 20:15:57 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A90CBEE4 for ; Tue, 14 Jan 2014 20:15:57 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 82D9210B0 for ; Tue, 14 Jan 2014 20:15:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6ED90B941; Tue, 14 Jan 2014 15:15:56 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Showing CDP info in ifconfig? Date: Tue, 14 Jan 2014 11:04:40 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52D50065.8060907@fsn.hu> In-Reply-To: <52D50065.8060907@fsn.hu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401141104.40813.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 14 Jan 2014 15:15:56 -0500 (EST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 20:15:57 -0000 On Tuesday, January 14, 2014 4:16:21 am Attila Nagy wrote: > Hi, > > Anybody thought about how useful would be showing CDP info in ifconfig > output? > > Something like this: > # ifconfig igb2 > igb2: flags=8843 metric 0 mtu 1500 > options=401bb > ether ac:16:2d:9a:18:ce > inet6 fe80::ae16:2dff:fe9a:18ce%igb2 prefixlen 64 tentative > scopeid 0x3 > inet 10.0.2.2 netmask 0xffffff00 broadcast 10.0.2.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > neighbor id: DP1106-A05-11-N5K(SSI3235613KZ) > neighbor ip: 172.28.2.24 > neighborport-id: Ethernet109/1/47 > > And maybe some other info (like VLAN tags, MTU etc). lladvd (for LLDP) implements this by using the information it gleans to set the optional description field on an interface. The result looks like: igb0: flags=8843 metric 0 mtu 1500 description: connected to someswitch (eth1/1/3) ... cxl0: flags=8843 metric 0 mtu 1500 description: connected to someotherswitch (Eth3) ... -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 14 20:22:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1761BB66 for ; Tue, 14 Jan 2014 20:22:48 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9547B14D3 for ; Tue, 14 Jan 2014 20:22:47 +0000 (UTC) Received: by mail-la0-f51.google.com with SMTP id c6so704750lan.24 for ; Tue, 14 Jan 2014 12:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mfzMzxM3i6aKIqzLCgfSfBQyPUbMugG7F3ixHYXEu0g=; b=PnfFD5coNbOwyEF3+UYjgUEDWj9nWqgP6vv4FKCY+v8SmJG74B0rx7TJ0/UilboU8Z HbNA3EJ9MyyE2XEWnE6Mt2fNWLB7Z9bkO5QZsHWGnbamQGJHrr8P5DAwUICvPbePsqwf y2Kw0F25z18n6adD/HHD2Z9F4aObQa6vvyium/FyMuweKF/uHRHlyQOx/eIGPDDNRxgE 7g6GQ8i0K3qjfCWdMfpCCzQr+T6kYckHEuflRlojtI0F7WEZqbs37w1mjgiq6vIOG9yc +TXb6ofwscqFZFsFpFbX6rj3rEbZBCaARlGAfYxLiw8nNXOEXGzfnc1JpXgkTp7kFVtM yKbQ== MIME-Version: 1.0 X-Received: by 10.112.130.35 with SMTP id ob3mr1980968lbb.2.1389730965700; Tue, 14 Jan 2014 12:22:45 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.114.242.33 with HTTP; Tue, 14 Jan 2014 12:22:45 -0800 (PST) In-Reply-To: <52D58E29.7040306@fsn.hu> References: <52D5138B.8050100@fsn.hu> <52D58E29.7040306@fsn.hu> Date: Tue, 14 Jan 2014 20:22:45 +0000 X-Google-Sender-Auth: r4Gbr9aKg9hwBeULL4tvYS6JxAM Message-ID: Subject: Re: ECMP hash keys? From: Nikolay Denev To: Attila Nagy Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 14 Jan 2014 20:22:48 -0000 On Tue, Jan 14, 2014 at 7:21 PM, Attila Nagy wrote: > Hi, > > I've read (well, mostly) OpenBSD's version > (http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/radix_mpath.c), and I > think it would be good to catch up with them. > > BTW, I couldn't even get it to work: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/185771 > but I have only netbooted machines, it seems the two don't match currently. > > > On 01/14/2014 08:15 PM, Nikolay Denev wrote: >> >> Hi, >> >> Currently it's implemented using Modulo-N Hash (RFC2991), see >> radix_mpath.c:rtalloc_mpath_fib() >> >> And as hash the xor of source and destination IP is supplied, look for >> rtalloc_mpath_fib() in ip_output.c : >> >> ... >> #ifdef RADIX_MPATH >> rtalloc_mpath_fib(ro, >> ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), >> inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); >> #else >> ... >> >> I've tried to hack this to use m_pkthdr.flowid if it exists, but in my >> case my network cards were not setting this (vr(4) on soekris) so I >> did not saw any change. Maybe my idea was completely wrong, but the >> XOR of src and dst IP is 4 bytes, and this is the size of the flowid >> as well. (haven't tried with FLOWTABLE enabled though). >> >> --Nikolay >> >> On Tue, Jan 14, 2014 at 10:38 AM, Attila Nagy wrote: >>> >>> Hi, >>> >>> Does equal cost multipath take only the destination address into >>> consideration when choosing the route? (I've spent only about two minutes >>> reading radix_mpath.h, but I've got this impression) >>> >>> What would be needed to use src and dst addresses and ports -if >>> appropriate? >>> >>> 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" > > I'm running slightly modified r259547, but I've had to disable "device pf" as I was also getting panics on boot. I have some of melifaro@'s RADIX_MPATH related fixes applied locally. And yes, probably some sync up with OpenBSD's mpath code can be done, however they seem to do some things differently: - Multipath route manipulation with route(8) requires the new "-mpath" flag, which might be something that would be needed for FreeBSD as well if RADIX_MPATH would become something enabled in GENERIC, otherwise I think some stuff might break, especially when you expect to be able to remove a route by simply providing the prefix without the gateway. - They seem to also have route priorities in the kernel, which also seem to be using the mpath code and I'm not sure FreeBSD developers would agree to merge, as it seems to make the kernel FIB more like a RIB. --Nikolay From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 06:02:30 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE0A232E; Wed, 15 Jan 2014 06:02:30 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 132411B10; Wed, 15 Jan 2014 06:02:29 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 67D5E1294221; Wed, 15 Jan 2014 07:02:27 +0100 (CET) X-Bogosity: Unsure, tests=bogofilter, spamicity=0.455723, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 9.2836] X-CRM114-CacheID: sfid-20140115_07022_009FB2D7 X-CRM114-Status: Good ( pR: 9.2836 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jan 15 07:02:27 2014 X-DSPAM-Confidence: 0.9930 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d62473997771253676042 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, >+the, 0.00081, wrote+>, 0.00189, >+>, 0.00323, >+>, 0.00323, From*Attila, 0.00438, looks+like, 0.00500, wrote, 0.00520, References*fsn.hu>, 0.00583, References*freebsd.org>, 0.00748, The+result, 0.00748, can't+find, 0.00748, Received*online.co.hu+[195.228.243.99]), 0.00872, Received*[195.228.243.99]), 0.00872, Looks, 0.00872, Received*online.co.hu, 0.00872, From*Attila+Nagy, 0.00872, like+>, 0.00872, Received*(japan.t, 0.00872, From*Nagy+ Date: Wed, 15 Jan 2014 07:02:25 +0100 From: Attila Nagy MIME-Version: 1.0 To: John Baldwin , freebsd-net@freebsd.org Subject: Re: Showing CDP info in ifconfig? References: <52D50065.8060907@fsn.hu> <201401141104.40813.jhb@freebsd.org> In-Reply-To: <201401141104.40813.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 06:02:30 -0000 On 01/14/14 17:04, John Baldwin wrote: > lladvd (for LLDP) implements this by using the information it gleans to set > the optional description field on an interface. The result looks like: > > igb0: flags=8843 metric 0 mtu 1500 > description: connected to someswitch (eth1/1/3) > ... > cxl0: flags=8843 metric 0 mtu 1500 > description: connected to someotherswitch (Eth3) > ... > Looks great, but I can't find it. Could you please give a pointer? Thanks, From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 07:25:31 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34DBB20E for ; Wed, 15 Jan 2014 07:25:31 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 99BE312AD for ; Wed, 15 Jan 2014 07:25:30 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1W3Kqm-000HL3-WF for freebsd-net@freebsd.org; Wed, 15 Jan 2014 11:25:21 +0400 Message-ID: <52D637E0.8070603@smartspb.net> Date: Wed, 15 Jan 2014 11:25:20 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD network optimization project References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140114-1, 14.01.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 07:25:31 -0000 Vitalii, I would be very appreciate if you will publish anywere your current production results and future experience. And I agree with you in NAT problem. By the way, while pf NAT is the best of the all available (in terms of speed, convenience and easy management), it has a huge lack - needs in external FTP helper (ftp-proxy) and event that doesn't work 100% correctly. So far I would say that for ISP purpose (which, I would say, is the most often use case, at least in Russia) we really need in rock solid NAT and shapers, in the scope of one mechanism. At the moment majority use at their NAT routers dummynet (for it mask flexibility) in ipfw and pf NAT for features described above. It's inconveniently. 14.01.2014 21:19, Vitalii Duk ÐŋÐļŅˆÐĩŅ‚: > Luigi, your project is really interesting, you've done a great job! > I will try to test ipfw and dummynet with netmap in my netork. > But there is still a problem with NAT and libalias. I havent tried new > SMP-friendly pf NAT, maybe it will give a good perfomance. But it will be > also great to have something working with ipfw. > > I think in my previous list I forget to note about two more problems: > 1. Not full support of LACP in FreeBSD (for example it's not possible to > set priority, hash algorithm and mode(active/passive)). > 2. No support of *RFC 3069 (IP unnumbered/SuperVLAN).* > > 2014/1/14 Luigi Rizzo > >> >> >> On Tue, Jan 14, 2014 at 6:26 AM, Luigi Rizzo wrote: >> >>> On Tue, Jan 14, 2014 at 5:48 AM, Vitalii Duk wrote: >>> >>>> Hello, colleagues! >>>> >>>> I'm working in ISP and use FreeBSD on BRAS'es. >>>> I have noticed that there are few problems in FreeBSD, which do not allow >>>> to use it on high speeds (>10G, >2Mpps). >>>> >>> for this type of applications you really want to look at netmap >>> >>> http://info.iet.unipi.it/~luigi/netmap/ >>> >>> which already does a lot of what you need. >>> >> and if you feel like funding some specific work in this area >> you can contact me off list >> >> cheers >> luigi >> >>> cheers >>> luigi >>> >>>> So I have a suggestion to create a list of improvements that needed to be >>>> done in FreeBSD collectively, to improve network perfomance and be on the >>>> same or higher level as Linux or Vyatta. >>>> After we create a todo list, it's possible to organize a donation for >>>> those >>>> developers who can do that job. >>>> I'm ready to donate money for this project, and I think that I'm not only >>>> one interested in it. I like FreeBSD and I don't want to migrate to >>>> another >>>> OS. >>>> >>>> My list of improvements in very general words (needed to be detailed): >>>> 1. Improve network subsystem and kernel to provide >10G forwarding. >>>> 2. Improve dummynet to provide massive shaping service and to be not >>>> single >>>> threaded (or maybe write something radically new). >>>> 3. Replace/rewrite libalias to support massive NAT service and remove >>>> current problems and limitations (non-SMP, offloading problems, etc). >>>> 4. Better work of tcpdump on >10G speeds (BPF improvements). >>>> >>>> Thank you in advance. Waiting for some other suggestions and support from >>>> specialists. >>>> >>>> Best regars, dv. >>>> _______________________________________________ >>>> 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" >>>> >>> >>> >>> -- >>> -----------------------------------------+------------------------------- >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>> TEL +39-050-2211611 . via Diotisalvi 2 >>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>> -----------------------------------------+------------------------------- >>> >> >> >> -- >> -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------- >> > _______________________________________________ > 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, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 07:55:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B113C5C for ; Wed, 15 Jan 2014 07:55:08 +0000 (UTC) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C60201543 for ; Wed, 15 Jan 2014 07:55:07 +0000 (UTC) Received: from [10.10.1.30] (helo=frv196.fwdcdn.com) by frv190.fwdcdn.com with esmtp ID 1W3L41-0002UG-HJ for freebsd-net@freebsd.org; Wed, 15 Jan 2014 09:39:01 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:Cc:To:Subject:From:Date; bh=eG3nJKoCjOF3QCTB9dTA35/o6sC18/PjcvuIr8DDoJU=; b=tBd50fs5OwWVrVl7UKMy5GbNnnYo1cfqsZ11OVUQuMFyPwMtyVJZVxrh3M2lKmyG/aDL8FuohAfiyOjze7V5q9DcDIkSo+a9NU3Wepic7aCjS0A2rBU4d02zRsXD1USh2d88sHsO/zdGCsp1qqzADrFCdEdgNVq8U9Xxgc7ZrJI=; Received: from [10.10.10.34] (helo=frv34.ukr.net) by frv196.fwdcdn.com with smtp ID 1W3L3q-0001Ss-Jc for freebsd-net@freebsd.org; Wed, 15 Jan 2014 09:38:50 +0200 Date: Wed, 15 Jan 2014 09:38:49 +0200 From: wishmaster Subject: Re[2]: FreeBSD network optimization project To: Dennis Yusupoff X-Mailer: mail.ukr.net 5.0 Message-Id: <1389771099.940290294.rj98b435@frv34.ukr.net> In-Reply-To: <52D637E0.8070603@smartspb.net> References: <52D637E0.8070603@smartspb.net> MIME-Version: 1.0 Received: from artemrts@ukr.net by frv34.ukr.net; Wed, 15 Jan 2014 09:38:49 +0200 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 07:55:08 -0000 Hi, from my point of view I think there is one solution from your words. I am about pf as NAT and dummynet as shaper. The pfSense uses own implementation of bundle of pf+dummynet. Ermal, my be time has come and you will commit this into FreeBSD HEAD? Cheers, w --- Original message --- From: "Dennis Yusupoff" Date: 15 January 2014, 09:25:40 > Vitalii, I would be very appreciate if you will publish anywere your > current production results and future experience. > And I agree with you in NAT problem. By the way, while pf NAT is the > best of the all available (in terms of speed, convenience and easy > management), it has a huge lack - needs in external FTP helper > (ftp-proxy) and event that doesn't work 100% correctly. > So far I would say that for ISP purpose (which, I would say, is the most > often use case, at least in Russia) we really need in rock solid NAT and > shapers, in the scope of one mechanism. At the moment majority use at > their NAT routers dummynet (for it mask flexibility) in ipfw and pf NAT > for features described above. It's inconveniently. > > 14.01.2014 21:19, Vitalii Duk ÐŋÐļŅˆÐĩŅ‚: > > Luigi, your project is really interesting, you've done a great job! > > I will try to test ipfw and dummynet with netmap in my netork. > > But there is still a problem with NAT and libalias. I havent tried new > > SMP-friendly pf NAT, maybe it will give a good perfomance. But it will be > > also great to have something working with ipfw. > > > > I think in my previous list I forget to note about two more problems: > > 1. Not full support of LACP in FreeBSD (for example it's not possible to > > set priority, hash algorithm and mode(active/passive)). > > 2. No support of *RFC 3069 (IP unnumbered/SuperVLAN).* > > > > 2014/1/14 Luigi Rizzo > > > >> > >> > >> On Tue, Jan 14, 2014 at 6:26 AM, Luigi Rizzo wrote: > >> > >>> On Tue, Jan 14, 2014 at 5:48 AM, Vitalii Duk wrote: > >>> > >>>> Hello, colleagues! > >>>> > >>>> I'm working in ISP and use FreeBSD on BRAS'es. > >>>> I have noticed that there are few problems in FreeBSD, which do not allow > >>>> to use it on high speeds (>10G, >2Mpps). > >>>> > >>> for this type of applications you really want to look at netmap > >>> > >>> http://info.iet.unipi.it/~luigi/netmap/ > >>> > >>> which already does a lot of what you need. > >>> > >> and if you feel like funding some specific work in this area > >> you can contact me off list > >> > >> cheers > >> luigi > >> > >>> cheers > >>> luigi > >>> > >>>> So I have a suggestion to create a list of improvements that needed to be > >>>> done in FreeBSD collectively, to improve network perfomance and be on the > >>>> same or higher level as Linux or Vyatta. > >>>> After we create a todo list, it's possible to organize a donation for > >>>> those > >>>> developers who can do that job. > >>>> I'm ready to donate money for this project, and I think that I'm not only > >>>> one interested in it. I like FreeBSD and I don't want to migrate to > >>>> another > >>>> OS. > >>>> > >>>> My list of improvements in very general words (needed to be detailed): > >>>> 1. Improve network subsystem and kernel to provide >10G forwarding. > >>>> 2. Improve dummynet to provide massive shaping service and to be not > >>>> single > >>>> threaded (or maybe write something radically new). > >>>> 3. Replace/rewrite libalias to support massive NAT service and remove > >>>> current problems and limitations (non-SMP, offloading problems, etc). > >>>> 4. Better work of tcpdump on >10G speeds (BPF improvements). > >>>> > >>>> Thank you in advance. Waiting for some other suggestions and support from > >>>> specialists. > >>>> > >>>> Best regars, dv. > >>>> _______________________________________________ > >>>> 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" > >>>> > >>> > >>> > >>> -- > >>> -----------------------------------------+------------------------------- > >>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > >>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >>> TEL +39-050-2211611 . via Diotisalvi 2 > >>> Mobile +39-338-6809875 . 56122 PISA (Italy) > >>> -----------------------------------------+------------------------------- > >>> > >> > >> > >> -- > >> -----------------------------------------+------------------------------- > >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione > >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > >> TEL +39-050-2211611 . via Diotisalvi 2 > >> Mobile +39-338-6809875 . 56122 PISA (Italy) > >> -----------------------------------------+------------------------------- > >> > > _______________________________________________ > > 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, > Dennis Yusupoff, > network engineer of > Smart-Telecom ISP > Russia, Saint-Petersburg > > _______________________________________________ > 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 Wed Jan 15 09:16:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FB10D27 for ; Wed, 15 Jan 2014 09:16:09 +0000 (UTC) Received: from quix.smartspb.net (quix.smartspb.net [217.119.16.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB5771CA6 for ; Wed, 15 Jan 2014 09:16:08 +0000 (UTC) Received: from dyr.smartspb.net ([217.119.16.26] helo=[127.0.0.1]) by quix.smartspb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.61 (FreeBSD)) (envelope-from ) id 1W3MZy-0004ql-Cr for freebsd-net@freebsd.org; Wed, 15 Jan 2014 13:16:06 +0400 Message-ID: <52D651D6.8060605@smartspb.net> Date: Wed, 15 Jan 2014 13:16:06 +0400 From: Dennis Yusupoff User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: FreeBSD network optimization project References: <52D637E0.8070603@smartspb.net> <1389771099.940290294.rj98b435@frv34.ukr.net> In-Reply-To: <1389771099.940290294.rj98b435@frv34.ukr.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 140114-1, 14.01.2014), Outbound message X-Antivirus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 09:16:09 -0000 Currently? I thinks it's the only way. And please, remember about external ftp-proxy helper, which is far from ideal and should to be replaced or at least fixed for work in CGN cases. Moreover, we should to understand that coming time for CGN (http://en.wikipedia.org/wiki/Carrier-grade_NAT) to work from IPv6-only networks in IPv4 networks. I can't commit anything in FreeBSD, I haven't enough skills. Or was it sarcasm? 15.01.2014 11:38, wishmaster ÐŋÐļŅˆÐĩŅ‚: > from my point of view I think there is one solution from your words. I am about pf as NAT and dummynet as shaper. The pfSense uses own implementation of bundle of pf+dummynet. Ermal, my be time has come and you will commit this into FreeBSD HEAD? -- Best regards, Dennis Yusupoff, network engineer of Smart-Telecom ISP Russia, Saint-Petersburg From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 09:18:37 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F578E65 for ; Wed, 15 Jan 2014 09:18:37 +0000 (UTC) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1E001CED for ; Wed, 15 Jan 2014 09:18:36 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id n16so908453oag.29 for ; Wed, 15 Jan 2014 01:18:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1Z7a24hl8pO1b4xCZQUyUvk1Nc/QaNkU/Rem7vu8g5s=; b=TfQ5e4nWhqI7nHALoKnQtVqUfFyBRjTnThnhWHApIZy3iYNOnp3CSltpTs9N09GfHW 4X+RFknT5pk/sYftGGoACSZgpmvHnFbOITOrHxW6N4Eh0aCON+frJ8TJZSkp+kYg+g3s aOPdBuxb+G/4DA9N1PDCHrV2FyqfikzjiS/Haos5jWSc5VI1kYbBDsmN+kXrlDM7TYWT SjKMTAv+o0FVJ4zH06BxTUbZv3fSQXBPuHJCFcQOFw4nqumJ0FGRDrJ7jWry4QDHdLGe 3mcVt3x2qnNMY6f4Q7UTqgzFNQXLox2q0nt4bLtHIjcQWX92FFmYxW6E2xULZvJcyyhL y+wg== X-Gm-Message-State: ALoCoQmZ+942RzEuWLmgqwyqf7Ymsewl7xvrDPKzVrewEAg3E3DhRIelMjsONgQnIVLPJ8YN8lYq X-Received: by 10.60.119.70 with SMTP id ks6mr745558oeb.45.1389775816060; Wed, 15 Jan 2014 00:50:16 -0800 (PST) Received: from [172.21.0.33] (67-198-60-238.static.grandenetworks.net. [67.198.60.238]) by mx.google.com with ESMTPSA id r6sm3807056obi.14.2014.01.15.00.50.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 00:50:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: FreeBSD network optimization project From: Jim Thompson In-Reply-To: <1389771099.940290294.rj98b435@frv34.ukr.net> Date: Wed, 15 Jan 2014 02:50:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2E3DCBFC-9714-467C-90D6-A1E3B2BD1FB1@netgate.com> References: <52D637E0.8070603@smartspb.net> <1389771099.940290294.rj98b435@frv34.ukr.net> To: wishmaster X-Mailer: Apple Mail (2.1827) Cc: Dennis Yusupoff , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 09:18:37 -0000 We=E2=80=99ve been more than willing for over a year. Jim On Jan 15, 2014, at 1:38 AM, wishmaster wrote: > Hi, >=20 > from my point of view I think there is one solution from your words. I = am about pf as NAT and dummynet as shaper. The pfSense uses own = implementation of bundle of pf+dummynet. Ermal, my be time has come and = you will commit this into FreeBSD HEAD? >=20 > Cheers, > w >=20 > --- Original message --- > From: "Dennis Yusupoff" > Date: 15 January 2014, 09:25:40 >=20 >=20 >=20 >> Vitalii, I would be very appreciate if you will publish anywere your >> current production results and future experience. >> And I agree with you in NAT problem. By the way, while pf NAT is the >> best of the all available (in terms of speed, convenience and easy >> management), it has a huge lack - needs in external FTP helper >> (ftp-proxy) and event that doesn't work 100% correctly. >> So far I would say that for ISP purpose (which, I would say, is the = most >> often use case, at least in Russia) we really need in rock solid NAT = and >> shapers, in the scope of one mechanism. At the moment majority use at >> their NAT routers dummynet (for it mask flexibility) in ipfw and pf = NAT >> for features described above. It's inconveniently. >>=20 >> 14.01.2014 21:19, Vitalii Duk =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> Luigi, your project is really interesting, you've done a great job! >>> I will try to test ipfw and dummynet with netmap in my netork. >>> But there is still a problem with NAT and libalias. I havent tried = new >>> SMP-friendly pf NAT, maybe it will give a good perfomance. But it = will be >>> also great to have something working with ipfw. >>>=20 >>> I think in my previous list I forget to note about two more = problems: >>> 1. Not full support of LACP in FreeBSD (for example it's not = possible to >>> set priority, hash algorithm and mode(active/passive)). >>> 2. No support of *RFC 3069 (IP unnumbered/SuperVLAN).* >>>=20 >>> 2014/1/14 Luigi Rizzo >>>=20 >>>>=20 >>>>=20 >>>> On Tue, Jan 14, 2014 at 6:26 AM, Luigi Rizzo = wrote: >>>>=20 >>>>> On Tue, Jan 14, 2014 at 5:48 AM, Vitalii Duk = wrote: >>>>>=20 >>>>>> Hello, colleagues! >>>>>>=20 >>>>>> I'm working in ISP and use FreeBSD on BRAS'es. >>>>>> I have noticed that there are few problems in FreeBSD, which do = not allow >>>>>> to use it on high speeds (>10G, >2Mpps). >>>>>>=20 >>>>> for this type of applications you really want to look at netmap >>>>>=20 >>>>> http://info.iet.unipi.it/~luigi/netmap/ >>>>>=20 >>>>> which already does a lot of what you need. >>>>>=20 >>>> and if you feel like funding some specific work in this area >>>> you can contact me off list >>>>=20 >>>> cheers >>>> luigi >>>>=20 >>>>> cheers >>>>> luigi >>>>>=20 >>>>>> So I have a suggestion to create a list of improvements that = needed to be >>>>>> done in FreeBSD collectively, to improve network perfomance and = be on the >>>>>> same or higher level as Linux or Vyatta. >>>>>> After we create a todo list, it's possible to organize a donation = for >>>>>> those >>>>>> developers who can do that job. >>>>>> I'm ready to donate money for this project, and I think that I'm = not only >>>>>> one interested in it. I like FreeBSD and I don't want to migrate = to >>>>>> another >>>>>> OS. >>>>>>=20 >>>>>> My list of improvements in very general words (needed to be = detailed): >>>>>> 1. Improve network subsystem and kernel to provide >10G = forwarding. >>>>>> 2. Improve dummynet to provide massive shaping service and to be = not >>>>>> single >>>>>> threaded (or maybe write something radically new). >>>>>> 3. Replace/rewrite libalias to support massive NAT service and = remove >>>>>> current problems and limitations (non-SMP, offloading problems, = etc). >>>>>> 4. Better work of tcpdump on >10G speeds (BPF improvements). >>>>>>=20 >>>>>> Thank you in advance. Waiting for some other suggestions and = support from >>>>>> specialists. >>>>>>=20 >>>>>> Best regars, dv. >>>>>> _______________________________________________ >>>>>> freebsd-net@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>>> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> = -----------------------------------------+------------------------------- >>>>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. = dell'Informazione >>>>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>>> TEL +39-050-2211611 . via Diotisalvi 2 >>>>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>>>> = -----------------------------------------+------------------------------- >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> = -----------------------------------------+------------------------------- >>>> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. = dell'Informazione >>>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >>>> TEL +39-050-2211611 . via Diotisalvi 2 >>>> Mobile +39-338-6809875 . 56122 PISA (Italy) >>>> = -----------------------------------------+------------------------------- >>>>=20 >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org" >>>=20 >>>=20 >>=20 >> --=20 >> Best regards, >> Dennis Yusupoff, >> network engineer of >> Smart-Telecom ISP >> Russia, Saint-Petersburg=20 >>=20 >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to = "freebsd-net-unsubscribe@freebsd.org"=20 > _______________________________________________ > 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 Wed Jan 15 09:18:32 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25ADEE4F for ; Wed, 15 Jan 2014 09:18:32 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B27521CDE for ; Wed, 15 Jan 2014 09:18:31 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1W3ImX-000Lap-LU; Wed, 15 Jan 2014 09:12:49 +0400 Message-ID: <52D6519D.2050400@FreeBSD.org> Date: Wed, 15 Jan 2014 13:15:09 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Roy Marples , freebsd-net@freebsd.org Subject: Re: IPv6: report address flag changes to userland References: 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.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 09:18:32 -0000 On 13.01.2014 19:36, Roy Marples wrote: > Hi List Hello! > > There is zero point as I see it in announcing newly added tentative > addresses to userland. > It's not as if userland can actually use the address at this point. > However, there is immense benefit in announcing address flag changes, > such as removal of tentative, or addition of the other flags. This looks very reasonable. > > The main benefit for this patch is so that dhcpcd(8) listen for when > the kernel has completed DAD and has announced the result. > dhcpcd can then react immediately instead of having to wait for the > full time as dictated by the RFC. This can also help when doing IPv6 netmap forwarding to sync kernel and userland records. > > The attached patch addresses the above and was cut from FreeBSD-9 - > there is a small adjustment needed for -current which is noted in the > patch. > The patch is based on the work I did in NetBSD a few months ago > documented here: > http://netbsd.2816.n7.nabble.com/PATCH-to-only-announce-RTM-NEWADDR-once-IPv6-DAD-completes-tp281110.html > > > Comments? I'll do some tests and merge it. > > Roy > > > _______________________________________________ > 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 Wed Jan 15 09:21:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0ED61D6 for ; Wed, 15 Jan 2014 09:21:45 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C55EF1D6A for ; Wed, 15 Jan 2014 09:21:44 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1W3Ipe-000LcP-83; Wed, 15 Jan 2014 09:16:02 +0400 Message-ID: <52D6525D.50102@FreeBSD.org> Date: Wed, 15 Jan 2014 13:18:21 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Nikolay Denev , Attila Nagy Subject: Re: ECMP hash keys? References: <52D5138B.8050100@fsn.hu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 09:21:45 -0000 On 14.01.2014 23:15, Nikolay Denev wrote: > Hi, > > Currently it's implemented using Modulo-N Hash (RFC2991), see > radix_mpath.c:rtalloc_mpath_fib() Yup. I'm going to change this to use flowid. > > And as hash the xor of source and destination IP is supplied, look for > rtalloc_mpath_fib() in ip_output.c : > > ... > #ifdef RADIX_MPATH > rtalloc_mpath_fib(ro, > ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), > inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); > #else > ... > > I've tried to hack this to use m_pkthdr.flowid if it exists, but in my > case my network cards were not setting this (vr(4) on soekris) so I You can try http://static.ipfw.ru/patches/netisr_ip_flowid.diff to get flowid values generated by netisr. > did not saw any change. Maybe my idea was completely wrong, but the > XOR of src and dst IP is 4 bytes, and this is the size of the flowid > as well. (haven't tried with FLOWTABLE enabled though). > > --Nikolay > > On Tue, Jan 14, 2014 at 10:38 AM, Attila Nagy wrote: >> Hi, >> >> Does equal cost multipath take only the destination address into >> consideration when choosing the route? (I've spent only about two minutes >> reading radix_mpath.h, but I've got this impression) >> >> What would be needed to use src and dst addresses and ports -if appropriate? >> >> 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" > _______________________________________________ > 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 Wed Jan 15 11:34:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86C79687; Wed, 15 Jan 2014 11:34:36 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1E28A189A; Wed, 15 Jan 2014 11:34:35 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0FBYUKe032160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jan 2014 15:34:30 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0FBYU44032159; Wed, 15 Jan 2014 15:34: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: Wed, 15 Jan 2014 15:34:30 +0400 From: Gleb Smirnoff To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Subject: Re: Regression on 10-RC5 with a multicast routing daemon Message-ID: <20140115113430.GK26504@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , andre@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 11:34:36 -0000 Olivier, On Tue, Jan 14, 2014 at 05:51:53PM +0100, Olivier Cochard-Labbé wrote: O> I'm trying to port a PIM sparse-mode daemon ( O> https://github.com/troglobit/pimd/) and I've meet a problem: O> This daemon compile and run fine on FreeBSD 9.2 but on 10-RC5 this daemon O> can't understand received multicast packets (received from other PIM O> neighbors) and display this kind of error message in debug mode "warning - O> Received packet from 10.0.12.2 shorter (28 bytes) than hdr+data length O> (20+28)". O> How to troubleshoot this problem ? O> O> My current work of this port can be tested with theses commands: O> O> cd /usr/ports O> fetch -o ports.pimd.shar " O> https://sourceforge.net/p/bsdrp/code/HEAD/tree/trunk/BSDRP/patches/ports.pimd.shar?format=raw O> " O> sh ./ports.pimd.shar O> cd net/pimd O> make install TL;DR version: you need not subtract iphdrlen in 10.0. Code in igmp.c:accept_igmp() should be smth like: iphdrlen = ip->ip_hl << 2; #ifdef RAW_INPUT_IS_RAW /* Linux */ ipdatalen = ntohs(ip->ip_len) - iphdrlen; #else #if __FreeBSD_version >= 1000000 ipdatalen = ip->ip_len - iphdrlen; #else ipdatalen = ip->ip_len; #endif #endif You can also look into quagga sources, file ospfd/ospf_packet.c, for more examples of workarounds for this API mess. Long story is the following. Historical behaviour of BSD raw sockets were the following: * packet is modified - packets' ip_len and ip_off are converted to host byte order - packets' ip_len is reduced by the actual size of IP header This is an artefact from the fact that the kernel stack modified every packet at the very beginning of its processing, and worked with it in this form. It just didn't bother to convert it before passing to raw socket, so raw socket wasn't truly _raw_. This is actually a bug. Later, most non-BSD operating systems defined the following API for raw sockets: * packet is passed unmodified btw, I find this much better behavior. Later, right before 9.0-RELEASE, in r226105 (merged to stable/9 as r226299) Andre has changed behaviour to: * packet is modified - packets' ip_len and ip_off are converted to host byte order This appeared a huge disaster to a number of ports, thus it was backed out in r227423 in stable/9. However this remained in head. We decided that all ports should be fixed during two years up to 10.0-RELEASE. Later on, there is a trend for BSD systems to convert their IP stacks to stop modifying byte order internally in kernel. But the compatibility for the raw sockets remained. This is what I did in FreeBSD in r241913 and in r241923. Right now, looking behind, it seems to me that we should have convert raw sockets to be truly raw, like in Linux, right in the 10-release cycle. The API mess should be reduced. According to comments in quagga, DragonFly has the following behavior: * packet is modified - packets' ip_len is reduced by the actual size of IP header Damn, what a mess. I'd like to go towards absolutely unmodified packets for the 11-release cycle. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 12:04:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2AAF443 for ; Wed, 15 Jan 2014 12:04:15 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 507501C90 for ; Wed, 15 Jan 2014 12:04:15 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3f46dn6QHrzGN37 for ; Wed, 15 Jan 2014 13:04:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla2; t=1389787447; x=1392379448; bh=giR oTDxazQp12MZxIY4aNgIuZsABIz74pGNkdMF5PtU=; b=FDB2+awOfAOCbqmg3P5 MDK81cwFsLD3Laj6nnt2njR1Ub5pWBQNNFcMd3BULYOYBSWJHZr3lRf+TsZCEkuS G6/Pi4BiZSgS6SOMyoVJiu9+xvAPwLBSWSmDAKZZnOVbfjaffea/52LHAVJUZNmF GpfGkusQdbE9puJztJNqzR/k= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id BvdIdnvD0Az2 for ; Wed, 15 Jan 2014 13:04:07 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Wed, 15 Jan 2014 13:04:07 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [193.2.4.95]) by mildred.ijs.si (Postfix) with ESMTP id DB23149D for ; Wed, 15 Jan 2014 13:04:07 +0100 (CET) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Wed, 15 Jan 2014 13:04:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 15 Jan 2014 13:04:07 +0100 From: Mark Martinec To: freebsd-net@freebsd.org Subject: Re: FreeBSD network optimization project Organization: J. Stefan Institute In-Reply-To: <52D651D6.8060605@smartspb.net> References: <52D637E0.8070603@smartspb.net> <1389771099.940290294.rj98b435@frv34.ukr.net> <52D651D6.8060605@smartspb.net> Message-ID: <3e8485b5832510b4781ea15fea2af849@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/0.9.5 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 12:04:15 -0000 2014-01-15, Dennis Yusupoff wrote: > Currently? I thinks it's the only way. And please, remember about > external ftp-proxy helper, which is far from ideal and should to be > replaced or at least fixed for work in CGN cases. > Moreover, we should to understand that coming time for CGN > (http://en.wikipedia.org/wiki/Carrier-grade_NAT) to work from > IPv6-only networks in IPv4 networks. CGN? Shudder to think of it! May be interesting to look at the Deutsche Telekom's TeraStream project when re-designing an ISP offering: http://blog.ipspace.net/2013/11/deutsche-telekom-terastream-designed.html http://www.youtube.com/watch?v=SUebF3UJiU4 http://blogs.cisco.com/sp/dts-ian-farrer-on-the-all-ipv6-terastream-network/ http://www.laboratories.telekom.com/public/English/Newsroom/news/pages/terastream-feldtest.aspx From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 12:52:13 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 225128FF for ; Wed, 15 Jan 2014 12:52:13 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70F1110F3 for ; Wed, 15 Jan 2014 12:52:11 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id s0FCptTT032714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Jan 2014 16:51:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id s0FCpttn032713; Wed, 15 Jan 2014 16:51:55 +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, 15 Jan 2014 16:51:55 +0400 From: Gleb Smirnoff To: Dennis Yusupoff Subject: Re: FreeBSD network optimization project Message-ID: <20140115125155.GN26504@FreeBSD.org> References: <52D637E0.8070603@smartspb.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D637E0.8070603@smartspb.net> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 12:52:13 -0000 On Wed, Jan 15, 2014 at 11:25:20AM +0400, Dennis Yusupoff wrote: D> Vitalii, I would be very appreciate if you will publish anywere your D> current production results and future experience. D> And I agree with you in NAT problem. By the way, while pf NAT is the D> best of the all available (in terms of speed, convenience and easy D> management), it has a huge lack - needs in external FTP helper D> (ftp-proxy) and event that doesn't work 100% correctly. I won't call that HUGE lack. Most bulk traffic nowdays is either HTTP or p2p. FTP is dying (and that's good). -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 14:09:47 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10935A5B; Wed, 15 Jan 2014 14:09:47 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E3F51696; Wed, 15 Jan 2014 14:09:45 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 7F0F112BD37E; Wed, 15 Jan 2014 15:09:36 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.350635, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 9.8668] X-CRM114-CacheID: sfid-20140115_15092_64B3A831 X-CRM114-Status: Good ( pR: 9.8668 ) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Jan 15 15:09:36 2014 X-DSPAM-Confidence: 0.9936 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d696a0232803360319692 X-DSPAM-Factors: 27, >+On, 0.00049, wrote+>>, 0.00115, wrote+>, 0.00189, >>+>, 0.00263, >>+>>, 0.00362, >>+>>, 0.00362, looks+like, 0.00500, wrote, 0.00520, wrote, 0.00520, References*fsn.hu>, 0.00583, References*fsn.hu>, 0.00583, In-Reply-To*fsn.hu>, 0.00617, Nagy+wrote, 0.00655, References*freebsd.org>, 0.00748, The+result, 0.00748, can't+find, 0.00748, Received*online.co.hu+[195.228.243.99]), 0.00872, Received*[195.228.243.99]), 0.00872, Looks, 0.00872, 07+02, 0.00872, Received*online.co.hu, 0.00872, Received*(japan.t, 0.00872, Received*(japan.t+online.co.hu, 0.00872, John+Baldwin, 0.01000, From*"Nagy, Attila" , 0.01000, mtu, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 8087012BD357; Wed, 15 Jan 2014 15:09:03 +0100 (CET) Message-ID: <52D6967B.8020507@fsn.hu> Date: Wed, 15 Jan 2014 15:08:59 +0100 From: "Nagy, Attila" MIME-Version: 1.0 To: John Baldwin , freebsd-net@freebsd.org Subject: Re: Showing CDP info in ifconfig? References: <52D50065.8060907@fsn.hu> <201401141104.40813.jhb@freebsd.org> <52D62471.9060808@fsn.hu> In-Reply-To: <52D62471.9060808@fsn.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 14:09:47 -0000 On 01/15/14 07:02, Attila Nagy wrote: > On 01/14/14 17:04, John Baldwin wrote: >> lladvd (for LLDP) implements this by using the information it gleans >> to set >> the optional description field on an interface. The result looks like: >> >> igb0: flags=8843 metric 0 mtu >> 1500 >> description: connected to someswitch (eth1/1/3) >> ... >> cxl0: flags=8843 metric 0 mtu >> 1500 >> description: connected to someotherswitch (Eth3) >> ... >> > Looks great, but I can't find it. Could you please give a pointer? > Nevermind, it's http://www.freshports.org/net/ladvd/ Thanks, From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 14:53:19 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 606B92E9 for ; Wed, 15 Jan 2014 14:53:19 +0000 (UTC) Received: from mail.lhr1.as41113.net (mail.lhr1.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 257171A41 for ; Wed, 15 Jan 2014 14:53:18 +0000 (UTC) Received: from [10.16.240.11] (unknown [212.9.98.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by mail.lhr1.as41113.net (Postfix) with ESMTPSA id 3f4BNm1g1qz7v2m; Wed, 15 Jan 2014 14:53:10 +0000 (UTC) Message-ID: <52D6A0D4.1060304@rewt.org.uk> Date: Wed, 15 Jan 2014 14:53:08 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Garrett Wollman , freebsd-net@freebsd.org Subject: Re: ETHER_MAX_LEN_JUMBO References: <21196.29430.733181.353677@hergotha.csail.mit.edu> <52CC9EF0.5010504@rewt.org.uk> <20140108012215.GV99167@funkthat.com> <52CCAA85.60107@rewt.org.uk> <20140108033959.GX99167@funkthat.com> In-Reply-To: <20140108033959.GX99167@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 14:53:19 -0000 On 08/01/2014 03:40, John-Mark Gurney wrote: > Joe Holden wrote this message on Wed, Jan 08, 2014 at 01:31 +0000: >> On 08/01/2014 01:22, John-Mark Gurney wrote: >>> Joe Holden wrote this message on Wed, Jan 08, 2014 at 00:42 +0000: >>>> 16k frames are available on commidity intel cards so perhaps a bump to >>>> 16k should be enough for the foreseeable future, although saying that >>>> there is nothing to stop another big leap in frame sizes. >>>> >>>> We should probably be ahead of the curve here, rather than playing catch >>>> up with vendors. Would it be possible to limit the max size by looking >>>> at drivers in the tree at compile-time, perhaps have them declare the >>>> max frame size the supported hardware can handle? >>> >>> Why do we even need this define? >>> >>> atse uses it to create a buffer so it doesn't have to deal w/ data being >>> split between mbufs... why they didn't use m_copydata + the ofset, I >>> don't know, but shouldn't be hard to fix the driver.. >>> >>> cas uses it instead of reading what the interface MTU is when programming >>> the max length of a frame... >>> >>> ng_eiface just uses it to limit how large you can set your MTU... >>> >>> It is used to define ETHERMTU_JUMBO, which is used by a few drivers >>> (cas, cxgb, cxgbe and mxge) to either set the default mtu, or limit how >>> large the MTU can be set to... >>> >>> I would say we should just remove these defines... If a card has an >>> MTU limit, let it define it's own, not use some fake limit by the rest >>> of the system... >>> >> This sounds like a much better idea if it isn't limited by the stack >> architecture, if it is only a handful of drivers that even care then the >> obviously correct solution is to remove this define entirely. > > I used fxr.watson.org to do this research: > http://fxr.watson.org/fxr/ident?i=ETHER_MAX_LEN_JUMBO > > Just so you can browse around for yourself. :) > > Hmm.. to make matters more interesting, the kernel version of cxgb > does not default to jumbo frames, BUT, the module version of cxgb does > default.. It's probably because no one uses the module that no one > noticed the difference... > > If you need help generating patches, let me know.. I can commit them > once they are tested, but I don't have hardware to test myself... > Looks like the only driver that relies on a fixed frame length for jumbos is cas, but that could easily be changed into a define just for that driver, the others (cxgb/cxgbe/mxge) just use it as either a default mtu or as an upper limit (which should really be based on the chip, not an arbitary limit) From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 15:17:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3A2ED29; Wed, 15 Jan 2014 15:17:58 +0000 (UTC) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B1E91D3F; Wed, 15 Jan 2014 15:17:58 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id nc12so1153824qeb.2 for ; Wed, 15 Jan 2014 07:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QWzA6AKiPdB5DWSaFp1YNfgle6/QvAjZqE3mJKQkxko=; b=Yeh7RqYfpna+tYNWti3fesb+V8RpacSCpTolWzXjfeJoYlm5zdWB7n648mgmF9cu66 Rpw9qgp6HSWIG2fecG1uh2yZ3m5wwBgGh7+dRZhMtxEFcl3ROVV8esS1witv+q9lBb17 trQrQp3PVIi0tjgUrPcgvvGBmlefyavloP6CZ+VfjR1UCDRygFUMtF99S/VP8YCa9Z5I yK5iVf3U2QRinsvYEHWt4oB9JDyQci3G+xRwX4XNPBUE6w+M6CKfylIPh5gUlReG7v6H mP09hEsRgTzyGHV+TS/Khtxmi0Yt194i1pEzHv29R0pvNN2ccUuySm7jdGQlOFazeEnz 1KaA== MIME-Version: 1.0 X-Received: by 10.224.16.72 with SMTP id n8mr5594616qaa.76.1389799077429; Wed, 15 Jan 2014 07:17:57 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Wed, 15 Jan 2014 07:17:57 -0800 (PST) In-Reply-To: <20140115113430.GK26504@FreeBSD.org> References: <20140115113430.GK26504@FreeBSD.org> Date: Wed, 15 Jan 2014 07:17:57 -0800 X-Google-Sender-Auth: bi58kQq144rVyX9EmM3He0r-6Ig Message-ID: Subject: Re: Regression on 10-RC5 with a multicast routing daemon From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= , "freebsd-net@freebsd.org" , "freebsd-current@freebsd.org" , Andre Oppermann X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 15:17:58 -0000 On 15 January 2014 03:34, Gleb Smirnoff wrote: [snip] > Damn, what a mess. I'd like to go towards absolutely unmodified packets > for the 11-release cycle. Well, now's the time to _start_ this. :-) Not 6 months before 11.0 :P -a From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 15:22:28 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8003140C; Wed, 15 Jan 2014 15:22:28 +0000 (UTC) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA5A1DF2; Wed, 15 Jan 2014 15:22:28 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id x13so1051416qcv.5 for ; Wed, 15 Jan 2014 07:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=toXs8X/mjlLuAZvCxGOvwX1MrPJqYPyWIVi05/SE6S4=; b=KCg+BFxyzBf9jQftiPHIQedot1uW6AEufdZE3ckiQRBY9vfcjCulLqk9xkaqu8Ti7J AQCIT8Rynd8y5e4OcS+7ztcm4MQf2T2XDUxEO+gJJfL26doasklbO//1UUbOHQwLc+WE lm8ZuMKDSr4IN1EXMPBRrdfAW6gVSPZRYVBeo4VP1sLoh09/goKwXCPIG/9L6jkn7RIE g2pg0Z+g/c+nqtRWN29i4KNHqOpvy7i6Zg2AYuI+jiVlnuIg9xuhjAPkctgoK4Km1ZFo 3D9+cnIgP2wjiHL+tAmcMu2rmwVWiFqF4xtACFnICOAJM+E0UpDeoUyM8vVALZ/yUdnC K+Wg== MIME-Version: 1.0 X-Received: by 10.49.28.65 with SMTP id z1mr5506500qeg.78.1389799347052; Wed, 15 Jan 2014 07:22:27 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Wed, 15 Jan 2014 07:22:27 -0800 (PST) In-Reply-To: <52D6525D.50102@FreeBSD.org> References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> Date: Wed, 15 Jan 2014 07:22:27 -0800 X-Google-Sender-Auth: Ns0i-3SwtKRQhXzGqW2mSW-OecQ Message-ID: Subject: Re: ECMP hash keys? From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 15:22:28 -0000 On 15 January 2014 01:18, Alexander V. Chernikov wrote: > On 14.01.2014 23:15, Nikolay Denev wrote: >> >> Hi, >> >> Currently it's implemented using Modulo-N Hash (RFC2991), see >> radix_mpath.c:rtalloc_mpath_fib() > > Yup. I'm going to change this to use flowid. > >> >> And as hash the xor of source and destination IP is supplied, look for >> rtalloc_mpath_fib() in ip_output.c : >> >> ... >> #ifdef RADIX_MPATH >> rtalloc_mpath_fib(ro, >> ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), >> inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); >> #else >> ... >> >> I've tried to hack this to use m_pkthdr.flowid if it exists, but in my >> case my network cards were not setting this (vr(4) on soekris) so I > > You can try http://static.ipfw.ru/patches/netisr_ip_flowid.diff to get > flowid values generated by netisr. Hm, this is interesting. I wonder if we should (finally) add in the toeplitz hash here and then make sure we are hashing the frame based on the right header contents and direction (so transmit and receive path frames hash to the same value.) What do you think? -a From owner-freebsd-net@FreeBSD.ORG Wed Jan 15 21:48:15 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73B65C39 for ; Wed, 15 Jan 2014 21:48:15 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3C44018BE for ; Wed, 15 Jan 2014 21:48:14 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s0FLjl7J042811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 15 Jan 2014 21:45:48 GMT Date: Wed, 15 Jan 2014 21:45:47 +0000 From: Karl Pielorz To: freebsd-net@freebsd.org Subject: LAST_ACK hanging around / reaping? Message-ID: <39BB47DB91A9375CDA87B5A2@study64.tdx.co.uk> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 15 Jan 2014 21:48:15 -0000 Hi, We've a number of FreeBSD 9.2 amd64 systems - recently we've noticed a large number of TCP sessions ending up stuck in 'LAST_ACK' (sometimes this can creep up to many thousands per box). Having dug around - it appears some kind of load balancer at the 'other ends' of these connections isn't handling connection closes too well or something [I don't think it's a FreeBSD issue - it looks like a 'them' issue]. The questions are a) Should we be concerned by constantly having several thousand connections in LAST_ACK b) Is there a sysctl to change how long they'll hang around for? And, more importantly, c) If the system needs these resources - will it reap some of them? (i.e. oldest first or something) - or could they potentially just keep growing in a worst case scenario until something runs out? Thanks, -Karl From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 03:14:09 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 332E81E4 for ; Thu, 16 Jan 2014 03:14:09 +0000 (UTC) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 803A014FC for ; Thu, 16 Jan 2014 03:14:07 +0000 (UTC) Received: from 172.24.2.119 (EHLO szxeml213-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOP65188; Thu, 16 Jan 2014 11:12:36 +0800 (CST) Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jan 2014 11:12:33 +0800 Received: from [127.0.0.1] (10.177.18.75) by szxeml421-hub.china.huawei.com (10.82.67.160) with Microsoft SMTP Server id 14.3.158.1; Thu, 16 Jan 2014 11:12:23 +0800 Message-ID: <52D74E15.1040909@huawei.com> Date: Thu, 16 Jan 2014 11:12:21 +0800 From: Wang Weidong User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Subject: netmap: I got some troubles with netmap Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.18.75] X-CFilter-Loop: Reflected Cc: freebsd-net@freebsd.org, Ding Tianhong X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 03:14:09 -0000 Hi Luigi, I learn netmap recently. I have some troubles and problems. Just below: ---------------------------------------------------------- My machine and the netmap and qemu version: netmap version: 20131019. qemu: 'git://git.qemu-project.org/qemu.git', v1.7 NIC hardware: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) PC: Suse x86_64 GNU/Linux, the kernel is suse-3.0.58 ---------------------------------------------------------- insmod netmap_lin.ko and ixgbe/ixgbe.ko problem 1: I only use ethtool -A eth2 autoneg/rx/tx off that I can get the speed up to 14.84 Mpps. Or, I only got 500 Kpps. I should do "ethtool -A"? problem 2: I turn intel_iommu=on. When I use pkt-gen -i eth2, I got failed. And the dmesg likes that: DRHD: handling fault status reg 202 DMAR:[DMA Read] Request device [03:00.0] fault addr 1f6bfbd000 Is that netmap no support IOMMU? Problem 3: "qemu-system-x86_64 -m 1024 -boot c -net nic -net netmap,ifname=vale0:1 -hda /home/disk/nm_d0 -enable-kvm -vnc :0", Use that command to start a vm. I test on the vm. #pkt-gen -i eth0 -f tx -l 60 -n 20000000, the speed is up to 1.02 Mpps. I do "vale-ctl -h vale0:eth2", then I test on the vm, the speed is up to 558.57 Kpps. While "vale-ctl -a vale0:eth2", the speed is up to 800 kpps. I did something wrong? ------ thanks, Wang From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 06:56:05 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9EFB2325 for ; Thu, 16 Jan 2014 06:56:05 +0000 (UTC) Received: from m12-12.163.com (m12-12.163.com [220.181.12.12]) by mx1.freebsd.org (Postfix) with ESMTP id 74D7013E0 for ; Thu, 16 Jan 2014 06:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Message-ID:From:Subject:Date:MIME-Version; bh=X1yyH sxOhtsBWb0972jCXZUvZL/BHTOhI7gQ5BsxH44=; b=a4+lSxzz4YfCTOb3Cd90D gZ6ycMFOx0KxYoRcp0qmy9RJRUSiZpAuVNEv1ENJCjoKiy2bTbGpdNNVAbt2kxKF yGkCuwmxFcZOBGDEdrXSf2hLQUTKNPshOBOUnhSA9/xJCh9RofsVzHiPRKy3vFwK 5p8S1sJ5DAXr08IZOhKpf4= Received: from duqh (unknown [113.111.194.204]) by smtp8 (Coremail) with SMTP id DMCowEBZy3R5gtdSSwuQCA--.752S4; Thu, 16 Jan 2014 14:55:55 +0800 (CST) Message-ID: From: "duqh" To: Subject: netmap with checksum offloading Date: Thu, 16 Jan 2014 14:55:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 X-CM-TRANSID: DMCowEBZy3R5gtdSSwuQCA--.752S4 X-Coremail-Antispam: 1Uf129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UbIYCTnIWIevJa73UjIFyTuYvjxUTksqUUUUU X-Originating-IP: [113.111.194.204] X-CM-SenderInfo: xgxtxiiwt6il2tof0z/1tbiPhsVb1D+QmEpTQAAs2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 06:56:05 -0000 SGksIGFsbDoNCm5ldG1hcCBpcyBhIGdyZWF0IHdvcmtzLCBpdCdzIHZlcnkgZmFzdC4NCldoZW4g aSBmb3VuZCB0aGUgTklDIChzdWNoIGFzIGludGVsIDgyNTc0TCkgaGFzIHRoZSBjaGVja3N1bSBv ZmZsb2FkaW5nIGZ1bmN0aW9ucywgYnV0IGhvdyBjYW4gaSB1c2VkIHRoZSBmdW5jdGlvbiB3aXRo IG5ldG1hcD8NCg0KdGhhbmtzIHZlcnkgbXVjaCENCg0KZHVxaA== From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 11:37:43 2014 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 442C1436; Thu, 16 Jan 2014 11:37:43 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 18E791E98; Thu, 16 Jan 2014 11:37:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s0GBbgiv094516; Thu, 16 Jan 2014 11:37:42 GMT (envelope-from melifaro@freefall.freebsd.org) Received: (from melifaro@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s0GBbgh4094515; Thu, 16 Jan 2014 11:37:42 GMT (envelope-from melifaro) Date: Thu, 16 Jan 2014 11:37:42 GMT Message-Id: <201401161137.s0GBbgh4094515@freefall.freebsd.org> To: melifaro@FreeBSD.org, freebsd-ipfw@FreeBSD.org, freebsd-net@FreeBSD.org From: melifaro@FreeBSD.org Subject: Re: kern/129036: [ipfw] 'ipfw fwd' does not change outgoing interface name X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 11:37:43 -0000 Synopsis: [ipfw] 'ipfw fwd' does not change outgoing interface name Responsible-Changed-From-To: freebsd-ipfw->freebsd-net Responsible-Changed-By: melifaro Responsible-Changed-When: Thu Jan 16 11:31:08 UTC 2014 Responsible-Changed-Why: Reclassify. This problem is not related to ipfw: ipfw(4) sets M_IP_NEXTHOP & adds PACKET_TAG_IPFORWARD on ingress and returns. ip_input() sees M_IP_NEXTHOP and passes packet to ip_forward() which performs routing decision and calls ip_output(). Finally, ip_ouput() calls PFIL hook with ifp determined by ip_forward() and checks M_IP_NEXTHOP _after_ that. http://www.freebsd.org/cgi/query-pr.cgi?pr=129036 From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 16:02:40 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D35FE5C2; Thu, 16 Jan 2014 16:02:40 +0000 (UTC) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE48A1A00; Thu, 16 Jan 2014 16:02:39 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id hr13so669111lab.15 for ; Thu, 16 Jan 2014 08:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YRJt/CgF1IBqjZpZ6gWkufEVUkRUQdJs8FQD0WC+Wzs=; b=YG610A2G7MvBekfOYFr/rSZu7+cOEo2NMrIxSlg28Tgqac+nkcJFGtZtHJZ7ayRx8M P/+bS0jMbn+DFb5x7yDxOA6WhbQHrb8/GuCGo2+tdVyT9eg7JIefIDDUlKUgT85KlyM+ EDdmbs+WbFihm0mUbXGeWufW7ftW2xp7WuBT1OH3Dxmw53TbaBjp/4+su+ohsPn+/bOx FHJuB58Tc+4uLnLkGboQlcOMPKx8gRzJQ+uW7Ugm3BbrsEO0w07X8zE6qwy9Gte4WRGF biODcnC463fT99vsB9q7chNb6yMANqO9ZvADnLu0SWHrFBjG1SLnpA/9dZrvT1NCNTis nbOg== MIME-Version: 1.0 X-Received: by 10.152.121.73 with SMTP id li9mr1423193lab.47.1389888157771; Thu, 16 Jan 2014 08:02:37 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.114.242.33 with HTTP; Thu, 16 Jan 2014 08:02:37 -0800 (PST) In-Reply-To: References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> Date: Thu, 16 Jan 2014 16:02:37 +0000 X-Google-Sender-Auth: ryqwKGMbD5dRQM07zGBvpptK0Ao Message-ID: Subject: Re: ECMP hash keys? From: Nikolay Denev To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 16:02:40 -0000 On Wed, Jan 15, 2014 at 3:22 PM, Adrian Chadd wrote: > On 15 January 2014 01:18, Alexander V. Chernikov wrote: >> On 14.01.2014 23:15, Nikolay Denev wrote: >>> >>> Hi, >>> >>> Currently it's implemented using Modulo-N Hash (RFC2991), see >>> radix_mpath.c:rtalloc_mpath_fib() >> >> Yup. I'm going to change this to use flowid. >> >>> >>> And as hash the xor of source and destination IP is supplied, look for >>> rtalloc_mpath_fib() in ip_output.c : >>> >>> ... >>> #ifdef RADIX_MPATH >>> rtalloc_mpath_fib(ro, >>> ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_addr), >>> inp ? inp->inp_inc.inc_fibnum : M_GETFIB(m)); >>> #else >>> ... >>> >>> I've tried to hack this to use m_pkthdr.flowid if it exists, but in my >>> case my network cards were not setting this (vr(4) on soekris) so I >> >> You can try http://static.ipfw.ru/patches/netisr_ip_flowid.diff to get >> flowid values generated by netisr. > > Hm, this is interesting. I wonder if we should (finally) add in the > toeplitz hash here and then make sure we are hashing the frame based > on the right header contents and direction (so transmit and receive > path frames hash to the same value.) > > What do you think? > > > -a Hi Adrian, Probably a stupid question, but I'm trying to understand more about this, so basically the benefit of using essentially an additive hash function would be that both directions of the same flow/connection would end up for processing on the same core? --Nikolay From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 16:03:12 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F339653 for ; Thu, 16 Jan 2014 16:03:12 +0000 (UTC) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F4AF1A08 for ; Thu, 16 Jan 2014 16:03:11 +0000 (UTC) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.14.7/8.14.7) with ESMTP id s0GFqtks058695 for ; Thu, 16 Jan 2014 09:52:56 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [127.0.0.1] (216-110-21-66.static.twtelecom.net [216.110.21.66]) by mail.shrew.net (Postfix) with ESMTPSA id 67291187E7E for ; Thu, 16 Jan 2014 09:52:50 -0600 (CST) Message-ID: <52D8005F.8070104@shrew.net> Date: Thu, 16 Jan 2014 09:53:03 -0600 From: Matthew Grooms User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: TCP socket handling lo[X], buggy in 9.x? References: <52D4E633.1060000@shrew.net> <20140114100612.GR8472@FreeBSD.org> In-Reply-To: <20140114100612.GR8472@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mx1.shrew.net [10.24.10.10]); Thu, 16 Jan 2014 09:52:56 -0600 (CST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 16:03:12 -0000 On 1/14/2014 4:06 AM, Gleb Smirnoff wrote: > Matthew, > > On Tue, Jan 14, 2014 at 01:24:35AM -0600, Matthew Grooms wrote: > M> It looks like the 9.2 host is sending a reset before sending every PDU. > M> Weird. In any case, this is really easy to re-produce. Anyone have an > M> idea as to why this started happening? I didn't try FreeBSD 10, but I > M> suspect the problem is the same. > > I failed to reproduce that on couple of FreeBSD 11 boxes. > Gleb, Thanks for the sanity check. I upgraded my vSphere ESXi host, and the problem went away. Maybe some esoteric bug with the vswitch. I can't explain it, and I was seeing the issue on two different VMs that were running 9.2-RELEASE-p2. Super weird. Thanks again, -Matthew From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 19:06:49 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B62A77E; Thu, 16 Jan 2014 19:06:49 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA7B61E3A; Thu, 16 Jan 2014 19:06:48 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id j5so2495585qaq.34 for ; Thu, 16 Jan 2014 11:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KKGatsn2qNXE54p+tgvmNEX0iut2nEaG927HOCVgVag=; b=uXoCU8bh2sbwzdv6V7by07ziNI9FpuP0125Ivjk3VbriJ3FIuaItNBEfAwfYw2aTBe SmJY1ulUzpD+2qktfPNBlk7T71wCkLQxG9RzJ9GDXioaoZO5aJFSJQGPAjYAfZPBRFxp 6qCm5Scdor9/NtQ1Fb/77F0eD5bANAI/TPuswgUwsPpYs8UIqvD7GfmdotcvmVBr/bQo cdD0biVJtwc7vWdRKk2ZtSHit7Q08r59ZtzZyxuoam6EOUQZLJldv0+b2leMYy/gdkmv 1wwAzr7hl03UqyWcMbyuYRBSsrLFYcFVEPGTnNtl6pZlTGuIQddXz11dxJKXFUmlRYFQ rWtg== MIME-Version: 1.0 X-Received: by 10.224.127.131 with SMTP id g3mr18678588qas.98.1389899207979; Thu, 16 Jan 2014 11:06:47 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 16 Jan 2014 11:06:47 -0800 (PST) In-Reply-To: References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> Date: Thu, 16 Jan 2014 11:06:47 -0800 X-Google-Sender-Auth: YZdX6-S288idk-sV-Rx0DRop9I4 Message-ID: Subject: Re: ECMP hash keys? From: Adrian Chadd To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 Cc: "Alexander V. Chernikov" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 19:06:49 -0000 On 16 January 2014 08:02, Nikolay Denev wrote: > Hi Adrian, > > Probably a stupid question, but I'm trying to understand more about this, > so basically the benefit of using essentially an additive hash function would be > that both directions of the same flow/connection would end up for > processing on the same core? Yes. For TCP workloads where you have a lot of shared state being changed in the transmit and receive direction, there's a _lot_ of lock contention going on all over the place. -a From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 20:28:39 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBB44728; Thu, 16 Jan 2014 20:28:39 +0000 (UTC) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C1A515AC; Thu, 16 Jan 2014 20:28:39 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id i11so3099659qej.28 for ; Thu, 16 Jan 2014 12:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=kqVwmanGwcd1AeA3L+3k/XPOonHxQuZpAx7hSNBYflg=; b=ob/9V3uagq1CACMtMUH7eU9sLDrdE1zyL8q8jEFLnkheWKsHDJXYZft5BvIXvU8rr4 zlK1unik4HbVP0zN5zippgaZ18q6HrL6g88hFQ8UHefNlLoqkrmG9FZRsfiTBiWQxYuJ a6l5GWOOX4G1Y1t1iUeyF2kL/W03bo4O9ePe4eCzpTUGEgfnMVZTZH1uMDGVufCktYop 3HY0m7PkNRiPp4NO1tLimQBSyR2PX9SFt0ehTYmEJbqQBEyo+4LfpvfOo095F0jDFBXA fW1RpsCP/iTrPb63nFwDB0pIRKrt+vMYiwlnz0f5456JxU+FxnxdUtwI1zVMSAyHcTQR WmKg== MIME-Version: 1.0 X-Received: by 10.229.122.195 with SMTP id m3mr19467158qcr.7.1389904118630; Thu, 16 Jan 2014 12:28:38 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 16 Jan 2014 12:28:38 -0800 (PST) Date: Thu, 16 Jan 2014 12:28:38 -0800 X-Google-Sender-Auth: l6Xtus_xKpTZTe7V0K7MzCHciIc Message-ID: Subject: [rfc] set inp_flowid on initial TCP connection From: Adrian Chadd To: FreeBSD Net , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 20:28:39 -0000 Hi, This patch sets the inp_flowid on incoming connections. Without this, the initial connection has no flowid, so things like the per-CPU TCP callwheel stuff would map to a different CPU on the initial incoming setup. -a Index: sys/netinet/tcp_syncache.c =================================================================== --- sys/netinet/tcp_syncache.c (revision 260499) +++ sys/netinet/tcp_syncache.c (working copy) @@ -722,6 +722,16 @@ #endif /* + * If there's an mbuf and it has a flowid, then let's initialise the + * inp with that particular flowid. + */ + if (m != NULL && m->m_flags & M_FLOWID) { + inp->inp_flags |= INP_HW_FLOWID; + inp->inp_flags &= ~INP_SW_FLOWID; + inp->inp_flowid = m->m_pkthdr.flowid; + } + + /* * Install in the reservation hash table for now, but don't yet * install a connection group since the full 4-tuple isn't yet * configured. From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 21:08:01 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42811386; Thu, 16 Jan 2014 21:08:01 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6FC8193F; Thu, 16 Jan 2014 21:08:00 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id h16so3081271oag.30 for ; Thu, 16 Jan 2014 13:07:59 -0800 (PST) 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=Up8yVxEtAI18pLKmlXBIrBwgF8GPnHnkZK2L1Os3Mko=; b=erQWD1iy2/sX7yyD50M+j7MynDtWKNasKxXCdV63uji+eo7RZV8+gi63xJDFYFdKxs yTa5wZjM7g0+zm5ZEdcGXAqtTryNdKtEUSkQFBBt/0Ny2reCN8yCAlLxSCZbOruNW+uC lnSEtX0wRPGQ9ktGA2nVrwUFi9Qdp9AisifzP94RGID+jxRU4brdiVcJRUVMUPggaGef jckgfAf8x3SfqSSQCkAUZ+cLI4pbfqKRpYyyw3BwdKJYwGvkQ6TUOhU+nAeb+n1kyWSd zZle2v9yGCWaXOpwosJ6wqFSoEumVe7zlNG3jFLGWMXI9NgG0r0xNg1DlowSBZ7/g+OF 6NEw== MIME-Version: 1.0 X-Received: by 10.60.52.14 with SMTP id p14mr9078522oeo.28.1389906479769; Thu, 16 Jan 2014 13:07:59 -0800 (PST) Received: by 10.182.153.65 with HTTP; Thu, 16 Jan 2014 13:07:59 -0800 (PST) In-Reply-To: References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> Date: Thu, 16 Jan 2014 13:07:59 -0800 Message-ID: Subject: Re: ECMP hash keys? From: Vijay Singh To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , "Alexander V. Chernikov" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 21:08:01 -0000 FYI, there is a Toeplitz hash function that gnn is reviewing for me and should be in the system soon. It would be used in the PCBGROUP framework when the hash needs to be generated in SW. On Wed, Jan 15, 2014 at 7:22 AM, Adrian Chadd wrote: > On 15 January 2014 01:18, Alexander V. Chernikov > wrote: > > On 14.01.2014 23:15, Nikolay Denev wrote: > >> > >> Hi, > >> > >> Currently it's implemented using Modulo-N Hash (RFC2991), see > >> radix_mpath.c:rtalloc_mpath_fib() > > > > Yup. I'm going to change this to use flowid. > > > >> > >> And as hash the xor of source and destination IP is supplied, look for > >> rtalloc_mpath_fib() in ip_output.c : > >> > >> ... > >> #ifdef RADIX_MPATH > >> rtalloc_mpath_fib(ro, > >> ntohl(ip->ip_src.s_addr ^ > ip->ip_dst.s_addr), > >> inp ? inp->inp_inc.inc_fibnum : > M_GETFIB(m)); > >> #else > >> ... > >> > >> I've tried to hack this to use m_pkthdr.flowid if it exists, but in my > >> case my network cards were not setting this (vr(4) on soekris) so I > > > > You can try http://static.ipfw.ru/patches/netisr_ip_flowid.diff to get > > flowid values generated by netisr. > > Hm, this is interesting. I wonder if we should (finally) add in the > toeplitz hash here and then make sure we are hashing the frame based > on the right header contents and direction (so transmit and receive > path frames hash to the same value.) > > What do you think? > > > -a > _______________________________________________ > 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 Jan 16 21:23:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 539949A7; Thu, 16 Jan 2014 21:23:34 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 102DB1A98; Thu, 16 Jan 2014 21:23:34 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1W3qZh-000CQ9-8y; Thu, 16 Jan 2014 21:17:49 +0400 Message-ID: <52D84DB0.4050607@FreeBSD.org> Date: Fri, 17 Jan 2014 01:22:56 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ECMP hash keys? References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2GFKVBXUUGERNTGMEWDIW" Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 21:23:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GFKVBXUUGERNTGMEWDIW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 15.01.2014 19:22, Adrian Chadd wrote: > On 15 January 2014 01:18, Alexander V. Chernikov = wrote: >> On 14.01.2014 23:15, Nikolay Denev wrote: >>> >>> Hi, >>> >>> Currently it's implemented using Modulo-N Hash (RFC2991), see >>> radix_mpath.c:rtalloc_mpath_fib() >> >> Yup. I'm going to change this to use flowid. >> >>> >>> And as hash the xor of source and destination IP is supplied, look fo= r >>> rtalloc_mpath_fib() in ip_output.c : >>> >>> ... >>> #ifdef RADIX_MPATH >>> rtalloc_mpath_fib(ro, >>> ntohl(ip->ip_src.s_addr ^ ip->ip_dst.s_a= ddr), >>> inp ? inp->inp_inc.inc_fibnum : M_GETFIB= (m)); >>> #else >>> ... >>> >>> I've tried to hack this to use m_pkthdr.flowid if it exists, but in m= y >>> case my network cards were not setting this (vr(4) on soekris) so I >> >> You can try http://static.ipfw.ru/patches/netisr_ip_flowid.diff to get= >> flowid values generated by netisr. >=20 > Hm, this is interesting. I wonder if we should (finally) add in the > toeplitz hash here and then make sure we are hashing the frame based > on the right header contents and direction (so transmit and receive > path frames hash to the same value.) I'm not sure I understand. What workload we are talking about? For pure routing we don't need both ends of TCP session to land on the same CPU core. For doing (transparent?) stateul firewalling - maybe, but that's not the default. Additionally, most (and all 10G) NICs already perform hashing (and toeplitz which is implemented in most? of them does not provide the same hash for forward/reverse packets of given session). We can do re-mark here, but that require us to: * do deferred netisr probably decrementing number of RX rings in every NI= C * improve netist (maybe, add batching and/or lockless queueing) That's definitely not the default, too. For server terminating connections - we can just save flowid of initial connection and that's all. I'm not sure we require hash(src,dst) to be equal to hash(dst,src) So, if you really want hashing function with this additional restriction - than we should add some more sysctls/tunables to netisr to be able to select several different flowid functions for given family (nearly like what is done for TCP CCs). Anyway, we really should add _some_ hashing function for IPv4/IPv6. >=20 > What do you think? >=20 >=20 > -a >=20 ------enig2GFKVBXUUGERNTGMEWDIW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLYTbUACgkQwcJ4iSZ1q2lsfQCePK/bMgOmx/fe1DatUBcv9y93 Ds8AnAoZe2aQ5qorZXjM1yvvzewNV9TC =atI4 -----END PGP SIGNATURE----- ------enig2GFKVBXUUGERNTGMEWDIW-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 16 22:08:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C282543F; Thu, 16 Jan 2014 22:08:45 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E5F31E73; Thu, 16 Jan 2014 22:08:45 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id f11so2693582qae.35 for ; Thu, 16 Jan 2014 14:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7lZl3tpcUf/WoEjPipNCAkh1pjyr1JCw8GlS+DaTiRQ=; b=J/6speF8KF+i/4Ulr/eUyXkQHAhzmYo6kxOYNKgwflyqvg6XV0IZZfbwYhzdA9gO0u WF2EMmOg36AbJu3XWLh2aG6nkSZ3DAWoAHwaxwv240rAL0G4mr7f0gQwsXuJ/JFGm2nZ wmSF69MRTUofnjDlZrNDosWHE0nQmSJ7OTLLDRqTy2jhnElLOOFs/eC/4IVxTlISD5Gx B5/prznu5Ot0NN2gCf13CKmLN/rqmLQGrZparZih6FzFARxTvbahB3jjThFVnSR60yp2 55Mme44W2xXOSZ7wl0L0toTGCpywkXHxBCv5gpjnyAo9jnll5bMjvNVTbF/N5QZyZaM1 92cw== MIME-Version: 1.0 X-Received: by 10.140.42.180 with SMTP id c49mr12426566qga.24.1389910124727; Thu, 16 Jan 2014 14:08:44 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Thu, 16 Jan 2014 14:08:44 -0800 (PST) In-Reply-To: <52D84DB0.4050607@FreeBSD.org> References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> <52D84DB0.4050607@FreeBSD.org> Date: Thu, 16 Jan 2014 14:08:44 -0800 X-Google-Sender-Auth: ukwbSwh_n1sSECOxNLwMvZXs40g Message-ID: Subject: Re: ECMP hash keys? From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 16 Jan 2014 22:08:45 -0000 The reason you need to make sure that you end up with hashes for both src,dst and dst,src being equivalent is to ensure that when you create an outbound socket, you know up front which path the receive path is going to come back on. Right now we don't mark new connections - inbound or outbound - with a flowid until we've received some data on it. It's also going to be eventually useful for the pcbgroup stuff, as vijay has said. -a From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 03:47:18 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCBA2547 for ; Fri, 17 Jan 2014 03:47:18 +0000 (UTC) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CCB01866 for ; Fri, 17 Jan 2014 03:47:16 +0000 (UTC) Received: from 172.24.2.119 (EHLO szxeml213-edg.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id AJJ80940; Fri, 17 Jan 2014 11:40:18 +0800 (CST) Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Jan 2014 11:40:13 +0800 Received: from [127.0.0.1] (10.177.18.75) by szxeml415-hub.china.huawei.com (10.82.67.154) with Microsoft SMTP Server id 14.3.158.1; Fri, 17 Jan 2014 11:40:09 +0800 Message-ID: <52D8A5E1.9020408@huawei.com> Date: Fri, 17 Jan 2014 11:39:13 +0800 From: Wang Weidong User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?windows-1252?Q?facolt=E0?= Subject: Re: netmap: I got some troubles with netmap References: <52D74E15.1040909@huawei.com> <92C7725B-B30A-4A19-925A-A93A2489A525@iet.unipi.it> In-Reply-To: <92C7725B-B30A-4A19-925A-A93A2489A525@iet.unipi.it> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.177.18.75] X-CFilter-Loop: Reflected Cc: Luigi Rizzo , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 03:47:18 -0000 On 2014/1/16 18:24, facoltā wrote: > Hi Wang, > > I work with Luigi, please check the replies below. > > > Il giorno 16/gen/2014, alle ore 04:53, Luigi Rizzo > ha scritto: > >> >> [...] >> Problem 3: >> "qemu-system-x86_64 -m 1024 -boot c -net nic -net netmap,ifname=vale0:1 -hda /home/disk/nm_d0 >> -enable-kvm -vnc :0", Use that command to start a vm. >> >> I test on the vm. >> #pkt-gen -i eth0 -f tx -l 60 -n 20000000, >> the speed is up to 1.02 Mpps. > >> >> I do "vale-ctl -h vale0:eth2", then I test on the vm, the speed is up to 558.57 Kpps. >> While "vale-ctl -a vale0:eth2", the speed is up to 800 kpps. >> > > The number you obtain in the first test is quite low. vale-ctl -h vale0:eth2 connects the host stack, which is very slow, so ~500 Kpps is not unexpected. I don’t know about the third test at the moment, I have to check. > > What version of our modified qemu are you using? Please note that there might be a qemu patch in the netmap sources, but that is only a leftover from our first attempts, so you should not use that. > Here, I use the qemu is from 'git clone git://git.qemu-project.org/qemu.git' origin/master and the commit is f976b09ea249 ("PPC: Fix compilation with TCG debug"). The netmap is submit into the qemu in commit 58952137b0("net: Adding netmap network backend"). Is the version I used is not right? Because of the netmap-20131019 doesn't support qemu, so I find the newest qemu. Although, I try to use the netmap-20120813 which support qemu, and download the qemu-1.0.1 from http://wiki.qemu-project.org/download/, then I patch the patch-zz-netmap-1 and copy the qemu-netmap to the qemu. I test the "pkt-gen -i eth0 -f tx -l 60 -n 20000000" on the vm, (the pkt-gen is from netmap-20131019) And the speed is unsteadily, sometimes up to 2Mpps or 1.44, and avg is 1.74Mpps. But when I use "./bridge -i vale0:eth2" on the host, then test "pkt-gen -i eth0 -f tx -l 60 -n 20000000" on the vm, I got a NULL pointer dereference BUG that: -------------- [ 2313.454871] BUG: unable to handle kernel NULL pointer dereference at (null) [ 2313.547751] IP: [] get_rps_cpu+0x44/0x390 [ 2313.613802] PGD 1f7cbe5067 PUD 1f7d792067 PMD 0 [ 2313.668509] Oops: 0000 [#1] SMP [ 2313.706703] CPU 0 [ 2313.728373] Modules linked in: ixgbe(N) netmap_lin(N) edd(N) bridge(N) stp(N) llc(N) mperf(N) microcode(N) fuse(N) loop(N) dm_mod(N) vhost_net(N) macvtap(N) macvlan(N) tun(N) kvm_intel(N) sg(N) i2c_i801(N) ipv6(N) kvm(N) ipv6_lib(N) i2c_core(N) i7core_edac(N) mptctl(N) iTCO_wdt(N) igb(N) pcspkr(N) edac_core(N) rtc_cmos(N) serio_raw(N) iTCO_vendor_support(N) mdio(N) dca(N) button(N) ext3(N) jbd(N) mbcache(N) usbhid(N) hid(N) uhci_hcd(N) ehci_hcd(N) usbcore(N) usb_common(N) sd_mod(N) crc_t10dif(N) processor(N) thermal_sys(N) hwmon(N) scsi_dh_alua(N) scsi_dh_hp_sw(N) scsi_dh_rdac(N) scsi_dh_emc(N) scsi_dh(N) ata_generic(N) ata_piix(N) libata(N) mptsas(N) mptscsih(N) mptbase(N) scsi_transport_sas(N) scsi_mod(N) [last unloaded: ixgbe] [ 2314.498465] Supported: Yes [ 2314.530455] [ 2314.548001] Pid: 10708, comm: bridge Tainted: G N 3.0.58-0.6.6-default #2 Huawei Technologies Co., Ltd. Tecal XH620 /BC21THSA [ 2314.718261] RIP: 0010:[] [] get_rps_cpu+0x44/0x390 [ 2314.813196] RSP: 0018:ffff881f5af75928 EFLAGS: 00010246 [ 2314.876137] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 2314.960745] RDX: ffff881f5af75990 RSI: ffff881f5b1da480 RDI: ffff881f59098000 [ 2315.045354] RBP: ffff881f5b1da480 R08: 0000000000000000 R09: 0000000000000004 [ 2315.129963] R10: 0000000080042000 R11: 0000000000000001 R12: ffff881f59098000 [ 2315.214570] R13: ffff881f7a480000 R14: ffff881f5b1da480 R15: 00000000000003ff [ 2315.299179] FS: 00007f948e25c700(0000) GS:ffff88203f200000(0000) knlGS:0000000000000000 [ 2315.395135] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2315.463237] CR2: 0000000000000000 CR3: 0000001f7bb55000 CR4: 00000000000026e0 [ 2315.547845] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2315.632454] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 2315.717064] Process bridge (pid: 10708, threadinfo ffff881f5af74000, task ffff881f5903a3c0) [ 2315.816120] Stack: [ 2315.839856] ffff881f5af7598f 0000000000000258 ffff881f81aa1280 ffffffff8137ed57 [ 2315.927586] ffff881f5af75990 0000000000000000 ffff881f5b1da480 0000000000000296 [ 2316.015317] ffff881f7a480000 ffff881f5b1da480 00000000000003ff ffffffff8138e998 [ 2316.103044] Call Trace: [ 2316.131948] [] netif_rx+0xf8/0x190 [ 2316.191799] [] netmap_sync_to_host+0x1de/0x2b0 [netmap_lin] [ 2316.277452] [] netmap_poll+0x495/0x610 [netmap_lin] [ 2316.354846] [] do_poll+0x115/0x2a0 [ 2316.414696] [] do_sys_poll+0x18e/0x200 [ 2316.478676] [] sys_poll+0x66/0x100 [ 2316.538526] [] system_call_fastpath+0x16/0x1b [ 2316.609726] [<00007f948d7724bf>] 0x7f948d7724be [ 2316.664418] Code: 24 40 49 89 fc 4c 89 74 24 48 4c 89 7c 24 50 48 89 54 24 20 0f b7 86 ac 00 00 00 66 85 c0 0f 85 d3 00 00 00 48 8b 9f d8 02 00 00 <4c> 8b 2b 4d 85 ed 0f 84 83 01 00 00 41 83 7d 00 01 0f 84 05 01 [ 2316.888727] RIP [] get_rps_cpu+0x44/0x390 [ 2316.955804] RSP ------------------------- As you point out that I shouldn't use these old version. So the BUG not occured in the netmap-20131019 and qemu-newest which integrated the netmap-backend. Btw, how can I use the bridge command for testing? Thanks, Wang > Cheers, > Giuseppe > >> I did something wrong? >> ------ >> >> thanks, >> >> Wang >> >> >> >> >> >> >> -- >> -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> -----------------------------------------+------------------------------- > From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 03:49:38 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73CB45F7 for ; Fri, 17 Jan 2014 03:49:38 +0000 (UTC) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A71D187E for ; Fri, 17 Jan 2014 03:49:36 +0000 (UTC) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOS67980; Fri, 17 Jan 2014 11:49:27 +0800 (CST) Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Jan 2014 11:49:23 +0800 Received: from [127.0.0.1] (10.177.18.231) by szxeml409-hub.china.huawei.com (10.82.67.136) with Microsoft SMTP Server id 14.3.158.1; Fri, 17 Jan 2014 11:49:20 +0800 Message-ID: <52D8A83E.5090201@huawei.com> Date: Fri, 17 Jan 2014 11:49:18 +0800 From: Yang Yingliang User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Luigi Rizzo Subject: BUG_ON triggered by igb driver in latest kernel Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.18.231] X-CFilter-Loop: Reflected Cc: freebsd-net@freebsd.org, dingtianhong@huawei.com X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 03:49:38 -0000 Hi, I use netmap with igb card in kernel 3.13-rc7, it triggered a bug_on. The reason is that the patch "diff--igb--30b00--99999" remove the napi_disable() in igb_down(). When netmap calls igb_up()->napi_enable(), a bug_on is triggered. ----------------------------------------------------------------------- Here is the calltrace: PANIC: "kernel BUG at include/linux/netdevice.h:502!" PID: 3200 TASK: ffff880069490410 CPU: 0 COMMAND: "pkt-gen" #0 [ffff880069493a00] machine_kexec at ffffffff81033c1d #1 [ffff880069493a50] crash_kexec at ffffffff810ad5a3 #2 [ffff880069493b20] oops_end at ffffffff81434650 #3 [ffff880069493b50] die at ffffffff81005716 #4 [ffff880069493b80] do_trap at ffffffff814341dc #5 [ffff880069493bd0] do_invalid_op at ffffffff81003540 #6 [ffff880069493c70] invalid_op at ffffffff8143ace8 [exception RIP: igb_up+344] RIP: ffffffffa030ed88 RSP: ffff880069493d28 RFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88007ac22840 RCX: 0000000000000000 RDX: ffff880037fbdc60 RSI: ffff88007ac22840 RDI: 0000000000000002 RBP: ffff880069493d38 R8: 0000000000000000 R9: 0000000000000006 R10: 000000000000000a R11: 0000000000000006 R12: ffff88007ac22000 R13: ffff8800377e7800 R14: ffff88007ac22840 R15: 0000000000000001 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff880069493d20] igb_up at ffffffffa030ec41 [igb] #8 [ffff880069493d40] igb_netmap_reg at ffffffffa030fa0d [igb] #9 [ffff880069493d80] netmap_do_regif at ffffffffa02d3915 [netmap_lin] #10 [ffff880069493dc0] linux_netmap_ioctl at ffffffffa02d4628 [netmap_lin] #11 [ffff880069493eb0] do_vfs_ioctl at ffffffff81143d84 #12 [ffff880069493f30] sys_ioctl at ffffffff811442a1 #13 [ffff880069493f80] system_call_fastpath at ffffffff81439c62 From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 09:50:33 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AC5A5C8 for ; Fri, 17 Jan 2014 09:50:33 +0000 (UTC) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF5C1145 for ; Fri, 17 Jan 2014 09:50:32 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 89DA03A82CA; Fri, 17 Jan 2014 10:50:23 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 11.6024] X-CRM114-CacheID: sfid-20140117_10501_8A60406E X-CRM114-Status: Good ( pR: 11.6024 ) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Jan 17 10:50:23 2014 X-DSPAM-Confidence: 0.9923 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 52d8fcdf486711946516935 X-DSPAM-Factors: 27, the+port, 0.00406, the+port, 0.00406, fixes, 0.00439, inet, 0.00439, From*"Nagy, Attila" , 0.00527, Received*online.co.hu+[195.228.243.99]), 0.00657, Received*[195.228.243.99]), 0.00657, Received*online.co.hu, 0.00657, the+host, 0.00657, Received*(japan.t, 0.00657, Received*(japan.t+online.co.hu, 0.00657, at+09, 0.00751, 17+08, 0.00875, Received*from+japan.t, 0.00875, but+I'm, 0.00875, Received*online.private+(japan.t, 0.00875, 17+09, 0.00875, 17+09, 0.00875, Received*japan.t+online.private, 0.00875, Received*japan.t, 0.00875, the+machine, 0.00953, 9a, 0.01000, 9a, 0.01000, fe80, 0.01000, mtu, 0.01000, mtu, 0.01000, X-Spambayes-Classification: ham; 0.00 Received: from japan.t-online.private (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id AA7E13A82BD for ; Fri, 17 Jan 2014 10:50:16 +0100 (CET) Message-ID: <52D8FCD4.2040900@fsn.hu> Date: Fri, 17 Jan 2014 10:50:12 +0100 From: "Nagy, Attila" MIME-Version: 1.0 To: FreeBSD Net Subject: lagg member interfaces don't come back after cable pull Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 09:50:33 -0000 Hi, Running stable/9@r260621, multiple (currently two) igb's connected to multiple Cisco Nexus 2ks, forming an LACP port channel. If I pull one of the cables from the switch, the port immediately goes down, and removed from the port channel. Everything works nicely. When I reconnect the cable, the member interface (igb1) remains down. On the host side, I see: igb1: flags=8843 metric 0 mtu 1500 options=401bb ether ac:16:2d:9a:18:cd nd6 options=29 media: Ethernet autoselect status: no carrier igb2: flags=8843 metric 0 mtu 1500 options=401bb ether ac:16:2d:9a:18:cd nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active admin: flags=8843 metric 0 mtu 1500 options=401bb ether ac:16:2d:9a:18:cd inet6 fe80::ae16:2dff:fe9a:18cd%admin prefixlen 64 tentative scopeid 0x9 inet 172.27.79.74 netmask 0xffffff00 broadcast 172.27.79.255 nd6 options=29 media: Ethernet autoselect status: active laggproto lacp lagghash l2,l3,l4 laggport: igb2 flags=1c laggport: igb1 flags=0<> Issuing an ifconfig down and up on igb1 fixes the problem, it gets back into the port channel. On the switch side I can see the following: 2014 Jan 17 08:58:11 DP1106-A05-11-N5K %ETH_PORT_CHANNEL-5-PORT_UP: port-channel6: Ethernet109/1/47 is up 2014 Jan 17 09:20:42 DP1106-A05-11-N5K %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel6: Ethernet109/1/47 is down 2014 Jan 17 09:31:52 DP1106-A05-11-N5K %ETH_PORT_CHANNEL-5-PORT_UP: port-channel6: Ethernet109/1/47 is up The cable was pulled at 09:20:42 and was reconnected in some seconds. ifconfig down and up was issued around 09:31:52, which fixed the access. From what I see it may be just the igb and not really connected to lagg, but I'm not sure and the machine is far away, so testing is not so easy. From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 19:17:08 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E2BABFA for ; Fri, 17 Jan 2014 19:17:08 +0000 (UTC) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC39D117F for ; Fri, 17 Jan 2014 19:17:07 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id 11so1760837vbe.10 for ; Fri, 17 Jan 2014 11:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=4j7q+NL347gXrWEmJZbxW2fCflx8wRbTLuZX4IiOQC0=; b=crLabw7XJ+IGLW2BOuffHPDswvks+5S/G3RM3icXvPmSepXc0mIQ8IUuJjoAxcAnCe iUnmVBjPDMewnsVjJSjt1UK2N2d1khxj0lOOjtbpOM6fvqHt4MKjO2pfPR7nWksaozy7 JefrBudwg49r2EQitxIooBRWRRplo6JoRefnCby4a/KgjurDZQDI6ULIuIlqElR5gOQF /2P6Wbh/Mg/CsnlKHad7jw1Qar+VtFoHSvfEIk4fGeS/S3Iji/qRFgPrJqBVY9ynyuK8 EMbgJVjQOACN/Gv7cjOJfhGNwxDtmwv3ZJE6uRkbBe74zDX3kMr/bJ1+/YtcwGeJL8cd j8BA== X-Received: by 10.52.117.176 with SMTP id kf16mr1470866vdb.6.1389986226859; Fri, 17 Jan 2014 11:17:06 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.171.1 with HTTP; Fri, 17 Jan 2014 11:16:46 -0800 (PST) In-Reply-To: References: From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 17 Jan 2014 20:16:46 +0100 X-Google-Sender-Auth: k5XDxN-16U_0tDzWiXTH1okpUkM Message-ID: Subject: Re: Problems with netmap pkt-gen (ip range and packet counter) To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 19:17:08 -0000 On Mon, Dec 23, 2013 at 11:16 AM, Olivier Cochard-Labb=E9 wrote: > > My second problem is with the latest -current version of pkt-gen only: Th= e > first time (and only the first time) I'm using the pk-gen in sender mode > with a max number of packet (-n option) to send: It doesn't stop and > doesn't exit automatically when counter is reached. > > > I've added some DEBUG messages to the pkt-gen code and found an infinite loop when it wait all the TX queues to be empty at "nm_tx_pending(txring)". (etc..) main_thread [1397] 12829932 pps (12842762 pkts in 1001000 usec) main_thread [1397] 12829621 pps (12842463 pkts in 1001001 usec) main_thread [1397] 12835472 pps (12861092 pkts in 1001996 usec) main_thread [1397] 12834919 pps (13078782 pkts in 1019000 usec) sender_body [1040] [DEBUG] End for while sent < n sender_body [1043] [DEBUG] End flush remaining packets sender_body [1048] [DEBUG] wait for TX queue 0 be empty... main_thread [1397] 8271783 pps (8797049 pkts in 1063501 usec) main_thread [1397] 0 pps (0 pkts in 1007501 usec) main_thread [1397] 0 pps (0 pkts in 1063499 usec) (etc....) From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 20:03:54 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45E1CE2D for ; Fri, 17 Jan 2014 20:03:54 +0000 (UTC) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D090715BD for ; Fri, 17 Jan 2014 20:03:53 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id q10so1156278ead.24 for ; Fri, 17 Jan 2014 12:03:10 -0800 (PST) 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:content-transfer-encoding; bh=OYFDDy8MiT+UEw7haQ+008ZBh1biiVXj9KJMmoPrftI=; b=ZE/cU+mseaTUVT7ENpjXHrLRCoUc6vjWC5Zt/hIY7AaZHTnMm61M1XQOxaQN/GraIR lsDtd4OMJrboP1ilWM5dfK9MZWENoEaYhppolY0cohhv4hI7i1AhDnI7hXGmc0U9PrSQ pWBzEvUFUc1EQgEs9Zf2JF0gkLMTjEafKSb3KKFJ0S3Gg9/Ty685HgVAjNctff88ZpE1 UHNpaD9HJ9DCcD2tpz0qcN6vr5UGsqCBj5hMEbVc5SX7Q9ekX4c59joCf1LqCXhJ0dxr aypx2Er03Vbtj8qU1P00DgOK+gYT7uiTFep1yM9vIe1/bPFJPIPH+XW3v9FAo1qNsz1k +NGQ== MIME-Version: 1.0 X-Received: by 10.15.74.200 with SMTP id j48mr4561835eey.102.1389988990738; Fri, 17 Jan 2014 12:03:10 -0800 (PST) Received: by 10.14.2.66 with HTTP; Fri, 17 Jan 2014 12:03:10 -0800 (PST) In-Reply-To: References: Date: Fri, 17 Jan 2014 12:03:10 -0800 Message-ID: Subject: Re: Problems with netmap pkt-gen (ip range and packet counter) From: hiren panchasara To: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 20:03:54 -0000 On Fri, Jan 17, 2014 at 11:16 AM, Olivier Cochard-Labb=C3=A9 wrote: > On Mon, Dec 23, 2013 at 11:16 AM, Olivier Cochard-Labb=C3=A9 > wrote: > >> >> My second problem is with the latest -current version of pkt-gen only: T= he >> first time (and only the first time) I'm using the pk-gen in sender mode >> with a max number of packet (-n option) to send: It doesn't stop and >> doesn't exit automatically when counter is reached. >> >> >> > I've added some DEBUG messages to the pkt-gen code and found an infinite > loop when it wait all the TX queues to be empty at "nm_tx_pending(txring)= ". > > > (etc..) > main_thread [1397] 12829932 pps (12842762 pkts in 1001000 usec) > main_thread [1397] 12829621 pps (12842463 pkts in 1001001 usec) > main_thread [1397] 12835472 pps (12861092 pkts in 1001996 usec) > main_thread [1397] 12834919 pps (13078782 pkts in 1019000 usec) > sender_body [1040] [DEBUG] End for while sent < n > sender_body [1043] [DEBUG] End flush remaining packets > sender_body [1048] [DEBUG] wait for TX queue 0 be empty... > main_thread [1397] 8271783 pps (8797049 pkts in 1063501 usec) > main_thread [1397] 0 pps (0 pkts in 1007501 usec) > main_thread [1397] 0 pps (0 pkts in 1063499 usec) > (etc....) Appears to me that main_thread() doesn't have a terminating condition based on g.npackets (number of packets to send). Only condition seems to be: if (done =3D=3D g->nthreads) break; Can we add if (npkts >=3D g.npackets) then break? Would that work? cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 20:18:26 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB9A733D for ; Fri, 17 Jan 2014 20:18:26 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 9A53516B2 for ; Fri, 17 Jan 2014 20:18:25 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id F37957300A; Fri, 17 Jan 2014 21:20:50 +0100 (CET) Date: Fri, 17 Jan 2014 21:20:50 +0100 From: Luigi Rizzo To: Olivier Cochard-Labb? Subject: Re: Problems with netmap pkt-gen (ip range and packet counter) Message-ID: <20140117202050.GC62555@onelab2.iet.unipi.it> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 20:18:26 -0000 On Fri, Jan 17, 2014 at 08:16:46PM +0100, Olivier Cochard-Labb? wrote: > On Mon, Dec 23, 2013 at 11:16 AM, Olivier Cochard-Labb? > wrote: > > > > > My second problem is with the latest -current version of pkt-gen only: The > > first time (and only the first time) I'm using the pk-gen in sender mode > > with a max number of packet (-n option) to send: It doesn't stop and > > doesn't exit automatically when counter is reached. sorry if i forgot to answer: if there is a difference between the first and subsequent run it is possibly a memory initialization problem. cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 20:48:34 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D07CEAF9; Fri, 17 Jan 2014 20:48:34 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9011418CE; Fri, 17 Jan 2014 20:48:34 +0000 (UTC) Received: from secured.by.ipfw.ru ([95.143.220.47] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1W4CVL-000Lri-GC; Fri, 17 Jan 2014 20:42:47 +0400 Message-ID: <52D996FD.6090901@FreeBSD.org> Date: Sat, 18 Jan 2014 00:47:57 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130728 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: ECMP hash keys? References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> <52D84DB0.4050607@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 20:48:34 -0000 On 17.01.2014 02:08, Adrian Chadd wrote: > The reason you need to make sure that you end up with hashes for both > src,dst and dst,src being equivalent is to ensure that when you create > an outbound socket, you know up front which path the receive path is > going to come back on. Right now we don't mark new connections - > inbound or outbound - with a flowid until we've received some data on > it. Well, this seems reasonable. However, how do you plan to interact with hardware RSS? For example, currently Intel used to set flowid to cpu number (which can be reasonable in some cases). Afair 82599 advanced RX descriptor contains original value that can be extracted, but we can't change cpu on which packet arrives on (well, we can reprogram indirection table, but..) I can't see any easy way to accomplish custom SW RSS: We can possibly have 1-2-4 ingress HW queues per NIC, ignore driver flowid, re-calculate with modified Toeplitz or similar and push to other ncpu-1 neisr queues. That can work, but requires custom setup (especially for lagg scenarios) and works well for small subset of workloads. It seems also guessing ingress flowid is not very much different between symmetric and asymmetric hashing approaches. > > It's also going to be eventually useful for the pcbgroup stuff, as > vijay has said. > > > -a > From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 20:50:18 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78444BC4 for ; Fri, 17 Jan 2014 20:50:18 +0000 (UTC) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 321B418DE for ; Fri, 17 Jan 2014 20:50:18 +0000 (UTC) Received: by mail-vb0-f42.google.com with SMTP id i3so1382707vbh.1 for ; Fri, 17 Jan 2014 12:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=VSnXkWfJYtPUV5AiPoyFVwpQEkTGpt83+qqNC/BBLIw=; b=eZ+4xElwpNPy6OaHvNx2OWNhGxHnUlwc0frjpEUPJqpsSvO3PcTpXURh5b2MI1LUDD 3VTaZlGKT9e1lmTOrceJZev1uf3lhenlWFvyPSKhVlGA5OE2GadwEiv1SkOAKw//UVIM w5gh20dAMaLgyhbZW652I6g7LnMJJNkfIiDlnv8epnPo2D2tlsfGP6mA7tS0XOPz3FnA T9EuxNUFxq9izIihrCt621p0jOOw/fu1P9Qs9+phZUUcQt28QmNePWha06fnXDom9wPF z1Ul9fBYBTZfZY084en27jtRrvcx/n/3txWgqXeLlMZ+TMGhgV310AmAoG4iJKBI7pAr hJhg== X-Received: by 10.58.6.239 with SMTP id e15mr2033863vea.14.1389991817259; Fri, 17 Jan 2014 12:50:17 -0800 (PST) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.58.171.1 with HTTP; Fri, 17 Jan 2014 12:49:57 -0800 (PST) In-Reply-To: <20140117202050.GC62555@onelab2.iet.unipi.it> References: <20140117202050.GC62555@onelab2.iet.unipi.it> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 17 Jan 2014 21:49:57 +0100 X-Google-Sender-Auth: qZSEzXERsIAdUI98AVgXhWDI6Xw Message-ID: Subject: Re: Problems with netmap pkt-gen (ip range and packet counter) To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 20:50:18 -0000 On Fri, Jan 17, 2014 at 9:20 PM, Luigi Rizzo wrote: > > sorry if i forgot to answer: > if there is a difference between the first and subsequent run > it is possibly a memory initialization problem. > > Yes: the first run only it failed to pass the "wait all the TX queues to be empty". All subsequent runs have no problem at all. I only have to reboot the server for reproducing the problem. From owner-freebsd-net@FreeBSD.ORG Fri Jan 17 23:49:06 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B6FAA10; Fri, 17 Jan 2014 23:49:06 +0000 (UTC) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E9B8816C4; Fri, 17 Jan 2014 23:49:05 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id w4so4598418qeb.36 for ; Fri, 17 Jan 2014 15:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hFfaRuwTmgDiGjJnQrbU0CuV6U5vcp0cHhZVP3RBwEQ=; b=f38WqMzWDcI7XC7wmbEO3tc9ucCucDBqk6Ak/y5ozcsSYFI37ct4us8YLqRwueAzP0 r9Icd/JFhSSSbIt4HkHrNs8G9vGJp5qeAF+OG4I0VPPzqXdhG1VXMOBln8m6MzhjoBYA tPSivX8X6ZhZ7w6/B9FSYmcsQIhtwvcT69p72z0cYxUxKSH/gznWFQ3JKzrKkUmPmlsR DYiid+vhNFhK2+jy+QzUe/bpuEwVs9a+4CAax2HOysRCdBmqjpvXaByEL3bgRoh6HwEH d6Y+OJBkDSwQo0YXg+xPN3wVOYB5CuE120ax72VUk29LQpWe8+tbmmceNPp/PoljZsqI Gmzg== MIME-Version: 1.0 X-Received: by 10.224.46.8 with SMTP id h8mr8157887qaf.49.1390002545112; Fri, 17 Jan 2014 15:49:05 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Fri, 17 Jan 2014 15:49:05 -0800 (PST) In-Reply-To: <52D996FD.6090901@FreeBSD.org> References: <52D5138B.8050100@fsn.hu> <52D6525D.50102@FreeBSD.org> <52D84DB0.4050607@FreeBSD.org> <52D996FD.6090901@FreeBSD.org> Date: Fri, 17 Jan 2014 15:49:05 -0800 X-Google-Sender-Auth: sGdvjrGjuqrHeYCEpUuKc18OuSk Message-ID: Subject: Re: ECMP hash keys? From: Adrian Chadd To: "Alexander V. Chernikov" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 17 Jan 2014 23:49:06 -0000 On 17 January 2014 12:47, Alexander V. Chernikov wrote: > On 17.01.2014 02:08, Adrian Chadd wrote: >> The reason you need to make sure that you end up with hashes for both >> src,dst and dst,src being equivalent is to ensure that when you create >> an outbound socket, you know up front which path the receive path is >> going to come back on. Right now we don't mark new connections - >> inbound or outbound - with a flowid until we've received some data on >> it. > Well, this seems reasonable. > > However, how do you plan to interact with hardware RSS? Well, if it's doing Toeplitz in hardware, we'll just use that. DragonflyBSD does this. They program the RSS registers on startup to map parts of the RSS space to CPUs as required. But if it isn't, we will have to do our own toeplitz hashing in software. I thought the majority of NICs these day do the topelitz calculation in hardware anyway. > For example, currently Intel used to set flowid to cpu number (which can > be reasonable in some cases). Afair 82599 advanced RX descriptor > contains original value that can be extracted, but we can't change cpu > on which packet arrives on (well, we can reprogram indirection table, but..) Well, that's the point, right? > I can't see any easy way to accomplish custom SW RSS: > > We can possibly have 1-2-4 ingress HW queues per NIC, ignore driver > flowid, re-calculate with modified Toeplitz or similar and push to other > ncpu-1 neisr queues. That can work, but requires custom setup > (especially for lagg scenarios) and works well for small subset of > workloads. Well, lagg is the same but different. Ie, we still choose the outbound TX queue on _a_ NIC based on the CPU/netisr derived from flowid. But the outbound NIC has to be chosen a different way or you end up with sub-optimal TX queue selection. Scott found this @ Netflix and this is why lagg now doesn't use the low bits of the flowid when it chooses which port to send _out_ on. > It seems also guessing ingress flowid is not very much different between > symmetric and asymmetric hashing approaches. I think the problem here is that flowid has been a mostly-opaque value for way too long. I like the dragonflybsd approach - they added a hashid, not flowid, and the netisr path checks to see if the driver has stamped it with a hardware toeplitz hashid or not. If not, it does its own hashing and punts the frame to the correct netisr RX queue on the right CPU. For routing it may not matter as much- we could just short-circuit that so it runs on the current CPU all the way to transmit. For NAT, it may be worthwhile keeping the per-flow state local on a given CPU to exploit various cache/lock coherencies. I guess the fall out from all of this is that I'd rather we had better specified things like "what is flowid", "how can we specify affinity", etc, so we can use it if we want, and not use it if we don't. Right now we have a "kind of but not quite done" way of affinity, enough to mostly not break TCP/UDP flow ordering, but not enough to really exploit affinity. -a From owner-freebsd-net@FreeBSD.ORG Sat Jan 18 06:58:36 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 415C86D2 for ; Sat, 18 Jan 2014 06:58:36 +0000 (UTC) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1672168F for ; Sat, 18 Jan 2014 06:58:35 +0000 (UTC) Received: by mail-ee0-f48.google.com with SMTP id t10so2460599eei.7 for ; Fri, 17 Jan 2014 22:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=KRCdpCrZm0+rvwAn7BSV7G3WcDBvqvxCvL2QEDZKkbE=; b=ejsviESAC43CSUG8zV+dmP8TLvQKrNLiNEbb+tx2oh7aEQCbczN/HnhlqcxyaJKcUM xfHh4nxUux4wybRKULuCsA472dx4yOAEuYVIGfl4tJbv+vvHg4t0piDXx0GjgZNm/FSd VC/a5JJmmBrC1Swf8K49MOUPVQQj5Sqs1inMRtrqM3qBSPYH6AcMU4pgjWvb+dNy3nO6 yy4SkwzuiPIhtrCrdDenB9ih/ZxunHU4fjxcmM7gg/vuUXrCZiTy2lUOavN8Sc2NplGw ve8hLXEpLvR9dGDkdZcF5t9NM/87dGHAT4I2MFebCCNSwjhFYCWilqdwqlF/bop++skJ LCkQ== MIME-Version: 1.0 X-Received: by 10.14.149.139 with SMTP id x11mr6585814eej.35.1390028314070; Fri, 17 Jan 2014 22:58:34 -0800 (PST) Received: by 10.14.2.66 with HTTP; Fri, 17 Jan 2014 22:58:33 -0800 (PST) Date: Fri, 17 Jan 2014 22:58:33 -0800 Message-ID: Subject: Port mirroring on FreeBSD From: hiren panchasara To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Cc: Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Jan 2014 06:58:36 -0000 I have this weird requirement that I am juggling right now and I wanted to reach out to larger audience: In this box I have 2 dualport ixgbe 10G cards. On ingress, I want to get data off of 2 ports of first 10G card and lagg/lacp them into 1 stream of data. But for outgoing, I want to have 2 identical streams of data going out on 2 ports of the second 10G card. (not load-balancing but more of a mirroring). The reason for this is, I need to be able to provide same data to 2 different application hosts downstream for monitoring. Something like: http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/port-mirroring-ex-series.html I believe a regular switch might be perfect but for I could not find anything simple in FreeBSD to do that. Luigi: Can netmap/vale be helpful here? Any other pointers would be really appreciated. Cheers, Hiren From owner-freebsd-net@FreeBSD.ORG Sat Jan 18 07:10:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BC5D912 for ; Sat, 18 Jan 2014 07:10:29 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4764117C0 for ; Sat, 18 Jan 2014 07:10:29 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tq11so4624354ieb.28 for ; Fri, 17 Jan 2014 23:10:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=/RNhp8wwozliSm0CG9fELsPLE7QVKUYLZry8pM6WxF8=; b=MAiscv0rR2qzGQOmO51l7/L6YOraydCVVGfYBgW3k+0clTjl9shPUFD4GskrusMT6O LyoqAvWoZGUr4ibgiCrZLLWcEhoVf/jDMNNhlfdSZALRwHDe6xeV/JQOWoVV0BRsTvAB D0RgOG51rZ4gfYq6eYIiLpNwdKPH4f8pdRcMM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=/RNhp8wwozliSm0CG9fELsPLE7QVKUYLZry8pM6WxF8=; b=CehpIw43OWHTRzPBk1BRZdw4MB5dDzpFupzt/agvDN255E97+tj4kP18q1FI6f3uFM O2TJ2Cg8ylqgi8Kbz3muWqjx7lsc2XOTUMZTa9qQfH03iorf9/Vbi/cB+wH+ZVJ1Ztti 242FFlvK5ryDLFKbZZbCxJ1WD9oz9khcnHG5Vgxuo19S1qX5rzkW//kf26oWteYuntqR TmrthZ7h2bu3+OE6Ga+/Tr91f+a8cJpJDvLv9/xNn4UE7TbLBN+Mi16pH+LdYYJyi7EU H+eFcxXW2EV4q/8s9CFAJ0+feMSTT3+vYixNfewgw9b5Lx5lKXHhF3O3egfbUzuPVslL sPYw== X-Gm-Message-State: ALoCoQmPRZ2urNj3v8EOakGwu4VedqLtGW2J4l2FStfWWjNty5ro6kz1CyWzABM60po9FgPnltzk X-Received: by 10.50.87.201 with SMTP id ba9mr2149600igb.21.1390029028635; Fri, 17 Jan 2014 23:10:28 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id gc2sm7864714igd.6.2014.01.17.23.10.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 23:10:26 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-C898EF05-7824-4E1C-82E7-D02D3055133A; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <77DEFAFC-6EFD-40A9-A111-2AB99BC241AF@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Port mirroring on FreeBSD Date: Sat, 18 Jan 2014 02:10:23 -0500 To: hiren panchasara X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Jan 2014 07:10:29 -0000 --Apple-Mail-C898EF05-7824-4E1C-82E7-D02D3055133A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sorry for the top post but cell phone here . . .=20 Have you thought of pf with the dup-to rule ? Also have thoughts of cisco etherChannel=20 --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 18, 2014, at 1:58, hiren panchasara wr= ote: >=20 > I have this weird requirement that I am juggling right now and I > wanted to reach out to larger audience: >=20 > In this box I have 2 dualport ixgbe 10G cards. On ingress, I want to > get data off of 2 ports of first 10G card and lagg/lacp them into 1 > stream of data. But for outgoing, I want to have 2 identical streams > of data going out on 2 ports of the second 10G card. (not > load-balancing but more of a mirroring). >=20 > The reason for this is, I need to be able to provide same data to 2 > different application hosts downstream for monitoring. Something like: > http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/port-mirror= ing-ex-series.html >=20 > I believe a regular switch might be perfect but for I could not find > anything simple in FreeBSD to do that. >=20 > Luigi: Can netmap/vale be helpful here? >=20 > Any other pointers would be really appreciated. >=20 > Cheers, > Hiren > _______________________________________________ > 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" --Apple-Mail-C898EF05-7824-4E1C-82E7-D02D3055133A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDExODA3MTAyNVowIwYJKoZIhvcN AQkEMRYEFH3U/gwTuUnzu1RtZanBOQqdBATdMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAlHJS1LvT5NK0/Aw85D/m b9KPYPKwz/eIe/ypfiT2HyWfHob8OtZ5U/PIGYiDHLkthJe6860yd3rczjuTEz/Nt7ft9j0RnhRO pDpatwxJHQt2G9pZ3sp2P4XP9f71C/R+P/1UJKmge7kx2SmFVcyFiHjkvXwqgRk7uP10JL5m7ulG vn9uTEeEZB8EkJ/mWzlOXopQEAMPaGqxRWmfK0tkVx92f0fCX8rZGv8QCzyLzOrJXN5YtHM3GkOa FsDK0C4HQHnXm45jJ50DXQYzp1Ib9aogruWC2EUY9icHT/2Xe/E1nIqILldEJfCQWc+YCOpaFDFg EPlrua0AsV6YUqwk9gAAAAAAAA== --Apple-Mail-C898EF05-7824-4E1C-82E7-D02D3055133A-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 18 12:56:24 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D755BD7E for ; Sat, 18 Jan 2014 12:56:24 +0000 (UTC) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92E351F01 for ; Sat, 18 Jan 2014 12:56:24 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id oy12so1550224veb.9 for ; Sat, 18 Jan 2014 04:56:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=N0tbEj2hMXTj6BvGjNg1ZKXnW1Eiwe/k0sVndGjMk2g=; b=TwrGNtHHfpJlwGOOjfnvMeqgVPEN2AMjUaJQo0B5batPmwV8ZUi8PTqHo1w68V4vVe bZ1gh8zgZILT2E32vS81vMumgCFEhlVPU1cKaPBtcyJ04hBjHTkc7Gqz/Cj8DxT2jJAO OIdr1yHXTMmhXPBlRMI7+cyC5fsmjv++uO3+t1+NuJKCa8rLQTeWIv095DWTvM/S08oa 1tZypp4jChL6WURbp2t+PcH6FY7PHSzPYZBAFd5qd6mWJVrPC9RYFH6RrDshfljZxWdC 8vA3ddsPiKQfUr54y4uu/gm78f7d10xy+N6dxaBMumXKwtgxKXOYebHL/CPbv3vjo92a 9eWw== MIME-Version: 1.0 X-Received: by 10.58.229.164 with SMTP id sr4mr2920493vec.18.1390049783632; Sat, 18 Jan 2014 04:56:23 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.220.78.84 with HTTP; Sat, 18 Jan 2014 04:56:23 -0800 (PST) In-Reply-To: <77DEFAFC-6EFD-40A9-A111-2AB99BC241AF@dataix.net> References: <77DEFAFC-6EFD-40A9-A111-2AB99BC241AF@dataix.net> Date: Sat, 18 Jan 2014 12:56:23 +0000 X-Google-Sender-Auth: l_0l6GPBMrYI84yLHYkXXfK1Jjw Message-ID: Subject: Re: Port mirroring on FreeBSD From: Nikolay Denev To: Jason Hellenthal Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo , hiren panchasara X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Jan 2014 12:56:24 -0000 On Sat, Jan 18, 2014 at 7:10 AM, Jason Hellenthal wrote: > Sorry for the top post but cell phone here . . . > > Have you thought of pf with the dup-to rule ? > > Also have thoughts of cisco etherChannel > > -- > Jason Hellenthal > Voice: 95.30.17.6/616 > JJH48-ARIN > >> On Jan 18, 2014, at 1:58, hiren panchasara wrote: >> >> I have this weird requirement that I am juggling right now and I >> wanted to reach out to larger audience: >> >> In this box I have 2 dualport ixgbe 10G cards. On ingress, I want to >> get data off of 2 ports of first 10G card and lagg/lacp them into 1 >> stream of data. But for outgoing, I want to have 2 identical streams >> of data going out on 2 ports of the second 10G card. (not >> load-balancing but more of a mirroring). >> >> The reason for this is, I need to be able to provide same data to 2 >> different application hosts downstream for monitoring. Something like: >> http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/port-mirroring-ex-series.html >> >> I believe a regular switch might be perfect but for I could not find >> anything simple in FreeBSD to do that. >> >> Luigi: Can netmap/vale be helpful here? >> >> Any other pointers would be really appreciated. >> >> Cheers, >> Hiren >> _______________________________________________ >> 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" if_bridge(4) and a port in the bridge configured as "span" port with ifconfig? However I'm not sure if that's going to be fast enough for 10G, and maybe as you've mentioned Netmap might be a better solution. --Nikolay From owner-freebsd-net@FreeBSD.ORG Sat Jan 18 16:29:46 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D97B0DCE for ; Sat, 18 Jan 2014 16:29:46 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DAB01E8D for ; Sat, 18 Jan 2014 16:29:46 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id y1so4485890lam.13 for ; Sat, 18 Jan 2014 08:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kA3qW6CcUwHOcI16akxjtuDWq3zbJF0v0zqGIpvjqCk=; b=YI02LrohbAvanMmCB2YAHHlCQe9iX2Jta0lvZm4VgMfgjghFQaECcYHTH4nM7Ng9KN zJD08x0e1QS7ZQkH/VOxfIJ0Tko+s+cd1rjIdKEW6f7vOYVoCAORnQr09AyuSeE/Wd9z w8H8QYuKxRk+ZZQfydcKHgfAXtyy5hmhsAL60DNm+4/1nO7NUQp3KUUGxlCGVQe6HEx3 z2q8MNo+ydEuPqc4KJaNur+Ccssuj+nOntu5zwPOzYxRQCALjYyZxAWQAUc+rQDIieYv f+WBlXrw4roMH4trxYnVPKnLvcS+FxqclT0qxu08jZFYXxoLX7aL8U8cSyrpQr1UqGc7 vRdA== MIME-Version: 1.0 X-Received: by 10.112.171.41 with SMTP id ar9mr41260lbc.74.1390062583441; Sat, 18 Jan 2014 08:29:43 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Sat, 18 Jan 2014 08:29:43 -0800 (PST) In-Reply-To: References: Date: Sat, 18 Jan 2014 08:29:43 -0800 X-Google-Sender-Auth: LAtJ1ZQoIBIPg_7Ov1SWZCt8eug Message-ID: Subject: Re: Port mirroring on FreeBSD From: Luigi Rizzo To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Jan 2014 16:29:47 -0000 On Fri, Jan 17, 2014 at 10:58 PM, hiren panchasara < hiren.panchasara@gmail.com> wrote: > I have this weird requirement that I am juggling right now and I > wanted to reach out to larger audience: > > In this box I have 2 dualport ixgbe 10G cards. On ingress, I want to > get data off of 2 ports of first 10G card and lagg/lacp them into 1 > stream of data. But for outgoing, I want to have 2 identical streams > of data going out on 2 ports of the second 10G card. (not > load-balancing but more of a mirroring). > > The reason for this is, I need to be able to provide same data to 2 > different application hosts downstream for monitoring. Something like: > > http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/port-mirroring-ex-series.html > > I believe a regular switch might be perfect but for I could not find > anything simple in FreeBSD to do that. > > Luigi: Can netmap/vale be helpful here? > for this and other custom applications what I would do is build a userspace application that puts the nics in netmap mode and does the necessary juggling. Note that since the host is going to be the performance bottleneck, you can probably do the same with just bpf without too much impact on performance (and some advantage since you do not need to handle the input traffic; at least, if i understand your description the monitor does not need to see a replica of the incoming traffic). Some time ago the answer to this type of questions used to be "use netgraph". Maybe it is also a valid option but i do not know if there are modules that suit your need. cheers luigi From owner-freebsd-net@FreeBSD.ORG Sat Jan 18 16:31:58 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 29FDEE7F for ; Sat, 18 Jan 2014 16:31:58 +0000 (UTC) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC0921EFA for ; Sat, 18 Jan 2014 16:31:57 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id ii20so4255353qab.4 for ; Sat, 18 Jan 2014 08:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5iTi6s0pRzw+obQX2/oClbh4/6A6axhLVCCLPVCVDoc=; b=Vsc5TJKKCI57l+nl1/5zGQT2mfsIQ+o1jyoopSI1UUZFhRknb7VGmWS/nhiEwThmSU hENVkgRe6bDFXZ3FOjj5RYbcLE9sgf2uQrMqHWCX3QcV6mxS3J6jkwOmuWspEy9ZBFxb 3zubuJe/VFCv1y82VcPZwUPdi8+fuYihC4Jynq4Z2mgxs1mwW5I7sGer5jC3BpeL76X/ Gxs+C3h9jX8+oDMNd4L4/0b4eTi/tgfp5xNLhYu20npZQE9+fZCUToLV406QY0a8lJap Sp5Cs7UleqygHOUwzV9WEetrUuNYV2VKdMWkS3K/cGMDoGgQlkXYtVuIDVW3R121IoUv 3woQ== MIME-Version: 1.0 X-Received: by 10.140.108.74 with SMTP id i68mr12555613qgf.87.1390062716587; Sat, 18 Jan 2014 08:31:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Sat, 18 Jan 2014 08:31:56 -0800 (PST) In-Reply-To: References: Date: Sat, 18 Jan 2014 08:31:56 -0800 X-Google-Sender-Auth: xMejva-fc5asLIjQPi0VeHVhLyw Message-ID: Subject: Re: Port mirroring on FreeBSD From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" , hiren panchasara X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Jan 2014 16:31:58 -0000 On 18 January 2014 08:29, Luigi Rizzo wrote: > On Fri, Jan 17, 2014 at 10:58 PM, hiren panchasara < > hiren.panchasara@gmail.com> wrote: > >> I have this weird requirement that I am juggling right now and I >> wanted to reach out to larger audience: >> >> In this box I have 2 dualport ixgbe 10G cards. On ingress, I want to >> get data off of 2 ports of first 10G card and lagg/lacp them into 1 >> stream of data. But for outgoing, I want to have 2 identical streams >> of data going out on 2 ports of the second 10G card. (not >> load-balancing but more of a mirroring). >> >> The reason for this is, I need to be able to provide same data to 2 >> different application hosts downstream for monitoring. Something like: >> >> http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/port-mirroring-ex-series.html >> >> I believe a regular switch might be perfect but for I could not find >> anything simple in FreeBSD to do that. >> >> Luigi: Can netmap/vale be helpful here? >> > > for this and other custom applications what I would > do is build a userspace application that puts the nics in > netmap mode and does the necessary juggling. > > Note that since the host is going to be the performance bottleneck, > you can probably do the same with just bpf without too much > impact on performance (and some advantage since you do not > need to handle the input traffic; at least, if i understand > your description the monitor does not need to see a > replica of the incoming traffic). > > Some time ago the answer to this type of questions used to be > "use netgraph". Maybe it is also a valid option but i do not > know if there are modules that suit your need. part of me wonders whether having a netgraph style system for gluing together netmap things but in userland would be useful. -a From owner-freebsd-net@FreeBSD.ORG Sat Jan 18 16:40:59 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81395217; Sat, 18 Jan 2014 16:40:59 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD4B71F3E; Sat, 18 Jan 2014 16:40:58 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id w7so3354908lbi.35 for ; Sat, 18 Jan 2014 08:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BrCNxVvDYiNOK0gXAxvx3Rxkj8siPr3UPrgMwS/aL1U=; b=XtnI5MNjJbbad82cL64j6Cv4X9cec5BNyZGOKAl/Rvj3pSQjiyjbTJTxMrPSwD/Ed6 CPI7ryVI6Yy17D+MKjfOyFNVlNZI3Ege/6N7ZDg4kGlR6uMEUvn20yMYTGHK9vK1xIq5 RzjowqZrGQZNbnprEG5qVKf+IT8dsxWRv6c9UGT5pQIlFWXmRd3/jLYIzKSMjjGXYJFo W4QJ3L2I2cW7vWs/zapasORsd5A5Qu6fxLXFKTX3nGTf46fBCQitdQWi4QAPKbObypP8 omdCfRcbfESdO3TTMtDcdQRPYdo7b7QzDxYsZUKhVXl+7MMT8l9j2Fqv1j3+0AojIM+r DyiQ== MIME-Version: 1.0 X-Received: by 10.112.53.201 with SMTP id d9mr4784819lbp.26.1390063256722; Sat, 18 Jan 2014 08:40:56 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.175.180 with HTTP; Sat, 18 Jan 2014 08:40:56 -0800 (PST) In-Reply-To: References: Date: Sat, 18 Jan 2014 08:40:56 -0800 X-Google-Sender-Auth: tlrn0rr9_TffriB8N9i295QwbKY Message-ID: Subject: Re: Port mirroring on FreeBSD From: Luigi Rizzo To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , hiren panchasara X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Jan 2014 16:40:59 -0000 On Sat, Jan 18, 2014 at 8:31 AM, Adrian Chadd wrote: > > > > > Some time ago the answer to this type of questions used to be > > "use netgraph". Maybe it is also a valid option but i do not > > know if there are modules that suit your need. > > part of me wonders whether having a netgraph style system for gluing > together netmap things but in userland would be useful. > there is such a thing, it is called click http://www.read.cs.ucla.edu/click/ https://github.com/kohler/click/ and it does have netmap support (i am about to push some updates). cheers luigi > > > -a > -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+------------------------------- From owner-freebsd-net@FreeBSD.ORG Sat Jan 18 17:09:29 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2A9C847 for ; Sat, 18 Jan 2014 17:09:28 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC90C110A for ; Sat, 18 Jan 2014 17:09:28 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id uy17so4330724igb.4 for ; Sat, 18 Jan 2014 09:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=T/5OGHcG+bmJgPRlikU2nxxsufsvX1zkXSlzzzDpI+g=; b=WePb1SfsvhttJaTsObHeVmGN7NcM875D7TIZq0dvv7sULj0KJEGIiRTtUOAI4Fas7C /hq/ERIPJ5kejPyEjmltgAFwdMVrZc5thyrfDKnggtfhqIsiLOBIJCNM/zk/BDoBcuQU t4xZaqPAAqmP0F4pahLK/1N3dW/OMDxmPSKNc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=T/5OGHcG+bmJgPRlikU2nxxsufsvX1zkXSlzzzDpI+g=; b=ave0FqV9boRiwtBm30vWVCymE5v1COH46fYbAyrwB/0c3xHG+cpjG73RESo14jZYox +ob35w0DuUMEz3+3PY6lsuxtPpXKT+Y9V9WqE0WLRKYw3apN3QCguA6u69gO87DaSmrP 4qMiqiBStGZeGs07exH0KKW8Se9YwsGrJZ9XufYVyGpS9Au0HTMZRYJAOOhODOf72hdE OKpT1XRL9bZHqexeX354kpZqP28vCx6LASuSrjgE64xxaapxyAKQZJfiSEY3svFct/Dl r3RT9Aw6kFRpc6fvUZdEmZhLkDHqsnEK9j5V669yPvoZFRlS3mBxFjPKwpd1Joyg4H5E hFdg== X-Gm-Message-State: ALoCoQkDSf+jWLbm5AsQBnId7HmabR3hf2rrkpalRx7pGHNSpbZ7+wp3D4MgEqxjMDhjDLQVJPWn X-Received: by 10.50.225.105 with SMTP id rj9mr1916711igc.19.1390064968046; Sat, 18 Jan 2014 09:09:28 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id ft2sm10061676igb.5.2014.01.18.09.09.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Jan 2014 09:09:26 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1AB63213-D089-48DC-8DB5-306D3750ED94; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <31C53E84-305D-4C3F-AEFD-9ED0419A0DF0@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: Port mirroring on FreeBSD Date: Sat, 18 Jan 2014 12:09:23 -0500 To: hiren panchasara X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Jan 2014 17:09:29 -0000 --Apple-Mail-1AB63213-D089-48DC-8DB5-306D3750ED94 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Generic solution ? Splice into the original sending cable to duplicate the t= raffic directly off the line itself ? --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 18, 2014, at 1:58, hiren panchasara wr= ote: >=20 > I have this weird requirement that I am juggling right now and I > wanted to reach out to larger audience: >=20 > In this box I have 2 dualport ixgbe 10G cards. On ingress, I want to > get data off of 2 ports of first 10G card and lagg/lacp them into 1 > stream of data. But for outgoing, I want to have 2 identical streams > of data going out on 2 ports of the second 10G card. (not > load-balancing but more of a mirroring). >=20 > The reason for this is, I need to be able to provide same data to 2 > different application hosts downstream for monitoring. Something like: > http://www.juniper.net/techpubs/en_US/junos13.2/topics/concept/port-mirror= ing-ex-series.html >=20 > I believe a regular switch might be perfect but for I could not find > anything simple in FreeBSD to do that. >=20 > Luigi: Can netmap/vale be helpful here? >=20 > Any other pointers would be really appreciated. >=20 > Cheers, > Hiren > _______________________________________________ > 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" --Apple-Mail-1AB63213-D089-48DC-8DB5-306D3750ED94 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDExODE3MDkyNVowIwYJKoZIhvcN AQkEMRYEFB7q03gFtfDB9ejat+FsfX2OnLCuMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAYXJ93iUX+sZV7oOMW8ZE HSqkDBvG3mAFF6Z/fx6N2yKDi2Oe+dYpmNqISosnHvqle4HU6esZtuju/YlQcwDvKPhzVccybVSi aoimz3kmamDuT+jqvcadB0Cr5qf5217ofJY8ZoNqQ63f+IsvvuCXb0kAGBhUunUsemGTmp6wuZU0 JsSjbWKum5PicspTQ44krRql2LislFfIHmdlL2PEXyd3/uKU9wh8Bz4eR71DqtLR3ctB8xdWt7Ni uxICl40sLWTCVavx6SDn1oXpoaMe2A3sb3goH/LANOu5XTQZVF3YIo4jwEy3icAV7W0qYq+DbE8b 03N/Efae6ZnRRrP6BgAAAAAAAA== --Apple-Mail-1AB63213-D089-48DC-8DB5-306D3750ED94--