Bonding ALB sends bogus packets

Bonding ALB sends bogus packets

[Stephen Hemminger]

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.

-- 

Re: Bonding ALB sends bogus packets

[Jay Vosburgh]

Stephen Hemminger <shemminger@vyatta.com> wrote:

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

	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

Re: Bonding ALB sends bogus packets

[Stephen Hemminger]

On Thu, 30 Jul 2009 13:28:19 -0700
Jay Vosburgh <fubar@us.ibm.com> wrote:

> Stephen Hemminger <shemminger@vyatta.com> wrote:
> 
> >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.
> 
> 	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

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.

Re: Bonding ALB sends bogus packets

[Mark Smith]

On Thu, 30 Jul 2009 13:35:45 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:

> On Thu, 30 Jul 2009 13:28:19 -0700
> Jay Vosburgh <fubar@us.ibm.com> wrote:
> 
> > Stephen Hemminger <shemminger@vyatta.com> wrote:
> > 
> > >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.
> > 
> > 	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
> 
> 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.

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
used for this bridge table address refresh purpose in the past.


> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bonding ALB sends bogus packets

[Rick Jones]

Mark Smith wrote:
> 
> 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 wonder how that relates to linkloop:

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

http://fr2.rpmfind.net/linux/RPM/opensuse/factory/x86_64/usr_share_doc_packages_linkloop_Tree.html

> 
> 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
> used for this bridge table address refresh purpose in the past.

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

rick jones

Re: Bonding ALB sends bogus packets

[Mark Smith]

Hi Rick,

On Thu, 30 Jul 2009 16:48:28 -0700
Rick Jones <rick.jones2@hp.com> wrote:

> Mark Smith wrote:
> > 
> > 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 wonder how that relates to linkloop:
> 
> http://sourceforge.net/projects/linkloop/
> 
> http://fr2.rpmfind.net/linux/RPM/opensuse/factory/x86_64/usr_share_doc_packages_linkloop_Tree.html
> 

> > 
> > 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
> > used for this bridge table address refresh purpose in the past.
> 
> I can never remember if linkloop uses XID or Test frames :(
> 

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