Re: [LARTC] Re: Multi-path routing only using last nexthop in default

From: Jody Shumaker <jody.shumaker@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Re: Multi-path routing only using last nexthop in default
Date: Tue, 17 Jan 2006 21:53:06 +0000	[thread overview]
Message-ID: <2af436490601171353o7bed72cbl1ca5ac4830a91dfa@mail.gmail.com> (raw)
In-Reply-To: <2af436490601161759l3a452733s7bc93c14fde96b09@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 3031 bytes --]

Does anyone have a confirmed to be working multipath setup? I'd like to see
their route output and confirm that this really is an issue.  The issue
might actually be something else and this output is expected? I'm just
sticking on this because the order of nexthops is what changes the behavior,
which seems wrong.

Also, if I try retieving paths from an internal address to an external, it
will always use only the last nexthop.

# for x in $(seq 1 10); do ip route get 66.1.1.$x from 192.168.0.128 iif
eth0; done
66.1.1.1 from 192.168.0.128 dev ppp0  src 192.168.0.1
    cache <src-direct>  mtu 1492 advmss 1452 metric10 64 iif eth0
66.1.1.2 from 192.168.0.128 dev ppp0  src 192.168.0.1
    cache <src-direct>  mtu 1492 advmss 1452 metric10 64 iif eth0
etc.

I'm using 2.6.14-gentoo-r5 #4 SMP PREEMPT w/ julian's patches and iptables
v1.3.4

- Jody

On 1/17/06, Alexander Samad <alex@samad.com.au> wrote:
>
> On Tue, Jan 17, 2006 at 12:37:48AM -0500, Jody Shumaker wrote:
> > Yes, it just shows you what is in the cache, but I was specifying ip
> > addresses that weren't in the cache yet. I also tried doing traceroutes
> from
> > an internal pc, and those always ended up going over the 1 interface.
> I've
> > also tried adjusting the weights to 1:1 and opening up numerous
> connections
> > to multiple ftp's.
> >
> > Also for comparison, if I change the order of the nexthop's I'll instead
> get
> > effectively the reverse.
> >
> > # ip route get 66.1.1.11
> > 66.1.1.11 via 66.189.76.1 dev eth1  src 71.248.183.63
> >     cache  mtu 1500 advmss 1460 metric10 64
> > # ip route get 66.1.1.12
> > 66.1.1.12 via 66.189.76.1 dev eth1  src 66.189.76.198
> >     cache  mtu 1500 advmss 1460 metric10 64
>
> your right I tried it on my machine
> for x in $(seq 1 10); do ip r g 1.1.1.$x; done
> 1.1.1.1 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.2 via 220.233.1.45 dev ppp0  src 141.168.16.16
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.3 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.4 via 220.233.1.45 dev ppp0  src 141.168.16.16
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.5 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.6 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.7 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.8 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.9 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
> 1.1.1.10 via 220.233.1.45 dev ppp0  src 220.233.15.63
>     cache  mtu 1492 advmss 1452 metric 10 64
>
> just the src address is changing, I am pretty sure this used work at
> some point in time, i am using 2.6.14-1-smp, iptables v1.3.3
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 5411 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc