Chapter 6. VLAN and Trunking Concepts

This chapter covers the following exam topics:

2.2. Describe classic Ethernet fundamentals

2.2.a. Forward

2.2.b. Filter

2.2.c. Flood

2.2.d. MAC address table

2.3 Describe switching concepts and perform basic configuration

2.3.a. STP

2.3.b. 802.1q

At its heart, the Layer 2 switching logic on Ethernet switches receives Ethernet frames, makes decisions, and then forwards (switches) those Ethernet frames. That core logic revolves around MAC addresses, the interface in which the frame arrives, and the interfaces out which the switch forwards the frame.

Several switch features have some impact on an individual switch’s decisions about where to forward frames, but of all the topics in this book, the virtual LAN (VLAN) easily has the biggest impact on those choices.

This chapter examines the concepts and configuration of VLANs. The first major section of the chapter explains the basics of VLANs and how to forward VLAN traffic over links called trunks. This first section explains Layer 2 forwarding, which includes considering the existence of VLANs. Next, the chapter adds the logic of how to forward data between two VLANs by using some form of routing, whether that routing is done by a device called a router or whether it is done by a switch that has the ability to also route packets.

The final section of the chapter explains the VLAN Trunking Protocol (VTP), which gives network engineers a tool to configure some VLAN settings on one LAN switch and have that configuration be pushed to the rest of the LAN switches.

1. In a LAN, which of the following terms best equates to the term VLAN?

a. Collision domain

b. Broadcast domain

c. Subnet

d. Single switch

e. Trunk

2. Imagine a switch with three configured VLANs. How many IP subnets are required, assuming that all hosts in all VLANs want to use TCP/IP?

a. 0.

b. 1.

c. 2.

d. 3.

e. You can’t tell from the information provided.

3. Switch SW1 sends a frame to switch SW2 using 802.1Q trunking. Which of the answers describes how SW1 changes or adds to the Ethernet frame before forwarding the frame to SW2?

a. It inserts a 4-byte header and changes the MAC addresses.

b. It inserts a 4-byte header and does not change the MAC addresses.

c. It encapsulates the original frame behind an entirely new Ethernet header

d. None of the other answers is correct.

4. For an 802.1Q trunk between two Ethernet switches, which answer most accurately defines which frames do not include an 802.1Q header?

a. Frames in the native VLAN (only one)

b. Frames in extended VLANs

c. Frames in VLAN 1 (not configurable)

d. Frames in all native VLANs (multiple allowed)

5. A Nexus switch has some ports assigned to VLAN 11 and some to VLAN 12. Which of the following devices, acting as described in the answers, can forward data between ports in different VLANs? (Choose two answers.)

a. The Nexus switch when acting as a Layer 2 switch

b. The Nexus switch when acting as a Layer 3 switch

c. An external router

d. An external bridge

6. A network engineer wants to use VTP to distribute VLAN configuration information to all switches in a data center so that all switches learn a new VLAN configuration when a VLAN configuration change is made. Which of the following modes cannot be used on any of the switches? (Choose two answers.)

a. Server

b. Off

c. Transparent

d. Client

7. Which of the following answers list configuration information that VTP distributes? (Choose two answers.)

a. VLAN name

b. VLAN assigned to a switch port

c. Ports on which 802.1Q is enabled

d. VLAN ID

A LAN includes all devices in the same broadcast domain.

A broadcast domain includes the set of all LAN-connected devices so that when any of the devices sends a broadcast frame, all the other devices get a copy of the frame. So, from one perspective, you can think of a LAN and a broadcast domain as being basically the same thing.

Without VLANs, a switch considers all its interfaces to be in the same broadcast domain. That is, for one switch, when a broadcast frame enters one switch port, the switch forwards that broadcast frame out all other ports. With that logic, to create two different LAN broadcast domains, you have to buy two different Ethernet LAN switches, as shown in Figure 6-1.

With support for VLANs, a single switch can accomplish the same goal of the design in Figure 6-1—that is, to create two broadcast domains. With VLANs, a switch can configure some interfaces into one broadcast domain and some into another, thus creating multiple broadcast domains. These individual broadcast domains created by the switch are called virtual LANs (VLANs).

For example, in Figure 6-2, the single switch creates two VLANs, treating the ports in each VLAN as being completely separate. The switch would never forward a frame sent by Dino (in VLAN 1) over to either Wilma or Betty (in VLAN 2).

Designing campus LANs to use more VLANs, each with a smaller number of devices, often helps improve the LANs in many ways. For example, a broadcast sent by one host in a VLAN will be received and processed by all the other hosts in the VLAN—but not by hosts in a different VLAN. Limiting the number of hosts that receive a single broadcast frame reduces the number of hosts that waste effort processing unneeded broadcasts. It also reduces security risks, because fewer hosts see frames sent by any one host. These are just a few reasons for separating hosts into different VLANs. The following list summarizes the most common reasons for choosing to create smaller broadcast domains (VLANs):

To reduce CPU overhead on each device by reducing the number of devices that receive each broadcast frame

To reduce security risks by reducing the number of hosts that receive copies of frames that the switches flood (broadcasts, multicasts, and unknown unicasts)

To improve security for hosts that send sensitive data by keeping those hosts on a separate VLAN

To create more flexible designs that group users by department, or by groups that work together, instead of by physical location

To solve problems more quickly, because the failure domain for many problems is the same set of devices as those in the same broadcast domain

To reduce the workload for the Spanning Tree Protocol (STP) by limiting a VLAN to a single access switch

This chapter does not examine all the reasons for VLANs in more depth. However, know that most enterprise networks use VLANs quite a bit. The rest of this chapter looks closely at the mechanics of how VLANs work across multiple Cisco switches. To that end, the next section examines VLAN trunking, a feature required when installing a VLAN that exists on more than one LAN switch.

When you use VLANs in networks that have multiple interconnected switches, which, of course, is typical in a data center LAN, the switches need to use VLAN trunking on the links between the switches. VLAN trunking causes the switches to use a process called VLAN tagging, by which the sending switch adds another header to the frame before sending it over the trunk. This extra trunking header includes a VLAN identifier (VLAN ID) field so that the sending switch can associate the frame with a particular VLAN ID, and the receiving switch can then know in what VLAN each frame belongs.

Figure 6-3 shows an example that demonstrates VLANs that exist on multiple switches, but it does not use trunking. First, the design uses two VLANs: VLAN 10 and VLAN 20. Each switch has two ports assigned to each VLAN, so each VLAN exists in both switches. To forward traffic in VLAN 10 between the two switches, the design includes a link between switches, with that link fully inside VLAN 10. Likewise, to support VLAN 20 traffic between switches, the design uses a second link between switches, with that link inside VLAN 20.

The design in Figure 6-3 functions perfectly. For example, PC11 (in VLAN 10) can send a frame to PC14. The frame flows into SW1, over the top link (the one that is in VLAN 10), and over to SW2.

However, although the design shown in Figure 6-3 works, it simply does not scale very well. It requires one physical link between switches to support every VLAN. If a design needs 10 or 20 VLANs, you would need 10 or 20 links between switches, and you would use 10 or 20 switch ports (on each switch) for those links.

VLAN trunking creates one link between switches that supports as many VLANs as you need. As a VLAN trunk, the switches treat the link as if it were a part of all the VLANs. At the same time, the trunk keeps the VLAN traffic separate, so frames in VLAN 10 would not go to devices in VLAN 20, and vice versa, because each frame is identified by VLAN number as it crosses the trunk. Figure 6-4 shows the idea, with a single physical link between the two switches.

The use of trunking allows switches to pass frames from multiple VLANs over a single physical connection by adding a small header to the Ethernet frame. For example, Figure 6-5 shows PC11 sending a broadcast frame on interface Fa0/1 at Step 1. To flood the frame, switch SW1 needs to forward the broadcast frame to switch SW2. However, SW1 needs to let SW2 know that the frame is part of VLAN 10, so that after the frame is received, SW2 will flood the frame only into VLAN 10, and not into VLAN 20. So, as shown at Step 2, before sending the frame, SW1 adds a VLAN header to the original Ethernet frame, with the VLAN header listing a VLAN ID of 10 in this case.

When SW2 receives the frame, it understands that the frame is in VLAN 10. SW2 then removes the VLAN header, forwarding the original frame out its interfaces in VLAN 10 (Step 3).

For another example, consider the case when PC21 (in VLAN 20) sends a broadcast. SW1 sends the broadcast out port Fa0/4 (because that port is in VLAN 20) and out Gi0/1 (because it is a trunk, meaning that it supports multiple different VLANs). SW1 adds a trunking header to the frame, listing a VLAN ID of 20. SW2 strips off the trunking header after noticing that the frame is part of VLAN 20, so SW2 knows to forward the frame out only ports Fa0/3 and Fa0/4, because they are in VLAN 20, and not out ports Fa0/1 and Fa0/2, because they are in VLAN 10.

Both ISL and 802.1Q tag each frame with the VLAN ID, but the details differ. 802.1Q inserts an extra 4-byte 802.1Q VLAN header into the original frame’s Ethernet header, as shown at the top of Figure 6-6. As for the fields in the 802.1Q header, only the 12-bit VLAN ID field inside the 802.1Q header matters for the topics discussed in this book. This 12-bit field supports a theoretical maximum of 2¹² (4096) VLANs, while in practice, it supports a maximum of 4094. (Both 802.1Q and ISL use 12 bits to tag the VLAN ID, with two reserved values [0 and 4095].)

802.1Q also defines one special VLAN ID on each trunk as the native VLAN (defaulting to use VLAN 1). By definition, 802.1Q simply does not add an 802.1Q header to frames in the native VLAN. When the switch on the other side of the trunk receives a frame that does not have an 802.1Q header, the receiving switch knows that the frame is part of the native VLAN. Note that because of this behavior, both switches must agree on which VLAN is the native VLAN.

The 802.1Q native VLAN provides some interesting functions, mainly to support connections to devices that do not understand trunking. For example, a Cisco switch could be cabled to a switch that does not understand 802.1Q trunking. The Cisco switch could send frames in the native VLAN—meaning that the frame has no trunking header—so that the other switch would understand the frame. The native VLAN concept gives switches the capability of at least passing traffic in one VLAN (the native VLAN), which can allow some basic functions, such as reachability to telnet into a switch.

First, it helps to know a few terms about some categories of LAN switches. Most of the Ethernet switch functions described in this book so far use the details and logic defined by OSI Layer 2 protocols. For example, Chapter 3 “Fundamentals of Ethernet LANs,” discussed how LAN switches receive Ethernet frames (a Layer 2 concept), look at the destination Ethernet MAC address (a Layer 2 address), and forward the Ethernet frame out some other interface. This chapter has already discussed the concept of VLANs as broadcast domains, which is yet another Layer 2 concept.

Some switches, including many in the Cisco Nexus series of data center switches, combine Layer 2 switching features with Layer 3 routing features. These basically route IP packets and use IP routing protocols, as introduced back in Chapter 4, “Fundamentals of IPv4 Addressing and Routing.” Switches that can also route packets go by the name multilayer switch or Layer 3 switch. The next few pages discuss the options for routing packets between VLANs, first with a router, and then with a multilayer switch.

Layer 2 switches will not forward data between two VLANs. In fact, one goal of VLANs is to separate traffic in one VLAN from another, preventing frames in one VLAN from leaking over to other VLANs. For example, when Dino (in VLAN 10) sends any Ethernet frame, if SW1 is a Layer 2 switch, that switch will not forward the frame to the PCs on the right in VLAN 20.

The network as a whole needs to support traffic flowing into and out of each VLAN, even though the Layer 2 switch does not forward frames outside a VLAN. The job of forwarding data into and out of a VLAN falls to routers. Instead of switching Layer 2 Ethernet frames between the two VLANs, the network must route Layer 3 packets between the two subnets.

That previous paragraph has some very specific wording related to Layers 2 and 3, so take a moment to reread and reconsider it. The Layer 2 logic does not let the Layer 2 switch forward the Layer 2 protocol data unit (L2PDU), the Ethernet frame, between VLANs. However, routers can route Layer 3 PDUs (L3PDUs [packets]) between subnets as their normal job in life.

For example, Figure 6-8 shows a router that can route packets between subnets 10 and 20. The figure shows the same Layer 2 switch as shown in Figure 6-7, with the same PCs and with the same VLANs and subnets. Now router R1 has one LAN physical interface connected to the switch and assigned to VLAN 10, and a second physical interface connected to the switch and assigned to VLAN 20. With an interface connected to each subnet, the Layer 2 switch can keep doing its job (forwarding frames inside a VLAN) while the router can do its job (routing IP packets between the subnets).

The figure shows an IP packet being routed from Fred, which sits in one VLAN/subnet, to Betty, which sits in the other. The Layer 2 switch forwards two different Layer 2 Ethernet frames: one in VLAN 10, from Fred to R1’s F0/0 interface, and the other in VLAN 20, from R1’s F0/1 interface to Betty. From a Layer 3 perspective, Fred sends the IP packet to its default router (R1), and R1 routes the packet out another interface (F0/1) into another subnet where Betty resides.

The design shown in Figure 6-8 works, but it uses too many physical interfaces, one per VLAN. A much less-expensive (and much preferred) option uses a VLAN trunk between the switch and router, requiring only one physical link between the router and switch, while supporting all VLANs. Trunking can work between any two devices that choose to support it: between two switches, between a router and a switch, or even between server hardware and a switch.

Figure 6-9 shows the same design idea as Figure 6-8, with the same packet being sent from Fred to Betty, except now R1 uses VLAN trunking instead of a separate link for each VLAN.

As a brief aside about terminology, many people describe the concept in Figures 6-8 and 6-9 as “routing packets between VLANs.” You can use that phrase, and people know what you mean. However, for exam preparation purposes, note that this phrase is not literally true, because it refers to routing packets (a Layer 3 concept) and VLANs (a Layer 2 concept). It just takes fewer words to say something like “routing between VLANs” rather than the literally true but long “routing Layer 3 packets between Layer 3 subnets, with those subnets each mapping to a different Layer 2 VLAN.”

The ultimate solution moves the routing functions inside the LAN switch hardware. Vendors long ago started combining the hardware and software features of their Layer 2 LAN switches, plus their Layer 3 routers, creating products called Layer 3 switches (also known as multilayer switches). Layer 3 switches can be configured to act only as a Layer 2 switch, or they can be configured to do both Layer 2 switching and Layer 3 routing.

Today, many data centers, as well as medium- to large-sized enterprise campus LANs, use Layer 3 switches to route packets between subnets (VLANs).

In concept, a Layer 3 switch works a lot like the original two devices on which the Layer 3 switch is based: a Layer 2 LAN switch and a Layer 3 router. In fact, if you take the concepts and packet flow shown in Figure 6-8, with a separate Layer 2 switch and Layer 3 router, and then imagine all those features happening inside one device, you have the general idea of what a Layer 3 switch does. Figure 6-10 shows that exact concept, repeating many details of Figure 6-8, but with an overlay that shows the one Layer 3 switch doing the Layer 2 switch functions and the separate Layer 3 routing function.

This chapter introduces the core concepts of routing IP packets between VLANs (or more accurately, between the subnets on the VLANs). Chapter 18, “IPv4 Routing Protocol Concepts,” discusses routing and Layer 3 switching in more depth, after you have read more about IPv4 addressing and subnetting.

For instance, if a LAN had 40 switches, and VLAN 11 needed to be supported on those switches, the configuration to create and name VLAN 11 could be done on one switch only. Then, VTP, running on all the switches, would send messages so that the other 39 switches could dynamically learn the configuration using VTP.

This final of three major sections in this chapter discusses the main concepts behind VTP. This section begins with a discussion of exactly what functions VTP provides, before moving on to show how VTP messages and processes advertise VLAN configuration information. This section ends with a discussion of how to avoid using VTP by using either VTP transparent mode or by disabling VTP.

VTP distributes some VLAN configuration information from one switch to the rest of the switches in a VTP domain. Specifically, the configuration includes the following:

The VLAN ID

The VLAN name

Note that VTP does advertise about each VLAN, but does not advertise the VLAN associated with each access port. For example, VTP does advertise the existence of a VLAN 11, named Payroll; however, VTP does not advertise the configuration that switch SW1’s E1/2 port has been assigned to VLAN 11.

VTP can also group switches together using a concept called VTP domains. For instance, a data center might separate the LAN to support accounting functions in one part of the network and sales functions in another. VTP can be configured to use VTP domains with different names (for example, Accounting or Sales) so that VLANs configured in the Sales domain are learned only by other switches inside that domain and are not learned by the Accounting domain’s switches, as shown in Figure 6-11.

VTP can be a powerful tool, but it is also a potentially dangerous tool. It does reduce the configuration effort, and it reduces the chances of making a typo in the VLAN name, because it is only typed once. However, a configuration mistake, such as deleting a VLAN that is still in use, automatically deletes the VLAN from all the switches in the same VTP domain. Once a VLAN is deleted, each switch can no longer forward frames in that VLAN. Other less-obvious mistakes can also lead to unintentionally deleting VLANs as well, so some installations simply avoid the dangers of VTP by just not using VTP.

This section next looks at how VTP works if you decide to use VTP, followed by a discussion of a few different ways to disable VTP.

Which switches to put in the same VTP domain; that is, which switches need to know the same set of VLANs.

A text name for the domain.

A VTP password for the domain. (Switches ignore incoming VTP messages unless both the domain name and password match with the local switch’s configuration.)

Which switches will act as VTP servers and which will act as VTP clients.

For example, imagine a small network, as shown in Figure 6-12. In this case, the engineer chose to put all switches in the same VTP domain, using a domain name of MyCompany and a password of MyPassw0rd. The engineer also chose to make the two switches at the top of the figure (EoR1 and EoR2) VTP servers, and the other switches VTP clients.

Most of the choices shown in Figure 6-12 relate to the business needs, but the choice of VTP server and client relates more to the features of VTP. VTP defines several modes of operation, including server mode and client mode. The VTP mode determines how the switch acts with VTP, with VTP servers and clients being active participants in VTP.

VTP servers and clients can both learn about an updated configuration by listening for a VTP message, processing the message, and then forwarding the message. However, only VTP servers can be used to configure VLANs—that is, creating a VLAN, giving it a name, and deleting it—whereas VTP client switches cannot. A VTP client switch literally rejects the configuration commands to create a VLAN because of the fact that the switch is a VTP client.

Figure 6-13 shows the process of what happens on a smaller LAN than shown in Figure 6-12. This updated LAN drawing has a different topology, but fewer links, just so the VTP features are more obvious; the design in Figure 6-13 is not a typical design. In this scenario, new VLAN configuration is added to EoR1, which then sends VTP messages to inform the other switches about the new VLAN.

The figure shows the following the steps:

Step 1. An engineer configures VLAN 11 on EoR1.

Step 2. EoR1 sends a new VTP update out its trunks to ToR1 and EoR2.

Step 3. ToR1 receives the VTP update, learns about new VLAN 11, and adds VLAN 11 to its local configuration.

Step 4. EoR2 also receives the VTP update, learns about new VLAN 11, and adds VLAN 11 to its local configuration.

Step 5. EoR2 forwards the VTP update to ToR4.

Step 6. ToR4 then learns about VLAN 11.

This example shows the basic process. The switches forward the VTP messages so they reach all the switches, following the spanning-tree path, as discussed in upcoming chapters. Both the VTP client and VTP server switches react, updating their configuration. By the end of the process, all four switches once again have a consistent configuration of the VLAN IDs and VLAN names.

The example in Figure 6-13 shows the basics, but VTP does more than what is shown in that example. To round out the discussion, note that the VTP update actually holds the VLAN database, which is the entire list of VLAN IDs and names. That is, when a configuration change is made, the server sends the entire database. Once the process has completed, each switch has an updated copy of the database.

The VTP process also makes use of a VTP revision number, which is a revision number for the VLAN database. Each VTP update message lists the revision number of the current database. When a configuration change occurs, the VTP server adds one to the revision number and then sends a new VTP update. The other switches can notice the change to the revision number and know that the VLAN database has changed.

As an example, suppose that the VTP update message in Figure 6-13 was revision 7. Then imagine the following process happening over the next few days:

Step 1. For 3 days, no one changes the VLAN configuration. So, EoR1 and EoR2 independently send VTP updates every 5 minutes, with revision number 7.

Step 2. The engineer makes a VLAN configuration change on EoR1. The resulting VTP update, sent by EoR1 (as shown in Figure 6-13), lists revision 8.

Step 3. All the other switches in the domain receive the VTP update with revision 8 and know that the previous message listed revision 7, so each switch uses VTP messages to learn about the VLAN configuration changes and to update their local copy of the VLAN database.

Step 4. Both VTP servers now have a copy of the VLAN database based on revision 8.

Step 5. Another day passes with no configuration changes; EoR1 and EoR2 independently send VTP updates, every 5 minutes, with revision 8.

Step 6. Next, the engineer happens to make a configuration change from EoR2 instead of EoR1. EoR2 sends a VTP update with revision 9.

Step 7. All the other switches process the revision 9 update, realizing that a configuration change happened because of the revision number change from 8 to 9.

Step 8. Both VTP servers (EoR1 and EoR2) now have a copy of the database based on revision 9.

As you can see, all the clients and servers track the revision number of the VLAN database as a way to synchronize, so that all switches use the same version of the VLAN database—in other words, the same version of the VLAN configuration.

VTP transparent mode works in subtle ways, and it’s most useful when an engineer wants to use VTP for some switches and not use VTP for others.

VTP off mode is straightforward, disabling VTP completely, and makes more sense when the engineer does not want to use VTP on any of the switches in the LAN.

VTP off mode disables all VTP processes on the switch. The switch does not originate VTP messages or process received VTP messages, and, importantly, it does not forward VTP messages. In designs that simply want to avoid VTP on all switches, off mode should be used.

VTP transparent mode disables most VTP processing, but not all, making a switch be transparent to the working (server and client) switches. To see how transparent mode is useful, consider the following requirements for a design:

Use VTP for some switches in the data center.

Purposefully do not use VTP on one switch and instead configure VLANs directly on that switch.

The switches should all have trunks connected to each other, which is useful for the VTP traffic to be able to pass through the transparent mode switch to other VTP servers and clients.

Figure 6-14 shows just such an example, using the same initial action as shown in Figure 6-13. In this case, the engineer wants to make switch EoR2 not use VTP, but the other three switches will use VTP. With EoR2 configured in VTP transparent mode, the engineer adds VLAN 11 configuration at EoR1, with the behavior of EoR2 differing from the example in Figure 6-13.

With EoR2 in VTP transparent mode, the switch acts just like VTP off mode, except that it can forward the VTP update sent by EoR1. As shown in Steps 4 and 5, EoR2 (in transparent mode) ignores the contents of the VTP update but forwards the update to ToR4. If EoR2 had been in VTP off mode, it would not have forwarded the VTP update.

VTP transparent and off-mode switches also have the added advantage of supporting more VLANs than VTP servers and clients. Servers and clients support VLANs 1–1005 only (called normal or standard VLANs). On Nexus switches, VTP transparent and off-mode switches support extended VLANs 1006–4094. (Note that 3968–4047 and 4094 are reserved and cannot be deleted.)

VTP off mode works very well for simply avoiding VTP altogether for all switches, enabling the use of many more switches, and is the preferred method to disable VTP when the design chooses to completely avoid using VTP. VTP transparent mode should be used as a tactic to support designs that call for use of VTP in some but not all switches.

802.1Q

trunk

trunking administrative mode

trunking operational mode

VLAN

VTP

VTP client mode

VTP server mode

VTP transparent mode

Layer 3 switch

access interface

trunk interface