All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julian Anastasov <ja@ssi.bg>
To: lartc@vger.kernel.org
Subject: Re: Re: [LARTC] multipath routing problem [Shorter version] - Help
Date: Fri, 25 Oct 2002 14:55:16 +0000	[thread overview]
Message-ID: <marc-lartc-103555809817621@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103555678715833@msgid-missing>


	Hello,

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).

> 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.

> 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/

  reply	other threads:[~2002-10-25 14:55 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 [this message]
2002-10-25 15:31 ` Vincent Jaussaud
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-103555809817621@msgid-missing \
    --to=ja@ssi.bg \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.