View Issue Details

IDProjectCategoryView StatusLast Update
0007883CentOS-7kernelpublic2014-11-15 02:29
Reporteramgems Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Product Version7.0-1406 
Summary0007883: ARP response incorrect when using bonding and plans
DescriptionARP 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 Reproducebond 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 InformationI 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.
TagsARP, bonding, vlan
abrt_hash
URL

Activities

amgems

amgems

2014-11-15 02:16

reporter   ~0021708

I mean "VLANs", not "plans". Damn that spelling chequer.
amgems

amgems

2014-11-15 02:18

reporter   ~0021709

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.
amgems

amgems

2014-11-15 02:25

reporter   ~0021710

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

Issue History

Date Modified Username Field Change
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