The caching is per destination and source ip. TOS, fwmark and input interface too, if present. Routing with netfilter does not solve cache problems anyway, cache will still be present, and it will be consulted before routing tables are hit. In my opinion, routing in netfilter gives more flexibility in dynamically choosing weights and such. But multipath routing gives a bit more IP persistence. Both solutions work pretty well; there are die-hard fans for both of the above approaches. Recent archives of lartc have lot of discussions on it. > -----Original Message----- > From: lartc-bounces@xxxxxxxxxxxxxxx [mailto:lartc-bounces@xxxxxxxxxxxxxxx] > On Behalf Of Grant Taylor > Sent: Wednesday, June 27, 2007 10:08 AM > To: Mail List - Linux Advanced Routing and Traffic Control > Subject: Re: Load Balance and SNAT problem. > > On 6/26/2007 9:03 PM, Mohan Sundaram wrote: > > The caching would be per destination IP - so it is likely all clients > > will use the same route and thus interface. > > This could be a problem. I was taking the caching to be remembering > which route was chosen and believing it to be associated with a specific > source IP address. I can see this being a very large issue when trying > to do load balancing. > > In light of this information, I think that better could be done in > Netfilter. However if there ever was a way to have route selection per > source IP in the kernel, I would be more interested in that. > > I wonder if route selection caching would be different in different > routing tables. In other words use a different routing table for a > different (set of) clients. Thus one cached routing decision per > routing table which could differ per routing table. > > > > Grant. . . . > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
