STP (802.1D) Overview
A robust network
design not only includes efficient transfer of packets or frames, but also
considers how to recover quickly from faults in the network. In a Layer 3
environment, the routing protocols in use keep track of redundant paths to a
destination network so that a secondary path can be used quickly if the primary
path fails. Layer 3 routing allows many paths to a destination to remain up and
active, and allows load sharing across multiple paths.
In a Layer 2
environment (switching), however, no routing protocols are used, and active
redundant paths are neither allowed nor desirable. Instead, some form of switching
provides data transport between networks or switch ports. The Spanning Tree Protocol (STP) provides
network link redundancy so that a Layer 2 switched network can recover from
failures without intervention in a timely manner. The STP is defined in the IEEE
802.1D standard.
STP is discussed in relation to the problems it solves
in the sections that follow.
Preventing Loops
with Spanning Tree Protocol
Switching loops
form because parallel switches (or switchs) are unaware of each other. STP was
developed to overcome the possibility of switching loops so that redundant
switches and switch paths could be used for their benefits. Basically, the
protocol enables switches to become aware of each other so they can negotiate a
loop-free path through the network.
Switching Loops
A transparent
switch must offer segmentation between two networks while remaining transparent
to all the end devices connected to it. For the purpose of this discussion,
consider a two-port Ethernet switch and its similarities to a two-port
transparent switch.
A transparent
Ethernet switch must operate as follows:
■ The switch has no initial knowledge of any end device’s
location; therefore, the switch must “listen” to frames coming into each of its
ports to figure out on which network each device resides. The switch assumes
that a device using the source MAC address is located behind the port that the
frame arrives on. As the listening process continues, the switch builds a table
that correlates source MAC addresses with the switch port numbers where they
were detected.
■ The switch can constantly update its switching table on
detecting the presence of a new MAC address or on detecting a MAC address that
has changed location from one switch port to another. The switch then can
forward frames by looking at the destination MAC address, looking up that
address in the switch table, and sending the frame out the port where the
destination device is known to be located.
■ If a frame arrives with the broadcast address as the
destination address, the switch must forward, or flood, the frame out all
available ports. However, the frame is not forwarded out the port that
initially received the frame. In this way, broadcasts can reach all available
Layer 2 networks. A switch segments only collision domains; it does not segment
broadcast domains.
■ If a frame arrives with a destination address that is not
found in the switch table, the switch cannot determine which port to forward
the frame to for transmission. This type of frame is known as an unknown unicast. In this case,
the switch treats the frame as if it were a broadcast and floods it out all
remaining ports. When a reply to that frame is overheard, the switch can learn
the location of the unknown station and can add it to the switch table for
future use.
■ Frames forwarded across the switch cannot be modified by the
switch itself. Therefore, the switching process is effectively transparent.
Switching in this fashion
works well. Any frame forwarded, whether to a known or unknown destination, is
forwarded out the appropriate port or ports so that it is likely to be received
successfully at the intended destination. Figure
2.1 shows a simple two-port switch functioning as a switch, forwarding
frames between two end devices. However, this network design offers no
additional links or paths for redundancy if the switch or one of its links
fails. In that case, the networks on either side of the switch would become isolated
from each other.
Figure 2.1 Transparent Switching
To add some
redundancy, you can add a second switch between the two original network segments,
as shown in Figure 2.2. Now, two
switches offer the transparent switching function in parallel. In theory, a
single switch or a single link can fail without causing end-to-end connectivity
to fail.
Consider what
happens when PC 1 sends a frame to PC 4. For now, assume that both PC 1 and PC
4 are known to the switches and are in their address tables. PC 1 sends the frame
onto network Segment A. Switch A and switch B both receive the frame on their gi1/0/1
ports. Because PC 4 already is known to the switches, the frame is forwarded out
ports gi1/0/2 on each switch onto Segment B. The end result is that PC 4
receives two copies of the frame from PC 1. This is not ideal, but it is not
disastrous, either.
Figure 2.2 Redundancy with
Two Switches
Now, consider the
same process of sending a frame from PC 1 to PC 4. This time, however, neither
switch knows anything about the location of PC 1 or PC 4. PC 1 sends the frame
to PC 4 by placing it on Segment A. The sequence of events is as follows:
Step 1. Both Switch A and
Switch B receive the frame on their gi1/0/1 ports. Because the MAC address of
PC 1 has not yet been seen or recorded, each switch records PC 1’s MAC address
in its address table along with the receiving port number, gi1/0/1. From this
information, both switches infer that PC 1 must reside on Segment A.
Step 2. Because the
location of PC 4 is unknown, both switches correctly decide that they must
flood the frame out all available ports. This is an unknown unicast condition
and is their best effort to make sure that the frame eventually reaches its
destination.
Step 3. Each switch floods
or copies the frame to its gi1/0/2 port on Segment B. PC 4, located on Segment
B, receives the two frames destined for it. However, on Segment B, Switch A now
hears the new frame forwarded by Switch B, and Switch B hears the new frame
forwarded by Switch A.
Step 4. Switch A sees that
the “new” frame is from PC 1 to PC 4. From the address table, the switch
previously learned that PC 1 was on port gi1/0/1, or Segment A. However, the
source address of PC 1 has just been heard on port gi1/0/2, or Segment B. By
definition, the switch must relearn the location of PC 1 with the most recent
information, which it now incorrectly assumes to be Segment B. (Switch B
follows the same procedure, based on the “new” frame from Switch A.)
Step 5. At this point,
neither Switch A nor Switch B has learned the location of PC 4 because no
frames have been received with PC 4 as the source address. Therefore, the new
frame must be flooded out all available ports in an attempt to find PC 4. This
frame then is sent out Switch A’s gi1/0/1 port and on to Segment A, as well as
Switch B’s gi1/0/1 port and on to Segment A.
Step 6. Now both switches
relearn the location of PC 1 as Segment A and forward the “new” frames back
onto Segment B; then the entire process repeats.
This process of
forwarding a single frame around and around between two switches is known as a switching loop. Neither switch
is aware of the other, so each happily forwards the same frame back and forth
between its segments. Also note that because two switches are involved in the
loop, the original frame has been duplicated and now is sent around in two
counter-rotating loops. What stops the frame from being forwarded in this
fashion forever? Nothing! PC 4 begins receiving frames addressed to it as fast
as the switches can forward them.
Notice how the
learned location of PC 1 keeps changing as frames get looped. Even a simple
unicast frame has caused a switching loop to form, and each switch’s switch
table is repeatedly corrupted with incorrect data.
What would happen
if PC 1 sent a broadcast frame instead? The switching loops (remember that two
of them are produced by the two parallel switches) form exactly as before. The
broadcast frames continue to circulate forever. Now, however, every end-user
device located on both Segments A and B receives and processes every broadcast
frame. This type of broadcast storm can easily saturate the network segments
and bring every host on the segments to a halt.
The only way to
end the switching loop condition is to physically break the loop by
disconnecting
switch ports or
shutting down a switch. Obviously, it would be better to prevent switching
loops than to be faced with finding and breaking them after they form.
Next
Topic Preventing
Loops with Spanning Tree Protocol will publish soon
No comments:
Post a Comment