Bill's Blog on Automation

Unexpected Flooding of Switch Ports

On a recent occasion, we had a customer question us about the following confusing situation. An Industrial Ethernet switch had been delivering unicast messages to the proper port for quite awhile when suddenly the messages began flooding to all switch ports.

After a brief investigation, we learned that the customer had been sending a sustained stream of messages to a destination with no acknowledgements from the destination device. The customer had no need of acknowledgement and so had not arranged for a response.

This kind of traffic pattern is seldom encountered and, therefore, rarely causes issues. However, unexpected message flooding can occur under the circumstances that this customer had unwittingly devised. The issue involved the switch address table.

After a MAC address has a prolonged period of inactivity, an Industrial Ethernet switch removes the dormant address from its address table. The switch learns the MAC address of each attached device that transmits to the network. But when a device fails to transmit for a long time, the switch assumes that the device has failed or left the network and so removes the inactive address to improve the efficiency of its address table. This process is called aging and is commonly set to occur after about five minutes.

If you have a situation similar to that described above, you may consider a managed switch. Managed switches generally have the ability to adjust the address table aging time. For example, each model in the several lines of managed switches from Contemporary Controls can have its aging time set to over 12 days.

When You Can't Reach an IP Address

The annoying alert below is often encountered by Firefox users, but it is particularly frustrating in an 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 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!

Securing Ethernet Communication

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:

  www.ccontrols.com/pdf/Extv5n1.pdf

A Common Switch Mistake

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.

Surviving a Broadcast Storm

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).

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.

Matching Fiber Optic Ports

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!

Do Your Networks Interfere with Each Other?

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:

www.ccontrols.com/pdf/abc9.pdf

The Value of Rate Limiting

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:

LA Times Article

Does Your Switch Block Certain Ports?

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.

ODVA on EtherNet/IP Infrastructure

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 www.ctrlink.com/odva.

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.

Can My Switch Work with EtherNet/IP?

This simple (and rather common) question presents several issues to consider.

EtherNet/IP (EIP) is an open networking standard that supports implicit (UDP) messaging for I/O and explicit (TCP) messaging for data viewing, configuration and management. In June 2001 ODVA published the standard to answer a growing need for Industrial Ethernet in control applications. It brought object-based CIP into the world of Industrial Ethernet.

In satisfying the needs of EIP, it is crucial to use a switching hub which provides directed messaging and eliminates collisions when full-duplex links are used. But must the switch be managed?

There are instances in which an inexpensive unmanaged switch will work, but for optimal EIP performance a managed switch must be used. EIP applications often use such managed switch features as IGMP snooping, port mirroring, VLANs, switch diagnostics, port forcing and web browser support.

Being a layer-two device, an unmanaged switch can create problems in an EIP network. It cannot assist in troubleshooting. It cannot force a port to a certain speed or duplex setting. It cannot disable Auto-MDIX if needed. It cannot participate in a redundant ring nor any other redundancy scheme. It cannot recognize multicast frames and, therefore, may experience high traffic through its switching fabric which could result in a cascading (backbone) port with a backlogged queue.

In summary, if you want to use unmanaged switches in an EIP network, only use them where their operation will not materially affect the network performance. Unless you are running a very unusual EIP application, you are going to need managed switches at least in the major traffic switching portions of the network. And unless you have a router to segregate your EIP network from your enterprise network, you will also need a managed switch at this vital point to keep the EIP communication where it belongs.

To learn more about EtherNet/IP switches, visit:

www.ccontrols.com/pdf/abc9.pdf

Data Latency Can Be Variable

A recent inquirer was concerned that his measurement of data latency in Ethernet switches yielded widely varying results. He measured a latency of 7 microseconds (µs) in one test then twice that in a second test. Another device had a measured latency of 125 µs in one instance and 40 µs when measured again. The switches functioned well in all cases, but the inquirer was mystified by the differences.

The situation was that he was unaware of the profound variation in frame size that he was encountering. Latency measures the delay of the switch but also the re-transmission time of the frame. This means the longer the frame, the greater the delay. If the traffic with which you are concerned contains regularly-sized frames, you should expect very little variation in the data latency. But with random-sized frames, you get random latency.

UL1604 and Industrial Ethernet

Industry movement, in adopting Ethernet standards, entails conformance to various agency regulations not required in office environments. Industrial Ethernet products are designed and tested to the higher standards required for industrial equipment.

UL 1604 covers electrical equipment and accessories for controlling various equipment in hazardous locations. Such equipment should be UL 508 Listed as Industrial Control Equipment and have been investigated for risks to life and property in accordance with numerous standards. Unless battery-powered, the equipment installation must satisfy requirements in Article 500 of the National Electrical Code, NFPA 70.

Classes: Hazardous locations are those where fire or explosion hazards may exist due to the presence of certain substances. Class I areas pertain to flammable gases, vapors or liquids. Class II covers atmospheres having dangerous concentrations of dust. Class III applies to atmospheres containing fibers or flyings.

Divisions: Hazardous areas are further defined as either Division 1 (where the environment is normally dangerous) or Division 2 (where the risk is not normally present).

Zones: Class I hazardous areas are also specified by how prevalent the dangerous substance is during normal operation. The three areas are Zone 0 (risk is present and long-term), Zone 1 (risk is likely but intermittent) and Zone 2 (risk is unlikely).

Groups: For Classes I and II, product specification by Division and Zone varies by the materials group to which the equipment is exposed. (Class III equipment has no such specification). Class I has four gas groups: A (acetylenes), B (hydrogens), C (ethylenes) and D (propanes). Class II has three dust groups: E (metals), F (coal) and G (grains).

Temperature: Classes I and II (not Class III) specify the maximum ambient temperature that rated equipment can withstand without becoming a risk. Rated equipment receives a T-Code per the following table where values in parentheses are temperatures in degrees Celsius.

T1 (450)

T2 (300), T2A (280), T2B (260), T2C (230), T2D (215)

T3 (200), T3A (180), T3B (165), T3C (160)

T4 (135), T4A (120)

T5 (100)

T6 (85)

For example, a Class I, Div. 2 Industrial Ethernet switching hub is suited for an environment in which dangerous gases, vapors or liquids are potentially, but not normally, present. It is common to find Industrial Ethernet equipment qualified for all four groups (A,B,C,D) and rated T4A.

Markings: Finally, UL 1604 rated Industrial Ethernet products must have certain markings which commonly include:

listee name

model number

electrical input ratings (voltage, power, frequency)

terminal identification

location rating (eg: "Class 1, Div 2, Groups ABCD Haz. Loc.")

operating temperature code (T-Code)

date code of manufacture

notice of "Supplied from Class 2 Source"

fiber optic power (if applicable) in micro-watts

Industrial Ethernet a Hit at SPS 2006

During November 28–30, over 43,000 visitors (a record) attended SPS/IPC/DRIVES 2006 International Exhibition & Conference in Nuremberg, Germany. Europe's premier tradeshow for electric automation systems and components included 1,203 exhibitors from 31 countries and occupied some 77,500 sqm of floor space (also a record). Special venues were dedicated for Electric Drives and Motion Control, Mechanical Systems and Periphery, Control Technology and Sensors, Software and Sensors, and Control Technology and Interface Technology. Key exhibition topics were Ethernet in Automation, Motion Control, and Safety and Security in Automation. Several conferences addressed the role of Industrial Ethernet in automation. Specialized Ethernet information was also available from various organizations such as ODVA, PI (PROFIBUS and PROFINET International) and the EtherCAT Technology Group.

Contemporary Controls and its subsidiaries were represented by George Thomas and Bennet Levine from the USA, Jan Thriene and Joerg Wehnert from Germany, Peter Jefferson from the UK, and Basile Waite from China. The company booth featured a very popular race car game played over an Industrial Ethernet redundant ring.

How Important Is SNMP?

The world of Industrial Ethernet is continually evolving. As it evolves, networks and equipment become more complex and the need for managed switches grows. One of the most significant developments in this area is the Simple Network Management Protocol (SNMP) — providing the core functionality of managed switches.

A recent survey asked Industrial Ethernet users, "How important is SNMP in your network?" Roughly four of ten respondents reported that SNMP was extremely important. The same percentage indicated that it was "somewhat important". No one said that SNMP was unimportant, but nearly two of ten asked, "What is SNMP?"

Those unclear about SNMP can get answers at:

www.ccontrols.com/pdf/abc11.pdf

Industrial Ethernet Redundancy

As Industrial Ethernet increases in popularity, redundant communication schemes often become an issue in the factory, plant or in any of many other industrial settings. Often redundancy involves extra data storage, redundant DCE equipment (switches and routers), redundant DTE equipment (network interface modules, operator work stations, HMIs), uninterruptible power supplies and backup network paths. Note that the Internet is already highly redundant, so rarely is its packet-switching activity of concern in redundant considerations.

For backing up network paths, the STP and RSTP standards are available, as well as many proprietary schemes. But when considering a redundant network, the fundamental issue of the thoroughness of redundancy needs attention. Some network engineers aim for what is sometimes called "five nines", which means an uptime of 99.999% for a specified time. For example, this design criterion allows for only about five minutes of total downtime during a one-year period. But what factors in to such a calculation?

A network is never completely redundant; there is always a lack of redundancy at some level. Therefore, an essential decision to be made is what level of redundancy is necessary. The more thorough the redundancy, the more costly its implementation.

Often the only concern is to safeguard against cable failure. Achieving this level of redundant coverage is straightforward. It typically involves a relatively minor cost to provide the backup cabling and the devices needed to activate the backup cabling.

Sometimes it is decided to also supply redundant copies of the DCE devices — typically managed switches — that activate the backup cabling. Of course, this adds to the cost of the installation.

Occasionally, backup power is provided to maintain uninterrupted power to the DCE equipment — both primary and backup. But to fully guard against power interruption, the power conductors themselves must be duplicated.

What is seldom provided is backup of the equipment being serviced by the network. And even when such backup exists, there will always be some threat to the facility itself — earthquake, fire, etc.

In short, it is impossible to provide 100% redundancy for any system or activity. The most we can achieve is reasonable redundancy at reasonable cost — and the definition of what is reasonable varies considerably. In the end, you must ask, "How much redundancy is needed and is it cost effective?"

UL 864 and Industrial Ethernet "Components"

The UL 864 standard pertains to Control Units and Accessories for Fire Alarm Systems. When customers need to install such devices in their plants, confusion sometimes arises about how prospective equipment qualifies under UL 864.

UL 864 requirements cover discrete electrical control units and accessories installed in accordance with various National Fire Protection Association (NFPA) Standards including NFPA 12, 12A, 13, 15, 16, 17, 17A, 70, 72, 92A, 92B and 2001.

Industrial Ethernet products covered by UL 864 are system components — they are incomplete in some aspect of construction or limited in some performance criteria. Consequently, a component must be used in combination with other devices to complete a commercial fire alarm system that provides monitoring, control, and indicating functionality. Components are not stand-alone devices for direct separate installation in the field. Also, UL 864 covers electrical units for use in indoor locations.

EtherNet/IP Seminar in Chicago

On September 21, 2006, the ODVA held a free EtherNet/IP seminar in the Rosemont suburb of Chicago, IL. Four engineers from Contemporary Controls attended, including Joe Stasiek pictured below.

Most Industrial Ethernet networks are modified for a specific application and they differ in language, data handling and Ethernet devices. EtherNet/IP™ (promoted by ODVA) fully complies with Ethernet and Internet standards and uses the media-independent industrial protocol, Common Industrial Protocol — or CIP™.

Seminar subjects included overviews of Industrial Ethernet, CIP and EtherNet/IP — and a roadmap for EtherNet/IP development in the areas of safety and motion.

Powering Industrial Ethernet

How does the voltage sourcing for your Industrial Ethernet compare with that of others? A recent survey asked "What's the most common low-voltage power source used in your Ethernet applications?" By far the most common supply voltage is 24 VDC. The responses were:

24 VDC: 45%

24 VAC: 20%

12 VDC: 17%

12 VAC: 20%

Other: 10%

An RSTP No-No

A while ago a customer complained of a very long recovery time (from one to four minutes) for his RSTP network. He had connected two managed switches (which had no fiber ports) through four unmanaged switches (RSTP-unaware) which he was using as media converters to provide a fiber backbone. The illustration below shows the six-switch network with the pertinent switch ports numbered. The RSTP protocol had forced the blue link inactive, making it the backup link. Then, to test his RSTP performance, the customer interrupted the red link — causing the blue backup link to activate. The fiber backbone is indicated by the green links. Analysis revealed that the unmanaged switch address tables were the source of the problem.

The RSTP protocol had elected MS 1 as the root device, placing its ports 2 and 6 in the forwarding state. On MS 2, port 6 was placed in the discarding state to stop messages from looping through the blue link.

Broadcasts affect the address tables of all switches. This is true even if a switch is not serving any message path — as is the case with UMS 3 and UMS 4 while the blue backup link is inactive. Consequently, UMS 3 and UMS 4 correctly register both PC 1 and PC 2 as connected on port 3 of each switch.

When the network topology is reconfigured due to an interruption of the red link, UMS 3 and UMS 4 become part of the communication path, but they will be ignorant of the reconfiguration. Consequently, UMS 3 and UMS 4 will still try to forward all messages to the left via port 3 of each switch — although the reconfiguration requires that messages from PC 1 to PC 2 exit UMS 3 and UMS 4 to the right via ports 4 of each switch. This means that once the blue backup link becomes active, messages destined for PC 2 will be lost until the address tables of UMS 3 and UMS 4 are corrected.

Switches filter, forward or flood received messages. They flood messages when the destination MAC address is not in their address table. They forward messages when the destination MAC address is in their address table. They filter messages (throw them away) when the destination MAC address is associated with the same port on which the messages arrive.

Message filtering was causing the problem for the customer. The solution was to use media converters (having no address tables) that pass link status between the managed switches.

It is unwise for your RSTP network to have a mix of switches that are RSTP-aware with those which are RSTP-unaware. As can be seen in this example, sometimes the effects of such mixing can impair network performance.