<div dir="ltr">Ondrej,<div><br></div><div>Thanks for pointing toward the directions of route cache. I think you might be right about the cache, even though there are multiple cache entries for 10.25.14.20 (the server) in this case, there's still only one path selected for each destination i.e. instead of multiple path for each destination...</div>
<div><br></div><div><div>10.25.14.20 via 10.25.206.69 dev eth1  src 10.25.206.70 </div><div>    cache  used 3 age 38sec ipid 0xfe2e rtt 40ms rttvar 10ms ssthresh 4081 cwnd 7935</div><div><br></div><div>10.25.14.20 via 10.25.205.69 dev eth0  src 10.25.205.70 </div>
<div>    cache  used 13 age 4sec ipid 0xfe2e rtt 40ms rttvar 10ms ssthresh 4081 cwnd 7935</div></div><div><br></div><div style>I think the problem is more with the way the client selected the interface to use then the route cache in this case. For example, you see that 10.25.205.70 interface is selected here instead of dividing the threads into multiple interfaces between 10.25.205.70 and 10.25.206.70 in which this host have two physical connections. I'm wondering if there is a way to ties say the dummy0 interface so that if you point traffic toward it, it will hash it across two physical links...</div>
<div style><br></div><div style><div>------------------------------------------------------------</div><div>Client connecting to 10.25.14.20, TCP port 5001</div><div>TCP window size: 64.0 KByte (default)</div><div>------------------------------------------------------------</div>
<div>[  6] local 10.25.205.70 port 52606 connected with 10.25.14.20 port 5001</div><div>[  4] local 10.25.205.70 port 52603 connected with 10.25.14.20 port 5001</div><div>[  5] local 10.25.205.70 port 52605 connected with 10.25.14.20 port 5001</div>
<div>[  3] local 10.25.205.70 port 52604 connected with 10.25.14.20 port 5001</div><div><br></div><div style>These nodes are not setup for transit traffic but I'm wondering how the through transit traffic would look and how the kernel would decide how to balance the traffic or it would pick one instead of two..</div>
<div style><br></div></div></div><div class="gmail_extra"><br clear="all"><div>-bn<br>0216331C</div>
<br><br><div class="gmail_quote">On Tue, May 7, 2013 at 1:13 AM, Ondrej Zajicek <span dir="ltr"><<a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, May 06, 2013 at 06:50:10PM -0700, Bao Nguyen wrote:<br>
> >From host A I do "iperf -c x.x.x.x -P 4" to host B's dummy0 interface, host<br>
> A iperf seemed to pick a single eth0 or eth1 but not both interfaces and<br>
> use it to send out traffic on all 4 difference processes. Ideally how would<br>
> one allow a single application (in this case iperf) with multiple<br>
> threads/processes to send 2Gbit worth of traffic? Ideally to a logical<br>
> interface and it's hash automatically to two difference eth0 and eth1?<br>
<br>
</div>AFAIK Linux kernel implements ECMP in a way that for each route cache<br>
entry just one path is used (and fixed in route cache). I heard that<br>
there are patches for different behavior. I don't know how this behavior<br>
differs on newer kernels without route cache. Without the current<br>
behavior, an application could use different addresses or ports for each<br>
thread to use multiple threads, i guess. Or use something completely<br>
different, like link-level interface bonding.<br>
<div class="im"><br>
> I've looked at setting (krt_prefsrc) to source the address as the dummy0<br>
> interface on each host. Would that be the answer?<br>
<br>
</div>Probably not (although it is probably useful anyway).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'SanTiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</font></span><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
<br>
iEYEARECAAYFAlGIt6QACgkQw1GB2RHercP+UACfZhlP0L9VbQ9pU281fmRGIj0G<br>
a3IAn1yeE9uPcY/NUbM9lm0bepkVJKNr<br>
=8shF<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br></div>