Sometimes when doing my 10-GigE testing, I would get results like
the following:
chance% nuttcp -w2m 192.168.88.8
1184.3614 MB / 10.04 sec = 989.8235 Mbps 12 %TX 9 %RX
This seemed to indicate it was using one of the GigE interfaces
rather than the 10-GigE interface. Both chance and chance4 have
multiple GigEs attached to the same VLAN as the 10-GigE interface,
but using different network addresses.
Immediate subsequent tests would still get GigE performance, but if
I would wait about 5 minutes and retest, it would be back to 10-GigE
performance levels.
After thinking about it a bit more, this seemed like it was probably
an ARP issue, which was verified by:
chance% arp -n 192.168.88.8
Address HWtype HWaddress Flags Mask Iface
192.168.88.8 ether 00:02:B3:D4:0C:D8 C eth0
eth0 is the 10-GigE interface on chance4 with an IP address of 192.168.88.8.
[EMAIL PROTECTED] ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:07:E9:11:6A:61
inet addr:192.168.88.8 Bcast:192.168.88.15 Mask:255.255.255.240
inet6 addr: fe80::207:e9ff:fe11:6a61/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:593 errors:0 dropped:0 overruns:0 frame:0
TX packets:801861 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10000
RX bytes:37952 (37.0 Kb) TX bytes:2254470945 (2150.0 Mb)
Base address:0xb800 Memory:fe8f8000-fe900000
eth3 is a GigE interface on chance4 with an IP address of 192.168.3.78.
[EMAIL PROTECTED] ifconfig eth3
eth3 Link encap:Ethernet HWaddr 00:02:B3:D4:0C:D8
inet addr:192.168.3.78 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::202:b3ff:fed4:cd8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:3023004 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10000
RX bytes:2944400295 (2807.9 Mb) TX bytes:1884 (1.8 Kb)
Base address:0x6800 Memory:fe4c0000-fe4e0000
So the ARP request for 192.168.88.8 got resolved to the eth3 GigE
interface on chance4 instead of the eth0 10-GigE interface, even
though eth3 is in a completeley different network than 192.168.88.8.
A tcpdump on chance verified that all the GigE interfaces on chance4
were doing ARP replies for the ARP request for 192.168.88.8, in addition
to the desired ARP reply from the 10-GigE interface.
[EMAIL PROTECTED] tcpdump -n -vv -s 1500 -e arp
tcpdump: listening on eth0
22:33:15.737712 0:7:e9:11:6a:26 Broadcast arp 42: arp who-has 192.168.88.8
tell192.168.88.10
22:33:15.738647 0:7:e9:11:6a:61 0:7:e9:11:6a:26 arp 60: arp reply 192.168.88.8
is-at 0:7:e9:11:6a:61
22:33:15.738648 0:2:b3:d4:c:d8 0:7:e9:11:6a:26 arp 60: arp reply 192.168.88.8
is-at 0:2:b3:d4:c:d8
22:33:15.738649 0:4:23:8:52:5d 0:7:e9:11:6a:26 arp 60: arp reply 192.168.88.8
is-at 0:4:23:8:52:5d
22:33:15.738658 0:4:23:8:52:5e 0:7:e9:11:6a:26 arp 60: arp reply 192.168.88.8
is-at 0:4:23:8:52:5e
22:33:15.738658 0:4:23:8:52:5c 0:7:e9:11:6a:26 arp 60: arp reply 192.168.88.8
is-at 0:4:23:8:52:5c
22:33:15.738751 0:4:23:8:52:5f 0:7:e9:11:6a:26 arp 60: arp reply 192.168.88.8
is-at 0:4:23:8:52:5f
Is it expected behavior that ARP replies would be generated for interfaces
on a different network than the IP address in the ARP request (note I
don't have Proxy ARP enabled), or is this a bug? To me it would seem
to be a bug.
-Bill
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
