Interesting passages to differentiate routing and bridging.
There has been a lot of confusion over which is better, routing or bridging. The reasons that most people went to routing was to build more scalable networks that at the time couldn’t be handled simply by bridging. When routing became the “thing to do,” a lot of the vendors who made only bridges had a big problem on their hands because they didn’t have routers to sell in the new “router-centric” marketplace. Their answer was to invent a new technology called a switch. By reinforcing the advantages of switching over routing, they convinced the industry that routing was slow, complicated, and unnecessary. After all, why route when you can switch? Switching was nothing other than a new term for bridging. The only difference was that switching was done in hardware instead of software. Switches also had a newer method of forwarding called cut-through, which would forward packets immediately after receiving the first 6 bytes of the destination MAC address. When the industry was done buying into the switching trend, something interesting happened; their networks suddenly became more complicated. No longer could they determine the location of a node simply by looking at the IP address and associating it with a subnet. Now, a node’s MAC address could be found anywhere on the network. Many people unaware of broadcast problems on small networks suddenly became aware of them as they started affecting the entire network. What was the industry’s answer to this? Simple, move back to routing. Except that this time they didn’t call it routing; they called it Layer 3 switching. What did everyone do? Of course, they followed the industry trend and moved to Layer 3 switching, completely unaware that they were using the same routing technology that had existed years ago.
Regardless of the marketing terms, the processes of packet forwarding have gone largely unchanged. Whether people call a product a switch, bridge, or router, it still has to handle the same layers of the OSI model that were around before the product.
Copied from page 79 of <TCP/IP Analysis and Troubleshooting Toolkit>