The bonding ALB mode builds packets with type, ETH_P_LOOP.

Well ETH_P_LOOP is defined as 0x0060 which looks completely bogus.
All Ethernet types less than 1536 are interpreted as 802.2 frames.
The result is that the resulting packet looks like a bogus 802.2
frame to the other host (or switch).  I have no idea what the 
initial design was or what the purpose of this code is, but it
should either send a real packet or nothing at all.

-- 
--

[ message continues ]

I've looked at that code before, too, although I hadn't noticed
that ETH_P_LOOP is under the limit for interpretation as a length
instead of a type.

	I believe the purpose of the code is to update the switch's MAC
address table for the port and insure it's correct, since the alb mode
can move MAC addresses around amongst the set of slaves.

	-J

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

[ message continues ]

On Thu, 30 Jul 2009 13:28:19 -0700

Then it ought to send an ARP or at least a real-looking 802.2 packet.
Also, if the purpose was to update switch MAC table, why does it need
to do it so often, rather than only when MAC address is swapped.
--

[ message continues ]

On Thu, 30 Jul 2009 13:35:45 -0700

Generally to overcome the 300 second address timeout. You can't be sure
that any actual traffic is going to come from that address within the
timeout period. Netflow collectors are a good example of something that
receives traffic but doesn't send any. It's a common problem to have
their MAC address timeout of the upstream switch and then start seeing
the UDP Netflow traffic being flooded to all switch ports. You then
have to set up something like a persistent periodic ping to refresh the
MAC address table.

ETH_P_LOOP should probably have been avoided, as "LOOP" or "loopback"
is commonly used to refer to the Ethernet Configuration Testing
Protocol (google search for "Ethernet Loop protocol"). 

I'd suggest not using any form of ARP for this purpose. It'd place an
IPv4 requirement on the bonded interface, and various "empty" ARP
frames have meaning e.g. duplicate address detection. 802.2 test frames
or the original Ethernet V2.0 Configuration Testing Protocol have been
--

[ message continues ]

I wonder how that relates to linkloop:

http://sourceforge.net/projects/linkloop/


I can never remember if linkloop uses XID or Test frames :(

rick jones
--

[ message continues ]

Hi Rick,

On Thu, 30 Jul 2009 16:48:28 -0700

From memory when I looked into it a year or so ago, linkloop
used 802.2 test frames.

When I decided to have a go at implementing ECTP for the Linux kernel
a couple of years ago, one thing I didn't want to was to duplicate
already existing layer 2 testing functionality in the kernel, which
meant comparing 802.2 test frames capability verses ECTP. 802.2 test
frames only do single hop unicast request/reply testing, obviously
requiring you to already know the test unicast address. ECTP, in
addition, provides broadcast and optionally multicast ECTP capable node
discovery, and the ability test a path of nodes, by providing a list of
unicast addresses to visit i.e. a strict source route. As I've found
IPv4 'broadcast pings' occasionally useful, I thought a layer 2
equivalent, not requiring IPv4 to be functioning, would also be quite
useful.

ECTP could also probably be used over any 802.2 capable network, by
using the SNAP encoding with an OUI of 0x000000 and then a protocol ID
of 0x9000. 

(When you start looking into it, it's interesting how many layer 2
keepalive/testing protocols have been developed over the years,
including most recently the Ethernet OAM protocols. What is also
suprising is that the original Ethernet V2.0 Configuration Testing
Protocol tends to be more capable than any of them - they're usually
just single-hop request/reply testing)

Regards,
Mark.
--

[ message continues ]