Hi all. I have some kinda of a strange question to ask!
I am behind a very fast connection that is capped @ 100 KBps per MAC address (they simply wanted to make stuff easier for themselves by doing so instead of setting up a proper traffic shaping mechanism) and well, I wanna bypass this limit. My plan is to create some fake ethernet devices, bridge them with my network card, get a different IP on each of these devices from the DHCP server and then download different files from each of the devices simultaneously. As a step further, if I succeed in the first step, I wanna bond these fake devices into one fake device so that I'd also be able to get the acceleration when downloading a single file.
I have played with tap and bridge devices in Backtrack (based on Ubuntu 10.04) a little bit but I didn't manage to even get the first step to work, thus I'd really appreciate any help from you guys.

Why not just use more ethernet cards?
If you are trying to bypass the limit per MAC, then you will need to spread the traffic over the multiple MACs. But that means spreading it over multiple IPs. You'd have to reprogram at the other end to load balance the file over the multiple IPs (or reprogram it to use SCTP if that can function across your ISP). And you need multiple IPs from your ISP, too.
I did some initial testing along these lines a couple weeks ago trying to figure out how to make Linux fake the MAC address of another machine while also using its own (e.g. 2 or more MACs per physical interface). I was not successful at finding a means to do that. Multiple NICs with fake MAC on the added ones would work, but adding more NICs isn't an option for the machine I needed to do this on due to it being remote. If adding NICs for your machine is an option, I suggest that means. Dual-port NICs are now days at the same price-per-port as single-port NICs. Quad-port NICs are still premium (and not so often used because all the existing load balancing or bonding solutions still do a poor job).

Hmm, to increase the 100 KBps cap to a reasonable speed, i.e. at least 2 MBps, I'd need 20+ ethernet cards and well, that's not really possible.

There is no problem getting multiple IPs, I have access to lots of access points here from which I can get as many IPs as I want, I just need to have enough ethernet devices. Before I forget, I'm talking about my uni's internet here.

Well, I prefer to try software methods right now; worst case scenario, I'll install XP on VMware and make 10-20 copies from it and run all the copies simultaneously and get a different IP on each VM and leech @ 100 KBps from each, lol!

Then your problem is equivalent to the problem I had (though for a different reason ... my case was the upstream router was not expiring its ARP table) ... which is a need to have MULTIPLE MACs on the same ethernet. But this won't make the traffic on ONE IP any better because that ONE IP will go over ONE MAC, and face that per-MAC throttle. A router not compliant with RFCs might be able to do tricks to spread one IP over many MACs.


They probably have throttling for a reason ... that you and I might not agree with. I assume THEY control the router, so it's never going to be modified to do one IP over mant MACs.

No way to convince them to give YOUR MAC more speed?

You will be able to do 20 separate streams on 20 separate IPs. But that won't make ONE stream to some host you don't control work any better, because that host won't know to multiplex the data over many streams.

FWIW, you can in fact use multiple macs in linux via the TUN driver. There are lots of refs around, also check an utility named "multimac" that IIRC automates/simplifies the work.

I wish I had known of this a couple weeks ago. It would have been a nice fix for one of our ISPs that has a bad router (either they have static ARP or disabled ARP timeout) and no clue about it. Some of the IPs in the subnet they assigned to us are never doing ARP query and instead are transmitting to the wrong MAC. I can see the traffic arriving (the switch doesn't know where that MAC needs to go). But all I needed was to get Linux to accept it as destined to the wrong MAC.

Stuff is moved to colo now, so no longer any need.

I mentioned what the reason for the traffic shaping is and there is no way they'd give me more speed.

Yeah, but even different streams on different IPs will do the job for me; yeah, I'm that desperate, lol!

Exactly the path I have been following. I soon encountered issues with multimac, that's why I decided to start creating and bridging TAP devices on my own (never understood what the use for the tp0 hub in multimac was) but since my issue is, well, quite rare, I haven't yet found any proper guides for this exact matter.

Yes, this is very much possible with macvlan devices. See my answer to this SuperUser question.

I believe this is not possible. If you assign the same IP address to two macvlan interfaces, you can use iptables (random matches) to load balance outgoing packets. But there's no way you're going to get the router to load balance incoming packets between your two MAC addresses. The router will just do ARP for the IP address and use one of the MAC addresses that respond to it.

If you create (the appearance of) multiple MACs (as in the macvlan) and have each ARPing with a different IP (gotten from different DHCPs), then supposedly you'd have up to 100 KBps per IP. Now you have to program the remote end to work the magic of balancing transfer loads over multiple IPs. Normal server software won't automatically do that. But maybe for a large file you can do multiple ranges. Say you have a 20MB file to download. Split the file size up into 20 different byte ranges, and have 20 clients (or one smart client) initiate the 20 transfers in parallel. But each socket will need to have its source IP bound to each of the different IPs you have on those 20 virtual interfaces so the server sees it as requests from the 20 different IPs ... so the load balance sees it as traffic for the 20 different MACs.

If this is for file transfers, the range thing could work with the right client programming or scripting. But getting a single stream to run at the combined speed will require tunnel demultiplexing at BOTH ends.

Hmm, macvlan looks quite interesting, I just gave it a try, successfully set up macvlan0 and gave it an IP from DHCP but I'm afraid it has the exact same problem as I had with multimac; when I ping through the created macvlan0, always after a certain period of time, usually equal to 8-9 pings, the packets start being dropped and canceling and re-initiating the ping doesn't result in any responses for some hosts (like google) while for some others, the same thing happens again and again, i.e. 8 successful pings, then all packets will be dropped. Funny thing is, pinging through eth0 in this situation, all packets will be dropped but as I remove the macvlan, everything goes back to normal!!??
I'm doing all these on Backtrack 5 R1 (based on Ubuntu 10.04) @ kernel 2.6.39.4 from inside VMware which is bridged with my host OS.

Nah, that's not what I wanna do. Each of the devices will have a different IP but will be bonded together into a new device with one MAC and one internal IP address which can be seen only from the inside; or at least that's what the "plan" is!

What matters is what IP the upstream throttling router sees. In order for it to be operating across 20 different MACs, so you get the bandwidth of 20 MACs, it needs to be routing 20 different IPs. That means the remote host/server out there on the internet has to be sending in parallel to 20 different IPs. If you want to bond ONE IP across the 20 separate streams going over 20 separate IPs, you have to do that on BOTH ends of the bonded connection, and do it at the TCP or higher layer (the remote end does not need to be 20 different IPs).

Any attempt to bond at a lower layer requires cooperation from the next hop at that layer, which in the case of the ethernet link layer, means the router. Normal behaviour for a route is to associate just ONE MAC per IP. If you want bonding at this layer, you need to change the router's logic. And if you could do that you could turn off the throttling for an easier solution. Since you can't, then you can't do bonding at the link layer here.

Doing "tcpdump -elnn -i eth0" on the machine host (not the VM guest) should be showing mixed traffic with 20 different MACs and 20 different IPs for your end (and the router's MAC and remote IP).

Well, right now, I can't even get to the bonding stage, whether it is possible or not, before I find the reason for the packet drops.