Ethernet Interface: Line Protocol Up - but what does it mean.

[jonathan1uk]

From reading various text on the Cisco web site I was of the understanding that the Line Protocol State for an Ethernet Interface was related to the presence of keepalive frames - an example extract is below.

However by observation the Line Protocol Sate for a FastE or GigE interface on a Cisco 3550 remains UP even when no keepalive frames are received on that interface. For example when the only thing connected to the 3550 is a very simple 8 Port D-Link switch the Line Protocol state is still UP, connecting a sniffer to the D-Link shows that no frames of any type are sent out be the D-Link. The same Sniffer is able to capture and display the keepalive [Loop Receipt] from the 3550. BTW the 3550 keepalive time is 10sec [default].

The only conclusion that I can come up with is that the Line Protocol State always follows the Link State?

Any thoughts would be much appreciated!

"The Protocol column lists the line protocol for an interface. A line protocol tells you whether the interface line missed the last three keepalives. If so, the column shows "down" for that interface."

[gpulos]

the interface has two areas that state must be in up mode to be operating correctly:

1) interface state - UP (not in shutdown mode)

2) line protocol state - UP (layer 2 connectivity established)

line protocol state could be likend to the linkState since link state is obtained at layer2 and this is what the router uses to determine if the line protocol is up. (it does use keepalives at layer2 if they're set)

[sean]

In addition with gpulos' response, you can see the keepalive in action on a router interface. Don't have a cable plugged into, no shut the interface and use the no keepalive command. The interface will show up/up despite the fact that there is nothing there. This is helpful in lab environments when you just want to hang IPs of an interface.

[jonathan1uk]

sean/gpulos,

Thankyou for your comments, things still do not quite stack up with respect to the keepalives.

As I said if I connect a D-Link switch [or a Lap-Top etc] to a 3550 in this case no keepalives are being sent to the 3550. In fact the Lap-Top and D-Link Switch are not sending out eathernet frames of any type [the D-Link is a dumb switch and I have set my Lap-Top up that way], I can prove this with either eatherrel or SnifferPro.

So the real question is if there are not keepalives, no ethernet frames, then what is keeping the Line Protocol UP?

This is driving me a bit mad and so I realy appreciate any thoughts!

Can anyone try connecting a "dumb" switch with no keepalives [or frames of any other types] to a Cisco box and let me know what you see?

Thanks again!

[Kevin Dorrell]

Jonathan,

I think this may be more to do with whether the switch has managed to transmit its keepalives, rather than if it has seen them comingh back in. What could prevent it from transmitting its keepalives? Well, lack of incoming carrier, for one thing - and your dumb switch is generating a carrier.

So in that sense, the link state does follow the physical state. Like you, I find it hard to image what conditions would make physical state up but protocol down. Maybe excessive collisions (i.e. 16 in a row) would do it. If you want to try that out in the lab (NOT on a live network ;-) you could try connecting your switch to a dumb hub, then connecting two other ports of the hub back-to-back. If you do that experiment, let me know the results, 'cos I'm curious to know.

Of course, if you have no keepalives then the switch cannot detect that it was unable to transmit them, so it will register "up".

Kevin Dorrell

Luxembourg

[jonathan1uk]

Kevin,

That is a very good point, I note that when using port mirroring keepalives are not sent [originated by the mirror], my Lap-Top is connected and the Line Protocol State is DOWN.

I'll let you know what happens when errored frames as sent into a none mirror port!