Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

For testing purposes (testing raw network speed over a number of cables) i have equippped my Mac Book pro with a Thunderbolt to Gigabit Ethernet Adapter besides the built-in gigabit ethernet connection.

Both interfaces have been assigned a manual IP in the 10.0.*/24 range.

Starting iperf with iperf -s --bind, then starting the client with iperf -c yields speeds of over 40 Gigabit per second. I assume (correctly so according to some googling) that not the interface itself is used but rather the local loopback interface as both IPs reside on the same computer. So my thought was to disable lo0, even just temporarily by issuing sudo ifconfig lo0 down. Thies doesn't work (it might have worked once for a few seconds but I can't prove that). lo0 just stays up.

Is there a way to (temporarily) disable the local loopback interface lo0 so I can do my tests?


share|improve this question
I'd suspect that disabling lo0 might have unintended consequences, so it might be better to find another way to accomplish your goal... change the routing tables so doesn't go through lo0, perhaps? I was going to suggest binding the server and client to different interfaces but that didn't make a difference in my test. –  gabedwrds Jul 3 '13 at 8:11
Where do you expect the ethernet packets to flow through once you've disabled lo0? From the Thunderbolt adapter to the built-in port? –  patrix Jul 3 '13 at 8:21
@patrix Yes. That way iperf would measure the actual throughput the cables can "handle". –  Christian Jul 3 '13 at 8:32
@gabedwrds I rather highly expect disabling lo0 to have, again, rather bad consequences, but it appeared the only solution. iperf knows how to bind to an IP (I`ll edit my request above because I actually used that option), but the kernel seems to outsmart it. One IP belongs to en0, the built-in interface, the other to en3, the Thunderbolt-to-Gigabit-Ethernet adapter. –  Christian Jul 3 '13 at 8:34
How do you want to force iperf to use the two interfaces (one for the server, one for the client)? –  patrix Jul 3 '13 at 9:11
show 3 more comments

1 Answer

The version of iperf I have (from Homebrew) does indeed allow binding the client and server to different interfaces, like so:

iperf -s --bind
iperf -c --bind

(for the purpose of this answer I assume that you want the server on .1 and the client on .2)

The problem is that the routing table (visible through netstat -rn) appears to override this, sending traffic to through the loopback interface.

Rather than disabling loopback altogether, you can delete that specific route:

sudo route delete

I found that this caused my Mac to be unable to reach itself (on that IP) for a few seconds, until it found an alternate route out the other interface and through my router. Once that route showed up in netstat -rn, iperf worked fine. Here's my before and after:

[  4] local port 5001 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  16.7 GBytes  14.3 Gbits/sec

And after:

[  4] local port 5001 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   343 MBytes   288 Mbits/sec

288Mbps being a fairly reasonable speed considering that one of the interfaces in use is 802.11n wireless.

I was also able to return my routing table to normal by simply toggling the interface off and on again.

share|improve this answer
Thanks, a sound idea, except: It doesn't seem to work on my end... Before deleting the route I get 42.5 Gbits/sec, after deleting the route I get 4.12 Gbits/sec - regardless of using a simple cable or my handy mini-switch which is only fast ethernet (the connection status correctly shows 100baseT). And that clearly is not possible. –  Christian Jul 4 '13 at 8:04
That is odd. Does iperf correctly identify the two IPs, just to confirm that both sides are bound to different interfaces? ("local ... connected with")? Do you get the same result going both ways (client on 1, server on 2 vs client on 2, server on 1)? –  gabedwrds Jul 5 '13 at 2:42
Yes, the IPs are confirmed and yes, both ways. What's particularly odd is that the "kernel" route gives 40 GBit/sec, this way I get 4 GBit/sec - and the network shouldn't be able to deliver more then 1 GBit/sec or even 100 MBit/sec at all... Mysterious ways... –  Christian Jul 5 '13 at 6:16
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.