If you’re confused about the numerous meanings of a switch, you’re not the only one. If you wonder how the whole mess started, here’s the full story (from a biased perspective of a grumpy GONER):

35 years ago, there were no bridges or routers. Hosts communicated directly with each other or used intermediate nodes (usually hosts, sometimes dedicated devices called gateways) to pass traffic ... and then a few overly-bright engineers at DEC decided their application (LAT) will run directly on layer 2 to make it faster.

Their company has been dead (actually, sold in pieces) for over a decade, but their eagerness to cut corners still haunts every one of us.

When someone managed to sell too many devices to a single customer (probably ignoring every design recommendation ever made ... isn’t that how progress is made?), and they could no longer fit onto the same thick Ethernet segment, DEC built a transparent bridge (and Radia Perlman designed STP).

At the same time, the number of protocols running on Ethernet (and other now-extinct technologies, including ARCNET and LocalTalk) exploded (the early CCIEs might “fondly” remember all the protocols we had to configure in the lab). Each of these protocols needed its own gateway (= router) devices and Bill Yeager at Stanford got a brilliant idea: let’s make a dedicated device that will serve as a gateway to all of them ... and thus multiprotocol router (initially still called gateway; that how AGS got its name) and Cisco were born.

Routers were way more complex (and expensive) than bridges, so someone got the next bright idea: let’s use bridges to connect remote sites together. While that might be survivable (but still stupid) for a few small remote sites today, we used very slow WAN links in those days (64 kbps was a high-speed link) and the crazy and overly-brave engineers building large bridged networks produced numerous catastrophic failures. Based on those events, bridge became a much-hated word and everyone understood that routers are good, bridges are bad.

Fast-forward a few years. Thick and thin coax Ethernet were replaced by twisted pair attachments to a hub and several startup companies got another great idea: let’s replace a hub with a bridge; it will boost performance and decrease the number of collisions (and potentially transmission errors).

Of course they forgot to mention increased latency (or played with the cut-through switching), but let’s not go there.

These startups were facing a serious problem: what they had was a bridge, but nobody wanted to buy a bridge (because bridges are bad), so some fateful marketing department invented a switch. New mantra: hubs are slow, switches are fast.

Even in those early days, some people figured out not every host (or user) belong to the same LAN segment. They wanted to implement LAN segmentation and decided to do it with higher-speed routers (Cisco 7000 was a quite popular option). The design worked, but had a significant drawback: high-speed multi-protocol routers were always expensive. Changed mantra: routers are expensive, switches are more cost-effective.

Some newbies who firmly believed marketing claims made by various vendors decided (yet again) to build WAN networks with switches (because routers were expensive) ... and (predictably and inevitably) failed.

Because the routers were so expensive (and switches already had hardware-based forwarding), networking vendors tried to combine the best of both worlds. Some of you might still remember the early days of Netflow and Multi-Layer Switching (where the router would inspect initial packets in a session and download the flow specification to the switches ... the craziness now resurrected in OpenFlow).

Finally, someone managed to implement cost-effective layer-3 forwarding in hardware, resulting in high-speed reasonably-priced routers ... only you couldn’t call those devices routers anymore, because routers are expensive, so they stretched the definition of switching to include layer-3 switching (the process formerly known as routing).

Is there a way out of this switching mess? Judging by the comments made by readers of Terminology: Switch vs Router article (by @packetlife), we’re way past the point of no return.

But remember: regardless of how you decide to call the physical (or virtual) device that forwards the data across your network, it’s important to understand whether it forwards the data based on physical layer-2 addresses (we called that bridging) or based on logical, hierarchical layer-3 addresses (what we called routing 20 years ago), because there are significant differences between routing and bridging (maybe even more than you think).