I've done some research on this topic yet I haven't found an appropriate 
solution yet and I was wondering if anyone who's had some experience 
with this could point me in the right direction.

My goal is to combine the bandwidth of two ADSL connections. Both 
connections have their own gateways and their IP addresses are on 
different subnets.

We've tried several different approaches. The first and obvious one was 
to use packet filtering and we had minor success with this on OpenBSD 
using a round-robin rule but this turned out to be very slow. I'm not 
sure that we were doing it correctly or not, but has anyone managed to 
do this with ipf on NetBSD?

The the other idea that we had was to use ALTQ somehow but it seems ALTQ 
was made to manage only one interface.

Thirdly, we looked at multiple default routes, but from the mailing 
lists it seems that there hasn't been success with this yet either.

Finally, and probably the most interesting was 802.3ad link aggregation 
which was added to NetBSD -CURRENT just a few weeks ago. I was very 
pleased with this new code. We actually managed to combine the two 
100baseT NICs to make a "200baseT" connection, but this is, 
unfortunately, not a solution to our problem.

I've made up my mind that must be a solution to this using NetBSD 
without any more expensive hardware.
I have some other vague ideas which I haven't completely hashed out yet 
such as some kind of bridging of the two subnets and using this link 
aggregation. If we could we could use the agr0 device such that it would 
send packets out in a round robin (or possibly a better algorithm since 
ALTQ will be able to operate on this single agr0 interface [can it 
select default routes?]) fashion to each of the two gateways which we 
could easily put on the same subnet by bridging. With the use of NAT, 
the packets would be returned to the right ports on that agr0 address. 
Like I said, that's quite vague but I believe there may be a solution in 
there somewhere.

I'm actually hoping someone on this mailing list will know of a simpler, 
more efficient, solution.

Thank you,
 * Anthony