Hubs, Bridges, and Multilayer Switches

Because this is not an introductory text, I do not discuss the operation theory of bridges, switches, and hubs. I just want to mention that I am using hubs in my lab setup for the ease of packet sniffing without the need to configure analyzer ports on a switch, which are easily overwhelmed with the traffic of an entire VLAN. This feature is called Switch Port Analyzer (SPAN) on Cisco switches. Besides, I do not own enough switches to build an interesting spanning-tree lab. Therefore, you will find just two limited spanning-tree labs at the end of this chapter so that you can look at the bridge protocol data units (BPDUs) going back and forth between a Linux bridge and a Cisco switch for demonstration purposes.

Of course, I once again warn you about the limited or missing loop-detection mechanisms of some UNIX bridge modes. Take the appropriate topological steps to avoid loops and do not emulate switch functionality with UNIX gateways. Linux, NetBSD, and OpenBSD implement the IEEE 802.1D STP (Spanning-Tree Protocol), which is in charge of loop prevention in switched/bridged topologies in only a crude and limited way.

Instabilities in STP behavior represent the single most severe threat to switched LAN environments with multiple switches and bridges because of the timers involved and the high-performance characteristic of modern switch fabrics. When STP fails, frames might not just circle infinitely; they might multiply (to make the matter even worse). Nevertheless, UNIX bridging modes have their merits in terms of trunk filtering, traffic shaping, and transparent firewalls. Just remember that they are not intended to emulate or replace dedicated switches.