Line protocol down?

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
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".

Re: Line protocol down?
Take a look about half way down the page here:

http://www.2000trainers.com/article.aspx?articleID=438&page=2



Re: Line protocol down?
Mike B wrote:
Quoted text here. Click to load it
That sums it up nicely. Thanks :)

Re: Line protocol down?
Quoted text here. Click to load it

You're welcome - happy to help.



Re: Line protocol down?
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
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml#t3
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.




Quoted text here. Click to load it



Re: Line protocol down?
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:

http://www.mit.edu/~jhawk/ctp.html

Quoted text here. Click to load it
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 Winkworth wrote:
Quoted text here. Click to load it
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml#t3
Quoted text here. Click to load it


Re: Line protocol down?

angry_engineer@yahoo.com wrote:
Quoted text here. Click to load it


HI,

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

Quoted text here. Click to load it

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.


Re: Line protocol down?
Quoted text here. Click to load it
protocol
segment/VLAN.
Quoted text here. Click to load it
the
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml#t3
Quoted text here. Click to load it
different.
is
on the
has
an
and a
packet back
packet back

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.
Quoted text here. Click to load it

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

stephen_hope@xyzworld.com - replace xyz with ntl



Site Timeline