* Re: [LARTC] Re: Multi-path routing only using last nexthop in default
2006-01-17 1:59 [LARTC] Re: Multi-path routing only using last nexthop in default Jody Shumaker
@ 2006-01-17 4:16 ` Alexander Samad
2006-01-17 5:37 ` Jody Shumaker
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Alexander Samad @ 2006-01-17 4:16 UTC (permalink / raw)
To: lartc
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: Multi-path routing only using last nexthop in default
2006-01-17 1:59 [LARTC] Re: Multi-path routing only using last nexthop in default Jody Shumaker
2006-01-17 4:16 ` Alexander Samad
@ 2006-01-17 5:37 ` Jody Shumaker
2006-01-17 19:23 ` Alexander Samad
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Jody Shumaker @ 2006-01-17 5:37 UTC (permalink / raw)
To: lartc
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: Multi-path routing only using last nexthop in default
2006-01-17 1:59 [LARTC] Re: Multi-path routing only using last nexthop in default Jody Shumaker
2006-01-17 4:16 ` Alexander Samad
2006-01-17 5:37 ` Jody Shumaker
@ 2006-01-17 19:23 ` Alexander Samad
2006-01-17 21:53 ` Jody Shumaker
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Alexander Samad @ 2006-01-17 19:23 UTC (permalink / raw)
To: lartc
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: Multi-path routing only using last nexthop in default
2006-01-17 1:59 [LARTC] Re: Multi-path routing only using last nexthop in default Jody Shumaker
` (2 preceding siblings ...)
2006-01-17 19:23 ` Alexander Samad
@ 2006-01-17 21:53 ` Jody Shumaker
2006-01-18 2:13 ` Alexander Samad
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Jody Shumaker @ 2006-01-17 21:53 UTC (permalink / raw)
To: lartc
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: Multi-path routing only using last nexthop in default
2006-01-17 1:59 [LARTC] Re: Multi-path routing only using last nexthop in default Jody Shumaker
` (3 preceding siblings ...)
2006-01-17 21:53 ` Jody Shumaker
@ 2006-01-18 2:13 ` Alexander Samad
2006-01-18 2:22 ` Ciprian Constantinescu
2006-01-18 4:59 ` Jody Shumaker
6 siblings, 0 replies; 8+ messages in thread
From: Alexander Samad @ 2006-01-18 2:13 UTC (permalink / raw)
To: lartc
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: Multi-path routing only using last nexthop in default
2006-01-17 1:59 [LARTC] Re: Multi-path routing only using last nexthop in default Jody Shumaker
` (4 preceding siblings ...)
2006-01-18 2:13 ` Alexander Samad
@ 2006-01-18 2:22 ` Ciprian Constantinescu
2006-01-18 4:59 ` Jody Shumaker
6 siblings, 0 replies; 8+ messages in thread
From: Ciprian Constantinescu @ 2006-01-18 2:22 UTC (permalink / raw)
To: lartc
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: Multi-path routing only using last nexthop in default
2006-01-17 1:59 [LARTC] Re: Multi-path routing only using last nexthop in default Jody Shumaker
` (5 preceding siblings ...)
2006-01-18 2:22 ` Ciprian Constantinescu
@ 2006-01-18 4:59 ` Jody Shumaker
6 siblings, 0 replies; 8+ messages in thread
From: Jody Shumaker @ 2006-01-18 4:59 UTC (permalink / raw)
To: lartc
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread