Bill's Blog on Industrial Ethernet

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:

Some time ago, a customer called to ask, "Are ports 1628 and 1629 open or blocked in your Industrial Ethernet switch?"

In general, the question was referring to TCP/UDP ports — the numbering scheme by which OSI layer-four messages are identified and controlled. Note that TCP/UDP ports are mere numerical abstractions that serve record-keeping and permissions purposes. Such ports are altogether different from the physical ports where CAT5 cables attach to Industrial Ethernet switches.

This specific inquiry was about the LonTalk protocol which uses port 1628 for normal messaging and port 1629 for urgent messaging. TCP/UDP ports are identified by 16 bits and are therefore numbered from 0–65,535. The lowest-numbered ports (0–1023) are reserved for specific TCP/UDP functions. Ports 1024–49151 are reserved by organizations. The remaining ports up to 65535 are for private use.

Regarding the question posed by the customer, the simple answer was that neither these ports nor any others were blocked because our devices are layer-two switches. Layer-two switches are ignorant of TCP/UDP functionality. To selectively block such a port requires what is often called a layer-three switch (or a router).

In summary, if you are using a layer-two switch — whether plug-and-play, configurable or managed — you need not worry about it blocking any TCP/UDP port. A configurable or managed layer-two switch could impose blocking of a physical port, but it does not have the ability to block TCP/UDP ports.

The ODVA has addressed those Ethernet features that are important to EtherNet/IP networks with its publication of Network Infrastructure for EtherNet/IP. This 118-page document covers issues most users feel are important to their specific applications. It references specific switch features (such as IGMP Snooping) that EtherNet/IP users require to facilitate proper communication. IGMP Snooping is especially significant because it can relieve hosts from the task of processing unneeded frames. Networks with multiple end devices that produce implicit data, may suffer performance issues if IGMP Snooping is not implemented.

To obtain your copy of this document, visit:

Bennet Levine, R&D Manager for Contemporary Controls, was one of the members on the EtherNet/IP Infrastructure Task Force who helped write this document.