ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on Gigabi

[mloenzo0100]

Hi all,

I have 3 switches A B and C in a hub and spoke design. When the trunk link between A and B are up everything is fine. Once I bring up the trunk between switch A to C. I receive the following error on switch B.

1d07h: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/1.

1d07h: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state

Has anyone come across this? I am thinking of turning off keepalives on my Trunk links. If anyone has any thoughts please let me know.

Thanks

mike

[deilert]

I beleive you have a bridging loop , do you have spanning tree enabled ?

[mloenzo0100]

Thanks for the reply.

I do have PVST enabled. The odd thing is that it takes almost 2 hours for the error to occur. It seems like a loop because the port is seeing its own keepalive packet then shutting down the port because of it. I would assume spanning tree would shut down the port immediatly if it detected a loop.

Thanks again

mike

[deilert]

what about port fast is that enabled on ony of these ports?

[mloenzo0100]

Port fast is not enabled. I did try the "no keepalive" command on the port in question and it stopped the keepalive loopback error and the err disable state. The port has stayed up for over 12 hours. Longest since I installed the 3 switches. Now my concern is that I may still have an issue that I temporarily fixed. Although, I have been monitoring the switches health and everything looks good. I have not been able to find any good documentation on this error or the no keepalive command.

Thanks again for your input

mike

[robho]

You can always plug a sniffer to any port and capture these loopback frames. It's been a while since I looked at the trace but believe it is Ethertype 0x9000 Loopback frame. I have recommended many times to disable keepalives. It is an addition to spanning-tree. If you are sure that stp is fwd/blk on the right ports, then I would not worry too much about it.

[steinar.haug]

Most likely you've had a temporary spanning tree loop.

We've had *lots* of problems with this loopback detection, to the point that we're turning it *off* on all our 3550s as a default. If you still want to use the loopback detection, you probably want the following:

errdisable recovery cause loopback

errdisable recovery interval 60

which makes IOS try to enable the port again after a while.

[robho]

Disable keepalive under the interface. Basically, this is a Loopback frame with the source/dest MAC that belongs to to the local port sending it. The receving end is supposed to absorb and punt to CPU. But, somehow the source receives it back.

This keepalive feature is not the same as the router interface. It is an add'l feature on the 2950/3550 platform. If you have stp enabled, then disabling this feature should not affect anything.

config t

interface gig 0/1

no keepalive

end

write mem

[sbrobak]

There is a bug CSCdt82690, but it relates to etherchannel.

From the info posted in this newsgroup, the bug is relates to trunks too. It would be very nice if this could be confirmed!!

Anyway, this issue explains some strange behavior in my network.

[mloenzo0100]

Turning off keepalives has worked. I am curiuos about this bug you mentioned. Maybe a call to TAC is in order to get more detailed info.

Thanks again for everyones input!

mike