All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damion de Soto <damion@snapgear.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] redundancy and multipath routing.
Date: Fri, 15 Aug 2003 04:34:13 +0000	[thread overview]
Message-ID: <marc-lartc-106092217228412@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106065875315797@msgid-missing>

S Mohan wrote:
> [Question 1]
> Am I wrong? Is my interpretation of metrics wrong?
yes and yes, but it's a common mistake.
packets will still use the lower metric if the route exists.
until the kernel knows the route/interface is dead and removes it, your metric 2 
default route won't do anything.

> [Result 2]
> Giving a ping here had the same results as in [Result 1]. I expected each
> ping packet to have different latency switching between 450 and 750ms. Did
> not happen. Latency was 750ms consistently.
> [Case 3]
> The above weight go by flows and not packets. Maybe a single single ping is
> treated as one flow. I changed the multipath to include equalize using
> commands as under:

does anyone know the difference between using the equalize command, and not ?
I haven't been able to work it out.

> [Result 3]
> Same as [Result 1] and [Result 2]. Atleast here I should have got latencies
> switching between 450 and 750ms for alternating ICMP requests.
probabaly not.

> [Questions]
> 1. Is this method of testing correct?
> 2. Are there any other utilities/ methodologies that I can use to test this
> better?
> 3. Is expecting load balancing/ redundancy to happen for a single flow
> wrong?
you're better off testing with machines behind the LEAF machine.

doing load balancing/multipath stuff the way you are doesn't work particularly well
for a single machine. especially the router itself.

using the equalize route method, you should start to see packets alternate routes on 
both links.  if all your requests are going out from the same machine, you may see it 
use one link more than the other.
if you have numerous machines behind the router, eventually it should balance out.

also, you'll probabaly need source-based routing for the return paths, unless your 
ISPs are doing tricky things.

the equalise route method also doesn't give real fail-over.  if one link goes down, 
every second packet/connection/flow/blah will still try to go out it.

if you want real fail-over with load balancing, perhaps you should look here:

http://www.ssi.bg/~ja/#multigw


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear ---                           ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

      reply	other threads:[~2003-08-15  4:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-12  3:41 [LARTC] redundancy and multipath routing S Mohan
2003-08-15  4:34 ` Damion de Soto [this message]

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-106092217228412@msgid-missing \
    --to=damion@snapgear.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 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.