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

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

[Jody Shumaker]

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

I found that for ppp devices, i should ony define the next  hop with the
dev, not a via.  However this still didn't fix my problem, but I've narrowed
down my problem a little further.

# ip route get 66.189.123.136
66.189.123.136 dev ppp0  src 71.248.183.244
    cache  mtu 1492 advmss 1452 metric10 64
# ip route get 66.189.123.137
66.189.123.137 dev ppp0  src 66.189.76.198
    cache  mtu 1492 advmss 1452 metric10 64

It does properly do a 5:1 round robin choice , but only the src changes, not
the dev.  The above I believe should really have outputted for the second
route:
66.189.123.137 dev eth1  src 66.189.76.198
    cache  mtu 1492 advmss 1452 metric10 64

I'm not sure what is wrong with my config, as I've gone over and over it. My
best guess is that something is wrong in the kernel I compiled with the
patches.

# ip rule show
0:      from all lookup local
50:     from all lookup main
201:    from 71.248.183.244 lookup 201
202:    from 66.189.76.198/22 lookup 202
221:    from all lookup 221
32766:  from all lookup main
32767:  from all lookup default

# ip route show table main
10.9.44.15 dev ppp0  proto kernel  scope link  src 71.248.183.244
192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.2
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
66.189.76.0/22 dev eth1  proto kernel  scope link  src 66.189.76.198
127.0.0.0/8 dev lo  scope link

# ip route show table 201
default via 10.9.44.15 dev ppp0  proto static  src 71.248.183.244
prohibit default  proto static  metric 1

# ip route show table 202
default via 66.189.76.1 dev eth1  proto static  src 66.189.76.198
prohibit default  proto static  metric 1

# ip route show table 221
default  proto static
        nexthop via 66.189.76.1  dev eth1 weight 1
        nexthop dev ppp0 weight 5

[-- Attachment #1.2: Type: text/html, Size: 4908 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

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

[Alexander Samad]

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

On Mon, Jan 16, 2006 at 08:59:32PM -0500, Jody Shumaker wrote:
> I found that for ppp devices, i should ony define the next  hop with the
> dev, not a via.  However this still didn't fix my problem, but I've narrowed
> down my problem a little further.
> 
> # ip route get 66.189.123.136
> 66.189.123.136 dev ppp0  src 71.248.183.244
>     cache  mtu 1492 advmss 1452 metric10 64
> # ip route get 66.189.123.137
> 66.189.123.137 dev ppp0  src 66.189.76.198
>     cache  mtu 1492 advmss 1452 metric10 64

doesnt the second ip r g just show you what you have in the route cache,
when I try it on my multi home machine

default  metric 5 
        nexthop via 141.168.16.1  dev eth0 weight 3
        nexthop via 220.233.1.45  dev ppp0 weight 4

but this might be because I don't have the round-robin patch applied to
the kernel.


> 
> It does properly do a 5:1 round robin choice , but only the src changes, not
> the dev.  The above I believe should really have outputted for the second
> route:
> 66.189.123.137 dev eth1  src 66.189.76.198
>     cache  mtu 1492 advmss 1452 metric10 64
> 
> I'm not sure what is wrong with my config, as I've gone over and over it. My
> best guess is that something is wrong in the kernel I compiled with the
> patches.
> 
> # ip rule show
> 0:      from all lookup local
> 50:     from all lookup main
> 201:    from 71.248.183.244 lookup 201
> 202:    from 66.189.76.198/22 lookup 202
> 221:    from all lookup 221
> 32766:  from all lookup main
> 32767:  from all lookup default
> 
> # ip route show table main
> 10.9.44.15 dev ppp0  proto kernel  scope link  src 71.248.183.244
> 192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.2
> 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
> 66.189.76.0/22 dev eth1  proto kernel  scope link  src 66.189.76.198
> 127.0.0.0/8 dev lo  scope link
> 
> # ip route show table 201
> default via 10.9.44.15 dev ppp0  proto static  src 71.248.183.244
> prohibit default  proto static  metric 1
> 
> # ip route show table 202
> default via 66.189.76.1 dev eth1  proto static  src 66.189.76.198
> prohibit default  proto static  metric 1
> 
> # ip route show table 221
> default  proto static
>         nexthop via 66.189.76.1  dev eth1 weight 1
>         nexthop dev ppp0 weight 5

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


[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 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

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

[Jody Shumaker]

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

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

It always is pointing to dev eth1 while with the reverse order it was ppp0.
All this by only changing the order of the nexthops. I went through and
double checked that I did apply julian's patches to the kernel source I last
built with.

- Jody

On 1/16/06, Alexander Samad <alex@samad.com.au> wrote:
>
> On Mon, Jan 16, 2006 at 08:59:32PM -0500, Jody Shumaker wrote:
> > I found that for ppp devices, i should ony define the next  hop with the
> > dev, not a via.  However this still didn't fix my problem, but I've
> narrowed
> > down my problem a little further.
> >
> > # ip route get 66.189.123.136
> > 66.189.123.136 dev ppp0  src 71.248.183.244
> >     cache  mtu 1492 advmss 1452 metric10 64
> > # ip route get 66.189.123.137
> > 66.189.123.137 dev ppp0  src 66.189.76.198
> >     cache  mtu 1492 advmss 1452 metric10 64
>
> doesnt the second ip r g just show you what you have in the route cache,
> when I try it on my multi home machine
>
> default  metric 5
>         nexthop via 141.168.16.1  dev eth0 weight 3
>         nexthop via 220.233.1.45  dev ppp0 weight 4
>
> but this might be because I don't have the round-robin patch applied to
> the kernel.
>
>
> >
> > It does properly do a 5:1 round robin choice , but only the src changes,
> not
> > the dev.  The above I believe should really have outputted for the
> second
> > route:
> > 66.189.123.137 dev eth1  src 66.189.76.198
> >     cache  mtu 1492 advmss 1452 metric10 64
> >
> > I'm not sure what is wrong with my config, as I've gone over and over
> it. My
> > best guess is that something is wrong in the kernel I compiled with the
> > patches.
> >
> > # ip rule show
> > 0:      from all lookup local
> > 50:     from all lookup main
> > 201:    from 71.248.183.244 lookup 201
> > 202:    from 66.189.76.198/22 lookup 202
> > 221:    from all lookup 221
> > 32766:  from all lookup main
> > 32767:  from all lookup default
> >
> > # ip route show table main
> > 10.9.44.15 dev ppp0  proto kernel  scope link  src 71.248.183.244
> > 192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.2
> > 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
> > 66.189.76.0/22 dev eth1  proto kernel  scope link  src 66.189.76.198
> > 127.0.0.0/8 dev lo  scope link
> >
> > # ip route show table 201
> > default via 10.9.44.15 dev ppp0  proto static  src 71.248.183.244
> > prohibit default  proto static  metric 1
> >
> > # ip route show table 202
> > default via 66.189.76.1 dev eth1  proto static  src 66.189.76.198
> > prohibit default  proto static  metric 1
> >
> > # ip route show table 221
> > default  proto static
> >         nexthop via 66.189.76.1  dev eth1 weight 1
> >         nexthop dev ppp0 weight 5
>
> > _______________________________________________
> > LARTC mailing list
> > LARTC@mailman.ds9a.nl
> > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFDzG+WkZz88chpJ2MRAkQJAKDaR/QeqheUntdS2pX/j5IMWoQ5FQCeLX4V
> EHKOXCpr481+FEt8h5bRzDo=
> =ukY3
> -----END PGP SIGNATURE-----
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 6384 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

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

[Alexander Samad]

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

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

> 
> It always is pointing to dev eth1 while with the reverse order it was ppp0.
> All this by only changing the order of the nexthops. I went through and
> double checked that I did apply julian's patches to the kernel source I last
> built with.
> 
> - Jody
> 
> On 1/16/06, Alexander Samad <alex@samad.com.au> wrote:
> >
> > On Mon, Jan 16, 2006 at 08:59:32PM -0500, Jody Shumaker wrote:
> > > I found that for ppp devices, i should ony define the next  hop with the
> > > dev, not a via.  However this still didn't fix my problem, but I've
> > narrowed
> > > down my problem a little further.
> > >
> > > # ip route get 66.189.123.136
> > > 66.189.123.136 dev ppp0  src 71.248.183.244
> > >     cache  mtu 1492 advmss 1452 metric10 64
> > > # ip route get 66.189.123.137
> > > 66.189.123.137 dev ppp0  src 66.189.76.198
> > >     cache  mtu 1492 advmss 1452 metric10 64
> >
> > doesnt the second ip r g just show you what you have in the route cache,
> > when I try it on my multi home machine
> >
> > default  metric 5
> >         nexthop via 141.168.16.1  dev eth0 weight 3
> >         nexthop via 220.233.1.45  dev ppp0 weight 4
> >
> > but this might be because I don't have the round-robin patch applied to
> > the kernel.
> >
> >
> > >
> > > It does properly do a 5:1 round robin choice , but only the src changes,
> > not
> > > the dev.  The above I believe should really have outputted for the
> > second
> > > route:
> > > 66.189.123.137 dev eth1  src 66.189.76.198
> > >     cache  mtu 1492 advmss 1452 metric10 64
> > >
> > > I'm not sure what is wrong with my config, as I've gone over and over
> > it. My
> > > best guess is that something is wrong in the kernel I compiled with the
> > > patches.
> > >
> > > # ip rule show
> > > 0:      from all lookup local
> > > 50:     from all lookup main
> > > 201:    from 71.248.183.244 lookup 201
> > > 202:    from 66.189.76.198/22 lookup 202
> > > 221:    from all lookup 221
> > > 32766:  from all lookup main
> > > 32767:  from all lookup default
> > >
> > > # ip route show table main
> > > 10.9.44.15 dev ppp0  proto kernel  scope link  src 71.248.183.244
> > > 192.168.100.0/24 dev eth1  proto kernel  scope link  src 192.168.100.2
> > > 192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1
> > > 66.189.76.0/22 dev eth1  proto kernel  scope link  src 66.189.76.198
> > > 127.0.0.0/8 dev lo  scope link
> > >
> > > # ip route show table 201
> > > default via 10.9.44.15 dev ppp0  proto static  src 71.248.183.244
> > > prohibit default  proto static  metric 1
> > >
> > > # ip route show table 202
> > > default via 66.189.76.1 dev eth1  proto static  src 66.189.76.198
> > > prohibit default  proto static  metric 1
> > >
> > > # ip route show table 221
> > > default  proto static
> > >         nexthop via 66.189.76.1  dev eth1 weight 1
> > >         nexthop dev ppp0 weight 5
> >
> > > _______________________________________________
> > > LARTC mailing list
> > > LARTC@mailman.ds9a.nl
> > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> >
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2 (GNU/Linux)
> >
> > iD8DBQFDzG+WkZz88chpJ2MRAkQJAKDaR/QeqheUntdS2pX/j5IMWoQ5FQCeLX4V
> > EHKOXCpr481+FEt8h5bRzDo=
> > =ukY3
> > -----END PGP SIGNATURE-----
> >
> >
> >

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


[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 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

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

[Jody Shumaker]

[-- 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

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

[Alexander Samad]

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

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

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


[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 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

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

[Ciprian Constantinescu]

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

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@samad.com.au> 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@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
> > >
> > >
> > >
>
> > _______________________________________________
> > LARTC mailing list
> > LARTC@mailman.ds9a.nl
> > 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@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
>
>


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

[-- Attachment #1.2: Type: text/html, Size: 8161 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

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

[Jody Shumaker]

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

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@gmail.com> 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@samad.com.au> 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.128iif
> > > 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
> > > >
> > > >
> > > >
> >
> > > _______________________________________________
> > > LARTC mailing list
> > > LARTC@mailman.ds9a.nl
> > > 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@mailman.ds9a.nl
> > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> >
> >
> >
>
>
> --
> Ciprian Constantinescu
> mobile: +40745192289
> e-mail: c_ciprian_ro@yahoo.com
> e-mail: c.ciprian@gmail.com
> yahoo messenger: c_ciprian_ro@yahoo.com
> msn messenger: c_ciprian_ro@yahoo.com

[-- Attachment #1.2: Type: text/html, Size: 13294 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