Re: [RFC, PATCH 2.6.29.1] Ethernet V2.0 Configuration Testing Protocol

[Eric Dumazet <dada1@cosmosbay.com>]

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.
> 
> I've had a go at implementing it for a number of reasons:
> 
> o  My day job involves running networks, and eventually you start to
> wonder what is going on inside the devices you use. I think having a go
> at implementing something is a good way to learn.
> 
> o  It's a very simple protocol (a single frame format), so it could be
> a good starting point for people who'd like to understand more about
> how networking works in the Linux kernel. I've tried to make the
> implementation easy for people to follow what it is doing.
> 
> o  It's actually quite useful - every now and then people in networking
> say, "wouldn't it be great if there was an Ethernet ping which didn't
> require IP to work". Recent Ethernet OAM standards provide that, but
> they're a lot more complicated to implement than ECTP, and I needed
> something simple to start with :-)
> 
> o  It might finally make Linux completely compliant with the Ethernet
> V2.0 specification which says that the protocol is required!
> 
> I've also put together a testing utility. I need to put a bit more
> polish on it, and find somewhere to host it, which I'll do in the next
> few days. Here are a couple of examples of it's use:
> 
> o  a unicast ECTP "ping"
> 
> [root@opy ectpping]# ./ectpping -i tap0 52:54:00:12:34:56
> ECTPPING 52:54:00:12:34:56 (qa64-eth0) using tap0
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=0 time=0.000346 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=1 time=0.000209 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=2 time=0.000203 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=3 time=0.000187 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=4 time=0.000210 sec
> ^C
> ---- 52:54:00:12:34:56 (qa64-eth0) ECTPPING Statistics ----
> 5 packets transmitted, 5 packets received, 0.000000% packet loss
> round-trip (sec)  min/avg/max/total = 0.000187/0.000231/0.000346/0.001155
> 
> 
> o  a multicast ECTP "ping"
> 
> [root@opy ectpping]# ./ectpping -i tap0
> ECTPPING cf:00:00:00:00:00 (loopback-assist) using tap0
> 106 bytes from 52:54:00:12:34:57 (qa64-eth1): ectp_seq=0 time=0.018630 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=0 time=0.056334 sec
> 106 bytes from 52:54:00:12:34:58 (qa64-eth2): ectp_seq=0 time=0.056656 sec
> 106 bytes from 52:54:00:12:34:58 (qa64-eth2): ectp_seq=1 time=0.020351 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=1 time=0.024241 sec
> 106 bytes from 52:54:00:12:34:57 (qa64-eth1): ectp_seq=1 time=0.031350 sec
> 106 bytes from 52:54:00:12:34:58 (qa64-eth2): ectp_seq=2 time=0.049382 sec
> 106 bytes from 52:54:00:12:34:57 (qa64-eth1): ectp_seq=2 time=0.067358 sec
> 106 bytes from 52:54:00:12:34:56 (qa64-eth0): ectp_seq=2 time=0.074230 sec
> ^C
> ---- cf:00:00:00:00:00 (loopback-assist) ECTPPING Statistics ----
> 3 packets transmitted, 9 packets received, 3.00 times packet increase
> round-trip (sec)  min/avg/max/total = 0.018630/0.044281/0.074230/0.398532
> 
> While I'm finishing off the utility, I thought I'd post the kernel
> source to get it out there for people to have a look at. I'd really
> appreciate any suggestions for improvement, or any pointers to where
> I've done the wrong thing or had any miss understandings. The patch is
> against 2.6.29.1.
> 
> Thanks very much,
> Mark.
> 
> (please CC me, as I'm not on the mailing list)
> 

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...)
 I presume most routers support ETCP?

Is ectpping needing your kernel patches, or can it work with current kernel ?
If not too large, you could post its source on this list.

Thank you