On Tue, Jan 17, 2006 at 04:53:06PM -0500, Jody Shumaker wrote: > 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. I think mine is working, because I se traffic heading out of the second interface (ones that I know have originated from my box), plus when I check the cache table there are entries for both interfaces. just can't prove it right now 8( A > > 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
