two 4503 core switches are connected eachother with sfp, each switch has supervisor engine II+TS and two fast ethernet line modules.
on the hyper terminal menu, i am getting the message below when I use Gigabit port (on the supervisor engine II +TS) and fast ethernet ports (on line modul of 4503)
000010: *Jan 04 05:09:42: %C4K_EBM-4-HOSTFLAPPING: Host 00:04:CB:4D:C1:5A in vlan 1 is flapping between port Fa2/1 and port Gi1/15
000011: *Jan 04 05:10:55: %C4K_EBM-4-HOSTFLAPPING: Host 00:04:CB:4D:C1:5A in vlan 1 is flapping between port Fa2/1 and port Gi1/15
000013: *Jan 04 06:46:46: %C4K_EBM-4-HOSTFLAPPING: Host 00:05:BA:02:E5:2F in vlan 1 is flapping between port Fa2/1 and port Gi1/15
000014: *Jan 04 06:46:47: %C4K_EBM-4-HOSTFLAPPING: Host 08:01:32:B4:24:92 in vlan 1 is flapping between port Fa2/1 and port Gi1/15
keeps sending these messages...
I dont get any of above messages when I use only fast ethernet ports on the line modul.
I dont understand what am I doing wrong? 10/100/1000 gigabit ethernet ports on SE should work with fast ethernet ports on the line modules without any trouble shouldnt they?
how can i prevent those error messages?
thank you in advance.
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.
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 ?
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.
i think, host flapping message relate L2 looping.
first all of, you should check the cpu status using sh process cpu | ex 0.00. and then, check the spanning tree status using sh span sum etc...
if L2 looping exsit in your network, you change some of cost such as "root bridge priority"...etc...
Whenever i met the same situation like you, i configure bridge priority...but you should consider what's switch be the root bridge...
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 Im very familiar with the hostflapping-messages and they can really become a nightmare, especially in large networks...
Im 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 youll 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.
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 dont 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 dont 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.
Youll need some time to study but its worth it! The good thing with faults like that is that you learn a lot of details about how ST works.
I have configured all ports connected to PCs like this
switchport mode access
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.
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!