Foundation Topics


Virtual LANs

Consider a network design that consists of Layer 2 devices only. For example, this design could be a single Ethernet segment, an Ethernet switch with many ports, or a network with several interconnected Ethernet switches. A full Layer 2only switched network is referred to as a flat network topology. A flat network is a single broadcast domain, such that every connected device sees every broadcast packet that is transmitted. As the number of stations on the network increases, so does the number of broadcasts.

Because of the Layer 2 foundation, flat networks cannot contain redundant paths for load balancing or fault tolerance. The reason for this is explained in Chapters 9, "Traditional Spanning Tree Protocol," through 12, "Advanced Spanning Tree Protocol." To gain any advantage from additional paths to a destination, Layer 3 routing functions must be introduced.

A switched environment offers the technology to overcome flat network limitations. Switched networks can be subdivided into VLANs. By definition, a VLAN is a single broadcast domain. All devices connected to the VLAN receive broadcasts sent by any other VLAN members. However, devices connected to a different VLAN will not receive those same broadcasts. (Naturally, VLAN members also receive unicast packets directed toward them from other VLAN members.)

A VLAN consists of hosts defined as members, communicating as a logical network segment. In contrast, a physical segment consists of devices that must be connected to a physical cable segment. A VLAN can have connected members located anywhere in the campus network, as long as VLAN connectivity is provided among all members. Layer 2 switches are configured with a VLAN mapping and provide the logical connectivity among the VLAN members.

Figure 6-1 shows how a VLAN can provide logical connectivity between switch ports. Two workstations on the left Catalyst switch are assigned to VLAN 1, while a third workstation is assigned to VLAN 100. In this example, no communication can occur between VLAN 1 and VLAN 100. Both ends of the link between the Catalysts are assigned to VLAN 1. One workstation on the right Catalyst also is assigned to VLAN 1. Because there is end-to-end connectivity of VLAN 1, any of the workstations on VLAN 1 can communicate as if they were connected to a physical network segment.

Figure 6-1. VLAN Functionality


VLAN Membership

When a VLAN is provided at an access-layer switch, an end user must have some means of gaining membership to it. Two membership methods exist on Cisco Catalyst switches:

  • Static VLAN configuration

  • Dynamic VLAN assignment

Static VLANs

Static VLANs offer port-based membership, in which switch ports are assigned to specific VLANs. End-user devices become members in a VLAN based on the physical switch port to which they are connected. No handshaking or unique VLAN membership protocol is needed for the end devices; they automatically assume VLAN connectivity when they connect to a port. Normally, the end device is not even aware that the VLAN exists. The switch port and its VLAN simply are viewed and used as any other network segment, with other "locally attached" members on the wire.

Switch ports are assigned to VLANs by the manual intervention of the network administrator, hence the static nature. Each port receives a Port VLAN ID (PVID) that associates it with a VLAN number. The ports on a single switch can be assigned and grouped into many VLANs. Even though two devices are connected to the same switch, traffic will not pass between them if they are connected to ports on different VLANs. To perform this function, you could use either a Layer 3 device to route packets or an external Layer 2 device to bridge packets between the two VLANs.

The static port-to-VLAN membership normally is handled in hardware with application-specific integrated circuits (ASIC) in the switch. This membership provides good performance because all port mappings are done at the hardware level, with no complex table lookups needed.

Configuring Static VLANs

This section describes the switch commands needed to configure static VLANs. By default, all switch ports are assigned to VLAN 1, are set to be a VLAN type of Ethernet, and have a maximum transmission unit (MTU) size of 1500 bytes.

First, the VLAN must be created on the switch, if it does not already exist. Then, the VLAN must be assigned to specific switch ports. VLANs always are referenced by a VLAN number, which can range from 1 to 1005. VLANs 1 and 1002 through 1005 automatically are created and are set aside for special uses. For example, VLAN 1 is the default VLAN for every switch port. VLANs 1002 to 1005 are reserved for legacy functions related to Token Ring and FDDI switching.

Catalyst IOS switches also can support extended-range VLANs, in which the VLAN number can be 1 to 4094, for compatibility with the IEEE 802.1Q standard. The extended range is enabled only when the switch is configured for VTP transparent mode with the vtp mode transparent global configuration command. This is because of limitations with VTP versions 1 and 2. VTP version 3 does allow extended range VLANs to be used and advertised, but this version is not available in any IOS-based Catalyst switches at press time. (VTP is covered in Chapter 7).

Tip

Although the extended range of VLAN numbers enables you to support more VLANs in your network, some limitations exist. For example, a switch normally maintains VLAN definitions in a special database file, separate from the switch configuration. The VLAN Trunking Protocol (VTP) uses the VLAN database so that VLAN definitions can be advertised and shared between switches over trunk links. When extended-range VLANs are created, they are not stored in the VLAN database file.

Why does this matter? As long as the switch remains in VTP transparent mode, the extended VLANs can be used. However, if the switch later is configured to participate in VTP as either a server or a client, you must manually delete the extended VLANs. For any switch ports that were assigned to the extended VLANs, you also must reconfigure them for VLAN membership within the normal VLAN range.


To configure static VLANs, you first can define the VLAN with the following command in global configuration mode:

Switch(config)# vlan vlan-num Switch(config-vlan)# name vlan-name

The VLAN numbered vlan-num immediately is created and stored in the database, along with a descriptive text string defined by vlan-name (up to 32 characters with no embedded spaces). The name command is optional; if it is not used, the default VLAN name is of the form VLANXXX, where XXX represents the VLAN number. If you need to include spaces to separate words in the VLAN name, use underscore characters instead.

As an example, you can use the following commands to create VLANs 2 and 101:

Switch(config)# vlan 2 Switch(config-vlan)# name Engineering Switch(config-vlan)# vlan 101 Switch(config-vlan)# name Marketing

To delete a VLAN from the switch configuration, you can use the no vlan vlan-num command.

Next, you should assign one or more switch ports to the VLAN. Use the following configuration commands:

Switch(config)# interface type module/number Switch(config-if)# switchport Switch(config-if)# switchport mode access Switch(config-if)# switchport access vlan vlan-num

The initial switchport command configures the port for Layer 2 operation. By default, every Catalyst IOS switch port is ready for Layer 3 operation, something that doesn't coexist with Layer 2 VLANs.

The switchport mode access command forces the port to be assigned to only a single VLAN, providing VLAN connectivity to the access layer or end user. The port is given a static VLAN membership by the switchport access vlan command. Here, the logical VLAN is referenced by the vlan-num setting (1 to 1005 or 1 to 4094).

To verify VLAN configuration, use the show vlan command to output a list of all VLANs defined in the switch, along with the ports that are assigned to each VLAN. Example 6-1 shows some sample output from the show vlan command.

Example 6-1. Verifying VLAN Configuration with show vlan Command
Switch# show vlan VLAN Name                             Status    Ports ---- -------------------------------- --------- ------------------------------- 1    default                          active    Gi1/1, Gi1/2, Gi3/20, Gi4/20 2    Engineering                      active    Gi4/2, Gi4/3, Gi4/4, Gi4/5                                                 Gi4/6, Gi4/7, Gi4/8, Gi4/9                                                 Gi4/10, Gi4/11, Gi4/12 101  Marketing                        active    Gi2/5, Gi2/6, Gi2/7, Gi2/8                                                 Gi2/9, Gi2/10, Gi2/11, Gi2/12                                                 Gi2/13, Gi2/14, Gi2/15, Gi2/16                                                 Gi2/17, Gi2/18

Dynamic VLANs

Dynamic VLANs provide membership based on the MAC address of an end-user device. When a device is connected to a switch port, the switch must, in effect, query a database to establish VLAN membership. A network administrator also must assign the user's MAC address to a VLAN in the database of a VLAN Membership Policy Server (VMPS).

With Cisco switches, dynamic VLANs are created and managed using network-management tools such as CiscoWorks 2000. Dynamic VLANs allow a great deal of flexibility and mobility for end users but require more administrative overhead.

Note

Dynamic VLANs are not covered in this text or in the BCMSN course or exam (at press time). For more information, refer to "Configuring VMPS" at http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12112cea/3550scg/swvlan.htm#xtocid35.


Deploying VLANs

To implement VLANs, you must consider the number of VLANs you need and how best to place them. As usual, the number of VLANs depends on traffic patterns, application types, segmentation of common workgroups, and network-management requirements.

An important factor to consider is the relationship between VLANs and the IP addressing schemes used. Cisco recommends a one-to-one correspondence between VLANs and IP subnets. This recommendation means that if a subnet with a 24-bit mask (255.255.255.0) is used for a VLAN, no more than 254 devices should be in the VLAN. In addition, you should not allow VLANs to extend beyond the Layer 2 domain of the distribution switch. In other words, the VLAN should not reach across a network's core and into another switch block. The idea again is to keep broadcasts and unnecessary traffic movement out of the core block.

VLANs can be scaled in the switch block by using two basic methods:

  • End-to-end VLANs

  • Local VLANs

End-to-End VLANs

End-to-end VLANs, also called campus-wide VLANs, span the entire switch fabric of a network. They are positioned to support maximum flexibility and mobility of end devices. Users can be assigned to VLANs regardless of their physical location. As a user moves around the campus, that user's VLAN membership stays the same. This means that each VLAN must be made available at the access layer in every switch block.

End-to-end VLANs should group users according to common requirements. All users in a VLAN should have roughly the same traffic flow patterns, following the 80/20 rule. Recall that this rule estimates that 80 percent of user traffic stays within the local workgroup, while 20 percent is destined for a remote resource in the campus network. Although only 20 percent of the traffic in a VLAN is expected to cross the network core, end-to-end VLANs make it possible for 100 percent of the traffic within a single VLAN to cross the core.

Because all VLANs must be available at each access-layer switch, VLAN trunking must be used to carry all VLANs between the access- and distribution-layer switches.

Tip

End-to-end VLANs are not recommended in an enterprise network, unless there is a good reason. In an end-to-end VLAN, broadcast traffic is carried over from one end of the network to the other, creating the possibility for a broadcast storm or Layer 2 bridging loop to spread across the whole extent of a VLAN. This can exhaust the bandwidth of distribution- and core-layer links, as well as switch CPU resources. Now the storm or loop has disrupted users on the end-to-end VLAN, in addition to users on other VLANs that might be crossing the core.

When such a problem occurs, troubleshooting becomes more difficult. In other words, the risks of end-to-end VLANs outweigh the convenience and benefits.


Local VLANs

Because most enterprise networks have moved toward the 20/80 rule (where server and intranet/ Internet resources are centralized), end-to-end VLANs have become cumbersome and difficult to maintain. The 20/80 rule reverses the traffic pattern of the end-to-end VLAN: Only 20 percent of traffic is local, while 80 percent is destined to a remote resource across the core layer. End users usually require access to central resources outside their VLAN. Users must cross into the network core more frequently. In this type of network, VLANs should be designed to contain user communities based on geographic boundaries, with little regard to the amount of traffic leaving the VLAN.

Local or geographic VLANs range in size from a single switch in a wiring closet to an entire building. Arranging VLANs in this fashion enables the Layer 3 function in the campus network to intelligently handle the interVLAN traffic loads, where traffic passes into the core. This scenario provides maximum availability by using multiple paths to destinations, maximum scalability by keeping the VLAN within a switch block, and maximum manageability.

VLAN Trunks

At the access layer, end-user devices connect to switch ports that provide simple connectivity to a single VLAN each. The attached devices are unaware of any VLAN structure and simply attach to what appears to be a normal physical network segment. Remember, sending information from an access link on one VLAN to another VLAN is not possible without the intervention of an additional deviceeither a Layer 3 router or an external Layer 2 bridge.

Note that a single switch port can support more than one IP subnet for the devices attached to it. For example, consider a shared Ethernet hub that is connected to a single Ethernet switch port. One user device on the hub might be configured for 192.168.1.1 255.255.255.0, while another is assigned 192.168.17.1 255.255.255.0. Although these subnets are discontiguous and unique, and both are communicating on one switch port, they cannot be considered separate VLANs. The switch port supports one VLAN, but multiple subnets can exist on that single VLAN.

A trunk link, however, can transport more than one VLAN through a single switch port. Trunk links are most beneficial when switches are connected to other switches or switches are connected to routers. A trunk link is not assigned to a specific VLAN. Instead, one, many, or all active VLANs can be transported between switches using a single physical trunk link.

Connecting two switches with separate physical links for each VLAN is possible. The top half of Figure 6-2 shows how two switches might be connected in this fashion.

Figure 6-2. Passing VLAN Traffic Using Single Links Versus Trunk Links


As VLANs are added to a network, the number of links can grow quickly. A more efficient use of physical interfaces and cabling involves the use of trunking. The bottom half of the figure shows how one trunk link can replace many individual VLAN links.

Cisco supports trunking on both Fast Ethernet and Gigabit Ethernet switch links, as well as aggregated Fast and Gigabit EtherChannel links. To distinguish between traffic belonging to different VLANs on a trunk link, the switch must have a method of identifying each frame with the appropriate VLAN. In fact, the switches on each end of a trunk link both must have the same method for correlating frames with VLAN numbers. The next section covers several available identification methods.

VLAN Frame Identification

Because a trunk link can transport many VLANs, a switch must identify frames with their respective VLANs as they are sent and received over a trunk link. Frame identification, or tagging, assigns a unique user-defined ID to each frame transported on a trunk link. Think of this ID as the VLAN number or VLAN "color," as if each VLAN was drawn on a network diagram in a unique color.

VLAN frame identification was developed for switched networks. As each frame is transmitted over a trunk link, a unique identifier is placed in the frame header. As each switch along the way receives these frames, the identifier is examined to determine to which VLAN the frames belong and then is removed.

If frames must be transported out another trunk link, the VLAN identifier is added back into the frame header. Otherwise, if frames are destined out an access (nontrunk) link, the switch removes the VLAN identifier before transmitting the frames to the end station. Therefore, all traces of VLAN association are hidden from the end station.

VLAN identification can be performed using two methods, each using a different frame identifier mechanism:

  • Inter-Switch Link (ISL) protocol

  • IEEE 802.1Q protocol

These methods are described in the sections that follow.

Inter-Switch Link Protocol

The Inter-Switch Link (ISL) protocol is a Cisco-proprietary method for preserving the source VLAN identification of frames passing over a trunk link. ISL performs frame identification in Layer 2 by encapsulating each frame between a header and a trailer. Any Cisco switch or router device configured for ISL can process and understand the ISL VLAN information. ISL primarily is used for Ethernet media, although Cisco has included provisions to carry Token Ring, FDDI, and ATM frames over Ethernet ISL. (A Frame-Type field in the ISL header indicates the source frame type.)

When a frame is destined out a trunk link to another switch or router, ISL adds a 26-byte header and a 4-byte trailer to the frame. The source VLAN is identified with a 15-bit VLAN ID field in the header. The trailer contains a cyclic redundancy check (CRC) value to ensure the data integrity of the new encapsulated frame. Figure 6-3 shows how Ethernet frames are encapsulated and forwarded out a trunk link. Because tagging information is added at the beginning and end of each frame, ISL sometimes is referred to as double tagging.

Figure 6-3. ISL Frame Identification


If a frame is destined for an access link, the ISL encapsulation (both header and trailer) is not rewritten into the frame before transmission. This removal preserves ISL information only for trunk links and devices that can understand the protocol.

Tip

The ISL method of VLAN identification or trunking encapsulation no longer is supported across all Cisco Catalyst switch platforms. Even so, you should still be familiar with it and know how it compares to the standards-based IEEE 802.1Q method.


IEEE 802.1Q Protocol

The IEEE 802.1Q protocol also can carry VLAN associations over trunk links. However, this frame-identification method is standardized, allowing VLAN trunks to exist and operate between equipment from multiple vendors.

In particular, the IEEE 802.1Q standard defines an architecture for VLAN use, services provided with VLANs, and protocols and algorithms used to provide VLAN services. You can find further information about the 802.1Q standard at http://grouper.ieee.org/groups/802/1/pages/802.1Q.html.

As with Cisco ISL, IEEE 802.1Q can be used for VLAN identification with Ethernet trunks. However, instead of encapsulating each frame with a VLAN ID header and trailer, 802.1Q embeds its tagging information within the Layer 2 frame. This method is referred to as single-tagging or internal tagging.

802.1Q also introduces the concept of a native VLAN on a trunk. Frames belonging to this VLAN are not encapsulated with any tagging information. If an end station is connected to an 802.1Q trunk link, the end station can receive and understand only the native VLAN frames. This provides a simple way to offer full trunk encapsulation to the devices that can understand it, while giving normal-access stations some inherent connectivity over the trunk.

In an Ethernet frame, 802.1Q adds a 4-byte tag just after the source address field, as shown in Figure 6-4.

Figure 6-4. IEEE 802.1Q Frame-Tagging Standard


The first 2 bytes are used as a Tag Protocol Identifier (TPID) and always have a value of 0x8100 to signify an 802.1Q tag. The remaining 2 bytes are used as a Tag Control Information (TCI) field. The TCI information contains a 3-bit Priority field, which is used to implement class-of-service (CoS) functions in the accompanying 802.1Q/802.1p prioritization standard. One bit of the TCI is a Canonical Format Indicator (CFI), flagging whether the MAC addresses are in Ethernet or Token Ring format. (This also is known as canonical format, or little-endian or big-endian format.)

The last 12 bits are used as a VLAN Identifier (VID) to indicate the source VLAN for the frame. The VID can have values from 0 to 4095, but VLANs 0, 1, and 4095 are reserved.

Note that both ISL and 802.1Q tagging methods have one implicationthey add to the length of an existing Ethernet frame. ISL adds a total of 30 bytes to each frame, whereas 802.1Q adds 4 bytes. Because Ethernet frames cannot exceed 1518 bytes, the additional VLAN tagging information can cause the frame to become too large. Frames that barely exceed the MTU size are called baby giant frames. Switches usually report these frames as Ethernet errors or oversize frames.

Note

Baby giant, or oversize, frames can exceed the frame size set in various standards. To properly handle and forward them anyway, Catalyst switches use proprietary hardware with the ISL encapsulation method. In the case of 802.1Q encapsulation, switches can comply with the IEEE 802.3ac standard, which extends the maximum frame length to 1522 bytes.


Dynamic Trunking Protocol

You manually can configure trunk links on Catalyst switches for either ISL or 802.1Q mode. In addition, Cisco has implemented a proprietary, point-to-point protocol called Dynamic Trunking Protocol (DTP) that negotiates a common trunking mode between two switches. The negotiation covers the encapsulation (ISL or 802.1Q) and whether the link becomes a trunk at all. This allows trunk links to be used without a great deal of manual configuration or administration. The use of DTP is explained in the next section.

Tip

You should disable DTP negotiation if a switch has a trunk link connected to a nontrunking router or firewall interface because those devices cannot participate in DTP negotiation. A trunk link can be negotiated between two switches only if both switches belong to the same VLAN Trunking Protocol (VTP) management domain or if one or both switches have not defined their VTP domain (that is, the NULL domain). VTP is discussed in Chapter 7. If the two switches are in different VTP domains and trunking is desired between them, you must set the trunk links to on mode or nonegotiate mode. This setting forces the trunk to be established. These options are explained in the next section.


VLAN Trunk Configuration

By default, all switch ports in Layer 2 mode are nontrunking and operate as access links until some intervention changes the mode. Specifically, ports actively try to become trunks as long as the far end agrees. In that case, a common encapsulation is chosen, favoring ISL if both support it. The sections that follow demonstrate the commands necessary to configure VLAN trunks.

VLAN Trunk Configuration

Use the following commands to create a VLAN trunk link:

Switch(config)# interface type mod/port Switch(config-if)# switchport Switch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate} Switch(config-if)# switchport trunk native vlan vlan-id Switch(config-if)# switchport trunk allowed vlan {vlan-list | all |   {add | except | remove} vlan-list} Switch(config-if)# switchport mode {trunk | dynamic {desirable | auto}}

A switch port must be in Layer 2 mode before it can support a trunk. To accomplish this, you use the switchport command with no other keywords. You then can configure the trunk encapsulation with the switchport trunk encapsulation command, as one of the following:

  • isl VLANs are tagged by encapsulating each frame using the Cisco ISL protocol.

  • dot1q VLANs are tagged in each frame using the IEEE 802.1Q standard protocol. The only exception is the native VLAN, which is sent normally and is not tagged.

  • negotiate (the default) The encapsulation is negotiated to select either ISL or IEEE 802.1Q, whichever both ends of the trunk support. If both ends support both types, ISL is favored. (The Catalyst 2950 switch does not support ISL encapsulation.)

In the case of an IEEE 802.1Q trunk, you should configure the native VLAN with the switchport trunk native vlan command, identifying the untagged or native VLAN number as vlan-id (1 to 4094). By default, an 802.1Q trunk uses VLAN 1 as the native VLAN. In the case of an ISL trunk, using this command has no effect because ISL doesn't support an untagged VLAN.

The last command, switchport trunk allowed vlan, defines which VLANs can be trunked over the link. By default, a switch transports all active VLANs (1 to 4094) over a trunk link. An active VLAN is one that has been defined on the switch and has ports assigned to carry it.

There might be times when the trunk link should not carry all VLANs. For example, broadcasts are forwarded to every switch port on a VLANincluding the trunk link because it, too, is a member of the VLAN. If the VLAN does not extend past the far end of the trunk link, propagating broadcasts across the trunk makes no sense.

You can tailor the list of allowed VLANs on the trunk by using the switchport trunk allowed vlan command with one of the following:

  • vlan-listAn explicit list of VLAN numbers, separated by commas or dashes.

  • allAll active VLANs (1 to 4094) will be allowed.

  • add vlan-listA list of VLAN numbers will be added to the already configured list; this is a shortcut to keep from typing a long list of numbers.

  • except vlan-listAll VLANs (1 to 4094) will be allowed, except for the VLAN numbers listed; this is a shortcut to keep from typing a long list of numbers.

  • remove vlan-listA list of VLAN numbers will be removed from the already configured list; this is a shortcut to keep from typing a long list of numbers.

In the switchport mode command, you can set the trunking mode to any of the following:

  • trunk This setting places the port in permanent trunking mode. DTP is still operational, so if the far-end switch port is configured to trunk, dynamic desirable, or dynamic auto mode, trunking will be negotiated successfully.

    The trunk mode is usually used to establish an unconditional trunk. Therefore, the corresponding switch port at the other end of the trunk should be configured similarly. In this way, both switches always expect the trunk link to be operational without any negotiation. You also should manually configure the encapsulation mode to eliminate its negotiation.

  • dynamic desirable (the default) The port actively attempts to convert the link into trunking mode. In other words, it "asks" the far-end switch to bring up a trunk. If the far-end switch port is configured to trunk, dynamic desirable, or dynamic auto mode, trunking is negotiated successfully.

  • dynamic auto The port can be converted into a trunk link, but only if the far-end switch actively requests it. Therefore, if the far-end switch port is configured to trunk or dynamic desirable mode, trunking is negotiated. Because of the passive negotiation behavior, the link never becomes a trunk if both ends of the link are left to the dynamic auto default.

Tip

In all these modes, DTP frames are sent out every 30 seconds to keep neighboring switch ports informed of the link's mode. On critical trunk links in a network, manually configuring the trunking mode on both ends is best so that the link never can be negotiated to any other state. If you decide to configure both ends of a trunk link as a fixed trunk (switchport mode trunk), you can disable DTP completely so that these frames are not exchanged. To do this, add the switchport nonegotiate command to the interface configuration. Be aware that after DTP frames are disabled, no future negotiation is possible until this configuration is reversed.


To view the trunking status on a switch port, use the show interface type mod/port trunk command, as demonstrated in Example 6-2.

Example 6-2. Determining Switch Port Trunking Status
Switch# show interface gig 2/1 trunk Port      Mode         Encapsulation  Status        Native vlan Gi2/1     on           802.1q         trunking      1 Port      Vlans allowed on trunk Gi2/1     1-4094 Port      Vlans allowed and active in management domain Gi2/1      1-2,526,539,998,1002-1005 Port      Vlans in spanning tree forwarding state and not pruned Gi2/1      1-2,526,539,998,1002-1005

Trunk Configuration Example

As an example of trunk configuration, consider two switches, Switch-D and Switch-A, which are distribution-layer and access-layer switches, respectively. The two switches are connected by a link between their GigabitEthernet 2/1 interfaces. This link should be configured to be a trunk carrying only VLAN numbers 100 through 105, although more VLANs exist and are used.

The trunk link should use 802.1Q encapsulation, with VLAN 100 as the native VLAN. First, configure Switch-D to actively negotiate a trunk with the far-end switch. You could use the following configuration commands on Switch-D:

Switch-D(config)# interface gig 2/1 Switch-D(config-if)# switchport trunk encapsulation dot1q Switch-D(config-if)# switchport trunk native vlan 100 Switch-D(config-if)# switchport trunk allowed vlan 100-105 Switch-D(config-if)# switchport mode dynamic desirable

At this point, you assume that Switch-A is configured correctly, too. Now, you should try to verify that the trunk is working as expected. On Switch-D, you can view the trunk status with the following command:

Switch-D# show interface gig 2/1 trunk Port        Mode         Encapsulation  Status        Native vlan Gi1/1       desirable    802.1q         not-trunking  100 Port      Vlans allowed on trunk Gi1/1       100 Port        Vlans allowed and active in management domain Gi1/1       100 Port        Vlans in spanning tree forwarding state and not pruned Gi1/1       none

To your surprise, the trunk's status is not-trunking. Next, you should verify that the physical link is up:

Switch-D# show interface status Port      Name               Status       Vlan       Duplex  Speed Type Gi1/1                        notconnect   1            auto   1000 1000BaseSX Gi1/2                        notconnect   1            auto   1000 1000BaseSX Gi2/1                        connected    100          full   1000 1000BaseSX

What could be preventing the trunk from being established? If Switch-D is in dynamic desirable negotiation mode, it is actively asking Switch-A to bring up a trunk. Obviously, Switch-A must not be in agreement. The desirable mode can negotiate a trunk with all other trunking modes, so Switch-A's interface must not be configured for trunking. Instead, it is most likely configured as an access port (switchport mode access).

Switch-A can be corrected by configuring its GigabitEthernet 2/1 interface to negotiate a trunk. Switch-D is in dynamic desirable mode, so Switch-A could use either trunk, dynamic desirable, or dynamic auto mode.

Now, suppose you realize that VLAN 103 should not be passed between these switches. You can use either of the following command sequences to manually prune VLAN 103 from the trunk:

Switch-D(config)# interface gig 2/1 Switch-D(config-if)# switchport trunk allowed vlan 100-102,104-105

or:

Switch-D(config-if)# switchport trunk allowed vlan remove 103

In the latter case, the previous range of 100 to 105 is kept in the configuration, and only 103 automatically is removed from the list.

When you manually prune VLANs from being allowed on a trunk, the same operation should be performed at both ends of the trunk link. Otherwise, one of the two switches still could flood broadcasts from that VLAN onto the trunk, using unnecessary bandwidth in only one direction.

For completeness, the configuration of Switch-A at this point would look like the following:

Switch-A(config)# interface gig 2/1 Switch-A(config-if)# switchport trunk encapsulation dot1q Switch-A(config-if)# switchport trunk native vlan 100 Switch-A(config-if)# switchport trunk allowed vlan 100-105 Switch-A(config-if)# switchport trunk allowed vlan remove 103 Switch-A(config-if)# switchport mode dynamic desirable

Troubleshooting VLANs and Trunks

Remember that a VLAN is nothing more than a logical network segment that can be spread across many switches. If a PC in one location cannot communicate with a PC in another location, where both are assigned to the same IP subnet, make sure that both of their switch ports are configured for the same VLAN. If they are, examine the path between the two. Is the VLAN carried continuously along the path? If there are trunks along the way, is the VLAN being carried across the trunks?

To verify a VLAN's configuration on a switch, use the show vlan id vlan-id EXEC command, as demonstrated in Example 6-3. Make sure the VLAN is shown to have an active status and that it has been assigned to the correct switch ports.

Example 6-3. Verifying Switch VLAN Configuration
Switch# show vlan id 2 VLAN Name                             Status    Ports ---- -------------------------------- --------- ------------------------------- 2    Engineering                      active     Gi2/1, Gi2/2, Gi2/3, Gi2/4                                                  Gi4/2, Gi4/3, Gi4/4, Gi4/5                                                  Gi4/6, Gi4/7, Gi4/8, Gi4/9                                                  Gi4/10, Gi4/11, Gi4/12 VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2 ---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------ 2    enet  100002     1500  -      -      -        -    -        0      0 Primary Secondary Type              Ports ------- --------- ----------------- ------------------------------------------ Switch#

For a trunk, these parameters must be agreeable on both ends before the trunk can operate correctly:

  • Trunking mode (unconditional trunking, negotiated, or nonnegotiated).

  • Trunk encapsulation (ISL, IEEE 802.1Q, or negotiated through DTP).

  • Native VLAN. You can bring up a trunk with different native VLANs on each end; however, both switches will log error messages about the mismatch, and the potential exists that traffic will not pass correctly between the two native VLANs.

    The native VLAN mismatch is discovered through the exchange of CDP messages, not through examination of the trunk itself. Also, the native VLAN is configured independently of the trunk encapsulation, so it is possible to have a native VLAN mismatch even if the ports use ISL encapsulation. In this case, the mismatch is only cosmetic and won't cause a trunking problem.

  • Allowed VLANs. By default, a trunk allows all VLANs to be transported across it. If one end of the trunk is configured to disallow a VLAN, that VLAN will not be contiguous across the trunk.

To see a comparison of how a switch port is configured for trunking versus its active state, use the show interface type mod/num switchport command, as demonstrated in Example 6-4. Look for the administrative versus operational values, respectively, to see if the trunk is working the way you configured it.

Notice that the port has been configured to negotiate a trunk through DTP (dynamic auto), but the port is operating in the static access (nontrunking) mode. This should tell you that both ends of the link probably are configured for the auto mode so that neither actively will request a trunk.

Example 6-4. Comparing Switch Port Trunking Configuration and Active State
Switch# show interface fast 0/2 switchport Name: Fa0/2 Switchport: Enabled Administrative Mode: dynamic auto Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Protected: false Unknown unicast blocked: disabled Unknown multicast blocked: disabled Voice VLAN: none (Inactive) Appliance trust: none Switch#

For more concise information about a trunking port, you can use the show interface [type mod/ num] trunk command, as demonstrated in Example 6-5.

Example 6-5. Viewing Concise Information About a Trunking Port
Switch# show interface fast 0/2 trunk Port      Mode         Encapsulation  Status        Native vlan Fa0/2     auto         802.1q         not-trunking  1 Port      Vlans allowed on trunk Fa0/2     1 Port      Vlans allowed and active in management domain Fa0/2     1 Port      Vlans in spanning tree forwarding state and not pruned Fa0/2     1 Switch#

Again, notice that the port is in the auto negotiation mode, but it is currently not-trunking. Because the port is not trunking, only the access VLAN (VLAN 1 in this example) is listed as allowed and active on the trunk.

To see if and how DTP is being used on a switch, use the show dtp [interface type mod/num] command. Specifying an interface shows the DTP activity in greater detail.



CCNP Self-Study(c) CCNP BCMSN Exam Certification Guide
Red Hat Fedora 5 Unleashed
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 177

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net