Re: Spill over

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kenneth Kalmer wrote:
Taylor & Chris (and the list)

The arguments behind my choice here is cost driven, the 64kbps line is a fixed monthly rate for unlimited use, the 512kbps line costs us roughly ZAR250 per 3GB of usage. This can get quite expensive as the lines in question is for a college and we all know what students do to bandwidth :)

Taken the amount we pay every month for the 64kbps line it's more economical to over utilize the link as a primary connection than to have it lying around as a backup. South Africa and data connections don't go well in the same sentence...

As Chris suggested, I need something that can detect when Link A is saturated and then redirect the traffic over Link B until there is available bandwidth on Link A again. The rate limit trick of Taylor might work once I get to understand the usage patterns of these students. But for at least the first 3 months I won't have proper data at my disposal.

Thanks for your replies!

Seeing as you are trying to avoid excessive bandwidth charges you find you self in a rather interesting position. Aside form what ever you end up using to control what route your traffic goes out you will ultimately want to have a fairly tight set up on what type of traffic is allowed. I have a client here in my town that managed to saturate an ADSL connection in the first 72 hours that we had the network in a testing state before we even went live with it. Ultimately we had to keep the traffic under 20 GB worth every month or they incurred extra charges. To this end I ended up setting up the router to only allow outbound traffic if it was destined to the following ports: (20) 21, 22, 23, 25, 53, 80, 110, 119, 143, and 443. I told the client that we would run with that set up until they told me that they needed another port opened for any given reason. I took the mentality of everything else will be shut down unless you can give me a reasonable request that is backed by someone with political authority (House monitor, Board Members, etc) that says that it is ok for you to be using this type of traffic. After I did this things have been GREAT. We have not had any more problems save for the month that they did not pay the ISP.


The real problem that I see in trying to keep one link saturated is that you can control the outbound traffic but you have no way to control the inbound traffic.  Well there are ways that you can attempt to control the inbound traffic but they are more a responsive control method (which is less likely to succeed) than a proactive control method like you can do if you control the sending end of the connection.

A really drastic idea that I have that might not be too hard to implement would be to establish a PPP multilink session out both connections to a server somewhere on the internet that has HIGH bandwidth (more than your aggregate bandwidth).  What this will allow you to do is control what link the traffic will come in and out.  All your traffic would appear to be coming from the IP of the server out on the net but I don't see that as a problem really.  I think if you do this you can set up routing and traffic control to try to use the 64 kbps link as the primary link and role over to the 512 kbps ASDL link if the first is saturated.  I'm not sure how to go about doing this as this would be either in side of the PPP set up or some other complex method.  You cold have traffic split across both links too as you control both ends and can reassemble it the way that it needs to be before it is sent out to the world or in to your LAN.

One really nasty what that I could think to make this work would be to set up a default gateway to the IP of the ISP side of the 64 kbps link with a metric of 1 and a default gateway to the IP of the ISP side of the 512 kbps link with a metric of 2.  You would need to watch the rate of traffic flowing out the 64 kbps link and any traffic that would be over it you would need to reject with no route to host which would cause your router to choose the other default route out, in this case the 512 kbps link.  One MAJOR draw back to this that I see is that you would need / want to flush your routing cache fairly often, at least once per minute to make sure that your router would not end up learning that the 64 kbps link had problems and thus start using the 512 kbps link as a de-fac-to standard by remembering that the 64 kbps link did not have a route to any specific host.

Something else that you should consider is that the subnets directly on the other side of each respective link have the best route to them of that said link vs going out the other link and hopping around on the internet to get back in to the first links IPSs network.  Why take the long way around the building around the back to get from one front corner to the other?  This is the type of paradigm that you will be creating.  If this is not an issue you can disregard this statement.

Needless to say there are a lot of issues involved here.  This is not just a simple here you go type of thing.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux