[Bridge] received packet with own address as source address

[Bridge] received packet with own address as source address

[Matthew Kent]

Trying to determine if I have a misconfiguration, misunderstanding or
have stumbled on a bug.

Have a CentOS 5.2 server with 2 e1000e nics in a balance-xor bond, check
this out: 


Test 1 - arping the bond device @ 172.16.0.117 from a second machine
---
root@foo [/root]# arping -c 1 -b -I eth0 172.16.0.117
ARPING 172.16.0.117 from 172.16.0.116 eth0
Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.607ms
Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.648ms
Sent 1 probes (1 broadcast(s))
Received 2 response(s)

Nothing logged to the kernel ring buffer on the server. All looks good
and happy.


Test 2 - now add a bridge @ 172.16.0.117 with the bond as a port:
---
root@foo [/root]# arping -c 1 -b -I eth0 172.16.0.117
ARPING 172.16.0.117 from 172.16.0.116 eth0
Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.603ms
Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.642ms
Sent 1 probes (1 broadcast(s))
Received 2 response(s)

Looks good, traffic moves, etc but now the following gets logged on the
server for every broadcast packet:

[26489.040112] bond0: received packet with  own address as source
address


Capturing the traffic for both tests and comparing, they look identical,
but the bridge wants to throw the warning level message in
net/bridge/br_fdb.c br_fdb_update(). The printk warning, being rate
limited, seems to add a noticable lag. Disabling the warning with a
patch made things happy again.

Couple questions from this for the more knowledgeable folks:

1) Are the two arp replies from a balance-xor bond normal?

2) Should the bridge handle this or should I just not be tying an ip to
the bridge in balance-xor mode?

Thanks for your time!
-- 
Matthew Kent \ SA \ bravenet.com

Re: [Bridge] [Bonding-devel] received packet with own address as source address

[Jay Vosburgh]

Matthew Kent <matt@bravenet.com> wrote:

>Trying to determine if I have a misconfiguration, misunderstanding or
>have stumbled on a bug.
>
>Have a CentOS 5.2 server with 2 e1000e nics in a balance-xor bond, check
>this out: 

	I suspect your switch is misconfigured.
	
	The balance-xor mode is nominally "Etherchannel compatible" and
the switch ports connected to bonding balance-xor should be in
Etherchannel mode ("Trunking", etc, but not "LACP" or "802.3ad").

	If the switch doesn't know the ports are aggregated, it may very
well send broadcasts recieved on one port back out the other port, which
may be the cause of what you're seeing.  The switch might also whine
about flapping of the MAC address.

	If I set up bonding here with the switch unconfigured for
Etherchannel, I see the same behavior as this:

ARPING 172.16.0.117 from 172.16.0.116 eth0
Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.607ms
Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.648ms
Sent 1 probes (1 broadcast(s))
Received 2 response(s)

	Specifically the "Received 2 response(s)" part.  This happens
because the bond receives one copy of the packet on each port, and
responds to each.

	After I configure the switch ports correctly for Etherchannel,
there is only 1 response.  Without the switch configuration IPv6
addrconf also complains about duplicate address detected.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: [Bridge] [Bonding-devel] received packet with own address as source address

[richardvoigt]

On Thu, Dec 4, 2008 at 12:46 AM, Jay Vosburgh <fubar@us.ibm.com> wrote:
> Matthew Kent <matt@bravenet.com> wrote:
>
>>Trying to determine if I have a misconfiguration, misunderstanding or
>>have stumbled on a bug.

I think there is a bug here although the description doesn't sound
like the buggy case.

Here is the specific configuration that produces the same message and
I think should not:

A bond in fail-over mode, either both or just one PHY connected.

VLANs configured on the bond device.

Two of the bond VLAN interfaces members of the same bridge, stp
enabled.  An external bridge device (actually a fancy transparent
traffic shaper with a history of occasional seizure) connecting the
same two VLANs.  A router on the higher-numbered (so less preferred by
STP) VLAN.  So the nominal case is for STP to block forwarding, but if
the traffic shaper fails then the bridge will start sending traffic
direct to the router.

Now when the traffic shaper is forwarding traffic, the BPDUs sent out
the preferred port come back on the non-preferred port and force it
into blocking mode as desired.  But the "received packet with own
address as source address" message is logged.

Re: [Bridge] [Bonding-devel] received packet with own address as source address

[Matthew Kent]

On Wed, 2008-12-03 at 16:46 -0800, Jay Vosburgh wrote:
> Matthew Kent <matt@bravenet.com> wrote:
> 
> >Trying to determine if I have a misconfiguration, misunderstanding or
> >have stumbled on a bug.
> >
> >Have a CentOS 5.2 server with 2 e1000e nics in a balance-xor bond, check
> >this out: 
> 
> 	I suspect your switch is misconfigured.
> 	
> 	The balance-xor mode is nominally "Etherchannel compatible" and
> the switch ports connected to bonding balance-xor should be in
> Etherchannel mode ("Trunking", etc, but not "LACP" or "802.3ad").
> 
> 	If the switch doesn't know the ports are aggregated, it may very
> well send broadcasts recieved on one port back out the other port, which
> may be the cause of what you're seeing.  The switch might also whine
> about flapping of the MAC address.
> 
> 	If I set up bonding here with the switch unconfigured for
> Etherchannel, I see the same behavior as this:
> 
> ARPING 172.16.0.117 from 172.16.0.116 eth0
> Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.607ms
> Unicast reply from 172.16.0.117 [00:15:17:70:A3:88]  0.648ms
> Sent 1 probes (1 broadcast(s))
> Received 2 response(s)
> 
> 	Specifically the "Received 2 response(s)" part.  This happens
> because the bond receives one copy of the packet on each port, and
> responds to each.
> 
> 	After I configure the switch ports correctly for Etherchannel,
> there is only 1 response.  Without the switch configuration IPv6
> addrconf also complains about duplicate address detected.
> 
> 	-J

Ah of course! :) Thanks for the helpful information. I should have read
the later section on balance-xor in bonding.txt more closely.
-- 
Matthew Kent \ SA \ bravenet.com

[Bridge] received packet with own address as source address

[Christopher S. Aker]

Hello,

I manage a number of servers all running 2.4 (same problem exists with 2.6).  My
problem is that since a few bridge versions ago, I've had to modify
net/bridge/br_fdb.c in the br_fdb_insert() function -- to get rid of the checks
that produce this error:

Jan 16 10:35:31 host15 kernel: tap_0: received packet with  own address as source
address
Jan 16 10:35:33 host15 kernel: tap_0: received packet with  own address as source
address

My specific setup is: br0 assigned an IP, with eth0 added to the bridge with no
IP.  I create tap devices, assign them no IP address but a unique MAC.  On the
other end of each tap device is an UML virtual machine's eth0.   My machines are
SuperMicro 6013 dual xeon boxes with e1000, and a 5012 box with e100 NICs.  I
don't believe this is a checksum issue raised a while back.  STP is off.  Settings
for setfd and sethello make no difference.   As soon as UML brings up its eth0
interface, the messages appear.

I'm really not a kernel hacker, but I was able to look at previous versions of the
file and more or less just comment out the "if (unlikely(fdb->is_local))"
statement.  This is what I've been using for the past few months.  It seems to
work as it did before this new check was put in place.  But, I still have a
problem where showmacs displays this for each tap interface:

  2     fe:fd:45:38:ad:f1       no                 4.88
  2     fe:fd:45:38:ad:f1       yes                0.00

Two entries for the same interface -- a local, non-expiring fdb entry, and a
non-local expiring fdb entry.  Once the non-local fdb entry times out, the tap
loses connectivity from the world.  If I log into the host machine locally and
ping an IP on the TAP interface, it comes back alive.  Same goes for logging into
the UML's console and pinging the host.  I've had this problem even with the older
bridge code.  I think all this is related to the real problem.  Looks like
something isn't detecting traffic as local, or perhaps it needs special handling
for this case?

Others have been using the identical bridge setup, minus the e100/1000 cards, and
haven't reported either of these problems.  Any advice would be appreciated.

Regards,
-Chris

Re: [Bridge] received packet with own address as source address

[Nikolay Datchev]

just my $0.02:

ethertap interfaces has fake mac addresses, generated somehow by the
tun/tap driver, and they are same on both sides in your case. Don't know
why.

-- Nikolay Datchev

On Fri, 16 Jan 2004, Christopher S. Aker wrote:

> Hello,
>
> I manage a number of servers all running 2.4 (same problem exists with 2.6).  My
> problem is that since a few bridge versions ago, I've had to modify
> net/bridge/br_fdb.c in the br_fdb_insert() function -- to get rid of the checks
> that produce this error:
>
> Jan 16 10:35:31 host15 kernel: tap_0: received packet with  own address as source
> address
> Jan 16 10:35:33 host15 kernel: tap_0: received packet with  own address as source
> address
>
> My specific setup is: br0 assigned an IP, with eth0 added to the bridge with no
> IP.  I create tap devices, assign them no IP address but a unique MAC.  On the
> other end of each tap device is an UML virtual machine's eth0.   My machines are
> SuperMicro 6013 dual xeon boxes with e1000, and a 5012 box with e100 NICs.  I
> don't believe this is a checksum issue raised a while back.  STP is off.  Settings
> for setfd and sethello make no difference.   As soon as UML brings up its eth0
> interface, the messages appear.
>
> I'm really not a kernel hacker, but I was able to look at previous versions of the
> file and more or less just comment out the "if (unlikely(fdb->is_local))"
> statement.  This is what I've been using for the past few months.  It seems to
> work as it did before this new check was put in place.  But, I still have a
> problem where showmacs displays this for each tap interface:
>
>   2     fe:fd:45:38:ad:f1       no                 4.88
>   2     fe:fd:45:38:ad:f1       yes                0.00
>
> Two entries for the same interface -- a local, non-expiring fdb entry, and a
> non-local expiring fdb entry.  Once the non-local fdb entry times out, the tap
> loses connectivity from the world.  If I log into the host machine locally and
> ping an IP on the TAP interface, it comes back alive.  Same goes for logging into
> the UML's console and pinging the host.  I've had this problem even with the older
> bridge code.  I think all this is related to the real problem.  Looks like
> something isn't detecting traffic as local, or perhaps it needs special handling
> for this case?
>
> Others have been using the identical bridge setup, minus the e100/1000 cards, and
> haven't reported either of these problems.  Any advice would be appreciated.
>
> Regards,
> -Chris
>
> _______________________________________________
> Bridge mailing list
> Bridge@lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/bridge
>

Re: [Bridge] received packet with own address as source address

[Christopher S. Aker]

> just my $0.02:
>
> ethertap interfaces has fake mac addresses, generated somehow by the
> tun/tap driver, and they are same on both sides in your case. Don't know
> why.
>
> -- Nikolay Datchev

Not sure what gave me the idea to use the same MAC on the TAP and inside the UML.
Since the earlier versions of bridge didn't complain about it, perhaps I figured I
should fight it :)  Anyways, using a different MAC for the TAP and the UML seems
to have solved all of the issues.

Thanks for the help!
-Chris