Re: Re: [LARTC] multipath routing problem [Shorter version] - Help

[Vincent Jaussaud <tatooin@kelkoo.com>]

On Mon, 2002-10-28 at 23:21, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On 28 Oct 2002, Vincent Jaussaud wrote:
> 
> > My question is, if we ensure that EVERY packets, whatever path they use
> > to arrive, finally pass through a single peer doing NAT, is this suppose
> > to work around my TOS problem ?
> 
> 	Sounds correct. The requirement is each packet from one
> connection to be NAT-ed only from one NAT router and to same
> masquerade address and port. The routing cache can not guarantee
> that. It can be done only from the patched masquerade.
> 
Hmmm.. then that's why it doesn't work.. final gateway doing NAT isn't
patched, only the first one is.

I think I'll have to drop the idea of using both gateways
simultaneously.
Now, If I only want do to fail-over (eg; only one gateway used at the
same time, other one used only in case the first one breaks.)

I was thinking about using the metric value for this.

Let's say:

ip route add table dual-gw proto static 192.168.0.0/24 via GW1 dev eth1
metric 1
ip route add table dual-gw proto static 192.168.0.0/24 via GW2 dev eth1
metric 2

I assume the kernel will always use the best route, that is the one with
best metric. So that all packets will use the same route. 
If GW1 breaks, patched kernel should mark first route as dead, and force
all further packets to use GW2 instead.

Is this suppose to work ? Or can we use different metric value inside a
multipath route, like:

ip route add table dual-gw proto static 192.168.0.0/24 nexthop via GW1
dev eth1 metric 1 nexthop via GW2 dev eth1 metric 2

?

Anyway, the more I think about this setup, the more I think I should use
a clustering solution instead. Maybe a cluster of gateway with one VIP
is much more appropriate for what I want to build. I'll use multipath
routing for ISP redundency then :)

Thanks to both of you, I've learn a lot during the last past few days,
this was one of my main concern too.

Thanks again.
Cheers,
Vincent.

> > What about the rp_filter kernel value ? Could it be a problem in such
> > setup ?
> 
> 	The patches are designed to work with rp_filter enabled.
> You can safely use it, it is changed to work only with the defined
> paths.
> 
> > Thanks again.
> > Vincent.
> 
> Regards
> 
> --
> Julian Anastasov <ja@ssi.bg>
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-- 
Vincent Jaussaud
Kelkoo.com Security Manager 
email: tatooin@kelkoo.com

"The UNIX philosophy is to design small tools that do one thing, and do
it well."

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/