VLAN Benefits

The main benefits of using VLANs are that they provide increased flexibility, scalability, and security.

Flexibility. Because a VLAN assigns a user to a broadcast domain based on the port their system is plugged into, additions, moves, and changes are made simple. If you wanted a user to be moved to a different broadcast domain, all you would have to do is reconfigure the port they’re connected to. For example, a user might have been working in Marketing and is now moving to Finance. Instead of moving their physical PC, simply modify the VLAN configuration of the port, changing it from the Marketing VLAN to the Finance VLAN. This flexibility allows you to create logical (rather than physical) groupings of users.

Scalability. VLANs aren’t limited to a single switch. In fact, you can actually have VLANs that span an enterprise organization. For example, you might have groups of users on the 4th, 18th, and 42nd floors all be part of the same VLAN, even though they’re connected to different switches. Taken a step further, VLANs can also be scaled beyond a single location, over a WAN link if necessary.

Security. VLANs provide a greater degree of security than a traditional LAN. Consider the situation where a user from Human Resources might be connected to the same physical segment as a variety of other users. If plugged into a hub, other users could capture the information passed to the HR computer using a protocol analyzer program. By configuring all HR user systems to be in their own VLAN, their traffic remains separate and distinct from other network users. Also, traffic between VLANs can then be more easily controlled using router features such as access lists.

In the above explanation, the groupings of users to VLANs were based on functional departments. This is a popular way to divide traffic on a network, especially if departments have their own servers. Human Resources tends to be particularly good example of a department that might require its own VLAN, based on the sensitive nature of the information they deal with. Separate VLANs are often defined for other purposes as well, including network management and monitoring.

Tip: Remember that when you define additional VLANs, you are actually creating a larger number of smaller broadcast domains.

Virtual LANs

While a switched network provides a number of great features including better performance, it also provides a greater degree of flexibility, scalability, and security. This is mainly accomplished through the use of Virtual Local Area Networks (VLANs).

Let’s get started on the right foot. VLANs are nowhere near as difficult to understand as some people make them out to be. Remember a traditional LAN? All computers are connected together in a segment referred to as a broadcast domain. Systems are usually very close together, and connect to devices such as hubs or switches.

At the most basic level, a VLAN is nothing more than a broadcast domain, meaning that it is a Layer 2 entity. What tends to throw people is that a VLAN is actually a broadcast domain configured on switches on a port-by-port basis. Say what? Well, imagine a switch that has 10 ports, like the one shown below. I could take the first 5 ports and make them part of one VLAN, and then take the next 5 and make them part of a different VLAN. What I’ve actually done is created two different broadcast domains. A broadcast made by a system on port 1 will only go to systems connected on those first 5 ports, and is not seen by those on the last six ports. In this way, I’ve used the switch to define two different broadcast domains.

Figure: Switch with 2 VLANs.

But how do systems on different VLANs communicate with each other? You actually already know the answer to that: the same way systems on two different broadcast domains communicate, that is, through a router. So, in order for systems on one VLAN to communicate with those on other, some type of routing device must be involved. This could be a router, a Layer 3 switch, or a route switch module (RSM).

Because different VLANs are actually different broadcast domains, you’ll need to be sure that you’re connecting hosts to the correct ports. For example, if you were to connect two systems that are supposed to be part of the same IP subnet to ports from different VLANs, they would not be able to communicate. That is, even though the IP addresses assigned to the hosts may be correct, it’s still possible that you’ve made them part of different VLANs by accident. In cases where two correctly-configured hosts connected to the same switch cannot communicate, be sure to check the VLAN membership of ports on the switch.

It is also possible for VLAN configurations to go beyond a single switch. Consider the figure below, where a crossover cable connects two switches. Notice that both switches contain ports on VLANs 1 and 2. In order for these VLANs to communicate properly across switches, we’ll need to set up and configure a trunk connection, which we’ll look at shortly.

Figure: VLANs spanning more than one switch.

Spanning Tree Protocol Convergence

While our network is now loop free, STP keeps working away. BPDUs are still sent out at 2-second intervals to be sure that things are how they should be. If at any point a bridge doesn’t hear from another bridge, the topology will need to be recalculated. For example, let’s say that bridge B fails. Bridge C will stop receiving BPDUs on its blocked port. Once 20 seconds have passed without receiving a BPDU from Bridge B, Bridge C will:

  • First go into a listening state for 15 seconds. During the listening state, a bridge is examining BPDUs sent by other bridges.
  • Then go into a learning state for 15 seconds. During this time, the bridge is building the MAC address table for the connected segment. Remember that it was in a blocked state previous to this.

After these stages, Bridge C will become the new designated bridge for segment BC, and will begin forwarding frames. Note that convergence took about 50 seconds to complete – 20 seconds waiting for a BPDU, plus 15 seconds listening and 15 seconds learning. The time during which a switch is listening and learning is referred to as the Forward Delay.

While a number of BPDUs are passed back and forth while a Spanning Tree topology is being calculated, in truth calculating a Spanning Tree topology is really no more than a three-step process:

  1. Elect the Root Bridge
  2. Elect a Root Port on each non-Root Bridge
  3. Elect one Designated Port on each network segment.

Once these steps are completed, a network should be loop free. However, you should also recall that while listening or learning, ports are not forwarding frames. A network is converged once all bridges have switched to a forwarding or blocking state.

Spanning Tree Protocol Designated Ports

You may have noticed that we haven’t talked about loops yet. If you look back at Figure 3-5, a loop definitively exists. On each network segment, one port needs to be chosen at the Designated Port. The responsibility of the Designated Port is to act as the single interface to forward traffic destined for the Root Bridge. Recall that in our network example, 3 segments exist. Refer back to Figure 5 to review the costs associated with each port on our network.

To choose the Designated Port, another election needs to take place. Bridges compare their port costs to decide who gets to be the Designated Port for that segment. Consider each segment in this figure:

On segment AC, the Designated Port will be port 2 on bridge A. That’s because port 2 on bridge A has a cost of 0, while port 1 on bridge C has a cost of 19.

On segment AB, the Designated Port will be port 1 on bridge A. Again, port 1 on bridge A has a cost of 0, while port 1 on bridge B has a cost of 19. Since their port cost is always 0, it should be clear that ports on the Root Bridge will always be Designated Ports for their connected segments.

On segment BC, there is a tie. Port 2 on each bridge has a cost of 19. As such, the Designated Port will be the switch with the lowest MAC address. In this case that’s bridge B, so port 2 on bridge B will become the Designated Port.

Note that after all this is done, all traffic from segment BC will be forwarded out port 2 on switch B. Port 2 on switch C will be put into blocking mode, as shown in the figure below. Notice also that there are no longer any loops on our network.

Figure: Designated Ports for each segment.

On any given segment, the bridge that has the current Designated Port is also known as the designated bridge.

Spanning Tree Protocol Root Ports

After the Root Bridge has been elected, it’s time for bridges to designate what are known as Root Ports. Before we can look at how Root Ports work, you need to know something about port costs. Obviously some ports are faster than others, and usually a faster port will be used to interconnect switches. As such, ports have what is known as a cost value, based on their speed. The lower a cost value, the faster a port. Table 3-1 outlines cost values used in STP calculations. It’s worth noting that when originally defined by the IEEE, 1 Gbps seemed like the fastest possible port speed. As such, there are two cost ranges that you’ll find on switches. The first column shows the original IEEE Spanning Tree port costs, and the second shows the new cost numbers. The Cisco 1900 switch uses the original IEEE values by default. Note that port cost values can also be changed.

Table: Original and new IEEE port costs.

Port Speed

Original IEEE Port Cost

New IEEE Port Cost

1 Gbps

1

4

100 Mbps

10

19

10 Mbps

100

100

Remember that a cost is associated with a port. These cost values are used in calculating which port will be the Root Port for any given bridge. All Non-Root Bridges will have one Root Port.

The figure below outlines why designating a Root Port is important. In it, bridges are exchanging BPDUs to try and find the lowest cost to the Root Bridge. Note that Bridge A is the Root Bridge in this case. Because it is the Root Bridge, both of its ports have a cost of 0. In this example, all of the bridges are connected using 100Mbps links. The port cost outlined in the table for a 100Mbps link is 19 (using the new IEEE costs).

Let’s walk through the process step by step. The Root Bridge will send out BPDUs with a cost of 0. These BPDUs will go to the 100Mbps port 1 on both bridges B and C. Since these ports have a cost of 19, the cost associated with port 1 on switches B and C reaching the Root Bridge is 19.

Figure: Port costs and Root Ports.

Now since B and C are also connected on segment BC with 100Mbps ports, these ports will also forward out BPDUs. Let’s assume that B is sending a BPDU to C. In it, it will announce a cost of 19 to reach the root. When it reaches C, this bridge will add its port cost of 19 to the value in the BPDU. As such, bridge C knows that it can reach the Root Bridge using port 2 with an aggregate cost of 38, or it can reach the Root Bridge with a cost of 19 using port 1. For bridge C, the Root Port becomes port 1, as it does for Bridge B as well. For both bridges B and C, port 1 represents the lowest cost to the root.

To summarize, a Root Port is the port on a switch that has the lowest cost path to the Root Bridge.

Spanning Tree Protocol Root Bridge

The first critical concept in understanding Spanning Tree is that of the Root Bridge. In any Spanning Tree instance, there is only one Root Bridge, and it must be elected. The Root Bridge is elected in the initial exchange of BPDUs between bridging devices. But how does the Root Bridge get elected? That’s simple. In networks running STP, every bridge has a priority value associated with it. By default, the priority of all bridges is 32,768, unless changed by an administrator. The bridge with the highest priority gets to be the Root Bridge. But wait – you’ll need to remember that the highest priority is the bridge with the lowest priority value. That is, a bridge priority of 1000 would beat the default priority of 32,768.

You have probably never touched bridge priorities. So if all the priorities are equal, who wins? That answer is the bridge with the lowest MAC address. All BPDUs contain a field called the Bridge ID (BID), which is actually made up of both the bridge’s priority and its MAC address. In cases where all priorities are equal, the bridge with the lowest MAC address gets to be the Root Bridge. Consider Figure the figure below, where Bridge A will become the Root Bridge, based on its MAC address.

Figure: Root Bridge election using priorities and MAC addresses.

So why should you care about a Root Bridge? The answer is that all other bridging devices need to calculate a path to the Root Bridge in order to make decisions on which links will be used, and which will not. By calculating the distance to the Root Bridge, not only does STP work to build a loop-free topology, but also one that will have the shortest distance between devices. In the case of STP, “shortest” refers to the path that has the lowest aggregate cost to the root. We’ll discuss aggregate costs in just a moment.

Tip: When bridge priorities are equal, the switch with the lowest MAC address will become the root bridge.

Spanning Tree Protocol

Let me start by saying that there are still many network administrators out there who consider the words “Spanning Tree” to be evil. This stems from the fact that many networks were first segmented using bridges, and this is where Spanning Tree got its start. The main problem is that just like anything else; Spanning Tree doesn’t work by magic. When a network is designed with redundancy and a link fails, it takes time to figure everything out and get back up to date – a process referred to as convergence. When a network using Spanning Tree does experience a failure, it can take anywhere between 30 seconds to over a minute for the network to converge. On a less-than-reliable large network, this can cause just as many headaches as it solves. To that end, many network administrators stopped using Spanning Tree and instead designed their networks loop-free, deciding that the lack of redundancy was better than dealing with convergence issues. In fact, once routing became a popular way to segment a network, many folks thought they had seen the end of Spanning Tree.

That was of course until Layer 2 switching became popular, reintroducing the need for the Spanning Tree Protocol on networks. The good news is that in the meantime, networks and equipment have gotten much more reliable. In that way, Spanning Tree isn’t nearly as painful as it once might have been, although the protocol itself still works in the same way it used to.

Spanning Tree isn’t nearly as difficult as most people make it out to be. At the most basic level, Spanning Tree’s job is to eliminate loops in a bridged or switched network that are caused by redundant paths. It does this by learning the topology of the network, and then selectively blocking ports to eliminate any loops. This is where the ‘tree’ part comes in. Instead of a network with loops, with Spanning Tree what you end up with is a tree-like structure of branches. When a failure occurs, Spanning Tree recalculates the topology, and makes use of the redundant path. If you keep this in mind as you’re trying to understand the protocol, you’ll really find that Spanning Tree isn’t that complex.

Tip: Spanning Tree’s main purpose is eliminate loops caused by redundant links on switched or bridged networks.

On most switches, Spanning Tree is turned on by default, mainly to help save you from yourself. You might accidentally introduce a loop to your network without really thinking about it when adding new equipment. To that end, Spanning Tree can also be turned off; although you’ll want to be sure that you really understand your network connections before doing that. By default, an instance of Spanning Tree runs on each VLAN that you’ve configured, although it can be turned off on a per-VLAN or global basis. When turned on, a switch using 802.1d will communicate with other switches using Spanning Tree to calculate its configuration. A Spanning Tree port can be in one of four states. These include:

  • Listening. In this state, a port is listening to Spanning Tree messages (BPDUs) and attempting to figure out how the network is configured.
  • Learning. In this state, a port is adding addresses to its MAC table, but not yet forwarding frames.
  • Forwarding. When in this state, a port is sending and receiving data as normal. During normal operation, a port will be in either a forwarding or a blocking state.
  • Blocking. When in this state, a port will neither send nor receive data, but will listen to network messages relating to Spanning Tree. By default, all ports are in blocking mode when a switch is first powered on.

So how is the state of a port decided? Well, messages are passed between bridges or switches that are referred to as Bridge Protocol Data Units (BPDUs). BPDUs are very small frames sent using multicasts to let other switches now about the network topology with respect to Spanning Tree. We’ll reference BPDUs often as we look at how the Spanning Tree topology is built.

Broadcast Storms

A broadcast storm occurs when packets are continuously forwarded around a network, grinding it to a halt. This is most easily illustrated with a simple example. Consider the network in Figure 3-1, with two bridges (Bridge A and Bridge B) connecting network segments 1 and 2. At first glance, the network probably looks good – if one of the two bridges fails, a second redundant path to the other segment exists. However, this design quickly becomes problematic, as I describe in the steps below.

Figure: Bridged network with redundancy.

Imagine that Computer 1 wants to send a frame to Computer 2. Let’s say that the bridges have already discovered that Computer 1 is on segment one, and that Computer 2 is on segment 2, and they have already added both to their MAC address tables. This is outlined in the figure below.

Bridge A MAC Table

Bridge B MAC Table

MAC

Interface

MAC

Interface

Computer 1

1

Computer 1

1

Computer 2

2

Computer 2

2

Remember that both segments are shared. As such, when Computer 1 sends a frame, both Bridge A and Bridge B will see it. Herein lies the first problem – both bridges see the frame and both will forward it. This means that 2 frames will be forwarded onto segment 2, even though only one was originally sent.

When those frames are forwarded, we have an even bigger problem. The frames will not only arrive at Computer 2 twice, but will also end up being encountered by both bridges on their segment 2 interfaces, as shown in the figure below.

Figure: Frame forwarded by both Bridge A and Bridge B.

So why is this a problem? Well, you’ll need to recall how a bridge builds its forwarding table. In this case, Bridge A will see the frame forwarded by Bridge B, and will look at the source address. The source address is still that of Computer 1. Because of this, Bridge A will now think that Computer 1 has been moved to segment 2, and will change its MAC address table. In the same way, Bridge B will see the frame forwarded by Bridge A, and will do the same. See the problem starting already?

Now let’s say that Computer 2 responds. The bridges will not forward these frames, because they think that Computer 1 is also on segment 2. Since Computer 1 never gets a response, it sends the original frame again – a bigger problem. The bridges now believe that Computer 1 is again on segment 1 (by looking at the source MAC address), and change their MAC tables yet again. 2 frames again get forwarded, and so on. Ultimately this corrupts the MAC address table. Based on the quantity of traffic being moved (remember, it could be many systems transmitting), a broadcast storm takes over the network. All this happens simply because we wanted a little redundancy.

So how do you avoid this scenario? Am I saying that you can’t have redundant links between switches? Not at all, but you will need a little help. In order to avoid the loops just described, you’ll need to use something called Spanning Tree Protocol (STP), defined in standard 802.1d. It will eliminate network loops until an active link loses connectivity. When this happens, Spanning Tree will automatically reconfigure the network to use the redundant path.

Redundancy and Loop Avoidance

When designing a switched or bridged network, you’ll almost certainly need to consider redundancy. While network redundancy is a great idea in principle, there are issues that you’ll need to be aware of. The biggest issue is that bridging redundancy exposes networks to a loop, and loops cause major problems if not dealt with properly.

The problems associated with network loops go back to the days when bridging was the primary way of segmenting a LAN. The idea was to have more than one bridge connecting two segments, in order to provide a redundant path should a link or bridge fail. The problem with having this redundancy in a bridged environment is that may create loops, and network loops are capable of causing communication problems. In the case of a bridging loop, a network becomes susceptible to broadcast storms.

In this section you’ll notice that I tend to refer to bridges instead of switches. The main reason is that a bridged network is easier to diagram that one using switches. For all intents and purposes, when describing loops the terms bridge and switch can be used interchangeably.

Cisco Switching Methods

When we looked at bridging in the previous chapter, I mentioned that a bridge would take the time to calculate the CRC value of every frame that it intended to forward. While this is true for a bridge, on Cisco switches you can configure the different methods in which switching will occur. Certainly a network will be more reliable if every frame has its CRC value calculated by the switch. However, this also introduces a degree of delay (or latency) to the network.

Network equipment today is more reliable than ever before. On a well-planned network using quality equipment, frame corruption shouldn’t be a huge issue. Because of this, you might consider eliminating the CRC check on frames to take advantage of higher forwarding rates. This can be done on Cisco switches (including the 1900) by configuring the method by which the switch forwards frames. The three frame forwarding methods supported by Cisco include:

  • Store-and-Forward
  • Cut-Through
  • FragmentFree

Store-and-Forward

Store-and-Forward switching is best described as traditional frame forwarding. When used, the switch will calculate the CRC value for each and every frame. When a frame enters a port, the switch will copy the entire frame onto its buffers and will calculate the CRC. If the CRC calculation shows the frame not to be corrupt, it will be forwarded to the destination port according to the information found in the switch’s MAC address table. In situations where the frame is corrupt, it will be dropped. Because Ethernet frames can be different sizes, the latency introduced by the Store-and-Forward method will vary according to the size of a frame. Latency is the time it takes the device to send the packet from the source to its destination. Latency coupled with bandwidth defines the network speed and the capacity of that network. Store-and-Forward switching is the slowest method of the three outlined in this section, but is the default on high-speed Catalyst switches like those in the 5000 and 6000 series.

Cut-Through

Cut-Trough switching is the fastest switching method offered by Cisco. Cut-Through doesn’t copy the entire frame to its buffers, but instead begins the forwarding process immediately once the first six bytes of the frame have entered the switch (remember that the first six bytes provide destination MAC address information). Because CRC values aren’t calculated, Cut-Through switches may very well forward corrupted frames. This is the tradeoff – you give up the added reliability of the additional CRC check, but gain in terms of faster frame forwarding rates. Another version of this switching method is referred to as adaptive Cut-Through. This involves a switch using Cut-Through until an error threshold is encountered. Once reached, the switching method automatically changes to Store-and-Forward.

FragmentFree

FragmentFree is a variation on the Cut-Through method described previously. Instead of initiating the forwarding process after the first six bytes of a frame, a switch configured to use FragmentFree waits until the first 64 bytes have been received, making sure that they are properly formatted. If they are, the switch will forward the frame to the port on which the destination MAC address resides.