Tuesday, October 06, 2009
Broadcast Storm Control
Broadcast messages are those sent to all possible destinations on a network. An Ethernet switch is designed to differentiate traffic by target destination — thereby achieving more efficient communication than is possible with a repeating hub. But if broadcast messages are sent when a switch is in the network, the switching strategy is defeated and the switch behaves much like a repeating hub.
A broadcast message is one with a destination MAC ID value of all ones (FF FF FF FF FF FF). Too many of such messages can be problematic, but Ethernet switches have a feature called Broadcast Storm Control (BSC) that can be employed to mitigate the issue. However, under some circumstances, BSC can itself cause problems.
BSC is disabled on all unmanaged (plug-and-play) switches from Contemporary Controls. This policy was adopted because some users will suffer dropped messages if they employ an Ethernet strategy that sends continuous broadcast messages. Instead of sending directed messages that use the essential characteristic of a switch, some applications deliberately broadcast messages to every device — even though only one may need it. Since BSC is seldom needed by most users, Contemporary Controls made a conscious decision in October 2008 to disable this feature on all unmanaged products.
Contemporary Controls offers a configurable switch (the EISC Series) in which BSC can, at the user's discretion, be enabled or disabled globally (applying to all ports or to none). On managed switches, BSC is not explicitly available. Instead, a similar strategy is accomplished with a feature known as Rate Control which allows the user to control rates of various types of traffic and vary the control by port. Like unmanaged switches, our managed switches have this feature disabled by default — but it can be enabled by the user quite easily.
If a customer wishes, unmanaged switches from Contemporary Controls can have BSC enabled at the factory — by request and at no charge. When enabled, each switch port will drop broadcast packets after receiving a continuous stream of 64 broadcast packets. The counter will reset to zero every 800 ms or if it receives a non-broadcast packet (one whose destination MAC ID is something other than FF FF FF FF FF FF).
With the appropriate equipment, it is possible to ascertain whether or not BSC is in effect on an Ethernet switch. To do this you will need a computer that has Ethernet connectivity, another Ethernet switch that is known to have BSC disabled, and three CAT5 patch cables. The setup is illustrated below. By observing the port LEDs, you can easily see how a broadcast storm is affected when BSC is enabled or disabled.
To use this setup, send a ping to an IP address that does not exist on the network. When the Ethernet switch receives the ping, it will examine its address table and discover that no such device is known. In response, the switch will send an ARP message (broadcast to all ports) in an attempt to locate the unknown device.
With the BSC feature enabled on the switch under test, you will see that all LEDs blink slowly when the ping is in progress. With BSC disabled, you will see that the ARP message causes a broadcast storm by virtue of the loop between the two switches and the LEDs are blinking rapidly.
Monday, August 10, 2009
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.
Monday, July 20, 2009
Using the BACnet® Discovery Tool – BDT
When applying BACnet routers in the field is there a quick way to determine if the router is successfully communicating to attached devices? We think there is with the BACnet Discovery Tool (BDT). Although limited to very simple tasks, it is easy to use — and it is FREE!
The BACnet Discovery Tool (bdt.exe) is a BACnet/IP application for Windows® that is easy to install and use. It is an excellent means for verifying communication with MS/TP devices that are being accessed through BACnet/IP routers such as those available from Contemporary Controls: the BASRT-B DIN-rail mounted BACnet/IP-to-MS/TP router — or its portable counterpart, the BASRTP-B.
The tool is based on an open source BACnet protocol stack developed by Steve Karg. His project is described at:
At just over 520 kB, bdt.exe is small — making it a snap to download. When you download the tool, you can save and run it from anywhere on your computer's hard drive.
We use BDT with our BACnet Interoperability Board. On this board we mount equipment from different BACnet vendors to prove our routers operate with different equipment configurations. In the photo at the end of this article you will notice mostly Alerton devices being tested, but we can change out equipment as needed. Although we have more elaborate BACnet tools, BDT is a vendor-neutral tool that can quickly discover BACnet devices. To give you an idea on how this works, we configured our board with three MS/TP segments each tied to a dedicated BAS Router. Each BAS Router has its BACnet/IP side tied to a common network through one of our Ethernet switches. Attached to the network is a workstation running BDT.
We launch bdt.exe by double-clicking its filename or icon. As soon as the application starts, it opens in its own window. It immediately activates its Who-Is service and transmits one Who-Is query. If we do not see any response within a few seconds, we can try pinging the IP address of the router to confirm that its IP channel is functional. NOTE: Because bdt.exe sends a BACnet/IP Who-Is (not a BACnet/Ethernet Who-Is) it will not discover any devices which only support BACnet/Ethernet.
Each I-Am response is reported on screen as soon as received. As shown in the screen below, each response also identifies the associated Device Instance number and Vendor identifier. The first three responses are from Contemporary Controls whose vendor number is 245. The remaining devices are identified as manufactured by Alerton whose vendor number is 18.
NOTE: For ease of illustration, the screen capture has been altered so that two lists that actually appear one-after-the-other , are here displayed side-by-side. Also, both lists (the responses on the left and the device information on the right) are abbreviated.
After all of the I-Am responses have been received, bdt.exe summarizes the information it has received as illustrated in the right portion of the sample screen. In this example, you see a list of many respondents on the left. The associated summary list on the right reports each Device Instance, the device’s maximum Application Protocol Data Unit (MaxAPDU) value and the number of the network ( Net) on which it resides. A Net value of 0 represents the network to which the BACnet Discovery Tool is attached — and so it must be an IP network. (This identification is reinforced by a MaxAPDU value of 1476 — typical of an Ethernet network.) Since the first three responses in the device summary on the right show that devices 202162, 202161 and 202160 have Net values of 0, the originators of the first three I-Am messages must be BACnet/IP devices — in this case, they are the three BAS routers.
The second column (MAC) of the summary report on the right, requires detailed explanation. The MAC value is a composite of two pieces of hexadecimal information obtained from the BACnet/IP device involved in each I-Am response. The first eight digits represent the IP address of the BACnet/IP equipment that has delivered the I-Am response. The last four digits report that device’s BACnet/IP UDP port number.
NOTE regarding the MAC value: there is a significant difference between the BACnet/IP protocol (used by bdt.exe) and the BACnet Ethernet protocol. The bdt.exe MAC value is not the Ethernet MAC address as you might expect. This is because BACnet/IP protocol uses the device IP address as the MAC value. Only BACnet Ethernet protocol uses the actual Ethernet MAC address as the MAC value.
The equipment delivering the I-Am response could itself be simply a BACnet/IP device (as is the case with the first three respondents) — or it could a router that is acting as an intermediary for devices on the far side of the router (which is the case with the remaining respondents in our example).
If the response Device Instance is that of an MS/TP device, then the associated MAC information pertains only to the router that delivered the response.
The first response shows device 202162. Its information tells us it is a BACnet/IP device (Net value 0) whose MAC value reported an IP address of 0A0000D9 and a BACnet standard UDP port number of BAC0.
Responses 4 and 5 are for devices 3015 and 3002, respectively. Because these two lines have identical MAC values, their I-Am responses must have passed through the same BACnet/IP router — a fact also indicated by the matching network numbers of 100. In this case the router’s IP address is seen to be C0A85C64 — and the router used UDP port BAC0. NOTE: If you wish to convert the foregoing hexadecimal values into their decimal equivalents, the UDP port is simply 47808. The displayed hexadecimal IP address value converts to a dotted decimal IP address by converting two digits at a time to decimal. In this example, segment C0A85C64 into its quad address hex values: C0-A8-5C-64 — then these four hex pairs convert to 192.168.92.100.
Note that response 6 (for device 3044) passed through a different router that is identified by a MAC value of C0A85C65BAC0, and operating on network number 101. And also see that the final response (for device 3043) passed through yet another router identified by a MAC value of C0A85C66BAC0 and residing on network 102.
Finally, the last line in the sample screen indicates that once you have finished examining its display you can end the application by pressing any key. When you terminate the application, its window closes automatically.
You can download this handy, free application by pointing your browser to:
http://www.ccontrols.com/exe/bdt.exe
