Triggers for Loopback - ErrDisable

arun kumar · ‎09-28-2008

Hi All,

We have two switches connected back to back SW-A and SW-B.

SW-B is connected to other upstream switches. When the uplink to upstream switch flaps in SW-B, im seeing the below logs in SW-A and the link between SW-A and SW-B also flaps. The link is automatically put into ERR DISABLE in SW-A because of the reason LoopBack.

"%ETHCNTR-3-LOOP_BACK_DETECTED"

When searched in Cisco, it says SW-A receives the same keep alive packet it sent on the same port and it is putting into ERRDISABLE. The link will automatically come after the ERR DISABLE recovery period or we need to manually shut/no shut the link.

I would like to know the possible causes of "loopback error" . There is no problem in Layer 1 apart from link flap. Will link flap will cause the loopback error.

Note: Link between SW-A and SW-B is not running any STP or VTP. It's just a open trunk port. But Uplink of SW-B connected to upstream switches are running MSTP.

Thanks in advance.

regards,

Arun Kumar

andrew.prince · ‎09-29-2008

Arun,

I am confused - you state "Link between SW-A and SW-B is not running any STP or VTP. It's just a open trunk port."

Spanning-tree is on by default? Have you actually configured spanning-tree to be disabled?

Is there another link from swa to swb other than the trunk link?

arun kumar · ‎09-29-2008

Hi Andrew,

Yes we disabled STP by configuring "bpdu-filter enable". There is no other link between swa and swb.

regards,

Arun Kumar

andrew.prince · ‎09-29-2008

Arun,

bpdu-filter enable stops the switch from "listening" for STP BPDU's.

Does not stop the switch from "Sending" BPDU's for STP.

Did you configure BPDU on both ends of the link between swa & swb?

Also why does the connection between them need to be a trunk port, just change it to a switch port?

Why do you not want to run spanning tree on swa?

Giuseppe Larosa · ‎09-29-2008

Hello Arun,

there was another thread about this issue some days ago.

It looks like that in some platforms with some IOS releases for a known and solved bug the coming back of interface keepalives is misunderstood as a sign of a loop and not as a sign of an healthy link and the port is placed in errordisabled.

This problem is not related to STP or STP loop guard.

I make a search...

see

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=LAN%2C%20Switching%20and%20Routing&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40^1%40%40.2cc1ebcc

the bug id is:

Cisco bug ID CSCea46385

Hope to help

Giuseppe