no it is in auto negotiate state but why would that cause error message since it is 10/100/1000 autosense?

Because while autosense is useful in timesavings, it is an 90% of your troubleshooting you can narrow down to duplex and speed issues. Just set it manually and see if it resolves the problems. If not, we can work towards something else.

Hello,

in addition to William´s posts, the message could also be caused be the MAC address being learned through both ports indicated in the error message. Are both the Gigabit and the FastEthernet ports configured in the same way, that is, as trunks or access ports ?

Regards,

GP

I strongly agree with both of you. i will do it. but not forcing ports 100 Mbps full duplex connection shouldnt have caused this kind of error message. they should have agreed on speed and work smoothly after.

i will give it a shut anyway.

both gigabit and fa ports are layer 2 switch ports.

hi john

It is not loop. I have checked, stp nicely works.

I ve already choosen the root bridge and staticly configure it as primary root bridge.

Stgrange thing is I never get this error message unless I use 10/100/1000 gigabit ethernet ports of SE II plus TS.

Everything works fine when I work with fast ethernet ports on Line module.

I am beginning to suspect this error is uniq for 4503 SE II.

First: We have about 35 Cat4000 and Cat4500 switches in our (redundant) network and I’m very familiar with the hostflapping-messages and they can really become a nightmare, especially in large networks...

I’m sure your problem is related to temporary loops. They might be too short to be seen with show-spanning-tree-commands. You should debug spanning-tree events and, if possible, log in debugging-level. Possibly you’ll find out an interface changing sometimes shortly into listening-state which is supposed to be in blocking-state.

If so, the work just begins: You have to find out the reason for that. Could be a simple link-problem. What about using UDLD or LoopGuard? I prefer UDLD and really can recommend it.

hi rolf

35 4(5)00s together! phew man you r the one who has all the answers to my questions about 4500 :)

it seems bobby was right about the loop. i was pretty confident about my network was protected against loops but i will take your advice and get a closer inspection.

1- do you know if i can monitor the time of the transition of blocking/listening/lerning/forwarding states? perhaps i need to report it to upstairs :(

perhaps i need an extra tool other than cisco cli?

2- about the hostflapping, in your network did you try not to use the ethernet ports on the SE?

tx for helping.

I think the simplest way to monitor the transition states is, like mentioned yesterday, with debug-commands and, if possible, a logging server like e. g. the (free) Kiwi Syslog Daemon. For a perfect look, make sure that the timestamps show the real time (e.g. ‘service timestamps debug datetime localtime’ and taking the local time from a ntp-server). Debugging ‘spanning-tree events’ should notify detailed about the transition states (you can test it easily by disconnecting/connecting an uplink). Access-ports should be configured with ST portfast because (among other things) you don’t want to monitor their transition states.

However, of cause you can also see the actual state with show-commands but this is hard going.

Another option is a protocol analyzer tool like Ethereal or Packetyzer to monitor the BPDUs themselves. But this is also hard going and you need to have quite a bit experience and knowledge. So, again: The easiest way should be to operate with some debug-commands (but don’t overdo it!).

To your second question: With our access-switches I have to use the ports of the SE, because those are the only GBit-Ports I have (The core-switches are 6500s). In deed we had several faulty SE III that caused effects like those you see in your network. The SE IV seems to be much better.

What I finally did is optimize the spanning-tree with tool like BpduGuard, UDLD, RootGuard etc.

Some good sources are http://www.cisco.com/warp/public/473/16.html, http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080136673.shtml

You’ll need some time to study but it’s worth it! The good thing with faults like that is that you learn a lot of details about how ST works.

thanks rolf.

I have configured all ports connected to PCs like this

switchport mode access

speed 100

duplex full

portfast

RSTP is enabled on all switches.

force setup primary and secondary root bridges (manual)

after all, hostflapping message didnt appear yesterday. but still early to decide it was solved.

sure william,

i will keep testing next week and let u know the result.

Oh, I didn't know that you use Rapid ST. This is a little bit different.

We use the standard ST because we still have some old (non-cisco) devices which doesn't support RSTP.

I think most of the features I mentioned are automatically included in RSTP (e.g. portfast, uplinkfast).

By the way: If you see hostflapping-message only seldom, it's no reason to worry about. If an uplink switches from primary to the backup you might see this message once or twice. You only have a serious problem if you see it very often or even permanently.

Thank you for rating!

you are right uplink fast&backbone fast is included in RSTP but portfast has to be configured on ports connected to end users.