Kazio Networks » Network Design & Analysis

EtherChannel is a technology used for port trunking (or “link aggregation” as Cisco calls it). It is used mostly in Cisco switches. The technology allows physical Ethernet ports to be grouped, forming one logical port/ connection. With that, only one connection is seen with the same MAC and IP address being shared, regardless of application(s) or user(s).

This is useful as a failsafe measure in the event that a link or several links are down makes it great for mission-critical applications — the technology redistributes traffic across the remaining active links with total transparency and speed. Distribution of loads across ports is based on Cisco’s proprietary algorithm which is calculated on the source/ destination IP, MAC and TCP/UDP port numbers.

EtherChannel is normally used within a network backbone rather than direct connections with end user devices/ machines. Connecting up end user devices would require the NIC / adapter of that particular device to be EtherChannel compatible. As of today, I don’t believe there is any PLC or embedded end user manufacturing/ control system device supporting EtherChannel, but that may change if the demand arises.

The maximum active number of ports that you can use with EtherChannel is eight (min. is two), regardless of the type of cable or whether it is Fast Ethernet, Gigabit Ethernet or 10 Gigabit Ethernet; with another one to eight ports acting as failover ports. The bandwidth is directly proportional to the ports and speed you use e.g. 5 ports running EtherChannel would give you 500 Mbit/s, 5 Gbit/s or 5 Gbit/s at Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet speeds respectively. This makes it very scalable as your traffic grows — a huge benefit.

When using EtherChannel, three things must apply:

1) All ports must be set to the same speed throughout

2) All links must comply with the IEEE 802.3 standard

3) All connected devices must support EtherChannel as well

One may argue the fact of why you would want to use EtherChannel when STP (Spanning Tree Protocol) is available. The answer would be that STP essentially limits the multiuse of links between switches and sends packets down one path at a time i.e. STP shuts down the extra redundant links. The use of EtherChannel allows the use of all available links between two devices at all times. You can use STP with EtherChannel to have a loop free topology and to prevent flooding of a network.

With all the good things being said, there is a drawback … EtherChannel is only limited to devices that support the proprietary technology. Therefore, you are bound by certain device manufacturers (mainly Cisco and Intel*). IEEE does have a similar open standard equivalent called IEEE 802.3AX (formerly IEEE 802.3ad).

*Intel has the capability to implement either the EtherChannel or IEEE 802AX within their Intel® PRO/100, PRO/1000, PRO/10GbE, Gigabit, and 10 Gigabit server adapters.

To Tap Or To SPAN?

Melvin Foo — Tue, 03 Feb 2009 16:21:33 +0000

Do you use a network tap or SPAN (Switched Port Analyzer)/ RSPAN (Remote Switched Port Analyzer) when doing network troubleshooting?

This discussion has come up quite often in the field. Here are my thoughts …

External taps allow a more accurate timestamp with zero packet delay and the physical errors are actually captured; whereas switches may drop the ethernet frames that have CRC errors. This defeats the purpose of trying to monitor, troubleshoot or analyze traffic. I WOULD want to see errors to determine what the problem is instead of it being discarded.

The packets that taps see are WYSIWYG i.e. there isn’t any outside influence on the traffic from the switch or any other source — what you see on your traffic analyzer is unfiltered, *real* and accurate. I can’t say this of mirrored traffic on SPAN ports as 1) the traffic seen is only as good as how the switch is configured and 2) only as good as how the switch functionality/ fabric performs.

So consider this:
- Taps are *dumb* and passive, they do not have the capability of adding traffic within the monitored ports or vice versa
- Taps don’t alter the frame of the packet nor does it introduce jitter or distortion
- Taps do NOT filter packets regardless of error type, IP version, size, and bandwidth

SPAN (or Port Snooping) may impact network performance as there is packet forwarding and duplication to the port that you are using to monitor/analyze. Then there is Cisco who has multiple spanning types (depending on what switch model you use) which may impact the way the Ethernet packets are transported differently.

RSPAN has a downside with its packet timing; the timestamp may not be true or indicative of when it actually reaches the remote port i.e. the timing of the packet may be skewed. Since RSPAN copies packets and distributes it to the remote ports, high volume scenarios may impact network traffic within the switch and propagate to its interconnections. What that means, is that you may have multiple problems added to your network in addition to what you already have. That is one reason why I would stay away from using RSPAN within an industrial control system network.

Taps aren’t totally golden, they do come with some drawbacks. The main drawback is that the network may need to be disrupted for a short period of time so that one can be installed. That may not be an option in certain networks that have to keep running. Putting taps on the network introduces another point of failure as well. Thirdly, taps may incur extra costs within the network system.

So where does that leave you in the decision of which one to use?

It’s a trade-off, the short disruption when installing a tap is manageable (and controlled). SPAN may potentially cause lengthy, uncontrolled disruptions. Uncontrolled disruptions with SPAN may be catastrophic as it is unexpected; short disruptions with tap installations are expected and everyone is prepared for it. Catastrophic occurrences within industrial networks may cost a manufacturing plant thousands of dollars. A worse scenario would be a bit not latching (within a control system), causing a Safety PLC to function incorrectly (or not function at all).

Before deciding which method to use, it would be wise to access the situation within an industrial network first. It goes without saying that monitoring/ troubleshooting of network traffic should always be done by a person that is comfortable performing the related pre setup tasks. You have to make sure that proper thought has been put into using the right analysis method as the switch mechanisms may cause more problems to the network than what you started out with.

My preference is to use external taps for analyzing/ monitoring networks. It is just more indicative of how the network performs at the given time/ instance. It is passive like and there isn’t the worry of it disrupting the network (after the initial installation) as compared with the SPAN alternative. A good industrial network design/ installation would most often have taps at strategic points of the network for instant access to network traffic. Datacom and Net Optics are examples of manufacturers who make network taps.

Of course, the debate of using the network tap vs. SPAN has been long argued by vendors championing its cause. From an industrial automation point of view, the decision of which method to use in troubleshooting may ultimately come down to who is going to have the least impact and risk on the network.

A typical tap setup within a network:

(Graphic source: Net Optics)

Here are some good articles on the web about Taps, SPAN and RSPAN:

SPAN port of Tap? (Tim O’Neill)
RSPAN … Friend or Foe? (Tim O’Neill)
Tap vs. SPAN Ports (Net Optics)
Network Taps vs. SPAN Ports (Datacom)