High levels of broadcast traffic may occur in most Industrial Ethernet networks and can hog available bandwidth, rob CPU time from end devices and in extreme cases may cripple a network. This situation can exist due to improperly set STP or RSTP parameters or malfunctioning PCs or end devices.

Routers can block broadcasts or other problematic traffic, but they are usually more expensive than switches and, generally, not as fast as switches.

Since some amount of broadcast traffic is likely present on your network, wouldn't you like to know how much is too much? A helpful management feature is rate limiting with which you can control your exposure to these levels of traffic. But the question becomes, "How much traffic can you sustain?" You can create your own traffic generator and then slowly raise the amount of broadcast traffic using rate limiting until you see a problem. This should help you establish the optimal rate limiting levels. You should probably set all message types to this level. Although broadcasts are the most common type of flooded messages you see during a message storm, you can also see directed or multicast messages arriving at a very high rate.

With a managed switch you can "fine tune" your message storm tolerance as described below — if certain precautions are taken. On the PC used as your test station, use a fixed IP address instead of DHCP and disable your firewall.

Procedure: Connect your PC to your LAN via a managed switch. On this switch, loop two ports together — taking care to disable RSTP or STP on the ports you have interconnected in creating the loop. Ping your subnet broadcast address. (For example, if your IP address is 192.168.1.1 and your netmask is 255.255.255.0, then your subnet broadcast address is 192.168.1.255.) This creates a traffic generator which can test your system survivability to various levels of traffic. Use rate limiting to control the level of traffic. (This could be done with an unmanaged switch, but the managed switch gives you the ability to control the level of traffic.)

Warning! Performing the above procedure on a production or office network will most likely cause com