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

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I understand it can work, my point was I want to figure out what is different or wrong with my setup compared to one where it is working.  Would you mind posting the results of
ip rule show
ip route show table all

what kernel version you have, and possibly the output from this command?

for x in $(seq 1 10); do ip r g 1.1.1.$x; done

I'm kind of grasping at straws because everything I've tried short of debugging/hacking the kernel code hasn't worked.

Thanks,
Jody


On 1/17/06, Ciprian Constantinescu <c.ciprian@xxxxxxxxx> wrote:
It works. I have a Debian and the tests were the following:
  1. multiple traceroute to multiple hosts. you can observe the gateway that changes
  2. i run a squid server and i entered http://whatismyip.com multiple times from the same computer in the lan. the ip changed between the 2 providers i have
  3. i run mrtg on the box, so the graph said it all

On 1/18/06, Alexander Samad <alex@xxxxxxxxxxxx> wrote:
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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDzaQ5kZz88chpJ2MRArpVAKDVe8ET7m4Qz09HhxbykV93/meFtACg3bWT
GgOZ8WrUWiAmIT83rrRCRR8=
=7U0w
-----END PGP SIGNATURE-----


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





--
Ciprian Constantinescu
mobile: +40745192289
e-mail: c_ciprian_ro@xxxxxxxxx
e-mail: c.ciprian@xxxxxxxxx
yahoo messenger: c_ciprian_ro@xxxxxxxxx
msn messenger: c_ciprian_ro@xxxxxxxxx

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

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux