Bridging Two Tunnel Interfaces For ALTQ

[Michael MacLeod]

On Fri, Jul 1, 2011 at 1:20 AM, Julian Elischer <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 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<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.

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.