Hi Eric,

Thanks very much for your time.

On Fri, 24 Apr 2009 09:36:14 +0200
Eric Dumazet <dada1@cosmosbay.com> wrote:

quoted text
> Mark Smith a écrit :
> > Hi,
> > 
> > I'm hoping my attached implementation of the Ethernet V2.0 Configuration
> > Testing Protocol could be reviewed, with eventual goal of inclusion in
> > the kernel.
> > 
> > Ethernet V2.0 Configuration Testing Protocol (ECTP) is an old Ethernet
> > testing protocol, specified in section 8 of the original Ethernet V2.0
> > specification. It provides request/reply "ping" style testing at
> > the Ethernet layer, testing of a path via a list of devices (i.e. a
> > strict source route), and identification of ECTP capable devices via
> > broadcast or multicast ECTP requests.
> > 
<snip> 
quoted text
> 
> Hello Mark
> 
> I am trying to find how ETCP could be useful :)
> 
> Could bonding use ETCP as a third way to validate a slave is operational ?
> 
> First way is mii-mon (link presence to next hop)
>   -> Very lazy since we can be connected to a switch that lost all connectivity to other equipments.
> 
> Second way is arp_ping (list of 1 to 16 IP addresses)
>   -> broadcast messages.
>    If many hosts are on [V]LAN, and small arp_interval, this can generate extra trafic.
> 
> Third way : ETCP messages sent to given MAC address ?
>   (Unicast messages, and no VLAN troubles...)

ECTP is designed exactly for that purpose - verifying
remote Ethernet node availability. The unicast ECTP message would
contain a forward message, specifying the originator's MAC address, and
a reply message. The receiver, if it is available, just forwards the
packet to the (unicast) MAC address provided in the current forward
message. For a liveness test, the MAC address in the forward message
would be that of the ECTP packet originator.

quoted text
>  I presume most routers support ETCP?
> 

Cisco IOS routers do. They also use the protocol as their Ethernet
keepalive test, altough those packets don't comply with the
specification - the packet src and destination addresses are both the
MAC address of the interface source, and they only contain a reply
message, where as the minimum compliant packet should have a forward
message and a reply message. I haven't completely worked out how that is
supposed to work, as any upstream switches won't forward a packet back
out the interface the packet is received on.

quoted text
> Is ectpping needing your kernel patches, or can it work with current kernel ?

It doesn't need the kernel patches to work. Of course, without my
patch, Linux hosts won't respond.

quoted text
> If not too large, you could post its source on this list.
> 

It's not so much that it's too large, more that I've got a few minor
things left to do it e.g. put licensing info in, put a version number
in etc. It's also generally a bit thrown together, as my focus was on
the kernel module.

I'll fix those things over the next few days, and put it up on the net.

Thanks again,
Mark.
--
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