Andrew,
I did not spend enough time reading your first post and missed the fact
your box is trying to send packets to itself back to back. Sorry I pointed
you in the wrong direction (I thought you "only" had two interfaces
connected to the same subnet, another interesting problem)
Back to your problems: it is very difficult to force Linux to send packets
outside and back to itself. That's because it is a massive waste of
resources and loss of performance. Fortunately this has been discussed
already here and elsewhere; Google is your friend. See for instance:
http://serverfault.com/questions/127636/force-local-ip-traffic-to-an-external-interface
Cheers,
Marc
2012/4/17 Andrew M <and...@oc384.net>
> Yes it's linux. arp_filter sounded like a good place to start but it
> didn't fix the issue. I still get this:
>
> [root@scooby ~]# ifconfig em1 192.168.123.1
> [root@scooby ~]# ifconfig em2 192.168.234.1
>
> [root@scooby ~]# iperf -p 777 -B192.168.234.1 -c192.168.123.1
> ------------------------------**------------------------------
> Client connecting to 192.168.123.1, TCP port 777
> Binding to local address 192.168.234.1
> TCP window size: 169 KByte (default)
> ------------------------------**------------------------------
> [ 3] local 192.168.234.1 port 777 connected with 192.168.123.1 port 777
> [ ID] Interval Transfer Bandwidth
> [ 3] 0.0-10.0 sec 20.8 GBytes 17.9 Gbits/sec
>
> Ideas?
>
> Thanks...
>
>
>
>
> On 4/17/2012 2:42 AM, Marc Herbert wrote:
>
>> Is this Linux? If yes try enabling arp_filter. I suspect iperf binds
>> to an address, not to an interface.
>>
>> http://www.kernel.org/doc/**Documentation/networking/ip-**sysctl.txt<http://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt>
>>
>> arp_filter - BOOLEAN
>> 1 - Allows you to have multiple network interfaces on the same
>> subnet, and have the ARPs for each interface be answered
>> based on whether or not the kernel would route a packet from
>> the ARP'd IP out that interface (therefore you must use source
>> based routing for this to work). In other words it allows control
>> of which cards (usually 1) will respond to an arp request.
>>
>> 0 - (default) The kernel can respond to arp requests with addresses
>> from other interfaces. This may seem wrong but it usually makes
>> sense, because it increases the chance of successful communication.
>> IP addresses are owned by the complete host on Linux, not by
>> particular interfaces. Only for more complex setups like load-
>> balancing, does this behaviour cause problems.
>>
>> arp_filter for the interface will be enabled if at least one of
>> conf/{all,interface}/arp_**filter is set to TRUE,
>> it will be disabled otherwise
>>
>>
>>
>> 2012/4/17 Andrew M<and...@oc384.net>
>>
>>>
>>> I have two network interfaces in one host:
>>> em1 192.168.123.1
>>> em2 192.168.234.1
>>>
>>> I'm running:
>>>
>>> SERVER:
>>> [root@scooby ~]# iperf -fm -p 777 -B192.168.123.1 -s
>>> ------------------------------**------------------------------
>>> Server listening on TCP port 777
>>> Binding to local address 192.168.123.1
>>> TCP window size: 0.08 MByte (default)
>>> ------------------------------**------------------------------
>>> [ 4] local 192.168.123.1 port 777 connected with 192.168.234.1 port 777
>>> [ ID] Interval Transfer Bandwidth
>>> [ 4] 0.0-10.0 sec 24396 MBytes 20444 Mbits/sec
>>> [ 5] local 192.168.123.1 port 777 connected with 192.168.234.1 port 777
>>> [ 5] 0.0-10.0 sec 20761 MBytes 17410 Mbits/sec
>>>
>>> CLIENT:
>>> [root@scooby ~]# iperf -p 777 -B192.168.234.1 -c192.168.123.1
>>> ------------------------------**------------------------------
>>> Client connecting to 192.168.123.1, TCP port 777
>>> Binding to local address 192.168.234.1
>>> TCP window size: 169 KByte (default)
>>> ------------------------------**------------------------------
>>> [ 3] local 192.168.234.1 port 777 connected with 192.168.123.1 port 777
>>> [ ID] Interval Transfer Bandwidth
>>> [ 3] 0.0-10.0 sec 20.3 GBytes 17.4 Gbits/sec
>>>
>>> This works even with the cable unplugged so I know it's not using the
>>> ports. Some reason why the client isn't initiating the outbound
>>> connecting on the port it's binding to?
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> Better than sec? Nothing is better than sec when it comes to
>>> monitoring Big Data applications. Try Boundary one-second
>>> resolution app monitoring today. Free.
>>> http://p.sf.net/sfu/Boundary-**dev2dev<http://p.sf.net/sfu/Boundary-dev2dev>
>>> ______________________________**_________________
>>> Iperf-users mailing list
>>> Iperf-users@lists.sourceforge.**net <Iperf-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/**lists/listinfo/iperf-users<https://lists.sourceforge.net/lists/listinfo/iperf-users>
>>>
>>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
