Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Vincent Jaussaud <tatooin@kelkoo.com>
To: lartc@vger.kernel.org
Subject: Re: Re: [LARTC] multipath routing problem [Shorter version] - Help
Date: Fri, 25 Oct 2002 15:31:52 +0000	[thread overview]
Message-ID: <marc-lartc-103555995420076@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103555678715833@msgid-missing>

On Fri, 2002-10-25 at 16:55, Julian Anastasov wrote:
> 
> 	Hello,
Hi julian !

> 
> On 25 Oct 2002, Vincent Jaussaud wrote:
> 
> > > ssh tends to play with TOS fields (and rightly so). Routing is keyed to the
> > > *triple* (src, dst, tos), something that most people (including me) normally
> > > forget. However, in this particular case that may be the reason for your
> > > ssh's breaking.
> > >
> > Hmm... that's really interesting. Thanks for the pointer. I remember now
> > that I've read something regarding SSH & TOS field some days ago. If I'm
> > right, it use the Minimum Delay TOS value.
> >
> > Now, how am I suppose to deal with this TOS issue ? What TOS value
> > should do the trick ?
> 
> 	In theory, you should not reach multipath route for
> traffic that is already NAT-ed. May be you have to fix your
> routes. The TOS field plays in the input routing performed
> on forwarding and traffic between two public IP addresses can select
> different nexthop if the TOS is different or if the routing
> cache is somehow flushed (on route/address add/del, expiration).

But traffic is NAT-ed after multipath routing occurs !
Eg, the box which do multipath routing do not NAT traffic; traffic get
NAT-ed when leaving the gateways:

LAN --> FW w/ multipath-routing 
	   |		|
	  Gateway1  Gateway2
	   | (NAT)	| (NAT) 
	   |		|
	-------------------- Remote Network
	
Packets reach the Remote Network using one of the Gateway NAT-ed IP, so
that when packets come back they should use the proper return path. Am I
wrong ?  

> 
> > I'm using a 2.2 kernel with ipchains.
> >
> > > The reason for FTP breaking possibly has to do with packets for
> > > the control connection going out the one gateway and for the data going
> > > out the other... but this is speculation on my part.
> >
> > That sounds wise. However, routes are suppose to be cached using the src
> > IP field as well (If I'm not mistaken), so that every packets coming
> > from a particular IP are likely to take the same route than the others.
> > Am I wrong ?
> 
> 	Yes, TOS is a routing key just like SADDR and DADDR.
> By using multipath route between 2 IP addresses you agree that
> the packets can _safely_ choose any of the paths. When using
> two or more ISPs you simply can't do this if the ISPs have
> source spoofing disabled. In such cases only the traffic that
> is NAT-ed from your box has the right to use the multipath route.
> This is a key requirement for the patches you are using. Once
> the NAT connections are established they don't hit multipath
> route.
> 
Hmmm... Then this is where the problem is. So, if I understand
correctly, packets coming from a single TCP connections will use any of
the multipath route _if_ they are not NAT-ed ? Isn't the routing cache
suppose to ensure that every packets coming from a single connection use
the same path ?

Now, If I understand the whole topic, in order to fix my problem, I need
to:

	- NAT everything on the FW itself
	- or disable NAT on both gateways, and ensure that routing is done
properly


Am I right ? I'm becomming a bit lost, here :-\

Many Thanks for your time.
Vincent.

> > A BIG Thanks for your reply :-)
> > Cheers,
> > 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/

  parent reply	other threads:[~2002-10-25 15:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-25 14:38 Re: [LARTC] multipath routing problem [Shorter version] - Help Vincent Jaussaud
2002-10-25 14:55 ` Julian Anastasov
2002-10-25 15:31 ` Vincent Jaussaud [this message]
2002-10-25 16:12 ` Julian Anastasov
2002-10-25 18:15 ` Vincent Jaussaud
2002-10-25 18:17 ` Arthur van Leeuwen
2002-10-25 18:21 ` Arthur van Leeuwen
2002-10-25 18:44 ` Vincent Jaussaud
2002-10-25 18:45 ` Julian Anastasov
2002-10-25 19:13 ` Vincent Jaussaud
2002-10-25 19:28 ` Julian Anastasov
2002-10-28 14:29 ` Vincent Jaussaud
2002-10-28 22:21 ` Julian Anastasov
2002-10-29 16:32 ` Vincent Jaussaud
2002-10-29 22:31 ` Julian Anastasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-103555995420076@msgid-missing \
    --to=tatooin@kelkoo.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox