Now... this is interesting.
I've been digging for a little bit now looking for some clarification on the mechanics of this protocol and found that it is called the "Configuration Test Protocol." It is not part of the IEEE 802.3 standard, but it is part of the original Ethernet Standard. I found a copy of the CTP specification here:
From what I can tell, there is very little support for this protocol.
So I wonder if you need to disable keepalives on a Cisco router that is attached to a non-Cisco switch or other ethernet device that does not support CTP? Or is the router not really looking for a reply on the wire? I wonder if the controller on the router is looping back this frame locally and that is what the router is looking for?
On the other hand, I know from personal experience that some media converters will supply a carrier toward the router even if the distant end device is down, and in those cases we see the ethernet is up, line protocol down. This would seem to indicate the router is indeed looking for a reply back on the wire.
Anyone else have any ideas on this? Perhaps some sniffer traces showing replies coming back to the router from the opposite direction?
- Hide quoted text -
- Show quoted text - Derick W> Actually, that information is not entirely accurate. On an ethernet
interface, the frame type of a neighbor does not determine if the line
> protocol is up or down. Ethernet Keepalives determine if the line protocol
> is up or down.
> Logically, there could be many different hosts on an ethernet segment/VLAN.
> If one of them comes on-line with an incorrect frame type, would all the
> routers on the segment suddenly go "ethernet down?"
> See
>formatting linkand scroll down to the "ethernet keepalives" section.
> ##############
> Ethernet Keepalives
> On broadcast media like an Ethernet, keepalives are slightly different.
> Since there are many possible neighbors on the Ethernet, the keepalive is
> not designed to determine if the path to any one particular neighbor on the
> wire is available. It is only designed to check that the local system has
> read and write access to the Ethernet wire itself. The router produces an
> Ethernet packet with itself as the source and destination MAC-address and a
> special Ethernet type code of 0x9000. The Ethernet hardware sends this
> packet onto the Ethernet wire and then immediately receives this packet back
> again. This checks the sending and receiving hardware on the Ethernet
> adapter and the basic integrity of the wire.
> ###############
> Based on this info, I imagine that if you had performed a "clear interface"
> on the Ethernet interface, it may have cleared the problem. If rebooting
> the router fixed the issue, I think the Ethernet controller could have been
> "stuck." This "stuck" condition could be the result of any number of
> things. Perhaps it was a faulty media converter.