Content
- 1 Broadcast Storms, Multicast Storms, and Spanning Tree Failures
- 2 Broadcast Storm
- 3 Multicast Storm
- 4 Spanning Tree Protocol (STP) failure
Broadcast Storms, Multicast Storms, and Spanning Tree Failures
There are a few potentially severe failure modes associated with the Mesh network, although in all fairness, these failure modes are associated with almost any network. The concern with the Foxboro Mesh is that it can potentially impact your entire control system. What this page will attempt to do is provide some background on these concerns and things you can do to reduce or eliminate the risk. —Gfhicks 17:37, 14 Feb 2008 (CST)
Broadcast Storm
– We’ll start with the easy one. The scenario here is that there are a large number of broadcast packets dumped onto the network from some device connected to the network. For a more detailed explanation of broadcast storms see http://en.wikipedia.org/wiki/Broadcast_storm. Based on testing done at TVA, and conversations with Foxboro personnel, the ZCP270/FCP270 controllers themselves are not noticeably impacted by a broadcast storm due to the design of the onboard Ethernet controller. However, what a broadcast storm on the Mesh can do is slow down HMI updates, and can completely smurf all displays. There is also the potential to impact ZCP to FCM communications (does not impact FCP to FCM communications).
– This one is relatively easy to mitigate on most if not all available Mesh switches. Broadcast packet limits can be set on all switch ports, typically to a value of 500 packets/second, that will limit broadcast traffic to negligible levels, but high enough to support normal network requirements. The default settings in the Mesh Configurator software version 2.2.6 is 500 packets/sec for 100MB ports, and 5000 packets/sec for 1GB ports. —Gfhicks 17:37, 14 Feb 2008 (CST)
Multicast Storm
This type of storm is somewhat less likely on a network, but still possible. This scenario has a multicast packet storm, which could be generated either by a faulty network switch or workstation network card, going out and over the network. For or more detailed explaination of multicast packets, see http://www.firewall.cx/multicast-intro.php. Unlike the broadcast packet storm, the ZCP270/FCP270 controllers will respond to and process these packets, which will consume CPU resources, in addition to causing problems with the HMI stations. The multicast packet storm will have a much greater potential impact on the ZCP architecture than it does the FCP architecture, since it will directly interfere with the ZCP to FCM communications. The results of this will be that a fault tolerant CP pair will go single due to data mismatches (caused by increased latency in the IO data getting to the CP), and IO updates from the CP will slow down, sometimes significantly (several seconds). With the FCP architecture, informal testing has shown that a fault tolerant pair will go single, but with no IO or process impact (This needs to be independently verified!).
– This one is not-so-easy to mitigate. On the higher end mesh switches, such as the Platinum Blades, rules can be set up to limit multicast packets based on mac addresses, and on most if not all mesh switches VLANs can be used to segment the ZCP Fieldbus network(s) from the overall Control network. By using the multicast packet rate limiting in the higher end switches, this failure mode can be mitigated. The benefit of using the VLAN architecture is that it limits the impact of this type of failure to a single ZCP or the Control network. —Gfhicks 16:52, 23 Jun 2008 (CDT)
Spanning Tree Protocol (STP) failure
Coming Soon