On Thu, 2002-11-21 at 11:11, Andreas Hasenack wrote: > Em Thu, Nov 21, 2002 at 12:46:56PM -0500, Ashok N N escreveu: > > i believe that SNAT is for connections initiated from outside world towards > > the internal network. and this would be reverse of what is intended here, > > That's DNAT. > Correct DNAT is outside in and SNAT is inside out. > > i'm still looking at the code here. AFAIK, the when you have multipath option > > set, then when looking up for a route to an address, among the multiple equal > > cost paths, one is selected according to some criteria (i read random > > somewhere in the kernel but am not able to locate it now). but once the route > > This criteria I would like to understand. >From what I understand it's like this. The whole load balancing thing works in two ways. load balancing outside in request and load balancing inside out request The multipath feature is there so you can have multiple paths from the inside out. Although without the equalize option each route would have to be specified and there really would be no balancing. Equalize along with the weights is what creates the balancing, from request coming from the inside going out. Multipath, equalize, and weights do not effect the incoming requests from the outside world. That are initiated from the outside. That type of load balancing typically is done at the DNS level. Balancing outside to in requests. As for the algorithm to balance from within using multipath and equalize its like this.If you have two routes with equal weights each one will be used half the time. If you have two routes one with weight 1, and the other with 2, then more than likely the first will be used 2 out of 3 times, with the second being used 1 out of 3 times. Or something like that. > > route. so it is kind of a route-based load-balancing. > > Considering that the route cache is 60s by default, this should work I guess. > I'm setting up such a setup for testing. I played around with the cache settings for like a week straight a while back. In the end I reverted to default values and they have worked out fine. > > i read in one of the threads that 'equalize' causes per-packet load balancing, > > i.e looks up the route for each packet. but i am doubtful about the > > performance when each packet causes a route-lookup in the FIB. > > (http://www.uwsg.iu.edu/hypermail/linux/net/0107.3/0028.html) > > Interesting, so 'equalize' bypasses the cache, that's about it? No, it will first look to the catch, and then consult the multipath for the next route/gateway to use when using the equalize option if it does not already exist in the catch. > So we only need to know the criteria with which the route is choosed in a multipath > route. Packet count? Round robin? 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. Once again a DNS thing if the request comes from the outside world. 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. If it was more on a packet level, the other end would be confused. It would be getting responses from an IP it was not expecting response from. I would imagine each side to send redirects, and all sorts of problems. Like it receiving every other packet and dropping the packets in between. I believe the cache also has effect on this. If during a file transfer the route cache is flushed, there is the possibility of the rest of the packets going out a different interface. But at that point all subsequent packets would be going out that interface as well. At some point I would further assume the client to catch on, and finish the transfer at some point. SSH and FTP most likely will not. Not to sure about HTTP, probably protocol dependent 1.0/1.1. This is also what would happen in case of link failure, so if redundancy is your main concern you may want to play with the catch settings. In the end load balancing is not exactly what you might expect it to be. >From the inside world out, you do it via the kernel multipath equalize. The the outside world in you use DNS. Neither does it perfectly or with intelligent algorithms. Neither allow you to use all paths for a single transfer. So if you have two 1.5 mbs connection, you do not end up with a 3.0 mbs line. You do have one internal gateway for both, and if one goes down the other can be used. So you do have redundancy, and both lines can be used to serve difference requests to different places. You also have separate paths, so if ISP1 is closer client1, and ISP2 is closer to client2, each others traffic will not effect the other. Not to mention better transfers due to less distance. But that's it. No bonding or true load balancing. > > > d) OSPF. I read in the RFC that OSPF can do "load balancing", but I failed > > > to understand how (no, I didn't read that RFC thoroughly, it's really high > > > tech for me at this point). Does it use multipath routes to accomplish this? > > Any thoughts on how OSPF does this? Never heard of it, but basically I am only aware of one way. Without having your own public ip block, and different provider routing for your own block. I believe then you would be using BGP or something. > Thanks for your input > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- 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/
