Bill's Blog on Industrial Ethernet

The annoying alert below is often encountered by Firefox users, but it is particularly frustrating in an Industrial Ethernet network that contains few devices.



As listed above, the site could be "temporarily unavailable" — a nice way of saying the targeted device is offline, perhaps due to a malfunction. The second suggestion above to "check your computer's network connection" is always good advice. The third caution about a "firewall or proxy" is less likely to be an issue — and usually you are aware of such situations anyway. And for those of you still using Internet Explorer (IE), the alert below gives similar suggestions.



The third suggestion from the IE alert above is perhaps the most significant to Industrial Ethernet users. Mistyping is among the most common cause of errors. But here is where you may encounter a most surprising and very simple mistake — one that often goes quite unrecognized until time has been wasted investigating other, more-expected issues.

This common mistake alluded to above occurs when you are careless with your list of network IP addresses. Have you ever failed to realize that you are typing in the very same address of the machine at which you are typing? Yes, making this simple mistake will yield either of the alerts shown above. Before you start checking network connections and other issues, confirm that you are not targeting your own IP address!

Sometimes an issue arises regarding the security of Industrial Ethernet communications. For example, security could be a major concern when Industrial Ethernet messages travel over the same network infrastructure accessible by BAS (Building Automation Systems), office personnel or IT staff. A simple way to provide the needed security is to use a VLAN (Virtual Local Area Network).

A VLAN restricts communication to stations that are VLAN members — non members are not privy to VLAN conversations. There are two basic types of VLANs: Port VLAN and Tagged VLAN (IEEE 802.1Q). Port VLAN, available on some configurable or smart switches, is simple to implement but has limited utility because its area of control is the set of devices attached to a specific switch port. Tagged VLAN, a feature of almost all managed switches, can extend VLAN membership through many switches to stations separated by considerable distances. Therefore, Tagged VLAN is almost always the best choice for Industrial Ethernet security.

Tagged VLAN works by embedding a code segment (the tag) within each Ethernet message. Membership information in the tag allows the message to be sent to only those stations that belong to the VLAN. For this scheme to work, each VLAN member station must attach to an appropriately configured managed switch that has VLAN functionality enabled. But the total communication path could contain unmanaged switches at points where VLAN decision-making would be unneeded.

Typically, a managed switch can accommodate several VLANs, each with its own set of members grouped according to whatever criteria are relevant in the Industrial Ethernet strategy. Thus, configuration of VLANs can generally be as simple or as complex as the situation demands.

Beyond security, other issues arise from mixing Industrial Ethernet with BAS or office networks. BAS traffic can consume a significant portion of available bandwidth. The same can be true of Internet data transfers. VLANs also help in managing the levels of such traffic — segregating bandwidth hogs (Internet downloads and security camera video) from other traffic.

For more information about VLANs, see this document:

Have you ever installed a switch only to discover that certain communication does not pass through it? One of the most common issues that arises in the installation or reconfiguration of an Industrial Ethernet switching hub (managed or unmanaged) involves the most defining feature of a switch — its address table.

Typically installers attach various CAT5 cables to a switch, power it up and check for initial functionality. Sometimes the initial functionality will be less than perfect for various reasons: a remote device has not been turned on, auto-negotiation was disturbed by some transient condition, initial cable placement needed to be changed, or some other issue caused a glitch.

Any of the issues mentioned above (among many others) could prompt the installer to move a cable from one port to another to see if the second port behaves in the same way as the first one that experienced the problem. Indeed, your natural inclination might be to move a cable from one port to another, then to another, and so on until each port Link LED has been confirmed to glow as expected.

But the port-swapping scenario described above can create headaches because of how the switch address table works. When a source device sends a message through the switch for the first time, the switch learns that the originating device is connected to a specific switch port and the switch records this device/port association in its address table for future use. If you then move that device's cable to another port on the switch, the switch still "thinks" the device is attached to the first port. Consequently, messages bound for the device will be mis-sent to the original port until the switch "realizes" the situation and updates its table — a process that usually takes several minutes. Until the mis-addressing is corrected, you might well think that the switch is defective. Pings to devices that are "lost" due to port swapping will go unanswered until the address table is correct.

If you find yourself confronting this address issue, the situation will self-correct in a few minutes (typically five) — or you can correct it immediately by cycling power to the switch.

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 (see "The Value of Rate Limiting" at the link below).


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. Now you can adjust the amount of traffic being generated by the traffic generator. (Although some unmanaged switches offer broadcast storm control, a 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 communications problems — only a test network should be used.

It is surprising how often a question arises about determining the fiber optic port compatibility between two Industrial Ethernet devices. The issue frequently involves matching a media converter to a switching hub.

On several occasions I have been asked why existing equipment is not communicating through a newly installed media converter. The problem is usually that the fiber optic port of one device is incompatible with that of the other. It seems that installers tend to assume that because the copper port of the media converter auto-negotiates the data rate to either 10 Mbps or 100 Mbps, then the fiber optic port will also adjust automatically. But that is not so (except for seldom-used equipment that is compliant with the 100BASE-SX specification).

Industrial Ethernet hubs and switches that operate exclusively at 10 Mbps — and have at least one fiber optic port — will most likely comply with the 10BASE-FL specification for fiber communication (unless the equipment is very old). Most modern switches are capable of operating at either 10 Mbps or 100 Mbps — but although their copper ports may adjust for data rate, their fiber ports will comply only with the 100BASE-FX specification.

A fiber optic port will not negotiate its data rate because it is fixed at the rate specific to the transceiver type. A 10BASE-FL transceiver passes a 10 Mbps data stream using a fixed wavelength of 850 nm. On the other hand, a 100BASE-FX transceiver passes a 100 Mbps data stream at a wavelength of 1300 nm. If someone connects an 850 nm fiber optic port to a 1300 nm fiber optic port, communication will not occur due to this difference in wavelength.

Another, less-common, issue is the compatibility of the fiber optic cable itself.

Most multimode fiber optic cable in North America is 62.5-microns in diameter (elsewhere, 50-micron cable may be more popular). This cable is basically used for segment distances under 2 km, works efficiently at either 850 nm or 1300 nm, and uses LED transmitters.

Single-mode fiber optic cable has a tiny core diameter in the range of 5 to 10 microns, works efficently at either 1300 nm or 1550 nm, and uses laser transmitters. It allows much greater data flow and much greater distance.

Both multimode and single-mode fiber optic cable can pass data at 1300 nm. But even if passing the same wavelength of light, single-mode fiber optic cable, multimode fiber optic cable, and their respective transceivers are incompatible with each other.

When troubleshooting a problem in which newly installed equipment with fiber optic ports is not communicating, do this first: Confirm that the port characteristics at one end of a run of fiber optic cable matches the port characteristics at the other end!

Recently I heard about a CEO who became quite agitated when his office network traffic crawled to a standstill due to his control network.

In the field of Industrial Ethernet, a common task is protecting the control network from traffic originating in the office or corporate network. Usually the control network has equipment that must operate reliably — with control messages delivered on time and error-free. Office traffic can wreak havoc in the control network, but sometimes the situation is reversed; your control network can interfere with your office network — much to the consternation of people you'd rather not offend.

As EtherNet/IP and other protocols using multicast messaging have proliferated in control networks, traffic issues have appeared. End devices can create a lot of multicast traffic. It is important (sometimes crucial) to specify devices to receive this traffic to avoid overwhelming a network. IGMP snooping (available on many managed switches) can direct multicasts to only the devices needing it, but a switch without IGMP snooping will flood such messages to all ports.

EtherNet/IP join messages are handled by all IGMP snooping switches that use information in the messages to determine which ports will get the multicast data — restricting multicasts to only devices that expect them. For this scheme to work, one or more switches or routers in the network must provide IGMP queries to periodically ask end devices to subscribe to multicasts. Without the IGMP query function, IGMP snooping switches will eventually forget their multicast-handling strategies and received multicasts will flood the network. Because the IGMP query is critical to IGMP snooping, it is recommended that multiple switches in the EtherNet/IP network have the query ability.

Some people successfully use port security (aka port locking) to keep corporate traffic from the control network, but IGMP snooping is the preferred solution. Both IGMP snooping and IGMP querier functions are available on all managed switch products from Contemporary Controls. More about IGMP snooping can be found at:

On August 11, 2007, nearly 20,000 passengers (by some estimates) were stranded for many hours at Los Angeles International Airport. The incident involved a U.S. Customs computer network containing information used to screen passengers seeking entry to the United States. It went down around 1 p.m. PDT and was not restored until 11:45 p.m. The last of the backlogged travelers from some 73 flights were not processed for another five hours.

Acting port director Peter Gordon reported, "This is probably one of the worst days we've had. I've been with the agency for 30 years, and I've never seen the system go down and stay down for as long as it did". U.S. Customs and Border Protection spokesman Mike Fleming added, "This was unprecedented in terms of impact."

Early reports blamed a "computer glitch", then suggested faulty hardware in general and insufficient backup, then perhaps the fiber optic cabling. It was determined three days later to be a sputtering network interface adapter.

Whether the interface adapter was generating a broadcast storm or some other torrent of Ethernet frames is unclear, but there is no doubt that the system was derailed by the card's incessant output.

While this incident involved no loss of life (although many passengers were hospitalized), the inconvenience to the travelling public was monumental. In some areas of Industrial Ethernet, such an outage could prove very costly in terms of economics and lives threatened.

The lack of systems backup was bemoaned by several analysts, but providing backup is never complete nor perfect. With the use of rate limiting (or rate control) that is available on some managed switches such as those from Contemporary Controls, the problem could have been so minimized that the network would likely have survived the card failure.

The exact nature of rate limiting varies by equipment, but typically ingress and egress port traffic can be controlled for the rate and type of traffic. Switches with this functionality allow you to control the rate of broadcast, multicast or unicast messages — and perhaps even destination look-up failures and MAC control frames. With these tools, bandwidth allocation can be fine tuned.

By limiting all frame types, the full bandwidth of a port can be controlled. Selecting only broadcast frames will create broadcast storm control governed by an adjustable maximum bandwidth setting. Rate control can be useful for connecting a Windows® computer to the control network and for limiting communications from an unknown or uncontrolled network such as when interconnecting the office and control networks.

For more about the airport incident, follow the link below: