On Thu, 2002-11-21 at 14:55, Christoph Simon wrote: > On 21 Nov 2002 14:20:57 -0800 > "William L. Thomson Jr." <support@obsidian-studios.com> wrote: > > > Also I do not believe the load balancing is packet based. Usually it's > > more "connection" based. Meaning that if you request a file, more than > > likely all parts of that file will be transfered using the same route. > > If you request it again, it may take the same route or another. > > It is packet based. There is no connection concept in IP. That's why I put that word in quotes. I meant more like during a file transfer than with a connection in the true sense. > >From the IP Command Reference: > > equalize: allow packet by packet randomization on multipath > routes. > > My understanding is, that for equalize to work, all lines must go to > the same point and that must not be the end point. Also, this same > point must implement the equalize very much the same way. Not necessarily. I have two lines going in completely different directions, different private nets, and then via different ISP/Public IPs. Now for true load balancing or bonding yes. Both lines would need to be coming from and going to the same ISP. > > 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 have not run into any problems along those lines. > > If it was more on a packet level, the other end would be confused. > > 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. 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. When I was experimenting with route cache timing in the Linux kernel, I had all kinds of problems on the client side. The client's catch settings would need to be the same as the linux router. Which is pretty impossible on the Internet. On a lan it would be a different story. -- 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/
