We've been seeing a lot of "excessive broadcast " messages from across our network. Our theory was that when a mobile cart full of laptops gets plugged in, all those broadcasts hitting the network may generate that message.
Is there a way we can track down the source and help eliminate these warnings?
A snapshot from the syslog may be more meaningful, assuming you setup syslog.
Basically, when a machine boots, in the syslog you may see several log entries: ports: ...off-line ports: ...on-line FFI: ...CRC/alingment errors FFI: ...Excessive Broadcasts
These are normal and usually can be ignored. Problem is when can they be ignored and when should there be more concern? PCM does not have any option to decide that important question.
You don't mention what model switch you have and what code level. After updating my 5308xl switches to 9.22, almost all of those alerts are no longer being trapped.
Heres the syslog from one affected switch I 04/14/05 17:16:14 ports: port 47 is now on-line I 04/14/05 17:16:17 ports: port 47 is now off-line I 04/14/05 17:16:19 ports: port 47 is now on-line W 04/14/05 17:16:30 FFI: port 47-Excessive CRC/alignment errors. See help. I 04/14/05 17:17:11 ports: port 35 is now on-line I 04/14/05 17:20:20 ports: port 3 is now off-line I 04/14/05 17:20:23 ports: port 3 is now on-line I 04/14/05 17:20:28 ports: port 3 is now off-line I 04/14/05 17:20:30 ports: port 3 is now on-line W 04/14/05 17:20:44 FFI: port 3-Excessive Broadcasts. See help.
So you're saying that can generally be ignored?
Is there a way to have PCM set a threshhold to ignore these (I have "link up/down" ignored already), so in the event of a real broadcast storm we may get a notice?
Correct, that is what I am saying. If you were to live in the Traffic Monitor of PCM as I do, then only what makes it in there is likely to be of any real consequence.
As for tracking down the source and eliminating the warnings, good luck. You may try experimenting with newer drivers or power management settings to reduce the volume of warnings but I doubt you can eliminate them completely.
I am not sure what HP put in their 9.22 code, but it reduced the noise in my logs by around 90%. For that I say KUDOS and THANKS.
I have been a bit of a thorn in their side on this topic for some time now. They probably consider me "noise" as well. ;)
Why do you think the port toggles can be ignored? Don't they indicate that there's a driver issue, cabling issue or switch issue? I'm seeing lots of these on my 2650's.
S├Г┬╕ren, If there are port toggles and the computer is NOT booting or rebooting they should not be ignored. You are correct, that toggles may be an indication of a hardware/software issue or power management setting.
That was why I said that PCM does not have the intelligence to decide what not to log. A human needs to interpret the lo
I meet the same link up/down problem as S├Г┬╕ren Fisker on 2650 switchs. We have 5304xl and 2824 switchs too and the error seems not appear on they. We have tried every thing around speed-duplex auto-nego, MDI mode and LACP, but the errors still appear. The problem is that the toggle last 20 ms, that is transparent for all applications except "Lotus Notes" which hang on each toggle. Have you identify the problem on your 2650 switch
I have been working with the danish HP network support on this for a while, and although they're very nice people they have no clue as to what's wrong - and thus have been completely useless. I've tried firmware H.08.58 (not yet on web) which made no difference. They basically tell you that it's a problem with either nic, patch cable or switch port. When you've checked those they'll offer to replace the switch, and if that doesn't help they're completely lost. I'm very sure this is a firmware problem.
I have seen power management settings cause excessive port toggles. Make sure to turn off power management on the NIC.
While the following does not cause port toggles, I also like to turn off LACP on most switches and make sure that spanning tree is properly configured.
Since upgrading my 5308 switches to 10.04 code, these FFI events that so often accompanied a link up are almost entirely eliminated. Kudos to the software engineer that fixed it. Reviewing my SysLogs is almost a pleasure now.
we have a lot af 8000M switches with 100BaseFx-modules. Our PC's mostly have a 3C905B-FX NIC, but we also have many laptops with mediaconverters (100baseFX-100BaseT. (fiber all the way between swithces and computers).
I see many of these excessive messages when there is a mismatch between the duplex-settings on the NIC and the switchport. All of our switchports are set to 100FullDuplex, but sometimes the NIC's on the PC are set to hardware default, auto or 100HalfDuplex and then the log are filled up with excessive broadcast. it also happens when the mediaconverter is not correctly configured.
TIP: to filter out write "log exc".
When I visit the user to correct the NIC-settings, most of them havent noticed any slow performance. seems to me that this is only unnecessary noice in the log.
Excessive broadcast and multicast traffic can seriously degrade network performance. By following the configuration examples given here and disabling IP-directed broadcasts on edge routers, it is possible to mitigate the effects of excessive broadcast and multicast traffic.
...except these "error" messages aren't caused by "excessive" broadcasts.
I may be wrong, but I assume they are caused by PC NIC traffic being dropped by the switchport while it is in "blocking" for a period as it becomes enabled. The PC is getting no reponse to its ARPs and keeps sending requests as all the active processes become aware the NIC is up and start sending traffic to it.
