Ok, here's how it is:
Im a student at a small private university in KY. In august our on campus ethernet sucked, I mean really sucked, time outs on simply browsing, download speeds below 1(one)k/sec... you get the picture.
So comcast came to the rescue, provided cable access to students, my 3 roommates and I got together and paid for it and it rocks... we can actually use the internet, and going back to dial-up at home is really painful. (only thing available here in the rural community)
Well, our IS department got there act and some grant money together and we're finally on a good connection (I think it's a full T1 for around 800 resident students, but don't hold me too it).
So now... we have two good-fast connections available. I'd like to be able to add them together so that we can have access to more bandwidth. I think linux is the only way to do it but if there's any other way, someone let me know.
And just to make it a little harder... the campus ethernet connection is flittered and packet sniffed and all sorts of things. I know I'll have to point our P2P software ports to the cable connection as the campus (and rightfully so) has it blocked. But what about http traffic that gets denied on the campus connection? Will it flip to the cable automatically? How do I avoid this problem?
Also, in linux, will the two connections be effectively 'added' together or can I only use one as the primary connection and then switch to another when one is bogged down? Can I only tell the server to use connection A for certain clients and connection B for another set of clients?
If linux is not the way to go that's ok, I've never really used linux anyway... but I like to get in over my head to learn something new.
welcome micah, that's an interesting topic you open!
As you said, what you want can be done fairly easily with linux or *bsd or solaris, through packet mangling.
For linux check this howto to get the idea
, or ask sahirh to write a better one for the upcoming Linux section, so that we can all benefit
Still I am not sure about what you said about specific HTTP traffic being denied through the T1, as that sort of filtering may be done in the application layer which is not nearly that simple as a policy at the transport layer. So it could be a trouble for you to forward only that specific traffic through your cable and maintain at the same time the load balancing for the rest of the HTTP traffic.
Unless you can learn exactly how the HTTP traffic is being judged and denied from your university, in which case you can obviously follow the same policy to forward it to your other gateway, or at least find out the general criteria with which HTTP traffic is judged to have a place to start.
Most likelly, what they do is forward the http traffic transparently to a caching proxy behind (or at) their router, and the proxy does the filtering, if it helps to know what to look for.
thanks alot for your help...
like I said Im not much of a linux user but I'd like to get to know it...
this could be getting a little objective but what flavor of linux should I use? would one of the dedicated firewall distros be good for this? I've been looking at smoothwall, clarkconnect, and monowall... most of them have access to the command line? I really like the graphical web interface especially since I live in a dorm room and I don't want to have another monitor sitting on my desk; and I could use my powerbook to admin it from inside the LAN.
speaking of the command line... where's a good site to learn the linux 'basics' using the command line, vi, fun stuff like that?
I would recommend that you pick slackware, provided that you want to actually learn how to use the operating system. Most of these GUIs you mention (and more), can be installed in every linux or non-linux unix distro. The fact that you don't want to have a seperate monitor and keyboard for your routing PC does't mean you can't access a command shell on it, you will be able to login remotelly and do whatever you want via SSH.
To make yourself familiar with Linux, you will need to install it somewhere (at least in a virtual machine at VMware) and play around a bit -a week or so- to see things in practice. A guide such as
will help you get the logic and work with basic commands.
NSKE! It's great to finally put a picture to that name ... Nice 3d avatar!
Micah, as nske noted, its quite a topic you've just opened and the good news is that there are a few ways you can go around it.
Be sure that we will be able to help you as we've done this before, but there are a few things which you'll need to decide.
The picture, from what I gather, is that you've got two connections to the Internet and you want to use the combined bandwidth. Obviously, one of them won't allow p2p programs, so as you correctly noted, you'll need to push them through the cable connection you have.
Even though bandwidth aggregation is possible with Linux, it can be quite tricky and I'm not sure how well it will work because of limitations and specific network rules which must be followed.
What I would recommend you do, at least as a first step, is to separate the traffic between the two lines, so you are clear with what will go through each of your lines. e.g all web browsing, emails e.t.c through the uni line, while gaming (!) and p2p will pass through the cable line.
The idea is as follows:
Your local network uses the Linux server as a firewall/gateway which will then pass your packets towards the Internet via one of two available lines.
You are able to tell the Linux server to use e.g ISP1 as a default gateway, but route specific type of packets (e.g gaming, p2p) through ISP2.
This way you are able to achieve the required result. In addition, if you want to make things more fancy, just like I have done so here at the office, you can place bandwidth restrictions for specific services or type of packets!
The first step to all the above would be installing the O/S. My personal preference is RedHat Fedora core 1 and above, but NSKE's choice of Slackware is equally good - in fact I'd say that Slackware is a hardcore Linux guru's choice over Redhat.
Whichever the choice, ensure you've got kernel 2.4.20 and above so you don't find yourself patching the kernel to perform the above!
Keep us up to date on your progress and we can help you through the process.