Any look at network switching concepts will ultimately lead to a discussion about network bridging, and vice versa. At the end of the day, the roles played by a bridge and a switch are more or less identical – they help to break a network up into a number of smaller collision domains. Recall from earlier in the series that a collision domain is simply a group of computers amongst which data collisions can occur. For example, when connecting systems using a hub, all systems are considered to be part of the same collision domain, since the hub will simply forward data out all ports, with no regard for where the actual destination host is located.
The difference between a bridge and a switch is not very difficult to comprehend. Bridges came on the network scene first, providing a way to break up a single large collision domain into a number of smaller collision domains. The bridging “logic” was usually implemented in software. In contrast, switches are basically an evolution of bridges – they implement their logic in hardware, and typically have a much higher port density than a bridge does. While you may still come across bridges on a network today, they are not nearly as common as they once were, given that switches tend to be much faster and have dropped significantly in price over the last 5 years. For all intents and purposes, beyond the differences that I just mentioned, you can use the words “bridge” and “switch” interchangeably. The concepts relating to their communication processes are basically identical.
Take a look at the diagram below. In it, all computers are connected to a hub, and as such, are part of the same collision domain. Collisions are obviously a bad thing, since when they occur, systems much resend their data, which leads to less-than-optimal throughput. Because of the shared nature of Ethernet networks, when systems are plugged into a hub, they can only communicate in half-duplex. As such, only one system can be transmitting or receiving data at any given point in time.
In the past, in order to make better use of the network and reduce the number of collisions, companies would implement a network bridge. The purpose of the bridge was to segment the network in a number of smaller collision domains, as shown below. The bridge doesn’t have any magical qualities. Its job was simply to help ensure that the “scope” of collisions was made smaller. In the diagram shown below, data from Computer1 and Computer2 is still capable of colliding. However, data sent from Computer1 will never directly collide with data from Conputer3, since the two are in different collision domains. All computers in the diagram below are still in the same broadcast domain, as we’ll discuss shortly.
The reason for the reduction is collisions when a bridge is implemented in due to the intelligent nature of a bridge. Unlike a hub, a bridge is capable of making decisions on whether or not to forward a frame based on its destination MAC address. Because it makes decisions based on MAC addressing, a bridge is known as a Data Link layer or Layer 2 device.
Consider the diagram below, in which the bridge breaks the network up into 3 collision domains. The job of the bridge is to learn about which systems are connected on each collision domain, and then store this information in its bridging table. The learning process occurs as the bridge encounters traffic, and uses the source MAC address of frames to determine from which interface a given system can be reached. In this case, as network traffic occurs, the bridge will learn that Computers 1 and 2 are accessible via interface A, Computers 3 and 4 via interface B, and Computers 5 and 6 via interface C. As of this information is gathered by the bridge inspecting the source addresses of the frames that it comes into contact with.
In this case, the bridging table would look something like the table shown below, with the exception that the table would contain MAC addresses instead of the Computer names.
How this information is used is the key. When Computer 1 attempts to communicate with Computer 2, the bridge (via interface A) will also see these frames. The bridge’s job is to decide whether frames that it encounters should be forwarded or not. In this case, it will look at the destination MAC address in the frame. Seeing that the destination MAC address is listed as being part of the collision domain connected to interface A, it will not forward the frame. Two things have now happened – the bridge has made an intelligent decision, and that decision has helped to reduce the amount of traffic that needs to be passed to the collision domains connected to interfaces B and C. Since Computers 1 and 2 are in the same collision domain, there is no good reason to burden other collision domains with this unnecessary traffic.
However, let’s say that Computer 1 now wants to communicate with Computer 3, who is in a different collision domain. In this case, when the bridge encounters the frame, it will look up the destination MAC address in its forwarding table. In doing this, it will discover that Computer 3 can be reached from interface B. The bridge will forward this frame out interface B only, thus allowing it to reach Computer 3. In this case, the bridge helped to ensure that traffic was not also forwarded to the collision domain connected to interface C, again helping to reduce network traffic.
It should already be starting to become apparent as to how a bridge makes a network more efficient by acting as a type of traffic filtering device. However, there are a couple of things that you must keep in mind. The first is the impact of broadcast traffic. On an Ethernet network, the destination address of a frame may be FF-FF-FF-FF-FF-FF, otherwise known as the broadcast address. In other words, this frame is meant to be seen by all hosts. As such, a bridge will always forward broadcast traffic to all connected interfaces. The reason? A bridge breaks up a network into smaller collision domains, but all computers are still part of the same broadcast domain. Just remember that a bridge will always forward broadcasts out all of its interfaces except for the one on which the broadcast originated (since it has obviously already been seen by hosts in that collision domain).
Besides broadcast traffic, a bridge will always forward all frames destined for unknown (to the bridge) MAC addresses. For example, imagine if Computer 7 was just turned on in the collision domain connected to bridge interface C. The bridge doesn’t yet know it, since it may not have transmitted any traffic. In this case, let’s assume that Computer 1 is attempting to communicate with Computer 7. When the bridge encounters the frame on interface A, it will check it’s bridging table and see that it doesn’t yet have an entry for the destination MAC address. As such, it will forward the frame out each of its interfaces, which the exception of the one on which the frame arrived. Ultimately Computer 7 will respond, giving the bridge a chance to add it to its bridging table, and helping to ensure that subsequent frames are not needlessly forwarded to each interface. Remember that a bridge will always forward all frames with “unknown” destination MAC addresses to all connected interfaces, besides the one the transmission originated on.
In the example that we just looked at, our bridge has 3 interfaces, thus connecting three collision domains. One limitation of a bridge is that they typically supported no more than 16 interfaces, and the bridging logic was implemented in software. In contrast, a switch implements its switching logic in hardware (via Application Specific Integrated Circuits, or ASICs), and is typically capable of supporting much higher port densities.
When you think of a switch, simply consider it to be a faster bridge with more ports. Each and every port on a switch represents a collision domain. For example, a 10-port switch provides 10 collision domains.
Like a bridge, a switch also has a bridging/forwarding (or MAC address) table. In this case, each port has only a single computer connected. As such, each collision domain is made up of only one system – without multiple systems in a collision domain, collisions cannot occur. This is part of the reason why companies have migrated to switches from hubs – the lack of collisions allows full access to bandwidth, as well as the ability for connected systems to communicate in full-duplex.
However, it is also possible to plug a hub into a switch. Consider the example below, where a hub is plugged into port 3 on the switch. The 4 computers plugged into the hub can only communicate in half duplex, and are all part of the same collision domain. Once the bridging table on the switch has been updated, the MAC addresses of all 4 computers will be shown as being accessible via port 3. If you’ve ever wondered why the MAC address tables in many switches are rated to support up to 1000 or more MAC addresses, this is the reason – it is possible that many levels of hubs ultimately terminate on the same switch port.
The operation of the switch is almost identical to that of a bridge. The MAC address table of a switch is built by inspecting the source MAC address of frames. Forwarding decisions are made using the destination address of frames. When the switch receives a frame, it looks at the destination MAC address and then forwards it out only the port associated with that MAC address. Like a bridge, a switch will always forward all broadcast and frames with unknown destinations to every port, with the exception of the port on which the transmission originated.
It is exceptionally important to recognize the impact of a switch in the network communication process. When only a single system is connected to each and every switch port, not only is each collision domain made up of only one system, but full-duplex communication also becomes possible. In other words, if three systems were connected at 10 Mbps, and a server was connected at 100 Mbps, all three clients could both send and receive a full 10 Mbps of traffic to the server simultaneously. This is a huge step up from a hub, where the basic bandwidth (say 10 Mbps) would be shared amongst all four system, half-duplex, with collisions probably a very regular occurrence. Because of this, many people consider a switch to be a magic box, and in a way it is – I can’t think of a single way to squeeze dramatically better performance out of a network than by replacing all hubs with switches.
*Originally published at 2000Trainers.com
Dan DiNicolo is a technical trainer, consultant, author, and the managing editor of the free IT learning web site 2000Trainers.com. When he’s not busy traveling the world as an IT volunteer with organizations like Geekcorps, Dan makes his home in the snowy northern backwoods of Canada.
