From owner-freebsd-net@FreeBSD.ORG Sat Jul 2 08:10:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73DE1106566C for ; Sat, 2 Jul 2011 08:10:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCF68FC12 for ; Sat, 2 Jul 2011 08:10:26 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p628ANmh094979 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 2 Jul 2011 01:10:24 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E0ED26C.6020701@freebsd.org> Date: Sat, 02 Jul 2011 01:10:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael MacLeod References: <4E0D593B.7090206@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Bridging Two Tunnel Interfaces For ALTQ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 08:10:26 -0000 On 7/1/11 12:59 AM, Michael MacLeod wrote: > On Fri, Jul 1, 2011 at 1:20 AM, Julian Elischer > wrote: > > On 6/29/11 11:28 AM, Michael MacLeod wrote: > > I use pf+ALTQ to achieve some pretty decent traffic shaping > results at home. > However, recently signed up to be part of an IPv6 trial with > my ISP, and > they've given me a second (dual-stacked) PPPoE login with > which to test > with. The problem is that the second login lacks my static > IP or my routed > /29. I can have both tunnels up simultaneously, but that > becomes a pain to > traffic shape since I can't have them both assigned to the > same ALTQ. > > ... unless there is some way for me to turn the ng > interfaces (I'm using > mpd5) into ethernet interfaces that could be assigned to an > if_bridge. I > could easily disable IPv4 on the IPv6 tunnel, which would > clean up any > routing issues, assign both tunnels to the bridge, and put > the ALTQ on the > bridge. It just might have the effect I'm looking for. Bonus > points if the > solution can be extended to allow it to work with a gif > tunnel as well, so > that users of 6in4 tunnels could use it (my ISPs IPv6 beta > won't let me do > rDNS delegation, so I might want to try a tunnel from he.net > instead). > > I spent some time this morning trying to make netgraph do > this with the two > ng interfaces, but didn't have any luck. Google didn't turn > up anyone trying > to do anything similar that I could find; closest I got was > this: > http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005598.html > > This is all assuming that the best way to use ALTQ on > multiple outbound > connections is with a bridge. If there is another or more > elegant solution, > I'd love to hear it. > > > rather than trying to shoehorn ng into if_bridge, why not use > the netgraph bridge itility, > or maybe one of the many other netgraph nodes that can split > traffic. > fofr example the ng_bpf filter can filter traffic on an almost > arbitrary manner that you program using > the bpf filter language. > > > Julian, thanks for responding. I'm not particularly concerned about > how I accomplish my goal, so long as I can accomplish it. I was > thinking about using if_bridge or ng_bridge because I have past > experience with software bridges in BSD and linux. Unfortunately, > ng_bridge requires a node that has an ether hook. I spent a bit of > time looking at the mpd5 documentation, and there's actually a > config option to have mpd generate an extra tee node between the ppp > and the iface nodes. These nodes are connected together using inet > hooks. If I could find a netgraph node that can take inet in one > side and ether on the other, I believe I'd be set. > > The nice thing (near as I can tell) about using ethernet based nodes > would be that pretty much everything can talk to an ethernet > interface (tcpdump, etc) and that ethernet should be fairly easy to > fake; just assign a fake MAC to the ether nodes (which is what the > ng_ether node does, pretty much) and the bridge will take care of > making sure traffic for tunnel 0 doesn't go to tunnel 1, etc. > > I haven't read up very much about ng_bpf yet, but it seems like a > pretty heavy tool for the job, and wouldn't the data have to enter > userspace for parsing by the bpf script? Also, I've never written > anything in bpf. It's not a huge hurdle, I hope, but it's certainly > more involved than a six line ngctl incantation that turns my iface > nodes into eiface nodes suitable for bridging. actually you can do that in 1 ngctl command.. I think you want the ng_eiface module. but I'm not sure...ngeiface presents an interface in ifconfig and produces ethernet frames which can be fed into the ng_bridge node teh output of which can be fed into a real ethernet bottom end. > > As I said, I'm not particularly concerned with the means, just the > end itself really. If there were an elegant way to create a virtual > ALTQ that I could then build sub-queues that were actually attached > to the tunnels in pf that would also satisfy my end goal, without > any netgraph mucking at all. I just haven't found any evidence that > ALTQ has any ability to do that. > > I just have two tunnels, one using IPv4 and one using IPv6, that > share the same bandwidth resource. I want a way to shape traffic > based on the pool of bandwidth, not the tunnels running through the > pool.