1

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 10.0.0.1, then starting the client with iperf -c 10.0.0.1 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?

Thanks!

Improve this question
8
  • 1
    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 10.0.0.1 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
    Commented Jul 3, 2013 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?
    – nohillside ♦
    Commented Jul 3, 2013 at 8:21
  • @patrix Yes. That way iperf would measure the actual throughput the cables can "handle".
    – Christian
    Commented Jul 3, 2013 at 8:32
  • 1
    @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 (Ill 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
    Commented Jul 3, 2013 at 8:34
  • How do you want to force iperf to use the two interfaces (one for the server, one for the client)?
    – nohillside ♦
    Commented Jul 3, 2013 at 9:11

1 Answer 1

Reset to default
3

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

iperf -s --bind 10.0.0.1
iperf -c 10.0.0.1 --bind 10.0.0.2

(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 10.0.0.1 through the loopback interface.

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

sudo route delete 10.0.0.1 127.0.0.1

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 192.168.2.99 port 5001 connected with 192.168.2.101 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  16.7 GBytes  14.3 Gbits/sec

And after:

[  4] local 192.168.2.99 port 5001 connected with 192.168.2.101 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.

Improve this answer
3
  • 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
    Commented Jul 4, 2013 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 10.0.0.2 ... connected with 10.0.0.1")? Do you get the same result going both ways (client on 1, server on 2 vs client on 2, server on 1)?
    – gabedwrds
    Commented Jul 5, 2013 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
    Commented Jul 5, 2013 at 6:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .