Ethernet – Back In The Day

Here, there and Ethernet everywhere

I am in the midst of re-building Astro Communications’ main web site. While writing the content for the network switch page I got a bit carried away. It was a bit too long and nostalgic for Astro’s web page but never one to waste anything, here I am. Oh and by the way, when I say Ethernet I am referring to IEEE 802.3 also.

“…if ever there was a technology arrive just in time Ethernet switches would be a contender for my first prize.”

At the heart of every corporate network is the network switch. The majority of network switches available on the market can be taken out of the box, plugged in and you can be up and running in a few minutes. Even the most sophisticated switches may have an element of plug and play. It is easy to add network switches to create a larger network either within one cabinet or throughout your building and even across your campus. With Ethernet WAN services being readily available you could have switches across your entire estate.

But how do you know whether or not your equipment is configured in the optimum way for your organisation? How do you know your network is operating trouble free and you are not heading for a costly period of down time? If you do suffer down time, how long will it take you to trawl back through every network switch added to your network over the last few years in an attempt to locate the problem? Network switches can be easy to install, but when they go wrong they can really make you suffer, resulting in significant, unplanned cost.

I have been designing switched networks since the very first network switch appeared on the market. That is going back to when the alternative to a switch was a bridge, and multi-port bridges were very expensive. Multi port bridges did a great job segregating collision domains but they were inefficient and could slow a network down considerably. I worked on a number of the really early switches to come onto the market and if ever there was a technology arrive just in time Ethernet switches would be a contender for my first prize. Can you imagine getting excited at becoming the proud owner of a seven port Ethernet switch? No, right now I can’t either. But, I did back then.

“I remember a conversation with one of the switch development engineers at the time and he said Ethernet switching was discovered by accident.”

The first switch I worked on was manufactured by Kalpana, which I believe was the first ever Ethernet switch. I remember a conversation with one of the switch development engineers at the time and he said Ethernet switching was discovered by accident. The story goes that the engineers were tasked with developing a highly secure hub. Hubs simply repeated everything coming in on one port out to all of the other ports regardless of where the destination device was, this was regarded as a security flaw. To counter this, the engineers came up with a device that automatically read and stored source addresses as data was received from the attached devices.

The source (Ethernet MAC) addresses were recorded in a database with a record of the port the data arrived on. Now when the secure hub receives data on one of its ports it can check the destination Ethernet address in the database and send the data to the specific port. Now we have a secure hub, and with the addition of some fast electronics the Ethernet switch is born! The story certainly sounds feasible.

“…the performance of the network could suffer to the point where PCs would give up and reboot – not a very happy state!”

Ethernet prior to the birth of the network switch suffered with severe design restrictions. Ethernet employs the CSMA/CD protocol – Carrier Sense Multiple Access with Collision Detect. Early Ethernet was a bus topology with many devices connected along a length of coaxial cable. So, a device with data to send must first listen to the cable to see if anyone else was sending. If the cable was free, the device sends but has to listen while sending to monitor its own transmission. The device has to listen while sending because a device at the other end of the shared cable could also start to send at the same time so they both have to listen to detect a collision, which is when two streams of data ‘collide’ on the cable. If a collision occurs both sending devices must back off and wait for a random amount of time before they can try to send again.

A single Ethernet network is referred to as a collision domain and in some organisations these were so large the performance of the network could suffer to the point where PCs would give up and reboot – not a very happy state! Ethernet would work very nicely up to a loading of around 30-40%, at 50% performance would start to degrade. Some of the large networks I was engaged to troubleshoot were running at 80% and that is when I witnessed PCs rebooting. Some of the traffic congestion problems were due to sheer weight of traffic and on other occasions it was due to fault conditions causing broadcast storms (still a problem today).

“…their switches were blisteringly fast (but still only 10Mbps, albeit Full Duplex)”

Talking of sheer weight of traffic, I hear that on the radio about my favourite road the M25 everyday. I learned a lot about network traffic management sitting on the M25 for hours on end that I was able to put to good use with my Ethernet networks. Bearing in mind that prior to this the majority of systems were proprietary dedicated cabling. There were some bus based systems but many of them had a polled deterministic access method as opposed to carrier sense multiple access with collision detect method.

Just a few years later I worked with an Israeli switch manufacturer called Ornet, their switches were blisteringly fast (but still only 10Mbps, albeit Full Duplex) as they used ‘cut through’ technology as opposed to store and forward. Store and forward switches had to receive the entire frame on the receive port before forwarding it out to the destination port whereas cut through only had to receive the header before sending the frame to the destination port. Both technologies had their advantages, and disadvantages. Cut through switches were faster but they relied on the underlying network being relatively error and trouble free as errors occurring after the header would be propagated. Store and forward switches had the benefit of being able to check the entire frame and then deciding whether to forward or discard. I used both technologies to great effect, and over the years I worked with more switch manufacturers than I can remember – many of them long gone.

“…unless you get the problems resolved quickly the costs will mount!”

Network problems have not gone away. Modern enterprise grade switches are feature rich, features that are designed to benefit your organisation, whether that is to improve network performance, traffic visability, reporting or security. I have been engaged by large and small organisations to troubleshoot their networks to overcome serious business threatening problems on many occasions. The problems I’ve investigated are varied but they generally all result in one thing… cost! And, unless you get the problems resolved quickly the costs will mount!

A common cause of switch related problems is widespread use of the default configuration – or almost default barring the addition of an IP address. Many of the problems I’ve investigated and resolved have been so unnecessary, and on some occasions I’ve fixed the problem in minutes (and on some occasions to my sales team’s dismay I’ve not charged because I felt the pain and anguish of the customer and didn’t want to add to it). So let’s take a look at one of my old favourites – auto detect – as an example.

“Badly installed and configured network switches can cause persistent or intermittent performance issues and may render your network users vulnerable to MalWare and virus attacks.”

There has been plenty of controversy over speed and duplex auto detect as it is one of the most basic network configuration parameters. When it first appeared on the market it was very unreliable. The auto detect protocol only had one shot at getting it right when the device or switch is powered up or the network cable is connected. If either device failed to detect the correct settings on first pass there was no second chance. At one stage I was seeing a 50% failure rate on auto detect managing to achieve the same configuration at each end of the link. At best a failure would lead to extremely poor performance and at worst I have seen an entire network brought to a standstill. So is it right to leave auto detect enabled or should you manually set speed and duplex.

My honest answer is I don’t know and this is where the problem begins. I trained as an engineer to assess risk and make design and configuration decisions based on the specific requirements of my customer. In recent years auto detect has become a reliable option and for some interfaces the only option as recommended by the manufacturer. I have experienced problems due to devices being unable to match their configurations and the only way to overcome this is to manually set the speed and duplex. I have also experienced problems on systems where the speed and duplex has been manually set against manufacturer’s advice resulting in performance degradation.

Badly installed and configured network switches can cause persistent or intermittent performance issues and may render your network users vulnerable to MalWare and virus attacks. There is no need for this. I strongly recommend against using any switch in default configuration and as far as auto detect speed and duplex is concerned, the best I can advise is to be diligent. Your network switches are almost certainly supporting the flow of the lifeblood of your organisation. For your own peace of mind the more you know about your network the better. Understand the problems that can arise and wherever possible design around them. I cannot emphasise enough the need to have as much of your network configuration in your control as possible. Wherever possible install your switches with the optimum configuration for your organisation from day one rather than just live in hope that the default plug and play configuration will stand the test of time.