Bridging Two Tunnel Interfaces For ALTQ

[Julian Elischer]

On 7/1/11 12:59 AM, Michael MacLeod wrote:
> On Fri, Jul 1, 2011 at 1:20 AM, Julian Elischer <julian at freebsd.org 
> <mailto:julian at freebsd.org>> 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
>         <http://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.
I think you need to draw a diagram..
>
> 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?
no you download the filter program into the kernel module to program it.

> 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.
read the ng_bpf man page and the tcpdump man page.
Having said that you may find many other ways to split traffic.

>
> 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.
not quite sure what you mean by that,,

an example would help.