This chapter introduces concepts specific to VLANs:
Quick quiz: what does the text remind us about again at the start of this chapter?
Switches are used to break up collision domains, and routers are used to break up broadcast domains.
Mouse over the sentence above to see the answer.
The chapter tells us that a network that contains only one broadcast domain can be called a flat network. You have better throughput by using switches instead of hubs, but switches alone do nothing for creating more broadcast domains. Why do we want more broadcast domains? To keep broadcasts away from hosts that don't need to be bothered by them. The solution proposed by this chapter: Virtual LANs. VLANs are logical subdivisions of a network, and you can make them using switches. Creating VLANs can allow you to separate users who would otherwise be in the same LAN, without having to separate them with routers. You are going to use switches anyway, so this approach does not lead to greater expense.
Switches increase the number of collision domains in your network, but they do not increase broadcast domains, unless you implement VLANs. Doing so will make the network more efficient, in that broadcasts can be limited to the audiences they are intended for.
The text seems to treat routers lightly at this stage. The point is that routers should not be the only devices used for security in a network, else you are not securing the LANs themselves. The idea is that you can control what VLAN each port on a switch connects to. Before you adopt this as a general principle, however, realize that not all LANs are locked down to this degree. It is sometimes good to let there be some flexibility, and to use other, simpler means to keep intruders off your network.
The text tells us that hosts on one VLAN, by default, are not able to communicate with hosts on another VLAN, even though they are all plugged into the same switch. This is true as far as broadcast messages are concerned. The text warns us that some applications use broadcasts extensively, so limiting those applications to a VLAN will minimize the burden on your network. To communicate from one VLAN to another, you can place a router on the network that belongs to both VLANs, with programming to allow traffic between them as desired.
A complementary fact: hosts whose ports are on the same VLAN can communicate with each other, regardless of which switch they are actually plugged in to.
In the examples in the text, the author describes creating a series of VLANs that he numbers 2 through 7. Some facts are helpful in understanding his numbers and his illustration:
VLANs can be static or dynamic:
The text describes two kinds of links (ports) on switches in VLAN networks:
As you might imagine, frames in a VLAN environment need to carry information about which VLAN the frame is meant for. Otherwise the switches could not decide whether to pass the frame to the next switch, or to a host on that switch. This information is called a frame tag, a VLAN ID, or a color. In the image below, I have used colors to illustrate the idea. The two boxes are switches. Each host is using an access link to its switch, and I have indicated two VLANs with light blue and light red patch cables. The green line between the two switches symbolizes a trunk link between them.
If a frame is sent from the host on the upper left to the host just to the right, that frame is tagged as being on the light red VLAN. (Both sender and receiver are on the light red VLAN, and are connected to the blue switch.) The blue switch receives the frame, and notes that it is for a host connected to it, on the same VLAN as the sender. The VLAN information is stripped off, and the frame is delivered to the addressee.
If the same host sends a frame to the host at the upper right of the image, it is still sending to another host on the light red VLAN. However, when the blue switch receives the frame, it notes that the addressee is not connected to it. The frame is sent across the trunk link to the red switch, and the VLAN tag is left on the frame. The red switch receives the frame, and notes that it is addressed to a host connected to it with an access link. The switch confirms that the frame is for a host on the same VLAN as the sender, the VLAN tag is removed, and the red switch delivers the frame to the addressee.
The text uses a new phrase in this section: switch fabric. The author means all the interconnected communication paths between all the switches in his network. You might think of it as many "threads", woven back and forth through the network, making a fabric. (It's a metaphor; don't stretch it too far.)
The text moves on to describe methods and protocols used for VLAN tagging:
Under VTP, switches can operate in three modes:
VTP can reduce its requirements for network traffic by using VTP Pruning. This method avoids sending updates to switches that are not part of the VLAN being updated. Oddly, this feature is not turned on by default. It cannot be turned on for VLAN 1, but it can be used for VLANs 2 through 1005.
The text returns to the idea of using routers to connect your VLANs. Remember that even though they are virtual, VLANs are separate networks, so you need routers to connect them together.
You begin creating VLANs by giving them names. Remember that VLAN 1 is reserved, so you should begin creating a series of them by starting with VLAN 2.
Back to switches. On a Catalyst 1900 switch, enter configuration
mode, and issue the command:
This command creates a VLAN, but does not move any ports into it. All ports are in VLAN 1, by default, until you move them into other VLANs.
On a 2950 switch, naming the VLAN is optional, so the command
To display the VLANs, use the command show vlan or show vlan brief.
Placing ports on a VLAN is done one way on a 1900 and another way on a 2950:
Trunk ports must be further configured:
A 3550 switch supports Layer 3 processes, and it will support
ISL as well as 802.1Q encapsulation. It has a new command,
with three options:
Back to routers, again. The text describes connecting a 1900 switch and a 2950 switch through a router. As noted above, these two switches use different encapsulation methods. This can still work, if we configure subinterfaces for the actual interface to the router. A subinterface is only logical: it does not physically exist. Declaring subinterfaces is like assigning multiple personalities to the same interface; we tell it to behave differently depending on who or what it is interacting with.
To configure a subinterface, first access it as you would the interface itself, but add a dot and a number. The text makes a reasonable suggestion that you should use subinterface numbers that match the VLAN the subinterface will interact with:
The text continues with an example that confuses the issue by throwing in IP addressing. Take this as an opportunity to review the subnetting chapter in the text. Discussing the example, some observations are made that are not entirely clear:
We are told that is not actually necessary to use a different subnet for each VLAN, but is recommended, and the text follows this concept in its examples. It is important to review the lessons in previous chapters about subnetting to be able to determine the subnets, masks, and addresses that would be assigned to router interfaces and hosts in these examples.
The text reminds us that switches in VTP environments are configured as VTP servers by default. To create a VTP domain, you must use a VTP server.
The text turns to troubleshooting VTP. Remember key facts: