Link Flap Erros on several 3500XL switches.

Has anyone seen this before?

Syslog message generated from device May 01 09:43:36 1344: May 1 09:39:59: %RTD-1-LINK_FLAP: FastEthernet0/7 link down/up 5 times per min

We have seen this happening starting a couple of weeks ago and only on the 3500XL switches. At first we thought this was related to wireless users and AP ports only. We were wrong. We see this error occurring on a lot of the 3500s now.

Any ideas?

Thanks in Advance.

Reply to
Loading thread data ...

Were these errors occuring all along and they have been just noticed or did they acutally just start a shoir time ago.

I would take one switch and 1 port that is experieincing this issue and delve into it further.

Enable logging buffer on the switch if not already

conf t logging buffer 10000 debug no logging buffer exit wri mem

Post the config for a switch experieincing the problem along with show interface and shlow log if the log contain error message related to port having the link flap message.

Also post the ouput of show version

so sh version sh run sh interface sh log

Reply to


conf t logging buffer 10000 debug no logging console exit wri mem

Reply to

Here's the latest from the Cisco TAC case:

I spoke to Cisco TAC yesterday regarding this issue. They had some interesting points that are contributing to this problem. On our logging configuration we are running level "debugging". The TAC engineer recommended that we change the value from "debugging" to "informational". Informational messages will provide all other message types (alerts, critical, emergencies, errors, etc). By having the messages at debugging the high volume of messages can cause the CPU to reach high usage levels as well as memory being used up due to the buffers having to be used while the CPU is writing the message.

Making this change will not stop the RTD messages regarding link flapping. In troubleshooting this issue the Cisco engineer believes this is a separate issue and would like to pursue this individually until we can correlate it. He would like for us to trace one of the devices out to find out what it is and to try moving it to another port to see if the problem moves to that port.

Reply to

I assume the TAC engineer meant if you had a debug command enabled.

Reply to

To eliminate CPU load related cause you could look at sh proc cpu. As Merv says "no logg console" is a good idea on pretty much all installations..

formatting link
that this issue is most likely related to the directly connected devices.

The log level thing from TAC is a wild goose chase. I cannot see how it will change anything unless a specific debug is enabled. In that case I would advise turning it off.

Are the devices actually losing connectivity. Maybe a bug that is just generating the log messages?

Ping one of the affected devices and see what happens.

If you have STP enabled you might consider turning OFF portfast on a particular port to make sure that you have something to observe. Be aware that this will increase the impact to the conencted devices of the failure.

Reply to
anybody43 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.