From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Samad Date: Wed, 18 Jan 2006 02:13:13 +0000 Subject: Re: [LARTC] Re: Multi-path routing only using last nexthop in default Message-Id: <20060118021313.GF10902@samad.com.au> MIME-Version: 1 Content-Type: multipart/mixed; boundary="===============0707536376==" List-Id: References: <2af436490601161759l3a452733s7bc93c14fde96b09@mail.gmail.com> In-Reply-To: <2af436490601161759l3a452733s7bc93c14fde96b09@mail.gmail.com> To: lartc@vger.kernel.org --===============0707536376== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p8PhoBjPxaQXD0vg" Content-Disposition: inline --p8PhoBjPxaQXD0vg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 s= ee > 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 behavi= or, > 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 >=20 > Also, if I try retieving paths from an internal address to an external, it > will always use only the last nexthop. >=20 > # 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 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 mtu 1492 advmss 1452 metric10 64 iif eth0 > etc. >=20 > I'm using 2.6.14-gentoo-r5 #4 SMP PREEMPT w/ julian's patches and iptables > v1.3.4 >=20 > - Jody >=20 > On 1/17/06, Alexander Samad 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 tracerout= es > > 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 inst= ead > > 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 --p8PhoBjPxaQXD0vg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDzaQ5kZz88chpJ2MRArpVAKDVe8ET7m4Qz09HhxbykV93/meFtACg3bWT GgOZ8WrUWiAmIT83rrRCRR8= =7U0w -----END PGP SIGNATURE----- --p8PhoBjPxaQXD0vg-- --===============0707536376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc --===============0707536376==--