Re: Re: Multi-path routing only using last nexthop in default route.

[Jody Shumaker <jody.shumaker@xxxxxxxxx>]

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@xxxxxxxxxxxx> 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

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