On Tue, Apr 17, 2012 at 9:16 AM, Andrew M <and...@oc384.net> wrote: > 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?
I can't believe nobody's asked this yet, but, what does scooby do? ;-) Seriously, though - as you've described your test, you're trying to have iperf test from one on-board NIC to another in the same host. What is the purpose of this test? -tt > 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 >> >> 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 >>> _______________________________________________ >>> Iperf-users mailing list >>> Iperf-users@lists.sourceforge.net >>> 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 -- Tom Throckmorton MCNC 919.248.1448 "Connecting North Carolina's future today" ------------------------------------------------------------------------------ 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
