Line protocol down?

I had a situation where one of our routers connected to a fiber converter for our ISP was showing no activity on the copper interface. At first, we assumed it was the converter, so we had our ISP come out to replace it. Once replaced, we noticed there was still no activity on it. The router was showing that the Interface was up, but line protocol was down. We tested with another cat5, and got the same results. It wasn't until we had to do a hard reset of the router that everything seemed to have corrected itself.

What does it exactly mean when the line protocol is down? I understand that if the interface is up, then there is link, but I am just a bit confused as to "technically" what it means when the line protocol is "down".

Reply to
Michael
Loading thread data ...

Take a look about half way down the page here:

formatting link

Reply to
Mike B

That sums it up nicely. Thanks :)

Reply to
Michael

You're welcome - happy to help.

Reply to
Mike B

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

Reply to
Derick Winkworth

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:

formatting link

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?

Derick W> Actually, that information is not entirely accurate. On an ethernet

formatting link
and scroll down to the "ethernet keepalives" section.

Reply to
angry_engineer

formatting link
> and scroll down to the "ethernet keepalives" section.

HI,

It seems to me that the Cisco Ethernet keepalives and Configuration Test Protocol are different and seperate.

As to the Cisco Ethernet keepalives I understand that a Half-Duplex ethernet transceiver listens to its own transmissions and that it could use that mechanism to in some sense verify that the interface ws connected to 'something'. I have no idea at all how this might operate with Full-duplex Ethernet.

Reply to
anybody43

formatting link
> > and scroll down to the "ethernet keepalives" section.

i think you will find that it doesnt work this way.

the protocol doesnt need any other device on the same ethernet, since an interface will come up even if only connected to a dumb Ethernet hub. It sends out a packet to periodically to see if that triggers a problem in hte interface.

When i have looked at these before with a sniffer, the source and destination MAC were both set to the same address (the same as the interface).

mechanics of an Ethernet repeater mean that when a device sends out a packet, it doesnt get a reply "from the wire" since this is the definition of a collision to show the packet got mangled.

it could get something from the transceiver - i seem to remember a heartbeat switch on a typical 10M external transceiver.

Agreed. there might be something in the low level guts of the Ethernet interface that tells the device the packet probably got sent successfully - but nothing comes back across the Ethernet cable itself.

Reply to
stephen

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.