Network analysis optimizes Ethernet network value

The performance level of automation and control applications on Ethernet is such that inefficiencies due to errors, congestion, collisions and extraneous traffic must be avoided. One way to avoid such inefficiencies is through a comprehensive network analysis. These often are performed to help control and network engineers implement migration projects across a range of vendor platforms.

For automation users, deterministic performance of Ethernet as a fieldbus is essential for control, messaging and large data acquisition applications. Simply deploying the latest switching technologies may not ensure determinism if those features are not carefully designed. A comprehensive examination of the network communications matrix, message traffic, host protocols used and capabilities of the infrastructure can lead to greater performance and reliability for the user’s investment.

A comprehensive network analysis should identify inefficiencies that rob performance, which include:

• System bottlenecks and congested message queues
• Unauthorized hosts or devices on the network
• Unnecessary protocols in use
• Excessive collisions, errors and delays
• Excessive broadcast or multicast traffic from switches, routers and PCs.

Identifying and correcting problems in these areas produce a cleaner, faster and more effective network. Free of such bottlenecks, Ethernet is real-time and deterministic.

In an advanced network analysis, traffic samples from different areas of the network are collected using protocol analyzers and other tools. Hosts are identified and entered into an Ethernet modeling topology map. Protocols, frame types and message types are sorted and analyzed for problem areas. Delta times for communications are profiled for each conversation pair.

The data collection process to baseline the network can, however, impose some challenges. An accurate picture of IP traffic and conversation pairs is developed in a shared Ethernet environment because all Ethernet MAC frames are broadcast to all ports on all segments. A single sample on a shared Ethernet network for 60 seconds should reveal a traffic pattern on the network.

This makes the use of a protocol analyzer especially useful in a shared environment. However, when the environment is switched, traffic is forwarded by the switches using virtual point-to-point circuits within the switch. This behavior minimizes the utility of a protocol analyzer. In a switched environment, connecting a protocol analyzer as a host on any particular port will limit its capturing ability to mostly broadcast and multicast traffic. Therefore, conversation traffic between controllers at Layers 3 (IP) and 4 (TCP) will bypass its ability to sample such traffic. One remedy is to use port mirroring – available on some Ethernet switches – to replicate traffic from one port to another.

The benefit is that traffic data can be collected unobtrusively by an attached protocol analyzer on the monitoring port. However, to collect traffic samples for all network devices would be time consuming on large networks. Then, all of the packet traces would have to be correlated to get an overall view of network loading.

Another method of data collection for analysis is the use of an SNMP Manager to perform a Ping discovery and SNMP Get Request to interrogate devices. The shortcoming of using this method is that it is of value only to devices that support SNMP. If the user’s network devices do not support SNMP, any devices found will be generic and have a limited amount of information that could be obtained from them. Also, SNMP works well only for existing Ethernet devices. If a user wants to project the addition of a number of devices, or simulate the increased traffic, SNMP may be of limited utility. An SNMP manager can populate devices, but cannot generate a traffic load for the added devices.

Traffic analysis reports the use of any extraneous activity that would generate excessive or unnecessary broadcast traffic such as the IPX/SPX, NetBeui or DLC protocols. Also, multicast traffic such as RIP updates, bridge updates and PC name server requests are examined and minimized, retimed or groomed out of the system if they are unnecessary. This traffic analysis also reports on total network activity and throughput. This sampling can also be inserted into a simulation model to study the effects of delays, collisions, errors, infrastructure device choices, port densities and congestion.

Topology analysis, the device, media and topology criteria are collected and mapped into a model. A load can then be simulated upon the topology indicating delay times at each node and stresses within the network.

From the traffic sample collected, analysis is performed to determine the protocols on the network and their origin. Frames are examined for proper size and construction in accordance with Ethernet II and IEEE 802.3 standards. Modbus TCP messages are also examined for correct formatting and conversation pairs. This will identify the traffic pattern associated with the devices. Frame analysis is particularly useful when troubleshooting a few devices, but of limited use to project network expansion.

From the traffic samples collected, a network analysis report should indicate problems and potential problems in the network. In some case, the actual traffic can be transferred into a simulator, where the communications are replayed on the network and further excessive network delays are identified.

Models are constructed and analyzed in one of two ways depending on whether the topology and Ethernet access method is switched or shared.

An inventory of devices and packet trace samples are collected to characterize the network. The model is then constructed with the criteria for each device entered into the model. The live traffic captured from a protocol analyzer can then be imported into a modeling system to analyze the amount of UDP, TCP and other traffic, as well as conversation pairs, latency, explicit point-to-point and background traffic such as broadcasts, multicasts, bridge updates (BPDUs), router updates and other services traffic.

The model is then subjected to a simulation, which will generate traffic over a predetermined period of time and produce a result, which may then be studied. The results are analyzed and adjustments are made to the model in software. The simulation is then run again to produce potential what-if scenarios of network changes. Therefore, the impact of potential changes can be studied before any configuration changes are performed on the network.

Once the model has been constructed and calculated, the results of model testing can indicate areas to focus on for improved throughput, as well as red flags for obvious deficiencies. Evaluating all of the facts and basing the changes on a priority basis develops a change strategy. These changes are then inserted into a duplicate model and the simulation run again to compare the findings. Once the user’s controls group validates the changes, an implementation schedule is drawn up and any desired changes are implemented.

A network analysis is useful not only in terms of optimizing existing networks, but for projecting performance if growth is anticipated. The impact of traffic loading, application scan times, packet inter-arrival times and Ethernet, IP and TCP stack processing delays can aid companies in projecting performance levels decisively.

Once a strategy is proven and change orders are rendered to optimize or expand the network, network certification engineers can provide the on-site assistance necessary to implement these changes.

Determinism is within the realm of Ethernet as a fieldbus with proper planning, segmentation and load balancing. Fault tolerance should also not be overlooked as a measure of preserving plant productivity and uptime. Conducting a comprehensive network analysis is the first step toward achieving those goals.