View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007883||CentOS-7||kernel||public||2014-11-15 02:13||2014-11-15 02:29|
|Summary||0007883: ARP response incorrect when using bonding and plans|
|Description||ARP request gets sent out to broadcast address. You can see the source address.|
Response comes back. You can see some bytes of the destination address correspond to some translated bytes of the original request source, and the rest are crap.
00:00:00.303841 18:af:61:b7:ea:f2 > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.98.85.162 tell 10.98.85.1, length 46
00:00:00.000113 cf:ff:81:00:10:55 > ea:f2:00:0c:bd:05, ethertype ARP (0x0806), length 56: Ethernet (len 6), IPv4 (len 4), Reply 10.98.85.162 is-at 00:0c:bd:05:cf:ff, length 42
|Steps To Reproduce||bond two 10gig ports (team works as well, but is much more of a pain in the ass to use).|
Call this bond85. The two 10gig ports are running LACP, but that does not matter. What matters is that the traffic on bond85 is VLAN tagged, ID 85.
Create a bond85.85 VLAN device, and make it be a bridge slave to br85.
Take a plain vanilla 1G port, and make it be a bridge slave to br85.
Bring everything up, and give it an IP address. I use 10.98.85.250.
On the 1G, non-tagged segment, put a host. I have 10.98.85.1.
On the 10G, VLAN tagged segment, put another host, 10.98.85.162.
From the .1 host, ping the .162 host.
On the .250 host (running Centos7), run 'tcpdump -vvvetttns0 -i br85'
See the ARP requests going out.
See the ARP response going back.
Spend many hours wondering wtf is happening. rip out all sorts of suspect networking gear because it utterly appears that it is filtering the ARP response.
Eventually observe the mangled response destination address.
Forget it all, and decide that team is broken (well, it is crap) and replace everything with bond (which used to work on Centos6).
repeat all the above steps including the "rip out lots of network equipment" until this time, you suddenly remember that you had this all figured out a few weeks ago.
Decide it is time to report the bug, after doing a yummy update and rebooting and not getting a fix.
|Additional Information||I can't believe that people really think team is better. Look at the docs. Wow. utterly horrible. It is so bad, I even made the mistake of letting NetworkMunger back on my system to try and configure it. What a joke! "enter the weird JSON crap you found by googling into the GUI text box here". Right.|
|Tags||ARP, bonding, vlan|
|I mean "VLANs", not "plans". Damn that spelling chequer.|
In case it is not obvious:
Req SRC: 18:af:61:b7:ea:f2
Rsp DST: ea:f2:00:0c:bd:05
The translation from VLAN-tagged to non-tagged just needs to be adjusted correctly.
on the .250 (Centos-7), I can ping both .1 and .162.
[root@t410 ~]# arp -an | grep 85.1
? (10.98.85.1) at 18:af:61:b7:ea:f2 [ether] on br85
? (10.98.85.162) at 00:0c:bd:05:cf:ff [ether] on br85
|2014-11-15 02:13||amgems||New Issue|
|2014-11-15 02:15||amgems||Tag Attached: bonding|
|2014-11-15 02:15||amgems||Tag Attached: vlan|
|2014-11-15 02:15||amgems||Tag Attached: ARP|
|2014-11-15 02:16||amgems||Note Added: 0021708|
|2014-11-15 02:18||amgems||Note Added: 0021709|
|2014-11-15 02:25||amgems||Note Added: 0021710|