Redundancy in Layer 2 Switched Networks

Redundancy in a network, such as that shown in Figure 2-3, is desirable so that communication can still take place if a link or device fails. For example, if switch X in this figure stopped functioning, devices A and B could still communicate through switch Y. However, in a switched network, redundancy can cause problems.

Figure 2-3. Redundancy in a Switched Network Can Cause

Problems

Figure 2-3. Redundancy in a Switched Network Can Cause

Problems

The first type of problem occurs if a broadcast frame is sent on the network. (Recall that a switch floods broadcast frames to all ports other than the one that it came in on.) For example, consider what happens when device A in Figure 2-3 sends an ARP request to find the MAC address of device B. The ARP request is sent as a broadcast. Both switch X and switch Y receive the broadcast; for now, consider just the one received by switch X, on its port 1. Switch X floods the broadcast to all its other connected ports; in this case, it floods it to port 2. Device B can see the broadcast, but so can switch Y, on its port 2; switch Y floods the broadcast to its port 1. This broadcast is received by switch X on its port 1; switch X floods it to its port 2, and so forth. The broadcast continues to loop around the network, consuming bandwidth and processing power. This situation is called a broadcast storm.

The second problem that can occur in redundant topologies is that devices can receive multiple copies of the same frame. For example, assume that neither of the switches in Figure 2-3 has learned where device B is located. When device A sends data destined for device B, switch X and switch Y both flood the data to the lower LAN, and device B receives two copies of the same frame. This might be a problem for device B, depending on what it is and how it is programmed to handle such a situation.

The third difficulty that can occur in a redundant situation is within the switch itselfthe MAC address table can change rapidly and contain wrong information. Again referring to Figure 2-3, consider what happens when neither switch has learned where device A or B are located, and device A sends data to device B. Each switch learns that device A is on its port 1, and each records this in its MAC address table. Because the switches don't yet know where device B is, they flood the frame, in this case on their port 2. Each switch then receives the frame, from the other switch, on its port 2. This frame has device A's MAC address in the source address field; therefore, both switches now learn that device A is on their port 2. The MAC address table is therefore overwritten. Not only does the MAC address table have incorrect information (device A is actually connected to port 1, not port 2, of both switches), but because the table changes rapidly, it might be considered to be unstable.

To overcome these problems, you need a way to logically disable part of the redundant network for regular traffic while still maintaining the redundancy for the case when an error occurs. The Spanning Tree Protocol does just that.

Was this article helpful?

0 0

Post a comment