How did we ever get into this switching mess?

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

19 comments:

  1. Hi Ivan,

    I agree that forwarding packets based on l3 should be called routing. Why whould that change just because the hardware changes, it doesn't matter if an ASIC or a CPU is doing the forwarding, it's still routing. The term layer 3 switcing is probably invented to show that there is a difference between a conventional router and a switch doing routing and that switching the packets must be much faster than routing them! On this note I found it interesting when I was doing a lab on frame-relay (preparing for CCIE) and the debug command is called debug frame-relay packet, since when is frame-relay a packet technology? :)

    ReplyDelete
  2. Ivan, speaking as someone who was working as a Network Engineer during all those sorry events you describe, I can confirm that it was the Marketing people who got us in this mess (the same marketing people who describe FastEthernet as 200Mbps throughput, factually correct but totally misleading). I can distinctly remember sitting in Cisco presentations being told of the wonders 'Layer3 Switching' and feeling deeply troubled. I had urges to stand up and tell them... 'this is routing, not switching'.... I looked around to see if anyone else felt the same, but everyone else was sat there, open mouthed, slightly dribbling, mumbling like Homer Simpson...."I want a layer3 switch".... There job was done, more confusion followed and Cisco's share price jumped again.
    l

    ReplyDelete
  3. Check out Radia Perlman's google talk where she discusses the LAT thing! http://www.youtube.com/watch?v=N-25NoCOnP4&

    It's Radia's network. We just put packets on it.

    ReplyDelete
  4. Switching is an old term dating back way before layer 3 networks and OSI IP stacks were born. Remember the days of Frames and x.25 when transistors literally switched in a regular interval, whether or not data packets were queued or not. It's an old TDM term, likely ~80 years old- and is why it's most prevalent on legacy voice environments and since been applied to virtualized software based switching technologies.

    ReplyDelete
  5. Please pardon the tangent. A lot of IT people fall into the profession, and much of our knowledge is built on direct exposure, either through scraping our knuckles on our networks, researching technologies / problems and studying for certifications. One thing that is missing is the historical knowledge of the people that preceded us. As I was reading this article, it occurred to me that our industry has been around long enough that the problems and their solution methods are becoming cyclical, everything old is new again. I very much enjoy learning how the problems I run into now, have been solved (for better and for worse) in the past and having a historical understanding of what works and what doesn't (and why). It is akin to other fields where they teach a historical component so each generation doesn't reinvent the wheel. Are there texts or other sources to gain a solid understanding of networking's past successes and failures?

    ReplyDelete
  6. Similar marketing idiots have invented "Routing at layer 2" (FabricPath)

    ReplyDelete
  7. This is a fantastic question with no good answer. I'm not aware of any book that I could recommend. There are classic texts (like Jeff Doyle's Routing TCP/IP), but not much on the history of internetworking.

    ReplyDelete
  8. Charles,

    I would highly recommend "Patterns in Network Architectures" by John Day. His views might be arguable, but he provides very interesting historical review.

    ReplyDelete
  9. Often I see people struggling to define the difference between the processes of routing and bridging. The key to me is that routing is the process of finding a path between two nodes in a graph. Here graph is a collection of nodes and links and path is ordered sequence of nodes to be traversed to reach the destination. Bridging, on contrast, is simply stitching or joining two links in one, i.e. changing connectivity property in the graph. This is why it is so hard to compare the two processes directly - they apply to different entities.

    Of course, for the purpose of advanced bridging, a link could be viewed as having complex structure, which, in turn, implements path determination and routing on its own. But I believe that understanding how this two processes apply to different entities is helpful.

    ReplyDelete
  10. Cmon ... go to acm or ieee ... they have histories on all this stuff ....these have existed before there was any of these tabloidesque blogs .

    ReplyDelete
  11. This is a great post, and there are some very relevant and insightful comments following it.

    I'm a fairly young engineer and really got my teeth sinking into the technologies around 1996-1997. I cut my teeth on a small Novell network and slowly went on from there. As already mentioned, seeing the history of how things came about (and more importantly, the taint of marketing) really helps to put terminology and sometimes even the technology in perspective. I remember when I just started struggling to understand the differences between some protocols (such as ISL vs 802.1q) only much later to find out the history. Of course, it puts everything into perspective.

    Another thought that came to mind is the understanding (or lack thereof) of some even senior people of the technology. We're talking true "understanding". Sometimes getting a few of my peers to really understand the difference between layer 2 and layer 3 is difficult. Then there is the guy that refers to any "switch" as a "hub"; those are the times when you just have to learn to interpret someone's language. :)

    Great post!

    ReplyDelete
  12. This is a great post, and there are some very relevant and insightful comments following it.

    I'm a fairly young engineer and really got my teeth sinking into the technologies around 1996-1997. I cut my teeth on a small Novell network and slowly went on from there. As already mentioned, seeing the history of how things came about (and more importantly, the taint of marketing) really helps to put terminology and sometimes even the technology in perspective. I remember when I just started struggling to understand the differences between some protocols (such as ISL vs 802.1q) only much later to find out the history. Of course, it puts everything into perspective.

    Another thought that came to mind is the understanding (or lack thereof) of some even senior people of the technology. We're talking true "understanding". Sometimes getting a few of my peers to really understand the difference between layer 2 and layer 3 is difficult. Then there is the guy that refers to any "switch" as a "hub"; those are the times when you just have to learn to interpret someone's language. :)

    Great post!

    ReplyDelete
  13. This is a great post, and there are some very relevant and insightful comments following it.

    I'm a fairly young engineer and really got my teeth sinking into the technologies around 1996-1997. I cut my teeth on a small Novell network and slowly went on from there. As already mentioned, seeing the history of how things came about (and more importantly, the taint of marketing) really helps to put terminology and sometimes even the technology in perspective. I remember when I just started struggling to understand the differences between some protocols (such as ISL vs 802.1q) only much later to find out the history. Of course, it puts everything into perspective.

    Another thought that came to mind is the understanding (or lack thereof) of some even senior people of the technology. We're talking true "understanding". Sometimes getting a few of my peers to really understand the difference between layer 2 and layer 3 is difficult. Then there is the guy that refers to any "switch" as a "hub"; those are the times when you just have to learn to interpret someone's language. :)

    Great post!

    ReplyDelete
  14. ACM has histories of published articles. How many of them are relevant? How many of them were purely academic exercises? Written to get a paper published? How many actual events happened (or decisions got made) without being glorified in an ACM paper?

    You could use ACM or IEEE archives to as one of the sources of your research. I hope someone will once take the time to do that and write a good historical overview. What I've seen from John Day was unfortunately too biased.

    ReplyDelete
  15. Heh, is there any historical review that is NOT biased? :) John Day is definitely exaggerating some things and his obsession with "naming problem" may be annoying at times, but so far his work is the only attempt to analyze the fundamentals of protocol design. The book is definitely not easy, though interesting reading. Arguable, but that's what I like it for.

    ReplyDelete
  16. Ah ! but is layers 3 forwarding really the same as routing ? Each packet isn't inspected and does pass thru all the same verifications. There is a major difference. L3 forwarding is more like L2.5 , only the first packet is routed , until theres a change, then the rest are switched.


    The hardware configurations are totally different , and the uses of routers and L3 switches isnt the same.

    ReplyDelete
  17. I dont think you know what your talking about ... Wouldnt be the first time eh. Please do some research

    There is an IEEE journal title Annals of the History of Computing ... Theres loads of articles there about the birth of X25 and all the assorted public networks (cyclades) etc etc and the thoughts governing why they choose this and that ....
    Also IETF have several RFC's documenting the history of deployment of various protocols in live environments
    ACM and IEEE are not just repositories for abstracts ..

    Thats the problem with networking ..any old hack can step up and get involved ..... unlike say programming where you at least need to have the talent to deal with the abstract and appreciate the foundations of computing .... networking is just all arithmetic these days.

    ReplyDelete
  18. Thanks for the tip. Will definitely investigate, I would love to know the background of a few things that have always irritated me.

    As for "wouldn't be the first time" - you're right, I make mistakes (but I never claimed I'm omniscient ;) ), but then one of the best parts of my blogging experience is that I learn something new on a daily basis based on your comments.

    Last but definitely not least, while it would be interesting to compare networking and programming (where I have seen a fair share of programmers that fall way short of your definition of minimum needs), I will not enter into a pissing contest with an anonymous commenter.

    ReplyDelete
  19. "Thats the problem with networking ...any old hack can step up and get involved ... unlike say programming where you at least need to have the talent to deal with the abstract and appreciate the foundations of computing" - Quite funny. Spoken like a programmer. Unfortunately, the Internet is littered with the "talent" of hack programmers. I'm surprised anyone who can spell IEEE and IETF would overlook that.

    Having had many years in both the programming and networking realms, I think that there is little difference between the clueful folk in either discipline. Likewise at the shallow end of the pool.

    While you may not have intended to be brusque (giving you the benefit of the doubt) in your reply, you would do well to show a little courtesy to someone who spends a great of time trying to help educate people. Pointing out mistakes can be done without being insulting.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.