Network bridging takes place at layer 2 (the data link layer) of the OSI model. There are several different types of bridges. A simple bridge isn't much different from a repeater, except for the fact that the two network segments it connects may use different types of media (for example, one segment may use 100Base-T cabling and the other may use 1000Base-T) and the fact that bridges use a store-and-forward mechanism to forward packets, thus creating two separate collision domains.

A simple bridge forwards packets to the other side of the bridge, regardless of whether the destination host is on the other side. There are bridges known as transparent bridges, however, which are able to learn which side of the bridge hosts are on and use this information to decide whether or not to forward packets. Such bridges utilize a database which is initially empty. Packets are initially sent to both sides of the bridge regardless of the location of the target host. Gradually, however, a transparent bridge learns the location of hosts by observing which side of the bridge a host sends from, and as this information is entered into the database, the bridge will only forward packets to the other side of the bridge if the destination host is on the other side.

As an example of how a transparent bridge might work, imagine a bridge with three nodes: A, B, and C. Nodes A and B are on one side of the bridge, and C is on the other side. A begins a session with B. The bridge, not knowing initially that B is on the same side of the bridge as A, initially floods both sides of the bridge with B's packets.

When B replies, the bridge learns that B is on the same side of the bridge as A, and traffic will not be forwarded anymore. If B begins a session with C, the bridge will initially flood both sides with B's packets again, not knowing where C is. Once the bridge learns C's location, traffic between B and C will be sent across the bridge.

Bridges, though somewhat limited, are in the form of hubs and switches, still tremendously useful if we need to partition our networks. To demonstrate how this might work, let's revisit the example network from Chapter 3, VLANs. You might recall that we had separate DEVELOPERS and ENGINEERING departments, and we wanted to partition them into separate networks. In that chapter, we implemented separate developer and ENGINEERING networks as VLANs, as this option seemed to provide the greatest amount of flexibility, scalability and security. The following diagram shows how we might partition DEVELOPERS and ENGINEERING with stackable hubs or switches:

As you can see, the network has a multi-tier design. Instead of having DEVELOPERS and ENGINEERING on the same physical interface, but separate VLANs, in this setup, DEVELOPERS and ENGINEERING are on separate physical interfaces (fxp0 and fxp1, respectively). Each network gets its own backbone hub, and each floor gets its own hub (or switch), and thus each floor forms a separate network segment.

This configuration isn't quite as good as the VLAN configuration we used earlier, but it does have several advantages:

• It can be implemented with unmanaged switches instead of managed switches. Unmanaged switches are typically far less expensive.
• It provides communication with nodes in the same department on different floors. At the same time, by partitioning the network in this way, we ensure that traffic between two nodes on the same floor does not reach the backbone hub. Thus, it does not affect users on different floors, which would not be the case if each network shared a single switch.
• Providing each network with its own backbone hub extends the total maximum distance between a node and the router. On a 1000BASE-T network, the maximum distance between devices is 100 meters. Thus, if a network has a single switch, and the switch connects to the router, then a node can be, at most, 200 meters from the router (100 meters to the switch and 100 meters between the switch and router). Adding a backbone hub extends the total possible distance between a node and the router by another 100 meters. Thus, it's like adding a repeater to the network.
• Another advantage of every network having its own hub is that if a hub/switch fails other than one of the backbones, the backbone hub will detect the problem and disable the port on the backbone to which it is connected. Thus the malfunctioning switch will not affect the rest of the network, while nodes on the same floor will still be able to communicate with each other.
• This setup is somewhat scalable; to add another network segment to one of the networks, we could plug another switch into the backbone hub for  that network.
• This setup is relatively secure; DEVELOPERS and ENGINEERING are on separate networks and won't be able to communicate with each other unless we create firewall rules to allow it.

This setup still has its limitations. With VLANs, we could add another floor to our configuration simply by getting another managed switch and connecting it to one of the trunk ports on the previous floor's switch. In this setup, we can only add another floor if the total distance between the new switch and the backbone switch/hub is 100 meters or less. If not, we will have to add another backbone. Moreover, as you might recall, one of the advantages of VLANs is that we could make VLAN assignments based on MAC addresses, so we could move a node around, plug it into any available switch (as long as it's a managed switch), and the node will be assigned to the correct VLAN. With this setup, a node must be connected to a switch that is physically connected to the right interface for the network for the node to be assigned to the correct network. Still, it's a viable option if we don't anticipate much growth in our network and we don't have to move nodes around very often.

Our setup has a key weakness. The backbone hub for each network represents a single point of failure. For this reason, it is often desirable to introduce some redundancy into our network by adding backbones. The following diagram shows how this might work:

As you can see, we have added a redundant backbone hub to each network. This, however, creates a new problem. Assume that a node on DEVELOPERS1 wants to start a session with a node on DEVELOPERS2. The switch for DEVELOPERS1 generates two copies of each frame whose destination is the DEVELOPERS2 node: one goes to BACKBONE HUB #1 and the second to BACKBONE HUB #1B.

Then each of these hubs sends the frame to DEVELOPERS2. If there are only two segments on each network, it won't be too bad, but what if we add another segment (DEVELOPERS3)? The backbone hubs will not know whether the destination resides on DEVELOPERS2 or DEVELOPERS3, so each of them will send a copy to both switches, generating a total of four frames. The number of frames generated from the original frame thus can grow exponentially fast, crashing the network. Even if the backbones are intelligent devices that have the capability of learning where nodes reside (for example, a transparent bridge), initially they don't know anything, at least until the destination node replies, so this problem exists whether our backbone is a simple hub, a switch, or a bridge.

Since we want to introduce redundancy into our network, but we don't want our network to crash, we are in need of a solution, and the solution in this case is a spanning tree protocol. With a spanning tree protocol, bridges communicate with each other in order to determine a spanning tree, a subset of the original network topology with no loops. The spanning tree algorithm is run, and certain interfaces are disconnected to create the spanning tree. If at some point one of the network devices fail, the spanning tree algorithm can be run again to determine which interfaces need to be activated to create a new spanning tree.

Since implementing a spanning tree is something you are likely to do if you implement multiple bridges on your network, it might be instructive to describe how Spanning Tree Protocol (STP), the oldest spanning tree protocol for bridges, works.

We will use the following network to illustrate the process:

The diagram on the left represents the network before the spanning tree calculation. As you can see, we have a network with several bridges (represented by boxes) and several network segments (represented by clouds). The numbers in the boxes are the bridge IDs. Assume that each network segment has a cost metric of 1. A spanning tree is formed as follows:

1. First, a root bridge is chosen. The root bridge is the bridge with the lowest bridge ID. In our example network, it is bridge 1.
2. Second, each bridge determines the least-cost path to the root bridge. The cost of traversing a path is the sum of the cost metrics of each segment on the path. The port, which provides a path to the least-cost path to the root bridge for each bridge, is designated the root port (RP).

3. Next, the bridges determine the least-cost path from each network segment to the root bridge. The port connecting each segment to each path is designated as the designated port (DP) for that network segment.
4. Finally, each port that is neither a RP nor a DP becomes a blocked port, and thus is not part of the spanning tree.

The diagram on the right illustrates the spanning tree after RPs and DPs have been determined. The spanning tree is outlined in red. All ports not connected to a red segment are blocked. We arrive at the spanning tree as follows:

1. We designate bridge 1 as the root bridge. 
2. We determine the least-cost path from bridge 2 to bridge 1. The path that runs through segment A has a cost of 13; the path that runs through segment B has a cost of 22; the path that runs through segment D has a cost of 38. We add the segments connecting 2 and A and A and 1 to the spanning tree.
3. We determine the least-cost path from bridge 3 to bridge 1. The path that runs through segment B has a cost of 12; the path that runs through segment D has a cost of 44 (the cost of the segments we would have to add to the spanning tree, however, are what we are concerned with, and these add up to 31). We add the segments connecting 3 and B and B and 1 to the spanning tree. 
4. We determine the least-cost path from bridge 4 to bridge 1. Since there is only one active port on bridge 4, our choice is forced, so we add the segment connecting 4 and C to the spanning tree. The only other port on connecting C to the rest of the network is the one that connects C to 3, so we add the segment connecting C to 3 to the spanning tree.
5. The ports between 2 and A, 3 and B, and 4 and C are RPs. 
6. We determine the least-cost paths from each network segment to bridge 1. The least-cost path from A to 1, B to 1, and C to 1 are already part of the spanning tree. The ports connecting each network segment to bridge 1 are marked as designated ports. D is not in the spanning tree. The path that runs through bridge 2 has a cost of 19; the path that runs through bridge 3 has a cost of 37. We add the segment from D to 2 to the spanning tree and the port connecting D to 2 is marked as a DP. 
7.  All other ports are blocked. The spanning tree has been calculated.