On Thu, 2002-11-21 at 15:41, Christoph Simon wrote: > On 21 Nov 2002 15:07:11 -0800 > "William L. Thomson Jr." <support@obsidian-studios.com> wrote: > > > > Not necessarily. I have two lines going in completely different > > directions, different private nets, and then via different ISP/Public > > IPs. > > Two lines in different directions using equalize? What's the point of > this? Once again let me clarify myself. By different directions I mean different ISPs. Not incoming from one and outgoing on another. It's more having two separate connections to the Internet with two separate ISPs. That's what I mean by two different directions. One of my ISPs is North of me, the other is South. So if I were to say send out a mass mailer or god forbid spam, I could use both lines from the inside to send data out. Same page now? Sorry bout that. > > > > Now if the request was generated from the inside it would still work > > > > some what the same. If I send two emails out at once, the first will > > > > use gw1 and the other will use gw2. > > > > > > > > All packets for each will travel via the same route and use the same > > > > gateway from start to finish. > > > > > > Not using equalize. > > > > Yes using equalize, because the path will already be known and used from > > catch. Correct that if a further look up occurs the packets will use a > > different interface, but that is rare. Most of the time during a > > transfer the route is already known and kept in catch from the first > > initial lookup. > > I didn't play too much with equalize, but using it for load balancing > and redundancy failed for reason by with equalize is defined. Yes for true redundancy the routes need to be removed and then added back or to stop being used. I believe that's were Julian's dead gateway detection stuff comes in. > As far > as I understood how weighting works: There are several identic routes > so that the probability to pick one of them corresponds to the given > weights. Still on a packet base. With equalize, the balancing should > be perfect, which can never be the case with few connections, even if > they imply massive data transfer. But if there is no NAT later, it > just can't work. Correct based on weights using equalize. Because without equalize it will just travel the first route no matter what unless a route using the second is already know and existing in cache. From the inside balancing is basically perfect using equalize. It's code I mean it does what it's is supposed to do but is not smart. If one line is being used more than another from the outside, it will still balance things from the inside. Even thought one line is being bogged down. Even if you say have two rather large unequal files to send out, it will send the first file out one, and the second file out the other, and then keep going back and forth equally if the weights are equal. Even though the actual load is not equal. In my case I am doing NAT, and it is part of the reason why things work, along with Julian's patches. But I have been informed I believe by Julian and others that the load balancing, multipath equalize feature can be used even without NAT but in a different situation that mine? > > > unless there is a routing cache which will hold the path. > > > > That's the problem. The route cache on the Linux load balancing router > > will be correct, but the route cache on the client will not be. > > If "client" here is a computer reaching the internet through the linux > router (it can't be anything else, because you said that there are two > independent lines out of your control), and unless that client uses > source routing which might be ignored by the linux router, the > client's view of this situation really doesn't matter. By client I mean someone in the outside world talking to say a server. The server is behind the Linux router. Not a client on the local lan looking out. > > The client will be caching the wrong path. So unless a redirect is sent > > the client will site there and expect further communication using the > > route in cache. > > The client will cache the route which leads to the Linux router and > not bother with details happening later. I am talking about the client caching the wrong public ip and communication being attempted on a separate public ip from the server. While the client sits there and times out on the first ip, when ever it's cache expires. -- Sincerely, William L. Thomson Jr. Support Group Obsidian-Studios Inc. 439 Amber Way Petaluma, Ca. 94952 Phone 707.766.9509 Fax 707.766.8989 http://www.obsidian-studios.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
